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

Bug #1314782 reported by Alistair Buxton
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Xfce4 Volumed
Invalid
Undecided
Unassigned
xfce4-volumed (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

On login, multimedia (volume) keys don't work.

If I run kill and re-run "xfce4-volumed" from a terminal, it will not respond to the multimedia keys.

However, if I run "xfce4-volumed --no-daemon &" then it works correctly.

I recently installed xubuntu-desktop^ and ubuntu-sdk on top of my xubuntu install - this might be related.

Update: I now fully understand what is happening.

In a vanilla Xubuntu desktop, gtk_init() will not open a dbus connection.

However, Ubuntu desktop installs various gtk preload libraries such as overlay scrollbars and ubuntu menuproxy (for app menus). These extra plugins open dbus connections. That means that when these plugins are present, calling gtk_init() opens a dbus connection which will become invalid after the fork().

This theory is proven by unsetting UBUNTU_MENUPROXY and then running xfce4-volumed - it will then work correctly.

This is the same thing that caused https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1239014 - except that was caused by the overlay scrollbar plugin rather than the appmenu plugin.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xfce4-volumed 0.2.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-8.28-generic 3.13.2
Uname: Linux 3.13.0-8-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CurrentDesktop: XFCE
Date: Wed Apr 30 20:54:20 2014
InstallationDate: Installed on 2014-02-11 (77 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140210)
SourcePackage: xfce4-volumed
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Alistair Buxton (a-j-buxton) wrote :
description: updated
Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

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?

Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

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

description: updated
Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

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!

Changed in xfce4-volumed (Ubuntu):
status: New → Confirmed
Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

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.

Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

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?

Revision history for this message
Martin Spacek (mspacek) wrote :

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?

Revision history for this message
Martin Spacek (mspacek) wrote :

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

Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

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.

Revision history for this message
Martin Spacek (mspacek) wrote :

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.

Revision history for this message
Martin Spacek (mspacek) wrote :

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.

Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

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

Changed in xfce4-volumed (Ubuntu):
importance: Undecided → Medium
Changed in xfce4-volumed (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Martin Spacek (mspacek) wrote :

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)

Changed in xfce4-volumed:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.