Some more thoughts... This MR is based on the standard `wl_data_device`, which comes with all the constraints and complications discussed in the description (needs app focus etc). There are some other approaches which I would like to present for consideration: 1. (Current MR) Use wl_data_device trying to fit into current infrastructure. - \+ Standard clipboard protocol, universal - \- Complexity due to interactions between clipboard manager window and foreground window - \- Doesn't work with multiple desktops (see @littlewu2508 comment above) 2. Use wlr-data-control (and it's recent successor [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/336](ext-data-control)): - \+ Unconstrained clipboard access, reduces winewayland implementation complexity - \- Although it's widely supported (https://wayland.app/protocols/wlr-data-control-unstable-v1#compositor-suppor...) it's not universally supported. Notably mutter is not expected to support it any time soon. - \- It's considered "privileged", uncertain whether compositors may try to limit which applications can access it (unlikely though) 3. Use wl_data_device with temporary "invisible" windows to get the focus - \- Seems fragile and requires some method (compositor specific protocols) to ensure we get the focus -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7236#note_94003