#1990 View/Mouse glitch under Wayland
Symptoms:
When moving the view with the mouse (by right clicking and dragging) horizontally or vertically, the view gets displaced abruptly to the direction you're moving.
Example:
I'm trying to look up, to the ceiling of the aircraft. While I'm moving the camera, the view will accelerate in a fraction of a second and overshoot the place I wanna see.
This happens when trying to look down, up, right or left. As the camera moves in one direction, it gets accelerated towards the end of that side. See the screencast.
Depending on the speed of the movement, it might not reproduce this behavior. I noticed that moving the camera very very slowly or moving in increments (releasing the mouse click and resuming the dragging motion) sometimes avoids the glitch. This cannot be reproduced with the hat switch from the flight stick. It's just the mouse/touchpad, which leads me to believe it has something to do with Wayland or related component (the way the mouse cursor is drawn).
Running Fedora Workstation 26 w/ Wayland (x86_64)
FlightGear 2017.2.1
I can confirm this is still an issue on FG 2018.3.2, and makes it close to unusable with the mouse on Wayland.
Still present on 2020.3.13. (as packaged by Gentoo, amd64, Wayland, AMDGPU, 3440x1440 screen resolution)
I noticed this problem after replacing an Nvidia GTX 970 with an AMD Radeon RX 6700 and switching from an X11 to a Wayland setup. Behavior is essentially as Douglas described it. It seems like there is a rectangular space at the center of the FlightGear window, about half the size of it, where panning with the mouse works. But once you drag outside of it, something goes wrong and the camera angle zips all the way to its limit. This happens in both windowed and full screen mode (i.e. the usable space appears to scale with the window).
Playing around with Debug->Browse Internal Properties, I took a look at "/devices/status/mice/mouse/" and I unraveled a bit more of a clue. Under normal operation, the values seem reasonable. "x" and "y" look correct. "accel-x" and "accel-y" hover around -1 to 1 unless the mouse is moving fairly quick, but still remain (roughly) between -10 and 10. But when (and only when) you're panning (right-click or tab), move the mouse near the edges of the window, you can see the behavior of "accel-x" and "accel-y" change suddenly. In the error condition, they appear to be reporting the distance from the center of the window, rather than some derivative of the distance from the previous mouse location. "accel-x" and "accel-y" report steady values in the several hundreds, and this is clearly not correct.
Update:
In the error condition, the values for "x" and "y" also appear to be incorrect. Running at fullscreen (3440x1440), X and Y seem to settle on values of 1720 and 720 respectively. When the mouse moves, they update to the correct value for what appears to be one frame, then return to these values. So maybe the "accel-x" and "accel-y" values are correct, and are simply a side effect of this error.
Update 2:
So I went digging through the code and I figured out what's going on. When you are panning the view, the mouse enters a "constrained" mode and is supposed to warp back into the center of the window when it crosses within a 25% boundary of the edge. I just tested this personally and this is exactly what happens both on Windows and X11. On Wayland, the mouse does not warp, but FlightGear makes the assumption that it does, and everything goes downhill from there.
The relevant mouse movement logic is defined in src/Input/FGMouseInput.cxx in the methods FGMouseInput::doMouseMotion(...) and FGMouseInputPrivate::constrainMouse(...). FGMouseInputPrivate::constrainMouse(...) makes a call to fgWarpMouse(...) which is implemented in src/Viewer/fg_os_osgviewer.cxx. fgWarpMouse(...) in turn makes a call to warpGUIPointer(...) from src/Viewer/CameraGroup.cxx, which in turn calls osgViewer::GraphicsWindow::requestWarpPointer(...) in OpenSceneGraph.
The function name, as well as the OSG documentation imply this function makes no guarantee of immediate effect or success (there also appears to be no error signal). There appear to be only two implementations of this method: in osgViewer::GraphicsWindowWin32, and osgViewer::GraphicsWindowX11.
The function's implementation seems to be doing some basic X11 stuff to warp the pointer which probably does not function through XWayland.
Well there we have it. As far as solutions in FlightGear go, I'd say the problem is we're assuming requestWarpPointer(...) will do what it says, but this is not true in all situations. This bug could be side-stepped if we found a way to make the mouse code not rely on warping. Alternately, we could see if this behavior could be fixed either in OSG or XWayland.
Last edit: UselessAbstraction 2022-07-10
This is still a big issue and makes simulation UNUSABLE. X11 is dead and about to being dropped by distros and desktop environments. Wayland is the future.
Priority should be set to high, not medium.
Last edit: Anonymous 2024-02-16
Given that the Wayland client interface has no means of setting the mouse position anyways one might just disable constraining the mouse movement altogether by setting the constrained property (from
mice.xml) to false.Yeah that's a good point actually, we could also display a message on startup when we detect the user is on Wayland.
From Erik:
Using getenv("XDG_SESSION_TYPE") should do the trick.
It either returns "x11" or "wayland¨.