--
v3: d3dx9: Link versions 42 and 43 to the corresponding d3dcompiler DLL.
d3dx9: Reimplement D3DXCompileShader() for versions before 42.
d3dcompiler: Use D3DCompile2VKD3D() from vkd3d-utils.
d3dcompiler: Use D3DPreprocess() from vkd3d-utils.
vkd3d: Import vkd3d-utils.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5814
Our findstr implementation defaults to textual search, while native
defaults to regex.
So this MR:
- add tests to show that,
- reverts the default,
- adapt tests that were written with textual search in mind to pass textual
search option
Note: native fails when passing the two flags ('findstr /l /r...'). I didn't bother
fixing our implementation.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7415
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