Clipboard not working for images

[StrilGit]

xrdp version

0.10.0

Detailed xrdp version, build options

xrdp 0.10.0
A Remote Desktop Protocol Server.
Copyright (C) 2004-2024 Jay Sorg, Neutrino Labs, and all contributors.
See https://github.com/neutrinolabs/xrdp for more information.

Configure options:
--enable-fuse
--enable-jpeg
--enable-rfxcodec
--enable-mp3lame
--enable-vsock
--enable-painter

Compiled with OpenSSL 3.0.2 15 Mar 2022

Operating system & version

Ubuntu 22.04

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

xorgxrdp

What desktop environment do you use?

XFCE

Environment xrdp running on

VM

What's your client?

Microsoft MSTSC

Area(s) with issue?

Clipboard

Steps to reproduce

Copy Image (e.g. screenshot) on Windows. Paste in LibreOffice

✔️ Expected Behavior

Image should be pasted

❌ Actual Behavior

"The contents of the clipboard could not be pasted" --> Nothing inserted

Anything else?

When I am using the repository-version 0.9.17, the image is pasted without problems

[griffondemo]

Hello,

I would like to share some findings/issues we are facing with clipboard support and xrdp software. Please assess if this is an issue, a bug or if a possible workaround exists. Thank you for your support

We are facing exactly the same issue as StrilGit.

We have tested this feature on Ubuntu 22.04 & Ubuntu 24.04.

• On Ubuntu 22.04, we have compiled from source xrdp latest version (i.e. 0.10.x) and clipboard support is not working as expected

• On Ubuntu 24.04, we have used the package from Ubuntu Repository (0.9.24.x or 0.9.25.x) and clipboard support is not working as expected

The Clipboard feature seems broken starting with version xrdp 0.9.23.x.

If you compile from source xrdp package version 0.10.x, same behavior happens on Ubuntu 22.04 & Ubuntu 24.04, ie clipboard not working

Operating system & version
Ubuntu 22.04 and later

Installation method
pkg/Compile from source

Which backend do you use?
xorgxrdp

What desktop environment do you use?
Gnome Desktop

Environment xrdp running on
VM/ Physical machine

What's your client?
Microsoft MSTSC

Area(s) with issue?
Clipboard

Steps to reproduce
Copy Image (e.g. screenshot) on Windows. Paste in LibreOffice

✔️ Expected Behavior
Image should be pasted

❌ Actual Behavior
"The contents of the clipboard could not be pasted" --> Nothing inserted

Anything else?
On Ubuntu 22.04, using repo version 0.9.17, clipboard works
On Ubuntu 24.04, using repo version 0.9.24 (or 0.9.25), clipboard does not work
manually compiled version 0.9.17 ->0.9.22.x => Clipboard works
xrdp version >= 0.9.23.x => Clipboard function does not work anymore

[metalefty]

@griffondemo Thank you for the report, too. I will check the changes between 0.9.22 and 0.9.23.1.

[metalefty]

I think I reproduce it. I still not found the root cause though.

[metalefty]

This is probably an application-specific issue. I can paste from Windows to Linux gimp but cannot paste to LibreOffice.

[metalefty]

I recalled #1994 that client-to-server copy&paste doesn't work depending on the application to paste.

[metalefty]

An image copied from RDP client to xrdp server is held in clipboard like this:

$ xclip -selection clipboard -t TARGETS -o
TARGETS
TIMESTAMP
MULTIPLE
image/bmp

I use this image for test: https://commons.wikimedia.org/wiki/File:Felis_catus-cat_on_snow.jpg

To confirm if the issue is xrdp specific, copy an image to clipboard not using xrdp.

$ wget https://upload.wikimedia.org/wikipedia/commons/thumb/b/b6/Felis_catus-cat_on_snow.jpg/1200px-Felis_catus-cat_on_snow.jpg
$ xclip -selection clipboard -t "image/bmp" -i 1200px-Felis_catus-cat_on_snow.jpg

Paste in LibreOffice: not possible
Paste in GIMP: possible

Regardless of whether image data is copied via xrdp or not, LibreOffice cannot paste image data held as image/bmp. So this is not an xrdp issue but we may be possible to address the issue on xrdp side.

