Jump to content
The Dark Mod Forums

Incorrect mouse movement in 3D / 2D views on Plasma Wayland


Recommended Posts

Wanted to ask here before reporting on the bug tracker. 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 one 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 (or reverse) but greatly accelerated throwing the view to one side immediately. Currently this makes DR unusable as there's no way I can control the view.

Looks like a hopefully minor thing to solve, but I'm curious if anyone else can reproduce it. If not what else do you suggest I look at? I tried toggling Discrete Movement in Settings - Camera but it seems to have no effect on the problem.

Edited by MirceaKitsune
Link to comment
Share on other sites

https://bugs.thedarkmod.com/view.php?id=6203

Been a few days and I can't find a solution so I went ahead and reported. Let me know if a suggestions come to mind.

If you're on Windows I imagine this should be possible to reproduce in a virtual machine: Download Manjaro KDE, install the plasma-wayland-session package (I don't think they defaulted it yet), build DR from Git on the setup then run it and use any of the views.

Link to comment
Share on other sites

13 minutes ago, jonri said:

Can you convince it to run under xwayland?  A proper fix is preferred, of course, but this might make it usable in the meantime.

Good thinking. Unfortunately I can't find a way to force an application compiled with Wayland support to launch under Xwayland, just looked and only found one suggestion that didn't work. Does DR have a runtime flag you can launch it with to force this, similar to how Firefox did to enable WL support optionally at first?

Link to comment
Share on other sites

4 minutes ago, jonri said:

DR uses wxGTK on Linux, so I'd expect anything that works for other GTK applications would do the trick.  I'm not set up to try it myself, but it looks like you might try setting the GDK_BACKEND=x11 environment variable.

Wonderful, thank you for that! Indeed that works, and running it this way resolves the problem with mouse movement. So at least there's a workaround until this can be solved.

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

  • 2 weeks later...

I'm actually having similar issues in Windows.  My mouse works fine, except in the DR camera view.

If you rotate the mouse, the view gets thrown around all over the place, or keeps jerking to the right.  This has happened before briefly, but a restart fixed it (I think  - it was quite awhile ago).  Now it's happening all the time, making DR unusable.

I just tried tweaking the camera movement settings, and now it's even worse.

Anyone know of any external things that may affect this?  Like mouse or Windows settings, etc?  

Link to comment
Share on other sites

5 minutes ago, datiswous said:

Have you tried removing your config file?

In my case I believe I tried a fresh config and same thing. It's interesting that on Linux it seems to be strictly an X11 vs Wayland issue, whereas on Windows the exact same thing happens at random: Likely means there's a bug somewhere in mouse input handling that's only reached in a few rare circumstances triggered in different ways by the OS.

Link to comment
Share on other sites

36 minutes ago, datiswous said:

Have you tried removing your config file?

yes - I blew away the entire DarkRadiant config directory and started from scratch.  That seemed to fix it.  If it happens again I'll try to be a bit more surgical about it.  

  • Like 1
Link to comment
Share on other sites

2 hours ago, Frost_Salamander said:

yes - I blew away the entire DarkRadiant config directory and started from scratch.  That seemed to fix it.  If it happens again I'll try to be a bit more surgical about it.  

Interesting. I tried again to be sure: In my case on Wayland even with a fresh config directory DR will always have the issue on Wayland (or X11 under Wayland in the cases I described).

Link to comment
Share on other sites

So it happened again.  I normally have the camera in its own window (undocked). If I dock it and then undock it again, the problem goes away.  🤷‍♂️

Link to comment
Share on other sites

  • 3 weeks later...

Is there any news on this please? @greebo what do you think it might be? I wouldn't poke too much about an issue, but since I switched to Wayland I'm struggling to run DarkRadiant properly due to this one problem even with the X11 mode override to mitigate it: As Frost Salamander confirmed the exact same behavior also happens on Windows, albeit more rarely and triggered by different circumstances... something must be breaking DR's interpretation of mouse input in a special circumstance.

Link to comment
Share on other sites

No, I don't have any idea what the cause could be. Even if I had time to work on DR right now, I wouldn't be able to work on this particular problem, since I don't have a matching native Manjaro installation around.

Link to comment
Share on other sites

As a workaround, does changing the setting "Freelook mode can be toggled" make any difference to the behaviour? This disables the right-click toggle mode and requires you to hold and drag with the mouse to rotate the view.

Link to comment
Share on other sites

6 hours ago, OrbWeaver said:

