[alsa-devel] Jack event API - decision needed

[Kay Sievers]

On Wed, Jun 22, 2011 at 15:25, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Wed, Jun 22, 2011 at 02:50:59PM +0200, Kay Sievers wrote:
>
>> I'm still pretty sure that there should be no fake input devices
>> involved for any jack related things. Especially not in the simple and
>> common desktop case, where the input devices are created by, and
>> direct child devices of the ALSA card device (like Intel HDA). I'm
>> sure, such things just belong to the ALSA control device directly.
>
> It would really helpful if you could engage with some of the discussion
> about this...  Apart from anything else "fake" seems a bit misleading,
> a jack is a physical thing which really exists and which I can point to
> on the system and in may cases has buttons on it.

Physical does not imply button, and even then, button does not imply
input. It's really a domain of the individual subsystem it is
associated with. Cdrom media eject buttons are no input devices, the
events come out of SCSI.

We should stop misusing input for anything that isn't user a real
input device like a keyboard button, mouse, joystick, screen, tablet
like interface. Otherwise, I fear, with that logic anything with a
physical state change could become an input device. USB would then
make a good case too, to have all ports as individual input devices,
telling us if anything is plugged in or out, and so on ...

The kernel's input just has some sensible event relay interface, that
should not be the reason to put everything that has a state and can
change its state as an input device. People should come up with their
own event channel instead of just lazily misuse input for unrelated
things.

>> There might be odd use cases or use cases where multiple device
>> classes are involved for the same type of jacks, which can probably
>> not be covered by the ALSA-only control device, and where some
>
> Like I said in reply to your earlier mail on this subject that's not a
> terribly unusual case for PC class hardware, HDMI is very widely
> deployed and obviously carries both audio and video over a single
> physical connector.

HDMI has no buttons, no virtual ones no physical ones. :)

HDMI exposes an ALSA interface if audio is involved, and that ALSA can
send events, just as the associated video interface can send video
related events. That there is a single connector does again not make a
case to use input for it, it's an hot-pluggable audio/video
connection, not an input device.

>> To me the ALSA control device events for audio-related jack events
>> seems like the natural interface and the best option currently. Unless
>> there are good technical reasons not to do that, I like to see them
>> made working, instead of adding support for input devices, or wait for
>> some (magic) meta multimedia device to be defined, or an additional
>> userspace event daemon requirement.
>
> To summarise some of the issues from the rest of the thread:
>
>  - This isn't a new interface at all, it's been implemented in the
>   kernel for quite some time now (the first switch was added in
>   2.6.18).

Which does not make it correct, or any more tasteful. It's just wrong
to misuse input for subsystem specific plugging events not related to
input.

If these devices should be removed ever, or at what time if so, is
nothing we need to discuss now. But we should not start using them in
_new_ stuff. They are just wrong from the beginning.

>   All that's changed here is that PulseAudio is trying to
>   use the information that the kernel is exporting.

Right, And we don't want to use mis-designed interfaces if we don't
need to. And as we are not in a hurry and have the option of a native
ALSA control interface, we should focus on that.

>  - Mixed function jacks aren't that unusual; if anything they're more
>   common on PCs than anything else.  HDMI is the obvious one for PC
>   class hardware and where these things happen we do need to be able to
>   join the audio and the video up with each other.

Sure. But again, HDMI has in no way any button or input. This is about
hot-plugging of audio/video devices. Just let ALSA _and_ the video
device send the event.

>  - Many jacks include buttons so need an input device anyway which again
>   we want to join up with the other functions.

I disagree. They are states for the associated class of devices, they
are not sensible input devices today and probably will never really be
such.

>  - We still need to handle cases where the jack isn't particularly
>   closely connected to the audio subsystem.

Sure, that might need to be solved by some mapping, still makes no
case to misuse input. In many modern connector cases the jack senses
are not even buttons anymore, and they should not become buttons for
userspace.

>  - There are other non-audio non-jack things being exposed via the same
>   interface which we need to have some method for handling even if we
>   end up doing something audio specific for some subset of jacks.
>
> and probably some others I forget.

Sure, they all might need to rethink their use of input, and ideally
stop doing that. I expect most of them are not right doing what they
do.

Thanks,
Kay