[alsa-devel] Jack event API - decision needed

[David Henningsson]

On 2011-06-21 14:39, Mark Brown wrote:
> On Tue, Jun 21, 2011 at 02:11:15PM +0200, David Henningsson wrote:
>> On 2011-06-21 01:40, Mark Brown wrote:
>
>>> Oh, then in that case we've got another issue in that jacks that happen
>>> not to be associated directly with a sound card for some reason (they're
>>> implemented by the embedded controller and exposed via ACPI for example)
>>> won't be made available to applications.
>
>> Which is not a problem IMO, because in the desktop world this does
>> not happen (or at least I've never seen it), and in the embedded
>> world you have PA running as root anyway.
>
> This seems rather short sighted - the desktop and embedded worlds aren't
> as clearly divided as all that, you've already got things like the
> Genesi systems on the market at the minute running Ubuntu on ARM
> hardware for example and you've also got a bunch of laptop manufacturers
> putting ARM systems in their systems to dual boot into.

If you have a better idea about how to determine if a SW_VIDEOOUT jack 
is actually an audio jack or not, let me know.

>>> OK, well that doesn't seem like an immediately obvious choice.  I can
>>> imagine there might be some concern around keyboards due to passwords
>>> but in general it doesn't seem obvious that the console user shouldn't
>>> be able to read physical input devices on the box (which is the case
>>> we're trying to implement here; we don't need write support).  Do all
>>> classes of input device currently have some root only service to mediate
>>> access to them, and if that is the model we're using perhaps it'd make
>>> sense to have one for this with a dbus interface or whatever that
>>> PulseAudio can talk do rather than to have it talking direct to the
>>> device?
>
>> If I look at what /dev/input devices I have here, that's keyboard,
>> mouse, and ACPI buttons (power, lid close etc). AFAIK, all of those
>> go through the X input layer. Play/pause keys should go through
>> there as well, but are you saying that audio jack events should also
>> go through the X input layer?
>
> I'm asking what the sensible model for handling this stuff is and why we
> need to use a different model for this.  Perhaps this should go through
> the X server, perhaps somewhere else.
>
> It does strike me that the UI may want to be able to join the buttons up
> with the particular jack - for example, if you've got a headset that
> you've got assigned to telephony functions only perhaps the mic short
> button on that headset should only do telephony things.
>
>> If you are, you're welcome to try to fit it in the 248 keycodes that
>> are already occupied, design a new X input extension, or whatever is
>> the right solution for that. I don't know myself.
>
>> If you're not, then that's why this is specific to audio.
>
> It doesn't strike me as an obviously awful solution if that's what we're
> using for things like the ACPI buttons which seem pretty similar - like
> I say one of my questions here is why we need to do something domain
> specific here.  There are certainly a bunch of other switch types in the
> input API which look like the desktop might want to look at them (things
> like SW_DOCK and SW_ROTATE_LOCK for example) so presumably we ought to
> handle them somehow too.
>
> It does sound like we need some input from the udev and more general
> userspace stack people about how this stuff is usually handled.

I was hoping for Lennart or Kay to answer here as they are more "udev 
and general userspace stack people" than I am, but lacking that, I can 
only notice that on my machine, the only processes listening to 
/dev/input files are upowerd (for the lid switch) and Xorg (for 
everything else). [1] Acpid seems to be able to listen to these events 
too, but does not seem to do that on my machine (as determined by "sudo 
fuser -v").

Xorg can only handle keypresses and mouse events, and AFAICT don't care 
about switch events, so, if the way things are usually handled is to add 
another u-audiojack-d just to forward events to pulseaudio, I would 
prefer giving the user access to the relevant input devices directly, 
out of pure simplicity.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[1] On a slightly older machine there is also hald-addon-input, but 
since that's deprecated, let's ignore that for now.