Wayland Relative Pointer API Progress

[x414e54]

Actually sorry I was wrong. UE4 uses HID raw input but there are some
older game engines that used to use directinput.

On Fri, Apr 17, 2015 at 1:43 PM, 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.
>
> 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.