Wayland Relative Pointer API Progress

[x414e54]

2015/04/21 5:42 "Bill Spitzak" <spitzak at gmail.com>:
>
> On 04/18/2015 03:20 AM, Hans de Goede wrote:
>
>> 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 makes sense though I can see some problems if you try to run a game
on a remote machine, since there is no fd that will work (unless there is a
network protocol added to communicate all devices, but if that is the case
why not reuse Wayland's protocol?).
>

You could probably use a fd to a socket to the device on the rdp client
instead or have the remote desktop server create evdev devices.

Personally I do prefer using events as it is easy for a client to use it
and also easy for the compositor to re-route or alter some data. But it
makes two way communication more difficult.

However not convinced about the current way of putting actual types for raw
data in the main protocol as it is difficult to change later.

Currently libinput uses doubles normalized to 1000dpi then Wayland uses
fixed_t then SDL uses int32. That is a lot of information loss. My current
mouse is 8200dpi (variable) with a 1000hz polling rate. It seems to make
more sense for the raw data just to be an integer "dots" delta as it is on
other platforms, then the game deals with this via a sensitivity setting.
You could transmit information about a default sensitivity but every game
is unique, that would probably be better via an xdg config file.

Trackpads are different but if used for mouse look they should be able to
be used like a thumbstick where center is home/origin. Rather than pushing
relative movement values. Similar to the Steam controller.

> I don't know what other platforms do, but perhaps it is acceptable if the
number of raw devices can be empty. A client can then either fail
gracefully, or try to do the best it can with the wl_pointer api. Anybody
have any examples, is there rdp access to fancy input devices on Windows?
So when you run your game remotely you are limited to the mouse emulation
no matter how fancy your controller is.
>

I think the assumption would be if you do not get a raw mouse then there
are no devices which can be used in relative mode and you should not try.

If you get no raw devices at all then you should either quit or pop up a
message telling the user to connect a device or the compositor would do
this. Raw devices could also include keyboards as there are plenty these
days which have fullcolor LEDS.

In windows or mac without raw/hid input device you would warp the cursor to
center after every move event and just hope it was a mouse. It seems much
better to just fail gracefully than resport to hacks when a user may only
have a gamepad plugged in.

As for RDP I think it supports (same as VMs) USB redirection. So the device
just shows up as a normal USB device to the remote windows server.

> It is likely that the method used to transform a device into wl_pointer
positions is controlled by user preferences, so there will need to be a
design such that the client can see these user preferences and replicate
them when using the raw device.
>

Yes I would definately like this, but it could be an xdg game config file
rather than by the Wayland protocol. Because with raw events you may still
want to use it for something different. Wayland just needs to provide a way
to get the raw evdev data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150421/ac487b46/attachment-0001.html>