On Fri, 17 Apr 2015 19:14:30 +0900 x414e54 <x414...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel