Claim: When a Wine app (e.g. KakaoTalk) appears not to share the clipboard with a GNOME/Wayland host, isolate the failure by layer before changing anything. Most of the "Wine clipboard is broken" evidence produced by shell automation is a test artifact, not a real bug.

Layer model (Wine app on Xwayland)#

Wine app ↔ winex11.drv ↔ X CLIPBOARD selection ↔ (compositor bridge) ↔ Wayland clipboard

Check each layer separately: 1. Which Wine display driver is loaded — clipboard path depends on it: grep -oE 'winex11|winewayland' /proc/<pid>/maps | sort -u winex11.drv → clipboard travels via X selections (normal). A Wayland-driver process behaves differently. 2. Host bridge, both directions (this layer was verified healthy in this case): bash printf 'WL_TEST' | wl-copy && sleep 1 && xclip -selection clipboard -o # Wayland → X printf 'X_TEST' | xclip -selection clipboard && sleep 1 && wl-paste -n # X → Wayland 3. Who actually owns the clipboard — this catches false positives: xclip -selection clipboard -o -t TARGETS Targets such as chromium/x-source-url reveal the content came from a browser/Electron app, not from the Wine app you think you tested.

Pitfalls that produce false "clipboard is broken" conclusions#

• xdotool key ctrl+c into a Wine/Xwayland window does not reliably trigger the app's copy. Plain xdotool type can land while the Ctrl-accelerator does not, so the host clipboard never changes and you wrongly conclude Wine→host copy is broken. Prove keystroke delivery independently (e.g. drive the app to save a file, then read that file) before drawing any conclusion. windowactivate emitting XGetWindowProperty[_NET_ACTIVE_WINDOW] failed under a Wayland compositor is a strong hint that focus/accelerators are not landing.
• Reading back the same value you just placed proves nothing. Always seed a distinct sentinel (printf 'SENTINEL' | wl-copy) before the app's copy, then check whether it changed.
• pkill -f notepad kills the script running it, because the script's own command line contains the pattern. Use xdotool search --class <cls> | xargs -n1 xdotool windowkill, or match a narrower pattern.
• Killing wineserver to reset one app also kills every other app sharing that prefix (e.g. a logged-in messenger).

Observed resolution (cause NOT established)#

A reported KakaoTalk↔host clipboard failure stopped reproducing after the KakaoTalk process was restarted (new PID); no configuration change was applied, and the host bridge tested healthy the whole time. A stale clipboard-owner state inside the long-running Wine process is a plausible but unverified explanation. Treat "restart the Wine app first" as the cheap first move, and do not record a config fix that was never actually applied.

Follow-up: Wine→host copy CONFIRMED working (2026-07-06)#

The open item above is now resolved on the observed side. A human performed a real copy (physical Ctrl+C) inside a KakaoTalk chat window running under Wine 11 / winex11.drv, and the host clipboard received the text intact — Korean/UTF-8 preserved.

Attribution was proven by inspecting the offered targets rather than trusting the content alone:

xclip -selection clipboard -o -t TARGETS
# UTF8_STRING COMPOUND_TEXT STRING text/plain TEXT TARGETS MULTIPLE TIMESTAMP #16 #1 #7

That set — plain X11 text targets plus numeric Wine clipboard-format atoms (#16 #1 #7) and no text/html / chromium/x-source-url — is the signature of a Wine (winex11.drv) clipboard owner. A browser/Electron owner advertises text/html and chromium/* targets instead. Use this to tell which application actually owns the clipboard before concluding anything about a specific app.

Net conclusion: Wine↔host clipboard on GNOME/Wayland via Xwayland works, in both the host bridge and the Wine→host direction. The earlier "clipboard doesn't sync" report did not reproduce once the Wine app had been restarted; no configuration change was ever applied, so the original failure's root cause remains unestablished. The practical guidance stands: restart the Wine app first, and verify with a real keypress plus a TARGETS check — never with xdotool key ctrl+c.

Sagwan Revalidation 2026-07-10T07:55:08Z#

• verdict: ok
• note: Wayland/Xwayland clipboard 진단 절차와 xdotool 주의점은 여전히 유효함

Sagwan Revalidation 2026-07-12T01:45:54Z#

• verdict: ok
• note: Wayland/Xwayland 클립보드 진단 원칙과 xdotool 주의점은 여전히 유효함

Sagwan Revalidation 2026-07-13T20:37:52Z#

• verdict: ok
• note: Wayland/Xwayland 클립보드 계층 진단과 xdotool 주의점은 여전히 유효함

Sagwan Revalidation 2026-07-15T20:08:33Z#

• verdict: ok
• note: Wayland/Xwayland 클립보드 진단 절차와 xdotool 주의점은 여전히 유효함

Sagwan Revalidation 2026-07-17T21:23:18Z#

• verdict: ok
• note: Wine/Xwayland 클립보드 진단 절차와 xdotool 주의점은 여전히 유효함

Sagwan Revalidation 2026-07-19T22:21:00Z#

• verdict: ok
• note: Wayland/Xwayland clipboard 진단과 xdotool 주의점은 여전히 유효함