another input/output question (libinput / pulseaudio / ....)

[Peter Hutterer]

On Tue, Feb 10, 2015 at 02:09:55PM -0500, Matthias Clasen wrote:
> On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote:
> 
> > However, especially for libinput, it gets hazy and also mostly pointless.
> > aside from some special processing required for touchpads and tablets, we
> > don't care much _what_ a device is, we just pass on the events.  If a device
> > has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the
> > compositor/X stack will then handle that however need be. There's no real
> > benefit to us trying to figure out what is a headset and what isn't, we'd
> > still just pass on the keys.
> 
> Fair enough. One thing that is important, though, is to preserve enough
> information about the originating device (and the general device
> topology) that higher levels have a chance to do the right thing (e.g.
> mute the headset and not the speakers, if that is where the mute button
> is).

I _think_ we do that but I'm open to suggestions if we don't do it
sufficiently.
First, all events in libinput are device-based. There are some seat helpers
but all events are still per libinput device, so you definitely know which
device the event is coming from.

Right now, the only real thing to associate with any topology you get from
libinput is the udev_device. What's in the works for 0.11 are device groups
(see http://who-t.blogspot.com.au/2015/02/libinput-device-groups.html) which
give you a bit more of the topology in some special cases, though that
probably won't apply in this particular case.

if there is anything more we should do pls let us know.

Cheers,
   Peter