'Twas brillig, and Mark Brown at 27/06/11 13:07 did gyre and gimble:
On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:
- We're continuing the path with /dev/input devices
2a) We'll rewrite these devices to be read-only ALSA mixer controls
2b) We'll rewrite these devices to be something within ALSA, but not exactly mixer controls.
For options 2a) and 2b) I guess the existing /dev/input thing should be deprecated and/or removed. So part of decision should maybe be based on information about how widespread the usage of these devices are currently...?
So, this discussion seems to have ground to a halt. Summarising briefly it seems that Lennart and Kay both seem adamant that they don't want a unified jack object visible to userspace, they want to glue the objects together via some implicit means. Lennart mentioned that there is some support for at least some of this functionality in PulseAudio already but didn't provide any details yet - does anyone else know what happens here or have time to go look at the code?
So AFAIK, there is no support in PulseAudio per-se for this.
My understanding is that the component which deals with handling the volume keyboard controls (e.g. gnome-settings-daemon?) is the bit that actually does this glueing....
I believe it works like this:
1. It gets an keyboard event for VOLUME_UP. 2. It checks which device this keypress came from. 3. If it's a generic keyboard or the laptop keyboard, then it likely just picks the "default" sound device. 4. If it's a USB HID that happens to have an "Originating Device" then g-s-d looks through the various PA sinks and see is one of them has the same "Originating Device". If we get a match, then this is the device we'll use. 5. g-s-d issues a volume increment or decrement to PA with the appropriate device.
The above is a very high level, hand wavey description. I don't think PA has (or needs) specific support to tie these things together.
I'm not 100% sure what elements of a sink is used to do this matching but I'd take a wild stab in the dark guess at the "device.bus_path" entry in the proplis which can look something like: device.bus_path = "pci-0000:00:1d.7-usb-0:7.1:1.0"
But I really don't know what the xinput2 or gtk3 side of things looks like for this, so I'm just going on descriptions Lennart has given in the past.
I'm also concerned that an implicit system may be hard to use from userspace, if only in terms of figuring out what the rules are for matching things up.
I doubt this will be much of a problem once a few clean examples are out there. The logic to match things up should be pretty trivial.
Col