#9 tdehw dbus daemons do not show DBus Introspectable interface in d-feet

Open
opened 10 months ago by MicheleC · 28 comments

Basic information

As of TDE R14.1.0-dev, the TDE HW DBUS daemon is missing the Introspectable interface. Any other DBus service that I have checked, does implement such interface.

## Basic information As of TDE R14.1.0-dev, the TDE HW DBUS daemon is missing the Introspectable interface. Any other DBus service that I have checked, does implement such interface.
MicheleC added this to the R14.2.0 release milestone 10 months ago
MicheleC commented 10 months ago
Owner

Correction. A call from CLI to introspect the interface works. But in d-feet the Introspectable interface does not show up.

dbus-send --system --dest=org.trinitydesktop.hardwarecontrol --type=method_call --print-reply /org/trinitydesktop/hardwarecontrol org.freedesktop.DBus.Introspectable.Introspect
Correction. A call from CLI to introspect the interface works. But in d-feet the Introspectable interface does not show up. ``` dbus-send --system --dest=org.trinitydesktop.hardwarecontrol --type=method_call --print-reply /org/trinitydesktop/hardwarecontrol org.freedesktop.DBus.Introspectable.Introspect ```
MicheleC changed title from tdehw dbus daemons do not implement DBus Introspectable interface to tdehw dbus daemons do not show DBus Introspectable interface in d-feet 10 months ago
SlavekB commented 10 months ago
Owner

I’m trying on R14.0.x branch – in d-feet I can browse the methods offered by TDE HW DBUS daemon without any problem.

You can test if that it’s not a regression caused by PR #2?

I'm trying on R14.0.x branch – in d-feet I can browse the methods offered by TDE HW DBUS daemon without any problem. You can test if that it's not a regression caused by PR #2?
SlavekB commented 10 months ago
Owner

The situation seems more mysterious. I have tried d-feet on Slax with Trinity => reported the problem. I installed the consolekit, logged off, again startx => was ok. I uninstalled the consolekit log off, again startx => was ok.

The situation seems more mysterious. I have tried d-feet on Slax with Trinity => reported the problem. I installed the consolekit, logged off, again startx => was ok. I uninstalled the consolekit log off, again startx => was ok.
MicheleC commented 10 months ago
Owner

TDE HW DBus daemon works fine in d-feet, no issue. What is missing is showing the Introspectable part, like other services. See screenshots, one showing the Introspectable interface in another service and one showing no Introspectable interface in tdehardwarecontrol

TDE HW DBus daemon works fine in d-feet, no issue. What is missing is showing the Introspectable part, like other services. See screenshots, one showing the Introspectable interface in another service and one showing no Introspectable interface in tdehardwarecontrol
MicheleC commented 10 months ago
Owner

Re “The situation seems more mysterious. I have tried d-feet on Slax with Trinity => reported the problem. I installed the consolekit, logged off, again startx => was ok. I uninstalled the consolekit log off, again startx => was ok.”

this sounds interesting. Perhaps something more to check :wink:

Re "The situation seems more mysterious. I have tried d-feet on Slax with Trinity => reported the problem. I installed the consolekit, logged off, again startx => was ok. I uninstalled the consolekit log off, again startx => was ok." this sounds interesting. Perhaps something more to check :wink:
SlavekB commented 10 months ago
Owner

Ah, I now understand – that the Introspectable interface and the Introspect method are not presented, although we are responding to this.

Ah, I now understand – that the Introspectable interface and the Introspect method are not presented, although we are responding to this.
deloptes commented 10 months ago
Collaborator

my 5cent on this topic - I also noticed this when looking into dbus implementations in TDE.

This is also the reason why I was looking into dbusxml2qt3 and wrote the howto after finding out how one could implement the Introspectable interface.

Not that it can not be implemented as already done, but I personally find it much nicer using the code as generated by dbusxml2qt3 and IMO it is not only less work but also less error prone.

In my PoC - the tdebluez project - I faced same problem - Introspectable was not visible but I could get response from it. AFAIR it was important to use the correct path for example “/”.

#define DBUS_AUTH_SERVICE_PATH  "/"

AuthService::AuthService(TQT_DBusConnection &conn)
	: org_trinitydesktop_tdebluez(),
	  m_connection(conn)
{
	m_interfaces.insert("org.freedesktop.DBus.Introspectable", this);
	m_interfaces.insert("org.bluez.Agent1", new Agent1Interface(m_connection));
	registerObject(m_connection,DBUS_AUTH_SERVICE_PATH);
}

So IMO the right thing (perhaps long term goal) would be to write the xml service file for org.trinitydesktop.hardwarecontrol and use dbusxml2qt3 to generate the interface and stop using low level dbus wrappers - I recall I’ve seen it also somewhere else in the tde code.

Although this is a different story, but it fits this context - dbusxml2qt3 needs to be pimped to generate async methods, but it would be more complex compared to the synchronous interfaces generated now.

my 5cent on this topic - I also noticed this when looking into dbus implementations in TDE. This is also the reason why I was looking into dbusxml2qt3 and wrote the howto after finding out how one could implement the Introspectable interface. Not that it can not be implemented as already done, but I personally find it much nicer using the code as generated by dbusxml2qt3 and IMO it is not only less work but also less error prone. In my PoC - the tdebluez project - I faced same problem - Introspectable was not visible but I could get response from it. AFAIR it was important to use the correct path for example "/". ``` #define DBUS_AUTH_SERVICE_PATH "/" AuthService::AuthService(TQT_DBusConnection &conn) : org_trinitydesktop_tdebluez(), m_connection(conn) { m_interfaces.insert("org.freedesktop.DBus.Introspectable", this); m_interfaces.insert("org.bluez.Agent1", new Agent1Interface(m_connection)); registerObject(m_connection,DBUS_AUTH_SERVICE_PATH); } ``` So IMO the right thing (perhaps long term goal) would be to write the xml service file for org.trinitydesktop.hardwarecontrol and use dbusxml2qt3 to generate the interface and stop using low level dbus wrappers - I recall I've seen it also somewhere else in the tde code. Although this is a different story, but it fits this context - dbusxml2qt3 needs to be pimped to generate async methods, but it would be more complex compared to the synchronous interfaces generated now.
deloptes commented 9 months ago
Collaborator

I was looking in hwlibdaemons and the introspection returned and in how it looks like in qdbusviewer. I was trying to find a way to generate code if I use a introspection xml file. There are several problems I see and I am not sure which is related to dbusxml2qt3 or to the design of tde_dbus_hardwarecontrol.c.

Changing this (based on previous discussion with Michele) looks appropriate for 14.2 and I would like to discuss this somewhere. As I can hardly catch you on jabber, where can we discuss this?

I was looking in hwlibdaemons and the introspection returned and in how it looks like in qdbusviewer. I was trying to find a way to generate code if I use a introspection xml file. There are several problems I see and I am not sure which is related to dbusxml2qt3 or to the design of tde_dbus_hardwarecontrol.c. Changing this (based on previous discussion with Michele) looks appropriate for 14.2 and I would like to discuss this somewhere. As I can hardly catch you on jabber, where can we discuss this?
MicheleC commented 9 months ago
Owner

We can discuss here or on jabber (you will find me in early afternoon usually these days, due to time difference and workload). What is it exactly that you are looking at?

We can discuss here or on jabber (you will find me in early afternoon usually these days, due to time difference and workload). What is it exactly that you are looking at?
deloptes commented 9 months ago
Collaborator

I don’t have access to anything usable from the office and when I get home it is about 18:00CET earliest.

What I am looking at is the introspection of org.trinitydesktop.hardwarecontrol and what is in fact implemented in “tdelibs/tdecore/tdehw/hwlibdaemons/dbus/tde_dbus_hardwarecontrol.c”

Introspection reports

<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
  <interface name="org.trinitydesktop.hardwarecontrol.Brightness">
    <method name="CanSetBrightness">
      <arg name="device" direction="in" type="s" />
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="SetBrightness">
      <arg name="device" direction="in" type="s" />
      <arg name="brightness" direction="in" type="s" />
      <arg name="value" direction="out" type="b" />
    </method>
  </interface>
  <interface name="org.trinitydesktop.hardwarecontrol.CPUGovernor">
    <method name="CanSetCPUGovernor">
      <arg name="cpu" direction="in" type="i" />
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="SetCPUGovernor">
      <arg name="cpu" direction="in" type="i" />
      <arg name="governor" direction="in" type="s" />
      <arg name="value" direction="out" type="b" />
    </method>
  </interface>
  <interface name="org.trinitydesktop.hardwarecontrol.InputEvents">
    <method name="GetProvidedSwitches">
      <arg name="device" direction="in" type="s" />
      <arg name="value" direction="out" type="au" />
    </method>
    <method name="GetActiveSwitches">
      <arg name="device" direction="in" type="s" />
      <arg name="value" direction="out" type="au" />
    </method>
  </interface>
  <interface name="org.trinitydesktop.hardwarecontrol.Power">
    <method name="CanStandby">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="Standby">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="CanFreeze">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="Freeze">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="CanSuspend">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="Suspend">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="CanHibernate">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="Hibernate">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="CanHybridSuspend">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="HybridSuspend">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="CanSetHibernationMethod">
      <arg name="value" direction="out" type="b" />
    </method>
    <method name="SetHibernationMethod">
      <arg name="method" direction="in" type="s" />
      <arg name="value" direction="out" type="b" />
    </method>
  </interface>
</node>

but you have node org, trinitydesktop, hardwarecontrol also implemented - what for? If you ommit the nodes it makes no difference unless you want to manage something at each level of the hierarchy - look at org.bluez. At the highest level you have the freedesktop Introspection and ObjectManager interfaces and below in /org/bluez the bluez relevant stuff. By analogy this would mean you should have Introspection and ObjectManager at top level and the details in /org/trinitydesktop/hardwarecontrol. Preferably we could use /org/trinitydesktop for other trinitydesktop dbus stuff. But a proper manager is required.

Therefor I think it is worth discussing and designing properly a dbus interface at higher level that could manage all trinitydesktop related interfaces.

Another thing related to hardwarecontrol is the mentioned Properties and also the signal “NameAcquired” which is not exported in the introspection. What is it good for?

regards

I don't have access to anything usable from the office and when I get home it is about 18:00CET earliest. What I am looking at is the introspection of org.trinitydesktop.hardwarecontrol and what is in fact implemented in "tdelibs/tdecore/tdehw/hwlibdaemons/dbus/tde_dbus_hardwarecontrol.c" Introspection reports ``` <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> <node> <interface name="org.trinitydesktop.hardwarecontrol.Brightness"> <method name="CanSetBrightness"> <arg name="device" direction="in" type="s" /> <arg name="value" direction="out" type="b" /> </method> <method name="SetBrightness"> <arg name="device" direction="in" type="s" /> <arg name="brightness" direction="in" type="s" /> <arg name="value" direction="out" type="b" /> </method> </interface> <interface name="org.trinitydesktop.hardwarecontrol.CPUGovernor"> <method name="CanSetCPUGovernor"> <arg name="cpu" direction="in" type="i" /> <arg name="value" direction="out" type="b" /> </method> <method name="SetCPUGovernor"> <arg name="cpu" direction="in" type="i" /> <arg name="governor" direction="in" type="s" /> <arg name="value" direction="out" type="b" /> </method> </interface> <interface name="org.trinitydesktop.hardwarecontrol.InputEvents"> <method name="GetProvidedSwitches"> <arg name="device" direction="in" type="s" /> <arg name="value" direction="out" type="au" /> </method> <method name="GetActiveSwitches"> <arg name="device" direction="in" type="s" /> <arg name="value" direction="out" type="au" /> </method> </interface> <interface name="org.trinitydesktop.hardwarecontrol.Power"> <method name="CanStandby"> <arg name="value" direction="out" type="b" /> </method> <method name="Standby"> <arg name="value" direction="out" type="b" /> </method> <method name="CanFreeze"> <arg name="value" direction="out" type="b" /> </method> <method name="Freeze"> <arg name="value" direction="out" type="b" /> </method> <method name="CanSuspend"> <arg name="value" direction="out" type="b" /> </method> <method name="Suspend"> <arg name="value" direction="out" type="b" /> </method> <method name="CanHibernate"> <arg name="value" direction="out" type="b" /> </method> <method name="Hibernate"> <arg name="value" direction="out" type="b" /> </method> <method name="CanHybridSuspend"> <arg name="value" direction="out" type="b" /> </method> <method name="HybridSuspend"> <arg name="value" direction="out" type="b" /> </method> <method name="CanSetHibernationMethod"> <arg name="value" direction="out" type="b" /> </method> <method name="SetHibernationMethod"> <arg name="method" direction="in" type="s" /> <arg name="value" direction="out" type="b" /> </method> </interface> </node> ``` but you have node org, trinitydesktop, hardwarecontrol also implemented - what for? If you ommit the nodes it makes no difference unless you want to manage something at each level of the hierarchy - look at org.bluez. At the highest level you have the freedesktop Introspection and ObjectManager interfaces and below in /org/bluez the bluez relevant stuff. By analogy this would mean you should have Introspection and ObjectManager at top level and the details in /org/trinitydesktop/hardwarecontrol. Preferably we could use /org/trinitydesktop for other trinitydesktop dbus stuff. But a proper manager is required. Therefor I think it is worth discussing and designing properly a dbus interface at higher level that could manage all trinitydesktop related interfaces. Another thing related to hardwarecontrol is the mentioned Properties and also the signal "NameAcquired" which is not exported in the introspection. What is it good for? regards
deloptes commented 9 months ago
Collaborator

I also think when you have a proper definition of the interface and use dbusxml2qt3 to generate the code everything is much simpler and better structured.

The question is why should I have /org/trinitydesktop/hardwarecontrol under /org/trinitydesktop/hardwarecontrol which is the current implementation - unless as mentioned before it is intended to hold also other interfaces, but the management is missing.

I also think when you have a proper definition of the interface and use dbusxml2qt3 to generate the code everything is much simpler and better structured. The question is why should I have /org/trinitydesktop/hardwarecontrol under /org/trinitydesktop/hardwarecontrol which is the current implementation - unless as mentioned before it is intended to hold also other interfaces, but the management is missing.
MicheleC commented 9 months ago
Owner

I wasn’t involved at the time the TDE dbus daemon was developed, but the structure of the dbus name seems fine to me. It follows a well-known convention which was introduced by Java (AFAICT) and has been around for almost 25 years now. The first part is the “organization” part and then you have the “services” part. If in future we add more services to TDE DBus, these would go under org.trinitydesktop.

I wasn't involved at the time the TDE dbus daemon was developed, but the structure of the dbus name seems fine to me. It follows a well-known convention which was introduced by Java (AFAICT) and has been around for almost 25 years now. The first part is the "organization" part and then you have the "services" part. If in future we add more services to TDE DBus, these would go under org.trinitydesktop.<object name> for example. <br> Introspection goes at the service level, to provide a list of what is available. You can use d-feet to take a look at other services in the system to have the idea, if required. Whatever is under "org.trinitydesktop.hardwarecontrol.Power" is definitely used, the remaining interfaces and properties I do not know at the moment, I will need to look into the code. We can look at simplifying them if they are not needed/used :wink: BTW, I am currently looking at adding polkit support to TDE HW DBus daemon, so expect the structure of the file to change a bit when that is ready.
SlavekB commented 9 months ago
Owner

The TDE HW DBus daemon was created as a simple tool to provide hardware-related tasks that require higher privileges. Therefore, Tim created it as a very simple code in C, no objects. Initially, there was no function that would provide data for introspection… Gradually, additional functions have been added, which are not provided by other tools – such as brightness adjustment, switch status detection (like LID). Most of these functions are my work. Including a function providing data for introspection. However, this is still a very simple code in C. Therefore, it still does not provide everything that is common in DBus daemons. Since data for introspection is created manually, only functions that are useful to users and for testing are listed here.

The fact that a full /org/trinity path is defined in the daemon, although this daemon provides functions on /org/trinitydesktop/hardwarecontrol seems to me to be a common way in DBus daemons. This does not prevent it if it will be useful to create another daemon that will provide other functions on /opt/trinity/<something>.

If you have enough effort to implement a daemon in a better way, we will welcome it.

The TDE HW DBus daemon was created as a simple tool to provide hardware-related tasks that require higher privileges. Therefore, Tim created it as a very simple code in C, no objects. Initially, there was no function that would provide data for introspection… Gradually, additional functions have been added, which are not provided by other tools – such as brightness adjustment, switch status detection (like LID). Most of these functions are my work. Including a function providing data for introspection. However, this is still a very simple code in C. Therefore, it still does not provide everything that is common in DBus daemons. Since data for introspection is created manually, only functions that are useful to users and for testing are listed here. The fact that a full /org/trinity path is defined in the daemon, although this daemon provides functions on /org/trinitydesktop/hardwarecontrol seems to me to be a common way in DBus daemons. This does not prevent it if it will be useful to create another daemon that will provide other functions on /opt/trinity/&lt;something&gt;. If you have enough effort to implement a daemon in a better way, we will welcome it.
deloptes commented 9 months ago
Collaborator

Hi, indeed I understand you both. This is also my observation, so I suggest we start with some discussion and clean xml interface specs.

The one point to keep all trinity related under org.trinitydesktop is intuitively OK - however there must be an interface to manage or list those services.

The challenge I have is that you have a service org.trinitydesktop.hardwarecontrol and a path for the interfaces of this service in /org/trinitydesktop/hardwarecontrol

Naturally a service to cover trinity related would be org.trinitydesktop with path /org/trinitydesktop and under this service the other services would follow.

Second point is that dbusxml2qt3 is somehow limited and does not allow empty nodes.

I will try to find out some suitable solution and will send you a proposal.

regards

Hi, indeed I understand you both. This is also my observation, so I suggest we start with some discussion and clean xml interface specs. The one point to keep all trinity related under org.trinitydesktop is intuitively OK - however there must be an interface to manage or list those services. The challenge I have is that you have a service org.trinitydesktop.hardwarecontrol and a path for the interfaces of this service in /org/trinitydesktop/hardwarecontrol Naturally a service to cover trinity related would be org.trinitydesktop with path /org/trinitydesktop and under this service the other services would follow. Second point is that dbusxml2qt3 is somehow limited and does not allow empty nodes. I will try to find out some suitable solution and will send you a proposal. regards
MicheleC commented 9 months ago
Owner

“org.trinitydesktop” is not a service, is the organization providing services. The service we are providing is (for now) hardwarecontrol, which is used to control some of the hardware aspects.
This is similar to the structure in freedesktop, where “org.freedesktop” is the organization part and then you have multiple services available (for example logind, polkit, consolekit, upower to name a few).
I think the current structure of TDE DBus is ok. Perhaps we can rearrange the services that we use and for example separate the section related to Power control from the one that controls the screen brightness, just as an example. In future we may be able to offer more services, perhaps even migrate some from DCOP to DBus.

"org.trinitydesktop" is not a service, is the organization providing services. The service we are providing is (for now) hardwarecontrol, which is used to control some of the hardware aspects.<br> This is similar to the structure in freedesktop, where "org.freedesktop" is the organization part and then you have multiple services available (for example logind, polkit, consolekit, upower to name a few).<br> I think the current structure of TDE DBus is ok. Perhaps we can rearrange the services that we use and for example separate the section related to Power control from the one that controls the screen brightness, just as an example. In future we may be able to offer more services, perhaps even migrate some from DCOP to DBus.
deloptes commented 9 months ago
Collaborator

I think the interfaces under hardwarecontrol are pretty OK. What I do not get is how I can generate the node structure out of introspection file with dbusxml2qt3. I also understood it this way and tried implementing in org.trinitydesktop.tdebluez. I couldn’t get this hierarchy /org/trinitydesktop/tdebluez to work. But it could be I need to have another look into that.

Thank you in any case for sharing this as it clarifies the overall plan and view.

