[kwin] [Bug 489602] New: Mouse movement causes stuttering in PipeWire captured content
https://bugs.kde.org/show_bug.cgi?id=489602 Bug ID: 489602 Summary: Mouse movement causes stuttering in PipeWire captured content Classification: Plasma Product: kwin Version: 6.1.1 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: screencasting Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- Created attachment 171278 --> https://bugs.kde.org/attachment.cgi?id=171278&action=edit Demo capture SUMMARY When moving the mouse on a PipeWire captured display, its content stutters inside of the capture. However, the actual display output is smooth. This does not happen while the cursor is enlarged with shakecursor. STEPS TO REPRODUCE 1. Set 60Hz on the about-to-be-captured display 2. Launch OBS, use Screen Capture (PipeWire), enable Show Cursor, set OBS capture FPS to 60 3. Launch a fullscreen application, i.e. VRRTest 4. Enable VSync in the app, ensure it's rendering at the display's refresh rate 5. Start recording 6. Start moving the mouse slowly but steadily and keep at it for a while 7. Stop moving the mouse 8. Trigger shakecursor and keep it active for a while 9. Stop moving the mouse again 10. Stop recording OBSERVED RESULT The captured display's content stutters when the cursor is moving, but not while shakecursor is active (Also see the attached "Demo capture" video file) EXPECTED RESULT Nothing stutters at all SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.7.arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489602] Mouse movement causes stuttering in PipeWire captured content
https://bugs.kde.org/show_bug.cgi?id=489602 fililip changed: What|Removed |Added CC||t...@nitrosubs.live -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481716] KWin drops frames on nvidia (Wayland)
https://bugs.kde.org/show_bug.cgi?id=481716 --- Comment #3 from fililip --- I have observed something in dmesg when using the Nvidia card with KWin: [ 303.194078] [drm] [nvidia-drm] [GPU ID 0x0c00] Framebuffer memory not appropriate for scanout [ 303.194258] [drm] [nvidia-drm] [GPU ID 0x0c00] Framebuffer memory not appropriate for scanout -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481716] KWin drops frames on nvidia (Wayland)
https://bugs.kde.org/show_bug.cgi?id=481716 --- Comment #5 from fililip --- Only happens on startplasma-wayland with the env var or connecting a display to the nvidia card, gets displayed only two times, making apps fullscreen doesn't trigger it again. I just thought it's relevant to the stutters. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481716] KWin drops frames on nvidia (Wayland)
https://bugs.kde.org/show_bug.cgi?id=481716 --- Comment #8 from fililip --- > (which is not the case for Intel) Interesting. I did not have these problems on an Arc A750 at all, even though I was also doing dual-GPU back when I still had it. What's more, these stutters do not happen on gnome/xorg, but they do on kwin/xorg. They also happen in gamescope (so I doubt the MR you linked me to will do anything about it). Using the nvidia vulkan driver to render xwayland/native wayland games and presenting them on a screen plugged into the AMD card works just fine, I don't seem to exhibit the xwayland explicit sync issue even there. I also noticed very high CPU usage when compositing on the nvidia card, compared to when off-loading. This is probably the strangest part. I really hope this is an early adopter problem, as this is a new RTX 4070 Super, which was not even properly referred to as such by the nvidia driver (it said Unknown Graphics Device or something like that) before 550. The other thing is that it behaves the same way on nouveau, no improvement there (nouveau also seems not to support AMS and adaptive sync, that's interesting). I'll try to test the MR soon. If it doesn't fix it, I'll try getting in touch with Nvidia (since I assume there is nothing more you guys can do about it). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481716] KWin drops frames on nvidia (Wayland)
https://bugs.kde.org/show_bug.cgi?id=481716 fililip changed: What|Removed |Added Version|5.93.0 |6.0.0 --- Comment #9 from fililip --- Alright, I tested kwin from master today and the issue still seems to exist - very high (33-40%) one CPU thread usage & occasional stuttering when simply compositing with an app open (VRRTest). I've also tried blacklisting amdgpu, turning on/off 64-bit decoding in UEFI, there's nothing I can do to make it work. Additionally, I tested xfce4 (xorg), just for fun, and found out that it works just fine. I'd say this is definitely Nvidia's fault. They seem to have issues with Wayland compositing in general. (At least for me.) What's interesting is that using nouveau does not help. I'll try to report the issue upstream. If nothing gets fixed, that's not a big deal for me, I still have the AMD card for presentation. At least offloading works just fine, and I have CUDA support. Thank you very much for your effort and sorry for the trouble. (I have another observation: multi-monitor VRR doesn't seem to work with Nvidia. The stutters still happen with one screen (it's ok with fullscreen though, but the CPU usage is frustrating nonetheless), but VRR breaks completely for me if I attach my non-VRR secondary display to the mix. This is probably not related to the stuttering bug though, so feel free to close this one.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483240] New: VRR below 30-ish FPS turns off completely
https://bugs.kde.org/show_bug.cgi?id=483240 Bug ID: 483240 Summary: VRR below 30-ish FPS turns off completely Classification: Plasma Product: kwin Version: 6.0.1 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- SUMMARY Adaptive sync set to "Automatic" or "Always" does not work with content refreshing below 30 FPS (or close). This makes 24 FPS video content less pleasant to watch (than on Plasma 5), as LFC probably doesn't get a chance to kick in. This does not happen on Plasma 5. STEPS TO REPRODUCE Open up mpv with a 23.98 FPS video playing fullscreen or vkcube/vrrtest limited to 30 FPS. OBSERVED RESULT Video juddering/monitor OSD saying the screen actually refreshes at 165Hz (my refresh rate). EXPECTED RESULT LFC kicks in properly no matter what the refresh rate is. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.8-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION I assume this is due to one MR/issue I remember seeing on the Plasma GitLab one day about keeping a certain minimum refresh rate for content, which was introduced to eliminate screen flickering with some panels. My panel has never manifested such issues, I've never ever seen flickering no matter how weird the content refresh rate was and how often it was changing. Is there a way to override this behavior with some kind of envvar? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483240] VRR below 30-ish FPS turns off completely
https://bugs.kde.org/show_bug.cgi?id=483240 --- Comment #1 from fililip --- I should probably add that using the hardware cursor works fine (I was using the software one), but I'd personally prefer to have the option to retain even a low software cursor refresh rate anyway, or at least not have this behavior at all when I'm not moving the mouse. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483240] VRR below 30-ish FPS turns off completely
https://bugs.kde.org/show_bug.cgi?id=483240 --- Comment #3 from fililip --- Ok, thanks for the quick response! I appreciate it. I'll stick to the HW cursor for now then. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481688] New: KWin crashes when both Alt+F3 and Alt+F4 are pressed on a window
https://bugs.kde.org/show_bug.cgi?id=481688 Bug ID: 481688 Summary: KWin crashes when both Alt+F3 and Alt+F4 are pressed on a window Classification: Plasma Product: kwin Version: master Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- SUMMARY KWin crashes when both Alt + F3 and Alt + F4 are pressed on a window STEPS TO REPRODUCE 1. Focus a window 2. Attempt to open the window's 'context menu' (Alt + F3) while closing it (Alt + F4) OBSERVED RESULT The compositor crashes EXPECTED RESULT The compositor should not crash SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.0-rc5-1-mainline (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481688] KWin crashes when both Alt+F3 and Alt+F4 are pressed on a window
https://bugs.kde.org/show_bug.cgi?id=481688 --- Comment #1 from fililip --- One thing of note is that the issue goes away after unsetting the default Alt + F3 shortcut -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481688] KWin crashes when both Alt+F3 and Alt+F4 are pressed on a window
https://bugs.kde.org/show_bug.cgi?id=481688 --- Comment #3 from fililip --- kwin_wayland[3942]: ASSERT: "!window->isDeleted()" in file /usr/src/debug/kwin/kwin/src/focuschain.cpp, line 217 systemd-coredump[78293]: Process 3942 (kwin_wayland) of user 1000 dumped core. Stack trace of thread 3942: #0 0x7fd00a6ab32c n/a (libc.so.6 + 0x8d32c) #1 0x7fd00a65a6c8 raise (libc.so.6 + 0x3c6c8) #2 0x7fd00a6424b8 abort (libc.so.6 + 0x244b8) #3 0x7fd00ac8a924 n/a (libQt6Core.so.6 + 0x8a924) #4 0x7fd00ac8b135 _ZNK14QMessageLogger5fatalEPKcz (libQt6Core.so.6 + 0x8b135) #5 0x7fd00ac89770 _Z9qt_assertPKcS0_i (libQt6Core.so.6 + 0x89770) #6 0x7fd00d3b4594 n/a (libkwin.so.6 + 0x1b4594) #7 0x7fd00d3b4432 n/a (libkwin.so.6 + 0x1b4432) #8 0x7fd00d5ee88a _ZN4KWin6Window16updateActivitiesEb (libkwin.so.6 + 0x3ee88a) #9 0x7fd00d627212 _ZN4KWin9X11Window16updateActivitiesEb (libkwin.so.6 + 0x427212) #10 0x7fd00d5beccd _ZN4KWin15UserActionsMenu15menuAboutToHideEv (libkwin.so.6 + 0x3beccd) #11 0x7fd00ad7c2c7 _ZN7QObject5eventEP6QEvent (libQt6Core.so.6 + 0x17c2c7) #12 0x7fd00bcf438b _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt6Widgets.so.6 + 0xf438b) #13 0x7fd00ad39818 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt6Core.so.6 + 0x139818) #14 0x7fd00ad39b9b _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt6Core.so.6 + 0x139b9b) #15 0x7fd00ae9f18f _ZN20QEventDispatcherUNIX13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x29f18f) #16 0x7fd00b7b26e2 _ZN23QUnixEventDispatcherQPA13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Gui.so.6 + 0x5b26e2) #17 0x7fd00ad43d6e _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x143d6e) #18 0x7fd00ad3c2b8 _ZN16QCoreApplication4execEv (libQt6Core.so.6 + 0x13c2b8) #19 0x561cdf4f427a n/a (kwin_wayland + 0x5927a) #20 0x7fd00a643cd0 n/a (libc.so.6 + 0x25cd0) #21 0x7fd00a643d8a __libc_start_main (libc.so.6 + 0x25d8a) #22 0x561cdf4fae55 n/a (kwin_wayland + 0x5fe55) Stack trace of thread 3980: #0 0x7fd00a6a5ebe n/a (libc.so.6 + 0x87ebe) #1 0x7fd00a6a8750 pthread_cond_wait (libc.so.6 + 0x8a750) #2 0x7fcffdf11f5e n/a (radeonsi_dri.so + 0x111f5e) #3 0x7fcffdef1a0c n/a (radeonsi_dri.so + 0xf1a0c) #4 0x7fcffdf11e8c n/a (radeonsi_dri.so + 0x111e8c) #5 0x7fd00a6a955a n/a (libc.so.6 + 0x8b55a) #6 0x7fd00a726a3c n/a (libc.so.6 + 0x108a3c) Stack trace of thread 3982: #0 0x7fd00a6a5ebe n/a (libc.so.6 + 0x87ebe) #1 0x7fd00a6a8750 pthread_cond_wait (libc.so.6 + 0x8a750) #2 0x7fcffdf11f5e n/a (radeonsi_dri.so + 0x111f5e) #3 0x7fcffdef1a0c n/a (radeonsi_dri.so + 0xf1a0c) #4 0x7fcffdf11e8c n/a (radeonsi_dri.so + 0x111e8c) #5 0x7fd00a6a955a n/a (libc.so.6 + 0x8b55a) #6 0x7fd00a726a3c n/a (libc.so.6 + 0x108a3c) Stack trace of thread 4031:
[kwin] [Bug 481688] KWin crashes when both Alt+F3 and Alt+F4 are pressed on a window
https://bugs.kde.org/show_bug.cgi?id=481688 --- Comment #4 from fililip --- Thread 1 "kwin_wayland" received signal SIGABRT, Aborted. 0x7f5a1b6ab32c in ?? () from /usr/lib/libc.so.6 Thread 39 (Thread 0x7f5991a006c0 (LWP 89386) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 38 (Thread 0x7f5992e006c0 (LWP 89384) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 37 (Thread 0x7f5993e006c0 (LWP 89381) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 36 (Thread 0x7f599cc006c0 (LWP 89368) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 35 (Thread 0x7f599d6006c0 (LWP 89367) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 34 (Thread 0x7f599e0006c0 (LWP 89366) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 33 (Thread 0x7f599ea006c0 (LWP 89365) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 32 (Thread 0x7f599f4006c0 (LWP 89364) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/libc.so.6 #6 0x7f5a1b726a3c in ??? () at /usr/lib/libc.so.6 Thread 31 (Thread 0x7f599fe006c0 (LWP 89363) "Thread (pooled)"): #0 0x7f5a1b6a5ebe in ??? () at /usr/lib/libc.so.6 #1 0x7f5a1b6a8a65 in pthread_cond_timedwait () at /usr/lib/libc.so.6 #2 0x7f5a1bea3ba4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6 #3 0x7f5a1bea64aa in ??? () at /usr/lib/libQt6Core.so.6 #4 0x7f5a1bea0bd3 in ??? () at /usr/lib/libQt6Core.so.6 #5 0x7f5a1b6a955a in ??? () at /usr/lib/lib
[kwin] [Bug 481688] KWin crashes when both Alt+F3 and Alt+F4 are pressed on a window
https://bugs.kde.org/show_bug.cgi?id=481688 --- Comment #5 from fililip --- Note: this only seems to affect xwayland apps. Native wayland ones don't have this issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481716] New: KWin drops frames on nvidia (Wayland)
https://bugs.kde.org/show_bug.cgi?id=481716 Bug ID: 481716 Summary: KWin drops frames on nvidia (Wayland) Classification: Plasma Product: kwin Version: 5.93.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- SUMMARY There seem to be weird frame drops when using KWin on an Nvidia dGPU (on Wayland). Adaptive sync on/off doesn't matter. STEPS TO REPRODUCE 1. Move the cursor in a circular fashion or 2. Launch testufo.com OBSERVED RESULT In the case of cursor motion, there are "dropped" cursor images (persistent vision; better visible on 120Hz+). With UFOTest, stuttering is noticeable. (Does not happen on AMD/Intel) EXPECTED RESULT Everything should be smooth. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.7.0 Kernel Version: 6.7.5-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION I use the nvidia-open-beta modules and nvidia-utils-beta (550.40.07) because my GPU does not work on 545 (too old drivers). KWin was launched with the DRM device env var set to just the nvidia card (/dev/dri/card1, since I also have an AMD GPU in my PC). Is this something that can be fixed in KWin or is it an nvidia specific bug? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481716] KWin drops frames on nvidia (Wayland)
https://bugs.kde.org/show_bug.cgi?id=481716 --- Comment #1 from fililip --- Note: I set my CPU frequency to 1750MHz minimum, now the framedropping doesn't occur with cursor motion, but there are observable CPU usage spikes on one thread when anything's happening on the screen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481716] KWin drops frames on nvidia (Wayland)
https://bugs.kde.org/show_bug.cgi?id=481716 --- Comment #2 from fililip --- The stutters still occur on Plasma 6.0.0. Will the explicit sync protocol address this? (I do not have a problem with apps glitching out on xwayland, just desktop wide stutters, even in native Wayland apps.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486081] New: Frame swapping in WebRTC screensharing while moving the mouse
https://bugs.kde.org/show_bug.cgi?id=486081 Bug ID: 486081 Summary: Frame swapping in WebRTC screensharing while moving the mouse Classification: Plasma Product: kwin Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- SUMMARY Screensharing using browsers (Firefox, Chromium, as well as things like Electron) / WebRTC swaps frames on the stream when mouse movement is performed. However, OBS Studio and Spectacle work fine regardless if the pointer is being moved or not. STEPS TO REPRODUCE 1. Go to a website like https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia and share the entire desktop 2. Open an app that constantly updates in the background (like vkcube or VRRTest) 3. Look at the browser preview and move the cursor around OBSERVED RESULT The preview in the browser has weird frame pacing issues EXPECTED RESULT The preview in the browser displays frames in proper order, just like OBS and Spectacle do SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.4 (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 6600 XT ADDITIONAL INFORMATION KWin 6.0.2 does not have this issue, this seems to be a regression in 6.0.3 or 6.0.4. Additionally, if by any chance the cursor does not get shown in the preview after screencasting is turned on (happened to me once), it seems to work fine too. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486081] Frame swapping in WebRTC screensharing while moving the mouse
https://bugs.kde.org/show_bug.cgi?id=486081 --- Comment #2 from fililip --- I've noticed one more thing. Going to https://mozilla.github.io/webrtc-landing/gum_test.html and setting a high FPS value (like 60 or even 120) results in the "FPS now" metric severely dropping while moving the mouse. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added Summary|Running Steam breaks|Running Steam causes KWin's |always-on VRR on desktop, |CPU usage to always |forcing full refresh rate |increase and breaks ||always-on VRR on desktop Version|6.0.3 |6.0.4 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #1 from fililip --- I've also observed much higher CPU usage with KWin while idle. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #3 from fililip --- Do you exhibit the CPU usage issue though? On my system, kwin_wayland's CPU usage increases by around 8% even after Steam is terminated. Restarting KWin helps. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #4 from fililip --- I've just checked it with the Show Paint effect: before Steam has ever been opened during a session on an empty desktop everything is fine. After Steam has run at least once, the effect constantly triggers, even on the secondary screen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #5 from fililip --- Running Steam in gamescope seems to mitigate this problem. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #6 from fililip --- Oh, alright, suspecting that it might be relevant, I unloaded the nvidia driver and removed the card from the PCI tree on my PC, everything is 100% fine now. I do wonder what Steam is doing with nvidia that is causing this though. Regular PRIME offloading does not trigger this, only Steam seems to do so. Sorry for the trouble! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #7 from fililip --- One final note though, to whom it may concern: on AMD/NVIDIA systems launching Steam has to be done like so: VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json steam This also works. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #8 from fililip --- Ah, unfortunately not - I still had the nvidia driver unloaded. The Vulkan driver choice doesn't seem to matter. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam causes KWin's CPU usage to always increase and breaks always-on VRR on desktop
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #9 from fililip --- I reported the issue to the Steam issue tracker too: https://github.com/ValveSoftware/steam-for-linux/issues/10847 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam on AMD+NVIDIA forces fullscreen repaints for the rest of the session all the time
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added Summary|Running Steam causes KWin's |Running Steam on AMD+NVIDIA |CPU usage to always |forces fullscreen repaints |increase and breaks |for the rest of the session |always-on VRR on desktop|all the time -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483240] VRR below 30-ish FPS turns off completely
https://bugs.kde.org/show_bug.cgi?id=483240
--- Comment #5 from fililip ---
I managed to add an option to override this behavior with an environment
variable, LFC finally works as it did before.
diff --git a/src/core/renderloop.cpp b/src/core/renderloop.cpp
index 5e3a74c..de7b7d3 100644
--- a/src/core/renderloop.cpp
+++ b/src/core/renderloop.cpp
@@ -201,10 +201,12 @@ void RenderLoop::scheduleRepaint(Item *item)
if (d->pendingRepaint) {
return;
}
+bool isEnvVarSet = false;
+const bool forceKernelLFC =
qEnvironmentVariableIntValue("KWIN_FORCE_KERNEL_LFC", &isEnvVarSet) != 0 &&
isEnvVarSet;
const bool vrr = d->presentationMode == PresentationMode::AdaptiveSync ||
d->presentationMode == PresentationMode::AdaptiveAsync;
if (vrr && workspace()->activeWindow() && d->output) {
Window *const activeWindow = workspace()->activeWindow();
-if (activeWindow->isOnOutput(d->output) && activeWindow->surfaceItem()
&& item != activeWindow->surfaceItem() &&
activeWindow->surfaceItem()->frameTimeEstimation() <=
std::chrono::nanoseconds(1'000'000'000) / 30) {
+if (activeWindow->isOnOutput(d->output) && activeWindow->surfaceItem()
&& item != activeWindow->surfaceItem() && !forceKernelLFC &&
activeWindow->surfaceItem()->frameTimeEstimation() <=
std::chrono::nanoseconds(1'000'000'000) / 30) {
return;
}
}
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 485425] New: Running Steam breaks always-on VRR on desktop, forcing full refresh rate
https://bugs.kde.org/show_bug.cgi?id=485425 Bug ID: 485425 Summary: Running Steam breaks always-on VRR on desktop, forcing full refresh rate Classification: Plasma Product: kwin Version: 6.0.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- SUMMARY After running Steam at least once on a KWin session, always-on VRR for desktop breaks entirely, forcing the full refresh rate at all times. Closing Steam, hotplugging the display and/or killing Xwayland after that don't seem to help. Fullscreen VRR for applications continues to work though. STEPS TO REPRODUCE 1. Launch Steam OBSERVED RESULT Desktop VRR is effectively disabled EXPECTED RESULT Desktop VRR still works SOFTWARE/OS VERSIONS KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.5.arch1-1 (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483240] VRR below 30-ish FPS turns off completely
https://bugs.kde.org/show_bug.cgi?id=483240 --- Comment #4 from fililip --- One note I'll add: after resuming from suspend, even when using the HW cursor, VRR still breaks below 30 FPS and requires a restart of KWin. Is this just random behavior or a bug? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 fililip changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #10 from fililip --- This is no longer an issue as of 6.0.2. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322
fililip changed:
What|Removed |Added
Status|RESOLVED|REPORTED
Ever confirmed|1 |0
Resolution|FIXED |---
--- Comment #11 from fililip ---
Oops, unfortunately not, I ran into this issue again after I wrote a fragment
shader that times out the GPU:
float t = mix(0.0, 1.0, sdf);
for (float i = 0.0; i < 7.0; i += 0.01) {
t += distance(gl_FragCoord.xy, aspect);
}
I had VSCode (Xwayland) open and while the reset succeeded, KWin was completely
stuck and I had to kill it.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 479845] The current Wayland GPU recovery experience (AMD) is not ideal with AMS disabled
https://bugs.kde.org/show_bug.cgi?id=479845 --- Comment #7 from fililip --- Personally, I don't think there's a point to maintaining legacy modesetting (even if there's still no tearing support for atomic), unless it's actually used on some devices (it's great for my non-VRR laptop; with a 60Hz display I can handle the broken recovery mechanism since tearing is much better than stuttering in my opinion). The reason I had it on in the first place was to test a bunch of games with both VRR and tearing on to see what frame rate limit I should set to avoid sporadic frametime jumps below 6.06ms which induced tearing/stuttering. After I was happy with 160 FPS, I forgot to unset the environment variable and that's how I got the issue. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 464868] Create UI to generate and use a custom Libinput acceleration profile
https://bugs.kde.org/show_bug.cgi?id=464868 fililip changed: What|Removed |Added CC||t...@nitrosubs.live --- Comment #7 from fililip --- What's the current status of this? Are custom acceleration curves planned? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 464868] Create UI to generate and use a custom Libinput acceleration profile
https://bugs.kde.org/show_bug.cgi?id=464868 --- Comment #9 from fililip --- Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480895] New: KWin 5.93.0 has a DRM timeout issue with GPU resets
https://bugs.kde.org/show_bug.cgi?id=480895 Bug ID: 480895 Summary: KWin 5.93.0 has a DRM timeout issue with GPU resets Classification: Plasma Product: kwin Version: 5.93.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- Created attachment 165565 --> https://bugs.kde.org/attachment.cgi?id=165565&action=edit journalctl log SUMMARY 5.92.0 is the last KWin version where GPU resets work, on 5.93.0 they cause a DRM timeout: [ 309.469926] amdgpu :0b:00.0: amdgpu: GPU reset(4) succeeded! [ 341.340379] amdgpu :0b:00.0: amdgpu: GPU reset begin! [ 343.468579] amdgpu :0b:00.0: [drm] *ERROR* flip_done timed out [ 343.468585] amdgpu :0b:00.0: [drm] *ERROR* [CRTC:85:crtc-0] commit wait timed out [ 353.708655] amdgpu :0b:00.0: [drm] *ERROR* flip_done timed out [ 353.708666] amdgpu :0b:00.0: [drm] *ERROR* [PLANE:64:plane-4] commit wait timed out [ 354.242787] amdgpu :0b:00.0: amdgpu: MODE1 reset When that happens, the PC sometimes requires a hard reset, sometimes it doesn't, but KWin is unusable after that anyway. Not sure if that's a KWin regression, usage of a new feature that hasn't gotten implemented in the kernel (DRM) uAPI or a kernel regression. I've also tried restoring the kernel to 6.7.0 as well as other packages (where I remember it working fine) to no avail. Tested on latest Mesa 24.1-dev. Screen configuration (if relevant): - primary display: 1080p165 VRR (adaptive sync set to "Always") - secondary display: 1080p60 non-VRR STEPS TO REPRODUCE 1. Upgrade KWin to 5.93.0 2. Reset the GPU OBSERVED RESULT The session is frozen (and sometimes the entire computer with it) EXPECTED RESULT The session is restored just fine SOFTWARE/OS VERSIONS OS: Arch Linux 6.7.3-zen1-2-zen KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.7.0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480895] KWin 5.93.0 has a DRM timeout issue with GPU resets
https://bugs.kde.org/show_bug.cgi?id=480895 --- Comment #2 from fililip --- One more thing: it also happens on 5.92.0 but can be worked around by disabling the hardware cursor, then it works. Should have added that. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480895] KWin 5.93.0 has a DRM timeout issue with GPU resets
https://bugs.kde.org/show_bug.cgi?id=480895 --- Comment #3 from fililip --- (In reply to Zamundaaa from comment #1) > This is a kernel bug, please report it to > https://gitlab.freedesktop.org/drm/amd/-/issues > > Maybe we should add a fallback timer for when pageflips time out so that > we're not stuck waiting for the kernel. I don't know if the system would be > usable after that though. Ok, will do -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480895] KWin 5.93.0 has a DRM timeout issue with GPU resets
https://bugs.kde.org/show_bug.cgi?id=480895 --- Comment #4 from fililip --- (In reply to fililip from comment #3) > (In reply to Zamundaaa from comment #1) > > This is a kernel bug, please report it to > > https://gitlab.freedesktop.org/drm/amd/-/issues > > > > Maybe we should add a fallback timer for when pageflips time out so that > > we're not stuck waiting for the kernel. I don't know if the system would be > > usable after that though. > > Ok, will do https://gitlab.freedesktop.org/drm/amd/-/issues/3155 Done -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480895] KWin 5.93.0 has a DRM timeout issue with GPU resets
https://bugs.kde.org/show_bug.cgi?id=480895 --- Comment #5 from fililip --- Another observation: this has nothing to do with KWin's version. Disabling the hardware cursor just makes it work somehow. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480895] KWin has a DRM timeout issue with GPU resets when using the hardware cursor
https://bugs.kde.org/show_bug.cgi?id=480895 fililip changed: What|Removed |Added Summary|KWin 5.93.0 has a DRM |KWin has a DRM timeout |timeout issue with GPU |issue with GPU resets when |resets |using the hardware cursor -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480895] KWin has a DRM timeout issue with GPU resets when using the hardware cursor
https://bugs.kde.org/show_bug.cgi?id=480895 --- Comment #9 from fililip --- Thanks a lot for the prompt fix! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486081] Frame swapping in WebRTC screensharing while moving the mouse
https://bugs.kde.org/show_bug.cgi?id=486081 --- Comment #5 from fililip --- Thanks a lot for finding relevant information! I'll try to patch kwin and report back. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running Steam on AMD+NVIDIA forces fullscreen repaints for the rest of the session all the time
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #10 from fililip --- After further testing, this can also happen when any "custom-border"/"custom-window" Xwayland app (such as FL Studio via Wine, Steam, game/mod launchers via Wine, etc.) is launched. This in turn forces full refresh rate whole-screen on all screens (unless VRR requirements are met, see below). These full repaints are easy to visualize with the Show Paint desktop effect in KWin. I've also tried removing the nvidia driver again, this time to no avail - FL Studio manages to trigger this behavior even on a single GPU (AMD) setup, so thankfully it seems like it's not an NVIDIA bug after all. (The Steam window itself for some reason manages to work fine on just AMD, but everything falls apart if I launch a game with "custom" windows, like OMSI 2.) However, this is probably intended behavior anyway (the minimum refresh rate requirement for VRR is not enforced prior to launching these apps, see https://bugs.kde.org/show_bug.cgi?id=483240, starting one of them "makes it work"). I'll just stick to nested compositing, the Wine Wayland driver and gamescope wherever I can - I'd like to retain full kernel LFC if possible. The only real issue with these repaints is the relatively "high" CPU usage they cause (compared to when they aren't present). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running a "custom" X window via Xwayland forces fullscreen repaints for the rest of the session all the time
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added Summary|Running Steam on AMD+NVIDIA |Running a "custom" X window |forces fullscreen repaints |via Xwayland forces |for the rest of the session |fullscreen repaints for the |all the time|rest of the session all the ||time -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483240] VRR below 30-ish FPS turns off completely
https://bugs.kde.org/show_bug.cgi?id=483240 fililip changed: What|Removed |Added CC||t...@nitrosubs.live --- Comment #6 from fililip --- Update: this is a problem only once https://bugs.kde.org/show_bug.cgi?id=485425 happens. Kernel LFC works fine until then. (This is why it's not that obviously noticeable, since I don't run such Wine/X11 programs every session.) In fact, the patch I sent above makes matters even worse - VRR is completely disabled if the situation above occurs. This means that the bug #485425 is related to this one. (Is it possible to mark it as such?) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running a "custom" X window via Xwayland forces fullscreen repaints for the rest of the session all the time
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added CC||t...@nitrosubs.live -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486081] Frame swapping in WebRTC screensharing while moving the mouse
https://bugs.kde.org/show_bug.cgi?id=486081 --- Comment #6 from fililip --- It looks like https://webrtc-review.googlesource.com/c/src/+/349881 has been merged. Now we need to wait for Firefox and Chromium to make use of this WebRTC fix. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running a Wine/X11 application forces constant fullscreen repaints for the rest of the session
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added Summary|Running a "custom" X window |Running a Wine/X11 |via Xwayland forces |application forces constant |fullscreen repaints for the |fullscreen repaints for the |rest of the session all the |rest of the session |time| -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running some Wine (X11) applications forces constant fullscreen repaints for the rest of the session
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added Summary|Running a Wine/X11 |Running some Wine (X11) |application forces constant |applications forces |fullscreen repaints for the |constant fullscreen |rest of the session |repaints for the rest of ||the session --- Comment #11 from fililip --- I've found a reliable reproducer: Yume Nikki on Steam (free). After running the game, the fullscreen repaints are forced on all screens. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running some Wine applications through Xwayland forces constant fullscreen repaints for the rest of the session
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added Summary|Running some Wine (X11) |Running some Wine |applications forces |applications through |constant fullscreen |Xwayland forces constant |repaints for the rest of|fullscreen repaints for the |the session |rest of the session -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486081] Frame swapping in WebRTC screensharing while moving the mouse
https://bugs.kde.org/show_bug.cgi?id=486081 fililip changed: What|Removed |Added Resolution|--- |UPSTREAM Status|CONFIRMED |RESOLVED --- Comment #7 from fililip --- This is now fixed in the latest Chromium build, you can check it out yourself by grabbing a build from https://download-chromium.appspot.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running some Wine applications through Xwayland forces constant fullscreen repaints for the rest of the session
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #15 from fililip --- Changing the window open/close animation to another mode/disabling and re-enabling it (or, to be safe, disabling and re-enabling all desktop effects one by one) seems to fix this issue entirely. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running some Wine applications through Xwayland forces constant fullscreen repaints for the rest of the session
https://bugs.kde.org/show_bug.cgi?id=485425 --- Comment #17 from fililip --- Does switching back to the Glide effect bring the issue back for you? For me it does; I have to use Scale. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478938] New: The presentation time protocol is buggy with VRR on Chromium
https://bugs.kde.org/show_bug.cgi?id=478938 Bug ID: 478938 Summary: The presentation time protocol is buggy with VRR on Chromium Classification: Plasma Product: kwin Version: 5.91.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- SUMMARY After setting VRR policy to "Always" (or going fullscreen on "Automatic"), running Chromium with the Ozone hint property set to Wayland or auto, the browser fails to VSync unless the hardware cursor is moved (software cursor has no influence). STEPS TO REPRODUCE 1. Set VRR policy to "Always" or "Automatic" 2. Launch Chromium with the Wayland backend (and go fullscreen if VRR policy is set to "Automatic") OBSERVED RESULT The browser has a seemingly random frametime (easily observed with UFOTest, simply scrolling a website, or with a YouTube video), but while moving the mouse everything looks good - I get 165 FPS. (This isn't good for low framerate video playback though, as moving the mouse sets the refresh rate back to 165Hz.) EXPECTED RESULT Chromium's draw/swap calls should dictate the refresh rate in a stable manner. SOFTWARE/OS VERSIONS Linux: Arch Linux, kernel version 6.6.7-zen1-1-zen KDE Plasma Version: 5.91.0 (Plasma 6.0 Beta 2) KDE Frameworks Version: 5.247.0 Qt Version: 6.7.0beta1 ADDITIONAL INFORMATION Setting KWIN_FORCE_SW_CURSOR to 1 doesn't cause Chromium to sync properly while moving the mouse - could this have something to do with cursor plane separation? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #8 from fililip --- As funny as that sounds, you can try using HIP with Blender to trigger a real reset (https://projects.blender.org/blender/blender/issues/100353, this is still not fixed...): 1. Open Blender 2. Select the Cycles HIP backend and your AMD GPU 3. Hit F12 4. Use the viewport renderer at the same time 5. This should almost instantly trigger a reset -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478938] The presentation time protocol is buggy with VRR on Chromium
https://bugs.kde.org/show_bug.cgi?id=478938 --- Comment #3 from fililip --- Done https://bugs.chromium.org/p/chromium/issues/detail?id=1517884 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479845] New: The current Wayland GPU recovery experience (AMD) is not ideal
https://bugs.kde.org/show_bug.cgi?id=479845 Bug ID: 479845 Summary: The current Wayland GPU recovery experience (AMD) is not ideal Classification: Plasma Product: kwin Version: 5.92.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- SUMMARY GPU recovery on Wayland (amdgpu) now either works too slowly, doesn't actually recover (forces a compositor restart) or hangs the input system, forcing SSHing into it and SIGKILLing kwin_wayland to restart the compositor. This is with one display attached (1080p 165Hz VRR), though. With two (1080p 165Hz VRR & 1080p 60Hz non-VRR), the compositor does not recover at all (or does, but very rarely) and either hangs the input system (forcing to SSH) or restarts itself, making apps (that do not support compositor handoff, I presume, since Konsole stays up just fine) to lose progress. When that happens, dmesg doesn't show gfxhub page faults, but two gfx timeouts and DRM commit failures. What's more, it used to work just fine on KWin 5.27.5 and Mesa 23.2 - everything happened fast enough, and it worked fine even with two displays. (Unfortunately, back then it was possible for a faulty app to reset the card in a way that did not aid recovery, and there was some kind of VRAM leak.) dmesg log after the reset completes (one display): [ 377.569608] amdgpu :0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2 pasid:32770, for process kwin_wayland pid 4036 thread kwin_wayla:cs0 pid 4068) [ 377.569613] amdgpu :0b:00.0: amdgpu: in page starting at address 0x80001000 from client 0x1b (UTCL2) [ 377.569615] amdgpu :0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00201431 [ 377.569616] amdgpu :0b:00.0: amdgpu: Faulty UTCL2 client ID: SQC (data) (0xa) [ 377.569617] amdgpu :0b:00.0: amdgpu: MORE_FAULTS: 0x1 [ 377.569617] amdgpu :0b:00.0: amdgpu: WALKER_ERROR: 0x0 [ 377.569618] amdgpu :0b:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [ 377.569618] amdgpu :0b:00.0: amdgpu: MAPPING_ERROR: 0x0 [ 377.569619] amdgpu :0b:00.0: amdgpu: RW: 0x0 [ 377.569622] amdgpu :0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2 pasid:32770, for process kwin_wayland pid 4036 thread kwin_wayla:cs0 pid 4068) [ 377.569624] amdgpu :0b:00.0: amdgpu: in page starting at address 0x80001000 from client 0x1b (UTCL2) [ 377.569625] amdgpu :0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x [ 377.569625] amdgpu :0b:00.0: amdgpu: Faulty UTCL2 client ID: CB/DB (0x0) [ 377.569626] amdgpu :0b:00.0: amdgpu: MORE_FAULTS: 0x0 [ 377.569626] amdgpu :0b:00.0: amdgpu: WALKER_ERROR: 0x0 [ 377.569627] amdgpu :0b:00.0: amdgpu: PERMISSION_FAULTS: 0x0 [ 377.569627] amdgpu :0b:00.0: amdgpu: MAPPING_ERROR: 0x0 [ 377.569628] amdgpu :0b:00.0: amdgpu: RW: 0x0 [ 377.569631] amdgpu :0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2 pasid:32770, for process kwin_wayland pid 4036 thread kwin_wayla:cs0 pid 4068) [ 377.569632] amdgpu :0b:00.0: amdgpu: in page starting at address 0x80001000 from client 0x1b (UTCL2) [ 377.569633] amdgpu :0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x [ 377.569634] amdgpu :0b:00.0: amdgpu: Faulty UTCL2 client ID: CB/DB (0x0) [ 377.569634] amdgpu :0b:00.0: amdgpu: MORE_FAULTS: 0x0 [ 377.569635] amdgpu :0b:00.0: amdgpu: WALKER_ERROR: 0x0 [ 377.569635] amdgpu :0b:00.0: amdgpu: PERMISSION_FAULTS: 0x0 [ 377.569636] amdgpu :0b:00.0: amdgpu: MAPPING_ERROR: 0x0 [ 377.569636] amdgpu :0b:00.0: amdgpu: RW: 0x0 [ 388.011857] amdgpu :0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2 pasid:32770, for process kwin_wayland pid 4036 thread kwin_wayla:cs0 pid 4068) [ 388.011882] amdgpu :0b:00.0: amdgpu: in page starting at address 0x80001000 from client 0x1b (UTCL2) [ 388.011894] amdgpu :0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00201431 [ 388.011900] amdgpu :0b:00.0: amdgpu: Faulty UTCL2 client ID: SQC (data) (0xa) [ 388.011905] amdgpu :0b:00.0: amdgpu: MORE_FAULTS: 0x1 [ 388.011909] amdgpu :0b:00.0: amdgpu: WALKER_ERROR: 0x0 [ 388.011913] amdgpu :0b:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [ 388.011916] amdgpu :0b:00.0: amdgpu: MAPPING_ERROR: 0x0 [ 388.011919] amdgpu :0b:00.0: amdgpu: RW: 0x0 [ 388.011932] amdgpu :0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2 pasid:32770, for process kwin_wayland pid 4036 thread kwin_wayla:cs0 pid 4068) [ 388.011942] amdgpu :0b:00.0: amdgpu: in page starting at address 0x80001
[kwin] [Bug 479845] The current Wayland GPU recovery experience (AMD) is not ideal
https://bugs.kde.org/show_bug.cgi?id=479845 --- Comment #1 from fililip --- Don't know if it's related to the issue (sorry if it isn't), but I tried applying this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27097 on top of Mesa 24.0.0-rc1 (and the linked patches against Linux 6.7) and resetting the GPU. Now it looks completely broken; the gfx ring keeps soft recovering (with one display; with two the whole machine is frozen and even SSH doesn't work) but KWin keeps reset-looping the GPU. The entire session is unusable and requires SIGKILLing KWin a bunch of times to return to TTY. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479845] The current Wayland GPU recovery experience (AMD) is not ideal
https://bugs.kde.org/show_bug.cgi?id=479845 --- Comment #3 from fililip --- > GPU reset handling is something that's very WIP throughout the stack By the stack do you mean kwin, upstream, or both? I thought kwin already had GPU recovery support for Wayland, I might be wrong though (unless what's currently present is experimental and that's why it's so hit-or-miss). What is the state of Wayland GPU recovery on other vendors' GPUs though? Does Intel work better? (asking out of curiosity) > Would it be better if kwin exited after N resets? Perhaps, if they happened way too close (time interval wise) to one another. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479845] The current Wayland GPU recovery experience (AMD) is not ideal
https://bugs.kde.org/show_bug.cgi?id=479845 --- Comment #5 from fililip --- Oh, I noticed one important thing - I was using the legacy DRM API (KWIN_DRM_NO_AMS=1) for tearing support. After disabling it, on latest Mesa 24.1 (dev) stuff works fine even on Plasma 5. Sorry for the trouble. > amdgpu will gain the ability to do the same soon though That's amazing news! Thank you for your continued effort. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #9 from fililip --- I've just had an idea: would it be possible to kill/restart Xwayland (togglable somehow with an env var or something similar) on a reset? That would be much better than a frozen desktop session. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #4 from fililip --- I tested Mesa 23.3, as well as 24. The reset mechanism is now extremely buggy; the second reset always resets kwin, killing all apps. Is this a Mesa issue or a Plasma 5 issue (that's fixed in 6)? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #5 from fililip --- It starts with kwin_wayland[60753]: kwin_scene_opengl: Waiting for glGetGraphicsResetStatus to return GL_NO_ERROR timed out! and ends with a long stack trace: #0 0x7f870c43f73d syscall (libc.so.6 + 0x10e73d) #1 0x7f87045126ce n/a (radeonsi_dri.so + 0x1126ce) #2 0x7f8704c9b201 n/a (radeonsi_dri.so + 0x89b201) #3 0x7f8704c59d08 n/a (radeonsi_dri.so + 0x859d08) #4 0x7f8704c5b6f3 n/a (radeonsi_dri.so + 0x85b6f3) #5 0x7f870456dde1 n/a (radeonsi_dri.so + 0x16dde1) #6 0x7f87059043ae n/a (radeonsi_dri.so + 0x15043ae) #7 0x7f8704561c3f n/a (radeonsi_dri.so + 0x161c3f) #8 0x7f8704561d08 n/a (radeonsi_dri.so + 0x161d08) #9 0x7f870eb99ce4 _ZN4KWin9GLTextureC2Ejiiib (libkwinglutils.so.14 + 0x11ce4) #10 0x557a93745f7f n/a (kwin_wayland + 0xbcf7f) #11 0x557a93746738 n/a (kwin_wayland + 0xbd738) #12 0x557a9374b36d n/a (kwin_wayland + 0xc236d) #13 0x557a9374c5eb n/a (kwin_wayland + 0xc35eb) #14 0x7f870edf9633 n/a (libkwin.so.5 + 0x1f9633) #15 0x7f870edf9c22 n/a (libkwin.so.5 + 0x1f9c22) #16 0x7f870edf1710 _ZN4KWin12EffectLoader15queryAndLoadAllEv (libkwin.so.5 + 0x1f1710) #17 0x7f870ee04146 _ZN4KWin18EffectsHandlerImplC1EPNS_10CompositorEPNS_14WorkspaceSceneE (libkwin.so.5 + 0x204146) #18 0x7f870edc1302 _ZN4KWin10Compositor20startupWithWorkspaceEv (libkwin.so.5 + 0x1c1302) #19 0x7f870edb9114 _ZN4KWin10Compositor12reinitializeEv (libkwin.so.5 + 0x1b9114) #20 0x7f870d4d1097 n/a (libQt5Core.so.5 + 0x2d1097) #21 0x7f870ed716d7 _ZN4KWin10RenderLoop14frameRequestedEPS0_ (libkwin.so.5 + 0x1716d7) #22 0x7f870edc8598 _ZN4KWin17RenderLoopPrivate8dispatchEv (libkwin.so.5 + 0x1c8598) #23 0x7f870d4d1097 n/a (libQt5Core.so.5 + 0x2d1097) #24 0x7f870d4d2bcf _ZN6QTimer7timeoutENS_14QPrivateSignalE (libQt5Core.so.5 + 0x2d2bcf) #25 0x7f870d4c3b4e _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2c3b4e) #26 0x7f870cb788ff _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 0x1788ff) #27 0x7f870d49c168 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x29c168) #28 0x7f870d4ea7cb _ZN14QTimerInfoList14activateTimersEv (libQt5Core.so.5 + 0x2ea7cb) #29 0x7f870d4eacb1 _ZN20QEventDispatcherUNIX13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2ea> #30 0x557a937c0ce2 n/a (kwin_wayland + 0x137ce2) #31 0x7f870d49ae74 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x29ae74) #32 0x7f870d49c313 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x29c313) #33 0x557a936dc40b n/a (kwin_wayland + 0x5340b) #34 0x7f870c358cd0 n/a (libc.so.6 + 0x27cd0) #35 0x7f870c358d8a __libc_start_main (libc.so.6 + 0x27d8a) #36 0x557a936de015 n/a (kwin_wayland + 0x55015) Looks like a Mesa problem, but unsure. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #6 from fililip --- Also, the first GPU reset is *extremely* slow with newer Mesa. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #3 from fililip --- I don't think that's relevant (but may as well be); it works with native Wayland apps, just not with XWayland (xwayland blocks kwin). Though, sometimes resetting the GPU does make KWin crash/hang even without XWayland, that seems to be a fix for something different. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489602] Mouse movement causes stuttering in PipeWire captured content
https://bugs.kde.org/show_bug.cgi?id=489602 --- Comment #4 from fililip --- I found a very cool OpenGL/Vulkan layer for game capture, anyone who has stuttering issues or annoyances with pipewire window/desktop capture should try this and see if it helps (it makes content entirely stutter free :D): https://github.com/nowrep/obs-vkcapture -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 fililip changed: What|Removed |Added CC||t...@nitrosubs.live --- Comment #13 from fililip --- To anyone who does shader dev and is worried about AMD GPU resets, I recommend applying the relevant patches for your GPUs from here: https://patchwork.freedesktop.org/series/136246/ I did just that, now I cannot get the card to reset at all, it just kicks the faulty job out of the scheduler and everything else continues to work fine. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485425] Running some Wine applications through Xwayland forces constant fullscreen repaints for the rest of the session
https://bugs.kde.org/show_bug.cgi?id=485425 fililip changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #26 from fililip --- I re-tested and Glide works fine now in 6.1.3, thanks! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #16 from fililip --- Oh, it looks like this issue is already tracked on Xorg's GitLab: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1612 For this reason maybe it's better to mark this issue as upstream? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475322] A GPU reset (amdgpu) causes Xwayland to hang kwin if an app interacts with X11
https://bugs.kde.org/show_bug.cgi?id=475322 --- Comment #18 from fililip --- Yeah, you're right, that makes sense. I came back to this issue, played with resets a bit more and noticed something odd with this hang: 1) I started a new, clean session, 2) I launched vkcube, 3) I triggered a reset with debugfs, the desktop recovered properly, the vkcube window became stuck, but no hang yet (that's why you might have gotten no coredump before), 4) I then attempted to move the vkcube window (with the Super + left mouse button combo) and immediately (a few frames later) got a hang. I presume this is when Xwayland crashed and became a zombie process. This feels like KWin is trying to process an event for Xwayland but fails and waits indefinitely (maybe for the event sockets that don't get a chance to unregister in time?). I'm also able to trigger this hang without a GPU reset by simply doing killall -9 Xwayland a few times rapidly after starting a new session, which suggests this is not just a graphics reset issue. Though this method only works sometimes, it doesn't hang all the time. (But the hang itself also seems non-deterministic, since I've also managed to crash Xwayland with a graphics reset without it blocking anything.) Some time ago you mentioned timing the blur effect out when it takes too long to execute. Would it be possible to do something similar for Xwayland, so that when it crashes and enters the zombie state, KWin can continue to function, or would that break functionality in some X11 apps (like games that freeze for a bit when loading/processing shaders that might be unnecessarily killed by such mechanism)? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 494830] New: plasmashell crashes when hitting both mouse keys in rapid succession
https://bugs.kde.org/show_bug.cgi?id=494830 Bug ID: 494830 Summary: plasmashell crashes when hitting both mouse keys in rapid succession Classification: Plasma Product: plasmashell Version: 6.2.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: t...@nitrosubs.live CC: qydwhotm...@gmail.com Target Milestone: 1.0 SUMMARY plasmashell crashes when hitting both mouse keys in rapid succession on a panel STEPS TO REPRODUCE Click and release both the left and the right mouse buttons rapidly when hovering over a Task Manager attached to a panel. OBSERVED RESULT The shell crashes and restarts EXPECTED RESULT The shell continues functioning SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.3 Kernel Version: 6.10.10-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT ADDITIONAL INFORMATION Backtrace: #0 0x769514a2 in ??? () at /usr/lib/libQt6Quick.so.6 #1 0x76b4cb6c in QQuickDeliveryAgentPrivate::onGrabChanged(QObject*, QPointingDevice::GrabTransition, QPointerEvent const*, QEventPoint const&) () at /usr/lib/libQt6Quick.so.6 #2 0x753a3457 in ??? () at /usr/lib/libQt6Core.so.6 #3 0x759bf5e4 in QPointingDevicePrivate::setExclusiveGrabber(QPointerEvent const*, QEventPoint const&, QObject*) () at /usr/lib/libQt6Gui.so.6 #4 0x76b4b214 in QQuickDeliveryAgentPrivate::handleWindowDeactivate(QQuickWindow*) () at /usr/lib/libQt6Quick.so.6 #5 0x753a3457 in ??? () at /usr/lib/libQt6Core.so.6 #6 0x7598386c in QGuiApplicationPrivate::setApplicationState(Qt::ApplicationState, bool) () at /usr/lib/libQt6Gui.so.6 #7 0x7597a7a2 in QGuiApplicationPrivate::processFocusWindowEvent(QWindowSystemInterfacePrivate::FocusWindowEvent*) () at /usr/lib/libQt6Gui.so.6 #8 0x759e7d24 in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () at /usr/lib/libQt6Gui.so.6 #9 0x75e05734 in ??? () at /usr/lib/libQt6Gui.so.6 #10 0x73eb9559 in ??? () at /usr/lib/libglib-2.0.so.0 #11 0x73f1c157 in ??? () at /usr/lib/libglib-2.0.so.0 #12 0x73eb8a55 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #13 0x755a985d in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt6Core.so.6 #14 0x75350106 in QEventLoop::exec(QFlags) () at /usr/lib/libQt6Core.so.6 #15 0x7534a27d in QCoreApplication::exec() () at /usr/lib/libQt6Core.so.6 #16 0x5557c15f in ??? () #17 0x74c34e08 in ??? () at /usr/lib/libc.so.6 #18 0x74c34ecc in __libc_start_main () at /usr/lib/libc.so.6 --Type for more, q to quit, c to continue without paging-- #19 0x5557c675 in ??? () -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 496280] Spectacle takes some time to take a high resolution screenshot
https://bugs.kde.org/show_bug.cgi?id=496280 fililip changed: What|Removed |Added CC||t...@nitrosubs.live -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 496280] New: Spectacle takes some time to take a high resolution screenshot
https://bugs.kde.org/show_bug.cgi?id=496280 Bug ID: 496280 Summary: Spectacle takes some time to take a high resolution screenshot Classification: Applications Product: Spectacle Version: 24.08.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: noaha...@gmail.com Reporter: t...@nitrosubs.live CC: k...@david-redondo.de Target Milestone: --- SUMMARY Spectacle takes time (that I believe to be longer than it should be) to take a high resolution screenshot (eg. a large region on a 1440p/4K display or between two 1080p displays). STEPS TO REPRODUCE 1. Invoke the rectangular region screenshotter 2. Take a screenshot of a large area (preferably >1080p) OBSERVED RESULT More than 500 milliseconds are needed to close the region selector copy the screenshot to clipboard EXPECTED RESULT It should probably take less time (see specs below for reference) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.7-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 496819] OBS is able to record the lockscreen including password typing with PipeWire and Wayland
https://bugs.kde.org/show_bug.cgi?id=496819 fililip changed: What|Removed |Added CC||t...@nitrosubs.live --- Comment #2 from fililip --- Can confirm, the PipeWire capture backend should probably show a black screen outside of the session, or at least just the lockscreen without any username/password prompts. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] With "Save clipboard across desktop sessions" disabled, images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666 fililip changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from fililip --- Fixed in 6.3. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 499871] New: Changing months too fast leads to a re-triggered animation but no month change
https://bugs.kde.org/show_bug.cgi?id=499871 Bug ID: 499871 Summary: Changing months too fast leads to a re-triggered animation but no month change Classification: Plasma Product: plasmashell Version: 6.3.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Calendar widget Assignee: plasma-b...@kde.org Reporter: t...@nitrosubs.live Target Milestone: 1.0 SUMMARY Changing months too fast leads to a re-triggered animation but no month change. STEPS TO REPRODUCE 1. Open up the Calendar widget 2. Try to go back a few months by pressing the left/right button very fast OBSERVED RESULT The month does not change; the animation simply replays again and again EXPECTED RESULT Animations should not affect the currently displayed month value (maybe it'd be good to temporarily disable them for changes that are too fast and re-enable them when they are slow enough?) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 20 × AMD Ryzen AI 9 365 w/ Radeon 880M Memory: 27.2 GiB of RAM Graphics Processor: AMD Radeon Graphics -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 fililip changed: What|Removed |Added CC||t...@nitrosubs.live --- Comment #13 from fililip --- This has been bothering me for a while, thanks for the find! With the patch it's much, much better now. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498881] New: Night Light makes colors less vibrant on screenshots and recordings
https://bugs.kde.org/show_bug.cgi?id=498881 Bug ID: 498881 Summary: Night Light makes colors less vibrant on screenshots and recordings Classification: Plasma Product: kwin Version: 6.2.90 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@nitrosubs.live Target Milestone: --- Created attachment 177523 --> https://bugs.kde.org/attachment.cgi?id=177523&action=edit screenshot with night light on SUMMARY Night Light makes colors less vibrant on screenshots and recordings. I don't remember whether this used to be the case on 6.2, but I'd been using pre-6.3 Plasma for a very long time, testing all sorts of things, and do not remember noticing anything off there. However, I've noticed this while testing a video game's performance (my friend noticed the weird colors on my screenshots). STEPS TO REPRODUCE 1. Enable Night Light 2. Take a screenshot or record a video 3. Disable Night Light 4. Take a screenshot or record a video OBSERVED RESULT Captures from steps 2. and 4. look different; 4. looks okay, while 2. is washed out I'll attach two screenshots for easy comparison. One thing to note is that with night light on, when viewing the two screenshots, they don't look too different. The difference is only visible with night light off. EXPECTED RESULT Captures from steps 2. and 4. shouldn't look too different, or should ideally be the same SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.90 KDE Frameworks Version: 6.10.0 Qt Version: 6.9.0 Kernel Version: 6.12.10-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498881] Night Light makes colors less vibrant on screenshots and recordings
https://bugs.kde.org/show_bug.cgi?id=498881 --- Comment #2 from fililip --- Created attachment 177525 --> https://bugs.kde.org/attachment.cgi?id=177525&action=edit the exact color I chose for testing -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498881] Night Light makes colors less vibrant on screenshots and recordings
https://bugs.kde.org/show_bug.cgi?id=498881 --- Comment #1 from fililip --- Created attachment 177524 --> https://bugs.kde.org/attachment.cgi?id=177524&action=edit screenshot with night light off -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498881] Night Light makes colors less vibrant on screenshots and recordings
https://bugs.kde.org/show_bug.cgi?id=498881 fililip changed: What|Removed |Added CC||t...@nitrosubs.live -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498884] New: The part of the tooltip showing seconds always seems to stay at 01 with 'Only in tooltip' selected
https://bugs.kde.org/show_bug.cgi?id=498884 Bug ID: 498884 Summary: The part of the tooltip showing seconds always seems to stay at 01 with 'Only in tooltip' selected Classification: Plasma Product: plasmashell Version: 6.2.90 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Digital Clock widget Assignee: plasma-b...@kde.org Reporter: t...@nitrosubs.live Target Milestone: 1.0 SUMMARY When hovering over the Digital Clock to see the tooltip, the part showing seconds stays constant, and even when minutes change, the minute part changes as well, but the second part stays at :01. However, when I set 'Show seconds' to 'Always', this problem goes away. STEPS TO REPRODUCE 1. Set 'Show seconds' to 'Only in tooltip' 2. Hover over the Digital Clock widget on a panel OBSERVED RESULT The second part stays at :01 (or potentially some other value) EXPECTED RESULT The second part changes as seconds pass no matter the 'Show seconds' setting SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.90 KDE Frameworks Version: 6.10.0 Qt Version: 6.9.0 Kernel Version: 6.12.10-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498884] The part of the tooltip showing seconds always seems to stay at 01 with 'Only in tooltip' selected
https://bugs.kde.org/show_bug.cgi?id=498884 fililip changed: What|Removed |Added CC||t...@nitrosubs.live -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] With "Save clipboard across desktop sessions" disabled, images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666 --- Comment #10 from fililip --- I compiled plasma-workspace from master and the clipboard works as intended again. However, I still don't know what fixes it or if it's gonna work on 6.3. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] With "Save clipboard across desktop sessions" disabled, images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666 --- Comment #9 from fililip --- Would it be possible to make it so that nothing gets saved to disk with that option disabled (by storing the sqlite db in memory), if nothing is to be preserved after a shell restart anyway? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498884] The part of the tooltip showing seconds always seems to stay at 01 with 'Only in tooltip' selected
https://bugs.kde.org/show_bug.cgi?id=498884 fililip changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #2 from fililip --- *** This bug has been marked as a duplicate of bug 497296 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 497296] Seconds are frozen in the popup (on hover)
https://bugs.kde.org/show_bug.cgi?id=497296 fililip changed: What|Removed |Added CC||t...@nitrosubs.live --- Comment #5 from fililip --- *** Bug 498884 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 494830] plasmashell crashes when hitting both mouse keys in rapid succession
https://bugs.kde.org/show_bug.cgi?id=494830 fililip changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|BACKTRACE |FIXED --- Comment #4 from fililip --- It works now, sorry for the noise, forgot to close this. Feel free to reopen if something is wrong though. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] New: Images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666 Bug ID: 498666 Summary: Images are no longer shown in the clipboard widget and cannot be re-selected for pasting Classification: Plasma Product: plasmashell Version: 6.2.90 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard widget & pop-up Assignee: plasma-b...@kde.org Reporter: t...@nitrosubs.live Target Milestone: 1.0 SUMMARY Images are not shown in the clipboard widget anymore and they cannot be re-used for pasting after copying something else. Additionally, QR code generation fails when requested on them, unsure if that's meant to work, I had not tried it before I updated to 6.2.90. STEPS TO REPRODUCE 1. Copy an image to clipboard OBSERVED RESULT The resulting image entry is empty and cannot be re-used EXPECTED RESULT The image entry contains the copied image and allows re-using it later SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.90 KDE Frameworks Version: 6.10.0 Qt Version: 6.9.0 Kernel Version: 6.12.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] Images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666 fililip changed: What|Removed |Added CC||t...@nitrosubs.live -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498665] The clipboard history does not get cleared
https://bugs.kde.org/show_bug.cgi?id=498665 --- Comment #1 from fililip --- It also seems like I cannot edit the copied text entries either. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498665] New: The clipboard history does not get cleared
https://bugs.kde.org/show_bug.cgi?id=498665 Bug ID: 498665 Summary: The clipboard history does not get cleared Classification: Plasma Product: plasmashell Version: 6.2.90 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard widget & pop-up Assignee: plasma-b...@kde.org Reporter: t...@nitrosubs.live Target Milestone: 1.0 SUMMARY The clipboard history does not get cleared, by either deleting a particular item, the dedicated keyboard shortcut / the 'Clear History' button or autoremoval on item count surpassing. STEPS TO REPRODUCE 1. Copy something to the clipboard 2. Try to remove an item or everything from clipboard history OBSERVED RESULT Nothing happens EXPECTED RESULT The clipboard item(s) are removed from history SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.90 KDE Frameworks Version: 6.10.0 Qt Version: 6.9.0 Kernel Version: 6.12.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498665] The clipboard history does not get cleared
https://bugs.kde.org/show_bug.cgi?id=498665 fililip changed: What|Removed |Added CC||t...@nitrosubs.live -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] Images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666 --- Comment #1 from fililip --- Update: this is broken only if I disable preserving clipboard history across sessions. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] Images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666 --- Comment #6 from fililip --- Disable the setting, restart plasmashell (I did it with `pkill plasmashell` and `plasmashell` in the Alt+F2 menu) and then copy an image. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498666] Images are no longer shown in the clipboard widget and cannot be re-selected for pasting
https://bugs.kde.org/show_bug.cgi?id=498666
--- Comment #4 from fililip ---
> Can you clarify exactly how you did that?
There's an option called 'Save history across desktop sessions.' Only with it
enabled does the clipboard work as expected on 6.2.90. Note that in order for
it to take effect plasmashell needs to be restarted.
> And can you also be specific about how you copy an image to make it fail to
> appear in the pop-up?
Either in a browser (with 'copy image'), nomacs ('copy buffer') or Spectacle
after taking a screenshot.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 498665] The clipboard history does not get cleared
https://bugs.kde.org/show_bug.cgi?id=498665 --- Comment #2 from fililip --- Update: this is broken only if I disable preserving clipboard history across sessions. -- You are receiving this mail because: You are watching all bug changes.
