On Sat, 27.06.09 11:52, Colin Guthrie (gmane at colin.guthr.ie) wrote: > 'Twas brillig, and Micha? Sawicz at 27/06/09 10:48 did gyre and gimble: >> Dnia 2009-06-25, czw o godzinie 14:46 -0500, Matthew Ellsworth pisze: >>> Am I just missing some program, or do you have a >>> "superior" way to bind the volume controls to the volume of a >>> particular sink? >> >> The VolumeUp/Down keys should modify volume of current _default_ sink, >> at least in 0.9.15+ and recent gnome-volume-control. >> >> If you're using gnome go to Preferences > Sound and there you can select >> which devices' (you can select multiple) volume will be modified. > > While this is a good work around for now, we really need a way to know > that the event from that "keyboard" is hardcoded to control that "sink". > > While using e.g. my keyboard or laptops's built in vol keys, I expect it > to control the "default" device as per above, but when I press the > buttons on the USB headset, I expect it control just that headset. > > So we need some way to tie this together - although I'm pretty sure that > fix will not be in pulseaudio itself. I've discussed this a bit with Kay a few weeks back. Here's what it's planned to fix this: Only for USB and BT devices matching input and audio devices that belong together matters. To identify which USB audio device belongs to which USB HID device we should have a an udev property "ID_ORIGINATING_DEVICE_COOKIE" which will be set by a simple udev rule to the audio/hid device's usb device sysfs path. That should then be read by PA and set as property on the card/sink obejcts. It should also be read by X11's Xinput framework and set as property on the keyboard device. To identify which BT audio device belongs to which BT input device we should use the same udev property, but set it to the MAC address of the BT device. BT audio devices are not kernel devices, so this matters only for the uinput devices. To allow this properly uinput needs a minor extension so that an abritrary **env can be passed to the kernel when it is allocated which is the handed back to userspace. For the audio device PA's BT module would set the property right-away from the BT MAC adress. With this in place both the XInput and the PA devices should carry the cookie which then can be used by g-v-c to find the right audio device to trigger for a volume/mute event. g-v-c would also need some changes to support Xinput properly. it could then read the cookie property from the device on each keypress and find the right sink for it. Now, all we need is someone to work on all of this. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
