Wayland Relative Pointer API Progress

[x414e54]

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.

On Fri, Apr 17, 2015 at 1:48 PM, x414e54 <x414e54 at linux.com> wrote:
> 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.