[kwin] [Bug 469295] New: Stuck or involuntary mouse drag events when Pointer Threshold is Close or Equal to Drag Start Distance with Logitech MX518 and other mouses
https://bugs.kde.org/show_bug.cgi?id=469295 Bug ID: 469295 Summary: Stuck or involuntary mouse drag events when Pointer Threshold is Close or Equal to Drag Start Distance with Logitech MX518 and other mouses Classification: Plasma Product: kwin Version: 5.23.2 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: libinput Assignee: kwin-bugs-n...@kde.org Reporter: lanthrus...@gmail.com Target Milestone: --- SUMMARY You can mostly see this bug happening while clicking in Chromium browser or other browsers, sometimes which seems random at first, when you click on an image or a menu on a web page it's displayed like it's going to be dragged although you released mouse left button and you can move that stuck in drag position block or image up or down without holding any mouse buttons, like you're actually dragging it. It happens with both libinput driver and mouse-evdev driver and in case of libinput you don't have a reliable workaround yet switching o mouse-evdev to provides you an opportunity to apply a workaround I found trying to fight with that bug described below. To work around this problem set: Pointer acceleration : 2.1 Pointer threshold : 1 pixel Drag Start Distance : 4 pixels To make this bug happening often you would have to set: Pointer acceleration : 2.1 Pointer threshold : 4 pixel Drag Start Distance : 4 pixels it happens with me with Logitech MX518 and it's a new issue which I first started seeing with Neon. Basically what happens here is that when Pointer threshold is equal to Drag Start Distance and you click on the mouse it's often that the mouse physically slides slightly at the moment the left mouse button is clicked and when this happens and Pointer Threshold is equal to Drag Start Distance (which is default for libinput as it seems) - the block the mouse is clicked on gets stuck quite often in Drag position involuntarily which is very annoying. The same issue is described here: https://forum.manjaro.org/t/drag-start-mouse-settings-dont-seem-to-do-anything/117793/3 SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 5.4.80-gentoo-r1-x86_64 #1 SMP PREEMPT (available in About System) KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Mouse: Logitech MX518 (checked two of them, same bug with both) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 377923] Task manager grouping popup list only shows 15 windows, no option to scroll
https://bugs.kde.org/show_bug.cgi?id=377923
--- Comment #5 from LTHR ---
And while I was looking through GroupDialog.qml I found another bug.
to see the bug set:
a. task grouping set to at least "By program name" (irrelevant though)
b. clicking grouped text set to "Show textual list"
open 5 konsoles, they should be stacked and popuped as 5 terminals normally
when clicked on konsole icon in the task bar
now open any 2 identical tasks that would stack into one group say chromium
And now the bug:
First click on konsole icon - 5 items would popup normally
Now click again on konsole icon - 5 items would close normally
And now click on Chromium icon - you will see that the popup opens with 2
chromium tasks but the height of
this popup would be the same as the height of the previous grouping popup that
contained 5 konsoles - an ugly looking thing
How to fix it:
1. override the system org.kde.plasma.taskmanager with a the local copy like
with the previous fix or skip this if you already
have a copy of it in your
~/.local/share/plasma/plasmoids/org.kde.plasma.taskmanager/
2. open
~/.local/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/GroupDialog.qml
find
onVisualParentChanged: {
if (visible && visualParent) {
attachModel();
} else {
visible = false;
}
}
and change it to
onVisualParentChanged: {
// Fixed
updateSize();
if (visible && visualParent) {
attachModel();
} else {
visible = false;
}
}
that's not all, find
onVisibleChanged: {
if (visible && visualParent) {
_oldAppletStatus = plasmoid.status;
plasmoid.status = PlasmaCore.Types.RequiresAttentionStatus;
attachModel();
groupDialog.requestActivate();
mouseHandler.forceActiveFocus();
} else {
plasmoid.status = _oldAppletStatus;
visualParent = null;
groupRepeater.model = undefined;
groupFilter.model = undefined;
groupFilter.rootIndex = undefined;
}
}
and change it to
onVisibleChanged: {
// Fixed
updateSize();
if (visible && visualParent) {
_oldAppletStatus = plasmoid.status;
plasmoid.status = PlasmaCore.Types.RequiresAttentionStatus;
attachModel();
groupDialog.requestActivate();
mouseHandler.forceActiveFocus();
} else {
plasmoid.status = _oldAppletStatus;
visualParent = null;
groupRepeater.model = undefined;
groupFilter.model = undefined;
groupFilter.rootIndex = undefined;
}
}
and that will fix the annoying bug with the wrong height of the window that
allocates stacked (grouped) tasks
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 377923] Task manager grouping popup list only shows 15 windows, no option to scroll
https://bugs.kde.org/show_bug.cgi?id=377923 LTHR changed: What|Removed |Added Status|RESOLVED|VERIFIED CC||lanthrus...@gmail.com --- Comment #4 from LTHR --- I confirm, the same bug is still in Version 21.04.3 :-), just hit accidentally, an annoying thing - the regression from the previous KDE releases Now how you can fix it: 1. Copy /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager to ~/.local/share/plasma/plasmoids/org.kde.plasma.taskmanager/ 2. Open ~/.local/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/GroupDialog.qml and change readonly property int preferredHeight: Screen.height / (2 * Screen.devicePixelRatio) to readonly property int preferredHeight: Screen.height / (1 * Screen.devicePixelRatio) this will give you the full screen height for the grouped tasks You may all so want to change readonly property int preferredWidth: Screen.width / (3 * Screen.devicePixelRatio) to readonly property int preferredWidth: Screen.width / (2 * Screen.devicePixelRatio) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #18 from LTHR --- (In reply to Nate Graham from comment #16) > Could we fall back to using the software renderer automatically if we detect > hardware that's not capable of doing hardware-accelerated rendering, perhaps? Or have an option in KDE config May be I'm wrong but it looks like a bug. Section "Device" Identifier "Device0" VendorName "INTEL Corporation" BoardName"GMA 3600 [GMA500]" Driver "modesetting" Option "AccelMethod" "glamor" # Option "SWCursor" "ON" Option "DPMS" "TRUE" Option "DRI" "3" EndSection DRI3 is fine, glxgears is fine, FULL HD video is fine, Photoshop 19 is fine, smooth graphics, LXQT - fine, XFCE - fine, chromium - smooth graphics and performance, firefox - smooth graphics, not much CPU usage from any of them. I can't image how normally plasmashell can consume more CPU than chromium with 50+ tabs opened for 5+ minutes when mouse is rolled over a menu item it's just 100% and nothing helps, that's the last thing left unsolved for this netbook. If you google you will find a lot of reports about plasmashell taking 100% of CPU all of a sudden. But randomly - the only way to fix it is to kill it. It looks very familiar to my case but in my case - it's always 100% and always re-producible. I believe it's the same bug. It can't normally be that rolling a mouse over an item it KDE menu can require the same amount of CPU as - none-accelerated Full HD VIDEO requires in 7 minutes. It must be a bug. May be fixing it will accelerate KDE to the new performance horizonts. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #17 from LTHR --- update : the same performance with 5.21.5 Just for the record : the power of that CPU is underestimated. It's a pure born linux box that works with linux better than with windows With CPU microcode patch it can utilize amd64 arch with 4Gb RAM and thankfully to kernel patches its graphical performance is amazing. I've built Gentoo ADM64 linux for Asus 1025c netbook and it's just something in terms of stability, consistency and performance - it plays FullHD video smoothly, runs Photoshop CS19, chromium, FF. I had a long to-do/fix list over these 6 months of working on it and the only problem I still can't fix is KDE :-( I'm ready to help. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #14 from LTHR --- reported -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #12 from LTHR --- info : Freameworks 5.78 tested, the short version : absolutely no change in performance. Same problem as shown on the video above, same symptoms, same lags : KDE is still unusable on this laptop. (In reply to Nate Graham from comment #6) > There were some performance improvements here recently. See > https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/168. Can > you check again with Frameworks 5.78 once it's released in about two weeks? > Thanks! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #11 from LTHR --- please let me know when OGV files are downloaded - I'll remove them -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #10 from LTHR --- info: framework 5.77 is the same no changes with the problem compared but some good news I prepared detailed videos demonstrating the problems with PLASMA. 1025ะก performance with different panels: 1. PLASMA 5.77 http://files.healtech.ru/plasma-22-01-2021.ogv I commented the problems with the video, please watch it to the end 2. LXQT 0.16 http://files.healtech.ru/lx-qt-22-01-2021.ogv 3. XFCE 4.14.4 http://files.healtech.ru/xfce-22-01-2021.ogv I hope it helps. The top is at the background. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #9 from LTHR --- I'm waiting for the new framework 5.78 to appear in Gentoo Portage, as soon as I have I'll provide the feedback. I'm currently installing 5.77 framework which is the latest available in the portage. And I will provide the feedback about it in a few days, after it installs. (In reply to Bug Janitor Service from comment #8) > Dear Bug Submitter, > > This bug has been in NEEDSINFO status with no change for at least > 15 days. Please provide the requested information as soon as > possible and set the bug status as REPORTED. Due to regular bug > tracker maintenance, if the bug is still in NEEDSINFO status with > no change in 30 days the bug will be closed as RESOLVED > WORKSFORME > due to lack of needed information. > > For more information about our bug triaging procedures please read the > wiki located here: > https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging > > If you have already provided the requested information, please > mark the bug as REPORTED so that the KDE team knows that the bug is > ready to be confirmed. > > Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] regenerating high-res SVGs is slow
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #7 from LTHR --- Certainly, as soon as I have the update in Gentoo portage tree. Alternatively I might install/compile some plasma components upon your request not waiting till the release. I'm still not able to find the exact cause of it. It feels like for some reason when a popup menu is opened or KDE System Settings are called when an icon is SVG Plasma does some super extra work, like unzipping all of svg files in the theme and the scaling them or in KDE System Settings. While menu is accessed and svg icon cache holds menu works, then icon goes out of view, caches is nullified and again that lag in menu. It's not plasma itself the problem is somewhere in how menu icons are rendered. I first it's qml but no, it's likely related to svg format. (In reply to Nate Graham from comment #6) > There were some performance improvements here recently. See > https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/168. Can > you check again with Frameworks 5.78 once it's released in about two weeks? > Thanks! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] PopupMenu renderer and plasmashell lockup bug
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #5 from LTHR --- That is requiring testing: (In reply to LTHR from comment #4) > Yes, it looks like all these lags are related to svg icon/theme files. I > checked my e3-1270 and kde 4.14.3 and it seems it all so has a similar > problem with popup but likely because of a much powerful cpu it's barely > noticeable. So we're basically wasted by SVG format... Not verified with 4.14.3 may be I'm wrong about 4.14.3 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] PopupMenu renderer and plasmashell lockup bug
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #4 from LTHR --- Yes, it looks like all these lags are related to svg icon/theme files. I checked my e3-1270 and kde 4.14.3 and it seems it all so has a similar problem with popup but likely because of a much powerful cpu it's barely noticeable. So we're basically wasted by SVG format... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] PopupMenu renderer and plasmashell lockup bug
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #3 from LTHR --- The problem narrowed down to qtsvg? i.e. if menu items have hi-res svg file in: /usr/share/icons/hicolor/scalable/apps/*.svg and cache expired the menu rendering is slow. That is what makes KDE sluggish. Is there any way to change qtsvg cache expiration time or make it permanent or to speed up qtsvg? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] PopupMenu renderer and plasmashell lockup bug
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #2 from LTHR --- 2. Turn of GMA3600 in the kerne v4.14.*l It should be Turn ON GMA3600 support -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 324540] Multiple keyboard repeat delay problems
https://bugs.kde.org/show_bug.cgi?id=324540 --- Comment #4 from LTHR --- I'm going to test the new environment after dealing with the bug: https://bugs.kde.org/show_bug.cgi?id=430565 I remember I managed to alleviate the problem by some combination of the settings and it never happened to me with 4.14.3. (In reply to Andrew Crouthamel from comment #2) > Dear Bug Submitter, > > This is a reminder that this bug has been stagnant for a long time. Could > you help us out and re-test if the bug is valid in the latest version? This > bug will be moved back to REPORTED Status for manual review later, which may > take a while. If you are able to, please lend us a hand. > > Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 329696] Please allow forcing the tabbox to a specific screen (or to show it on all screens) to ensure it's in sight
https://bugs.kde.org/show_bug.cgi?id=329696 --- Comment #2 from LTHR --- Yes both displays are sometimes good but if you have one display you work and other display is to demonstrate say a control board for others the task switcher appearing on all screens would be an annoying experience. But in some cases all display task switcher is good. So it looks like we have two new options: 1. fixed: let a user to choose display for the switcher 2. general: all display task switcher (In reply to tobiasz.cudnik from comment #1) > I cant believe this is an 6yo bug. I expect the task switcher to be on all > screens by default. > > Use case: > - alt+tab through windows > - pick a wrong window on a different screen > - start alt+tabbing again > > Result: Task Switcher moved to another screen > Expected: I can continue my flow looking at one screen only -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] PopupMenu renderer and plasmashell lockup bug
https://bugs.kde.org/show_bug.cgi?id=430565 --- Comment #1 from LTHR --- Generally it feels like plasmashell is doing something it shouldn't. Like some logic inside doing some unnecessary job over and over again. It more feels like when you have IRQ conflict problem on a graphic card and from time to time the whole picture just locks and there is nothing you can do but wait then it unfreezes and for some time it's responsive again and then again it freezes and so it's how Plasma works but on the same PC other applications perform like x100 faster. Let's dig into this deeper I have that laptop under LXQT now which is stunningit just feels and has optimized efficient desktop with noting extra - a cool option for a developer. May be LXQT should be adopted by plasma as plasma-lite alternative because it's certainly fills in the niche. Nevertheless it's just a bug in Plasma that makes it so different and may be we could find the cause and fix it. I'm a developer but have no experience with neither QT not Plasma. If you need some extra info - please let me know -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 430565] New: PopupMenu renderer and plasmashell lockup bug
https://bugs.kde.org/show_bug.cgi?id=430565 Bug ID: 430565 Summary: PopupMenu renderer and plasmashell lockup bug Product: frameworks-plasma Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: libplasma Assignee: notm...@gmail.com Reporter: lanthrus...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY KDE Plasma 5.20.4 POPUP application launcher and other dialogs suffer from massive plasmashell renderer lockup issues mitigated by hardware OpenGL support and powerful CPUs. When a users clicks on Launch button it would first render the frame then on some computers after 5 or more seconds it the menu would appear. Then when you go to the next level the situation repeats. The second time you go through the same menu route it's faster. The same happens with some other plasma dialogs. More info: Linux 1025c 4.14.209-gentoo-x86_64 #1 SMP PREEMPT Thu Dec 10 19:00:20 MSK 2020 x86_64 Intel(R) Atom(TM) CPU N2800 @ 1.86GHz GenuineIntel GNU/Linux STEPS TO REPRODUCE 1. Find a laptop with GMA3600. 2. Turn of GMA3600 in the kerne v4.14.*l 3. Use xorg-server-1.20.8-r1 with sddm launcher and modsetting driver 4. Install KDE Plasma 5.20.4 OBSERVED RESULT Multiple lockup issues in plasmashell EXPECTED RESULT Linux/KDE Plasma: 4.14.209-gentoo-x86_64 Plasma 5.20.4 (available in About System) Qt Version: 5.15.2 ADDITIONAL INFORMATION That is certainly a bug. I experimented quite a lot with that box. It happens like in the summary with all of a sudden plasmashell taking all 100% of a CPU thread and it goes on and on and during all this time plasma gets unresponsive. Turning off Compositon or changing turning off or on effect doesn't help. The performance is all the same. It happens with some KDE apps too. Never happens with the other apps like VLC with QT5 or LXQT apps. GMA3600 in kernel support is quite fast. And ASUS 1025C 64bit platform with 4Gb of memory is very responsive. For example I'm having now 10 load average on 4 threads compiling chromium and firefox and other apps in different terminals and it responding amazingly well for that CPU. LXQT all so works staying amazingly responsive. But with plasma there is a lockpu bug. Plasma it very fast drawing windows with all the decorations and transparencies but opening a popup or initiating a some settings dialogs are causing plasmashell lockup for a period of 4 to 40 seconds. It looks like you click on a menu with only 1 item and you have to wait for 20 seconds. I have no other QT5 application that behaves the same on this box but KDE apps and plasma itself. At the same time FPS is not suffering it always as high as 25 and everything look smooth except these lockups. The logs have nothing special to tell. I've done nearly a lot of testing in the past week over this issue and nothing seems to help. The hardware platform and other apps performance and responses - outstanding but KDE plasma suffers. I'm ready to nail down this problem and provide all possible assistance to find out the cause of that. You many not notice the lags because of the the powerful CPU and hardware opengl support which GMA3600 lacks. The difference between Plasma opening a popup menu with a single item and LXQT doing the same or other QT5 apps like VLC is nearly 100 times. That is amazingly high difference not accountable by slow processor. During all that difficult times it's always plasmashell taking 100% of the thread for 5-20 seconds or more and then the menu appears. -- You are receiving this mail because: You are watching all bug changes.
