Wayland Relative Pointer API Progress

[x414e54]

This is why my original suggestion was for a generic controller
protocol similar to DirectInput or pass libinput events directly
similar to HID RawInput rather than a fd.

Also even if you are passing a fd it does not mean it needs to
re-implement trackpad support, if they driver exports a mouse HID
usage page then you can pass this directly, or you could export a fd
to some abstracted device which transmits relative axis information
(which is what libinput is doing anyway). But my preferred idea would
be better to send HID compatible events with a device id so you can
open the device directly if you need to.

Passing around relative values in a wl_pointer and hoping the
unaccelerated data will fit into a wl_fixed_t or even that the device
supports relative mode, seems very restrictive for games. High dpi
mouse wheels also exist and currently the wl_pointer axis events will
not support this. Also there is no information about the wl_pointer
axes, are they normalised, relative, absolute and/or discrete. Force
feedback/haptic mice (and trackpads) also exist.

The input protocol should be generic allowing the implementation to be
able to grow around it otherwise you are limiting the growth of game
innovation on Linux by whatever a small group of people decide a
"wl_pointer" is.

On Sun, Apr 19, 2015 at 6:55 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 18-04-15 16:03, x414e54 wrote:
>>>
>>> Right.
>>>
>>> This has been discussed before, and as mentioned before I really
>>> believe that we should not define a joystick API at all,
>>> rather we should define an API which will allow an app to:
>>>
>>> 1) List devices which it can get raw access to
>>> 2) Request raw access, if this succeeds the app will be handled
>>> an evdev fd for the device
>>> 3) Notify the app that the compositor is revoking access (e.g.
>>> because the app lost focus), when this happens the compositor
>>> will do a revoke ioctl on the evdev fd rendering it useless
>>> to the app, so the app cannot keep using this (so no security
>>> issue).
>>> 4) Hand a new evdev fd to the app when it regains access.
>>>
>>> This will allow whatever gaming crazy devices pop up to work,
>>> and will allow force feedback to work too.
>>>
>>> I think that trying to define a wayland "controller" protocol for
>>> this is not a good idea, we will just end up wrapping evdev and
>>> adding a whole lot of unnecessary indirection. Currently
>>> games (e.g. libSDL) already are used to opening raw evdev nodes,
>>> by moving the enumeration + actual opening into the compositor
>>> we are fixing the security concerns of the old approach while
>>> keeping all the good bits of it (mainly giving games raw
>>> access to complex input devices), and this also solves the
>>> seat assignment problem neatly.
>>>
>>> Regards,
>>>
>>> Hans
>>
>>
>> Yes I agree this is the best option and it should be used to implement
>> mouse support in games. They get the fd and can get all of the
>> unaccelerated raw relative information they need. There are also other
>> cases like mice which have RGB LEDS and the game will want to change
>> the color of these. This also allows support for multiple pointers in
>> games which do not all drive the system pointer.
>
>
> Erm, I was specifically not talking about mice, I'm not so sure the above
> is a good idea for mice actually, esp. since games which are playable by
> mouse should most likely also be playable by trackpoint / touchpad on
> laptops and we really do not want each game to re-implement touchpad
> support. So no the API which I propose in very rough lines above is out
> of the question for mice (and touchpads and trackpoints).
>
> Regards,
>
> Hans