Support Wayland protocol to allow GUI apps to work.

[barry-scott]

Given the Linux world is moving to Wayland as the step on from X11 it would be
good to see Wayland supported in WSL.

Off the top of my head think there is enough protocol/API to completely isolate
a windows Wayland server as part of the normal windows desktop from the
wayland clients running in WSL.

All the important GUI tool kits have Wayland support today and its will become mainstream
on Linux distros on the next year.

At this point in time doing work for X11 may be wasted effort.

[iz0eyj]

Maybe I'm wrong because I'm not a Linux developer, but I think that the future for Canonical is Mir and not Wayland.

[pharaone]

@iz0eyj right!

[fpqc]

The main problem with Mir and Wayland is that both require DRM/GL. Right now, WSL does not expose graphics hardware, and rendering/compositing is done over remote X, which partially uses AIGLX and partially uses software rendering due to missing plugins in vcXsrv.

In order for DRM/GL to work, Microsoft would need to have an API for driver makers to expose their devices inside of WSL, which is not yet planned. Wayland and Mir do not support remote indirect opengl rendering, and they won't for the foreseeable future, although perhaps it might be possible in the future (I have a thread on this called something like "WSL should add a DRM api for Windows driver makers" or something like that).

In theory, I also don't see a reason why MS couldn't also provide a translation layer for DRM openGL calls to the corresponding Windows openGL driver, since I don't think the syscalls would even have to be translated.

This is what the Usermode side of Linux is looking for:
https://en.wikipedia.org/wiki/Direct_Rendering_Manager#API

The LXSS and LXCore might support just forwarding this on to the Graphics drivers, since I know that the win32 graphics system was moved to the kernelmode in like 1995 (see below)

From Wikipedia's article on the native NT api:

user32.dll and gdi32.dll include several other calls that trap into kernel mode. These were not part of the original Windows NT design, as can be seen in Windows NT 3.5. However, due to performance issues of hardware of that age, it was decided to move the graphics subsystem into kernel mode. As such, system call in the range of 0x1000-0x1FFF are satisfied by win32k.sys (instead of ntoskrnl.exe as done for 0-0x0FFF), and are declared in user32.dll and gdi32.dll. These functions have the NtUser and NtGdi prefix (e.g. NtUserLockWorkStation and NtGdiEnableEudc).

However, I'm not positive how this works, since I am pretty sure that both OpenGL and DirectX on Windows bypass GDI entirely, and I'm not sure how the Win32 subsystem interfaces at the kernel level with Graphics drivers. I have some speculation and research that I've done below:

Usermode to kernelmode for hw-accelerated OpenGL in Windows

Apparently the situation with openGL on Windows is that the built-in library opengl32.dll is an ancient library used as a loader to get to the graphics card's openGL interface with basic functionality (sort of like how VGA used to work), which then loads a series of OpenGL extensions provided by GLEW in a special header in order to extend the functionality to a modern version of OpenGL.

This means that the "magic" happens inside of opengl32.dll, which opens the tunnel to the graphics hardware, which is then quickly widened in scope to the full modern OpenGL4.5 API by loading OpenGL extensions.

Maybe someone who has experience writing graphics drivers for Windows could explain this at a high level?

Usermode to kernelmode for hw-accelerated OpenGL in Linux

Presumably, however OpenGL32.dll works, the WSL team understands it, and the difficulty would be either mapping the usermode functionality of Linux's Direct Rendering Manager to a corresponding Windows native component, or emulate it in lxss.sys. Since NT understands its own drivers, this would probably actually avoid driver makers having to support LXSS directly. I'm not exactly sure how this would work, but that is probably what you would need to do.

[iz0eyj]

@fpqc would be possible to build a layer OVER WSL that intercepts the graphic calls and transmit it to the Win side?

[fpqc]

@iz0eyj Not with Wayland or Mir. Both of them, I believe, do not have server-side rendering functionality. All rendering is done at the client side via libdrm or perhaps with a fallback to software rendering.

The compatibility layer would have to be part of WSL, although conceptually it actually doesn't seem that difficult to imagine MS being able to emulate the direct rendering manager itself (it would be part of the WSL layer sitting between libdrm and libgl on the Linux usermode side and whatever kernel-mode interface Windows uses to provide hardware-accelerated rendering in the kernelmode).

The main problem with DRM is that emulating it would be much harder than emulating the Linux Standard Base API, since DRM is much newer and much less well documented, and potentially less stable. It also happens to be one of the most active areas of Linux Kernel development over the past few years, and could potentially be much more difficult to emulate, especially if there is no corresponding native NT component that provides the same functionality as DRM. It could entail essentially rewriting 5-10 years of recent (and therefore less-well-documented) work by Linux Kernel devs from scratch, which seems like a pretty daunting task.

[barry-scott]

@iz0eyj Oh yeah Mir... (I wonder how long Canonical will keep that project going, they do like going out on there own).

@fpqc Server side rendering is almost dead these days. Even with X11 modern tool kits do lots of rendering client side and just give X11 the pixmap to draw. Also note that X11 has security issues which Wayland has fixed.

@fpqc From what I have seen the Linux DRM has lots of documentation, which can always be improved if that is necessary.

I'm sure if Microsoft in interesting it adding DRM they can talk to the developers from Intel, AMD etc that wrote the specs and implementation.

I have not looked but I expect that Mir sits on top of DRM as well.

[barry-scott]

All the graphics cards these day have Windows and Linux driver. The graphic card vendors could easily expose there Linux API for WSL if Microsoft specs the interface.

[fpqc]

@barry-scott Not exactly how it would work. They would have to be Windows drivers that attached to some kind of DRM translation interface (or Windows could manage access). Using the Linux driver directly (at least the kernel-mode part) is totally out of the question.

[barry-scott]

@fpqc I must not have been clear.

Assuming that MS wish to do this they provide a Windows Kernal API that allows the DRM interface into the graphics driver.

The vendors have DRM code. Its not beyond the wit of man to put that code into the same Windows driver with the Windows Kernel interface code.

The Linux Kernal DRM API can then be exposed to a WSL user process.

That is how it could work.

[anidotnet]

Now as Mir is out of the picture, implementing Wayland support is the only hurdle in supporting GUI apps in wsl.

[oleid]

Are you sure DRM is required at all? The way I understood it DRM would only be a requirement for running weston or gnome-shell on the Linux side. But that is not what you're want to do.

Wayland doesn't specify how the compositor does the job. C.f. the weston branch using raspberry pi's dedicated hardware or Sailfish's compositor, which uses proprietary android drivers.

Theoretically, one could implement a Direct X12 based compositor.

If the client is using hardware accelerated drawing, that's of course a different story. OpenGL calls would need to be for to the host operating system. Maybe VMWare's gallium driver could be adapted. But for the time being software rendering would do.

[fpqc]

Theoretically one could implement a DX12 based compositor but it would be a lot of work and would not be packaged with ordinary Linux distros.

[oleid]

I'm not saying one should use DX12. I just wanted to point out, that the Linux guest doesn't have to know details about the compositor just to get the basics working. It would definitely make sense to have some means of doing hardware accelerated rendering on the client side and only implement a basic compositor on Windows side supporting client compositors like gnome-shell or kwin. AFAIR this is what login managers like gdm do. But for the rootless case, I assume a full featured compositor on the windows side would be required.
I'm not sure if libweston is tied to drm. If not, that would make implementing a Windows native compositor a lot easier, I guess.