[PATCH 0/2] MR11203: winewayland: Require XDG output version 2.
Also fixes a race condition. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203
From: Etaash Mathamsetty <etaash.mathamsetty@gmail.com> --- dlls/winewayland.drv/wayland.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dlls/winewayland.drv/wayland.c b/dlls/winewayland.drv/wayland.c index 5b2b0c5b25b..18aa3ecefc6 100644 --- a/dlls/winewayland.drv/wayland.c +++ b/dlls/winewayland.drv/wayland.c @@ -305,6 +305,9 @@ BOOL wayland_process_init(void) wl_display_roundtrip_queue(process_wayland.wl_display, process_wayland.wl_event_queue); wl_display_roundtrip_queue(process_wayland.wl_display, process_wayland.wl_event_queue); + /* A third roundtrip to help avoid race conditions for zxdg output and color management extensions. */ + wl_display_roundtrip_queue(process_wayland.wl_display, process_wayland.wl_event_queue); + /* Check for required protocol globals. */ if (!process_wayland.wl_compositor) { -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/11203
From: Etaash Mathamsetty <etaash.mathamsetty@gmail.com> --- dlls/winewayland.drv/wayland.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/dlls/winewayland.drv/wayland.c b/dlls/winewayland.drv/wayland.c index 18aa3ecefc6..6da49618de1 100644 --- a/dlls/winewayland.drv/wayland.c +++ b/dlls/winewayland.drv/wayland.c @@ -105,6 +105,8 @@ static void registry_handle_global(void *data, struct wl_registry *registry, { struct wayland_output *output; + if (version < 2) return; + process_wayland.zxdg_output_manager_v1 = wl_registry_bind(registry, id, &zxdg_output_manager_v1_interface, version < 3 ? version : 3); @@ -334,6 +336,11 @@ BOOL wayland_process_init(void) ERR("Wayland compositor doesn't support wp_viewporter\n"); return FALSE; } + if (!process_wayland.zxdg_output_manager_v1) + { + ERR("Wayland compositor doesn't support zxdg_output_manager_v1!\n"); + return FALSE; + } /* Check for optional globals. */ if (!process_wayland.zwp_pointer_constraints_v1) -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/11203
Rémi Bernon (@rbernon) commented about dlls/winewayland.drv/wayland.c:
wl_display_roundtrip_queue(process_wayland.wl_display, process_wayland.wl_event_queue); wl_display_roundtrip_queue(process_wayland.wl_display, process_wayland.wl_event_queue);
+ /* A third roundtrip to help avoid race conditions for zxdg output and color management extensions. */ + wl_display_roundtrip_queue(process_wayland.wl_display, process_wayland.wl_event_queue);
What race condition exactly? Can we solve them in a better way that doing an arbitrary number of roundtrips? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143794
On Mon Jun 22 07:45:17 2026 +0000, Rémi Bernon wrote:
What race condition exactly? Can we solve them in a better way that doing an arbitrary number of roundtrips? Currently there are not enough roundtrips for the zxdg output extension to report ouput data to us. Therefore, there is a race condition where the dispatcher thread is unable to dispatch any events before the app queries display related stuff through win32u, which gives the app stale information.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143821
On Mon Jun 22 09:01:33 2026 +0000, Etaash Mathamsetty wrote:
Currently there are not enough roundtrips for the zxdg output extension to report ouput data to us before process init finishes. Therefore, there is a race condition where the dispatcher thread is unable to dispatch any events before the app queries display related stuff through win32u, which gives the app stale information. If an arbitrary number of rountrips is necessary we should probably use a condition variable and wait until the required information has been fully received before going back to win32u.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143822
On Mon Jun 22 09:02:08 2026 +0000, Rémi Bernon wrote:
If an arbitrary number of rountrips is necessary we should probably use a condition variable and wait until the required information has been fully received before going back to win32u. Note that it could also be nicer to not wait for anything, and use NtUserCallNoParam_DisplayModeChanged when we've received the information to tell win32u about updated display devices. It may mean using default dummy display devices on prefix startup, which could perhaps have undesired effects, or perhaps not.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143823
On Mon Jun 22 09:08:30 2026 +0000, Rémi Bernon wrote:
Note that it could also be nicer to not wait for anything, and use NtUserCallNoParam_DisplayModeChanged when we've received the information to tell win32u about updated display devices. It may mean using default dummy display devices on prefix startup, which could perhaps have undesired effects, or perhaps not. Unfortunately, we do have to wait for all the globals to get registered at the least before we can proceed with the rest of the init code, and handling all the initial events is also required so that the wl_keyboard and wl_pointer exist before process init. I'm in favor of using a condition variable, though, and we can potentially put a timeout on it in case the compositor misbehaves.
Is the system thread stuff ready to be used on a driver like winewayland (can we use win32u with system threads)? I could add that into this patch as well if we are using a condition variable -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143824
On Mon Jun 22 09:25:49 2026 +0000, Etaash Mathamsetty wrote:
Unfortunately, we do have to wait for all the globals to get registered at the least before we can proceed with the rest of the init code, and handling all the initial events is also required so that the ~~wl_keyboard and wl_pointer exist before process init~~ (edit: I thought about that a bit more and I don't think there are any problems with that. However, there could be problems with having dummy output information. I would rather avoid adding new problems). I'm in favor of using a condition variable, though, and we can potentially put a timeout on it in case the compositor misbehaves. Is the system thread stuff ready to be used on a driver like winewayland (can we use win32u with system threads)? I could add that into this patch as well if we are using a condition variable I don't know whether system threads can be used, but in any case we don't have the winewayland dispatch thread spawned at this point anyway.
What about doing something like: ``` while (wl_display_dispatch_queue_timeout( process_wayland.wl_display, process_wayland.wl_event_queue, &timeout ) != -1) if (process_wayland.initialized) break; ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143827
On Mon Jun 22 09:23:49 2026 +0000, Rémi Bernon wrote:
I don't know whether system threads can be used, but in any case we don't have the winewayland dispatch thread spawned at this point anyway. What about doing something like: ``` while (wl_display_dispatch_queue_timeout( process_wayland.wl_display, process_wayland.wl_event_queue, &timeout ) != -1) if (process_wayland.initialized) break; ``` The system thread support itself should be ready. I tried to switch to using it in winewayland but unfortunately it seems it will need a redesign of the clipboard support first, since clipboard access causes it to dispatch messages on the system thread.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143828
On Mon Jun 22 09:24:02 2026 +0000, Alexandre Julliard wrote:
The system thread support itself should be ready. I tried to switch to using it in winewayland but unfortunately it seems it will need a redesign of the clipboard support first, since clipboard access causes it to dispatch messages on the system thread.
while (wl_display_dispatch_queue_timeout( process_wayland.wl_display, process_wayland.wl_event_queue, &timeout ) != -1)
if (process_wayland.initialized) break;
this won't work unless we find a way to initialize that variable within the callbacks (not easy from a cursory look). I'll think about this more -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11203#note_143829
participants (4)
-
Alexandre Julliard (＠julliard) -
Etaash Mathamsetty
-
Etaash Mathamsetty (＠etaash.mathamsetty)
-
Rémi Bernon (＠rbernon)