RDM Mac 2026.2.3.1 replaces a local screenshot PNG with an unfulfillable TIFF promise, hanging all local paste receivers

Hello

I tried on my side but I wasn't able to reproduce the problem. I'm afraid the analysis you posted has some inaccuracies (probably guessed at by an LLM?) and unclear sources (for example, I'm not sure what the "unified macOS pasteboard log" is).

The best path forward is if you can:

1. Close RDM
2. Reopen RDM and enable Session Logging (Help > Session Logging)
3. Reproduce the issue
4. Locate the relevant log file back in the Session Logging window and send it to me by PM (you may need to .zip it first to attach it)
5. Restart RDM a further time to reset the session logging state

Please, let me know if something isn't clear or you have other questions

Kind regards

sent requested logs.

I did notice that it may be related to connecting to XRDP (Linux, Debian 13, XFCE) instead of just a regular windows 11.

Hello

Thanks for sending the log over.

So in the regular case when you "copy" an image (for example) on your Mac, macOS advertises that on the pasteboard in several formats for applications to choose from. For a screenshot, you'll get PNG and TIFF usually. RDM sees the local clipboard change and tells the RDP server(s) "these are the formats that are available". In this case, we support conversion to a Windows bitmap so that's the (only) format that we announce to the server (CF_DIB, device independent bitmap).

Usually that's where things end until someone pastes. If you paste on the server, at that point RDP actually requests the bytes from the clipboard, RDM fulfills them and converts to bitmap and sends over the wire, and the paste happens on Windows. This is "delayed" rendering - clipboard data is only transferred if you actually paste on the other side. It ensures data is only sent when needed, and only sent in the correct format.

What I see from your logs is, as soon as RDM tells the server "there's a bitmap on the clipboard", the server immediately requests the data (as though someone had pasted on that side). Then the server tells us "I have new formats on the pasteboard!" and advertises DIB, DIBv5 and a couple others. So it's like there's a synthetic paste-copy operation happening automatically on the server. It can be a third party software on the server, or as you suggest, maybe a quirk of xrdp.

Ok, so now the server told us "there are new clipboard formats" so, according to the protocol, RDM now updates the Mac's pasteboard with those new formats. We know how to go from DIB to TIFF, so we advertise TIFF on the clipboard. When you paste (in Slack, or whatever), we request the data from the server and try to convert it. That conversion is failing in an ungraceful way and is causing your hang.

So, two things here:

1. I need to make the conversion process more robust; whatever data xrdp is sending us either isn't a valid DIB or they're encoding it in a way that exposes a bug in our decoder. I can make it so it won't freeze the pasting application, but I likely won't be able to truly fix it without knowing what xrdp is sending here.
2. xrdp, or maybe a third-party program on a Winodws server, is behaving badly here. It doesn't seem reasonable to pull 5MB of data from the client machine clipboard as soon as it's copied, and it doesn't seem reasonable to perform a conversion on that data and then advertise it back to the client as new data. In effect; it's the server taking ownership of the local clipboard here, not RDM.

The second point might just be the way xrdp is; we could maybe work around it by trying to apply a heuristic around the format list it sends but that seems really fragile.

I'll work on fixing the freeze but what would be most helpful is to understand the server-side environment (is this only in xrdp as you suggest; what version you are running, etc); because without seeing exactly what data it's sending back to us after converting I won't be able to make this scenario actually work.

Please, let me know if something isn't clear or you have any questions

Kind regards,

I traced the XRDP session further.

Server: Debian 13, xrdp 0.10.1-3.1+deb13u1, XFCE.

A bpftrace trace of xrdp-chansrv’s X11 events shows the immediate request comes from `xfsettingsd` (PID 1582), not xrdp retrieving data merely because RDM announced CF_DIB.

`xfsettingsd` requests `TARGETS`, then `image/bmp` (plus PNG/JPEG/GIF). Its `image/bmp` request causes xrdp to send `CB_FORMAT_DATA_REQUEST(CF_DIB)` to RDM. `xfdesktop` only requested `TARGETS`.

So there is a concrete XFCE-side trigger for the immediate bitmap request. However, RDM should still avoid replacing the original local image with an unfulfillable TIFF promise or blocking local paste consumers if conversion fails.


I am going to see if I can disable `xfsettingsd` or turn off something over here to workaround it.

Hello

I'll open a ticket here and make it so a bitmap that we can't decode from the server won't hang the pasting client. But I won't be able to make the paste actually work unless I can reproduce on xrdp and see what kind of data it sends, so I'll work on that at the same time.

Kind regards,

I confirmed a working server-side workaround.

Debian 13/XFCE 4.20 runs `xfsettingsd`. It immediately requests every advertised image format, including `image/bmp`, which causes xrdp to request CF_DIB from RDM and triggers the clipboard round trip.

Disable only that clipboard component while leaving the rest of `xfsettingsd` running:

XFSETTINGSD_NO_CLIPBOARD=1 xfsettingsd --replace --daemon

After applying this, the `image/bmp` requests stopped. I repeated the same macOS screenshot test and pasted into Slack locally; it completed immediately without hanging.

To make this permanent, XFCE autostart entry can be overridden per user so that it runs:

env XFSETTINGSD_NO_CLIPBOARD=1 xfsettingsd

This is an effective workaround, although RDM should still handle failed DIB/TIFF conversion without leaving an unfulfilled pasteboard promise or blocking local applications.

Hello

Thanks for sharing the instructions for fixing the clipboard round-trip and confirming it prevents the hang.

As you wrote, clearly there are still issues with a failed bitmap to TIFF conversion; so I've made the following fixes:

• a failure here will now be handled gracefully; and immediately return an empty data object to the "pasting" application; so no more freeze
• at that time, we'll log some specific metadata about what was actually sent by the server
  • so, if you have trouble explicitly copying an image from xrdp, it should be sufficient to repeat the session logging exercise and we'll know better what's actually arriving
• that being said, I've also made the conversion more robust in general and better able to deal with different header formats

All those fixes will be part of 2026.2.4. Once that's available, please let me know if you still have an issue.

And don't hesitate with further questions or comments.

Kind regards,

Thanks!
I know AI can be troublesome with a lot of this. But I don't know if I would have found this without your help and its help.

It was just super frustrating to not be able to paste into applications if RDP was running with a Linux session inside!

Again, thanks!