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 <x414...@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 <x414...@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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
