On Thu, 23.06.11 02:10, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Wed, Jun 22, 2011 at 11:01:31PM +0200, Lennart Poettering wrote:
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:
Input devices should really just be used for input, i.e. interfacing with humans via keyboards, mice, joystick, touchscreens and
Once more: there are several mostly orthogonal issues here which are getting conflated a bit. The main ones are:
- We need to represent the fact that multiple subsystems are working with the same jack.
Tbh I am not entirely convinced that this is really such an important thing. We can't even map audio controls to PCM devices which would be vastly more interesting, and we can't even do that.
I can give you a thousand of real-life usecases for wanting to match up PCM devices with controls, but the one for wanting to match up HDMI audio with HDMI video is much weaker, since machines usually have multiple PCM streams, but not multiple HDMI ports.
I am not saying that such a match-up shouldn't be possible, but I'd say it could be relatively easy to implement. One option would be to go by names. i.e. simply say that if an alsa control device is called "HDMI1 Jack Sensing", and an X11 XRANDR port is called "HDMI1", then they should be the same, and apps should comapre the first words of these names, and that both can be traced to the same udev originating device.
In fact, something similar is now already in place for external usb speakers with built-in volume keys to map X11 XInput keypresses up to PA audio devices so that we can map volume keypresses to the appropriate audio device in gnome-settings-daemon (note that the latter is not making use of this yet, as the infrastructure is still very new): for each keypress we can find the originating XInput device, from that we can query the kernel device, which we can then find in sysfs. Similarly we can find the sysfs device from PA and then do a match-up.
So, what I am saying here is that doing this cross-subsystem match-up in other areas is already possible. It's not beautiful, but it works.
If you are thinking about matching up devics across subsystems, you should not limit your focus to jack sensing events only: the above mentioned key-press use is a lot more interesting -- and is solved.
Also, I'd claim that adding an additional subsystem that covers only jack sensing would complicate things even further, since now you have to match up audio, video and input devices with this jack sensing device, instead of just matching them up directly.
- Even if we invent new interfaces for this we really ought to be able to teach userspace about existing kernels.
See, I don't buy this actually. It wouldn't be a regression if we don't support the input device based scheme in PA.
- 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.
That's not my point - I'm talking about things like the docking station or front proximity detection that are clearly not at all related to jacks but are going out via the same interface. If jacks don't currently work in the application layer due to the way input is handled then like I said above it looks like we have a bunch of other issues we also need to cope with.
I think bolting proximity detection and docking station stuff into the input layer is very wrong too. Both deserve probably their own kind of class devices.
Lennart