If a surface is being clipped and hides the cursor, drawing its own one,
winewayland constrains using a pointer lock and enables Wayland relative
motion. If the application decides to stop drawing its own cursor and
make the cursor visible, winewayland will disable relative motion and
pointer lock, and enable pointer confinement. The user will perceive a
pointer jump from the win32/application drawn cursor to where the
Wayland pointer is after being unlocked and an absolute motion event is
received, because they were desynchronized due to the Wayland one being
locked in place.
The pointer constraints protocol says this:
> If the client is drawing its own cursor, it should update the position
> hint to the position of its own cursor. A compositor may use this
> information to warp the pointer upon unlock in order to avoid pointer
> jumps.
So, right before unlocking, make a request for the compositor to warp
the pointer to the win32 position on pointer unlock.
--
v3: winewayland: Update locked pointer position hint.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7352
This MR adds clipboard support to the winewayland driver by using the wlr-data-control-unstable-v1 protocol. Note that this protocol was recently merged into wayland-protocols as ext-data-control-v1, but it's not yet widely supported, so I preferred to use the wlr version for now.
This MR has many similarities to https://gitlab.winehq.org/wine/wine/-/merge_requests/7236, but due to the unconstrained nature of wlr-data-control-unstable-v1 the implementation is simpler and more robust. It can neatly fit into the existing Wine clipboard design (single proxy window in the desktop process) without requiring any event forwarding etc.
Since wlr-data-control-unstable-v1/ext-data-control-v1 is considered privileged, it may not be available in all situations, e.g., in sandboxes, and there are also a couple of compositors that may not implement it at all. It is therefore useful to have a simple fallback using the core wl_data_device interface. This fallback is not part of this MR, but I have pushed a WIP implementation based on this MR at: https://gitlab.winehq.org/afrantzis/wine/-/commits/wayland-copy-paste-data-… (note: only the win32 -> wayland direction implemented at the moment). The new fallback approach is different from https://gitlab.winehq.org/wine/wine/-/merge_requests/7236 in that when using wl_data_device it creates per-process clipboard windows instead of forwarding messages from the desktop clipboard window. This allows it to work within the design of this MR with minimal changes and maximum code reuse.
--
v2: winewayland: Normalize received MIME type strings.
winewayland: Support copying data from native clipboard to win32 apps.
winewayland: Support exporting various clipboard formats.
winewayland: Generalize support for exporting clipboard formats.
winewayland: Support copying text from win32 clipboard to native apps.
winewayland: Implement zwlr_data_control_device_v1 initialization.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7336
This allows some relevant events, in particular ClientMessage with WM_TAKE_FOCUS and PropertyNotify for WM_STATUS updates to go through even when QS_POSTMESSAGE is not set. Before this change, if an application was not processing posted messages, it would fail to obtain focus, and also leave WM status updates pending.
Previously, use_take_focus was disabled on Proton by default because x11drv would fail to respond to TAKE_FOCUS events properly. We are now looking to drop this hack in favor of processing the relevant events.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7399
This should allow the CI to fully pass on this merge request.
If it does, master branch could have CI tests enabled to ensure
any actual broken test caused by a merge request is visible just
by the CI status, and master can also reflect the passing status.
Signed-off-by: Damien Zammit <damien(a)zamaudio.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7410