On Fri, 17 Apr 2015 13:43:11 +0900 x414e54 <x414...@linux.com> wrote:
> Thank you for the comments. > I do have a few counterpoints but I will leave after that. > > > > > Not sure an IR/laser/wii mote pointer should even be considered a > > "relative" pointer since they operate in absolute coordinates. Given > > this, there is no "set position" hint to consider. Transmitting > > acceleramoter data via a "relative pointer" doesn't sound reasonable. > > > > I think this is the issue right here. Pointers are not relative, mice > are not pointers. What definition of a "pointer" are you using? The definition Wayland uses for a wl_pointer is a device that: - requires a cursor image on screen to be usable - the physical input is relative, not absolute This definition is inspired by mice, and mice have been called pointer devices, so we picked the well-known name "pointer" for mice-like devices. Specifically, a pointer is *not* a device where you directly point a location on screen, like a touchscreen for example. For touchscreens, there is a separate protocol wl_touch. For drawing tablets, there will be yet another procotol. Joysticks or gamepads fit into none of the above. For the rest of the conversation, you should probably look up the long gamepad protocol discussions from the wayland-devel mailing list archives. A fundamental difference between a wiimote and a pointer, as far as I understand, is that wiimote might be off-screen while a pointer never can. You also would not unfocus a wiimote from an app window just because it went off-screen or off-window, right? Button events should still be delivered to the app? A Pointer will unfocus, because without grabs, the focus is expected to shift to whatever is under the pointer. On Fri, 17 Apr 2015 14:21:58 +0900 x414e54 <x414...@linux.com> wrote: > If you add in something like get a wl_input from a wl_seat which can > be used as a generic interface to access the libinput directly in a > safe way but still controlled the compositor if the window loses focus > or there needs to be some translation done. This would be much more > generic than my wl_jostick or wl_6dof proposal. That is quite much what Jason meant by: On Fri, 17 Apr 2015 11:30:16 +0800 Jonas Ådahl <jad...@gmail.com> wrote: > Joysticks, gamepads, 6DOF are orthagonal to pointer locking and relative > pointers. Currently games usually rely on opening the evdev device > themself, and so far it doesn't seem reasonable to abstract such devices > in the compositor. What may make more sense is to rely on the compositor > to handle focus, passing fds around, continuing to make the client > responsible for translating input events to character movements or > whatever. Passing around and revoking fds is how a raw generic interface to access an input device would be implemented. It would be up to the client to then use any appropriate code to handle the readily-opened evdev kernel device. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel