Yes, I think few people seem to realize X Windows can be operated over a network as well. I used to do that with the Windows Subsystem for Linux to use the KDE Konsole and other great tools on my Windows machine using an X server running on the Windows side and a few environment variable tweaks on the Linux side. My colleagues were always confused when they saw the Linux UI seamlessly mixed with the Windows stuff on my display. For the use case mentioned in the article xvfb probably makes more sense though as that stuff often runs on a server and you don't want to stream the output somewhere to work with it interactively.
This is not running X on any network, just sharing access to the resources that the containerized app needs to find the X server on the same host. There's probably an equivalent incantation for Wayland, too.
Well, that's sort of splitting hairs... It is a unix socket, which at the API level is the same as a network connection, but the kernel skips the hassle of attaching protocol headers and routing the packets.
The example above is writing and reading every X11 message over a socket, and not reaching into /dev on the host, else it would need additional parameters added to the docker command.
I'm not current on Wayland, but as of a few years ago all attempts to run it non-locally required the X11 back-compat layer. I have no idea what /dev nodes would be required to be shared for wayland to run in a chroot.
Pretty simple and reasonable really, just needs to use the same Wayland socket and (in order to access it) user ID. From:
https://unix.stackexchange.com/a/359244
I suppose if you were adventurous you could give it whatever other known user ID, and start a separate Wayland compositor for it. But I don't know why you would, when surely the point is to get containerised GUIs visible to you alongside others. Containerised multi-seat I suppose?
Transports
To date all known Wayland implementations work over a
Unix domain socket. This is used for one reason in
particular: file descriptor messages. Unix sockets are
the most practical transport capable of transferring file
descriptors between processes, and this is necessary for
large data transfers (keymaps, pixel buffers, and
clipboard contents being the main use-cases). In theory,
a different transport (e.g. TCP) is possible, but someone
would have to figure out an alternative way of
transferring bulk data.
So, that is why I hear about needing X11 compat for remote connections; wayland connections are still sockets (not e.g. shared mem), but they require the ability to pass file descriptors through the socket, which can only be done with Unix sockets. (and those file descriptors provide access to shared mem)
I don't see any details about how this interacts with OpenGL, like whether indirect rendering is possible or if applications would need /dev mounted.
It's verbose, but that's why I included the description 'just needs same socket and user ID'. That's simple isn't it? Of course it'll always need something.
It could be made less verbose by encapsulating in a compose file, or by removing the env var to point into /tmp and instead using whatever the default is for the chosen image. Also it's not necessary to specify the value for an env var being passed through with the same name (I just copied from SO).
You could do the same thing with User Mode Linux or a virtual machine. WSL is just the easiest/fastest way to run native Linux binaries on a Windows system. If you have a X11 server installed properly on windows and can run Linux apps over ssh (which I've done with cygwin, but there are other paid options as well), then you can run them over ssh to a virtual linux on your own host, or look for ways to skip the ssh tunnel if they can route packets to eachother.
I'm a little surprised the examples don't require fiddling with X permissions, which I always had to do when not using ssh.
