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/33...)): - + 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