clipboard copy fails with "Cannot set X11 selection owner" on qt6

wjr_

Since I switched to debian trixie (currently 13.3) I have a couple of apps where clipboard stops operating after a while.

Pinning down, it seems that "copy" (by menue, by ctrl-C) is broken.
A couple (sometimes even only one) copy actions succeed, but after a while, upon copy, in the logs or on the starting console I find message
QXcbClipboard::setMimeData: Cannot set X11 selection owner
Clipboard contains old content, so the copy has failed.
Repairing copy requires restarting the application.

Internet search reveals that this was a known issue back in qt5, but reported to be solved years ago.

However, in my case, all apps impacted are recent ("stable") builds on qt6:

Okular 25.04.2 using qt 6.8.2
Dolphin 25.04.3 using qt 6.8.2
MuseScore 4.6.5 (on AppImage) using qt 6.9.2

I may use evince to replace okular. I can restart dolphin and get a working instance that allows a couple of copies.

However, MuseScore gets close unusable, so I reported a bug there.
They recommended me to turn to qt:
https://github.com/musescore/MuseScore/issues/32172#issuecomment-3926451597

Before I report a bug here, I'd like to ask for some help to reproduce and pin the issue down.
The time until copy fails seems to be related to

workload of the app
my clipboard manager (currently qlipper)
pasting into a windows prog running under wine
images and app specific clipboard content

Since others can't reproduce, some peculiarities of my system:

upgraded from deb 12
running lxde now
tried KDE and Gnome, w/ and w/o wayland before
tried different clipboard managers before
btrfs with elaborated snap-backup, so I have some /var and /tmp subdir symlinked or bind-mounted to avoid cluttered backup

My guess is, however, that all those system pecularities just but "burden" on the clipboard, thus finding the error, not causing it. Most other applications run without issue.

IgKh

Welcome to the forum!

This forum is mostly for direct users of Qt - that is, authors of applications that use Qt as their direct dependency. Users of software written with Qt are usually advised to contact the authors of said software for help; they in turn can use resources such as this forum or the mailing lists for help. But it seems that you already did that in your case, and they declined to investigate.

It is not very likely that anyone here will be willing to do much without a small and self-contained C++ or Python program that can reliably reproduce the issue, and a bug report in Jira will be unlikely to gain traction without the same.

I can try a little though... the known issue you are referring to is probably https://qt-project.atlassian.net/browse/QTBUG-65145; but depending on the exact length of the "after a while" (assuming it is not 50 days) you are likely having a different but possibly similar issue.

The error message seen is related to the xcb_set_selection_owner call in the XCB API not being effective, and therefore Qt failing to gain ownership of the X11 clipboard (and this error is very X11 specific, so I find it hard to believe that running on native Wayland session doesn't work either). It might be that the clipboard manager or the window manager are interfering somehow, by already owning the clipboard with a newer timestamp. One thing you can try to collect more information, is to trace such calls with the x11trace program.

Good luck.

wjr_

the known issue you are referring to is probably https://qt-project.atlassian.net/browse/QTBUG-65145;

not really.
This particular one, I have ruled out already. Obviously it was related to a counter overflow after quite reproducable 50 days.
My clipbard fails after a couple of minutes, sometimes some hours, after restart of an application.

However, the fact that the problem there could be solved within qt gives weight to the assumption it might be a qt issue, in my case, again.

Just tried to recollect from my notes (including browser history).
May be a good start is here - I encountered this only after I found some other similiar issues

https://www.linuxquestions.org/questions/slackware-14/[bug]-copy-paste-from-qt5-applications-4175723946/

https://github.com/qtile/qtile/issues/1542
Do a duckduck search for
QXcbClipboard::setMimeData: Cannot set X11 selection own
There are many hits. See if any apply to you. Looks like a Qt bug.

Apparently, in those qt5 times, all those loosely related issues could be solved within qt.

this error is very X11 specific, so I find it hard to believe that running on native Wayland session doesn't work either

May be. But at least today, linux desktop still is X11.
I've stopped trying wayland on debian after less than half an hour - don't even remeber why, but far before I came to test applications with advanced clipboard usage.
May be, wayland can be the future. Soemtimes. But I don't think app developers do any favor to users and the very idea of linux by forcing users to such an immature thing.

Axel Spoerl

It's definitively not a bug in Qt and probably also not in MuseScore.
I have total sympathy for you. Not being able to write sheets would render the system unusable for me too.

The error message just says that the X11 clipboard doesn't allow the QT application to take ownership of the clipboard, i.e. write something into it.

Just for the record: Trixie is not an officially supported platform. It doesn't run in our CI. Qt may still work, actually even likely.

To narrow the issue down, please try the following:

Give Wayland another go and set QT_QPA_PLATFORM=wayland, to make sure MuseScore doesn't run on XWayland.
Eliminate Clipboard handlers. Typical suspects sticking on the clipboard are klipper, xfce4-clipman and copyq. The latter can be closed by copyq exit, the former ones need a kilall to stop. You can also restart them after killing them once.