Clipboard isn't kept in copyq in KDE 6.5

[pallaswept]

Describe the bug
Copying to the copyq clipboard does not work in KDE 6.5 Wayland. The copied clip does seem to be available immediately, but it's not stored.

To Reproduce
Highlight this text, hit ctrl+c
Go somewhere you can paste it, hit ctrl+v
The text is pasted
Open copyq
The text is not in the list

Expected behavior
The text is in the list

Version, OS and Environment
CopyQ Clipboard Manager v13.0.0
Qt: 5.15.17
KNotifications: 5.116.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: openSUSE Tumbleweed

Additional context

I install this from your lovely OBS repository, thank you for maintaining that for us! It's been working flawlessly for a few years straight now, bravo!

I have not done much troubleshooting, I just discovered this, but I thought it would help to give as much advance notice as possible. I'll keep looking into it and let you know if I find anything.

Latest logs do not show any errors (these warnings are totally normal, I've always had them and they don't cause any problem)

[2025-10-25 13:15:37.794] Note : Starting server: CopyQ v13.0.0
[2025-10-25 13:18:34.771] Warning : [qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2025-10-25 14:06:56.031] Warning : [qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2025-10-25 14:07:18.562] Warning : [qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2025-10-25 14:08:04.324] Warning : [qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2025-10-25 14:08:11.780] Warning : [qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2025-10-25 14:15:26.080] Warning : [qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2025-10-25 14:18:00.554] Warning : [qt.qpa.wayland] Wayland does not support QWindow::requestActivate()

[pallaswept]

A bit more info: if I open copy and select File...Show Clipboard Content, it is correct and showing whatever I last copied. Pasting from the existing entries works. I checked that the wayland support command is up to date and it is. Running with xcb platform plugin environment variable did not change the behaviour.

[nikitosiusis]

Same here on kde neon after plasma update to 6.5.0 with copyq v13.0.0 from ppa

I think your comment about "The copied clip does seem to be available immediately" is quite confusing.
It is copied to kde clipboard, that's why it is available, but it never reaches the copyq (check meta+v).

They definitely mention some changes in the clipboard manager in 6.5.0 release notes, but I don't have an idea where to dig any further.

[pallaswept]

it never reaches the copyq (check meta+v).

Yeh it is confusing, it makes it into copyq, but doesn't make it to copyq's history (meta+v).

I've just been running copyq with debug logging enabled and when I copy, just nothing happens at all. It's not so much that the clipboard data can't reach copyq, it seems that copyq doesn't even try to read that data, because it doesn't know that it changed.

When we read it with Ctrl+Shift+c, there's no problem accessing it, it gets to copyq fine. It's the notification that it changed, that doesn't get there. Or, it gets there but copyq doesn't react as expected - but that seems unlikely since there's no debug messages about a failure. But the clip is available there in copyq, with ctrl+shift+c, immediately after it's taken.

I'm going to try and debug this but I am completely alien to this codebase so wish me all of the lucks and pray that hluk arrives :D

[pallaswept]

Just had a quick look at the code before I dove in and can already see something that might be missing in my debug logs - the clipboard owner changes don't seem to be detected. If I exit and restart copyq, with a delay so I can switch to any window, it will log that it set the owner of the clipboard to the active window when it starts, but I never see it change after that. Kinda implies that the owner is changing but copyq doesn't see it.

I'll drop breakpoints in the loops that check for updates on both these things and see what happens.

[pallaswept]

That was interesting, but not much. I can't get it to break on any of the callbacks. While I was in there I found a higher logging level (TRACE) and with that when I switch active app or copy, nothing is logged by that at all. It's just like nothing happened. Those callbacks appear as though they are supposed to be called by Qt, so I don't know why that's not happening.

I think I might have hit a wall with what I can contribute to this, sorry!

[pallaswept]

Hey I got it working!!

The answer was simple: build against Qt6
From what I can tell, only Fedora has Qt6 builds, but debian and suse and arch have qt5 builds... and something seems unhappy in qt5 land. The copyq changelogs from 12.0.0 say Qt5 builds are deprecated and since I lost track of the failure in Qt, I figured that newer Qt might sort it... and it did! 🎉

@hluk I have a working qt6 package here for opensuse if that's of any interest to you?

I'm about to tidy it up (it took a few hours of failing to get here and the spec file is evidence haha) and afterwards I will branch your OBS repo and push my changes to my branch, so they will be linked to you if you want to borrow from it and correct any mistakes I may have made... But it works!

Here's proof :)

Here's proof :)Here's proof :)Here's proof :)
Woohooo!

[hluk]

I have a working qt6 package here for opensuse if that's of any interest to you?

I use OpenSuse Build Service to build the packages: https://build.opensuse.org/package/show/home:lukho:copyq/CopyQ-Qt5

Isn't there a package in official repos for OpenSuse already? I would prefer not to maintain and build the packages myself. The only distro I use now is Fedora, and they already include the package.

For Ubuntu, I use files under debian/ in this repo and scripts utils/launchpad/run.sh and utils/debian/create_source_packages.sh to help publish the package on PPA.

[pallaswept]

Hi hluk! I mentioned that package above and thanked you for it, it's been a really nice thing to have, so thank you!

I understand that maintaining the package is a heavy load so it's fine if you can't do it any more.

Unfortunately, that build isn't working on KDE 6.5. The callbacks from Qt when the clipboard is updated, are never called. I had to make a new package against Qt6. which I branched from your repository. It is working well.

There is no package in the official repos yet, but I notice that another user has a repository where they have a better Qt6 RPM package than my one. Perhaps we can organise to push it to Factory and he and/or I can maintain it?

[xolve]

FWIW, a temporary workaround is to run copyq as QT_QPA_PLATFORM=xcb copyq, as mentioned in docs https://copyq.readthedocs.io/en/latest/known-issues.html#on-linux-global-shortcuts-pasting-or-clipboard-monitoring-does-not-work.

[pallaswept]

As mentioned above in this thread, that does not work. We needed to entirely repackage and rebuild the application.

Running with xcb platform plugin environment variable did not change the behaviour.