GNOME Bugzilla – Bug 340720
Apply volume on the device the key came from
Last modified: 2011-11-02 20:14:51 UTC
Please describe the problem: I have a Logitech USB headset that appears as a second sound card. As well as appearing as a USB audio device, it also appears as a USB keyboard. When I use the volume up/down buttons on the headset, keyboard events get generated. I can bind these keyboard events to volume up or down in the keybindings control panel, but this ends up altering the volume of the first sound card. Steps to reproduce: 1. Connect a second sound card to the system 2. Open the keybindings control panel 3. try to add a keybinding to control the volume of the second sound card Actual results: There is no entry in the list for volume up/down of second sound card. Expected results: There should be an entry in the list for controlling the volume of the second sound card. Does this happen every time? yes Other information:
Isn't this basically #173035, just more specific for one case?
It's more specific than bug 173035. But right now, we can't do anything about it, as X merges all the keyboard events onto a "core" keyboard. I have the same problem with a USB remote which uses arrows as its main buttons, when I'd want those to be handled as Volume up/down, Rewind, FFwd. We need to have X support from the input hotplug work before we can do anything about this.
*** Bug 581039 has been marked as a duplicate of this bug. ***
Created attachment 200031 [details] [review] First pass at using XI2 keygrabs
Still need to implement the key matching using XI2 events, and actually lookup the output stream that corresponds to the input device, if we can actually do that easily and quickly (could PulseAudio tell us whether it's worth searching for?). Carlos reckons that we need this patch for the grabs to work: http://lists.x.org/archives/xorg-devel/2011-August/024772.html Built into some test packages: http://koji.fedoraproject.org/koji/taskinfo?taskID=3461590
Created attachment 200046 [details] [review] First pass at using XI2 keygrabs
Comment on attachment 200031 [details] [review] First pass at using XI2 keygrabs New patch is against master
Review of attachment 200046 [details] [review]: Two issues with this patch: - the return value of XIGrabKey should be checked, it's the number of modifiers that failed to establish (all the ones that did fail are returned in mods) - a modifier of "0" is still a modifier and must be submitted normally. A num_modifiers of 0 is essentially a noop in the server. Also note that https://bugs.freedesktop.org/show_bug.cgi?id=42298 currently prevents passive key grabs.
A build with the above bug fix: http://koji.fedoraproject.org/koji/taskinfo?taskID=3465679
Created attachment 200121 [details] [review] common: Use XI2 to capture key events
We don't really do error checking in gnome-settings-daemon (apart from the "a key couldn't be captured, meh"). I'll need to rework the current capture code we have to do a single XIGrabKeycode for all the modifier variants, which should make it quicker.
I forgot to mention that the code from the above patch works (at least doesn't regress) with your patch applied.
Created attachment 200208 [details] [review] common: Use XI2 to capture key events
And something that mostly works. There are a couple of FIXMEs for caching (though performance shouldn't be impacted that much), and libcanberra should be forced onto the correct PA sink. The code is also only tested for USB devices. Making Bluetooth devices work would probably need some more work. Peter, any chance to get the X.org patch committed? I really don't want to support 2 codepaths for this feature.
There's a good example of how to do it in the gvc-speaker-test.c in gnome-control-center, but that requires not using ca_gtk_play_for_widget() and following the theme ourselves, only to replicate ca_context_change_device().
Created attachment 200332 [details] [review] common: Use XI2 to capture key events
Created attachment 200347 [details] [review] patch Split up patch, will commit as soon as the X.org patch is committed upstream.
See https://bugs.freedesktop.org/show_bug.cgi?id=42445 about the necessary infrastructure to do that for Bluetooth devices.
Now implemented in master. It will be broken as long as the X.org bug above isn't merged. Feel free to poke your distributions about it.