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