Wayland driver development - December 2021 update and next steps

[Jacek Caban]

On 12/14/21 4:33 PM, Alexandros Frantzis wrote:
> On Mon, Dec 13, 2021 at 05:34:30PM +0100, Jacek Caban wrote:
>> Hi Alexandros,
> Hi Jacek!
>
>> 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.
> It was a relief to remove from driver all the registry related manipulations for
> the display setup. Thanks :)
>
>> 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.
> Thanks for all the information. It helps put the changes into
> perspective.
>
> Moving in this direction earlier rather than later for the Wayland
> driver makes sense to me. Are all these changes safe to do before the
> full transition?


Yes, it should be fine.


> Also is it possible at this point to mix and match
> calls, e.g., to win32u NtUser* and also to user32.dll (for any functions
> not yet in win32u), or can such a partial transition lead to issues?


Yes, mixing win32u and user32 is possible and should not lead to issues.


>>> * 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.
>>
> I haven't seen the details of how Proton deals with full screen scaling,
> but, at least in the Wayland driver, it's all done using Wayland specific
> functionality, so it's not clear to me at this point how much sharing is
> possible.
>
> In particular, in the Wayland driver the work of scaling is relegated to
> the compositor. The application renders normally, assuming whatever mode
> is active from the Win32 perspective, and the driver tells the
> compositor to scale the surface accordingly to provide the illusion of a
> mode change.


Thank for explanation, it sounds like it fits the driver in this case. 
(I should add a disclaimer that I have little knowledge about Wayland.)


Thanks,

Jacek