FreeRDP Latest: missing FormatListResponse breaks GNOME Remote Desktop -> Windows clipboard

# FreeRDP Latest: missing FormatListResponse breaks GNOME Remote Desktop -> Windows clipboard

Please route this to the team maintaining the RDM Windows FreeRDP integration. Server-side debugging identified an unacknowledged clipboard format list as the immediate cause of failed remote-to-local text transfers. A controlled server workaround restored both directions without switching away from FreeRDP or disabling dynamic resolution.

## Environment

- Client: Windows 11, Remote Desktop Manager.
- Reproduced with RDM 2026.3.10.0 and after downgrade to 2026.2.19.0 64-bit (JIT).
- RDP engine: FreeRDP Latest; clipboard redirection enabled; dynamic resolution enabled.
- Server: Fedora 44 x86_64, GNOME remote login with a user handover session.
- Server packages: gnome-remote-desktop 50.2-1.fc44; freerdp-libs 3.31.1-1.fc44; mutter and gnome-shell 50.5-1.fc44.

The FreeRDP library version above is the SERVER package version, not an identification of the DLL bundled with RDM.

## Reproduction and controls

1. Connect from RDM Windows using FreeRDP Latest to an unmodified GNOME Remote Desktop 50.2 server and sign into the desktop.
2. Copy a fresh plain-text marker on the remote desktop, then paste into a Windows text editor. No usable text is pasted.
3. Copy a different marker from Windows and paste remotely. This direction works.

The native Windows RDP client transfers text in both directions to the same server. RDM FreeRDP also transfers text in both directions to a separate Oracle Linux server. That server was not instrumented, so its reason for accepting the client behavior is unknown.

## Evidence and immediate failure mechanism

Stock GNOME diagnostic:

```text
[RDP.CLIPRDR] Possible protocol violation: Client did not send format list response (Timeout reached)
```

Custom GDB instrumentation of the actual GNOME user-session daemon captured:

```text
CLIPTRACE incoming FORMAT_DATA_REQUEST format=13
CLIPTRACE REJECT_DATA: requested MIME has not been acknowledged
```

These CLIPTRACE lines are instrumentation, not stock log messages or a packet capture. Format 13 is CF_UNICODETEXT.

GNOME keeps advertised formats in pending_server_formats until a positive CB_FORMAT_LIST_RESPONSE moves them to allowed_server_formats. The observed data request arrives without that acknowledgment having been processed, so request_server_format_data() returns CB_RESPONSE_FAIL before reading the Wayland clipboard content.

The public Devolutions implementation supports this diagnosis: cs_cliprdr_server_format_list() caches the advertised formats and requests text without calling ClientFormatListResponse. Its empty-list path also returns without a response. This was inspected in branches devolutions-rdp-3.24.0 and devolutions-rdp-3.31.1. We have not established that the installed RDM DLLs match either branch exactly; please confirm the shipped implementation.

- [Devolutions clipboard implementation](https://github.com/Devolutions/FreeRDP/blob/devolutions-rdp-3.31.1/DevolutionsRdp/clipboard.c)
- [GNOME Remote Desktop 50.2 implementation](https://github.com/GNOME/gnome-remote-desktop/blob/50.2/src/grd-clipboard-rdp.c)

## Controlled workaround validation

A temporary server-side compensation accepted only advertised, pending text formats. With it enabled, ASCII text transferred exactly in both directions; remote-to-local multiline Unicode text, including accented characters, also matched after CRLF/LF normalization. Removing the compensation caused a fresh remote-to-local marker to fail again at the same rejection branch.

An opt-in build of GNOME Remote Desktop 50.2 with that text-only workaround was then installed separately from the packaged daemon. The user confirmed normal clipboard behavior and dynamic resolution, and confirmed the fix still worked after a full server reboot on September 27, 2026.

The attached px13-clipboard-compat.patch is a GNOME SERVER workaround/proof of mechanism, not a tested RDM client patch. It is disabled unless GRD_RDP_TEXT_CLIPBOARD_IMPLICIT_ACK=1 and does not implicitly authorize image or file formats.