On Wed, Jun 22, 2011 at 04:11:30PM +0100, Mark Brown wrote:
On Wed, Jun 22, 2011 at 03:55:46PM +0200, Kay Sievers wrote:
On Wed, Jun 22, 2011 at 15:25, Mark Brown
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.
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 idea of reporting presence status for USB ports doesn't seem obviously bad.
And so is reporting whether network cable is plugged in. Does not mean that it should be routed through input though.
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.
So if what you want to do is create a new API for this sort of switch rather than do some audio specific thing like you keep saying I guess we could merge some version of the switch API that the Android guys wrote because they didn't notice the existing functionality. Currently it'd need quite a bit of work from what I remember, it's very basic, and there's going to be a transition period where we move all or most of the various existing users of switches out of the input API.
I do not think you want to have switch API, it is more a 'connection' API that is needed (i.e. we need a way to report and query whether something is connected to something else or not).
One can, of course, flip this around and say that what we should really be doing is factoring the event delivery mechanism out of the input layer and into a generic subsystem where it can be reused so we don't have to reinvent the wheel. The transition issues do apply there too but probably less so and it seems like we'd end up with less redundant code.
If we did one of those two things we would still need to deal with all the same permission management issues that we've got for input devices at some point.
Hmm, the connection changes should normally be infrequent; maybe delivering them over netlink in the same fashion we deliver uevents woudl make sense. In fact, maybe uevents are all that is needed here.
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.
There's two orthogonal issues here which you keep confusing.
One is that you keep saying to add a new audio specific API to replace the existing API. This seems like a clear loss to me, we're currently able to represent multi function jacks as a single object to the application layer and we'd loose that ability. That seems like a failure.
The other is that you don't like the fact that the input layer has been used for this stuff. This seems like a more valid point, the main issues are implementation and deployment, but you keep suggesting an audio specific solution.
- 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.
You keep saying subsystem specific here - like I keep on saying I don't think that reflects the reality of the hardware we've got currently.
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.
Well, deciding that we want to ditch the current API doesn't really help people like David who are trying to use the current kernel - userspace has a lot of the information right now, it's just having a hard time figuring out how to talk to itself. That's a third mostly orthogonal problem.
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.
I don't think it makes any sense to push for an audio specific solution.
- 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.
I'm not so sure about that, I believe there's some mechanism for propagating events through HDMI links for things like volume changes which we don't currently support and I'd not be surprised if they didn't look like buttons. Besides if you don't like HDMI as an example there's also four pole analogue jacks that can do video, audio and buttons. I'm mostly just mentioning HDMI because it's a blatantly obvious example seen on PCs.
Besides, userspace needs some way to figure out that the two events are connected and that they're also connected with anything else that appared as part of the same accessory detection.
- 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.
Please read what I wrote, this is for *buttons*. For example, I'm sitting here with a headset that has play/pause, rewind and fast forward buttons on it. Pretty much every headset used with phones has at least one such button.
- 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
So again why the push to come up with an audio specific solution? We can see right now that it's got some issues with current hardware.
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.
I do have some passing familiarity with the physical implementations, thanks. Note that the presence detection stuff is all reported as *switches* rather than buttons.
Buttons or switches does not really make much difference. They are not really HID devices (unless there are physical switches that can be toggled by the user while device is still plugged into a socket).