search

microsoft / wslg

Enabling the Windows Subsystem for Linux to include support for Wayland and X server related scenarios
MIT License
10.22k stars 305 forks source link

WSL2 X11 output corruption #1150

Open deviantbit opened 11 months ago

deviantbit commented 11 months ago

Windows Version

Version 10.0.22631 Build 22631

WSL Version

2.0.9.0

Are you using WSL 1 or WSL 2?

Kernel Version

5.15.133.1-1

Distro Version

Ubuntu-22.04

Other Software

Any and all applications that use xlib or X Windows.

Repro Steps

Launch an xeyes, or emacs.

Expected Behavior

image

Actual Behavior

image

Diagnostic Logs

Nothing in logs to report.

github-actions[bot] commented 11 months ago

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

deviantbit commented 11 months ago

I have tried multiple versions of NVIDIA drivers. Doesn't appear to be a driver issue. Appears to be and issue with the internal X window server.

etxaleku commented 11 months ago

I'm experiencing the same issue. After a lot of reading I'm thinking that it may be because I'm running on a Surface Pro 7 with a 2560x1440 resolution display. Found some postings talking about HiDPI displays having issues with FreeRDP, an internal WSLg component.

$ wsl.exe --version WSL version: 2.0.9.0 Kernel version: 5.15.133.1-1 WSLg version: 1.0.59 MSRDC version: 1.2.4677 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.22621.2715

Specifically I'm (also) trying to get emacs working using the following:

$ git clone --single-branch --branch emacs-29 git://git.sv.gnu.org/emacs.git $ sudo apt install build-essential libgtk-3-dev libgnutls28-dev libtiff5-dev libgif-dev libjpeg-dev libpng-dev libxpm-dev libncurses-dev texinfo autoconf libgccjit-11-dev libsqlite3-dev xml2 libattr1-dev libacl1-dev libxml2-dev $ cd emacs $ ./autogen.sh $ ./configure --with-pgtk $ make -j4 $ sudo make install

$ emacs --version GNU Emacs 29.1.90 Development version 687c416ce9bf on emacs-29 branch; build date 2023-11-27.

All Windows 11 updates have been applied with particular attention to drivers and firmware.

gnome-tweaks and other linux gui apps all seem to have the same behavior.

deviantbit commented 11 months ago

I plugged in a 1080p monitor. It had the same issue.

etxaleku commented 11 months ago

I also noticed that whenever I try to run any GUI apps like emacs for example, my %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder is filling up with hundreds of 4MB files...

trace-files

deviantbit commented 11 months ago

This is rasterization problem.

image

etxaleku commented 11 months ago

I got mine completely working! It's rock solid and I couldn't be happier... well, I guess I could win the Lotto but... :)

