wslg
wslg copied to clipboard
Window will not stay on 2nd monitor (need local move support)
Windows build number:
10.0.22621.819
Your Distribution version:
22.04
Your WSL versions:
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.22621.819
Steps to reproduce:
- Open application (application will open on primary monitor)
- Move window from primary monitor to 2nd monitor
- Move cursor to 2nd monitor
- Application window will move back to primary window and become unresponsive. Video attached of issue
https://user-images.githubusercontent.com/26581168/207087434-3eba9c94-4b7a-4d54-9160-cd296e5b114b.mp4
WSL logs:
stderr.log weston.log pulseaudio.log
WSL dumps:
No dumps present.
Expected behavior:
Application windows open and are movable to either monitor. This was the case until recently.
Actual behavior:
Application window opens on primary display. When moved to the 2nd display, the application window will return to the primary display if hovered over by the mouse or keystrokes are made in interaction with the window.
@hideyukn88 thank you for looking into this issue. Please let me know if there is any further information I can provide or debugging steps to take.
@mluckam, thanks for reporting the issue, how do you move the window at step 2 to another monitor? thanks!
I moved the window in the above video to an another monitor using the hotkey WinKey + Left Shift + Right Arrow.
Attempting alternate strategies the window is movable with the following sequence:
- Open window on monitor 1
- Use the minimize/restore button on the window
- Drag the window to monitor 2
- Use the minimize/restore to maximize on monitor 2
This process is tedious when operating with multiple windows and the use of hotkey would be preferable.
@mluckam, thanks for info, this is known issue as the window is moved by Windows (rather than by Linux side), thus Linux application/Window manager has no idea about window has been moved, so, at next update, it's moved back to where Linux side is aware of. For proper window movement, it has to be moved by Linux side window manager (or application) as result of certain input event (such as dragging by mouse), and this is limitation on RDP (remote desktop protocol) WSLg utilize to remote Linux window to Windows's desktop. We have been working to address this issue, thanks!
@mluckam, thanks for info, this is known issue as the window is moved by Windows (rather than by Linux side), thus Linux application/Window manager has no idea about window has been moved, so, at next update, it's moved back to where Linux side is aware of. For proper window movement, it has to be moved by Linux side window manager (or application) as result of certain input event (such as dragging by mouse), and this is limitation on RDP (remote desktop protocol) WSLg utilize to remote Linux window to Windows's desktop. We have been working to address this issue, thanks!
@hideyukn88 is there any progress implementing local move support ?