Microsoft is working on its own composer, Wayland, which is derived from Weston’s code base.
Following yesterday’s announcement of the BUILD 2020 GPU-Accelerated Virtual Conference with GUI applications on WSL2, Microsoft has accelerated its plans for GPU / DirectX acceleration on WSL2 and even released the DirectX kernel driver. But until now it was not so clear that they were planning to work with graphics applications in WSL2.
Support for WSL2 graphics applications will still depend on the DXGKRNL kernel driver to communicate with the host via Hyper-V, but they did not directly indicate how the application would be presented, especially on the Linux side, for example if they would write their own X server, as Apple did for MacOS, or any other approach. It turns out that thanks to feedback from the developers, we now know that they are actually working on their own Wayland composer as part of the presentation stack.
The short explanation is that Microsoft will use its own Wayland Composer with the well-known Remote Desktop Protocol (RDP) to display applications on the Windows desktop. Microsoft engineer Steve Pronovost presented the first information about Wayland’s presentation plans as part of this discussion on the mailing list:
As far as the presentation is concerned, I need to clarify something. Today we announced support for Linux GUI applications. That’s pretty much how it’s gonna work. We write the Wayland composer, who will essentially be a bridge to RDP-RAIL (RAIL=Remote Application Integrated Locally). We’ll start at Weston Air Force Base. Weston already has an RDP backend, but this is for a complete remote office access system. Weston draws the desktop and deletes it via RDP… and you can then view this desktop with the rdp client on the Windows side. Rale works differently. In that case, our Putland composer won’t sign a desk… Instead, it simply sends the custom visual / wl_surface to the RDP RAIL channel so that these visual images can be displayed on the Windows desktop. The RDP client creates a proxy window for each of these visual top layers and its content is filled with data from the RDP channel. All pixels belong to the RDP/WSL server… so these windows look different from the original window – they are painted and thematically represented by the WSL. Proxy window at the host input for collection and return via RDP . This is essentially how the application runs remotely on Windows, and all this is publicly documented as part of the various specifications of the RDP protocol. For the RDP server on the Weston side, we are even considering continuing to use FreeRDP (and to provide patches/extensions as required by the public project). We then look at other improvements to avoid having to copy the content to a RAIL channel and instead swap the buffer between the guest and the host. We have an extension to the RDP protocol called VAIL (Virtualized Application Integrated Locally) that makes this possible today. Nowadays this system is only used on Windows for very specific scenarios. We plan to extend the public RDP protocol with these VAIL extensions to make it the official Microsoft-supported protocol that will allow us to tackle WSL. We’ve completed the detailed design of this section. Our goal would be to use something on wl_drm, dma-buf, dma-fence and so on. This composer and all our contributions to FreeRDP will be fully open, including our design document. We are not sure if it will be presented as a separate project, totally different from Weston’s roots… or we’ll propose an extension so that Weston can work in that mode. We want to configure it so that, theoretically, any Wayland composer can add support for this mode when he wants to uninstall an application on a Windows host (on a network or a single block).
In addition to Wayland’s data, Steve mentioned that there were, at least internally, discussions about DirectX support on Linux outside Windows/WSL2 :
We have considered bringing the DX to Linux without the Windows cable. I’m not ready to discuss this… but in the hypothetical case, the DX will run on DRI/DRM under native Linux. It is likely that we would make some changes to the DRM to correct the discrepancy and get a better view for our custom driver, but we would not try to move /dev/dxg in the image. In this hypothetical world we would essentially have DX target DRM on native Linux, and DX continues to target DXG on WSL to share the GPU with the host.
There are some interesting moments to come…