2015/04/21 5:42 "Bill Spitzak" <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>>: > > 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.