Wayland Relative Pointer API Progress

[x414e54]

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.

I think this is perfectly fine to how it would work in practice
because when you button down on a GUI widget and ask for a "relative"
pointer the compositor just hides the pointer switches to the wii mote
accelerometer and transforms the motion into a 2d projection. If it
does not have an accelerometer then the relative motion finishes at
the edge of the input area.

> Sliders etc will be possible with the pointer lock and relative pointer
> protocols. Confinement has other use cases.

Yes but this protocol should be revised to take an implicit grab
serial and freeze the pointer and be separate to the
explicit/long-term grab required for the game api.

It needs to be separate to prevent GUI applications receiving a
generic explicit grab on the pointer when they do not need it.

> Well, they do. Sure, consoles don't tend to use a mouse for input, but
> on PC, a very large amount of games do. And a large amount of those tend
> to use it in "relative mode" i.e. not to show a cursor (Quake,
> Neverball, ...).

I am not sure if you have made a game but I have shipped a few and I
am currently sitting in front of the source for a major game engine
and the "relative pointer" is really just a 2 axis joystick delta. It
is labeled separately from the gamepad thumb axis but it still reaches
exactly the same api call at the end which is then using the 2 axis
deltas to rotate or transform a 3d view. Even with absolute mouse
positions it is still transformed into an axis delta.

People seem to think because mouse input is superior look aim in FPS
to a thumb-stick or because one is mapped to a ursor that they are
somehow completely different programatically... they are not.

>
> 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.

On windows you would use direct input to open the mouse for "relative"
motion events, this is exactly the same API as used for joysticks. In
direct input a "mouse" is just a 2 axis direct input device with the
mouse label.
>From the point of games they really are not orthogonal. UE4 on window
uses direct input (joystick api) for it's "high resolution" mouse
mode.

There are various reasons why you should also need to abstract the
joystick API and that could be multiple games running at the same time
trying to access the joystick. You need to give the focus window
access for example. Also in 3D a VR compositor you would need to
translate plenty of matrices from the HMD tracking and the 6DOF input
devices to get the correct view of a 3D window. It would not be
reasonable to allow an application to access these devices directly.

> It doesn't make any sense to compositor driven hot-swap what input device
> type a game should use. Many games probably wouldn't even support
> changing from a mouse+keyboard to a gamepad simply because the gameplay
> would be different. A game needs to decide itself what input device type
i> t should use.

As above it games just check the axis label against a list of mappings
to work out if it is a rotate or translate, etc. You could perfectly
have a gamepad thumb-stick as movement and a mouse as look and have
the compositor swap the two inputs without the game caring. Internally
the game would still think "this is the mouse axis" it is irrelevant
if it is coming from a different device than the wl_pointer, it just
needs to be from the same wl_seat.

> Emulating pointer devices from controller input I think is completely
> out of scope for any protocol. It can be done by something server side
> if needed.

This is exactly what the compositor is currently doing with mouse input.