If you don't move the mouse, it will stay stuck. Operating System: Arch Linux KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 47.0 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C94 System Version: 1.0
It's not clear to me what issue this is reporting. Can you attach a screen recording that shows it happening?
Created attachment 172919 [details] Screen recording of the problem Sorry for the late upload, this is a screen recording about the problem I encountered
Hi, this looks more like a global issue - it affect also your calendar panel, so it is not System Tray only. Unfortunately I cannot reproduce. I see you setup is heavily customized. Can you check if it works correctly: * on X11 * using fresh, newly created user If clean setup is good, then start adding customization until you can reproduce this issue.
(In reply to Konrad Materka from comment #3) > Hi, > > this looks more like a global issue - it affect also your calendar panel, so > it is not System Tray only. > > Unfortunately I cannot reproduce. I see you setup is heavily customized. Can > you check if it works correctly: > * on X11 > * using fresh, newly created user > If clean setup is good, then start adding customization until you can > reproduce this issue. Hi, thanks for helping with the problem I tried these two methods, but the problem did not reproduce, even if I configured the new user's environment to the old user's environment In addition, I made a new discovery. In the environment of old users, when I turned on several plug-ins for the calendar panel (Alternate Calender, Holidays, Calender Events), the calendar panel no longer got stuck, but the system tray problem still existed. My old user's desktop was upgraded from plasma5 to plasma6. Will this cause the problem?
It's possible there's some old config file entry that isn't being handled properly in Plasma 6. I know it's a lot to ask, but if there's any way you can try to figure out what it is, that would be really helpful!
(In reply to Nate Graham from comment #5) > It's possible there's some old config file entry that isn't being handled > properly in Plasma 6. I know it's a lot to ask, but if there's any way you > can try to figure out what it is, that would be really helpful! Hello, I tried to use the new user's configuration to restore the old user's configuration to find the problem, but I failed, The lag still existed. so I tried to get some system logs (via journalctl -f), and when I clicked on the system tray, I got the following information: plasmashell[70742]: kf.plasma.quick: location should be set before showing popup window plasmashell[70742]: kf.windowsystem.wayland: Failed to recreate shadow for PlasmaQuick::AppletPopup(0x5e682b9f69a0, name="popupWindow") plasmashell[70742]: qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0 When I clicked on the calendar and it got stuck, only the second and third lines were displayed. In addition, when I clicked on the application launcher (the system logo icon in the upper left corner), the same thing happens with calendar. It seems that the second line is more relevant to the problem. Do you think these logs will be helpful?
Very interesting. So far the "eglSwapBuffers failed with 0x300d, surface: 0x0" has been tracked at Bug 490813, which was found to be an NVIDIA driver bug. But I see from your system information that you have an AMD GPU. Is this accurate, or is there also a second NVIDIA GPU in the system?
Created attachment 173297 [details] attachment-2286463-0.html The system information is accurate, there is only one AMD GPU, no NVIDIA GPU. 获取Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ 发件人: Nate Graham <bugzilla_noreply@kde.org> 发送时间: 星期三, 九月 4, 2024 3:44:44 上午 收件人: voltkde@outlook.com <voltkde@outlook.com> 主题: [plasmashell] [Bug 491844] Show hidden icons gets stuck when there are no open windows on the desktop https://bugs.kde.org/show_bug.cgi?id=491844 --- Comment #7 from Nate Graham <nate@kde.org> --- Very interesting. So far the "eglSwapBuffers failed with 0x300d, surface: 0x0" has been tracked at Bug 490813, which was found to be an NVIDIA driver bug. But I see from your system information that you have an AMD GPU. Is this accurate, or is there also a second NVIDIA GPU in the system? -- You are receiving this mail because: You reported the bug.
Created attachment 173298 [details] attachment-2287241-0.html The system information is accurate, there is only one AMD GPU, no NVIDIA GPU.
OK, thanks.
(In reply to voltkde from comment #6) > I tried to use the new user's configuration to restore the old user's > configuration to find the problem, but I failed, The lag still existed. Sorry, I don't understand fully, could you clarify what do you mean by "but I failed, The lag still existed."? Does it mean you failed to reproduce issue in the new user? In which user lag still existed? Did you change KWin/Plasma renderer? You can check by running: kcmshell6 kcm_qtquicksettings If you were not able to reproduce using new user then that's kind of a good news - you can fix your old user by changing configuration (but which one?) or wiping it out entirely. If you were able to reproduce, that's kind of a good news as well: if you have time and will it should be possible to pinpoint abusive config. This might be tedious, because each manual config change (when you are replacing files) should be done when new user is not logged is not running, because KWin/Plasma/whatever can flush it's current config on shutdown.
(In reply to Konrad Materka from comment #11) > (In reply to voltkde from comment #6) > > I tried to use the new user's configuration to restore the old user's > > configuration to find the problem, but I failed, The lag still existed. > > Sorry, I don't understand fully, could you clarify what do you mean by "but > I failed, The lag still existed."? Does it mean you failed to reproduce > issue in the new user? In which user lag still existed? > > Did you change KWin/Plasma renderer? You can check by running: > kcmshell6 kcm_qtquicksettings > > If you were not able to reproduce using new user then that's kind of a good > news - you can fix your old user by changing configuration (but which one?) > or wiping it out entirely. > If you were able to reproduce, that's kind of a good news as well: if you > have time and will it should be possible to pinpoint abusive config. This > might be tedious, because each manual config change (when you are replacing > files) should be done when new user is not logged is not running, because > KWin/Plasma/whatever can flush it's current config on shutdown. My failure means that I did not solve the problem by replacing the new user's configuration file with the old user's configuration file. But I can currently solve the problem by changing the user. I have now switched to the new user's environment. This environment There is no problem.