Clipboard copy silently fails on non-wlroots Wayland compositors (e.g. niri) / 在非 wlroots 的 Wayland 合成器上剪贴板复制静默失败 (e.g. niri)

[NLD37BYs]

EN

Environment

• deepseek-tui version: 0.8.40
• OS: CachyOS (Arch Linux)
• Compositor: niri (Wayland, non-wlroots)
• Clipboard tool: wl-copy / wl-paste

Description

Selecting text inside deepseek-tui and copying (via the mouse selection menu) writes
nothing to the system clipboard. The copy action appears to succeed (no error shown), but
pasting in other applications yields nothing.

Root cause

deepseek-tui uses the arboard crate for clipboard access. On Wayland, arboard uses the
wlr-data-control-unstable-v1 protocol — a wlroots-specific extension. Compositors that are
not based on wlroots (niri, River, cosmic-comp, etc.) do not implement this protocol, so
arboard::Clipboard::set_text() silently fails.

The fallback to OSC 52 (write_text_with_osc52) is never reached because arboard returns
Ok(()) even when the data was never actually written to the system clipboard.

Suggested fix

Before falling through to arboard on Linux, try writing to the clipboard via the standard
wl-copy tool (which uses the wl_data_device_manager protocol supported by all Wayland
compositors). Only fall back to arboard (and then to OSC 52) if wl-copy fails.

Patch

--- a/src/tui/clipboard.rs
+++ b/src/tui/clipboard.rs
@@ -132,6 +132,14 @@
         #[cfg(not(test))]
         {
             self.ensure_clipboard();
+
+            // Linux: try wl-copy first because arboard's Wayland backend
+            // requires wlr-data-control which niri does not implement.
+            #[cfg(target_os = "linux")]
+            if write_text_with_wlcopy(text).is_ok() {
+                return Ok(());
+            }
+
             if let Some(clipboard) = self.clipboard.as_mut()
                 && clipboard.set_text(text.to_string()).is_ok()
             {
@@ -200,6 +208,30 @@
     Err(anyhow::anyhow!("Set-Clipboard failed"))
 }
 
+/// Write text to the Wayland clipboard via `wl-copy`.
+#[cfg(target_os = "linux")]
+fn write_text_with_wlcopy(text: &str) -> Result<()> {
+    let mut child = std::process::Command::new("wl-copy")
+        .stdin(std::process::Stdio::piped())
+        .spawn()
+        .map_err(|e| anyhow::anyhow!("Failed to run wl-copy: {e}"))?;
+    if let Some(mut stdin) = child.stdin.take() {
+        use std::io::Write;
+        stdin
+            .write_all(text.as_bytes())
+            .map_err(|e| anyhow::anyhow!("Failed to write to wl-copy: {e}"))?;
+    }
+    let status = child
+        .wait()
+        .map_err(|e| anyhow::anyhow!("Failed to wait for wl-copy: {e}"))?;
+    if status.success() {
+        return Ok(());
+    }
+    Err(anyhow::anyhow!("wl-copy failed"))
+}
+
 #[cfg(not(test))]
 fn write_text_with_osc52(text: &str) -> Result<()> {
     let mut stdout = io::stdout();

────────────────────────────────────────────────────────────

ZH / 中文说明

环境

• deepseek-tui 版本：0.8.40
• 操作系统：CachyOS (Arch Linux)
• 合成器：niri（Wayland，非 wlroots）
• 剪贴板工具：wl-copy / wl-paste

问题描述

在 deepseek-tui
中选中文本并复制（通过鼠标选择菜单），系统剪贴板中没有写入任何内容。复制操作看似成功（无错
误提示），但在其他应用中粘贴无效。

根因

deepseek-tui 使用 arboard 库访问剪贴板。在 Wayland 上，arboard 依赖
wlr-data-control-unstable-v1 协议——这是 wlroots 系的私有扩展。非 wlroots 的合成器
（niri、River、cosmic-comp 等）不支持该协议，导致 arboard::Clipboard::set_text()
静默失败。

OSC 52 回退路径永远走不到，因为 arboard 返回 Ok(()) 时实际并未写入数据。

修复方案

在 Linux 上，优先使用标准工具 wl-copy（走 wl_data_device_manager 协议，所有 Wayland
合成器均支持），写入成功则直接返回。只有 wl-copy 失败时才回退到 arboard 和 OSC 52。

[Hmbown]

Thank you for the detailed bilingual repro and root-cause write-up. PR #1938 now tracks a wl-copy fallback for this exact non-wlroots Wayland clipboard path.

I am keeping the issue open until the patch gets current CI/local focused tests and reporter validation on a real niri/non-wlroots Wayland session. Not a v0.8.42 blocker, but it is valid platform feedback and should not be lost.

[NLD37BYs]

@Hmbown Replying from niri (CachyOS, Wayland). Tested v0.8.44.

**Write (copy out)** — Fixed.
Selected text now pastes into other apps (Firefox, terminal) as expected. This was the main pain point, and it'
s working now.

**Read (paste in)** — Still a gap.
Right-click Paste and Ctrl+V produce nothing on niri. I had AI help look at the code — it seems the clipboard.r
ead() path still goes through arboard with no wl-paste fallback like the write path has. Likely the same underl
ying issue as before: arboard silently fails on reads under non-wlroots Wayland compositors.

I see v0.8.46 has copy/select work planned — mentioning this in case read-path coverage fits in there, but no a
ssumptions.

Thanks @ousamabenyounes for the patch and tests, and thanks for landing it in v0.8.44.

---

**写剪贴板** — 已修复。
选中文本后能在其他应用（Firefox、终端）粘贴出来了，不再静默失败。这个问题对日常使用影响很大，现在正常了。

**读剪贴板** — 仍有一个缺口。
右键菜单的粘贴和 Ctrl+V 在 niri 上粘贴不出来。用 AI 协助分析——看起来 clipboard.read() 路径还只走 arboard，没有
类似写路径的 wl-paste 回退——和之前写问题的原因可能相同：arboard 在非 wlroots 合成器上读也不工作，且不报错。

看到 v0.8.46 在做 copy/select 相关改动，不知道是否会把读路径也覆盖到，提一下供参考。

感谢 @ousamabenyounes 的补丁和测试，也感谢你把它合进 v0.8.44。

[Hmbown]

The remaining read-side Wayland gap from your v0.8.44 retest is now included in the v0.8.50 candidate branch via #2504:

• e2201b87d harvests fix(tui): read Wayland clipboard via wl-paste #2540 from @cyq1017 so Linux reads try wl-paste before falling back to arboard.
• 9f33c4d59 adds --no-newline to avoid adding a trailing newline to pasted text, with a mock wl-paste regression that checks the argv contract.

Local validation on the release branch:

• cargo test -p codewhale-tui --all-features --locked wl_paste_helper_reads_text_from_stdout -- --nocapture
• cargo test -p codewhale-tui --all-features --locked clipboard -- --nocapture
• cargo clippy -p codewhale-tui --all-targets --all-features --locked -- -D warnings

I moved this issue into the v0.8.50 milestone, but I am leaving it open until there is validation on a real niri/non-wlroots Wayland session after the candidate build is available. Thanks @NLD37BYs for the original report and the v0.8.44 read-path retest, and thanks @ousamabenyounes for the earlier write-path work that got the copy-out side fixed.