[alsa-devel] [0/2] Jack reporting

[Dmitry Torokhov]

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