As a workaround, does changing the setting "Freelook mode can be toggled" make any difference to the behaviour? This disables the right-click toggle mode and requires you to hold and drag with the mouse to rotate the view.

No, that setting makes no difference: Same behavior both when running DarkRadiant in Wayland mode (always), or when running it in X11 mode on Wayland session (starts after using the clipper tool).

The good news is 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.

Link to comment
Share on other sites

I don't generally use Wayland myself due to the numerous applications which have problems with it, but I tried logging into my Ubuntu GNOME desktop using the Wayland session and I do not see any problems with the view rotation or mouse capturing in DR. Which unfortunately means this will probably only be solved if a developer with a system similar to yours is able to investigate it.

Link to comment
Share on other sites

1 hour ago, OrbWeaver said:

I don't generally use Wayland myself due to the numerous applications which have problems with it, but I tried logging into my Ubuntu GNOME desktop using the Wayland session and I do not see any problems with the view rotation or mouse capturing in DR. Which unfortunately means this will probably only be solved if a developer with a system similar to yours is able to investigate it.

Weird. Thanks for confirming that though, one useful piece of information. So it might only be doing it on KDE / Plasma in this case. I wonder if it would be reproducible on a virtual machine, normally it should only drivers and high level stuff differ... if yes it would be possible for someone to test on VirtualBox, would require setting a VM up but not changing the actual OS.

Does anything come to mind in terms of things I can try myself? I always compile DR from Git: If a specific line of code comes to mind feel free to suggest a change and I could recompile and test with it.

Link to comment
Share on other sites

On 2/22/2023 at 10:40 PM, MirceaKitsune said:

Does anything come to mind in terms of things I can try myself? I always compile DR from Git: If a specific line of code comes to mind feel free to suggest a change and I could recompile and test with it.

The relevant code is in CamWnd.cpp (starting with the CamWnd::startCapture method) which makes use of a class called FreezePointer which can be found in the wxutil library. It's not possible to be any more specific than that because I have no idea what would be causing the problem.

Presumably it's either (1) a logic error in our code which is being exposed by Wayland handling mouse events in a subtly different way, or (2) a fundamental incompatibility between wxWidgets, GTK and Wayland over which we have no control.

Link to comment
Share on other sites

If it's a WxWidgets / GTK issue yeah, it would need to be reported with them. I might look at that code and in case I understand it enough make a few changes to test and recompile. At worst maybe there's a specific trigger we can work around without issue.

Link to comment
Share on other sites

  • 2 months later...

I tried playing with the obvious things there but nothing seems to work; Adding a "return" at the beginning of those functions can stop the camera from moving at all but that's about it... when the view is engaged the pointer always moves in the background, capturing and holding it in place is what's universally failing. If this is in any way relevant, the pointerMode variable always has a value of 15 both in X11 (working) and Wayland (when the issue occurs).

A reminder: When using "GDK_BACKEND=x11" the 2D view at least works well initially but experiences the same issue after selecting the clipper tool (X key by default). Can anyone think of anything only the clipper is doing to the XY window that could be used as a lead to understand what's happening?

Link to comment
Share on other sites

  • 2 weeks later...

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.

Edited by MirceaKitsune
Link to comment
Share on other sites

  • 2 months later...

I came across this bug report on wxwidgets: https://github.com/wxWidgets/wxWidgets/issues/23778

The short of it is that GTK decided not to support mouse pointer warping on wayland.  There may be some sort of workarounds by making direct wayland calls, but I'm not sure yet if that's something we could even do from our layer, or if it would have to happen within wxwidgets.

  • Thanks 1
Link to comment
Share on other sites

9 hours ago, jonri said:

I came across this bug report on wxwidgets: https://github.com/wxWidgets/wxWidgets/issues/23778

The short of it is that GTK decided not to support mouse pointer warping on wayland.  There may be some sort of workarounds by making direct wayland calls, but I'm not sure yet if that's something we could even do from our layer, or if it would have to happen within wxwidgets.

Thanks: Really sounds like that bug must be the case and what I'm experiencing. Question is if we can use any workarounds on DR's end, which like you said is itself very questionable.

I think there would be one way actually: What if DR didn't require cursor wrapping at all? Just translate mouse movement as it happens and don't care where the mouse pointer is located! If the flag is available snap the pointer to the center of the windows / screen for sanity's sake, but if not let it go everywhere without translating the view based on it. At worst this could be done by comparing the mouse movement only between every two frames / ticks, instead of caring about the pointer's start position and expecting it to be in the center?

Edited by MirceaKitsune
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...