[PATCH v3 0/1] MR6372: winewayland: Some init changes.
-- v3: winewayland: Make the pointer protocols optional. https://gitlab.winehq.org/wine/wine/-/merge_requests/6372
From: Aida Jonikienė <aidas957(a)gmail.com> Some compositors (like Mutter in nested mode) don't support the relative motion protocol (which causes winewayland to fail to load even if it's used for simple apps like winecfg). --- dlls/winewayland.drv/wayland.c | 13 +++++-------- dlls/winewayland.drv/wayland_pointer.c | 15 +++++++++++++++ 2 files changed, 20 insertions(+), 8 deletions(-) diff --git a/dlls/winewayland.drv/wayland.c b/dlls/winewayland.drv/wayland.c index 35dbcb5f0ef..9432dc934c9 100644 --- a/dlls/winewayland.drv/wayland.c +++ b/dlls/winewayland.drv/wayland.c @@ -274,16 +274,13 @@ BOOL wayland_process_init(void) ERR("Wayland compositor doesn't support wp_viewporter\n"); return FALSE; } + + /* Check for optional globals. */ if (!process_wayland.zwp_pointer_constraints_v1) - { - ERR("Wayland compositor doesn't support zwp_pointer_constraints_v1\n"); - return FALSE; - } + ERR("Wayland compositor doesn't support optional zwp_pointer_constraints_v1 (pointer locking/confining won't work)\n"); + if (!process_wayland.zwp_relative_pointer_manager_v1) - { - ERR("Wayland compositor doesn't support zwp_relative_pointer_manager_v1\n"); - return FALSE; - } + ERR("Wayland compositor doesn't support optional zwp_relative_pointer_manager_v1 (relative motion won't work)\n"); process_wayland.initialized = TRUE; diff --git a/dlls/winewayland.drv/wayland_pointer.c b/dlls/winewayland.drv/wayland_pointer.c index b549aa28257..403fc080506 100644 --- a/dlls/winewayland.drv/wayland_pointer.c +++ b/dlls/winewayland.drv/wayland_pointer.c @@ -736,6 +736,14 @@ static void wayland_pointer_update_constraint(struct wl_surface *wl_surface, { struct wayland_pointer *pointer = &process_wayland.pointer; BOOL needs_relative, needs_lock, needs_confine; + static unsigned int once; + + if (!process_wayland.zwp_pointer_constraints_v1) + { + if (!once++) + ERR("This function requires zwp_pointer_constraints_v1\n"); + return; + } needs_lock = wl_surface && (confine_rect || covers_vscreen) && !pointer->cursor.wl_surface; @@ -814,6 +822,13 @@ static void wayland_pointer_update_constraint(struct wl_surface *wl_surface, } } + if (!process_wayland.zwp_relative_pointer_manager_v1) + { + if (!once++) + ERR("zwp_relative_pointer_manager_v1 isn't supported, skipping relative motion\n"); + return; + } + needs_relative = !pointer->cursor.wl_surface && pointer->constraint_hwnd && pointer->constraint_hwnd == pointer->focused_hwnd; -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/6372
I'm splitting the more important part of this MR to !6438 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6372#note_80888
Leaving the decision to @afrantzis, I don't actually mind. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6372#note_81746
What's the reason reason/need to have this exception? Is this just for development (perhaps a local patch would be good enough then?), or to make it easier for people to try simple things out (but does a nested server provide the ideal environment for that?), or are there other use cases? There isn't a fundamental reason that's preventing the implementation of these protocols in nested mode, so it seems to me that making them optional introduces an exception for just a couple of compositors that haven't implemented it for nested mode (yet!), which I don't think is the direction we want to move towards (note that all major compositors support the protocols in non-nested mode). In the end, the change is small enough that I don't mind it either if it's useful for you, but it's not something I would propose myself. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6372#note_81776
On Mon Sep 16 16:45:06 2024 +0000, Alexandros Frantzis wrote:
What's the reason reason/need to have this exception? Is this just for development (perhaps a local patch would be good enough then?), or to make it easier for people to try simple things out (but does a nested server provide the ideal environment for that?), or are there other use cases? There isn't a fundamental reason that's preventing the implementation of these protocols in nested mode, so it seems to me that making them optional introduces an exception for just a couple of compositors that haven't implemented it for nested mode (yet!), which I don't think is the direction we want to move towards (note that all major compositors support the protocols in non-nested mode). In the end, the change is small enough that I don't mind it either if it's useful for you, but it's not something I would propose myself. My primary DE is KDE Wayland so having a nested Mutter session is nice to figure out some Mutter-specific issues
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6372#note_82313
On Thu Sep 19 12:46:29 2024 +0000, Aida Jonikienė wrote:
My primary DE is KDE Wayland so having a nested Mutter session is nice to figure out some Mutter-specific issues OK, it's fine by me then.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6372#note_82643
This merge request was approved by Alexandros Frantzis. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6372
participants (3)
-
Aida Jonikienė -
Alexandros Frantzis (＠afrantzis)
-
Rémi Bernon