SUMMARY Copy paste function does not work from wayland into x11 (xwayland) window after several minutes. STEPS TO REPRODUCE 1. Use Steam \ Discord for a bit, play a game under wine. 2. Try to copy image \ text from Wayland into X11 window. OBSERVED RESULT Does not paste. Xclip shows: Error: target STRING not available. EXPECTED RESULT Paste stuff. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION Using wl-clipboard from aur to have a workaround for that bug. When I'm copying stuff from x11 windows it starts working again till it doesn't after a min or two. Used xclip to track down bug.
Seems like it got fixed in update.
Seems like it was fixed in update. Will keep an eye on that.
Nah, still exists.
What specific app are you copying content from, and what specific app are you copying content into? Does it reproduce with both text and images?
Copying from Google Chrome or image from Spectacle into apps like Steam, Discord and games like Path of Exile and Dead by Daylight. Yes, both text and images.
Does the issue reproduce in a new clean user account on the same system? If it does, feel free to go back to your normal user account. And then let's test with some better-behaved apps, like copying from Spectacle's main window into Dolphin.
(In reply to Nate Graham from comment #6) > Does the issue reproduce in a new clean user account on the same system? > > If it does, feel free to go back to your normal user account. And then let's > test with some better-behaved apps, like copying from Spectacle's main > window into Dolphin. No, I just can't even reproduce it in my main account. Thing is that I'm using dual layouts, and when I tried to switch to another layout in new account I couldn't paste anything in any window, so it might be connected to my issue. I'll try to gather more information and if it fails I'll just remake my profile from scratch and try to go from there. Thanks for support.
So far I couldn't reproduce bug due to complication with catching it, but it still there. I used kwin debug console to track something and it printed this: TARGETS timeout reading from pipe SAVE_TARGETS timeout reading from pipe MULTIPLE timeout reading from pipe Even in a new user profile when I copy something from xorg application. Found related bugreport: https://bugs.kde.org/show_bug.cgi?id=433854 Should I just move my whole workflow and apps in new profile and see if it still appears, or is that a clue to problem?
ive had this issue for a long time. not sure about the xwayland part but it seems like i randomly wont be able to paste into electron apps. most of my apps are flatpaks and i know i dont have problems with pasting into system apps(kate) but do electron apps. its always fine after a fresh login but at some point of time or system suspensions i cant paste anymore until i log out/in. im sorry i cant narrow it down better than that but its extremely frustrating as most of my apps are flatpak'd electron apps 😭 i came here because i was searching for issues after it was happening again, and in a first for me, i was able to paste again w/o having to log out/in 🤷♂️ Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.11-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i7-5600U CPU @ 2.60GHz Memory: 11.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 5500
> Thing is that I'm using dual layouts First can you clarify what this means?
(In reply to Nate Graham from comment #10) > > Thing is that I'm using dual layouts > First can you clarify what this means? Two keyboard layouts with different languages.
In progress with https://invent.kde.org/plasma/kwin/-/merge_requests/6217.
Git commit 7e23386d46d8441d31a1e82c210179546ee6cae1 by David Edmundson. Committed on 10/08/2024 at 21:53. Pushed by davidedmundson into branch 'master'. xwayland: Drop outdated guard against clipboard races This guard was added as part of d335070b80c2f3bc5674355e3edba61bc010bc36. The guard as-is does not work correctly. If a client quits at the wrong point or simply never responds to the request for targets, we get into a stuck state where we will never update the clipboard from Wayland to X again until the selection owner changes. The guard appears to be outdated: The rationale given in the original MR was that it prevented a race where: 1. The X11 clipboard changes 2. We start fetching targets 3. We notify Wayland clients that the clipboard changed is now empty 4. Klipper replaces the clipboard 5. Kwin then replaces the X11 clipboard 6. X11 finishes fetching targets, but this is now discarded as there's a new X11 clipboard However we can not find a path for step 2 to happen in the current codebase. Potentially due to one of many refactors over the past few years. The wayland selection is only replaced when targets are fully loaded. The only way it could happen is if an X11 client replaced the clipboard by explicitly deleting the old selection first, but this also does not appear to happen in any tested apps. M +0 -10 src/xwayland/clipboard.cpp M +0 -1 src/xwayland/clipboard.h M +0 -10 src/xwayland/primary.cpp M +0 -1 src/xwayland/primary.h https://invent.kde.org/plasma/kwin/-/commit/7e23386d46d8441d31a1e82c210179546ee6cae1