Microsoft Is Writing Its Own Wayland Compositor As Part Of WSL2 GUI Efforts
Following yesterday's announcement from their BUILD 2020 virtual conference over GPU acceleration and GUI apps support coming to WSL2, Microsoft was quick to detail their GPU acceleration / DirectX plans for WSL2 and even publishing their DirectX kernel driver. But they weren't as clear until now with how they plan to handle their GUI application handling within WSL2.
The WSL2 GUI application support will still rely upon that DXGKRNL kernel driver for communicating with the host via Hyper-V, but they didn't immediately detail how the application presentation would be handled particularly on the Linux side, such as if they would be writing their own X Server as Apple previously did for macOS or some other approach. It turns out thanks to developer comments we now know they are actually working on their own Wayland compositor as part of the presentation stack.
The quick explanation is Microsoft will be using their own Wayland compositor with a glorified RDP (Remote Desktop Protocol) setup for then showing the applications on the Windows desktop. Microsoft engineer Steve Pronovost offered up the first bits of information on their Wayland presentation plans via this mailing list discussion:
In term of presentation, I need to clarify a few things. We announced today that we're also adding support for Linux GUI applications. The way this will work is roughly as follow. We're writing a Wayland compositor that will essentially bridge over RDP-RAIL (RAIL=Remote Application Integrated Locally). We're starting from a Weston base. Weston already has an RDP Backend, but that's for a full desktop remoting scheme. Weston draws a desktop and remote it over RDP... and then you can peek at that desktop using an rdp client on the Windows side. RAIL works differently. In that case our wayland compositor no longer paint a desktop... instead it simply forward individual visual / wl_surface over the RDP RAIL channel such that these visual can be displayed on the Windows desktop. The RDP client create proxy window for each of these top level visual and their content is filled with the data coming over the RDP channel. All pixels are owned by the RDP server/WSL... so these windows looks different than native window are they are painted and themed by WSL. The proxy window on the host gather input and inject back over RDP... This is essentially how application remoting works on windows and this is all publicly documented as part of the various RDP protocol specification. As a matter of fact, for the RDP server on the Weston side we are looking at continue to leverage FreeRDP (and provide fixes/enhancement as needed to the public project). Further, we're looking at further improvement down this path to avoid having to copy the content over the RAIL channel and instead just share/swap buffer between the guest and the host. We have extension to the RDP protocol, called VAIL (Virtualized Application Integrated Locally) which does that today. Today this is only use in Windows on Windows for very specific scenario. We're looking at extending the public RDP protocol with these VAIL extension to make this an official Microsoft supported protocol which would allow us to target this in WSL. We have finished designing this part in details. Our goal would be to leverage something along the line of wl_drm, dma-buf, dma-fence, etc... This compositor and all our contribution to FreeRDP will be fully open source, including our design doc. We're not quite sure yet whether this will be offered as a separate project entirely distinct from it's Weston root... or if we'll propose an extension to Weston to operate in this mode. We would like to build it such that in theory any Wayland compositor could add support for this mode of operation if they want to remote application to a Windows host (over the network, or on the same box).
Beyond the Wayland details, Steve did mention that at least internally they had been discussing the possibility of supporting DirectX on Linux outside of the Windows/WSL2 scope:
We have consider the possibility of bringing DX to Linux with no Windows cord attached. I'm not ready to discuss this at this time... but in the hypothetical that we were do this, DX would be running on top of DRI/DRM on native Linux. We likely would be contributing some changes to DRM to address area of divergence and get better mapping for our user mode driver, but we wouldn't try to shoehorn /dev/dxg into the picture. In that hypothetical world, we would essentially have DX target DRM on native Linux and DX continue to target DXG in WSL to share the GPU with the host.
Interesting times ahead...
190 Comments
