On Wed, Jul 16, 2008 at 01:50:53PM +0100, Mark Brown wrote: > 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. :/ > Completely my fault, I am verry sorry. > > 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. > It really depends on what you can do with this button. If it is just a simple circuit breaker then it is not really an input device. However is you can remap it for different purposes or map a regular key on a keybaord to perform this function then I will agree with you. For example sleep and power buttons can be anywhere. They can be implemented as ACPI button but there also a bunch of keyboards that have a sleep button on them. Or, like you said, multimedia keys - they not always control hardware directly, often you have an option to remap and re-use them. > 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. Yes, I agree, we would need to transit the existing users to the new scheme. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
