Wayland Relative Pointer API Progress

[Pekka Paalanen]

On Fri, 17 Apr 2015 19:14:30 +0900
x414e54 <x414e54 at linux.com> wrote:

> If the compositor can handle this by creating its own evdev device fd
> then having the client use libinput to receive the raw relative mouse
> motion events and dpi information then this seems a very acceptable
> solution. I am not sure though if it would be a good idea to expose
> the original evdev device directly as data might need to be
> transformed or understood by the compositor in the case such as the
> "home" button on a gamepad maybe should act like the super key.

The point of passing the evdev fd to a client is to take the compositor
completely off the input path. For things like game controllers where
you may want high sampling rates of many different sensors, having the
compositor as a relay in between just adds latency and CPU load.

But yes, it indeed does have the downside, that if an input device is
forwarded to a client like that, the compositor can no longer see the
input events. Or maybe it could get a copy of the stream, but that
would a) bring problems with who is handling what event, and b) not
allow all the CPU savings as the compositor would need to check all
events to filter out the Home button events.

I think a solution to this could be splitting a single physical game
controller into multiple evdev devices already in the kernel. I don't
know how you would currently choose to get or not, say, accelerometer
inputs from a PS3 or 4 controller. Putting the Home button alone into a
new evdev device would solve the problem nicely. Does it already work
that way?


Thanks,
pq