Mouse locking/hiding not working in OpenGL app
NoozAbooz opened this issue · 15 comments
Environment
Windows build number: 10.0.22000.71
Your Distribution version: 20.04
Your WSLg version: 1.0.24
Steps to reproduce
Download and install https://jenkins.thebrokenrail.com/job/minecraft-pi-reborn/job/master/97/artifact/out/minecraft-pi-reborn-client_2.1.6~buster_amd64.deb. For reference, I'm playing Minecraft Pi Edition: Reborn by MCPI Revival.
WSL logs:
- Attach WSLg logs from
/mnt/wslg
You can access the wslg logs using explorer at: \\wsl$\<Distro-Name>\mnt\wslg (e.g.: \\wsl$\Ubuntu-20.04\mnt\wslg)
pulseaudio.log
weston.log
(versions log was empty)
Expected behavior
The mouse should have been hidden, and it should have also locked in place to the center of the window
Actual behavior
The mouse isn't hidden and it also can move freely around when the game is playing without being locked in place. This doesn't happen on normal linux. The mouse moving freely also breaks the player view.
21.07.2021_15.59.26_REC.mp4
I can also confirm this issue with Minecraft Java Edition (issue #374).
Same thing happens for me, but in another app. (issue #170)
I can confirm this happens to me too, in all OpenGL apps that lock the cursor. I use glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_DISABLED); in my application and the mouse does not get locked properly.
I would really love for this to be fixed as I'm trying to develop an OpenGL application and this is preventing me from doing so. I might just temporarily switch back to VcXsrv in the meantime. I switched because I wanted anti-aliasing.
Is there any update to this?
this happen with qemu too.
The only "fix" I have for this issue is to use GWSL, a community app implementing vcxsrv.
I can confirm that mouse hiding and warp in OpenGL is still a problem, even though WSL has gone from pre-release to sharp version. With GWSL, however, it works.
WSL-version: 1.0.0.0
Kernelversion: 5.15.74.2
WSLg-version: 1.0.47
MSRDC-version: 1.2.3575
Direct3D-version: 1.606.4
DXCore-version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows: 10.0.19045.2311I was hoping to use WSL to develop OpenGL programs without having to power up two machines for development (isn't that what everyone wants these days?).
Quick'n'Dirty:
Windows 10 Pro 64-bit, WSL2, Ubuntu 20.04.03 LTS, VSCode 1.75.1
C++, compiled using g++, using GLFW 3.3.8 running an OpenGL 3.3 (Core) context, GLSL 3.30
Alas, when I try to lock the mouse to my program, it seemingly ignores the request.
Adding the below information in the hopes that it helps.
Windows 10 Pro 64-bit (10.0, Build 19045) (19041.vb_release.191206-1406)
AMD Ryzen 7 3700X (8-core)
128GB RAM
WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2486
Linux Win10 5.15.79.1-microsoft-standard-WSL2 #1 SMP Wed Nov 23 01:01:46 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
NAME STATE VERSION
* Ubuntu-20.04 Running 2
Radeon RX 5500 XT
Driver Name: C:\WINDOWS\System32\DriverStore\FileRepository\u0387206.inf_amd64_081d192bd0a4e0cb\B386218\aticfx64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\u0387206.inf_amd64_081d192bd0a4e0cb\B386218\aticfx64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\u0387206.inf_amd64_081d192bd0a4e0cb\B386218\aticfx64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\u0387206.inf_amd64_081d192bd0a4e0cb\B386218\amdxc64.dll
Driver File Version: 31.00.12029.10015 (English)
Driver Version: 31.0.12029.10015
DDI Version: 12
Feature Levels: 12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1
Driver Model: WDDM 2.7
1920 x 1080 (32 bit) (60Hz)
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Microsoft Corporation (0xffffffff)
Device: D3D12 (Radeon RX 5500 XT) (0xffffffff)
Version: 21.0.3
Accelerated: yes
Video memory: 73664MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: Microsoft Corporation
OpenGL renderer string: D3D12 (Radeon RX 5500 XT)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.0.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.1 Mesa 21.0.3
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
This is what I see running the program that I want to behave.
GLFW version: 3.3.8 X11 GLX EGL OSMesa clock_gettime evdev shared
GLFW_CURSOR_DISABLED
Running in CONTEXT VERSION: 3.3 (Core Profile)
OpenGL version: 3.3 (Core Profile) Mesa 21.0.3
GLSL version: 3.30
Vendor: Microsoft Corporation
Renderer: D3D12 (Radeon RX 5500 XT)
After days of trying every way I can think of to make this work, it really seems like there is some sort of disconnect with waylan/weston/x11/opengl/DX/glfw that's causing this to not work specifically for programs running within WSL. And it apparently has been going on for a while.
Onward! To...more investigations.
If you do find a solution, please let me know!
If you go to the issue I mentioned in the GLFW repo, you will see that I have taken a deep dive down into GLFW and spent a while tracing out the exact call tree for setting GLFW_CURSOR_DISABLED. I won't reiterate what I did as it can be read in the other issue.
What I will say though, this issue seems to be coming from WSLg/RDP/Xorg/Wayland/etc. When I compiled my code on Ubuntu 22.04 running on bare metal, it worked as expected.
So, while I won't say definitively that this is a WSLg/etc issue, I'm 99.999% confident it is. Alas, I have neither the time nor the knowledge to fork WSLg and attempt to drill down into it the same way I did with GLFW. My solution is going to be cross-compiling with MinGW and running the code natively on Windows (which was the long term goal anyways). While it would be awesome to not need to cross-compile, it seems to be the state of things.
I'll add this issue to my list of "things to tackle if I have spare time".
If someone else comes across this issue, and has the time to spare, digging into WSLg seems like the best place to start. Good luck!
I'll also add, while I haven't setup and used this myself, the authors of it claim it somehow sets up vcxsrv so that these issues go away. While it appears to make it easier to use X11 apps more easy, I don't think it's doing anything magical that will make this particular bug go away. I use vcxsrv manually, and everything their app does using vcxsrv I do by hand, so I have my doubts.
If you go to the issue I mentioned in the GLFW repo, you will see that I have taken a deep dive down into GLFW and spent a while tracing out the exact call tree for setting GLFW_CURSOR_DISABLED. I won't reiterate what I did as it can be read in the other issue.
What I will say though, this issue seems to be coming from WSLg/RDP/Xorg/Wayland/etc. When I compiled my code on Ubuntu 22.04 running on bare metal, it worked as expected.
So, while I won't say definitively that this is a WSLg/etc issue, I'm 99.999% confident it is. Alas, I have neither the time nor the knowledge to fork WSLg and attempt to drill down into it the same way I did with GLFW. My solution is going to be cross-compiling with MinGW and running the code natively on Windows (which was the long term goal anyways). While it would be awesome to not need to cross-compile, it seems to be the state of things.
I'll add this issue to my list of "things to tackle if I have spare time".
If someone else comes across this issue, and has the time to spare, digging into WSLg seems like the best place to start. Good luck!
I am fairly certain it's WSLg as well, it's kinda disappointing really considering that even stuff like windows management isn't as seamless compared to third party solutions like VcXsrv, Xming, or any of those paid solutions.
Heck, GL support is kinda useless coz I couldn't get stuff like qemu with virgl to work due to lack of dri, waydroid, etc. It's more of a gimmick really rather than something interesting to use.
This is also a problem with SDL2, not just GLFW. I believe it has to do with how the hardware mouse works in WSL, since this also occurs in VirtualBox with the hardware mouse enabled, and is fixed when using the software mouse.
In fact, every functionality that controls the mouse doesn't work with a hardware mouse. You can't set its position via xdotool either.
As per the WSL architecture overview from the readme WSLg uses RDP which has this issue as well. So maybe that is the cause? Is there a way to have it use a different RDP client instead?
The solution is to use GWSL instead of wslg.
- In Windows, create/edit
%HOMEPATH%/.wslconfig, add/setguiApplications=true. - Find the IP of your Windows IP, which can be LAN IPv4, ULA IPv6, or public IPv6.
- In WSL, add
export DISPLAY=WIN_HOST_IP:0to~/.bashrc. ReplaceWIN_HOST_IPwith your Windows IP. Surround IPv6 with[]. - Restart WSL by running
wsl --shutdownin Windows. - Start GWSL
- Launch WSL in Terminal App, start Minecraft.
- In Minecraft, turn off "Raw Input" under "Mouse Settings"
The default-size window gave me around 110 FPS in the game, full-screen and maximized-window gave around 40 FPS. I got a 1080p monitor.