Skip to content

[client,x11] fix raw clipboard transfer between two clients - #13558

Open
yerbolgmailcom wants to merge 1 commit into
FreeRDP:masterfrom
yerbolgmailcom:fix-x11-clipboard-raw-transfer
Open

yerbolgmailcom wants to merge 1 commit into
FreeRDP:masterfrom
yerbolgmailcom:fix-x11-clipboard-raw-transfer

Conversation

@yerbolgmailcom

Copy link
Copy Markdown
Contributor

Problem

Copy and paste between two xfreerdp sessions running on the same X display no longer works. Copying text or an image in one session and pasting in the other pastes nothing. Copy and paste between each session and local applications still works.

This is a regression from a60f2db ("[client,x11] remember available atoms in clipboard"), included in 3.31.1, 3.32.0 and 3.32.1.

Cause

When the clipboard owner is another FreeRDP client, xfreerdp uses raw transfer: it reads the owner's format list from _FREERDP_CLIPRDR_FORMATS and requests data as CF_RAW (_FREERDP_RAW). The owner never lists _FREERDP_RAW in its TARGETS.

Since a60f2db, xf_cliprdr_server_format_data_request() looks up the CF_RAW client format through xf_cliprdr_get_client_available_format_by_id(), which skips formats whose atom was not in the owner's TARGETS. The lookup always fails, so the client never calls XConvertSelection() and sends an empty Format Data Response to the server. The reply path (xf_cliprdr_get_requested_data(), xf_cliprdr_process_requested_data() and the INCR PropertyNotify handler) uses the same filtered lookup with requestedFormatId == CF_RAW, so it would discard the raw data as well.

Change

Look up CF_RAW without the available-atom filter, both when sending the selection request and when handling the reply. Other formats still use the filtered lookup.

How to test

  1. Start two xfreerdp sessions with /clipboard to two Windows hosts on the same X display.
  2. In session A, copy text in Notepad.
  3. In session B, paste in Notepad. Without this change nothing is pasted; with it the text is pasted.
  4. Repeat with an image and in the other direction.

Validation

  • Diagnosis: an X RECORD trace showed that on paste the requesting client wrote the requested format ID to its _FREERDP_CLIPRDR property but never sent ConvertSelection. The owning client answered _FREERDP_RAW requests from a test client for formats 1 and 13 within about 20 ms, including four at once.
  • Live test: two xfreerdp sessions to two Windows hosts on Hyprland/XWayland. Text and images now paste in both directions. This used the same change on a 3.31.2-dev branch.
  • This branch, rebased on current master: xfreerdp builds with no new warnings, git clang-format makes no changes and git diff --check passes.

🤖 Generated with Claude Code

Since a60f2db ("remember available atoms in clipboard") client formats are
only used if their atom was listed in the clipboard owner's TARGETS. When
the owner is another FreeRDP client, data is transferred as CF_RAW
(_FREERDP_RAW), which the owner never lists in TARGETS. The requester
therefore never found the CF_RAW format, sent an empty format data
response and pasting between two xfreerdp sessions stopped working.

Look up CF_RAW without the available-atom filter, both when sending the
selection request and when handling the reply.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@freerdp-bot

Copy link
Copy Markdown

Can one of the admins verify this patch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants