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

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.

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

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?

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.

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

intro_2.jpg

112 KiB

intro_1.jpg

222 KiB

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 😉

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

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.

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?

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?

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

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 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.

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.

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

"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.

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.

re org.trinitydesktop.tdebluez: yes, you got the point 😄
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.

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!

We did not discuss

signal NameAcquired
Properties

both are in the code but missing in the introspection

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 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

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.

We did not discuss

signal NameAcquired

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.

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

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 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.

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.

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.

https://mirror.git.trinitydesktop.org/gitea/deloptes/hardwarecontrol

perhaps

Hi Emanoil,
I assume this is an alternative implementation of the tdehw daemon that we talked about a few times.
Will put on my list of things to do after R14.0.10 is out.

Quick feedback: I see you derived from TQApplication. We need to make sure this is a unique application, since it is meant to be a daemon. So if we launching twice the second instance should just exit right away. I may be wrong (I had a super super super quick look) but I don't see any such check. The second instance would keep trying acquiring the bus name every 4 seconds, which although technically not wrong, is a bit pointless giving we are talking about daemon services, IMO. What do you think?

I think we can move all related discussions to #132 now.

I think we can move all related discussions to #132 now.

so shall we close this issue and jsut continue on #132?

You opened the issue, so that we do not forget, but now you are asking me to close it :)
If you wish, I don't mind. Of course we could also close, when #132 is merged.

ok, let's leave it open until we complete work on #132. Makes more sense I guess.