[pulseaudio-discuss] Binding volume changes to hotkeys.

[Lennart Poettering]

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