2

Qt apps work from Terminal-hosted WSL, but not from window WSL.

I am trying to run a Qt app, such as xeyes, on WSL2 with Ubuntu 20.04, on Windows 11. When I launch it (xeyes, or Wireshark, or Qt-made software from my company), I have an error: Error: Can't open display: :0.

Depending on the software, the error can be detailed as:

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

For the sake of legibility, I will start code lines like that:

  • C:\Users\me> foo is the Windows terminal (CMD)
  • bash-5.0$ fight is WSL called from the terminal (in the same window)
  • user@PC:~$ is WSL started from Windows 11, from the desktop, in a separate window. It is supposed to be the exact same thing, but apparently not...

The weird thing is that I can run these if I start WSL2 from CMD. But not in my main WSL installation, the one that I start from a shortcut on my Windows desktop.

There are a lot of questions on the subject: Here, here, here. None of the solutions work for my system. My takeaway is that on start-up, WSL changes a network configuration.

How to reproduce

If I open Terminal (Windows command invite) and start WSL from there, it works:

C:\Users\me> wsl ~ -e bash --norc --noprofile
bash-5.0$ xeyes               # --> xeyes work

But if I open WSL directly from Windows, it does not work.

user@PC:~$ xeyes
Error: Can't open display: :0

And the weird thing is, once I opened WSL2, I can't start the app from CMD-hosted WSL again.

C:\Users\me> wsl ~ -e bash --norc --noprofile
bash-5.0$ xeyes
Error: Can't open display: :0

My conclusion is that something in WSL2 changed network settings at launch.

Possible leads

I tried changing the DISPLAY variable.

  • user@PC:~$ export DISPLAY=0.0.0.0 --> same error
  • user@PC:~$ export DISPLAY=0.0.0.0:0 --> runs for several minutes, then same error
  • user@PC:~$ export DISPLAY=10.0.0.3 (local IP) --> same error
  • user@PC:~$ export DISPLAY=10.0.0.3:0 --> runs for several minutes, then same error
  • user@PC:~$ export DISPLAY=[route] putting the default route --> same error

In all cases, the problem must not be DISPLAY, because it has the same default value in CMD and WSL2.

WSL from Windows desktop:

user@PC:~$ echo $DISPLAY --> :0

WSL from Terminal:

C:\Users\me> wsl ~ -e bash --norc --noprofile
bash-5.0$ echo $DISPLAY
bash-5.0$ :0

I thought maybe WSL from desktop changes the network settings. But both ifconfig and ip route show return exactly the same parameters. I also have nothing in my .bashrc that could modify them, at least I think so.

rss.clement
  • 33
  • I think you need to consolidate the three existing questions - Ultimately, they are all towards the same goal, right? – NotTheDr01ds Sep 12 '22 at 17:14
  • And just as a heads-up, I think I'm seeing something similar myself now. Can you add a wsl --status to one of your questions? Thanks! – NotTheDr01ds Sep 12 '22 at 21:28
  • Also, I don't think I've asked you yet, but a wsl -l -v might be useful (or might not) – NotTheDr01ds Sep 12 '22 at 21:37
  • Hey, you're right, I should have consolidated the questions. Thanks for your answers, I'm going through them :)

    Here is wsl --status:

    Default distribution: Ubuntu

    Default version: 2

    Last update: 13/07/2022

    Auto updates are enabled

    Core version: 5.10.102.1

     – rss.clement Sep 13 '22 at 06:46
  • And here is wsl -l -v:

    C:\Users\TRUST-ME>wsl -l -v NAME STATE VERSION * Ubuntu Running 2 CentOS7 Stopped 2

    I installed CentOS7 for our project, but never used it. I don't think it's the source of the problem.

     – rss.clement Sep 13 '22 at 06:48

1 Answers1

1

I am on Windows 10, WSL2 on Ubuntu.

Try the following export QT_QPA_PLATFORM="xcb" sudo apt install libxcb-xinerama0 libqt5x11extras5

ifyouaretea
  • 11