On Thu, Jun 23, 2011 at 11:49:25AM +0200, Lennart Poettering wrote:
On Thu, 23.06.11 02:10, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
- 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.
No disagreement that being able to expose the audio routing within the devices is needed.
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.
Apparently that's becoming an issue on desktops with nVidia chipsets - there's been a moderate amount of discussion on that recently on the list.
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.
You certainly can't assume that the same device will originate all the functionality on the jack - in embedded systems the way functionality is built up from blocks on the SoC means that the control bus routing is of essentially no use in working out how the system looks to the user.
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.
OK, can you point us to a description of what the actual mechanism is here? This sounds hopeful, though the fact that nobody knows about it isn't inspiring.
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.
I have *repeatedly* talked about the need to hook the button presses up with the rest of the jacks. Including in the mail you're replying to.
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.
On the other hand it also means you now have to work through any number of separate APIs (the jack could acquire other functionality beyond those three) and manually build up a picture of what's there. I like the idea that we can point application developers to a thing rather than them having to infer what's going on from a bunch of separate devices - the fact that nobody else seems to know about the support you mention is one of the potential issues with this.
- 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.
On the other hand if we go for doing something completely new it's going to push back support by I'd guess at least six months. Which doesn't seem great.
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.
I don't really disagree, I'm just saying that we have a broader problem which we should probably look at those too.