Baike.dev
Log in
Back to tool/Back to issues
#10142·deskflow

[X11 server] Cursor stays hidden ~2s after switching back from client; input and next switch-away gated by same delay

Author: HomioCreated Sep 9, 2026Updated Sep 11, 2026
Labels:large_orange_diamond: pending response

Before reporting a bug, please complete the sanity checks above.

  • I have done the sanity checks, and my issue persists.

Deskflow version info

Deskflow: 1.26.0 (flatpak 1.26.0 from Flathub) Qt: 5.15.x (bundled in flatpak runtime) System: Ubuntu 20.04.6 LTS (X.Org session, GNOME Shell 3.36.9) Session: X11 (X.Org + GNOME)

Build types

Community package (apt, dnf, pacman/aur, brew, etc.)

Deskflow configuration

  • Ubuntu 20.04 (X11/X.Org) server, Windows client
  • Server (Ubuntu) runs Deskflow 1.26.0 flatpak from Flathub as a systemd user service; client (Windows) runs Deskflow in Barrier protocol mode
  • Server has two monitors: 2560x1440 primary (left) + 1440x2560 rotated left (right); client has a single 2240x1400 screen
  • Client is linked to the LEFT edge of the server's primary screen
  • NVIDIA proprietary driver 570.133.07 on the server

What steps will reproduce the problem?

  1. Start the server (Ubuntu/X11) and client (Windows), normal operation.
  2. Move the mouse from the server screen to the client screen (cross the configured left edge).
  3. Do something on the client, then push the mouse back across the edge to the server screen.

Observed on every switch-back (client -> server):

  • Control returns instantly: the server pointer is warped to the correct entry position immediately and the keyboard works.
  • BUT the server-side cursor image stays invisible for ~2 seconds, then appears by itself.
  • Mouse clicks on the server do nothing until that same ~2s delay has elapsed.
  • Moving/shaking the mouse does NOT make the cursor reappear sooner; waiting ~2s always restores it. It is a fixed internal delay, independent of user input.

Also observed:

  • A new switch-away (server -> client) is blocked for ~2.0-2.8s after each switch-back. Rapid back-and-forth switching is impossible; each return costs ~2.3-2.5s. With the user continuously pushing against the edge, the switch-away lands consistently at ~2.3s after the switch-back (see log below). Switch-back itself has no gate at all (can happen 0.003s after switching away).
  • Waiting a while before switching away makes the switch-away instant again.

Log output

Show log 

Server journal (INFO level), rapid back-and-forth switching, 15 consecutive cycles.
Note the BACK->next-AWAY intervals: all between 1.98s and 2.80s while the user is
continuously pushing against the edge (gate), while AWAY->BACK intervals go as low
as 0.003s (no gate in that direction):

