Feedback is needed on clipboard behavior

General Discussion
1

Dear Forum members.

I need feedback on clipboard behaviour on Qubes r4.2.3

I appreciate if anyone could try copying a text file over 256KiB to clipboard (in any qube) and then try to copy it to Global clipboard. You could create a text file large enough with something like this:

#!/bin/python
a = "x"*255 + "\n"
b = a*2048
print(b)

The output of the above python code will be 512KiB. Which you could pipe to a text file. And then try to open the text file in a text editor, copy it to clipboard (ctrl+c). Then copy to global clipboard (ctrl+shitf+c). I would like to know the output message from Global Clipboard widget.

Thanks in advance.

2

Global Clipboard
Clipboard content fetched from qube: ‘disp1234’
Copied 1 byte to the global clipboard.

1 Like
3

Oh. Yes. Many thanks.

Yet another bug to solve. cc @marmarek

p.s. The existing clipboard handling code is not INCR aware. And the patch I am making for issue 9296 is already very big. I will work on INCR later.

1 Like
4

For what it’s worth, I get a max. global clipboard size of 65000 bytes for clipboard sizes <= 256KiB
If the source is greater than 256KiB, apparently only one byte gets in. I write “apparently” because pasting that 1-byte global clipboard into a file results (consistently) in:

user@disp4949:~$ hexdump -C zzz.txt
00000000  c2 b1 0a                                          |...|
00000003

Note that I used vi and didn’t press anything but “Esc :wq” after pasting the global clipboard.
Buffer under-/over- flow? “c2 b1 0a” magic incantation? :smile:

1 Like
5

Yes. This is what I have been working on in last few days. Here is my analysis and further done the video & description of the solution:

And above 256KiB, X11 mechanism switches to a protocol known as INCR, communicating clipboard data in chunks of 256KiBs; Which originally Qubes OS devs did not consider during the early development of shared inter-vm clipboard. It turns out that it is also a known bug. But no one had the time to work on it:

2 Likes
6

BTW, this is the X11 Atom identifier for INCR. If you look at program 2 in this very useful article, you can find how to detect it in line:

    incr = XInternAtom(dpy, "INCR", False);
    if (type == incr)
    {
        printf("Data too large and INCR mechanism not implemented\n");
        return;
    }

If anyone is interested on INCR:
https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html

Another way which is/was used to deal with 256KiB limitation in X11:
https://www.x.org/releases/X11R7.7/doc/bigreqsproto/bigreq.html

1 Like
7

I noticed once before the 65000 byte limitation, and worked around it by writing to a file and using qvm-copy instead.

Thank you for explaining this behavior, and for taking time to work on a fix!
Really appreciated.

1 Like