The Dawn of a New Era. Why Needs You Anymore vcxsrv You Stupid Piece of ..

Just kidding - VC X-server has been a boon to mankind, but, one must keep up with the times.

For whatever reason, today:

suddenly, when I do

gedit

In WSL, nothing launches. There's no error message

And if I do

ps

It shows the process is running

(To everyone's favorite agony aunt chatty Cathy GPT)

Not sure where I had this (I think it was from using chatGPT a few months ago), but my display was being set using

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

(but I don't know in which file). My vcxsrv is getting launched through an icon in the Startup folder.

This, apparently, is something you only need if you're on WSL2 and, there's something new called WSLg. Who knew?

PS C:\Users\anant> wsl --version

WSL version: 2.3.26.0

Kernel version: 5.15.167.4-1

WSLg version: 1.0.65

MSRDC version: 1.2.5620

Direct3D version: 1.611.1-81528511

DXCore version: 10.0.26100.1-240331-1435.ge-release

Windows version: 10.0.26100.3624

Thanks — this tells us you do have WSLg (Windows Subsystem for Linux GUI) installed and active, which means:

✅ You do not need VcXsrv anymore
✅ WSL itself can display GUI apps natively (gedit, xclock, etc.)
✅ It’s cleaner, faster, and more stable — and works even if no X server is manually started on Windows

✅ 1. Shutdown any lingering X servers

  • Kill any running VcXsrv from Task Manager

  • Delete or disable VcXsrv shortcuts from your Startup folder (optional)

✅ 2. Unset DISPLAY manually (WSLg sets it automatically)

In WSL:

bash
unset DISPLAY

Then try:

bash
gedit

If all is working correctly, it should just open — WSLg handles everything behind the scenes (no need to set DISPLAY, run xhost, etc.).

analog@DESKTOP-O264A5N ~ $ unset DISPLAY

analog@DESKTOP-O264A5N ~ $ gedit


(gedit:1186): Gtk-WARNING **: 17:21:04.856: cannot open display:

Thanks — that output confirms you're not currently running inside a WSLg session, even though WSLg is installed.
You're falling back to a non-GUI terminal where DISPLAY is not automatically set by WSLg.

Option 3: Test if WSLg is working

In a GUI-enabled WSL session:

bash
echo $WAYLAND_DISPLAY

If it returns something like wayland-0, WSLg is active.

analog@DESKTOP-O264A5N ~ $ echo $WAYLAND_DISPLAY

wayland-0

Perfect — that means:

✅ You're now in a WSLg-enabled session
✅ The WAYLAND_DISPLAY=wayland-0 confirms that WSLg is active
❌ But gedit still failed earlier — likely because DISPLAY wasn't set (even though WSLg is running)


🛠️ Fix That Bridges It All

Try this now in your WSLg-enabled shell:

bash
export DISPLAY=:0
gedit

Since WSLg uses Wayland behind the scenes but still supports X11 apps like gedit, it normally sets DISPLAY=:0.
Sometimes it doesn’t inherit correctly depending on how the session started.

✅ If That Works...

You can add this to your .bashrc or .zshrc, but only if WAYLAND_DISPLAY is set (to avoid conflicting with VcXsrv):

bash
if [ -n "$WAYLAND_DISPLAY" ]; then
  export DISPLAY=:0
fi

This way, gedit, xclock, and all other GUI apps will "just work" in WSLg sessions, and you can forget about VcXsrv entirely.

And it did!

Note that this might not be the end of the story. Check if you have a .profile with stuff lingering from old chatGPT conversations from a pre-WSLg era in which you *had* to set DISPLAY to window_ip:0. I found out just now:

WINDOWS_IP=$(ip route | awk '/^default/ {print $3}')
# Appropriately set DISPLAY to Windows X11 server
# DISPLAY="$WINDOWS_IP:0"

Was shooting me in the f..

Comments

Post a Comment