I think the interfaces under hardwarecontrol are pretty OK. What I do not get is how I can generate the node structure out of introspection file with dbusxml2qt3. I also understood it this way and tried implementing in org.trinitydesktop.tdebluez. I couldn't get this hierarchy /org/trinitydesktop/tdebluez to work. But it could be I need to have another look into that. Thank you in any case for sharing this as it clarifies the overall plan and view.
MicheleC commented 9 months ago
Owner

re org.trinitydesktop.tdebluez: yes, you got the point :smile: I have not used dbusxml2qt3, so I can’t make any comment about it, but I guess there is a way to have subnodes since this is pretty much the standard in dbus world.

re org.trinitydesktop.tdebluez: yes, you got the point :smile: I have not used dbusxml2qt3, so I can't make any comment about it, but I guess there is a way to have subnodes since this is pretty much the standard in dbus world.
deloptes commented 9 months ago
Collaborator

I was just looking today into it and played a bit with the generated code. I also looked at dbusxml2qt3.

I will open an issue in dbus-1-tqt as it belongs there. I think dbusxml2qt3 is poorly implemented or implemented based on old dbus concept as it does not support empty nodes (without interface) even if it should as Introspectable is always present.

I think it would be good if dbusxml2qt3 could be used in future dbus implementations as it saves a lot of time and makes things nice … nice but not perfect :)

Let’s move it to dbus-1-tqt.

For this specific case if I call:

dbus-send --print-reply --system --dest=org.trinitydesktop.hardwarecontrol /org/trinitydesktop/hardwarecontrol org.freedesktop.DBus.Introspectable.Introspect

I get a node without a name and dbusxml2qt3 refuses to create the node class.

If I add name to the node i.e. it would generate the node class “hardwarecontrolnode” and interfaces can be accessed via this class.

So what is right? See here: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format

Only the root element can omit the node name, as it’s known to be the object that was introspected. If the root does have a name attribute, it must be an absolute object path. If child have object paths, they must be relative.

If a child has any sub-elements, then they must represent a complete introspection of the child. If a child is empty, then it may or may not have sub-elements; the child must be introspected in order to find out. The intent is that if an object knows that its children are “fast” to introspect it can go ahead and return their information, but otherwise it can omit it.

So do I understand it right that by asking for Introspection at /org/trinitydesktop/hardwarecontrol we are at the root node and omitting the name is correct? However it also says that it should have absolute object path, so <node name="/org/trinitydesktop/hardwarecontrol">...</node> is also correct and accepted by dbusxml2qt3.

Please help understand where what is right. Thanks!

I was just looking today into it and played a bit with the generated code. I also looked at dbusxml2qt3. I will open an issue in dbus-1-tqt as it belongs there. I think dbusxml2qt3 is poorly implemented or implemented based on old dbus concept as it does not support empty nodes (without interface) even if it should as Introspectable is always present. I think it would be good if dbusxml2qt3 could be used in future dbus implementations as it saves a lot of time and makes things nice ... nice but not perfect :) Let's move it to dbus-1-tqt. For this specific case if I call: ``` dbus-send --print-reply --system --dest=org.trinitydesktop.hardwarecontrol /org/trinitydesktop/hardwarecontrol org.freedesktop.DBus.Introspectable.Introspect ``` I get a node without a name and dbusxml2qt3 refuses to create the node class. If I add name to the node i.e. <node name="hardwarecontrol"> it would generate the node class "hardwarecontrolnode" and interfaces can be accessed via this class. So what is right? See here: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format >Only the root <node> element can omit the node name, as it's known to be the object that was introspected. If the root <node> does have a name attribute, it must be an absolute object path. If child <node> have object paths, they must be relative. > >If a child <node> has any sub-elements, then they must represent a complete introspection of the child. If a child <node> is empty, then it may or may not have sub-elements; the child must be introspected in order to find out. The intent is that if an object knows that its children are "fast" to introspect it can go ahead and return their information, but otherwise it can omit it. So do I understand it right that by asking for Introspection at /org/trinitydesktop/hardwarecontrol we are at the root node and omitting the name is correct? However it also says that it should have absolute object path, so `<node name="/org/trinitydesktop/hardwarecontrol">...</node>` is also correct and accepted by dbusxml2qt3. Please help understand where what is right. Thanks!
deloptes commented 9 months ago
Collaborator

