On 2011-06-27 13:07, Mark Brown wrote:
On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:
- We're continuing the path with /dev/input devices
2a) We'll rewrite these devices to be read-only ALSA mixer controls
2b) We'll rewrite these devices to be something within ALSA, but not exactly mixer controls.
For options 2a) and 2b) I guess the existing /dev/input thing should be deprecated and/or removed. So part of decision should maybe be based on information about how widespread the usage of these devices are currently...?
So, this discussion seems to have ground to a halt.
Yes, unfortunately, and without a clear consensus. That puts me in a difficult position, because I'm trying to get the job done. And very preferrable, in the next release of Ubuntu (which is to be released on October this year). I've been talking to a few of my colleagues here at Canonical, and here's how we reason currently:
We have the input layer. We also have a set of patches for supporting this in PulseAudio (although currently unmerged and I'm not sure about their current quality/state). We don't have the alternative Alsa Control API discussed in this thread. Without taking a stance of whether that would be a better solution or not, designing it will take some time - somewhat depending on the set of problems we're aiming to solve. Regardless, it will definitely not reach the 3.0 kernel (which is what we will ship in the next release of Ubuntu).
As such, it makes the most sense for me to continue working on the existing input layer API for the time being. If or when a new API is announced and finished, rewriting the pulseaudio patches to target that API will probably make sense. But we're not there today, and the time schedule for getting there is unknown.
If upstream udev/PulseAudio would be willing to merge my (existing and upcoming) patches, I would appreciate that, as I believe that would make both our lives easier. If not, well at least make a note that I /tried/ to do things the right way, and to make everybody happy - which is not always possible.