On Tue Feb 18 15:25:24 2025 +0000, david edmundson wrote:
Can we back up to explain the specific problems of using wl_data_device, there might be some things we can do within the current constraints.
This MR tries to work within the current Wine clipboard Wine by
forwarding relevant clipboard messages to the foreground window which is likely to have the keyboard focus and that can actually handle them I don't fully understand this part. If you are notified on the data_device about a change, you can still forward this message to all Wine windows whether they have focus or not.
- It's considered "privileged", uncertain whether compositors may try
to limit which applications can access it (unlikely though) I can confirm that Kwin already does limit who can access the clipboard manager to any flatpak'd apps. It's not a direction we want applications to go. That doesn't mean we won't bend over backwards to help with whatever, I would rather explore a design that allow us to set the clipboard even without focus with wl_data_device than to allow all wine apps to read the clipboard without focus via ext-data-control if that's what's needed to solve your problems.
the best way forward would be to design and expose our own set of
protocols that would fit exactly the Win32 model, and let compositors decide if they want to support Wine or not The problem of having to shim an immutable existing API into a completely different awkward Wayland API is not a Wine specific problem. All the cross-platform toolkits have their own set of very similar challenges that we keep having issues with. There's more commonality here than you might think.
Hi David, thanks for your feedback. Long answer ahead :)
Can we back up to explain the specific problems of using wl_data_device, there might be some things we can do within the current constraints.
wl_data_device works OK for many typical uses cases, that's why it was my initial choice (and I still think we should support it, see next paragraph). However, the constraints posed by wl_data_device mean that we are not able to provide the full win32 functionality. For example a win32 application can populate the clipboard or read clipboard contents without the need for a window at all. That's not supported by wl_data_device, but possible with the data-control family of protocols.
The idea behind the alternative MR !7336 is to provide the full win32 functionality if data-control is available, but *also* implement a fallback based on wl_data_device that provides as much functionality as we can within the constraints of that protocol. In this way sandboxed apps will still work OK for the typical clipboard use cases. See the description of !7336 for a link to WIP follow-up MR that implements the wl_data_device fallback.
This MR tries to work within the current Wine clipboard Wine by forwarding relevant clipboard messages to the foreground window which is likely to have the keyboard focus and that can actually handle them
I don't fully understand this part. If you are notified on the data_device about a change, you can still forward this message to all Wine windows whether they have focus or not.
For the wl_data_device scenario in particular, below are notes for the two clipboard directions ((2) is the one relevant for what you asked, but just writing everything down for completeness).
1. Copy data from win32 app, paste into native Wayland app
In order for the win32 clipboard contents to become available to Wayland applications, we need to offer them through (the process that owns) the focused surface. This may not be the process that actually put the data into the clipboard. There are a few options here:
1. Only support the case where the process that places data into the clipboard also has the focus. 2. [This MR] Have a single handler of win32 clipboard updates (in the desktop process), which then notifies the window/process that has the focused surface. 3. [Follow-up to other MR] Have every process listen to win32 clipboard updates, whichever has the focused surface handles the update.
2. Copy data from native Wayland app, paste into win32 app
When we get a new offer from the native Wayland app, the clipboard can be populated with the offered content types by any process (e.g., the one that receives the `wl_data_device.selection` event). However, we need to mark a specific win32 window as the owner of the clipboard, which will then be responsible for providing the data for a particular content type when it receives the WM_RENDERFORMAT window message. The current approach across all drivers is to create a special, message-only win32 window that represents the real native clipboard owner:
1. [This MR] Have a single owner window for all processes, which will then forward any request for clipboard data to the window that actually has access to them (i.e., the one with the Wayland focus). 2. [Follow-up to other MR] Have a separate owner window for each process, which can request the data directly from within the same process. The owner window changes dynamically as Wayland focus moves to different processes.
The design space is not limited to the above and I am happy to explore other avenues if needed. I experimented a bit with some other ideas (e.g., see https://gitlab.winehq.org/wine/wine/-/merge_requests/7236#note_94002), but I am currently most comfortable with the alternative MR approach for wl_data_device, which doesn't deviate much from how the clipboard integration is done in the other Wine drivers.
That doesn't mean we won't bend over backwards to help with whatever, I would rather explore a design that allow us to set the clipboard even without focus with wl_data_device than to allow all wine apps to read the clipboard without focus via ext-data-control if that's what's needed to solve your problems.
What you propose would help in terms of functionality with clipboard direction (1) above. Compared to data-control, though, it would still be both less powerful and more complex, since the main part of the integration complexity comes from direction (2). However, if we do want the fallback anyway, the complexity aspect perhaps is not as important (and in fact supporting only one protocol would be simpler).
In the end I think the decision boils down to just one thing: whether we are happy with the somewhat limited (but mostly adequate) functionality that's possible with wl_data_device, or we want to provide the 100% full win32 clipboard functionality.
--
I understand that the decision to use data-control (or not) involves wider, somewhat not-technical aspects. To me this whole discussion underlines that there are fundamental unresolved issues in the concept of privileged protocols:
1. Without a sandbox it's game over in terms of security anyway (and as you said the sandbox can limit access to privileged protocols). 2. It's a losing game to expose a protocol and then expect applications to just be good Wayland citizens and not use it, without enforcing that restriction somehow. Also, who decides which applications should use which protocol?
But I guess this is a discussion for another forum.