Commit d205e6be does not explain what is wrong with nxagent's clipboard management

[xavierog]

The message for commit d205e6b clearly states:

--nxagent --clipboard: use clipboardrc instead of builtin clipboard

which indeed describes what happens in this commit.
However, both message and code fail at explaining why such a change is necessary or relevant. Could you please clarify?

Context: on multiple occasions, I found myself unable to copy/paste to/from the applications run through x11docker. My investigations are not complete yet (mainly because this usually happens right when I have other priorities), but I was surprised to notice that nxagent's seemingly interesting clipboard capabilities had been recently replaced with the clipboardrc mechanism.

[phil294]

I found myself unable to copy/paste to/from the applications run through x11docker

using which backend? on nxagent exclusively, too? Asking as I too once had my clipboard randomly stop working a few times, but with Xephyr only.

[xavierog]

using which backend? on nxagent exclusively, too?

Yes, my setup relies exclusively on nxagent.

[mviereck]

Thank you for the report!
I can confirm that occasionally the clipboard fails to work in x11docker beta.
I've rewritten the clipboard script some time ago to improve it, notable to support image clips, too.

I am not sure what exactly causes the issue. A suspicion: If more than one x11docker instance is running with --clipboard, and both read the clipboard content of the host X server at the very same time with xclip, one or both instances of xclip get a wrong result.

Currently there are two versions of clipboardrc included in the code, one of them is disabled.
I'll just switch them now; maybe that helps. However, if my suspicion above is right, the same issue might occur again.

(The clipboard content is repeatedly checked. This will hopefully be improved in future with a new xclip option to wait for clipboard changes. Compare astrand/xclip#134 (comment) ff.)

Please update and tell me if the issue has disappeared. I'll check here, too (no issue the last few hours).

However, both message and code fail at explaining why such a change is necessary or relevant. Could you please clarify?

IIRC nxagent does not support image clips while x11docker's clipboardrc does. However, I could just switch back to native nxagent clipboard for now until clipboardrc is fixed.
This would not fix issues with Xephyr because Xephyr does not have a clipboard option.

[xavierog]

IIRC nxagent does not support image clips.

Thank you for this clarification. Do not hesitate to comment the code accordingly in case someone else stumble upon the same interrogation.

As to clipboard problems: I confirm I run multiple applications with x11docker simultaneously. I have patched x11docker to leverage nxagent's capabilities instead of clipboardrc and intend to keep it this way for some time to ensure it works reliably (even if it is limited to text only).
In parallel, I am going to have a look at X11/clipboard/selection/xclip subtleties. Especially, I need to wrap my mind around what can and cannot be done in terms of "clipboard orchestration". I suspect that clipboard ownership and change monitoring are challenging parts.

[mviereck]

In parallel, I am going to have a look at X11/clipboard/selection/xclip subtleties. Especially, I need to wrap my mind around what can and cannot be done in terms of "clipboard orchestration". I suspect that clipboard ownership and change monitoring are challenging parts.

Some points I found so far:

• The clipboard content has an "owner" that provides it. The X server itself does not store the content. In case one sends content with xclip -in, xclip is the owner that runs in background until the content changes.
• Clipboard content can be provided in multiple formats. They can be seen with xclip -out -t TARGETS. For example, an image can be provided as image/jpg, image/png and many other formats at the same time. The format might be created not earlier than at the time the content is requested.
• xclip -in can provide only 1 target format at a time. xclip does not allow multiple targets.
• x11docker only supports targets UTF8_STRING and image/png. Other possible content, including e.g. videos, files, or formatted strings like HTML, is ignored. (UTF8_STRING is the default of xclip if no target is specified.)
• There are three clipboards (called selection):
  • One is called clipboard that is available with STRG-C/STRG-V or right click context menu copy/paste.
  • One is called primary that allows to select/highlight text and paste it with middle mouse click.
  • One is called secondary. No one uses it.
  • x11docker supports selections clipboard and primary.
• x11docker runs a loop (in current clipboardrc even 4 loops) to check for clipboard changes every half second. I hope for a new xclip -waitforchange option in ticket Orphaned subprocesses may cause command substitution to hang. astrand/xclip#134 (comment). This would avoid the sleep command and reduce cpu usage of the loops.

[mviereck]

Using the new clipboardrc since a week I don't have issues anymore.
I assume the bug is fixed.

[xavierog]

I read https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html -- it does a fairly good job explaining the complexity of the X11 copy/paste mechanisms without covering all the subtleties.
My first thought was "ideally, we need a copy/paste proxy able to deal with not just 2 but rather multiple X servers". And of course, this proxy could be instructed to block/allow copy/paste whenever relevant. The work achieved in the xclipglue project could help but this remains a pretty big, time-consuming project so I did not venture to start a prototype.

Instead, I went a little further with nxagent's copy/paste capabilities and submitted this PR that makes it possible to change nxagent's clipboard mode (none, client, server, both) on the fly: ArcticaProject/nx-libs#1047 -- alas, no feedback so far.

Thank you for the fix, I'll have a look at it.

[mviereck]

The work achieved in the xclipglue project could help but this remains a pretty big, time-consuming project so I did not venture to start a prototype.

xclipglue looks like a good matching tool. But it has severe issues that need a fix. It might be worth a try to contact the maintainer.
However, I decided to keep xclip because it is available everywhere, so I did not contact him.