[alsa-devel] Jack event API - decision needed

[Dmitry Torokhov]

On Thu, Jun 23, 2011 at 01:15:01AM +0100, Mark Brown wrote:
> On Wed, Jun 22, 2011 at 02:41:54PM -0700, Dmitry Torokhov wrote:
> > On Wed, Jun 22, 2011 at 04:11:30PM +0100, Mark Brown wrote:
> 
> > > The idea of reporting presence status for USB ports doesn't seem
> > > obviously bad.
> 
> > And so is reporting whether network cable is plugged in. Does not mean
> > that it should be routed through input though.
> 
> Like I said in the message you're replying to I don't really disagree
> with that.  There's a whole section of the mail (which you quoted but I
> didn't respond to)

That is because I mostly agree with you saying that it should be a
generic API, not alsa or other subsystem-specific solution.

> where I tried to clarify the several issues here.
> Just to reiterate once more it's not the fact that people don't like the
> input API, it's the fact that people are proposing solutions which are
> obviously less functional than what we've got right now.
> 
> > > So if what you want to do is create a new API for this sort of switch
> > > rather than do some audio specific thing like you keep saying I guess we
> > > could merge some version of the switch API that the Android guys wrote
> 
> > I do not think you want to have switch API, it is more a 'connection'
> > API that is needed (i.e. we need a way to report and query whether
> > something is connected to something else or not).
> 
> The reason I called it switch is because that's what both the existing
> Android API and the events within input are called.

And I think we should stop calling them switches, if only to avoid
confusion. Input layer originally had notion of switches representing
physical objects that could be toggled on an off and retain their state
(unlike a button that is expected to auto-release). Later jacks were
added as "switches" (which is something I never liked but end up adding
snice we did not have anything better at the time - still don't).

>  It's also not just
> a case of reporting if things are connected, we need to group these
> things together into bundles and link them to multiple other devices in
> the system.

Hmm, I am not sure I follow. We usually need to calssify and group
devices; there is nothing new here...

> 
> > > If we did one of those two things we would still need to deal with all
> > > the same permission management issues that we've got for input devices
> > > at some point.
> 
> > Hmm, the connection changes should normally be infrequent; maybe
> > delivering them over netlink in the same fashion we deliver uevents
> > woudl make sense. In fact, maybe uevents are all that is needed here.
> 
> uevents are what the Android switch API uses.  I think that would have
> some of the daemon issues that David raised, though?

I'll have to locate original email; I am not subscribed to alsa list.

> 
> > > > case to misuse input. In many modern connector cases the jack senses
> > > > are not even buttons anymore, and they should not become buttons for
> > > > userspace.
> 
> > > I do have some passing familiarity with the physical implementations,
> > > thanks.  Note that the presence detection stuff is all reported as
> > > *switches* rather than buttons.
> 
> > Buttons or switches does not really make much difference. They are not
> > really HID devices (unless there are physical switches that can be
> > toggled by the user while device is still plugged into a socket).
> 
> There are such switches on a vast proportion of jacks out there,
> typically presented physically as a button, so we really do want input
> devices in the mix.  To repeat again I'm not saying that they need to be
> the only way a jack is represented.

And I agree here as well.

Thanks.

-- 
Dmitry