[ksysguard] [Bug 460348] Plasmashell high CPU usage

2024-07-03 Thread Urs Schroffenegger
https://bugs.kde.org/show_bug.cgi?id=460348

--- Comment #5 from Urs Schroffenegger  ---
(In reply to Nate Graham from comment #4)
> Is this still happening in Plasma 6.1?

I'm still on kde 5.27.11, debian unstable hasn't updated to 6.x yet, I'll try
it then.

I worked around this by not using any sensors. I set up some sensors again and
ran into it again, with Plasma Wayland, this time, and NVidia 555.42.

I'll check again once Plasma 6.x is packaged for Debian Sid.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-browser-integration] [Bug 440160] On some websites the drop-down-menus don't work with browser integration activated

2023-06-26 Thread Urs Schroffenegger
https://bugs.kde.org/show_bug.cgi?id=440160

Urs Schroffenegger  changed:

   What|Removed |Added

 CC||nab+...@lampshade.ch

--- Comment #2 from Urs Schroffenegger  ---
I've seen the same behaviour on Firefox 114.0. I also suspected the
plasma-integration extension and disabled it. 
It disappeared, so I thought I found the culprit, and then, it was back again.
So it's probably not linked to this extension. If anyone has a pointer on how
to debug this, I'd be interested. 

For other examples, it also happens with Jupyter Lab's menus, or Simon Tatham's
puzzle page
(https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/inertia.html). The
menu opens, but the click on the menu item just closes the menu.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kglobalaccel] [Bug 415995] Cannot assign accented keys as global shortcuts

2022-11-22 Thread Urs Schroffenegger
https://bugs.kde.org/show_bug.cgi?id=415995

Urs Schroffenegger  changed:

   What|Removed |Added

 CC||nab+...@lampshade.ch

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksysguard] [Bug 460348] Plasmashell high CPU usage

2022-10-17 Thread Urs Schroffenegger
https://bugs.kde.org/show_bug.cgi?id=460348

--- Comment #2 from Urs Schroffenegger  ---
(In reply to Patrick Silva from comment #1)
> I had the same problem on Arch Linux after update to Plasma 5.26, but on
> Wayland. kwin_wayland process was also causing high cpu usage. Deleting
> kwinrc file in /home/myuser/.config/, logging out and logging in solved my
> case.

I did try and remove kwinrc and restart, it didn't solve the issue here, so I
don't think it's the same issue.

Thanks for your answer!

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 460348] New: Plasmashell high CPU usage

2022-10-13 Thread Urs Schroffenegger
https://bugs.kde.org/show_bug.cgi?id=460348

Bug ID: 460348
   Summary: Plasmashell high CPU usage
Classification: Plasma
   Product: plasmashell
   Version: git-stable-Plasma/5.26
  Platform: Debian unstable
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: System Monitor
  Assignee: plasma-b...@kde.org
  Reporter: nab+...@lampshade.ch
CC: ahiems...@heimr.nl, notm...@gmail.com
  Target Milestone: 1.0

SUMMARY
I updated my Debian Sid to kde 5.26 yesterday. After restarting today, I
noticed that the UI is getting sluggish from time to time or even hangs for a
while. In htop, it looks like plasmashell is always lingering at 25-30% of CPU.

The machine is Debian Sid, on X11, with a nvidia 2080 ti, and latest 510.0
nvidia drivers from the debian sid repo.


STEPS TO REPRODUCE
1. upgrade debian sid to kde 5.26
2. restart
3. log in to kde X11
4. run htop


OBSERVED RESULT
plasmashell takes up 35-30% of cpu, UI is sluggish and hangs

EXPECTED RESULT
pasmashell is somewhere down in the noise in CPU usage and spikes a bit up when
more UI intense stuff happens.

SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.0-2-amd64 (64-bit)
Graphics Platform: X11
Processors: 48 × AMD Ryzen Threadripper 3960X 24-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2
Manufacturer: ASUS


ADDITIONAL INFORMATION

Having stumbled upon bug #460248, I checked the output of 
$ sudo perf top -K -p $(pidof plasmashell)

Samples: 10K of event 'cycles', 4000 Hz, Event count (approx.): 2988952206
lost: 0/0 drop: 0/0
Overhead  Shared Object  Symbol
  15.59%  libKSysGuardSensors.so.5.26.0  [.] KSysGuard::SensorDataModel::data
   5.20%  libQt5Core.so.5.15.6   [.] operator<
   4.78%  libQt5Core.so.5.15.6   [.] QVariant::QVariant
   3.49%  libQt5Core.so.5.15.6   [.] QVariant::toString
   2.87%  libQt5Core.so.5.15.6   [.] operator==
   2.53%  libQt5Core.so.5.15.6   [.] 0x0014af6d
   2.43%  libKSysGuardSensors.so.5.26.0  [.] 0x00014910
   1.75%  libKSysGuardSensors.so.5.26.0  [.] 0x000148c6
   1.70%  libKSysGuardSensors.so.5.26.0  [.]
