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