We did not discuss

  1. signal NameAcquired
  2. Properties

both are in the code but missing in the introspection

We did not discuss 1. signal NameAcquired 2. Properties both are in the code but missing in the introspection
MicheleC commented 9 months ago
Owner

I am no expert, by my understanding is that at the root node you can omit the node name because you already know where you are since you are introspecting that node. There may be a node name attribute, but it is not mandatory and if present, all children need relative paths instead of absolute paths.

Again, when unsure it is good practice to compare with other well-known services. For example the reply from

dbus-send --print-reply=literal --system --dest=org.freedesktop.PolicyKit1 /org/freedesktop/PolicyKit1/Authority org.freedesktop.DBus.Introspectable.Introspect

is very similar to the one you get from tde

I am no expert, by my understanding is that at the root node you can omit the node name because you already know where you are since you are introspecting that node. There may be a node name attribute, but it is not mandatory and if present, all children need relative paths instead of absolute paths. Again, when unsure it is good practice to compare with other well-known services. For example the reply from ``` dbus-send --print-reply=literal --system --dest=org.freedesktop.PolicyKit1 /org/freedesktop/PolicyKit1/Authority org.freedesktop.DBus.Introspectable.Introspect ``` is very similar to the one you get from tde
deloptes commented 9 months ago
Collaborator

I would go on with this discussion in TDE/dbus-1-tqt#3 I think there is a missing link as stated there, where you can generate the code for a node with interfaces, but not for the rest of the path, so that you can actually access the interfaces. I would love to correct it (if I could), but I need a proper understanding as the documentation I read is a bit confusing so is the current implementation.

Let us discuss here the two other topics, that I did not understand - why they are in the code but not in the interface and what they are good for. This is indeed tdehw related.

thanks

I would go on with this discussion in TDE/dbus-1-tqt#3 I think there is a missing link as stated there, where you can generate the code for a node with interfaces, but not for the rest of the path, so that you can actually access the interfaces. I would love to correct it (if I could), but I need a proper understanding as the documentation I read is a bit confusing so is the current implementation. Let us discuss here the two other topics, that I did not understand - why they are in the code but not in the interface and what they are good for. This is indeed tdehw related. thanks
MicheleC commented 9 months ago
Owner

At first sight, it could just be a bug that need fixing. I will come back on those missing points in a while, after I am done with polkit in tde hw dbus, if you do not mind.

At first sight, it could just be a bug that need fixing. I will come back on those missing points in a while, after I am done with polkit in tde hw dbus, if you do not mind.
SlavekB commented 9 months ago
Owner

We did not discuss

  1. signal NameAcquired
  2. Properties

both are in the code but missing in the introspection

Both have a simple explanation:

The functions that we need are treated in the code. And for other functions, an error message is returned – see error_UnknownMessage.

When daemon is started and will acquire requested dbus name, we get the NameAcquired signal. If the response was not treated in the code, an error message would be returned.

A similar situation was also with Properties / GetAll => if we did not respond to this call, then would not properly work introspection (if I remember correctly).

Both are therefore functions that we do not need => that’s why we did not burden to write information into introspection, but they are necessary for DBus communication to be in all decency.

> We did not discuss > > 1. signal NameAcquired > 2. Properties > > both are in the code but missing in the introspection Both have a simple explanation: The functions that we need are treated in the code. And for other functions, an error message is returned – see error_UnknownMessage. When daemon is started and will acquire requested dbus name, we get the NameAcquired signal. If the response was not treated in the code, an error message would be returned. A similar situation was also with Properties / GetAll => if we did not respond to this call, then would not properly work introspection (if I remember correctly). Both are therefore functions that we do not need => that's why we did not burden to write information into introspection, but they are necessary for DBus communication to be in all decency.
deloptes commented 9 months ago
Collaborator

Thank you Slavek! I can not comment NameAcquired, but I doubt you need empty response to Properties.GetAll .

It could be that it fits here:

Each value is a dict whose keys are interfaces names. Each value in this inner dict is the same dict that would be returned by the org.freedesktop.DBus.Properties.GetAll() method for that combination of object path and interface. If an interface has no properties, the empty dict is returned.

