-- v3: winewayland: Make the pointer protocols optional.
From: Aida Jonikienė aidas957@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;
I'm splitting the more important part of this MR to !6438
Leaving the decision to @afrantzis, I don't actually mind.
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.
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
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.
This merge request was approved by Alexandros Frantzis.
-
Aida Jonikienė -
Aida Jonikienė (＠DodoGTA)
-
Alexandros Frantzis (＠afrantzis)
-
Rémi Bernon (＠rbernon)