Repository navigation
Weston implements no data-control protocol: background clipboard access steals keyboard focus, and nested compositors cannot watch the clipboard over Wayland #1512
Description
Summary
WSLg's Weston exposes no clipboard-manager protocol (neither wlr-data-control-unstable-v1 nor the newer ext-data-control-v1). As a result, a nested Wayland compositor running inside WSLg (sway, river, labwc, Hyprland, …) cannot be notified when the Windows clipboard changes, so clipboard sharing between Windows and applications inside the nested compositor can only be implemented by polling.
Clipboard sharing between Windows and WSLg's direct clients works fine. The gap is specific to nested compositors, which run as an ordinary WSLg client and therefore have their own, isolated Wayland display.
Environment
WSL version: 2.7.14.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.7214
weston: 04d436c7d9a0cd55fa64b6612c7fa678d6fcd077
Azure Linux: 3.0.20260510
Guest distro: Arch Linux (WSL), sway 1.12, wl-clipboard 2.3.0
Details
WSLg's Weston advertises 20 globals; the only clipboard-related one is wl_data_device_manager:
$ WAYLAND_DISPLAY=wayland-0 wayland-info | grep -i data
interface: 'wl_data_device_manager', version: 3, name: 9
For comparison, the nested sway compositor on the same machine advertises:
$ WAYLAND_DISPLAY=wayland-1 wayland-info | grep -iE 'data|primary'
interface: 'wl_data_device_manager', version: 3, name: 5
interface: 'zwlr_data_control_manager_v1', version: 2, name: 31
interface: 'ext_data_control_manager_v1', version: 1, name: 32
interface: 'zwp_primary_selection_device_manager_v1', version: 1, name: 55
Core wl_data_device only delivers selection events to the client that currently holds
keyboard focus, which is by design and is exactly why clipboard managers need a privileged
extension. Consequently any attempt to watch WSLg's clipboard from a background client fails:
$ WAYLAND_DISPLAY=wayland-0 wl-paste --watch true
Watch mode requires a compositor that supports the data-control protocol
One-shot wl-paste / wl-copy against wayland-0 do work, so reading and writing are fine —
only change notification is missing.
Impact and current workaround
To bridge the clipboard between Windows and applications inside nested sway, I had to implement
the two directions asymmetrically:
- nested → Windows: event-driven. sway supports data-control, so
wl-paste --watchworks. - Windows → nested: polling only (currently once per second), because of the above.
The polling cost is small but it is permanent, and the latency is bounded by the poll interval
rather than being immediate.
Note that Weston itself does deliver wl_data_device.selection to the nested compositor,
because the nested compositor is the focused client — but a compositor is not expected to
re-export the parent selection to its own clients, so that path is not usable either.
Request
Please consider enabling a data-control protocol in WSLg's Weston — ext-data-control-v1
preferably, since it is the standardized successor, or wlr-data-control-unstable-v1 for
wider client compatibility. That would let clipboard managers and nested compositors receive
clipboard change notifications and make Windows↔nested clipboard sharing fully event-driven.
Related (nested/desktop usage of WSLg, no clipboard discussion): #101, #1019
Activity
yycen commentedon Sep 28, 2026
Update / correction to two statements in the original post:
1. One-shot
wl-paste/wl-copyagainstwayland-0are not side-effect-free. Without data-control, wl-clipboard falls back to creating a transient surface to obtain keyboard focus (corewl_data_deviceonly serves the focused client). Each call therefore briefly steals keyboard focus from whatever WSLg window has it. My once-per-second poll caused the nested sway window to lose and regain focus every second; on regaining focus the held keys are re-sent as new presses, so users saw random doubled characters and bursty key repeat (~1006 ms period = 1 s sleep + ~6 ms per call). I confirmed this by timestamping every byte a terminal receives: duplicate characters arrived 5–116 ms apart, far below the client's repeat delay, and the problem disappeared as soon as the poll stopped usingwayland-0.2. Polling is not the only option. WSLg's own Xwayland (
DISPLAY=:0) shares the clipboard with Weston and Windows, and X selections can be read and written without focus. Subscribing toCLIPBOARDowner changes with XFixes (XFixesSelectSelectionInput) delivers one event per Windows-side copy, so I now bridge Windows → nested sway fully event-driven via:0(xclip + an XFixes watcher), with no polling and no focus stealing.The request still stands. The workaround depends on Xwayland, and any pure-Wayland client that accesses WSLg's clipboard in the background still steals focus.
ext-data-control-v1(orwlr-data-control-unstable-v1) would fix both without X11.[-]Weston implements no data-control protocol, so clipboard cannot be shared with nested compositors (sway/river/etc.) without polling[/-][+]Weston implements no data-control protocol: background clipboard access steals keyboard focus, and nested compositors cannot watch the clipboard over Wayland[/+]Add sway-wslg: run sway nested in WSLg on Windows