[metalefty]

xrdp v0.9.22.1 has the following clipboard. The difference is STRING and UTF8_STRING.

$ xclip -selection clipboard -t TARGETS -o
TARGETS
TIMESTAMP
MULTIPLE
STRING
UTF8_STRING
image/bmp

Probably this is a regression of #2766?

[matt335672]

I've had a look at this.

The pasting into Libre Office appears to be quite picky. The image you've got is a jpeg, but you're giving it a MIME type of bmp.

This works for me in Libre Office:-

xclip -selection clipboard -t "image/jpeg" -i 1200px-Felis_catus-cat_on_snow.jpg

Also, if I convert the image to a bmp using GIMP, I can insert it on the clipboard with:-

xclip -selection clipboard -t "image/bmp" -i 1200px-Felis_catus-cat_on_snow.bmp

That also pastes into Libre Office.

That doesn't answer the question of why having STRING or UTF8_STRING present would cause a difference.

On the latest devel snapshot I tried a screenshot and got this :-

$ xclip -selection clipboard -t TARGETS -o
TARGETS
TIMESTAMP
MULTIPLE
image/bmp

I couldn't paste the image into Libre Office.

On v0.9.22 I get this:-

$ xclip -selection clipboard -t TARGETS -o
TARGETS
TIMESTAMP
MULTIPLE
STRING
UTF8_STRING
image/bmp

I can paste the image into Libre Office. However, both of these commands hang (which is one of the #2766 fixes):-

xclip -selection clipboard -t STRING -o
xclip -selection clipboard -t UTF8_STRING -o

On both builds I then copied the image from the clipboard using xclip:-

xclip -selection clipboard -t image/bmp -o >devel.bmp  ;# devel build
xclip -selection clipboard -t image/bmp -o >works.bmp  ;# v0.9.22

The files are a little different:-

$ ls -l *.bmp
-rw-rw-r-- 1 aaa aaa 16588852 Jun 10 10:24 devel.bmp
-rw-rw-r-- 1 aaa aaa 16588866 Jun 10 11:37 works.bmp
$ file *.bmp
devel.bmp: PC bitmap, Windows 3.x format, 3840 x 1080 x 32, 3 compression, image size 16588800, cbSize 278, bits offset 54
works.bmp: PC bitmap, Windows 3.x format, 3840 x 1080 x 32, 3 compression, image size 16588800, cbSize 278, bits offset 54

Both files can be loaded by an image viewer. However, Libre Office cannot load devel.bmp.

I noticed that devel.bmp is smaller than works.bmp. I made a devel2.bmp which is the same size as works.bmp:-

$ ( cat devel.bmp ; echo -n "aaaaaaaaaaaaaa" ) >devel2.bmp

I CAN load devel2.bmp in Libre Office.

My conclusion is the clipboard code in devel is cutting the pasted image short somehow, and this is causing Libre Office to not load the bitmap.

[matt335672]

Quick clarification; in tha above, I'm loading the image files into Libre Office with Insert/Image.

Loading devel.bmp fails with:-

[metalefty]

Thanks for the clarification.

I think ImageMagick is a better tool for describing an image file. Indeed, the pasted image is corrupted and shortened.

$ xclip -selection clipboard -t image/bmp -o > /tmp/scr.bmp
$ identify /tmp/scr.bmp
identify: length and filesize do not match `/tmp/scr.bmp' @ error/bmp.c/ReadBMPImage/950.
identify: insufficient image data in file `/tmp/scr.bmp' @ error/bmp.c/ReadBMPImage/1127.

[metalefty]

There is another issue other than cut-off of data. The BMP image header is hardcoded but is incorrect compared to the specification.
https://en.wikipedia.org/wiki/BMP_file_format

It cannot be hardcoded because the whole file size is included in the BMP header. 4 bytes after 0x42, 0x4d must be the total image length than the hardcoded value 0x16, 0x01, 0x00, 0x00 (278) .

static char g_bmp_image_header[] =
{
    /* this is known to work */
    //0x42, 0x4d, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

    /* THIS IS BEING SENT BY WIN2008 */
    0x42, 0x4d, 0x16, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x36, 0x00, 0x00, 0x00
    //          ^^^^^^^^^^^^^^^^^^^^^^
    //          here is total data length
};

0x116 is 278 in decimal however it should be 16588854 = 3840 x 1080 x 32bit+ 14 (BMP file header) + 40 (BITMAPINFOHEADER).

devel.bmp: PC bitmap, Windows 3.x format, 3840 x 1080 x 32, 3 compression, image size 16588800, cbSize 278, bits offset 54
                                                                                                       ^^^
works.bmp: PC bitmap, Windows 3.x format, 3840 x 1080 x 32, 3 compression, image size 16588800, cbSize 278, bits offset 54
                                                                                                       ^^^

I see that the total data length is always 2 bytes shortened. v0.9.22 gives 12 bytes longer data than expected.

[matt335672]

Crossing messages here!

I think this bug was introduced in v0.9.24, not v0.9.23 with #2824.

@griffondemo appears to have tested with v0.9.22 and v0.9.24, but not v0.9.23 if I'm reading his message correctly.

The reason I think this, is that some of the code removed by #2824 included a hack to increase the sent data by 14 bytes, which is the length of a bitmap header:-

    if (req->target == g_image_bmp_atom)
    {
        incr_bytes += 14;
    }

This is a bit of a mess. Looking in clipboard_process_data_response_for_image() we copy the bitmap header and bitmap data into the g_clip_c2s structure, but set the length to be the data length only (i.e. 14 bytes short). This was then patched up later on.

If I add 14 to the length set in clipboard_process_data_response_for_image() I can paste images again in devel.

We absolutely should fix the header problem too I think.

[metalefty]

That makes sense v0.9.22 produces 12 bytes longer data. -2 bytes + another 14 bytes.

[griffondemo]

@matt335672

Regarding your comment about version 0.9.23.x, we have tried and test it as well. The copy/paste clipboard function with image was working with version 0.9.23.x. indeed. I missed to communicate this information in my initial report

We can confirm the behavior starting in 0.9.24 and later.... (no image copied over... )

As an additional comment/challenge/request, we have also users that are complaining that when the paste text from Libre Office from the local session and using xrdp clipboard to paste the text in the LibreOffice running in the remote session, all the text formatting get lost. This was already mentioned/discussed/reported in issue #3056

Since this behavior is also related to the clipboard code section, I wanted to report this specific situation as well. Since there might be code changes for the clipboard feature, maybe we can look into including the text copy/paste formatting enhancement feature as well ....

Again, here just an idea.... :)

