Arch Linux uses Wayland, and syncing to Windows takes several seconds.

[wowvwow]

How frequently does the bug occur?

Always

Description

I hope to compress the content to within milliseconds so that it can be copied and pasted synchronously.

Stacktrace & log output

Can you reproduce the bug?

Always

Reproduction Steps

No response

Version

2.1.3

OS

window10 and archlinux with wayland

[guiyanakuang]

Hi @wowvwow, thanks for the report.

Normal sync should complete in milliseconds — only large file transfers are expected to take noticeably longer, so a multi-second delay on regular content is worth a closer look.

Two things to note:

1. CrossPaste's Linux clipboard support is currently built on X11. Wayland isn't officially supported yet, so there may be unknown timing issues under your compositor (likely via XWayland).

2. Could you share the Linux-side log so we can see where the time is being spent? It's at:

   ~/.local/share/.crosspaste/logs
   

   The most recent file covering a slow-sync reproduction would be ideal.

[wowvwow]

crosspaste.log

[wowvwow]

I found Text characters of any size experience high latency.

[guiyanakuang]

Thanks for the log, @wowvwow — it pointed us straight to the root cause, and it turns out the bottleneck isn't the network.

What we found

The gap between notify change event (Wayland reports a clipboard change) and CrossPaste finishing ingestion repeatedly hits 1.5–2.7 seconds, all before any network call:

Time	Local processing
11:38:04	2646 ms
14:10:44	2650 ms
14:49:13	2401 ms
15:58:49	2763 ms
17:41:05	1584 ms

The cause: CrossPaste reads the Linux clipboard through Java AWT (X11 only), and under XWayland the bridge frequently fails on first attempts (Owner failed to convert data in the log), forcing an exponential-backoff retry loop. LAN sync itself is fast — the delay you feel is the Linux side struggling to read the clipboard.

How we'll fix it in the next release

1. Native Wayland clipboard path. We'll add a Wayland-native implementation alongside the existing X11 one and dispatch automatically based on the session type. Expected per-paste local latency: ~30–100 ms, matching macOS/Windows.

2. Fast-fail on disconnected peers. The log also shows one paste taking 13 s to give up because the Windows side was briefly unreachable and the HTTP send waited on Ktor's timeout. We'll short-circuit sync when the peer is DISCONNECTED and let the reconnect loop retry in the background.

I'll link the PR here once it's up.