Linux Container Under Windows 10 WSL Supporting Graphics
I recently discovered that it is possible to get Linux graphics working with Linux containers on Windows 10 using VcXsrv. I figured out how to capture the DISPLAY variable from the host Linux and pass it to the container by writing it to a shared file. This technique is similar to activating Python virtual environments, and I'm excited to share my findings with you.
Unlocking Linux Graphics with Containers on Windows 10 WSL
By Michael Levin
Tuesday, July 26, 2022
I’ve been showing people how to get Linux graphics working under the Windows Subsystem for Linux on Windows 10 using VcXsrv for awhile now. But now that I’m using containers, the question arises whether these containers can use the same Linux graphics. And so…
See if we can get Linux graphics under:
- Windows 10
- WSL2 (Windows Subsystem for Linux)
- LXD Container
- VcXsrv (X-Server)
- Unnecessary on Windows 11 because of WSLg
- WSL supports graphics on Windows 11 but not Windows 10
Yes, it was possible. The .bash_profile of the “host” Linux running directly under WSL2 is must contain:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0
This requirement predates containers to make VcXsrv know where to listen to X-Windows messages. It amounts to finding the IP of the internal DNS server, which is always a trick with these virtual-lan setups. That command extracts it from a standard Linux file /etc/resolv.conf and plugs it into a location accessible from the container.
I had to capture this variable and “pass it down” to the container. It’s dynamically generated on the host, but it must be the same one used in the Linux container’s DISPLAY environment variable. And since my ~/data location is in common to the host and container, I am able to do this in the .bash_profile as well:
echo "export DISPLAY=${DISPLAY}" > ~/data/display.sh
An unexpected surprise is that because the contents of this file reads exactly like an executable bash script:
export DISPLAY=172.30.112.1:0
…I am able to put this one very simple line into the .bash_profile of the container:
source ~/data/display.sh
…which you may recognize as extremely similar to the command that activates Python venvs:
source ~/py310/bin/activate
…because it’s using the same trick!