Created attachment 149914 [details] The first site shows, when it works after a reboot or smt, the second pictures shows, when I closed it and try to open it again. SUMMARY STEPS TO REPRODUCE 1. Create a panel and add a "Application launcher" widget 2. Click on the launcher twice (opens and closes) 3. Click on the launcher again OBSERVED RESULT It wont open, instead it only gets underlined, like it is opened, but it isn't. EXPECTED RESULT Open the application launcher normally. SOFTWARE/OS VERSIONS Linux: Arch (64 bit) Kernel: 5.15.48-1-lts KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 Graphics Platform: Wayland (Happens on X11 as well) ADDITIONAL INFO It started to happen, when updating to Plasma 5.25.0. It actually happens to all openable widgets in panels. (Did not try free widgets)
Sounds like one of those cases where double-click signal is emitted and handled weirdly even when no explicit/intentional handling was designed. It will auto-fix in Qt 6. I know several places / widgets / buttons in KDE/Plasma that suffer from this "bug". However, I'm struggling reproducing it on the "Application launcher" widget as you described.
(In reply to ratijas from comment #1) > Sounds like one of those cases where double-click signal is emitted and > handled weirdly even when no explicit/intentional handling was designed. It > will auto-fix in Qt 6. > > I know several places / widgets / buttons in KDE/Plasma that suffer from > this "bug". However, I'm struggling reproducing it on the "Application > launcher" widget as you described. Would be great, when it was fixed in QT 6. This bug is very annoying, since the only way to open applications is through the krunner. Things like the system tray can't be reached to take out applications and I have to start system monitor (through krunner) to search them in the process table. But thanks for trying to fix it.
(In reply to ratijas from comment #1) > Sounds like one of those cases where double-click signal is emitted and > handled weirdly even when no explicit/intentional handling was designed. It > will auto-fix in Qt 6. > > I know several places / widgets / buttons in KDE/Plasma that suffer from > this "bug". However, I'm struggling reproducing it on the "Application > launcher" widget as you described. When will Qt6 be available to use (I would join beta channels when possible)?
Before we confirm that this is indeed the same bug, could you please upload a video of you reproducing it, with a «Workspace Behavior» -> «Desktop Effects» -> «Mouse Click Animations» ON? Also try running plasmashell from a console window, and see if there are any suspicious warnings printed at the same time. > When will Qt6 be available to use (I would join beta channels when possible)? The porting work is ongoing, but I wouldn't expect it to be publicly distributed before the next year. If you are feeling adventurous, welcome to join developers/testers team! This page should get you started: https://community.kde.org/Get_Involved/development :)
Sure, I can send the video this evening. Right now I'm not home.
(In reply to ratijas from comment #4) > Before we confirm that this is indeed the same bug, could you please upload > a video of you reproducing it, with a «Workspace Behavior» -> «Desktop > Effects» -> «Mouse Click Animations» ON? Also try running plasmashell from a > console window, and see if there are any suspicious warnings printed at the > same time. Here is the requested video. The quality is questionable, but since I use wayland, screen capture is another thing. The bug is visible tho. https://youtu.be/2yJlhsFBLyE I'm checking now the command line.
When I start it from the terminal and click the menu the following messages are printed qt.qpa.wayland: Wayland does not support QWindow::requestActivate() kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_246(0x561ec6c90b20, name="popupWindow") kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_246(0x561ec6c90b20, name="popupWindow") kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_246(0x561ec6c90b20, name="popupWindow") When it became very laggy and I clicked to fast, sometimes: kwin_core: Could not find window with uuid "{bfd51821-b365-455f-979e-0b9949084ca9}" was printed as well.
Huh… in addition to Wayland-specific bug, there seems to be a race condition in the bookkeeping of `expanded` state of applets
(In reply to ratijas from comment #8) > Huh… in addition to Wayland-specific bug, there seems to be a race condition I just reinstalled my os and now it only happens on wayland, so I can use X11 to prevent it (luckily) Even when X11 is a bit old, it works until now. Hope I can switch back to wayland soon.
*** Bug 455276 has been marked as a duplicate of this bug. ***
*** Bug 456230 has been marked as a duplicate of this bug. ***
This is a really big and annoying regression and QT6 seems to be too far away. Is there anything that can be done to help debug this? Some patch or build flag with tons of debug/log messages? I can easily reproduce this bug on normal desktop usage.
Two extra findings on this: 1 - Tooltips (and thumbnails for windows) are not shown in this case (mouse hover) 2 - If I clear clipboard and disable my phone (KDE connect), this issue is really hard do reproduce on system tray (although it still easy to reproduce on app launcher) The moment I copy something and clipboard icon shows up in the tray the issue becomes much easier to reproduce like if it is stealing focus and actions?
(In reply to Marcelo Bossoni from comment #13) > Two extra findings on this: > 1 - Tooltips (and thumbnails for windows) are not shown in this case (mouse > hover) > 2 - If I clear clipboard and disable my phone (KDE connect), this issue is > really hard do reproduce on system tray (although it still easy to reproduce > on app launcher) > The moment I copy something and clipboard icon shows up in the tray the > issue becomes much easier to reproduce like if it is stealing focus and > actions? Or maybe this is just lucky because it received focus because of the right click...
Can you test if you also experience a hang in krunner while you type in it? It seems that the issue you described here (which I also experience) and the one with krunner both popped up in 5.25.
yeap, I do
I'm having the same problem since Plasma 5.25, but only on Wayland sessions. I had to fall back to X11 since. If I try to get through my day on Wayland, it eventually becomes impossible to open the start menu (or any other widget from the task bar, like calendar). I use KRunner instead of my start menu then, but that actually also stops working eventually! I then fall back to the new overview effect with Meta + W, which also has a KRunner-like input box. This always worked, since it is not a widget, I guess. Arch Linux Kernel: 5.18.10-zen1-1-zen (happens on default linux and lts kernel too) Plasma: 5.25.3 Frameworks: 5.96.0 Qt Version: 5.15.5 Nvidia drivers: 515.57 Graphics Platform: Wayland
I have the same problem, only with the Wayland session. Also it extends to all the widgets of the taskbar I've got. A temporary solution I've found is to reset Plasma kquitapp5 plasmashell then kstart5 plasmashell. It's clearly not perfect, but still, it solves the problem temporarily, before it happens again. this problem doesn't happen in the x11 session tho.
I have the same issue on Fedora 36. I only get it when using my NVIDIA eGPU as primary. When I use my Intel iGPU as primary, this issue doesn't happen. I have not tested this with X11. OS: Fedora 36 KDE Kernel: 5.18.11-200 KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.3 Graphics platform: Wayland NVIDIA Driver Version: 515.48.07 from the NVIDIA CUDA repo (not RPMFusion)
Also happens on my end. Nvidia GPU + Wayland. The application launcher doesn't show up half of the time and Krunner freezes after entering a few characters. X works fine, but isn't an option for me personally.
I can confirm this issue as Wayland specific. > A temporary solution I've found is to reset Plasma Yes. In my testings, killing plasmashell process and starting it again mitigates this bug. And not "until it happens next time", but until log out. So, there's something going on when plasmashell starts for the first time during Wayland session. Error messages on console are the same, but restarts are not glitched somehow. Jul 21 16:04:51 orange plasmashell[49983]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate() Jul 21 16:04:52 orange plasmashell[49983]: kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_24(0x557d0d675a30, name="popupWindow") Jul 21 16:04:52 orange plasmashell[49983]: kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_24(0x557d0d675a30, name="popupWindow") Jul 21 16:04:52 orange plasmashell[49983]: kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_24(0x557d0d675a30, name="popupWindow") I got logs of non-restarted plasmashell from journalctl, of course. Even after applets start disappearing, there's still a chance that they will appear after any next click. Plasma tooltips stop showing up randomly, and they seem to be unrelated to this bug. At least I haven't found any consistent pattern. Applets placed on a desktop are also affected by this glitch. Some times after interacting with Plasma panels and widgets for a while, it may stop responding (and KWin shades it with light gray). It may unfreeze though. It is NOT eating any noticable amount of CPU when it hangs like that. Once I attached gdb to a frozen Plasma, detached, and it unfroze. Might be unrelated though. Backtrace of frozen plasma (missing some symbols, I know): (gdb) bt f #0 0x00007f5c1aa13119 in () at /usr/lib/libc.so.6 #1 0x00007f5c1aa15920 in pthread_cond_wait () at /usr/lib/libc.so.6 #2 0x00007f5c1afbf744 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #3 0x00007f5c1d3104bd in () at /usr/lib/libQt5Quick.so.5 #4 0x00007f5c1b54da97 in QWindow::event(QEvent*) () at /usr/lib/libQt5Gui.so.5 #5 0x000055cde2e20cd3 in PanelView::event(QEvent*) (this=0x55cde4fa0ad0, e=0x7fffba33cea0) at /home/ratijas/kde/src/kde/workspace/plasma-workspace/shell/panelview.cpp:1124 #6 0x00007f5c1c013b3c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #7 0x00007f5c1b160ad8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #8 0x00007f5c1b541884 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () at /usr/lib/libQt5Gui.so.5 #9 0x00007f5c1b520935 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Gui.so.5 #10 0x00007f5c1a1f1fe5 in () at /usr/lib/libQt5WaylandClient.so.5 #11 0x00007f5c192efc6b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #12 0x00007f5c19346001 in () at /usr/lib/libglib-2.0.so.0 #13 0x00007f5c192ed392 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #14 0x00007f5c1b1ab32c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #15 0x00007f5c1b15927c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #16 0x00007f5c1b163da9 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #17 0x000055cde2e0a8a8 in main(int, char**) (argc=2, argv=0x7fffba33d428) at /home/ratijas/kde/src/kde/workspace/plasma-workspace/shell/main.cpp:243 qpaVariable = false app = <incomplete type> aboutData = {d = std::unique_ptr<class KAboutDataPrivate> = {get() = 0x55cde385da00}} replace = false corona = 0x55cde385c7d0 __PRETTY_FUNCTION__ = "int main(int, char**)" service = {<QObject> = {<No data fields>}, static staticMetaObject = {d = {superdata = {direct = 0x7f5c1b3de560 <QObject::staticMetaObject>}, stringdata = 0x7f5c1cf9e0c0 <qt_meta_stringdata_KDBusService>, data = 0x7f5c1cf9e360 <qt_meta_data_KDBusService>, static_metacall = 0x7f5c1cf89e5a <KDBusService::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, relatedMetaObjects = 0x0, extradata = 0x0}}, d = std::unique_ptr<class KDBusServicePrivate> = {get() = 0x55cde3865240}} (gdb) info threads Id Target Id Frame * 1 Thread 0x7f5c1674cac0 (LWP 5795) "plasmashell" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 2 Thread 0x7f5c15f45640 (LWP 5799) "WaylandEventThr" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 3 Thread 0x7f5c15744640 (LWP 5800) "WaylandEventThr" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 4 Thread 0x7f5c14e07640 (LWP 5801) "QDBusConnection" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 5 Thread 0x7f5c075ef640 (LWP 5828) "QQmlThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 6 Thread 0x7f5c0662f640 (LWP 5857) "Qt bearer threa" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 7 Thread 0x7f5bfcbe6640 (LWP 5956) "plasmashell" 0x00007f5c1aa925f1 in pselect () from /usr/lib/libc.so.6 8 Thread 0x7f5bef5ef640 (LWP 6078) "QQuickPixmapRea" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 9 Thread 0x7f5bdd8bc640 (LWP 6092) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 10 Thread 0x7f5bee5ed640 (LWP 6106) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 11 Thread 0x7f5bdd0bb640 (LWP 6107) "QSGRenderThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 12 Thread 0x7f5bdc8b5640 (LWP 6108) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 13 Thread 0x7f5bcb7c2640 (LWP 6185) "CPMMListener" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 14 Thread 0x7f5bca91a640 (LWP 6291) "KCupsConnection" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 15 Thread 0x7f5bba2f1640 (LWP 6299) "QSGRenderThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 16 Thread 0x7f5bbaaf2640 (LWP 6300) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 17 Thread 0x7f5bb9af0640 (LWP 6301) "QSGRenderThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 18 Thread 0x7f5bb92ea640 (LWP 6302) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 19 Thread 0x7f5bab7fe640 (LWP 6306) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 20 Thread 0x7f5babfff640 (LWP 6307) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 21 Thread 0x7f5baaffd640 (LWP 6308) "QSGRenderThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 22 Thread 0x7f5baa7fc640 (LWP 6309) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 23 Thread 0x7f5b87fff640 (LWP 6328) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 24 Thread 0x7f5b85afb640 (LWP 6357) "SessionThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 25 Thread 0x7f5b852fa640 (LWP 6358) "SessionThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 26 Thread 0x7f5b6cbf9640 (LWP 6534) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 27 Thread 0x7f5b86ffd640 (LWP 6606) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 28 Thread 0x7f5b5b7fe640 (LWP 6792) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 29 Thread 0x7f5b5abfd640 (LWP 7923) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 30 Thread 0x7f5b5bfff640 (LWP 8233) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 31 Thread 0x7f5b6dffc640 (LWP 8316) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 32 Thread 0x7f5b6ffff640 (LWP 8338) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 33 Thread 0x7f5b5a3fc640 (LWP 8364) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 34 Thread 0x7f5b6effd640 (LWP 8471) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 35 Thread 0x7f5b59bfb640 (LWP 8481) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6 36 Thread 0x7f5b2affd640 (LWP 8482) "QSGRenderThread" 0x00007f5c1aa8fc3f in poll () from /usr/lib/libc.so.6 37 Thread 0x7f5b6d7fb640 (LWP 8483) "QSGRenderThread" 0x00007f5c1aa13119 in ?? () from /usr/lib/libc.so.6
Plasma does go through a subtly different code path with a cold boot vs restart. See my sad conclusions in Bug 439159.
I can't reproduce this bug on my Arch and Fedora desktops, running KDE Frameworks 5.96.0 and Plasma 5.25.3. Does it also happen when logging in with a new account?
Yeap. Fresh user, first login, just played a bit and got the issue. Are you on nvidia? Maybe kwin/compositor is to blame and not plasma shell?(In reply to Bernie Innocenti from comment #23) > I can't reproduce this bug on my Arch and Fedora desktops, running KDE > Frameworks 5.96.0 and Plasma 5.25.3. > > Does it also happen when logging in with a new account? Yeap. Fresh user, first login, just played a bit and got the issue. Are you on nvidia? Maybe kwin/compositor is to blame and not plasma shell?
Created attachment 150882 [details] Fresh user, bug on application menu and tray icons
Can confirm that it is also happening on a completely fresh arch installation.
*** Bug 457543 has been marked as a duplicate of this bug. ***
Interesting. Tried wayland again after installing vulkan beta drivers on arch. For some reason it doesn't install gbm.so files needed for wayland. KDE/kwin ended up falling back to mesa LLVMpipe and I couldn't reproduce the bug there. So it really seems to be related to nvidia/kwin
I got the same issue on Gentoo, also with nvidia gpu. KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.96.0 QT Version: 5.15.5 Kernel Version: 5.19.1 Graphics Platform: Wayland I think I also got it when pressing the Meta key (which opens the Application Launcher for me).
Hi! I'ld also like to add my 2 cents here. Same situation: NVIDIA & Wayland. Symptom: Application Launcher not opening most of the time. Waiting a while before opening it again appears to help very often, and repeatedly clicking on it - clearly - not. General note: I would REALLY wish that I was able to say that I love to use nothing else than KDE Plasma for all it's AMAZING features and beauty, but the reality is that I am experiencing tooooooooooooo many bugs with it every time I use it. And of course, I can fall back to Xorg. But on Xorg it's so slow that I consider it unusable, especially with things like Application Launcher. Wayland is definitely the way to go!, it's the future. But sadly, as very much opposed to my Wayland experience with GNOME (same machine and both on Arch Linux - so the versions of the software are very new), the large number of bugs makes it very hard to use.
Hi, I recently installed Fedora 36 KDE Plasma. I'm also facing to the same bug, the Application Launcher is not always opening. NVidia driver has been installed, System upgraded and this bug seem to appear mainly with Wayland.
Having the same problems here. Starts out fine until I launch an application or two, either Steam or Brave or Signal Messenger. All of a sudden I can no longer launch the KDE Application Launcher unless I log out and log back in on X11. This is very frustrating and preventing me from using Wayland. Operating System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.6-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2 Manufacturer: ASUS
Quick update: Issue : - When double clicking quickly on the "Application launcher", it doesn't open as expected. Workaround : - The only way I found at the moment to open the "Application launcher", is to select an alternative Widget screenshot : https://userbase.kde.org/images.userbase/thumb/0/01/LauncherAlternatives.png/400px-LauncherAlternatives.png I'm not 100% sure, but it seems to be harder to repro with "Application Dashboard".
Hi! I think have the same or at least a similar issue. Sometimes I can't click on the application menu, icons in the system tray or the clock. I can see the blue "bar" and the hover effect but the popup does not open when you click. It usually works again if I keep clicking. Sometimes it stops working completely and I have to log out/in or restart plasmashell. I can't reproduce the issue by following the steps in this bug report, but if I just click on these icons/objects in the system tray it will happen randomly. I also use Wayland and a NVIDIA graphic card with their proprietary driver. I have the same issue on Fedora 36 and openSUSE Tumbleweed, both on completely fresh installations. I wish I could provide some more technical information but I'm not smart enough for that sadly. The output from plasmashell is the same when it works and doesn't work and it is the same output that has already been posted in this report. Operating System: openSUSE Tumbleweed 20220906 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.7-1-default (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-9700K CPU @ 3.60GHz Memory: 15,6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1080/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B17 System Version: 1.0 /Daniel
*** Bug 458851 has been marked as a duplicate of this bug. ***
I did a git bisect and found that https://invent.kde.org/plasma/plasma-workspace/-/commit/b68b59dac6f4b70acb56587dc74e3f121f72bc2e is what broke it on my hardware.
Thanks, that's very valuable info. This is starting to make sense because the init function that now no longer gets run includes a workaround for an upstream NVIDIA+Wayland bug, which re-exposed the upstream bug. So we have a few options for how to fix this: - Re-add the code that runs the workaround - Work around the upstream bug in a different way in KWin - Work with our NVIDIA contacts to try to get the upstream bug fixed... upstream! This is also a good lesson on the value of code comments. If any of those removed lines of code had a nearby comment saying "this includes workarounds for such-and-such bug; don't remove it unless they're fixed" then they might not have gotten removed as part of an innocent-looking refactor.
Would setting QSG_RENDER_LOOP=basic be enough as a workaround while bug is being worked on?
Should be.
Confirmed workaround work
Can confirm the cause. However, in current state it is no longer possible simply reverting that single MR: the init() function that was removed in it got subsequently deprecated and compile-disabled along with its whole class, so it would need patching back kdeclarative too.
I just compiled plasma-workspace based on the 5.25 branch without the specific commit (I used "git revert" (hint for some users who might not know how to do it)), and it seems to solve the issue for me. Thanks to Alexander Burnett for finding the commit. I hope that the KDE team could now include a fix.
I also managed to compile plasma-workspace (master) without the commit that Alexander found (I also had to revert c3b8430b in the kdeclarative repository for it to build) and it looks like it solves the issue for me as well. So does setting the environment variable QSG_RENDER_LOOP to basic like Marcelo mentioned. Thanks for the help so far, the wiki-page for "Get Involved/development" is great.
QSG_RENDER_LOOP=basic brings back another bug where panel items stop updating, like clock freezes at a certain time and list of running apps on task manager are out of sync with what is opened. (Closed applications are still shown and newly opened ones do not show on it). Only way to recover is to enter edit mode and move the panel to another screen corner. But this bug happens far less than the app menu not showing up.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/52
(In reply to Marcelo Bossoni from comment #44) > QSG_RENDER_LOOP=basic brings back another bug where panel items stop > updating, like clock freezes at a certain time and list of running apps on > task manager are out of sync with what is opened. (Closed applications are > still shown and newly opened ones do not show on it). > Only way to recover is to enter edit mode and move the panel to another > screen corner. But this bug happens far less than the app menu not showing > up. The freeze on wayland should have been fixed, at least I cannot reproduce it. What's your distro and Qt version?
Git commit 52bd3c9cc2a78e2ba8d87e09e01706d309720a6f by Vlad Zahorodnii. Committed on 13/09/2022 at 08:41. Pushed by vladz into branch 'master'. Bring back workaround for threaded render loop not working on NVIDIA Wayland For more details, check QTBUG-95817. But to summarize it in a couple of words: a window will stop pushing buffers when it's resized and using threaded render loop. M +13 -0 src/platformtheme/qtquickrenderersettings.cpp https://invent.kde.org/plasma/plasma-integration/commit/52bd3c9cc2a78e2ba8d87e09e01706d309720a6f
The workaround was added back, so I think it can be closed. Panel freezing seems unrelated. I recommend to create a new bug report to track that issue.
Just upgraded to the 5.25.90(5.26 beta) and this issue is still present unless I use - QSG_RENDER_LOOP=basic
(In reply to kodatarule from comment #49) > Just upgraded to the 5.25.90(5.26 beta) and this issue is still present > unless I use - QSG_RENDER_LOOP=basic Can you share your .config/kdeglobalsrc?
Correction: ~/.config/kdeglobals
(In reply to Vlad Zahorodnii from comment #51) > Correction: ~/.config/kdeglobals Yes here - https://pastebin.com/nkN6p8LK
Same problem here on beta. Fun fact: arch added this patch to 5.25.5-2 (https://github.com/archlinux/svntogit-packages/commit/c3af8a4b079f81ceb1aabad413539a77dd164e90) and it works. But moving to beta bring the problem back unless I set the loop to basic.
(In reply to Marcelo Bossoni from comment #53) > Same problem here on beta. > Fun fact: arch added this patch to 5.25.5-2 > (https://github.com/archlinux/svntogit-packages/commit/ > c3af8a4b079f81ceb1aabad413539a77dd164e90) and it works. > But moving to beta bring the problem back unless I set the loop to basic. Does not work for me going from beta back to it or just upgrading that package doesn't solve anything...
(In reply to Marcelo Bossoni from comment #38) > Would setting QSG_RENDER_LOOP=basic be enough as a workaround while bug is > being worked on? I can confirm: adding the QSG_RENDER_LOOP=basic environment variable (into .bash_profile for instance) solves the issue.
I tried the workaround, but the issue persists on my side. I added to my .bash_profile : QSG_RENDER_LOOP=basic then ```source .bash_profile``` I can see "QSG_RENDER_LOOP=basic" in my environment variables. The only way to stop this bug, is when I switch from "Application Launcher" to "Application Dashboard". Also the bug is mainly on Application Launcher and Menu, and it's pretty hard to repro on "Application Dashboard"
(In reply to Vlad Zahorodnii from comment #47) > Git commit 52bd3c9cc2a78e2ba8d87e09e01706d309720a6f by Vlad Zahorodnii. > Committed on 13/09/2022 at 08:41. > Pushed by vladz into branch 'master'. > > Bring back workaround for threaded render loop not working on NVIDIA Wayland > > For more details, check QTBUG-95817. But to summarize it in a couple of > words: a window will stop pushing buffers when it's resized and using > threaded render loop. > > M +13 -0 src/platformtheme/qtquickrenderersettings.cpp > > https://invent.kde.org/plasma/plasma-integration/commit/ > 52bd3c9cc2a78e2ba8d87e09e01706d309720a6f If anything this merge request seems to have fixed - https://bugs.kde.org/show_bug.cgi?id=455913 as I no longer have issues using krunner(but could also be helped with QSG_RENDER_LOOP=basic not too sure)
hi, this bug also affects me, i am also using a nvidia gfx-card (mobile), but i am not using Wayland but X11. so, are you sure, this only happens on wayland? whenever i click on the most top left desktop icon (Application Launcher), i can see the start-menu for about a quarter second, then it instantly closes again.
New to participating on KDE bugs. How can I pull or build the branch with the 5.26 patch in it for Arch linux and provide feedback or whether I can still reproduce the bug? Thanks!
On my system QSG_RENDER_LOOP is set to "basic" anyway. From the info on https://nobaraproject.org/ I learned today that this value is set by default if you are using NVIDIA's proprietary driver: "QSG_RENDER_LOOP=”basic” set for nvidia cards — fixes nouveau Wayland freezes. The nvidia proprietary driver sets this anyway after installation. This fixes the issue of KDE Wayland often times freezing on first login before nvidia proprietary drivers are installed." In other words: This fix is ONLY effective if you use Nouveau. If you experience the issues with the proprietary driver like me, something else is wrong that you probably cannot fix by yourself.
(In reply to Eduard from comment #60) > On my system QSG_RENDER_LOOP is set to "basic" anyway. > From the info on https://nobaraproject.org/ I learned today that this value > is set by default if you are using NVIDIA's proprietary driver: > "QSG_RENDER_LOOP=”basic” set for nvidia cards — fixes nouveau Wayland > freezes. The nvidia proprietary driver sets this anyway after installation. > This fixes the issue of KDE Wayland often times freezing on first login > before nvidia proprietary drivers are installed." > > In other words: This fix is ONLY effective if you use Nouveau. If you > experience the issues with the proprietary driver like me, something else is > wrong that you probably cannot fix by yourself. This fix is not only for Nouveau. Do not spread incomplete information. What one distro do is not what all of them do. QSG_RENDER_LOOP workaround works for proprietary driver as well.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/53
Git commit 97a2a802948d7ff91be6db564472d2c82286bd2f by David Edmundson. Committed on 21/09/2022 at 11:44. Pushed by davidedmundson into branch 'master'. Fix QtQuickRenderSettings from loading Currently the firstCall guard is broken and the code is never run. M +15 -2 src/platformtheme/qtquickrenderersettings.cpp https://invent.kde.org/plasma/plasma-integration/commit/97a2a802948d7ff91be6db564472d2c82286bd2f
Git commit 6ef5734ab8c4f354eb236269fa6cb22f8178cb53 by David Edmundson. Committed on 21/09/2022 at 14:04. Pushed by davidedmundson into branch 'cherry-pick-97a2a802'. Fix QtQuickRenderSettings from loading Currently the firstCall guard is broken and the code is never run. (cherry picked from commit 97a2a802948d7ff91be6db564472d2c82286bd2f) M +15 -2 src/platformtheme/qtquickrenderersettings.cpp https://invent.kde.org/plasma/plasma-integration/commit/6ef5734ab8c4f354eb236269fa6cb22f8178cb53
(In reply to David Edmundson from comment #63) > Git commit 97a2a802948d7ff91be6db564472d2c82286bd2f by David Edmundson. > Committed on 21/09/2022 at 11:44. > Pushed by davidedmundson into branch 'master'. > > Fix QtQuickRenderSettings from loading > > Currently the firstCall guard is broken and the code is never run. > > M +15 -2 src/platformtheme/qtquickrenderersettings.cpp > > https://invent.kde.org/plasma/plasma-integration/commit/ > 97a2a802948d7ff91be6db564472d2c82286bd2f Does this mean we don't need "QSG_RENDER_LOOP=basic" anymore? Thanks.
(In reply to keydieyeah from comment #65) > (In reply to David Edmundson from comment #63) > > Git commit 97a2a802948d7ff91be6db564472d2c82286bd2f by David Edmundson. > > Committed on 21/09/2022 at 11:44. > > Pushed by davidedmundson into branch 'master'. > > > > Fix QtQuickRenderSettings from loading > > > > Currently the firstCall guard is broken and the code is never run. > > > > M +15 -2 src/platformtheme/qtquickrenderersettings.cpp > > > > https://invent.kde.org/plasma/plasma-integration/commit/ > > 97a2a802948d7ff91be6db564472d2c82286bd2f > > Does this mean we don't need "QSG_RENDER_LOOP=basic" anymore? Thanks. I think it means we have to wait until the next plasma update, before we don't need the temp fix...
That's correct, but don't re-open closed bugs please.
*** Bug 459675 has been marked as a duplicate of this bug. ***
*** Bug 454671 has been marked as a duplicate of this bug. ***
In my case updating to the NVIDIA 535.113.01 driver (https://packages.ubuntu.com/nvidia-driver-535) solved the issue.