[2026-09-08T19:18:11.821] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,659
[2026-09-08T19:18:12.061] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 24,1114   (+0.240s)
[2026-09-08T19:18:14.859] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,651   (+2.798s after back)
[2026-09-08T19:18:15.189] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 3,1229    (+0.330s)
[2026-09-08T19:18:17.596] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,660   (+2.407s after back)
[2026-09-08T19:18:17.956] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 69,1143   (+0.360s)
[2026-09-08T19:18:20.491] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,598   (+2.535s after back)
[2026-09-08T19:18:20.754] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 40,1024   (+0.263s)
[2026-09-08T19:18:23.056] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,562   (+2.302s after back)
[2026-09-08T19:18:23.364] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 92,898    (+0.308s)
[2026-09-08T19:18:25.862] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,538   (+2.498s after back)
[2026-09-08T19:18:26.162] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 55,885    (+0.300s)
[2026-09-08T19:18:28.730] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,527   (+2.568s after back)
[2026-09-08T19:18:29.019] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 40,1024   (+0.289s)
[2026-09-08T19:18:31.554] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,593   (+2.535s after back)
[2026-09-08T19:18:31.802] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 21,1063   (+0.248s)
[2026-09-08T19:18:34.539] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,625   (+2.737s after back)
[2026-09-08T19:18:34.794] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 46,1010   (+0.255s)
[2026-09-08T19:18:36.998] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,550   (+2.204s after back)
[2026-09-08T19:18:37.011] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 153,1006  (+0.013s)
[2026-09-08T19:18:39.321] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,559   (+2.310s after back)
[2026-09-08T19:18:39.324] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 51,1019   (+0.003s)
[2026-09-08T19:18:41.342] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,566   (+2.018s after back)
[2026-09-08T19:18:42.062] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 26,938    (+0.720s)
[2026-09-08T19:18:44.041] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,522   (+1.979s after back)
[2026-09-08T19:18:44.057] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 10,948    (+0.016s)
[2026-09-08T19:18:46.667] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,467   (+2.610s after back)
[2026-09-08T19:18:47.004] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 39,869    (+0.337s)
[2026-09-08T19:18:49.258] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,496   (+2.254s after back)
[2026-09-08T19:18:49.456] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 36,869    (+0.198s)
[2026-09-08T19:18:51.808] INFO: switch from "DRL-DZ002436" to "DRW-DZ001415" at 2239,492   (+2.352s after back)
[2026-09-08T19:18:51.811] INFO: switch from "DRW-DZ001415" to "DRL-DZ002436" at 1,893     (+0.003s)

Additional information

Measurements (controlled experiment)

All numbers come from a controlled experiment on the server: the switch cycle was triggered programmatically via XTEST, while XQueryPointer and XFixesGetCursorImage were polled at 20-50 ms resolution and correlated with the server's INFO journal (millisecond timestamps).

  1. Server -> client: within ~20 ms the server replaces the local cursor with a 1x1 transparent cursor (XFixesGetCursorImage reports width=1, height=1, cursor_serial=19) and parks the local pointer at a fixed position. Hiding is instant - no issue here.

  2. Client -> server: the server warps the local pointer to the entry position immediately (journal line switch from "<client>" to "<server>" at x,y matches the observed warp within 20 ms). Control and keyboard return instantly.

  3. But the cursor image stays hidden: XFixesGetCursorImage keeps reporting the 1x1 transparent cursor for 2.119 s and 1.867 s (two consecutive cycles) after the switch-back, then the normal 24x24 cursor reappears. Moving/shaking the mouse does not accelerate this - it is a fixed internal timer, independent of user input.

  4. Input is gated by the same delay: mouse clicks during that window do not reach server applications; usability resumes together with the cursor restore (~2s).

  5. Next switch-away is gated ~2.0-2.8s: see journal excerpt above (15 rapid cycles on a pristine instance after a service restart: BACK->next-AWAY between 1.98 s and 2.80 s; AWAY->BACK as fast as 0.003 s).

Ideas about the cause

The 1x1 transparent cursor is defined on the root window and on deskflow's own window (observed via the cursor attribute in XGetWindowAttributes along the pointer's window chain). During the hidden window, a third-party XUndefineCursor on those windows restores the cursor image within ~7 ms - so the image is merely left hidden by a delayed internal restore; it is not an X/driver rendering problem. It looks like the X11 server path re-shows the cursor from a periodic timer (~2 s period) instead of immediately on enter, and the same timer appears to gate the next switch-away and (by observation) mouse input.

Workarounds

  • None found. Scroll Lock (lock to screen) avoids switching entirely but defeats the purpose.
  • No relevant existing issue found (searched deskflow, barrier and input-leap trackers; closest are #8204 and the Windows parked-cursor PRs #9942/#9943/#9962 - the X11 path may be missing the equivalent of the Windows "showing cursor" handling).

Impact

Every return to the server machine costs ~2-2.5 s before the cursor is visible and clickable, and rapid back-and-forth switching between screens is impossible. Restarting deskflow does not help; the behavior is 100% reproducible.

Source: deskflow/deskflow

View original on GitHubView discussion on GitHub