This allows using one single wineprefix, one wineserver and one single wine executable for running both arm and arm64 executables.
This setup actually has worked earlier; Ubuntu 22.04 packages Wine 6.0, where the wine32 + wine64 packages together end up working this way. However, since Wine 6.0, a couple of refactorings has broken this setup along the way; reinstate this way of working.
The new wow64 mode probably won't work on arm, as it's not easily possible to switch between 32 and 64 bit execution mode within a process, as far as I know, but the old wow64 mode is still a great convenience - especially considering distro-packaged use for users who aren't familiar with the particular quirks on this architecture.
--
v3: server: Include ARMNT as one of the supported architectures on aarch64
ntdll: Allow running arm/aarch64 in (old) wow64 mode
https://gitlab.winehq.org/wine/wine/-/merge_requests/7204
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7336
This MR tries to implement the SetIMECompositionRect user driver function and partially the WINE_IME_POST_UPDATE message call. It requires support for zwp_text_input_v3 from the compositor. It supports submitting committed text to the win32 side and notifying the compositor about the area of the text cursor rectangle.
This doesn't add support for embedded pre-edit because I couldn't immediately get it to appear. Either I did something incorrect, or it has something to do with Wayland. On X11, the pre-edit appears completely separated to the application window and doesn't move with it, which doesn't seem to be compatible with Wayland.
If Windows has the surrounding text feature, it does not seem possible to support it here with the provided interface.
The IME is always enabled on the focused surface, like on X11. If Windows has a facility that applications can use to say that it does or does not accept text entry at certain parts of the UI, it does not seem possible to support it here with the provided interface.
--
v4: winewayland: Post IME update for preedit text.
winewayland: Implement SetIMECompositionRect.
winewayland: Post IME update for committed text.
winewayland: Enable/disable the zwp_text_input_v3 object.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7241
When transitioning a window from IconicState to NormalState and the window is managed, go through
WithdrawnState. This is needed because Mutter doesn't unmap windows when making windows iconic/minimized
as Mutter needs to support live preview for minimized windows. So on Mutter, a window can be both
iconic and mapped. If the window is mapped, then XMapWindow() will have no effect according to the
XMapWindow() documentation. Thus we have to transition to WithdrawnState first, then to NormalState.
Fix Mass Effect Legendary Edition (1328670) starts minimized.
--
v2: winex11.drv: Go though WithdrawnState when transitioning from IconicState to NormalState.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7331
When transitioning a window from IconicState to NormalState and the window is managed, go through
WithdrawnState. This is needed because Mutter doesn't unmap windows when making windows iconic/minimized
as Mutter needs to support live preview for minimized windows. So on Mutter, a window can be both
iconic and mapped. If the window is mapped, then XMapWindow() will have no effect according to the
XMapWindow() documentation. Thus we have to transition to WithdrawnState first, then to NormalState.
Fix Mass Effect Legendary Edition (1328670) starts minimized.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7331
Allow the user to press Ctrl-C to abort lengthy DIR (or DIR /p, etc.) operations.
--
v2: programs/cmd: Implement ability to abort lengthy directory operations via Ctrl-C.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7322