multimedia keys don't work when xfce4-volumed is run in daemon mode

This bug can be "fixed" by moving the fork() to before the gtk_init() - which is apparently the only correct order to make these calls.

It should also be noted that upstream in xfce, the fork() call happens before gtk_init().

Upstream latest version is 0.1.13, the version in ubuntu claims to be 0.2.0 and is rather different to the upstream version, but the package contains no distro patches. Anyone know why?

So turns out that Ubuntu actually uses xfce4-volumed-pulse, which is forked off from the original, and lives at:

https://launchpad.net/xfce4-volumed-pulse

So, merge request incoming...

Kudos on the fixing Alistair! Lionel, may I please ask you to notify me in a way or another when you modify something in your fork, so that:

- if there was a reason I did it differently, I can let you know about it and we can discuss what approach fits best
- if my code was bad, I can improve it and deliver to the few people out there still stuck on ALSA

Thanks!

I simply used the same code as xfsettingsd… (consistency is good, at least now we know this code is buggy ;-).

Thanks for the patch, I've added it to my todo list (btw, the lp branch is only a mirror). Feel free to include it in the ubuntu package without waiting for a new release, since it seems Ubuntu is the most affected by this bug.

Indeed, xfsettingsd has an identical bug which has been known about for much longer but never explained until now.

If the LP branch is a mirror, where is the upstream?

Hallelujah! Thanks for the workaround Alistair. I was going somewhat crazy, finding that rather randomly, volume keys and notifications and screen brightness notifications would work, sometimes only one would work, and sometimes neither would work. That smells like some kind of a race condition. This is in Xubuntu 14.04 amd64 on a Thinkpad W510 with nvidia binaries.

At first I thought Bug #1254881 was the problem (xfce session starts multiple instances of xfce4-power-manager and xfce4-volumed), since I had multiple instances of both processes. After going through the procedure in that bug description, I got rid of my multiple instances (and my efforts seem to have stuck after logout and/or reboot), but I still had random functionality of volume keys and brightness notifications. Adding --no-daemon to the Exec line in both xfce4-volumed.desktop and xfce4-power-manager.desktop in /etc/xdg/autostart nailed it. Thanks for the tip!

It seems xfsettingsd also suffers from some kind of DBus communication problem (Bug #1239014, xfsettingsd unable to daemonize properly when overlay scrollbars are activated). I notice that if I try logging out immediately after logging in, the system just sits there for about 10 seconds. I've also been noticing weird behaviour of my workspace applet (wrong workspace labels for the first 10 or 20 sec, which then magically correct themselves to the labels set in the settings), which I suspect might also be related to xfsettingsd. Unfortunately, adding --no-daemon to xfsettingsd.desktop in /etc/xdg/autostart doesn't seem to actually launch xfsettingsd with the --no-daemon flag in the session.

Anyways, any news on merging the fix in the branch so these workarounds aren't required? Has it been tested?

Bug #1048805 is also related (xfce4-appfinder launches very slowly).

I very highly doubt that anything being slow has to do with this bug. This one should break things entirely rather than slow them down.

The slowness in that bug may simply be some kind of timeout being hit due to a dbus connection problem. After the timeout, maybe it retries and succeeds, or tries some other method.

I also have an unsubstantiated hunch that Bug #976638 (pkexec does not find any authentication agent) is also affected by this.

The slowness in that bug may simply be some kind of timeout being hit due to a dbus connection problem. After the timeout, maybe it retries and succeeds, or tries some other method.

I also have unsubstantiated hunches that:

Bug #976638 (pkexec does not find any authentication agent)
and
Bug #1193236 (Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-*)

are also affected by this.

It's a usability issue that doesn't limit the functionality of a core package.

On the advice of AlbertoSalvia Novella , I've submitted a new bug report against dbus with links to all the bugs (in my install of Xubuntu 14.04) that I vaguely suspect are related to one another:

Bug #1347272 (DBus communication problems affecting multiple packages)