Introduction
------------
This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know.
A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland.
Part 1
-------
This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files. Please see the individual commit message for more details.
Some questions I would appreciate some feedback on in the context of this MR:
1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland)
2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland)
Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list.
Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.
--
v3: winewayland.drv: Introduce wayland_mutex.
winewayland.drv: Initialize basic per-thread Wayland instance.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2275
The goal is to eventually move all interfaces from each driver's `mmdevdrv.c` into `mmdevapi`.
--
v2: wine{alsa,coreaudio,oss,pulse}: Move test_connect handling into mmdevapi.
winepulse: Move process_attach and process_detach handling into mmdevapi.
mmdevapi: Query MemoryWineUnixFuncs virtual memory and store the resulting handle.
wine{alsa,coreaudio,oss,pulse}: Return STATUS_NOT_IMPLEMENTED for unused unixlib functions.
include: Add missing "winternl.h" include to unixlib.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1543
Introduction
------------
This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know.
A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland.
Part 1
-------
This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files. Please see the individual commit message for more details.
Some questions I would appreciate some feedback on in the context of this MR:
1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland)
2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland)
Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list.
Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.
--
v2: winewayland.drv: Introduce wayland_mutex.
winewayland.drv: Initialize basic per-thread Wayland instance.
winewayland.drv: Add stub for per-thread data.
winewayland.drv: Perform basic per-process Wayland initialization.
winewayland.drv: Add initial unixlib stub.
winewayland.drv: Add initial driver stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2275
On Wed Mar 1 08:06:29 2023 +0000, Huw Davies wrote:
> @rbernon, note that you should explicitly approve this as it contains
> commits from another author.
I see, yeah, I tried to add the correct strings to the types, but couldn't find anything on array. The others were pretty straightforward.
Also, the build error was misleading and I think it'd be helpful to add the equivalent of `TRACE` in widl. The existing debug parameters were not helpful.
Thanks for the link, good info.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2304#note_25975
ZusiDisplay sometimes loads the same font file into two different
PrivateFontCollections using two threads, so there is a race condition
when the file is opened without the FILE_SHARE_READ sharing mode. The
second call to GdipPrivateAddFontFile() might fail if the first one
hasn't closed the file handle yet.
--
v2: gdiplus: Use FILE_SHARE_READ in GdipPrivateAddFontFile().
gdiplus/tests: Test for GdipPrivateAddFontFile() sharing violation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2302