KSysGuard::SensorDataModel::rowCount
   1.68%  libQt5Core.so.5.15.6   [.] QVariant::~QVariant
   1.54%  libQt5Core.so.5.15.6   [.] QVariant::toDouble
   1.43%  libQt5Core.so.5.15.6   [.] 0x0014af30

I'm not familiar with perf, but it looks like the ksysguard sensor reading is
taking time?
I have three sensors active in my top bar:
- Individual core usage
- Total CPU usage
- Memory usage

If I get rid of these, the behaviour is the same. But if I reboot after
removing them, plasmashell cpu usage is normal.
Adding one of those sensor widgets again bumps plasmashell cpu usage up again.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kglobalaccel] [Bug 434949] Custom shortcuts containing accented keys ("é" "è" "ç" "à") aren't working on X11

2022-08-11 Thread Urs Schroffenegger
https://bugs.kde.org/show_bug.cgi?id=434949

--- Comment #26 from Urs Schroffenegger  ---
Addendum: 

Trying to manually change the config file to handle "Meta+Shift+N" with N=3,4,5
with what I would expect:

Window to Desktop 3=Meta+*,,Window to Desktop 3
Window to Desktop 4=Meta+ç,,Window to Desktop 4
Window to Desktop 5=Meta+%,,Window to Desktop 5

Then, log out, log in, and the config file has been changed to 

Window to Desktop 3=Meta+*,,Window to Desktop 3
Window to Desktop 4=Meta+Ç,,Window to Desktop 4
Window to Desktop 5=Meta+%,,Window to Desktop 5

"Meta+Shift+3" and "Meta+Shift+5" work. "Meta+Shift+4" fails...

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kglobalaccel] [Bug 434949] Custom shortcuts containing accented keys ("é" "è" "ç" "à") aren't working on X11

2022-08-11 Thread Urs Schroffenegger
https://bugs.kde.org/show_bug.cgi?id=434949

Urs Schroffenegger  changed:

   What|Removed |Added

 CC||nab+...@lampshade.ch

--- Comment #25 from Urs Schroffenegger  ---
Hi, 

I just tried switching from XMonad to KDE with the tiling extension to try and
see if I can replace my WM with a full fledged desktop compatible with Wayland.
I tried to set up the key combinations I used for years under XMonad and ran
into this same issue.

I'm on a Swiss french keyboard ("fr-ch" variant of "ch" keyboard). Trying to
map "Window To Desktop 4" to what would be "Meta+Shift+4", It registers as
"Meta+Shift+Ç" (which is a capital "ç", ccedilla is the alternative character
on the "4" key, get it with "Shift+4").

I tried to edit it in the ".config/kglobalshortcutsrc", but to no avail.
Compared to setting keys in XMonad, where it uses either the letter that is
typed when pushing the key or a keycode, it looks a bit inconsistent:
- typing "meta+shift+r", get "Meta+Shift+R". 
   Why capital R ? I'd expect "Meta+Shift+r" or "Meta+R"

- typing "meta+shift+3", get "Meta+*". 
  I'd expect "Meta+Shift+3" to be consistent with the first above, or "Meta+*"
consistent with the second. 

- typing "meta+shift+4", get "Meta+Shift+Ç". 
  I'd expect "Meta+Shift+4" or "Meta+ç". I didn't even know how to type that
capital ç (Ç) on this keyboard, looks like it's "CapsLock+Shift+4", so the
stored shortcut looks like pressing "CapsLock+Meta+Shift+4".


It looks like it stores a weird mix in the config between storing the keycode +
modifiers and the keysym (or even the LookupString?). So the shortcut doesn't
match what is typed. It would make more sense to me to store the base key and
the modifiers. But it seems that all this is handled by Qt, I don't know how
this library handles all that.

This happens on Debian Unstable, Plasma 5.25.4, KDE Framework 5.96.0, Qt
5.15.4.

I replaced it with Meta+Alt+ for now, but years of muscle memory
disagree with this solution :-D
Any news on a fix or any potential workaround by hacking the configs ? 




If it's any help, here are the XEvents from xev when pressing "Meta+Shift+3"
and "Meta+Shift+4". I don't understand how it gets to that capital ccedilla "Ç"
in the config. 

KeyPress event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3796440, (29,94), root:(1220,816),
state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3796702, (29,94), root:(1220,816),
state 0x50, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3796885, (29,94), root:(1220,816),
state 0x51, keycode 12 (keysym 0x2a, asterisk), same_screen YES,
XLookupString gives 1 bytes: (2a) "*"
XmbLookupString gives 1 bytes: (2a) "*"
XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3796990, (29,94), root:(1220,816),
state 0x51, keycode 12 (keysym 0x2a, asterisk), same_screen YES,
XLookupString gives 1 bytes: (2a) "*"
XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3797046, (29,94), root:(1220,816),
state 0x51, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3797046, (29,94), root:(1220,816),
state 0x50, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3798107, (29,94), root:(1220,816),
state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x741,
root 0x1c9, subw 0x0, time 3798227, (29,94), root:(1220,816),
state 0x50, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: Fa