Wayland Relative Pointer API Progress

[Pekka Paalanen]

On Fri, 17 Apr 2015 13:43:11 +0900
x414e54 <x414e54 at 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 <x414e54 at 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 <jadahl at 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