Share the clipboard with a machine driven by --control by avillagran · Pull Request #109 · omacom/gliff

avillagran · 2026-10-30T21:25:50Z

Stacked PR. This builds on #106 (the mouse button in the window, which
builds on #105). Only 7c8ddf0 is new here. Once those land, the diff shrinks to it.

The problem

gliff --control sends the pointer and keyboard and nothing else, so text
copied on the driven machine cannot be pasted here, or the other way round.
With one mouse on two machines, that is the first thing you reach for.

What this adds

The clipboard is shared in both directions with each driven machine, from
the command line and from the window, the way a video session shares it:
text, images and copied files, lazily, so nothing crosses until something is
pasted.

--no-clipboard turns it off.
Local selections marked x-kde-passwordManagerHint are not offered, as in
the window. Offering nothing also withdraws what the machines were offered.
What was copied here before connecting is offered to the machine. What was
copied there stays there until the next copy, so connecting or reconnecting
does not replace this machine's clipboard.

How

gliff-server already had the half that joins the compositor's clipboard
(hypr_input::Clipboard) to the transfer engine. It knows nothing about being
a server, so it moves to a new crate, gliff-bridge, and runs on both ends of
--control, which has no window to own a gdk::Clipboard.

On the client, Shared holds the one compositor clipboard and a bridge per
connected machine, and tracks which machine's copy is the selection, so a
paste goes to that machine.
On the server, --control now uses the session's reader task, so it can
write clipboard chunks without being able to deadlock against the client.
Clipboard::start now returns after the initial selection reached the
sink, which lets an owner tell it from a new copy. That one extra roundtrip
changes nothing for a video session.

An older server ignores the messages, and an older client ignores the offers,
so no feature flag is needed.

Limits

A copy on one driven machine reaches this one, not another driven machine.
If the machine holding the selection drops, the selection here is cleared.
Pasting does not show progress here: --control has no window. The driven
machine shows its usual notifications.
x-kde-passwordManagerHint is checked on this machine only, as it is for a
video session: a server offers such a selection.

Testing

scripts/check.sh passes.
Two x86_64 machines, one driving the other over real ssh, with wl-copy and
wl-paste in both directions: text with non-ASCII characters, 4 MB of text
with matching hashes, a PNG with matching hashes, and a copied file.
A copy made before connecting reached the machine in 3 of 3 runs after one
earlier run that did not; the cause of that run was not found. Stopping the
client cleared a selection held by the other machine.
From an aarch64 laptop driving two x86_64 machines from the window, copying
and pasting in both directions by hand.
The tests above ran before the --no-clipboard and password hint checks were
added; those are covered by a unit test of Shared for the hint and by
reading for --no-clipboard, not run.

gliff --stdio shows the gliff-server whose protocol arrives on stdin and leaves on stdout. Another machine runs that server and starts this over ssh with the server's stdout as its stdin, to use this screen as one of its own; only that machine needs ssh access to this one. - stdout is kept for the protocol and fd 1 points at stderr, so nothing that prints can corrupt the stream. - Started by ssh outside the desktop session, it finds the user's Hyprland session the way gliff-server does. - The window shows only that session and remembers nothing; it closes when the stream ends, since only the other machine can start it again. - --fullscreen opens the window fullscreen; the header no longer warns when the window starts that way.

A headless output always went where Hyprland found room. --position puts it right, left, above or below this machine's screens, and --align lines it up with their top or left edges (start), their middles, or their bottom or right edges (end). The position is worked out from the other screens' layout each time the output's mode is set, so a resize keeps it in place beside them.

The header gets a button that adds a headless output here and shows it on the selected machine with `gliff --stdio --fullscreen` over ssh, and a settings button for which side of this computer's screens it stands on and how it lines up. A gliff there without `--stdio` still shows it through a relay in place of its ssh, with Hyprland making its window fullscreen. Stopping, the other window closing or this window closing gives the screen back.

The position comes from the output's logical size, which resize computed with the requested scale. When Hyprland applies a rounded scale instead, place the output again at that scale, so it still meets the other screens on the chosen side and lines up as asked.

The window closes when that stream ends, so a machine opened from its address bar would close with it. A --stdio window shows neither the + nor the address bar, and connecting from the bar does nothing there.

A --stdio window that closes on a connection error or an incompatible server now makes gliff exit with a failure, with the reason as its last stderr line, so the machine that started it can say why. A window the user closes, or a stream the other side ends, still exits successfully.

Showing another machine forgets the lent screen's tab as the selection, and selecting that tab again did not bring it back, so it lost its highlight and the screen buttons asked for a tab once the screen stopped. Selecting a tab whose screen is in use now makes it the selected one, as starting the screen does.

Hyprland places a screen whose position is `auto`, as Omarchy's default configuration does, after every screen with a fixed one. A fixed position for the headless output therefore pushed such a screen aside: on a laptop asked for `--position right`, the laptop screen moved right of the new output. When placing the output moves another screen, the placement goes to Hyprland's `auto-right`, `auto-center-right` and related positions instead. They line up at the start or the center of a side, so `--align end` is centered there, with a warning.

gliff 0.4.1 opens the GPU decoder whenever VA-API lists H.264, and NVIDIA's VA-API driver does, but every picture then fails to export, so the screen lent to such a machine stayed black. That gliff cannot switch to the CPU on its own, so the relay asks for it with GLIFF_VIDEO=cpu when every render node belongs to the nvidia driver, unless GLIFF_VIDEO is already set.

A new crate puts a one-pixel layer surface along chosen outer edges of the layout. When the pointer touches one it locks the pointer there, hides it, takes the keyboard and inhibits shortcuts, and reports relative motion, buttons, the wheel, keys, modifiers and the keymap until told to release. Releasing puts the pointer back just inside that edge, through a new hypr-ipc move_cursor that speaks both config formats.

--control SIDE skips the picture: after the usual Hello it binds a virtual keyboard and pointer, with the client's keymap, to the screen on SIDE of the layout, answers with that screen's size, and injects the client's keys, motion, buttons and wheel until the client goes. The handshake and the setup error report are the session's own.

gliff --control SIDE:HOST, given once for each machine, runs with no window: it keeps a gliff-server --control connection to each machine, reconnecting with backoff, and arms that side's edge only while the machine answers. Pushing the pointer past an armed edge carries it onto that machine's screen, entering at the facing edge where it left this one. Moving back across that edge, or the release hotkey, returns it at the matching point; a held button keeps the pointer there. Keys and buttons still held are let go on the other machine on every return. The release hotkey is matched by keysym in the local keymap, so it means the same keys in any layout.

# Conflicts: # crates/gliff/src/main.rs

A mouse button beside the screen buttons drives the selected machine with this computer's pointer and keyboard across the edge on its side: the same side the screen settings keep, asked for the first time as they are, without the alignment, which only a screen in use needs. Each driven machine runs its control on a thread of its own, so one machine on each side can be driven at once; a second machine on a side already taken is refused. The machine's tab stays selected without its session, says how to cross over or that it is connecting, and its dot shows whether the machine answers. The tab's button or the mouse button, now a stop button, ends the control, which gives the pointer back. A machine is not driven and used as a screen at once. Closing the window ends every control. The control loop now stops on a signal from its owner and reports when a machine connects, drops and why, and when it ends.

While a machine is driven or its screen is in use, the window has nothing to show, so a button beside the screen buttons hides it. A tray icon (a StatusNotifierItem over the session bus, which Omarchy's bar and Waybar show) stands in for it, and a click on the icon brings the window back. Without a tray to come back from, the window stays. The window also comes back by itself once nothing runs in the background any more.

A speaker button, shown while the selected machine is driven, moves that machine's sound to this one: over ssh, pw-record takes what its default output plays, before its volume, as raw 48 kHz stereo, and pw-play plays it here. The other machine's output is muted meanwhile and unmuted however the stream ends. It is muted only once the capture has woken the output, because WirePlumber restores a suspended output's saved mute as it wakes, and once more a second later. The choice is kept per machine and applies the next time it is driven. Stopping the control, or the window, stops the sound too.

The client works out the pointer's extent from the size in HelloAck, but it got the mode as Hyprland reports it, unrotated, while the server bound the pointer to the rotated screen. On a portrait screen the pointer could not reach its bottom. Swap the size for a 90 or 270 degree transform, as the video session does.

The pointer returned to the edge's screen as it stood when control started. A screen moved or rescaled meanwhile put it somewhere else, possibly on the edge again. Read the layout when releasing, and keep the old one only when it cannot be read.

The script unmuted whichever output was the default when the stream ended, and read the mute of the default rather than of the output it muted. If a headset became the default meanwhile, the speakers stayed muted and the headset was unmuted. Keep the default output at the start and use that one throughout.

A sound stopped and started again, or stopped with its control and started with the next one, ends after the new sound began. Its end cleared the machine's sound by name, which dropped the new one and killed its ssh. Each sound now has an id, and an end from another run is ignored.

If the tray's connection failed, its thread ended and the icon went with it, but the window stayed hidden, leaving no way to stop what ran. A closed channel from the tray now shows the window, as a click does.

The other machine's keyboard started from a fresh state and followed only the keys typed into it, so a second layout selected here, or Caps Lock or Num Lock already on, did not apply there. The client now sends its layout in effect and locked modifiers, by name, on entering and whenever they change while captured, in a new KeyboardLocks message. The control server lists the keyboard-locks feature and applies them to its virtual keyboard; a server that does not list it is not sent them, and the video session ignores the message.

Hotkey::parse accepts names such as exclam, but matching looked only at each key's unshifted symbol, so shift+exclam was accepted and never matched. A key now matches by its unshifted symbol or by the one it produces with the modifiers held.

A link whose network went away without closing the connection stayed up: nothing read had a deadline, so its edge kept taking the pointer to a machine that was gone, and input queued for a write that never ended. The link now pings every 2 seconds and is dropped after 6 seconds without hearing from the other machine, or when a write takes that long; it then disarms its edge and reconnects as after any drop.

An edge's screen and rectangle were chosen once, so a screen added farther out left the edge on what was now an inner side, and a moved or rescaled screen kept the old coordinates. hypr-wl's Outputs now binds and forgets outputs that come and go, and hypr-edge reads the layout again after each output's burst, when one goes away, and when the pointer is given back: an edge whose outermost screen changed is put on the new one once Wayland has announced it, or after the pointer it holds is given back. Whether an edge is armed is now kept apart from its surface, so a surface the compositor closes with its screen is given again, and events from an edge's previous surface are ignored.

Keymaps and locks reach a link by separate ways, so a layout selected in a keymap that had just gained it could arrive first, be dropped by a server still on the old keymap, and not be sent again. The link now writes the last locks again right after each keymap.

An edge whose screen changed while it held the pointer moved only when the pointer was given back by a release. When the compositor ended the capture instead, by leaving the edge or unlocking the pointer, the edge stayed on the old screen until the next layout change. Losing the capture now reads the layout again, as a release does.

The window's clipboard stops at its sessions, so a machine driven from an edge could neither give nor take a copy. Move the server's bridge to a crate of its own and run it on both ends of --control. One clipboard here serves every driven machine: a copy here is offered to them all, and a copy there is pasted from the machine that made it.

greptile-apps · 2026-10-30T21:34:08Z

Confidence Score: 3/5

[High impact] The changes reach desktop input, clipboard transfers, and remote-screen workflows on both machines.

The PR should not merge until stale clipboard offers are withdrawn and stalled clipboard reads can no longer block the connection watchdog.

Findings

Replaced files remain available ▶
Stalled reads bypass the watchdog ▶

Summary

The PR shares the clipboard with machines driven through --control, using the new gliff-bridge crate on both ends.

Since the previous review:

Control connections send pointer and keyboard input across screen edges and share clipboard contents.
A remote machine can add a screen to this desktop, with window controls for sound and the tray.

No new findings were accepted.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    Local[Local clipboard] --> Shared[Shared]
    Shared --> Bridges[Bridge for each driven machine]
    Bridges --> Remote[Remote clipboard]
    Remote --> Holder[Remember which machine owns the copy]
    Holder --> Paste[Local paste requests data from that machine]

_{Reviews (2) · Last reviewed commit: "Merge settling a returning pointer and h..." · Reviewed by Greptile}

greptile-apps · 2026-10-30T21:34:11Z

+            if !mime_types.is_empty() || !files.is_empty() {
+                self.holder.set(Some(side));
+                *self.selection.borrow_mut() = None;


Replaced files remain available

When a driven machine takes the clipboard, Shared::on_peer clears only the remembered selection. It never withdraws the local offers already sent to other machines. After copying files locally and then copying something on machine A, machine B can still paste those old local files because its bridge keeps the old serial and file paths.

Withdraw every bridge's local offer when a remote copy takes ownership, before installing that copy.

Knowledge Base Used: Client clipboard experience

greptile-apps · 2026-10-30T21:34:11Z

+                                        *data_len as usize <= CHUNK,
+                                        "clipboard chunk of {data_len} bytes exceeds the limit"
+                                    );
+                                    reader.read_payload(*data_len).await?


Stalled reads bypass the watchdog

If SSH delivers a clipboard message and then stalls partway through its bytes, read_payload waits inside the selected branch without a timeout. This prevents the keepalive branch from running. The session never reports the link down, so the edge stays active and the pointer does not return automatically.

Wrap the payload read in a timeout or move complete message reads to a separate task while keeping the watchdog running.

The stream arrives in bursts, and over WiFi one is sometimes 70 ms late, which left the 30 ms player with nothing to play.

With a machine on each side the screen between them is narrow enough for a fast return to reach the other edge and leave again.

avillagran added 30 commits October 29, 2026 05:32

Keep a --stdio window to its one stream

e8ac6f4

The window closes when that stream ends, so a machine opened from its address bar would close with it. A --stdio window shows neither the + nor the address bar, and connecting from the bar does nothing there.

Merge gliff --control into the screen buttons' branch

c068704

# Conflicts: # crates/gliff/src/main.rs

Bring the window back when its tray icon goes away

39f9177

If the tray's connection failed, its thread ended and the icon went with it, but the window stayed hidden, leaving no way to stop what ran. A closed channel from the tray now shows the window, as a click does.

Merge the control fixes from gliff --control (omacom#105)

8164117

Merge the second round of control fixes (omacom#105)

e9c42a7

Merge writing the keyboard locks after a new keymap (omacom#105)

37a072d

avillagran added 2 commits October 30, 2026 00:54

Merge moving a held edge when the capture is lost (omacom#105)

0820e15

avillagran added a commit to avillagran/gliff that referenced this pull request Oct 30, 2026

Merge sharing the clipboard with a driven machine (omacom#109)

e0ee25d

greptile-apps Bot reviewed Oct 30, 2026

View reviewed changes

avillagran added 3 commits October 30, 2026 18:41

Hold back a moment of a machine's sound so it plays without gaps

80c4d4f

The stream arrives in bursts, and over WiFi one is sometimes 70 ms late, which left the 30 ms player with nothing to play.

Keep a pointer coming back fast from running on to the far edge

12133c9

With a machine on each side the screen between them is narrow enough for a fast return to reach the other edge and leave again.

Merge settling a returning pointer and holding back sound (omacom#106)

ca3f59f

Navigation Menu

Repository navigation

Share the clipboard with a machine driven by --control - #109

Share the clipboard with a machine driven by --control#109
avillagran wants to merge 35 commits into
omacom:mainfrom
avillagran:feat/control-clipboard

avillagran commented Oct 30, 2026

Uh oh!

greptile-apps Bot commented Oct 30, 2026 •

edited

Loading

Diagram

Uh oh!

greptile-apps Bot Oct 30, 2026

Uh oh!

greptile-apps Bot Oct 30, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

avillagran commented Oct 30, 2026

The problem

What this adds

How

Limits

Testing

Uh oh!

greptile-apps Bot commented Oct 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Confidence Score: 3/5

Findings

Summary

Diagram

Uh oh!

greptile-apps Bot Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

greptile-apps Bot commented Oct 30, 2026 •

edited

Loading