Server aborted with "pure virtual method called" when the bind address
was in use: EiScreen's PortalInputCapture glib thread outlived Arch and
hit its freed vtable. ~EiScreen never deleted m_portalInputCapture, and
a fatal startup threw past cleanupServer(). Fix both.
Add libportal clipboard handling to the remote desktop.
Supports both directions (server to Wayland client paste,
and copy from the Wayland client back to the server)
for UTF-8 text, plain text, and PNG/BMP images.
The shared mime-type table, BMP/DIB and PNG encode/decode helpers, and
portal selection read/write live in a new PortalClipboard
helper used by both PortalInputCapture and PortalRemoteDesktop.
If the portal returns a restored RemoteDesktop session without clipboard
enabled (a token persisted before clipboard support existed), discard
the restore token and reconnect so the user gets a fresh permission
dialog. Otherwise the session would loop with a clipboard-less token
forever.
Send the clipboard over the libportal InputCapture portal. Only built
if the installed libportal has clipboard support.
AI disclosure: Claude was used on both sides of this work.
- Peter Hutterer: "The second commit was purely written by Claude
after I stared at this for too long without seeing any hope of
getting started. Turns out Claude wrote something that at least
looks correct and it does work. It needs review but also needs
knowledge of deskflow's internals that I don't have..."
- Nick Bolton: Claude also assisted with the follow-up work listed
below (image copy/paste, session re-request, race fixes, size/mime
validation, and CMake detection).
Server side (Wayland host, Peter Hutterer):
- Initial scaffolding for inputcapture clipboard support, guarded so it
only builds when the portal exposes the clipboard API.
- Integrate clipboard data into the inputcapture session so the host
clipboard can be offered to the remote (the Claude-written commit
referenced above).
Client side (Wayland receiver, KoljaFrahm):
- Receive clipboard data from the server and feed it into the local
clipboard through libportal. Built on the reference code by Peter:
https://github.com/whot/libportal-clipboard-test/tree/main
Build integration and rebase (Chris Rizzitello, sithlord48):
- Add the original CMake check for libportal/clipboard.h to define
HAVE_LIBPORTAL_CLIPBOARD, and guard the libportal clipboard use on
it.
- Update the code style and rebase onto the updated input capture
session persistence: https://github.com/deskflow/deskflow/pull/9415
Image support and reliability fixes (Nick Bolton):
- Support image copy/paste in addition to text, so screenshots and
other image clipboard contents work both ways through inputcapture.
- Re-request the input capture session when it comes up without a
clipboard, so new testers with existing sessions can get clipboard
functionality without needing to clear the session.
- Defer clipboard reads until the input capture session is active,
avoiding races where reads happen before the portal is ready.
- Fix assorted style issues in original commit to match conventions.
- Check the configured clipboard size limit and validate incoming
mime types before forwarding inputcapture clipboard data.
- Switch the CMake clipboard probe to check_symbol_exists so detection
matches what the compiler actually sees in the headers.
Co-authored-by: Nick Bolton <nick@symless.com>
Co-authored-by: KoljaFrahm <GitHub.Kolja@dfgh.net>
Co-authored-by: Chris Rizzitello <sithlord48@gmail.com>
For libei, there's no indication that a key is repeated.
However, sending repeated key down events (DKDN instead
of DKRP for the synergy protocol) can be confusing to
clients, which then causes issues like in #7971.
Detect repeated key down events in EiScreen server and
send them to the client with the repeat flag set, so in
e.g. synergy that causes the DKRP messages, to be less
confusing.
For me this fixes an issue where the synergy client is
creating a USB device, which requires repeated events
to be entirely dropped since the host OS where the USB
device is connected will do its own repeat when a key
is held down.
this is currently based on wl-copy/wl-paste.
One could probably just implement wl-copy/wl-paste without adding much
complexity and better performance.
Co-authored-by: KoljaFrahm <GitHub.Kolja@dfgh.net>
For the longest time, this log line has bugged me:
```
active sides: e
```
It's hex, but it looks like a bug, since there's no `0x` prefix. Also, most humans can't read hex, so I added a string representation.
New version:
```
[2025-08-06T11:56:00] DEBUG: active sides: LRT (0x0e)
```
This change may help us turn up some everyday problems in the field that get missed due to not using debug log level.
This could also make the log a bit noisier, so at a later date we may need to downgrade anything that is not actually a failure/warning.