So what you say makes sense for the last sentence.

So now it makes more sense but I’ll test both when I am that far.

Thanks for explaining

Thank you Slavek! I can not comment NameAcquired, but I doubt you need empty response to Properties.GetAll . It could be that it fits [here](https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties): >Each value is a dict whose keys are interfaces names. Each value in this inner dict is the same dict that would be returned by the org.freedesktop.DBus.Properties.GetAll() method for that combination of object path and interface. If an interface has no properties, the empty dict is returned. So what you say makes sense for the last sentence. So now it makes more sense but I'll test both when I am that far. Thanks for explaining
deloptes commented 9 months ago
Collaborator

I forgot to mention that I think both should be in the interface Introspection if I were to create the interface with dbusxml2qt3. The NameAquired is sent to the connection when it obtains the requested name, but I have difficulty to understand what this means

void signal_NameAcquired(DBusMessage* msg) {
    DBusMessageIter args;
    char *name = NULL;
    if(dbus_message_iter_init(msg, &args)) {
        if(DBUS_TYPE_STRING == dbus_message_iter_get_arg_type(&args)) {
            dbus_message_iter_get_basic(&args, &name);
        }
    }
    fprintf(stderr, "[tde_dbus_hardwarecontrol] Name acquired: %s\n", name);
}

please explain and thanks in advance

I forgot to mention that I think both should be in the interface Introspection if I were to create the interface with dbusxml2qt3. The NameAquired is sent to the connection when it obtains the requested name, but I have difficulty to understand what this means ``` void signal_NameAcquired(DBusMessage* msg) { DBusMessageIter args; char *name = NULL; if(dbus_message_iter_init(msg, &args)) { if(DBUS_TYPE_STRING == dbus_message_iter_get_arg_type(&args)) { dbus_message_iter_get_basic(&args, &name); } } fprintf(stderr, "[tde_dbus_hardwarecontrol] Name acquired: %s\n", name); } ``` please explain and thanks in advance
MicheleC commented 9 months ago
Owner

I agree with Emanoil that those should be in the introspectable interface too. Again, compare with what other service do is the key, and I see “Properties.GetAll” in login1 or polkit1 for example. I don’t see the NameAcquired, so either it is not necessary or it does not need to be in the interface.

I agree with Emanoil that those should be in the introspectable interface too. Again, compare with what other service do is the key, and I see "Properties.GetAll" in login1 or polkit1 for example. I don't see the NameAcquired, so either it is not necessary or it does not need to be in the interface.
deloptes commented 9 months ago
Collaborator

IMO they should not be required, but I did not manage to test it and confirm so far. No interface in hardwarecontrol suggests Properties - GetAll returns empty dictionary - could be that is implicit from dbus, and I did not have to implement such in tdebluez - also not properties present.

NameAcquired seems to be connection specific

org.freedesktop.DBus.NameAcquired

This is a signal:

       NameAcquired (STRING name)

Message arguments: Argument Type Description 0 STRING Name which was acquired

This signal is sent to a specific application when it gains ownership of a name.

but as I mentioned I do not understand the code, if it is listening to this signal, or is implementing it.

IMO they should not be required, but I did not manage to test it and confirm so far. No interface in hardwarecontrol suggests Properties - GetAll returns empty dictionary - could be that is implicit from dbus, and I did not have to implement such in tdebluez - also not properties present. NameAcquired seems to be connection specific >org.freedesktop.DBus.NameAcquired > >This is a signal: > > NameAcquired (STRING name) > > >Message arguments: >Argument Type Description >0 STRING Name which was acquired > >This signal is sent to a specific application when it gains ownership of a name. but as I mentioned I do not understand the code, if it is listening to this signal, or is implementing it.
MicheleC commented 8 months ago
Owner

Introspect, Peer and Properties standard interfaces have been added in PR #2.

NameAcquired is a standard dbus signal. The current code in tde hw daemon simply prints a message in the log if the signal is received.

Introspect, Peer and Properties standard interfaces have been added in PR #2. NameAcquired is a standard dbus signal. The current code in tde hw daemon simply prints a message in the log if the signal is received.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.