[PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

[Peter Hutterer]

On Fri, Oct 16, 2015 at 06:58:32PM -0700, Bill Spitzak wrote:
> On Mon, Oct 12, 2015 at 10:01 PM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
> 
> At least based on this example, I think this is fixing the wrong problem.
> > knowing which device sends a key is fairly meaningless unless you have
> > direct access to the devices anyway (which you probably don't, at least not
> > in the default setups).
> 
> 
> Nonsense. A client may very well want to do something different for the X
> key on device 1 than the X key on device 2. It does not need any low-level
> device access to do that, in fact it is not going to send or query anything
> from any device, just receive wayland events.
> 
> This is used to differentiate the tablet pen and eraser and puck and the
> normal mouse. The program does absolutely nothing special, it gets position
> events, but ignores the device, then they all move the cursor and have the
> same effect. But a painting program that figures out which device is the
> eraser will certainly act differently for that one.

what does this example have to do with the original example that you
conveniently dropped?
tablets are different, which is why we have a separate interface for it and
per-device handling. it's not the same as the keyboard.

> > And there are plenty of devices that have
> > meaningless names made from the pid/vid hex codes or even worse - "USB
> > Keyboard".
> >
> 
> Yea that is a problem, but not as big as you think, as long as all clients
> see the same name assignments, and all the devices have a different name.

and the last requirement is not guaranteed. yes, maybe in some ideal setup
you can assume this, but not in the real world where e.g. every gaming mouse
gives you multiple event nodes with the same pid/vid and the same name.
 
> > the source of your problem is IMO that you're treating the remote control
> > like a keyboard when it isn't one. This is what we've been trying to solve
> > with the buttonset interface in libinput (still WIP and needs a wayland
> > protocol extension). Those devices are merely sets of buttons and require
> > their own focus control and behaviour, separate to (and more
> > domain-specific
> > than) keyboards. But it moves the issue into its own separate corner where
> > it can be handled correctly, rather than papering over the issues.
> >
> 
> Buttonset interface is not going to solve anything. What if the user has
> two button devices, both with the same button?

I'm glad that you're convinced the buttonset interface isn't going to solve
anything, clearly without having looked at it or being part of the
design/discussion around it. Otherwise you'd know that unlike the
pointer/keyboard/touch interface it's designed as a per-device interface.

*plonk*

Cheers,
   Peter