On Wed, Jun 22, 2011 at 15:25, Mark Brown broonie@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