Wayland driver development - December 2021 update and next steps

[Jacek Caban]

Hi Alexandros,

It's good to hear that the driver is progressing well.

On 12/10/21 6:56 PM, Alexandros Frantzis wrote:
> The vast majority (but not all) of the commits in the series affect only
> the driver itself. However, there is still a lot of surface area, mostly
> in terms of interfaces used to interact with Wine core, that could lead
> to broken code when upstream is updated. This has been more pronounced
> the last few weeks with the various changes in the driver interface.


I was responsible for those changes. This is just a preparation for a 
huge change that drivers will need to implement as a part of PE 
separation. While following interface changes shouldn't be too hard, 
doing the final separation will be more tricky. Let me roughly describe 
what will need to be done.


A majority of the driver will ultimately live in Unix library (not 
PE-in-ELF like now) and will be executed behind syscall barriers. The 
main practical implication is that while it will have full access to 
Unix libraries, it will not be able to (easily) call PE libraries. This 
requires changes all over the place (see dlls/win32u for an example and 
"#pragma makedep unix" in general):

- Instead of kernel32/kernelbase system functions, the driver can use 
ntdll.so directly.

- Instead of kernel32 runtime functions, like memory allocators for 
memory not exposed outside Unix space, it will need to libc functions.

- For synchronization primitives like CRITICAL_SECTION, it can use ptherad.

- For gdi32 and user32, it can use win32u.so. win32u.so, however, is 
still a work in progress. While it should be already be able to cover 
gdi32 usage, some user32 are still missing in win32u.

- The above are the more straightforward parts. Doing that will live 
some other calls that will be more tricky. Some parts of the driver may 
need to be in PE file, for example.


We don't do that for in-tree drivers yet, mostly because win32u needs to 
be more complete before we can have a complete solution. But since your 
branch is a new and actively developed code, it may make your work 
easier if you take that into account sooner.


> * Display mode changes (emulated with compositor scaling, rather than
>    real display hardware mode changes).


This essentially sounds like "full screen" hack that Proton uses. Given 
that there apparently is a demand for such feature, I wonder if it would 
make sense to share such emulation between drivers. I imagine that this 
could be a null driver's behaviour that other drivers could choose to 
utilize.


> There are some known cases where the driver doesn't work properly, that
> I think deserve an explicit mention since they may trip people up.
>
> The first is when applications try to render to window created by
> another process. Although this not a typical scenario, it's how
> Chrome/Chromium and thus applications using CEF, including some game
> store apps, work. For now, the workaround is to instruct the application
> to use "in-process" GPU handling (with the "--in-process-gpu"
> command-line) or turn-off GPU rendering completely (typically with
> "--disable-gpu --disable-software-rasterizer"). For example, one can run
> GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"


Yeah, we had those problem with winemac.drv for years. At some point I 
wrote a hack that used window surfaces backed by shared memory that 
could be used in child process and parent windows' process later copy 
that into the actual window surface. It works well enough for a number 
of scenarios, but it's not really enough for Vulkan/OpenGL.


I would hope that a cross-driver solution could be found. winex11.drv 
also has some problems with its support for cross process rendering. At 
the time, we talked about an OpenGL-based compositor, although Vulkan 
would be probably the first choice those days. It seems to me that for 
cases when driver can provide support for Vulkan top level windows' 
surfaces, the rest could be implemented in win32u. Child windows 
Vulkan/OpenGL rendering could be rendered off-screen and then composed 
with the rest top level window. OOP rendering could probably be 
implemented on top of that by setting up a top-in-the-process window 
surface and additional IPC to parent window's process. I think that 
Windows has something like that and exposes some of it with DComposition 
APIs, so aligning such solution with that would be interesting. Anyway, 
I didn't look deep enough to be sure about any of that, but that's 
roughly how I imagine that this could be solved with a lot of work, but 
not much involvement on driver side.


Thanks,

Jacek