Wayland Relative Pointer API Progress

[x414e54]

>From the top just, to get our way through this treacle, what a game wants is:

1. Enumerate input devices.
2. Select the HID type each player wants and get a device that
supports that usage.

e.g. Mouse type devices - (could be thumb-stick, pointer stick, mouse,
accelerometer, trackpad or pen as long as it is relative motion across
two axis and has at least two buttons), gamepads, HMDs, 6DOF pointers
etc.

3. For each player assign the input device, either based on one input
per wl_seat or the game assigning the enumerated devices from one
wl_seat.
4. If the device controls the system cursor (wl_pointer) hide, lock,
detach or constrain.
5. Receive raw unaccelerated data from those devices (including mouse wheels).
6. Be able to open the device directly and communicate back to that
same device to provide force feedback and changing LED colors etc. per
player.


If the game wants to use any available trackpad as an absolute pointer
device it should be able to but it should also be able to use it as a
normal mouse input separate of the wl_pointer.


The way todo this seems to be for the compositor and client to
negotiate an event type they both can understand such as
libinput_event or hid events and then a way to request a revokable fd
to the evdev directly so it can control LEDS and force feedback etc.
This allows for applications and compositors to grow separately of the
wayland protocol so it does not need updating every time someone
invents some new mouse device which needs 128bit integers instead of
doubles, has a z axis, thumbstick or tiny projector built in, etc.


This is all completely different from what a GUI input wants todo
which is temporarily receive constant motion from the wl_pointer not
constrained by the window or output size based on dragging some widget
or slider.


Thank you for listening, I hope I have given you a good insight into
the way games work.
But I do not really have any more time to spend on this.