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