So I tried a ton of stuff but the one that got everything working was upgrading my video driver. So throughout Microsoft's WSL/WSLg web pages they do mention that it's very important for WSLg/Wayland to work that you update your video driver to the latest from the manufacturer. But then both Microsoft (laptop vendor) and Intel (driver vendor) warn that if you update from Intel (the driver vendor) then you risk losing any special customizations/configurations that the OEM vendor (Microsoft in this case) may have made and worst case you could even lose your video entirely (the warnings look a bit ominous). They both recommend going to the laptop vendor site and upgrading from there as the safe path - so that's what I had (previously) done. But in the case of the Surface Pro Microsoft does offer a single package that upgrades all the Surface drivers and firmware and puts everything back to "out of box" so I applied that (early on) but no joy. So armed with that as a "backup" I went ahead, held my breath, and upgraded from the Intel (driver vendor) site at www.intel.com/content/www/us/en/support/intel-driver-support-assistant.html being careful to select the right video hardware and "generation", etc. The vendor driver update went smoothly (I may have passed out holding my breath once or twice during the process, it took a while) but then after a reboot I brought up emacs and it seems rock solid. No video weirdness whatsoever, new frames are fine, splitting windows is flawless, everything is exactly as I've known emacs to be for, well, a long time. Even web browsing works (I'd never even tried that before)!

And no more trace files have shown up in my %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder.

Also, all other WSL GUI apps (gnome-tweaks, octave, gnuplot, etc) are also all working smoothly now. Octave and gnuplot integrate and work from emacs smoothly.

I cannot say enough great things about WSL/WSLg - it's the environment I've always wished for and maybe a bit more!

Thanks to everyone that worked on and supports WSL/WSLg!

deviantbit commented 11 months ago

Something else resolved it. I'm not on a laptop, and using the latest drivers. I went back several generation of drivers and it still had the problem. So you did something else.

ksylvan commented 11 months ago

I'm on a desktop, with an external display, seeing the same thing.

image

I have an NVIDIA GeoForce RTX-4090 and the latest drivers.

etxaleku commented 11 months ago

Hmm, I see what you mean. Are you also seeing those trace files piling up in your %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder?

For me, I really feel like the driver update made the difference. But there’s a lot of components involved here so I can imagine that every situation has its own nuances. I kept pretty careful notes and I went back and reviewed my command history, and I couldn’t find anything else that looked like it really had any hope. I installed libgccjit-11-dev if that makes a difference.

ksylvan commented 11 months ago

Hmm, I see what you mean. Are you also seeing those trace files piling up in your %AppData%\Local\Temp\DiagOutputDir\RdClientAutoTrace folder?

Yes @etxaleku

keesj commented 11 months ago

I have had similar issues (on and off) for .. about the last 2 or 3 weeks. E.g. I started seeing the issue on a Friday morning(I guess after a windows update) and was having different problems but the issue disappeared .. possibly after restarting wsl. Due to other issues over the last week (can only run WSL as administrator I install a pre-release (version 2.0.11) see https://github.com/microsoft/WSL/releases and I think the problems started to appear again.

image

I have an Intel IRISxe graphics card, dell laptop and dell usb-c docking startion/multiple displays.

Update: I upgrade the 2.0.12.0 and the issue remains present form me (my intel driver is from 11/07/2023)

image

ksylvan commented 11 months ago

I've restarted WSL (and even shutdown and restart the desktop) and can reproduce this every time, so it's a genuine WSLG bug as far as I can see.

etxaleku commented 11 months ago

I had a bit of a regression - so my Surface Pro 7 with WSL2 initially experienced the video "fuzzing" problem and I struggled with it for a while but eventually upgraded my Intel Iris Plus driver from the intel web site and all my issues stopped. No more video "fuzz" ever, all Linux graphical apps run smoothly (gnome-tweaks, etc) and no more trace files piling up in that RdClientAutoTrace folder. Well... that is until I did some desktop screen sharing and tried to show them how it was all working... something about the desktop screen sharing caused the issue to come back - emacs and all Linux GUI apps all "fuzzed out" 100% of the time and the RdClientAutoTrace folder starting filling up with the 4MB trace files again... situation continued until I rebooted (getting out of the screen sharing session made no difference) and after the reboot everything is back to rock solid working order... no more fuzz or trace files...

So it look like I have a great working environment, but I can't ever do any screen sharing and expect it to work. :(

And probably once I do any screen sharing then I'll need to reboot to get things working again.

Oh well, it could be worse, as others have mentioned (where they don't have a "fix").

Just thought I'd document the screen sharing aspect as that might shed some insight to a WSLg developer trying to work on this issue.

keesj commented 11 months ago

In my case I do not think it matters if I use an external display or not. I can boot and reproduce the issue with my laptop "standalone"

mahi1980 commented 11 months ago

I have the same issues. Updating GPU drivers didn't work (AMD Radeon Pro WX 2100, Driver 31.0.21018.6011 (2023/08/24)). RdClientAutoTrace is being filled as well, but file size is much larger than 4MB.

Stanzilla commented 11 months ago

I have the same issue, also latest driver from today (nvidia)

lucvdv-aleacsys commented 11 months ago

Same issue here, latest Dell-provided Nvidia drivers on a Dell laptop. I only found out about WSLg this morning after the problem occurred. I don't use GUI apps that much and thought I was still using VCXSrv, which always did the job fine. Turns out it was silently changed into using WSLg. No wonder uninstalling (and reinstalling) VCXSrv didn't help :)

thanat0s commented 11 months ago

I have the same issue on NVIDIA 546.29 latest WHQL driver on a triple monitor desktop setup.

EDIT: problem seems solved using this : #1130

bryghtlabs-richard commented 11 months ago

Dell laptop with Dell Nvidia drivers, first boot of wsl2, same issue. Looks like a mismatch in stride or pixel format. Thanat0s' linked solution apt update, apt upgrade, wsl --shutdown fixed it for me.

brianherold commented 11 months ago

Thanat0s' linked solution fixed it for me as well. I'm running a Dell laptop with Dell Nvidia drivers. The issue popped up for me sometime last week after a few months of stable use.

deviantbit commented 11 months ago

That didn't resolve it for me. Maybe there is an update being pushed down stream that hasn't arrived.

lucvdv-aleacsys commented 10 months ago

I hadn't tried any GUI apps since my previous comment (2 weeks ago), so I don't know exactly when it got fixed, but the problem no longer occurs here either (see comments by brianherold and thanat0s). I remember doing an 'apt update && apt upgrade' last wednesday, so that must have fixed it.

deviantbit commented 10 months ago

This has been resolved for me now.

av-2024 commented 10 months ago

This should be reopened. It might be resolved for @deviantbit, but the same issue exists for a lot of other people. For me, it happens after my system has been on for a while. Rebooting temporarily fixes it, but it always happens again after some time.

deviantbit commented 10 months ago

Okay. I reopened the issue.

etxaleku commented 10 months ago

I agree, it is working for me (very reliably) but there are times when it regresses and the issue reappears. The two situations where I have seen it reappear is -

R1. if I use Teams in a screen sharing session then I have seen it reappear. Rebooting (and avoiding screen sharing) returns it to working condition. R2. if I bring up other Windows-based apps of a "graphical" nature, like a browser, BEFORE starting WSL2 and X-based Linux apps, then the issue seems to be very reproducible - so far 100% of the time based on about 10 reiterations.

For R1 I have successfully been able to do some Teams screen sharing recently and did not have the issue reappear. That one seems to be intermittent. Given the frequency of the Teams screen sharing recurrence, I'm almost wondering if those few times that occurred that it might have actually been a reproduction of R2 as I wasn't aware of R2 initially.

For R2, that one seems very reproducible. If I reboot and the very first thing I start up is WSL2 and then emacs then everything works very reliably and I can use anything (Windows or Linux) I want for days on end without issue. But if I reboot and bring up a browser first then when I start WSL2 and then emacs the issue appears every time. A quick reboot returns everything to working order.

@avaranze, when you say that it works and then "always happens again after some time", how much time are you finding has to pass before it happens? Is it hours or days? Mine has been stable for periods on the order of 7 days or so. The main X-based "graphical" app that I'm running is emacs though I have recently started running a Linux-based version of IntelliJ (Community Edition).

I do also see the "other" issue where X-based graphical apps are "orphaned" after a Windows sleep. Basically if your machine goes to sleep for any reason (manual or automatic), then after resuming the graphical apps are still running according to "ps -ef" but they don't appear on the taskbar and cannot be rendered. But this is a different issue than the one discussed here - the video "fuzzing" issue.

keesj commented 10 months ago

I am still having the issue

fuzy112 commented 10 months ago

I still have this issue. A workaround for me is to use fullscreen mode when using Emacs (M-x toggle-frame-fullscreen). But other apps still don't work now.

indigodarkwolf commented 10 months ago

I ran into this issue on a fresh Windows 11 install. Double-checked and already had the latest drivers for my NVIDIA card. Using WSL and the Debian build from the Microsoft Store app.

I wound up working around it by creating a .wslgconfig file in %userprofile%, following the advice from https://github.com/microsoft/wslg/issues/1148#issuecomment-1827607993.

jakubzeman-acc commented 10 months ago

A simple solution that worked for me on Windows 11 was setting a default user in the Windows registry. Set the following key to your non-root UID (usually 1000, which is in HEX 3e8)> HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\\DefaultUid

And restart wsl.

epg commented 10 months ago

:metoo:

WSL version: 2.0.14.0 Kernel version: 5.15.133.1-1 WSLg version: 1.0.59 MSRDC version: 1.2.4677 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.3930

Reproducible with:

tkonsta commented 9 months ago

After reading some comments which related to the intermittent WSLg issues to running programs on windows I did some tests and for me disabling Microsoft PowerToys resulted in a reliably stable WSLg experience without UI glitches and without lagging or hanging keyboard. Maybe someone else who is running PowerToys on Windows could give this a try and confirm?

keesj commented 9 months ago

I have tried a few more suggestions posted here and elsewhere

[system-distro-env] ;disable GPU in system-distro LIBGL_ALWAYS_SOFTWARE=1


* Downgrading drivers

Perhaps that my setup has something else with it going wrong.
* I did upgrade the kernel / ubuntu to a recent version e.g.  23.10
* Hyper-V is disabled

Currently I am working around the issue by using xpra (but that does require me to remount /tmp/.X11-unix read/write
neodon commented 9 months ago

I've run into this problem many times and did some experimenting. Observations:

Here is the solution I am using that has been working consistently. This command needs to be run in PowerShell as an administrator.

Restart-Service -Name WSLService

Since the WSLg processes run under WSLService, this command restarts them. It consistently fixes the corrupt display issue for me... at least for a few hours. 🤷

Cpt-Squirrell commented 8 months ago

I can throw my hat into the mix here. Same issue consistently as the images earlier in this thread show. I run Intel ARC card so hey, mine might not be very surprising. For all I know though it might not be GPU related at all.

mahi1980 commented 8 months ago

For me, updating to the latest pre-release of WSL solved the issue. https://github.com/microsoft/WSL/releases/tag/2.1.1

keesj-riscure commented 8 months ago

For me, updating to the latest pre-release of WSL solved the issue. https://github.com/microsoft/WSL/releases/tag/2.1.1

From the looks of it. it might also have solved my problem

Initial state

WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.4046

Upgraded

wsl --update --pre-release
Checking for updates.
Updating Windows Subsystem for Linux to version: 2.1.3.

and so far things appear to be working. I also noticed that 2.1.1 has an upgrade of gwsl to version 1.0.60

etxaleku commented 8 months ago

@keesj-riscure and @mahi1980, your approach of upgrading to the WSL pre-release sounds very promising and your results sound great but one question - how stable is your environment? Do you use it a lot and depend on it for work? It sounds like you've both been on it for about a week, any concerns? I use mine for work and have to depend on it to work.

One aspect I've noticed that probably significantly contributes to the seemingly random behavior is that starting from a Windows reboot, for me at least, it greatly depends on the order that I start apps. If I reboot and start emacs or any X-application from WSL BEFORE running any Windows graphics apps then everything works and life is good. But if I reboot Windows and bring up say a browser and pull up some web pages and then try to start any WSL X-applications then I get the video fuzzing.

Definitely planning on trying @neodon's recommendation of Restart-Service -Name WSLService from PowerShell, that sounds promising.

keesj-riscure commented 8 months ago

@keesj-riscure and @mahi1980, your approach of upgrading to the WSL pre-release sounds very promising and your results sound great but one question - how stable is your environment? Do you use it a lot and depend on it for work? It sounds like you've both been on it for about a week, any concerns? I use mine for work and have to depend on it to work.

I use WSL2 / Ubuntu 99% of the time and I am quite sure my setup is unique and over the last 2 years of using WSL2 it has been a love/hate affair. I can not perform my work without it and when it works .. it works great but I do accept some breakage.

This last update resolved multiple issues for me who is forced to use a firewall/VPN. I needed to run "netsh winsock reset" after every reboot before I was able to access WSL2 and this problem is gone. A colleague of mine was able to restore X11 using https://github.com/microsoft/wslg/issues/426 (e.g. wsl --system, and then kill -9 the /usr/bin/weston ) but that did not work for me.

In the time X11 was not working I used https://github.com/Xpra-org/xpra/wiki/Download with much satisfaction. (I had to mount -o remount,rw /tmp/.X11-unix the X11 folder and started xpra start --start=xterm --bind-tcp=0.0.0.0:10000 )

All that to say.. that I am currently very happy with the upgrade and the relationship is currently good but dmesg is trying to tell me something different:

[   17.647043] WSL (2) ERROR: WaitForBootProcess:3335: /sbin/init failed to start within 10000
[   17.667864] WSL (2): Creating login session for keesj

One aspect I've noticed that probably significantly contributes to the seemingly random behavior is that starting from a Windows reboot, for me at least, it greatly depends on the order that I start apps. If I reboot and start emacs or any X-application from WSL BEFORE running any Windows graphics apps then everything works and life is good. But if I reboot Windows and bring up say a browser and pull up some web pages and then try to start any WSL X-applications then I get the video fuzzing.

I have had occasions where it was working but wsl --shutdown never fixed it for me.

Definitely planning on trying @neodon's recommendation of Restart-Service -Name WSLService from PowerShell, that sounds promising.

mahi1980 commented 8 months ago

@etxaleku I need WSL for work as well, so basically I had no real choice. Regularly trying the new pre-releases was my only hope to come back to a fully operational setup. So far, I did not have any further issues with the pre-release.

etxaleku commented 8 months ago

Thanks for the feedback, gives me confidence to go to the pre-release.

This last update resolved multiple issues for me who is forced to use a firewall/VPN. I needed to run "netsh winsock reset" after every reboot before I was able to access WSL2 and this problem is gone.

Oh wow, I wonder if this will resolve my WSL2 issue when on VPN... Whenever I'm on VPN I have had to use WSL1 as WSL2 would not route traffic properly. I tried everything I could find to get it to work but nothing helped - maybe going to the pre-release of WSL2 will do it for me!

bernhardkaindl commented 4 months ago

In another issue, it was recommended to kill the weston of the system instance for WSDg to let it restart:

# On CMD.exe or also PowerShell:
wsl --system pkill weston

This helped in my case now.

This restarts the X server, so you have to reload .Xresources (if you use them), e.g. like:

xrdb -merge ~/.Xresources