wslg: Attempting to run GUI apps returns an error

Environment

Windows build number: Microsoft Windows [Version 10.0.21364.1]
Your Distribution version: Ubuntu 20.04
Your WSLg version: 1.0.17.1

Steps to reproduce

  1. Update to Windows build 21364.
  2. Install special NVIDIA 470.14 driver.
  3. Run wsl --update.
  4. Reboot.
  5. Create new Ubuntu 20.04 WSL2 instance.
  6. Install GUI applications (x11-apps, Chrome, etc.).
  7. Attempt to run the applications.

WSL logs:

pulseaudio.log weston.log versions.txt

Expected behavior

GUI applications should open when run.

Actual behavior

Attempting to launch from the CLI returns the error: Error: Can't open display: :0.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 6
  • Comments: 43 (1 by maintainers)

Most upvoted comments

I’m having the same issue.

Cool, which game?

I made a javascript-based (electron) game engine for 2d games, mainly for my Collectible card game (https://store.steampowered.com/app/723410/Doomtrooper_CCG/) but I’ve been making a few short horror titles too.

That configuration will indeed fail at the moment, but will work correctly with the upcoming update.

Great! I can’t wait. I have it all setup so I’ll watch this thread for news.

Appreciate you guys’ hard work on this. WSL2 (and now WSLg) has done the impossible… brought me back from my Linux box to Windows 10 gasp

“College me” would be pissed, for sure!

Thanks @zacharee, we understand the problem and will have the fix in the next version of WSLg.

Just to be selfishly curious what sort of ETA are we looking at for that? Exactly the same issue here, rearrange display and it sparks to life.

We’ll have an update out by early next week.

Thanks @zacharee, we understand the problem and will have the fix in the next version of WSLg.

We’ll repro this locally and fix this… can you try moving monitor 1 to be on the right of 2… i suspect it will fix your issue

My system also has both /tmp/.X11-unix and /mnt/wslg/.X11-unix. I think @pecigonzalo’s issue might be unrelated.

Here’s the command output:

root@ZORIGIN:/mnt/c/Users/Zacha# ls -la /tmp/.X11-unix
lrwxrwxrwx 1 root root 19 Apr 21 19:49 /tmp/.X11-unix -> /mnt/wslg/.X11-unix
root@ZORIGIN:/mnt/c/Users/Zacha# ls -la /mnt/wslg/.X11-unix/
total 0
drwxrwxrwx 2 root    root   60 Apr 21 19:51 .
drwxrwxrwt 5 root    root  180 Apr 21 19:49 ..
srwxrwxrwx 1 zachary users   0 Apr 21 19:51 X0
root@ZORIGIN:/mnt/c/Users/Zacha#

We appreciate the kind words 😃, glad this is working out for you. The thanks for the multi-mon fix goes to @hideyukn88.

@spronovo just wanted to drop in and high five you. My dev machine just leveled up majorly, being able to do GUI apps without any hacks and SOUND IS BACK.

Thanks for all your hard work, and the implementation is so nice for a first release!) image

Thanks for fixing the monitor configuration issues!

@noce2 would you mind creating a new issue for yours, it looks like you are hitting different issue than the monitor configuration and fstab issue discuss in this thread. We have fixes on their way for both of those issues.

While filling the new issue, could you dump the content of the DISPLAY environment variable, run both ls -la /tmp/.X11-unix and ls -la /tmp/.X11-unix/ and attach your /mnt/wslg/weston.log to the bug… if you are only seeing a socket on X1 something strange happened 😃.

@spronovo As a last resort, I rm -rfed the socket and the symlink, and now I get the expected contents for the folder (and I no longer get the display not found error). I’m not sure what the cause of this was but I can say I had previously installed kali-linux and X410 as means of getting the experience that wslg now provides.

ah, that makes sense, thanks for tracking that down. Unfortunately for X11 we don’t have a choice on the location of the socket… it has to be at /tmp/.X11-Unix as this is where X11 client are hardcoded to look at. In Wayland the location of the socket is specified in an environment variable so we’re not dependent on mapping from /tmp for Wayland native app. This link is being setup as part of the WSL private INIT before the user distro take over. Once the user distro takes over, we don’t have any hook back to do further configurations… so we setup everything up front. But if you overwrite /tmp later on, that undo the setup we did. We’ll need to think about this some more and loop-in @benhillis. For the time being, folks that want to override their /tmp will need to manually recreate the link to get GUI application to work properly.

@spronovo Yes, I know that has to be the location, but I was wondering if we could change the process to inject those after fstabs are mounted. That way we can maintain the normal Linux workflow.

It seems like that is a separate issue than the one OP is having. Should I split this up to another issue or a conversation? Or would you like to do so?

Agreed, after a bit more research it looks like it’s actually our init that is processing these… so we should be able to swap the order to address this i think. Will chat about this with @benhillis next week. Please go ahead and split this into a separate issue.

Also if you could try recreating the link to see if that’s the only problem.

ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

Do X11 app start after that? If you can help us understand how the link get wiped on your system that would be much appreciated as we don’t see this on our end 😃.