View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006203||DarkRadiant||General||public||23.12.2022 00:53||04.10.2023 19:10|
|Summary||0006203: Incorrect mouse movement in 3D / 2D views on Plasma Wayland|
|Description||I use Manjaro Linux with KDE / Plasma: Due to numerous bugs I stuck to the X11 session and avoided Wayland, with most finally solved over the past years I decided to try switching to Wayland Plasma session again. TDM seems to be working great, DR starts up well but has a massive issue.|
On Wayland mouse capture and acceleration no longer seem to be working correctly. If I right-click the 3D viewport to go into mouselook or right-click-drag the 2D view, it will go in the direction of the mouse, but greatly accelerate throwing the view to one side immediately. It's as if the greater the cursor is from the center point of the window the faster it will interpret that movement. Currently this makes DR unusable as there's no way I can control and stabilize the view.
|Steps To Reproduce||Use any Linux distribution with KDE then start a Wayland Plasma session, be aware some distros may require installing a custom system package to present the option... I don't see why this shouldn't be reproducible on a virtual machine, so if you're a Windows user or don't want to change your Linux DE trying it in Virtualbox might work (haven't tested). Once that's done just start up DR and use mouselook in 3D view or dragging in the 2D view: You should see the view going all over the place even from small movements.|
|Tags||input, linux, mouse, views, wayland|
|Found a workaround thanks to jonri on the forum: Running DR with "export GDK_BACKEND=x11" will make it use X11 under a Wayland session. This confirms it's definitely a Wayland issue likely in interpreting its input system, Radiant won't have this problem if ran through Xwayland.|
After doing more testing and practically using DR under Wayland, I uncovered more bizarre functionality to this issue. Even when using the parameter GDK_BACKEND=x11 to run Radiant through X11, the same input issue will still occur in some cases.
First of all the model chooser will always have it: If you choose to add a new model or edit the model of a selected entity, right-clicking in the 3D view of the Choose Model window to look at the mesh from different angles causes the mouse to wildly throw the camera around only allowing for small movements.
Then I noticed the 2D view in the main window will sometimes start doing it too, though unlike the model browser it doesn't always have the problem and something triggers it (on X11 backend, full Wayland always does). Finally I was able to see what it is: After pressing X to select the clipper tool and cutting a brush, click-dragging the 2D view always produces the same exaggerated movement. Switching away from he clipper doesn't fix it once the issue has been triggered, right now I need to constantly restart DarkRadiant after using the clipper to cut a brush or I can't control the 2D view any more.
Some good news: I seem to have discovered what's triggering this... not in the code which I'm not familiar with, but in practice which seems obvious now. The bug seems to be caused by the mouse cursor not being locked during movement, the pointer moves together with the camera which doesn't happen under normal circumstances. This surely causes DR to interpret it at the new position each time and accelerate the further you go from the original position of the pointer when the view was first clicked. The exact behaviors (normal and broken) I'm seeing in both the 2D and 3D views as follows:
Normal: Right-clicking causes the mouse cursor to disappear as you move the view around. Once you let go of the mouse button or click it again to disengage, the cursor reappears at the same position on the screen as before you clicked.
Broken: Right-clicking no longer causes the mouse cursor to disappear while the view is controlled (a separate but minor annoyance). As you move the view around, the mouse cursor also moves on the screen instead of being locked.
As I don't know what else to do to help debug this, I went through the process of verifying if the issue can be reproduced in a VM. Took me over an hour due to some problems on my end, in the end I managed to confirm that it can! I've laid out the exact steps needed for anyone (including Windows users) to reproduce this:
1 - Install VirtualBox, get the Manjaro KDE / Plasma iso from https://manjaro.org/download
2 - In VBox create a new VM of Type: Linux, Version: Other Linux (64-bit). Under its Settings - Storage add the iso as optical drive with the option "Live CD/DVD", also add a virtual hard drive to install to.
3 - Booting up the VM should start a live Manjaro session. It will provide a prompt to start the installer; Do so using the default settings, choose any username and password but don't enable automatic login. Restart once it's finished and boot from the virtual drive instead of the iso (F12), the VM should now load into the installation.
4 - The SDDM login manager should present you with the login screen after booting. Before typing your password look in the bottom-left corner: You have options for Plasma X11 and Plasma Wayland, click it and select the later. After changing the session type use the password you chose in the installer and log in.
5 - Open a console (Konsole). Clone DarkRadiant with "git clone https://github.com/codereader/DarkRadiant.git". After that follow the instructions at https://wiki.thedarkmod.com/index.php?title=DarkRadiant_-_Compiling_in_Linux to install Manjaro dependencies with the "pacman" command followed by "cmake .;make --jobs=4;sudo make install". This takes a while so remember to give your VM a few CPU cores then use them in the jobs argument.
6 - Open up the DarkRadiant binary, you should find it in /usr/local/bin. Skip past any questions and warnings regarding the DarkMod data, you don't need TDM for this test, note that may crash it at first. As DR shows up right-click in the 2D or 3D view to take control: You should be seeing my issue as the views go all over the place.
I'm sorry for the messy setup again... can understand if the team doesn't have time to bother with it, but still hope you can find a moment to try it out. The good news is once this setup is in place, you should be able to push changes to the VM and recompile (only part of the code changes) to test the result immediately. I'm happily ready to run any tests myself and confirm any solution found! Let me know if I can help with any more information.
|Is there any difference in behaviour if you disable the "Freelook mode can be toggled" under Preferences/Camera? This turns the right-click toggle into a right-click hold to rotate the camera (similar to the right-click drag used in the ortho views). Although if you see the same problem when right-dragging the ortho views I suspect it won't make any difference.|
|Just tested again and same problem in both cases: The "freelook mode can be toggled" option does make it so you hold the right mouse button to drag, but the issue occurs even then and the camera starts spinning fast.|
|23.12.2022 00:53||MirceaKitsune||New Issue|
|23.12.2022 00:53||MirceaKitsune||Tag Attached: input|
|23.12.2022 00:53||MirceaKitsune||Tag Attached: linux|
|23.12.2022 00:53||MirceaKitsune||Tag Attached: mouse|
|23.12.2022 00:53||MirceaKitsune||Tag Attached: views|
|23.12.2022 00:53||MirceaKitsune||Tag Attached: wayland|
|23.12.2022 01:40||MirceaKitsune||Note Added: 0015609|
|07.01.2023 21:37||MirceaKitsune||Note Added: 0015727|
|20.02.2023 15:21||MirceaKitsune||Note Added: 0015956|
|09.06.2023 19:36||MirceaKitsune||Note Added: 0016015|
|09.06.2023 19:43||MirceaKitsune||Note Edited: 0016015|
|04.10.2023 18:57||orbweaver||Assigned To||=> orbweaver|
|04.10.2023 18:57||orbweaver||Status||new => acknowledged|
|04.10.2023 18:57||orbweaver||Note Added: 0016097|
|04.10.2023 19:10||MirceaKitsune||Note Added: 0016098|