Xpra: Ticket #877: clipboard hitting maximum requests per second limit

Xpra 0.15 from apt repository, running on Ubuntu 14.04 on both server and client (server 32 bit, client 64 bit). Copying from one forwarded app window to another one resulting in clipboard crashing.

Debugging message on server side log shows

2015-06-01 05:24:49,027 clipboard disabled: more than 10 clipboard requests per second!

I am running a clipboard manager called parcellite on the client side, but the bug is not present in 0.14.28, which works fine with parcellite after the earlier bug I reported in ticket #703 is resolved.



Tue, 02 Jun 2015 05:29:20 GMT - Antoine Martin: owner, description changed

There were NO changes whatsoever in the clipboard code between 0.14 and 0.15. Do you have sound enabled? (this did change)

It is possible that we are now handling clipboard requests faster than before, and therefore hitting the limit sooner. r9566 raises the default limit to 20 per second. I will backport to 0.15, until then you can raise the limit yourself with:

XPRA_CLIPBOARD_LIMIT=20 xpra start ...

Note: running a clipboard manager is always going to be a problem, these tools just really mess up the way the X11 clipboard was designed. Handling the clipboard is hard enough as it is, dealing with the somewhat broken behaviour from these tools is never going to be a high priority for us... sorry.


Tue, 02 Jun 2015 05:30:22 GMT - Antoine Martin: summary changed

(editing bug title)


Tue, 02 Jun 2015 17:55:41 GMT - Jiang:

I do have sound enabled.

I understand clipboard manager is a problem, so I understand that this may not be fixed completely. However, perhaps higher limit, perhaps even 40 or 50, may be helpful.

Is the limit set to prevent loops? If so, as you commented on the bug I filed for ticket #703, if there is indeed a true loop, the clipboard grow out of control and the limit will be hit very quickly however high the limit is. If there is no true loop, then the higher limit is more tolerant of normal behaviors.

Thanks for looking into this


Tue, 02 Jun 2015 18:01:18 GMT - Antoine Martin:

I do have sound enabled.


That explains it I think: I believe sound was acting as a rate-limiter for your clipboard requests until now by adding extra latency.

If there is no true loop, then the higher limit is more tolerant of normal behaviors


Unfortunately, that's not the case: you often just end up just crashing or making xpra so slow it becomes unusable. I think #812 may help here.


Wed, 03 Jun 2015 02:58:45 GMT - Jiang:

I understand your point better now. I think being able to adjust the limit myself via XPRA_CLIPBOARD_LIMIT is a great idea, because I can then adjust the value myself without having to bother the developers, particularly since I run a clipboard manager, a non-standard setup

I did not know that the option existed! Should I change the variable on the client or the server side? Is there some documentation, either in the manpage or on the website, about this? I could add something on the appropriate place once I find out how to do this, and by trial and error find a good limit for XPRA_CLIPBOARD_LIMIT.


Wed, 03 Jun 2015 04:41:07 GMT - Antoine Martin:

I have added more information on the wiki/Clipboard page (look under "Notes and Tuning"), feel free to suggest more edits.

I think we can close this ticket?


Wed, 03 Jun 2015 05:51:22 GMT - Jiang: status changed; resolution set

Sure. I'm too busy right now to check it (since I'm running a production system, I have to downgrade to 0.14 branch). I will check it after things calm down a bit on my end. At worst, I'll reopen the ticket if it turns out this is not the cause of the problem. Thank you again for helping!


Fri, 05 Jun 2015 09:00:22 GMT - Antoine Martin:

Could be related to #883.


Fri, 05 Jun 2015 18:18:02 GMT - Antoine Martin:

Applied to the v0.15.x branch in r9591.


Sat, 23 Jan 2021 05:08:35 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/877