Bug 1625

What is the dbus-send comand you used?

(Odpověď na komentář #1)
> What is the dbus-send comand you used?

dbus-send is from dbus package. See:
http://dbus.freedesktop.org/doc/dbus-send.1.html

Some examples on:
http://upower.freedesktop.org/docs/UPower.html

A very useful tool is also d-feet:
https://wiki.gnome.org/DFeet

Yes, but what is the exact command syntax you used to test tdehwlib?

Also what usability symptoms are you seeing? I'm not noticing anything unsual.

The daemon does not provide introspection functionality as it is not needed when called from the TDE hardware library.  Therefore, this is not so much a bug report as it is a feature request to add introspection support to the daemon. ;-)

The fact that the demon does not offer information interfaces is now less important. The fundamental problem is that the demon certainly not running.

# dbus-send --system --print-reply \
   --dest=org.trinitydesktop.hardwarecontrol \
   /org/trinitydesktop/hardwarecontrol \
   org.trinitydesktop.hardwarecontrol.CPUGovernor.CanSetCPUGovernor \
   int32:0

Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1


When I run the daemon manually, I get another error message:

Error org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.84" (uid=0 pid=5031 comm="dbus-send) interface="org.trinitydesktop.hardwarecontrol.CPUGovernor" member="CanSetCPUGovernor" error name="(unset)" requested_reply=0 destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=5021 comm="/opt/trinity/bin/tde_dbus_hardwarecontrol))

Here is what I see in konsole:

dbus-send --system --print-reply --dest=org.trinitydesktop.hardwarecontrol /org/trinitydesktop/hardwarecontrol org.trinitydesktop.hardwarecontrol.CPUGovernor.CanSetCPUGovernor int32:0

method return sender=:1.14 -> dest=:1.13 reply_serial=2
   boolean true

I'm running git as of commit 3c06aad1 2013-08-11. I have not rebuilt tdelibs with the recent WITH_TDEHWLIB_DAEMONS changes.

Note: after starting Trinity, I see the following in my process list in konsole:

/opt/trinity/bin/tde_dbus_hardwarecontrol

> Note: after starting Trinity, I see the following in my process list in konsole:
Oops, my mistake. That was after I ran the previous dbus-send command. Apparently after I logged out of Trinity back to the command line, the tde_dbus_hardwarecontrol process did not terminate. Thus when I restarted Trinity the process seemed to have started but was actually still running from the previous session.

Should tde_dbus_hardwarecontrol terminate when Trinity is not running anywhere?

Ha, for you it behaves as it should! Exiting system service tde_dbus_hardwarecontrol is a matter for dbus.

I just noticed tdelibs CMakeLists.txt has a build option WITH_TDEHWLIB_DAEMONS that defaults to ${WITH_ALL_OPTIONS}, which defaults to OFF. Therefore I was never building tdelibs to use that option. Rebuilding now....

Slavek, do you have that build option enabled?

>I noticed that tdehwlib dbus daemon is not running, although it is properly installed.

Tim,

When should we see the tde_dbus_hardwarecontrol in the process tree? I just rebuilt tdelibs, with WITH_ALL_OPTIONS=ON, which means WITH_TDEHWLIB_DAEMONS=ON.

I do not see tde_dbus_hardwarecontrol in the process tree unless I run the dbus-send command, basically forcing a query of the daemon. Is that normal/expected? Is tde_dbus_hardwarecontrol someting that runs on demand? If yes, what kind of demands launches tde_dbus_hardwarecontrol?

Yes, what you are seeing is normal.  DBUS itself loads the daemon when a request is made; the daemon then stays loaded until system shutdown.  This is one of the primary reasons for high DBUS latency on the first call to some daemons. :-)

(Odpověď na komentář #10)
> I just noticed tdelibs CMakeLists.txt has a build option WITH_TDEHWLIB_DAEMONS
> that defaults to ${WITH_ALL_OPTIONS}, which defaults to OFF. Therefore I was
> never building tdelibs to use that option. Rebuilding now....
> 
> Slavek, do you have that build option enabled?

Yes, WITH_TDEHWLIB_DAEMONS is enabled, the daemon is built, it is installed but not working => as I wrote in a comment 0.

I have a test machine with Debian Squeeze.

>Yes, what you are seeing is normal.
Ok, now we know.

What kind of events will trigger tde_dbus_hardwarecontrol?

(In reply to comment #14)
> >Yes, what you are seeing is normal.
> Ok, now we know.
> 
> What kind of events will trigger tde_dbus_hardwarecontrol?

Requests to change CPU frequency or screen brightness.

>Requests to change CPU frequency or screen brightness.
Then perhaps I'm seeing the same thing as Slavek. When I test tdepowersave and the screen auto dims I don't see tdehardwarecontrol in the process list.

tdehardwarecontrol now appears regularly in my process list when I run tdepowersave. This is across reboots.

I tried dbus-daemon run from the console to see the output:

[tde_dbus_hardwarecontrol] Listening...
[tde_dbus_hardwarecontrol] Name request failed with error 'Rejected send message, 2 matched rules; type="method_call", sender=":1.1" (uid=0 pid=8424 comm="dbus-send) interface="org.trinitydesktop.hardwarecontrol.CPUGovernor" member="CanSetCPUGovernor" error name="(unset)" requested_reply=0 destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=8426 comm="/opt/trinity/bin/tde_dbus_hardwarecontrol))'
[tde_dbus_hardwarecontrol] Not primary owner (-1), exiting!

I see. I tested call dbus-send as root from ssh console. When I tried to call as a regular user of X console daemon is started and provides answers.

When I tried in /etc/dbus-1/system.d/org.trinitydesktop.hardwarecontrol.conf add rules to allow send also for <policy user="root">, daemon is started and provide answers also for the root in ssh console.

I assume that the default setting that allows sending only for <policy at_console="true"> is so intentionally. So this bug probably can be closed?

(In reply to comment #19)
> I assume that the default setting that allows sending only for <policy
> at_console="true"> is so intentionally. So this bug probably can be closed?

Yes, this is intentional.  Only people sitting at the local machine should be able to change the brightness/CPU frequency governor settings.

Tim

(Odpověď na komentář #20)
> (In reply to comment #19)
> > I assume that the default setting that allows sending only for <policy
> > at_console="true"> is so intentionally. So this bug probably can be closed?
> 
> Yes, this is intentional.  Only people sitting at the local machine should be
> able to change the brightness/CPU frequency governor settings.
> 
> Tim

Yes, I understand.

The fact that will be decency to define methods NameAcquired and Introspect are not subject to this bug report, which can therefore be closed.