[kwin] [Bug 491452] New: Color correction (built-in) performance issues
https://bugs.kde.org/show_bug.cgi?id=491452 Bug ID: 491452 Summary: Color correction (built-in) performance issues Classification: Plasma Product: kwin Version: 6.1.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: bmil...@gmail.com CC: xaver.h...@gmail.com Target Milestone: --- SUMMARY When built-in color correction is enabled I see the following performance issues on two systems: 1. At 1440p 180hz running glxgears/vkcube, system with 7950x AMD iGPU get's like +30-50% usage compared to color correction off. 2. At 1440p 240hz running glxgears/vkcube, system with NVIDIA RTX 3090 gets constant periodic usage spikes (+30%) and stutters (going from P2 to P5), compared to smooth 240hz at P2 with color correction off. ADDITIONAL INFORMATION I'm thankful this got implemented, just reporting this as a minor issue as it deserves to get optimized further. There are a few too many wide gamut panels without any form of sRGB emulation, or handicapped ones. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486034] clicklockd, a mouse accessibility tool doesn't work correctly on Wayland
https://bugs.kde.org/show_bug.cgi?id=486034 --- Comment #4 from Bruno Filipe --- Hey, took a try at fixing this: https://invent.kde.org/plasma/kwin/-/merge_requests/5696 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486034] clicklockd, a mouse accessibility tool doesn't work correctly on Wayland
https://bugs.kde.org/show_bug.cgi?id=486034 --- Comment #3 from Bruno Filipe --- Here's some reference for expected multiseat behavior (from https://wayland.freedesktop.org/libinput/doc/latest/seats.html) if the same button is pressed on different devices, the button should only be considered logically pressed once. if the same button is released on one device, the button should be considered logically down if still down on another device. if two different buttons or keys are pressed on different devices, the logical state is that of both buttons/keys down. if a button is pressed on one device and another device moves, this should count as dragging. if two touches are down on different devices, the logical state is that of two touches down. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486034] clicklockd, a mouse accessibility tool doesn't work correctly on Wayland
https://bugs.kde.org/show_bug.cgi?id=486034 --- Comment #2 from Bruno Filipe --- (In reply to Zamundaaa from comment #1) > Can confirm. KWin is lacking the key press deduplication logic that's > required for multiple devices on the same seat to cooperate with each other. Hey Zamundaaa, thanks for the quick confirmation. I got a bit of practical evidence on what's happening after playing a bit with libinput debug (sudo libinput debug-events --verbose) , along with clicklockd and also a script using python-evsieve to simulate my scenario. In summary, like you already said, the current issue in kwin Wayland behavior is that when the same key is pressed/released on multiple seats it lacks any logic to avoid repeating events to mess with each other. In my scenario what happens is this: -event4 POINTER_BUTTON +1.541s BTN_LEFT (272) pressed, seat count: 1 # Real mouse BTN_LEFT pressed, from neutral state - Self-explanatory -event15 POINTER_BUTTON +1.541s BTN_LEFT (272) pressed, seat count: 2 # Virtual mouse BTN_LEFT pressed - This click should be ignored since we're already in pressed state on another seat (real mouse), but it is not. It generates a double-click instead. -event4 POINTER_BUTTON +3.125s BTN_LEFT (272) released, seat count: 1 # Real mouse BTN_LEFT released - This one should also be ignored since virtual is still in pressed state, but it is not. event4 POINTER_BUTTON +4.589s BTN_LEFT (272) pressed, seat count: 2 # Real mouse BTN_LEFT pressed again - Also should be ignored since virtual is still in pressed state, but it is not. event4 POINTER_BUTTON +4.677s BTN_LEFT (272) released, seat count: 1 # Real mouse BTN_LEFT released - Also should be ignored since virtual is still in pressed state, but it is not. -event15 POINTER_BUTTON +4.677s BTN_LEFT (272) released, seat count: 0 # Virtual BTN_LEFT released - Now kwin/Plasma should actually release effectively. A bit difficult to explain, but something like this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486034] clicklockd, a mouse accessibility tool doesn't work correctly on Wayland
https://bugs.kde.org/show_bug.cgi?id=486034 Bruno Filipe changed: What|Removed |Added CC||bmil...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486034] New: clicklockd, a mouse accessibility tool doesn't work correctly on Wayland
https://bugs.kde.org/show_bug.cgi?id=486034 Bug ID: 486034 Summary: clicklockd, a mouse accessibility tool doesn't work correctly on Wayland Classification: Plasma Product: kwin Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: input Assignee: kwin-bugs-n...@kde.org Reporter: bmil...@gmail.com Target Milestone: --- SUMMARY Hello, I'm a quadriplegic KDE user and can't migrate to Wayland due to this issue, I appreciate and thank in advance any help even though I realize it's a really niche use-case. Clicklockd is a open source tool that mimics a Windows accessibility feature known as Clicklock. It's the only public tool that does it correctly. As described by it's author, germag: "Clicklockd enables you to highlight or drag without holding down the mouse button. This feature allows you to hold the mouse button for a few seconds, move the mouse to the new location, and then click it again. The effect is the same as a drag and drop but without having to hold the mouse button for a long time." Instead of the expected behavior, clicks doesn't lock at all and single clicks are turned into double clicks. It works fine on Plasma X11 and other Wayland DE's/compositors like GNOME, and only depends on libudev, so the dev believies it's likely something related to how Plasma/kwin Wayland handles inputs. STEPS TO REPRODUCE 1. Build and run clicklockd (https://github.com/germag/clicklockd) OBSERVED RESULT . Clicklock won't work correctly and single clicks become double clicks instead. EXPECTED RESULT When we hold left click for x seconds, specified in argument like "-t 1.5s" passed to clicklockd, that click should be held on until another click comes in. SOFTWARE/OS VERSIONS KDE Plasma 6.0.4 on Arch Linux ADDITIONAL INFORMATION Github issue and discussion with developer: https://github.com/germag/clicklockd/issues/6 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463879] Virtual desktops Pager applet makes windows resize stutter/jerky with NVIDIA hardware rendering
https://bugs.kde.org/show_bug.cgi?id=463879 --- Comment #7 from Bruno Filipe --- Which info could I provide to help debug this? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463879] Virtual desktops Pager applet makes windows resize stutter/jerky with NVIDIA hardware rendering
https://bugs.kde.org/show_bug.cgi?id=463879 --- Comment #5 from Bruno Filipe --- (In reply to David Edmundson from comment #2) > Can you double check the pager makes a difference. It doesn't make much > sense other than more windows are redrawing > > We have other reports about nvidia resizing being slow that we can work on. It does, at least on my setup. Just reproduced on a clean Fedora to rule out any Arch oddness or config issue. FWIW it's a 75hz (74,991~) Ultrawide 2560x1080 monitor, GSync disabled when testing, everything on default except I added a couple of virtual desktops so they show up on the widget. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463879] Virtual desktops Pager applet makes windows resize stutter/jerky with NVIDIA hardware rendering
https://bugs.kde.org/show_bug.cgi?id=463879 --- Comment #1 from Bruno Filipe --- Another update, it looks a lot better when running only kwin_x11 --replace with the env var __GL_MaxFramesAllowed=1 - but this hack introduces problems of their own, out of topic for this issue, but still worth mentioning the behavior. Without the env var it also looks extremely smooth if I kill plasmashell, or if I run plasmashell with picom compositing instead of kwin. Suggess not a problem in Kwin or Plasmashell itself, but a specific problem to plasmashell+kwin_x11 (on Nvidia OpenGL drivers). Another thing worth mentioning, this bug https://bugs.kde.org/show_bug.cgi?id=436902 is also kinda mitigated by setting qtquick to Software. Instead of notifications dropping hundreds of frames, it drops a couple which is negligible unless you're gaming and being flooded on Discord :P -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 463879] New: Virtual desktops Pager applet makes windows resize stutter/jerky
https://bugs.kde.org/show_bug.cgi?id=463879 Bug ID: 463879 Summary: Virtual desktops Pager applet makes windows resize stutter/jerky Classification: Plasma Product: plasmashell Version: master Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Pager Assignee: plasma-b...@kde.org Reporter: bmil...@gmail.com CC: h...@kde.org Target Milestone: 1.0 SUMMARY *** When the virtual desktops Pager applet is enabled, resizing windows lags really hard. It also seems to increase random stutters, which exists anyway with Nvidia+KDE. Pretty sure it didn't happen with my last GPU (RX580 on AMDGPU). It is likely related to OpenGL+Nvidia since it also doesn't happen if I set QtQuick rendering to "Software" in kcmshell5 qtquicksettings *** STEPS TO REPRODUCE 1. Have at least two virtual desktops. 2. Add Pager widget to your panel. 3. Resize any window OBSERVED RESULT The entire desktop stutters really hard while you resize windows. EXPECTED RESULT The usual Nvidia resize stutters anyway but it is a lot better without pager enabled. SOFTWARE/OS VERSIONS Linux @ Arch Linux on Kernel 6.1.2 KDE Plasma Version: 5.26.5 KDE Frameworks Version: dunno Qt Version: 5.15.7 ADDITIONAL INFORMATION GPU: RTX 3090 on latest NVIDIA proprietary driver (525.60.11) Workaround: Set Software rendering in 'kcmshell5 qtquicksettings' qdbus org.kde.KWin /KWin supportInformation -> https://invent.kde.org/-/snippets/2461 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 424408] Multiple coredumps with every login/logout
https://bugs.kde.org/show_bug.cgi?id=424408 --- Comment #36 from Bruno Filipe --- I tested a clean install of Fedora KDE spin and it's reproduceable OOTB, both before and after full system upgrades. This breaks multi-user desktops and should be looked at with higher priority. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 424408] Multiple coredumps with every login/logout
https://bugs.kde.org/show_bug.cgi?id=424408 Bruno Filipe changed: What|Removed |Added CC||bmil...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 424488] Log out then login causes plasmashell to crashes
https://bugs.kde.org/show_bug.cgi?id=424488 Bruno Filipe changed: What|Removed |Added CC||bmil...@gmail.com --- Comment #5 from Bruno Filipe --- This was driving me crazy. I'm using https://invent.kde.org/plasma/plasma-workspace/commit/da34fd073f6b361fde1fdcee559d60e8c0268cd6 as a workaround for now, no hangs yet on login with that revert. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 401279] baloo_file_extractor eats the whole RAM
https://bugs.kde.org/show_bug.cgi?id=401279 --- Comment #4 from Bruno Filipe --- (In reply to eduardo from comment #3) > Anyway, why is the baloo file allowed to take more than 25% of the available > ram? that has to be limited somehow. To take all the ram is unnaceptable in > any circunstance. Agree, same for CPU. It should only use that much CPU if pc is idle. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 401279] baloo_file_extractor eats the whole RAM
https://bugs.kde.org/show_bug.cgi?id=401279 Bruno Filipe changed: What|Removed |Added CC||bmil...@gmail.com --- Comment #2 from Bruno Filipe --- I've got the same poblem, also on Manjaro. After last updates it started eating a lot of ram and cpu usage. I used the baloo monitoring GUI and noticed it was stuck on a big folder, and also generating errors for every file. Solution was stop baloo, delete index, blacklist that big folder I have (with lots of git repos), and then start baloo again. Only blacklisting the huge folder and/or restarting didn't do it, I think the index got corrupted somehow. -- You are receiving this mail because: You are watching all bug changes.
