SUMMARY When a notification starts drawing (yes, it's a slow process here) and I'm using Firefox, both mouse and keyboard input are effectively blocked until the notification is displayed. When it's done drawing, the events get delivered, but the 3-4 second lag that it causes is annoying. STEPS TO REPRODUCE 1. Do something in Firefox 2. Receive a notification while typing OBSERVED RESULT The input is delayed until the notification finishes rendering EXPECTED RESULT The input continues as normal SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.2 KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2 Graphics Platform: X11
wat Is is causing the CPU to spike to 100% or something?
No, the resource usage seems to stay as usual...
*** This bug has been marked as a duplicate of bug 414785 ***
Reopening to keep it separate from the NVIDIA report, as people there seem to have high CPU load when notifications are displayed. I have an Intel iGPU.
I commented on the other bug, but this one resembles mine more: I have an NVIDIA GPU but it's switched-off and I only use my Intel iGPU. No CPU spike, and just one notification causes it. Doesn't happen only on Firefox for me though, happens with everything.
What Intel GPU specifically do you have? And what is the rendering method in System Settings > Display & Monitor > Compositor? Finally, can you open the hidden "Plasma Renderer" settings window by searching for "Plasma Renderer" in KRunner of Kickoff and opening it, and then mention what the values in the two comboboxes are?
Intel® Core™ i5-10210U, Intel® UHD Graphics (CometLake-U GT2), i915 driver OpenGL 3.1 Auto
Thanks. I have the same GPU and chipset (Comet lake) and the same plasma renderer settings. But I'm using OpenGL 2.0, which I believe is the default, rather than OpenGL 3.1, as you're using. I switched to OpenGL 3.1 but could not reproduce the lag when a notification appears. Can you try to change to 2.0 and see if the issue goes away?
I have an NVIDIA GeForce GTX 960M GPU (disabled with bbswitch) and Intel HD Graphics 530 iGPU (CPU is Intel i5-6300HQ). I'm also using OpenGL 3.1 and have Automatic in both the Plasma Renderer options. Changing compositor to use OpenGL 2.0 didn't fix the issue for me. However, that did inspire me to check disabling the compositor entirely, and that does fix the issue.
Thanks folks. Moving to KWin, as it seems related to compositing.
This is very easy to reproduce, in a konsole do: for i in 1 2 3 4 5 6 7 8 9 10; do notify-send --expire-time 20000 test $i;done With --expire-time 0 (no expiry at all) there seems to be no impact on CPU or responsiveness. So it appears to have something to do with the way expiry is implemented.
I haven't had this problem in a long time, so I will close this report
I have this problem every day and I don't understand why it can be closed just if one person hasn't seen it for some time. If one needs a recent reproduction scenario then please just ask.
I closed it because I'm the one who reported it in the first place, and there has been no activity in 3 years, which led me to think that no new users are experiencing this. I'm glad that you have found time to reopen it, but then please also update the fields with up-to-date version info.
Are you 100% positive it's the exact same issue? Including triggering steps as well as GPU hardware? Os so, updated reproduction steps would be appreciated If not, we need a new bug report to track it since it's a different issue. Thanks!
(In reply to Nate Graham from comment #15) > Are you 100% positive it's the exact same issue? Including triggering steps > as well as GPU hardware? Os so, updated reproduction steps would be > appreciated If not, we need a new bug report to track it since it's a > different issue. > > Thanks! It hasn't repeated recently. I've since updated the kernel, GPU, and various tumbleweed KDE packages, so I don't think I'll ever get to the bottom of it. I'll raise a new issue if anything similar reliably repeats.
I'm not 100 confident if my issue is the same bug. My freezes are not as long as the OP describes. Mine feel like just a few milliseconds. Thus I can't tell for sure if mouse and keyboard are affected, too. I realize it only when watching video which I mostly do using mpv. Video stops then until the popup is fully opaque. It does not freeze when popup disappears. Consecutive popups don't freeze. I sadly can't tell how long the timespan without popups has to be until the next one triggers it again. I only use Intel Graphics, the Nvidia Optimus one is too buggy on linux. System information: > # inxi -G > Graphics: > Device-1: Intel TigerLake-H GT1 [UHD Graphics] driver: i915 v: kernel > Device-2: NVIDIA TU117M [GeForce MX450] driver: nvidia v: 550.67 > Device-3: Sunplus Innovation Integrated_Webcam_HD driver: uvcvideo > type: USB > Device-4: Logitech StreamCam > driver: hid-generic,snd-usb-audio,usbhid,uvcvideo type: USB > Display: x11 server: X.Org v: 21.1.12 with: Xwayland v: 23.2.5 driver: X: > loaded: modesetting,nvidia dri: iris gpu: i915 resolution: 1: 1920x1080 > 2: 1920x1080 3: 1920x1080~60Hz > API: EGL v: 1.5 drivers: iris,nvidia,swrast > platforms: x11,surfaceless,device > API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: intel mesa v: 24.0.2-manjaro1.1 > renderer: Mesa Intel UHD Graphics (TGL GT1) > API: Vulkan v: 1.3.279 drivers: intel,nvidia surfaces: xcb,xlib chosen parts from mpv verbose output: > [vd] Looking at hwdec h264-vaapi... > [vo/gpu] Loading hwdec drivers for format: 'vaapi' > [vo/gpu] Loading hwdec driver 'vaapi' > [vo/gpu/vaapi] using EGL dmabuf interop > [vo/gpu/vaapi] Trying to open a x11 VA display... > [vo/gpu/vaapi/vaapi] Initialized VAAPI: version 1.20 > [vo/gpu/vaapi] Going to probe surface formats (may log bogus errors)... > [vo/gpu/vaapi] Done probing surface formats. > [...] > [vd] Using hardware decoding (vaapi). > [...] > [cplayer] VO: [gpu] 1920x1080 vaapi[nv12] vainfo shows: > vainfo: VA-API version: 1.20 (libva 2.20.1) > vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 24.1.3 () Compositing part from kinfocenter: > Compositing > =========== > Compositing is active > Compositing Type: OpenGL > OpenGL vendor string: Intel > OpenGL renderer string: Mesa Intel(R) UHD Graphics (TGL GT1) > OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.2-manjaro1.1 > OpenGL platform interface: GLX > OpenGL shading language version string: 4.60 > Driver: Intel > GPU class: Tiger Lake > OpenGL version: 4.6 > GLSL version: 4.60 > Mesa version: 24.0.2 > X server version: 1.21.1 > Linux kernel version: 6.6.25 > Direct rendering: Requires strict binding: yes > GLSL shaders: yes > Texture NPOT support: yes > Virtual Machine: no > OpenGL 2 Shaders are used
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!