1

I am working on WSL2 (Ubuntu 20.04) and I have trouble setting up the $DISPLAY environment variable. More specificallly, I have a network configuration that allows me to ping devices connected to eth0, but I cannot run Qt apps.

(Edit: I run WSL2 on Windows 11)

When I run Qt software like Wireshark or in-house software from my company, I have this error message:

user@DESKTOP-XXX:~$ wireshark
qt.qpa.xcb : could not connect to display 0
qt.qpa.plugin: Couoldl not load the Qt platform plulgin "xcb" in "" even though it was found.

Looking this up, I understood that my $DISPLAY variable is not set properly. (I checked and the "xcb" plugin is installed and Qt locates it). I am now on a quest to understand the $DISPLAY envionment variable, and more specifically, how it works on WSL2. I found this great AskUbuntu answer about generalilties, but since WSL2 works a bit particularly (virtual machine, Hyper-V Virtual switch, etc), I can't understand what to set $DISPLAY to to communicate with something connected via Ethernet.

My network settings for WSL2:

I want to cmmunicate with a machine connected via Ethernet on my WSL2 computer. To do this, I set up the following configuration, that allows me to ping the machine:

  • Hyper-V virtual manager Windows app: WSL virtual switch set up as "External network" via the Ethernet connector I use
  • Network Connections Windows app:
    • Ethernet:
      • "Hyper-V extensible virtual switch" checked
    • vEthernet (WLS):
      • Hyper-V extenible virtual switch unchecked;
      • IPV4: IP 10.0.0.10, gateway 10.0.0.3, favorite DNS 0.0.0.0
  • Ubuntu network settings:
    • sudo ifconfig eth0 10.0.0.3 netmask 255.255.255.0
    • sudo ip route add default via 10.0.0.5 dev eth0

This setup allows me to ping my external machine via 10.0.0.2. (If I want to reach Internet via eth0, I need to add nameservers to resolv.conf.)

However, Qt apps still cannot reach it. And they cannot run at all. When I launch, for instance, Wireshark, I have the error message I stated above.

Some solutions I tried, inspired by things I found online:

user@DESKTOP-XXX:~$ export DISPLAY=0.0
qt.qpa.xcb : could not connect to display 0.0

user@DESKTOP-XXX:~$ export DISPLAY=8080
qt.qpa.xcb : could not connect to display 8080


user@DESKTOP-XXX:~$ export DISPLAY=10.0.0.2
qt.qpa.xcb : could not connect to display 10.0.0.2


user@DESKTOP-XXX:~$ export DISPLAY=10.0.0.2:0


infinite loading
rss.clement
  • 33
  • 1
  • 2
  • 6

4 Answers4

0

I believe the problem may be actually occurring in the WSLg "system distribution" rather than in Ubuntu itself. Note that at this point, this is purely a theory -- a theory with a lot of supporting information, but still a theory.

As background, when you start a WSL2 distribution under Windows 11, two distributions are actually started:

  • The main distribution (e.g. Ubuntu)
  • A corresponding system distribution for each "main" distribution. This distribution is actually a Microsoft CBL-Mariner distribution.

Interestingly, for X applications to work in WSL2, you don't even need a network connection from Ubuntu itself. I was able to start Ubuntu, take down eth0, delete all routes, and I could still launch X applications. This is because Ubuntu is linked to the WSLg distribution through a symlink (or in Preview releases, a bind mount) of the X11 socket in /tmp/.X11-Unix/ to /mnt/wslg/.X11-Unix.

What's probably more important is the networking inside that system distribution. I have a feeling that it isn't able to make the proper connections due to the networking changes you mention.

In some quick trials on my end, I'm getting the feeling that you won't be able to "fix" the network at runtime. You can certainly try, and I encourage you to, by launching:

wsl --system -u root

But I wasn't able to "break" it by tearing down network connections myself, and my guess is that this is because the network connections are already established when the system distribution started. From the readme:

WSLGd is the first process to launch after init.

So it seems that we'll need to tear down any existing WSLGd (along with the Weston, XWayland, and Pulse subprocesses) and relaunch it/them after fixing the networking. I haven't gotten that far myself, but perhaps you'll have better success. At this point, if I stop the existing WSLGd, et. al., and restart it, I'm not able start X apps even without any other changes. So getting a basic stop and restart working will be the next step.

Ultimately, I have a feeling that, to permanently fix the issue (if I'm even on the right track with the issue), that you'll need to build your own system distribution with the networking changes already in place.

But that's today's theory. Hopefully I'm overthinking it, and you'll find it's something much more straightforward.

NotTheDr01ds
  • 22,082
0

Throwing this out as another answer (workaround) if you want to go this route. It doesn't "fix" the problem, but you should be able to fall back to the "Windows 10" way of getting X running, which is to either:

  • Install a third-party X server such as VcXsrv (or one of many others)
  • Run via XRDP

That would take WSLg out of the picture, and allow you to run as long as you have a proper network connection between the Windows host and WSL2.

Some details in:

WSLg is nice, but if you need that custom networking configuration, and you can't get WSLg working with it, it's nice to have the "fallbacks" at least.

NotTheDr01ds
  • 22,082
0

Ok, here's another possibility now that I can reproduce this to some extent.

If you are running the latest WSL Preview (0.66.2), then there's a known WSLg issue that causes the X11 socket to be recreated while the old one still exists. This leads the system distribution (see my earlier answer for details) to increment the display number (since the old one is locked).

Check:

ls /tmp/.X11-unix

If this is the issue you are experiencing, then you'll see something other than X0 when the problem is occurring.

You should able to temporarily recover by setting the DISPLAY to whatever number follows the X. For instance, if you have X2, then:

export DISPLAY=:2

Then try xeyes or wireshark.

What I haven't figured out yet is all of the various things that can trigger the issue. In my case, I can easily reproduce it by:

wsl --terminate Ubuntu

... then quickly restarting. This causes a timing issue where the system distro is still running.

As you can see in that issue report, the WSLg team is aware of the problem and will be reverting the change in the next release.

NotTheDr01ds
  • 22,082
0

I'm on windows 10 and running wsl Ubuntu.

Try sudo apt install libxcb-xinerama0

This worked for me beautifully. Especially after so many hours of trying.

ifyouaretea
  • 61