Thank you for your support and for looking into this issue...

[matt335672]

@griffondemo - thanks for the additional information.

I'm aware that @metalefty is working on a fix for this particular issue at the moment. I think we'd like to keep #3056 separate as it's not entirely clear what the implications will be for implementing this at present.

[metalefty]

I think I have fixed the bmp file header issue. However, the bmp file with the correct header cannot be recognized by file utility.

The bmp file created by mspaint.exe @ Win 11 cannot be recognized by file utility as well. So it seems not an issue with the bitmap file header I made.

• Created by mspaint: xrdp-login.bmp.gz
• Copy & paste via xrdp: cat.bmp.gz

I'm waiting for the original reporter @StrilGit 's feedback in a private channel to go forward.

AlmaLinux 9

$ file --version
file-5.39
magic file from /etc/magic:/usr/share/misc/magic
$ sha256sum xrdp-login.bmp
5d0bd763d2aca01a3556745d2ead57b054393f9009efbdffeaed0a4d3120929a  xrdp-login.bmp
$ identify xrdp-login.bmp
xrdp-login.bmp BMP3 1920x1200 1920x1200+0+0 8-bit sRGB 6.59185MiB 0.010u 0:00.008
$ file xrdp-login.bmp
xrdp-login.bmp: data
$ xxd xrdp-login.bmp | head -4
00000000: 424d 3678 6900 0000 0000 3600 0000 2800  BM6xi.....6...(.
00000010: 0000 8007 0000 b004 0000 0100 1800 0000  ................
00000020: 0000 0078 6900 0000 0000 0000 0000 0000  ...xi...........
00000030: 0000 0000 0000 552f 0055 2f00 552f 0055  ......U/.U/.U/.U

FreeBSD 14

$ file --version
file-5.45
magic file from /usr/share/misc/magic
$ sha256sum xrdp-login.bmp
5d0bd763d2aca01a3556745d2ead57b054393f9009efbdffeaed0a4d3120929a  xrdp-login.bmp
$ identify xrdp-login.bmp
xrdp-login.bmp BMP3 1920x1200 1920x1200+0+0 8-bit sRGB 6.59185MiB 0.133u 0:00.129
$ file xrdp-login.bmp
xrdp-login.bmp: PC bitmap, Windows 3.x format, 1920 x 1200 x 24, image size 6912000, cbSize 6912054, bits offset 54
$ xxd xrdp-login.bmp | head -4
00000000: 424d 3678 6900 0000 0000 3600 0000 2800  BM6xi.....6...(.
00000010: 0000 8007 0000 b004 0000 0100 1800 0000  ................
00000020: 0000 0078 6900 0000 0000 0000 0000 0000  ...xi...........
00000030: 0000 0000 0000 552f 0055 2f00 552f 0055  ......U/.U/.U/.U

[matt335672]

That looks OK to me :-

Offset	Length	Comment
0	2	ASCII 'BM'
2	4	Hex 0x697836 (little-endian) = Decimal 6,912,054
6	2	Reserved (0)
8	2	Reserved (0)
10	4	Hex 0x36 (liitle-endian) = decimal 54
14	40	DIB header

If you can zip a small file up which file on Linux doesn't cope with, I'll see what file is actually doing.

[matt335672]

Oh sorry - you have. I'll take a look now.

[matt335672]

On Linux Mint 21.3 (based on Ubuntu 22.04):-

$ file cat.bmp
cat.bmp: PC bitmap, Windows 3.x format, 1200 x 800 x 32, image size 3840000, cbSize 3840054, bits offset 54

I don't have an Alma Linux 9 VM available, but on CentOS 8:-

$ file /tmp/cat.bmp 
/tmp/cat.bmp: PC bitmap, Windows 3.x format, 1200 x 800 x 32

I should really install Alma Linux on a VM. I'll kick off a download now.

[metalefty]

Surprisingly, file can recognize the bmp file if I modify file size field of the bmp file to 16010000 (and other values) using binary editor . Ubuntu 20.04 has file-5.38 which has the same issue with AlmaLinux 9. This is probably a bug of file utility already fixed in newer versions.

$ cat /etc/almalinux-release
AlmaLinux release 9.3 (Shamrock Pampas Cat)

$ file --version
file-5.39
magic file from /etc/magic:/usr/share/misc/magic

$ file cat-mspaint.bmp
cat-mspaint.bmp: PC bitmap, Windows 3.x format, 1200 x 800 x 24, image size 2880000, cbSize 278, bits offset 54

$ xxd cat-mspaint.bmp |head -4
00000000: 424d 1601 0000 0000 0000 3600 0000 2800  BM........6...(.
00000010: 0000 b004 0000 2003 0000 0100 1800 0000  ...... .........
00000020: 0000 00f2 2b00 0000 0000 0000 0000 0000  ....+...........
00000030: 0000 0000 0000 f4ef ecf5 f0ed f5f0 edf5  ................

[metalefty]

Probably fixed at this commit: file/file@03b6dcb

[matt335672]

Agreed.

If I copy the updated images file to /tmp/images on my Alma 9 VM:-

$ file -m /tmp/images /tmp/cat.bmp 
/tmp/images, 1246: Warning: EXTENSION type `	b_w/b&w' has bad char '&'
/tmp/cat.bmp: PC bitmap, Windows 3.x format, 1200 x 800 x 32, image size 3840000, cbSize 3840054, bits offset 54

[griffondemo]

@metalefty
Just providing some feedback here
We have recompiled the xrdp from source using your updated clipboard.c file and it seems that your latest commits allow now the copy of images to libreoffice apps. We have performed really basic testing so far. just wanted to provide again some inputs and feedback.. We will keep testing this if required...and provide feedback

Thank you for your support and for working on this issue..

[metalefty]

@griffondemo Thanks for the quick feedback. I am glad to hear now it works properly. I have added a tidy-up commit but it is functionally the same.