Yes thank you for the comments. I have added a bug/enhancement report related to dealing with this from the evdev fd or libinput side. I do not have a huge amount of time so please feel free to re-word it if you think of a better way.
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 wiimote example was mainly for GUI uses in this case you get an implicit grab serial from the button down ask for the pointer to be frozen/hidden and then receive events though the evdev fd (which may be using the accelerometer). For using a wiimote in a windowed game it is the confinement/warping hint that is the main issue rather than the focus lock. Thank you for the help and good luck with the API! _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
