On Wed, 22.06.11 14: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.
I fully agree with Kay here btw.
Input devices should really just be used for input, i.e. interfacing with humans via keyboards, mice, joystick, touchscreens and suchlike. However Jack sensing does not qualify as such. The main reason why input device exist to do jack sensing right now appears to be that there was no other infrastructure readily available for it. But that is a poor excuse, which might be acceptable early in the game where things aren't really clear yet but not for the long run. On top of that there actually always has been a more appropriate place for signalling audio jack sensing events: the alsa control layer. Because that is what Jack sensing ultimately is: audio control. And if you have it in audio control this has many benefits: for example it's in the same namespace as the other audio controls (a very weakly defined namespace, but still the same namespace), so you could by employing some rules match up mute and volume controls with their matching jacks.
On top of that Takashi has patches ready to port HDA over to jack sensing via control devices, and hence I believe this is definitely the way to go.
Jack sensing for video plugs should similarly be handled by the video layer -- and actually is handled like that for VGA hotplug already.
HDMI is a composite technology, but I don't think this should be used as excuse to implement jack sensing via an independent subsystem. If it is composite it should simply use the native sensing interfaces for its technologies, i.e. send plug notifications via both video and audio control, the way they want.
There are a number of other non-input technologies that have been bolted into the input subsystem, but that is really not an excuse to bolt even more into them.
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). All that's changed here is that PulseAudio is trying to use the information that the kernel is exporting.
It's not a new interface, but it will be used for the first time in a big way that will find its way into generic distros. That means it is still time to get this right before this is too late.
You should also not forget that having a fucked up kernel interface usually means a lot of additional work to work around that in userspace: i.e. in PA we need some way to match up input devices with alsa control devices and specific controls. That is messy, requires knowledge and logic that would be much much simpler if we could just access jack sensing via the same interface as the rest of the audio control stuff we do.
- 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.
As mentioned this is not really an excuse as nothing stops you from sending out plug events via both the audio and the video subsystem
- Many jacks include buttons so need an input device anyway which again we want to join up with the other functions.
Well, if you are speaking of headsets here with specific Play and Stop buttons then I believe those actually qualify as proper input keys, and it is the right thing to route them via the input layer. And if we do X and GNOME and Rhythmbox will actually already handle them as they should.
- We still need to handle cases where the jack isn't particularly closely connected to the audio subsystem.
Well, I am tempted to say that this should be handled in kernel. I am not convinced that it is a good idea to expose particularities of the hw design too much in userspace. In fact, I agree with David that the thinkpad laptop driver would best integrate directly with HDA so that in userspace no knowledge about their relation would be necessary.
- 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.
This exists for VGA hotplug at least. I see no reason why this shouldn't be available for HDMI as well.
Lennart