Running graphical Linux applications on Windows used to be one of those tasks that separated the patient from the pragmatic. You needed a third-party X server, manual firewall exceptions, careful environment variable management, and a willingness to troubleshoot after every major Windows update. That era is over. WSLg — the built-in graphical application support in WSL2 — has matured into a genuinely reliable subsystem that handles Wayland, X11, GPU acceleration, and audio without the fragile scaffolding of the old approach.

This guide covers the current state of running Linux GUI apps on Windows 11 as of early 2026, including the WSLg architecture, GPU passthrough improvements, audio routing, multi-monitor behaviour, and the failure modes that still catch people. If you have worked through the older X11 on WSL guide on this site, consider this the updated companion — same practical focus, current reality. This guide is part of the how-to section and connects to the broader Linux on Windows topic.

The current architecture​

WSLg ships a Weston-based compositor inside the WSL2 lightweight virtual machine. It provides both a Wayland socket and an XWayland bridge, which means both modern Wayland-native applications and legacy X11 applications work without configuration. The compositor communicates with the Windows host through RDP-based transport, rendering Linux application windows as native Windows windows — complete with taskbar integration, window management, and clipboard sharing.

The key difference from the pre-WSLg era is that nothing runs on the Windows side. There is no VcXsrv, no Xming, no X410. The display server lives inside the VM, and the transport to the Windows desktop is handled by the system. If you still have a third-party X server installed from the old days, it will not conflict, but you do not need it.

GPU acceleration passes through the /dev/dxg virtual device, which maps to the host GPU via Microsoft's DirectX-to-Linux translation layer. This means hardware-accelerated OpenGL and Vulkan rendering work inside WSL2 applications, using whichever GPU the Windows host has — Intel, NVIDIA, or AMD. The performance is not native, but for most GUI applications it is indistinguishable from native rendering.

For those curious about how the original subsystem handled things differently, the LXSS and lxrun tech note covers the earlier architecture and why so much legacy advice no longer applies.

Verifying your setup​

Before troubleshooting anything, confirm the basics:

wsl --version

You need WSL version 1.0 or later with a kernel version of 5.15 or above. If your version output does not show WSLg support, run wsl --update from an elevated PowerShell prompt.

Inside your distribution, verify the display socket exists:

ls -la /tmp/.X11-unix/X0

And confirm the environment variable is set:

echo $DISPLAY

It should return :0. If it returns nothing, or if it returns an IP address like 172.x.x.x:0, you have a leftover configuration from the pre-WSLg era overriding the default. Check your .bashrc, .zshrc, or .profile for old export DISPLAY lines and remove them.

Installing and launching GUI applications​

With WSLg working, installing a graphical application is no different from installing it on a regular Linux system:

sudo apt update
sudo apt install firefox gedit nautilus

Launch it directly from the terminal:

firefox &

The application window appears on your Windows desktop as a regular window. It shows in the taskbar, supports Alt+Tab switching, and respects your Windows display scaling settings. Clipboard copy-paste works bidirectionally for text content.

GPU acceleration in practice​

The GPU passthrough in WSL2 has improved considerably since its introduction. OpenGL applications render with hardware acceleration by default. You can verify this inside your distribution:

glxinfo | grep "OpenGL renderer"

The output should reference your actual GPU hardware rather than a software renderer like llvmpipe. If you see llvmpipe, the GPU passthrough is not functioning — usually because the Windows GPU driver is outdated or the WSL kernel needs updating.

For NVIDIA GPUs, CUDA support is available directly through the NVIDIA drivers installed on the Windows host. You do not install CUDA drivers inside the Linux distribution — the passthrough handles this. This distinction trips up anyone following standard Linux CUDA installation guides, which assume direct hardware access.

Audio support​

WSLg routes audio through PulseAudio, with the PulseAudio server running inside the WSL2 VM and communicating with the Windows audio subsystem. Most Linux applications that use PulseAudio or ALSA work without configuration.

Test it with:

paplay /usr/share/sounds/freedesktop/stereo/bell.oga

If audio does not play, check that PulseAudio is running:

pactl info

The most common cause of audio failure is a distribution that ships with PipeWire configured as the default and the WSLg PulseAudio socket not being picked up. In that case, ensure the PULSE_SERVER environment variable points to the WSLg socket:

export PULSE_SERVER=unix:/mnt/wslg/PulseServer

Multi-monitor setups​

WSLg renders Linux GUI windows on whichever monitor has focus, and the windows can be moved between monitors like any other Windows application. However, DPI scaling behaviour can be inconsistent across monitors with different scaling factors. A Linux application that looks crisp on your 100% scaled monitor may appear blurry on a 150% scaled display, because the WSLg compositor renders at one scale factor and Windows performs the scaling for other monitors.

The workaround for DPI-sensitive work is to set GDK_SCALE and QT_SCALE_FACTOR environment variables to match your primary monitor's scaling. This is imperfect — it works best when all monitors share the same scaling factor. Mixed-DPI setups remain one of the rough edges in the WSLg experience.

Common failure modes​

Application launches but no window appears. Check echo $DISPLAY. If it is empty or set to an IP address, WSLg is either not running or being overridden. Remove old DISPLAY exports and restart WSL with wsl --shutdown followed by launching a new session.

OpenGL applications crash on launch. This usually indicates a GPU driver mismatch. Update your Windows GPU drivers to the latest version — the WSL2 GPU passthrough requires specific driver support that older drivers may lack.

Clipboard sharing stops working. This happens intermittently after Windows updates that affect the RDP transport layer. Restarting WSL with wsl --shutdown typically resolves it.

Performance is noticeably worse than native. The RDP-based transport adds latency compared to a native display server. For most productivity applications this is imperceptible, but for anything involving rapid screen updates — terminal emulators with fast scrolling, video playback, animation-heavy applications — the overhead becomes visible. For heavy graphical workloads, a native Linux installation or a full virtual machine with GPU passthrough may still be the better option.

When WSLg is not enough​

WSLg handles the vast majority of graphical Linux application use cases well. The scenarios where it falls short tend to involve professional graphics work, real-time media production, or applications that require direct Vulkan 1.3 features not yet supported by the translation layer. For those cases, the practical options remain dual-booting or running a full Linux VM with dedicated GPU passthrough via Hyper-V.

For most development workflows — running an IDE, testing a web application, using graphical diff tools, previewing documents — WSLg is the correct answer in 2026. The setup effort is minimal, the integration with the Windows desktop is genuine, and the failure modes are well understood.