On Wed, Jul 16, 2008 at 01:02:35PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
Takashi, do you have any comments on these patches?
I have no strong opinion about this. Your implementation looks small enough. But, if Dmitry finds the input layer not suitable for such a purpose, this isn't a good way to go.
Unfortunately Dimitry hasn't been responding to any of the e-mails on this subject since his initial one. :/
I think the question is how general and how extensible these features should be. If it's just a jack reporting, there are bunch of other
To reiterate points I've previously made:
As well as detecting the presence of a connected device typical jack detection implementations also support the implementation of at least one button which would require an input device for at least some jacks even if something else were done. This is consistent with existing usage of the input layer - it's similar to multimedia keys which are normally reported via the input layer. Things like sleep and power buttons are implemented as individual input devices.
We do also already have existing in-kernel users of the input API to report jack status (usually done via GPIOs outside of ALSA). From that point of view this ALSA helper is simply implementing the existing user space interface for reporting jacks. I feel that if we want to do something different we should work out how to transition these existing users to it too. We can always add the existing code while working out what that transition plan might be.
The concern Dmirty raised about requring an ioctl() to get the initial switch state seems to be something that ought to be addressed anyway regardless of what happens here. Similarly, the concerns about the resouce consumption of the input layer seem to be a general issue (and to be honest I'm not convinced that they're a practical problem).
Without the existing users of this interface and the button I'd probably agree with Dmitry but those two factors persuade me otherwise.
possible implementations. Even ALSA control API could provide a similar functionality.
This has most of the concerns that applied to the existing input API :(