Re: Jack event API - decision needed

Colin Guthrie
2011-06-27T17:01:59Z

'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:
>
>> 1) 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

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]