Wayland requirement

[waynesbrain]

Hi, just wondering about this requirement from the README:

Wayland compositor with wlr-data-control protocol...

So, do I have to just have that installed or do I have to be running a Wayland based desktop? I'm running XFCE.

[zackb]

Hi, it is a good question. Since clipboard sync was one of the primary goals in the beginning, it made sense to do it all in wayland.

That being said, it should gracefully degrade based on availability. I honestly don't know how it works under X11 but want to find out.

The daemon and the CLI should work in theory.

[waynesbrain]

Thanks. Yeah, I forked to take a look and get some answers. I've never done any real work with C++ or native Linux so I did some searching and I had to ask for help (apologies if you hate AI) - according to DeepSeek the codebase seems well prepared to work an ICCCM-based solution in there. I left the notes below.

Automated estimate by DeepSeek

There are two Wayland-only integrations, and the clipboard is the big one:

1. Clipboard Sync — wayland.cpp connects to wl_display, binds wl_seat plus a data-control manager, and drives the templated DataControlClipboard<Manager, Device, Offer, Source> in clipboard.hpp. The template is already protocol-agnostic — init() picks ext_data_control_manager_v1 first (KWin), falls back to zwlr_data_control_manager_v1. Consumers (daemon, net.cpp clipboard_set/clipboard_updated) go through the g_wayland global via copy_to_clipboard / set_clipboard_callback.
2. Pairing confirmation popup — src/dialog/main.cpp is a gtk-layer-shell overlay dialog (zwlr_layer_shell_v1, also wlroots-only), spawned for both WiFi pairing (net.cpp) and Bluetooth pairing (pairing.cpp).

Two things soften the blow: the daemon already runs without Wayland — if wayland_srv.init() fails it just skips registering clipboard sync and continues (daemon/main.cpp:119) — so on XFCE today you'd lose only clipboard sync, not files/messages/notifications/OTP. And tether-gtk itself (tray, views) has no Wayland dependency.

The X11 comparable technology: ICCCM selections + XFixes

On X11 there's no compositor-owned clipboard. The clipboard is a client-to-client selection mediated by the X server, specified by ICCCM (classic references). The 1:1 mapping to data-control's capabilities:

wlr-data-control	X11 equivalent
set selection (write)	XSetSelectionOwner(CLIPBOARD) + serve SelectionRequest events (TARGETS / UTF8_STRING)
read selection	XConvertSelection → owner sends SelectionNotify, INCR protocol for large payloads
set_selection change events	XFixes: XFixesSelectSelectionInput(CLIPBOARD) → XFixesSelectionNotify on every ownership change (clipnotify)
primary selection	same machinery with the PRIMARY atom

XFixes is the piece you may not have had on your list — it's how every X11 clipboard manager (xfce4-clipman, klipper, parcellite, clipit) detects changes without polling. CLI conveniences exist: xclip and xsel are the X11 analogs of wl-copy/wl-paste, and wl-clipboard-x11 wraps them as a drop-in (wl-clipboard-x11, linuxjunkies clipboard guide).

How hard the swap would be

The plumbing is easy — this codebase is unusually well-prepared:

• The backend is a single ClipboardManager interface with one construction site (wayland.cpp init()) and all consumers behind WaylandContext methods. There's already a "pick a backend" pattern in init() (ext vs wlr) that you'd extend to "X11 vs Wayland," selected by $XDG_SESSION_TYPE / presence of $WAYLAND_DISPLAY vs $DISPLAY.
• The daemon's epoll loop already integrates wl_display's fd; an X connection is also a socket (ConnectionNumber), so the same integration pattern carries over.

The genuinely hard part is ICCCM itself. Unlike data-control, X11's selection is demand-driven and asymmetric: you must implement the INCR protocol for anything over a few KB, negotiate TARGETS, handle ownership races, and — the classic pitfall — avoid feedback loops when you take ownership to watch changes. xclip is ~700 lines of careful Xlib C for this. A robust, event-loop-integrated implementation is a few hundred lines of focused code (Xlib or xcb + xcb-xfixes), following xclip/xsel as reference implementations.

So the honest estimate: the clipboard backend is a ~1–2 day implementation, not a rewrite — the architecture absorbs it, the protocol is a solved problem with canonical references. The tether-dialog layer-shell popup is a separate few-hour fix: on X11 there's no layer-shell, so you'd fall back to a regular always-on-top (override-redirect) GTK popup. The main risks are edge cases, not architecture: XWayland interop (X11 and Wayland clipboards are separate and famously don't play together under XWayland — Hyprland discussion), large-binary INCR handling, and testing across real XFCE sessions.

Bottom line: if you want clipboard sync on XFCE, the comparable stack is ICCCM selections for read/write + the XFixes extension for change notification — exactly what xfce4-clipman already does. Given how the backend is abstracted, I'd call it "moderate, well-scoped" rather than hard. The daemon wouldn't even need Wayland anymore; you'd keep the data-control path for Wayland users and add an X11 path selected at runtime.

One note for planning: since ext_data_control_v1 is the standardized protocol, the README's "requires wlr-data-control" requirement is slightly narrower than reality — the code already supports KWin's variant too. That's all discussion, of course; I've made no changes to the repo.

[zackb]

This is fabulous. Thank you very much! I don't hate AI at all as this saves me countless hours. The more I think about it the more X11 support seems worth it. I will add this work to the TODO list and update with progress.

Thanks again!