A Microsoft desenvolve seu próprio compositor Wayland, derivado da base de código Weston para o WSL2. Este foi mais um dos muitos anúncios. durante a conferência virtual BUILD 2020 sobre aceleração de GPU e suporte a aplicativos de GUI chegando ao WSL2. Assim, a Microsoft foi rápida em detalhar seus planos de aceleração de GPU/DirectX para WSL2 e até publicar seu driver de kernel DirectX. Entretanto, eles não foram tão claros até agora sobre como planejam lidar com a interface de aplicativos no WSL2.
O suporte ao aplicativo WSL2 GUI ainda contará com o driver do kernel DXGKRNL. Então, isso serve para se comunicar com o host via Hyper-V. No entanto, eles não detalharam como a apresentação do aplicativo seria tratada principalmente em relação ao Linux. Assim, é como se eles estivessem escrevendo seu próprio X Server, como a Apple fazia anteriormente para o macOS ou alguma outra abordagem. Graças aos comentários dos desenvolvedores, agora sabemos que eles estão realmente trabalhando em seu próprio compositor Wayland.
A explicação rápida é que a Microsoft usará seu próprio compositor Wayland com uma configuração RDP (Remote Desktop Protocol) para mostrar os aplicativos na área de trabalho do Windows.
Microsoft desenvolve Compositor Wayland próprio para o WSL2
O engenheiro da Microsoft, Steve Pronovost, deu as primeiras informações sobre seus planos de apresentação em Wayland via lista de discussão:
Em termos de apresentação, preciso esclarecer algumas coisas. Anunciamos hoje que também estamos adicionando suporte para aplicativos GUI do Linux. A maneira como isso funcionará é aproximadamente a seguinte. Estamos escrevendo um compositor de Wayland que fará a ponte sobre o RDP-RAIL (RAIL = Aplicativo Remoto Integrado Localmente). Estamos começando a partir de uma base de Weston.
Weston já possui um RDP Backend, mas isso é para um esquema completo de comunicação remota na área de trabalho. Weston desenha uma área de trabalho e a remota através de RDP … e então você pode espreitar essa área de trabalho usando um cliente rdp no lado do Windows.
RAIL funciona de maneira diferente. Nesse caso, nosso compositor wayland não pinta mais uma área de trabalho … em vez disso, simplesmente encaminha o visual/wl_surface individual pelo canal RDP RAIL, para que esse visual possa ser exibido na área de trabalho do Windows.
O cliente RDP cria uma janela proxy para cada um desses visuais de nível superior e seu conteúdo é preenchido com os dados provenientes do canal RDP. Todos os pixels pertencem ao servidor RDP/WSL … portanto, essas janelas parecem diferentes da janela nativa, pois são pintadas e temáticas pelo WSL. A janela do proxy no host coleta entradas e injeta novamente no RDP.
É basicamente assim que o sistema de comunicação remota de aplicativos funciona no Windows e tudo isso é documentado publicamente como parte das várias especificações do protocolo RDP. Por uma questão de fato, para o servidor RDP no lado Weston, estamos analisando continuar utilizando o FreeRDP (e fornecendo correções/aprimoramentos conforme necessário ao projeto público).
E ele continua sobre Microsoft Wayland no WSL2
Além disso, estamos buscando melhorias adicionais nesse caminho para evitar a necessidade de copiar o conteúdo pelo canal RAIL e, em vez disso, apenas compartilhar / trocar buffer entre o convidado e o host. Temos extensão para o protocolo RDP, chamado VAIL (aplicativo virtualizado integrado localmente), que faz isso hoje. Hoje, isso é usado apenas no Windows no Windows para cenários muito específicos. Estamos pensando em estender o protocolo RDP público com essa extensão VAIL para torná-lo um protocolo oficial suportado pela Microsoft, o que nos permitiria segmentar isso na WSL. Terminamos de projetar esta peça em detalhes. Nosso objetivo seria alavancar algo na linha de wl_drm, dma-buf, dma-fence etc …
Esse compositor e toda a nossa contribuição para o FreeRDP serão totalmente de código aberto, incluindo o nosso documento de design. Ainda não sabemos ao certo se isso será oferecido como um projeto separado, completamente diferente da raiz de Weston … ou se proporemos uma extensão ao Weston para operar nesse modo.
Além dos detalhes de Wayland, Steve falou que pelo menos internamente eles discutiam a possibilidade de oferecer suporte ao DirectX no Linux fora do escopo do Windows/WSL2:
Consideramos a possibilidade de levar o DX ao Linux sem um cabo Windows conectado. Não estou pronto para discutir isso no momento … mas, na hipótese de fazer isso, o DX estaria em execução no DRI/DRM no Linux nativo. Provavelmente estaríamos contribuindo com algumas alterações no DRM para tratar da área de divergência e obter um mapeamento melhor para o driver do modo de usuário, mas não tentaríamos colocar o sapato /dev/dxg na imagem. Nesse mundo hipotético, teríamos essencialmente o DX de destino do DRM no Linux nativo e o DX continuaria no DXG no WSL para compartilhar a GPU com o host.
