SUMMARY Plasmashell hangs when I switch back from virtual console (ctrl+alt+f1...f7). I can move mouse cursor only. Plasma is not responding to clicks. Only restart of X helps. STEPS TO REPRODUCE 1. Switch to virtual console, ctrl+alt+f3 for example 2. Switch back to X server 3. Plasmashell not responding. OBSERVED RESULT Plasmashell not responding. Only killing Xserver helps. EXPECTED RESULT Works fine like before switching. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Ubuntu 19.10, KDE 5.62.0, (available in About System) KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 ADDITIONAL INFORMATION KDE is installed from ppa:kubuntu-ppa/ppa repository.
When you say plasma is not responding to clicks, you mean in all applications or just the panel/background? Are windows draggable? What other restarts have you tried other than X?
All windows (no matter if KDE or gtk programs) are not draggable. I have clock widget with seconds on panel and it stops. Any other widgets are not updating or not responding. Only Conky on desktop is updating but less times than before (normally it updates one on 3 seconds). I see on Conky that X server start using more CPU resources and hear that the fan enters a higher speed. After few minutes in this state KDE is start responding. I can move windows and widgets are updating but X server still using more resources than normally (60-70% of 8 core CPU).
It happens on Intel and NVidia graphic card with one difference: on NVidia when I switch back to KDE screen is black for few seconds, only mouse is moving. After these few seconds whole graphic environment is back but still not responsive.
> What other restarts have you tried other than X? Only restart of X server helps to back to normal.
If you need more info I will share. Just say what you want.
I made two bug reports, this one and 420138, and all of these issues can be fixed by disabling Keyboard Daemon in Background services. After disabling it system works quicker. Switching between virtual console and the X server is quick. No more lags during logging in.
moving to need more info as it looks like old issue. Bugs placed into NEEDSINFO status will receive a reminder if the ticket: Is at least 15 days old Has not received any comment within 15 days If a bug remains in NEEDSINFO for another 15 days with no comment, it will be closed as RESOLVED > WORKSFORME. If a bug remains in NEEDSINFO with a comment provided within less than 15 days, no action will be taken (as it does not meet the above criteria).
I fixed it by disabling keyboard daemon. I didn't turn it on. I will check if it's still happens on new Plasma version.
Yes, try with latest stable. plasma 5.23.5 thanks
(In reply to galdera from comment #9) > Yes, try with latest stable. plasma 5.23.5 > thanks The problem still persists in 5.23.5 but the same workaround works.
Hello, could you please provide your current setup? I'm using Kubuntu 21.10 with plasma 5.23.5 and nvidia proprietary driver(performance mode). I don't have any problem switch between XOrg displays. Regards
Operating System: Ubuntu 21.10 KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-27-lowlatency (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4700HQ CPU @ 2.40GHz Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce 840M/PCIe/SSE2 The info is generated by the about page in system settings. If you want some more info just tell me.
Created attachment 146089 [details] attachment-24362-0.html When you say keyboard deamon. Which one do you mean? How do enable disable it? It seems like an issue with your particular setup. Do you have same problem with other computers? On Sun, 30 Jan 2022, 23:26 QkiZ, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=420054 > > --- Comment #12 from QkiZ <root@qkiz.pl> --- > Operating System: Ubuntu 21.10 > KDE Plasma Version: 5.23.5 > KDE Frameworks Version: 5.90.0 > Qt Version: 5.15.2 > Kernel Version: 5.13.0-27-lowlatency (64-bit) > Graphics Platform: X11 > Processors: 8 × Intel® Core™ i7-4700HQ CPU @ 2.40GHz > Memory: 15.5 GiB of RAM > Graphics Processor: NVIDIA GeForce 840M/PCIe/SSE2 > > The info is generated by the about page in system settings. If you want > some > more info just tell me. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
When I say "Keyboard daemon" I mean a setting that is in Background Services. Full path: run System Settings, then click on Startup and Shutdown, then Background Services and uncheck Keyboard Daemon on the list. Like on picture below. http://imgurl.pl/img2/2022-01-3117-57_61f8152f43c67.png After unchecking this problem with hanging Plasmashell and lagging login to account disappears. I can reproduce this problem on a different computer, especially this one with switching between X and virtual console. Second computer information: Operating System: Kubuntu 21.10 KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-25-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 (In reply to galdera from comment #13) > Created attachment 146089 [details] > attachment-24362-0.html > > When you say keyboard deamon. Which one do you mean? > How do enable disable it? > > It seems like an issue with your particular setup. Do you have same problem > with other computers?
Thanks, that's helpful.
Please upload the journal or whereever plasma logs to on your system. There are probably device unplug/plug events triggered by VT switching. Does this happen all the time when you switch VTs? Can you trigger the issue with "kded5 --replace"? Can you still trigger the issue after "killall kglobalaccel5"? Please also run QT_LOGGING_RULES=*.debug=true kded5 --replace |& tee kded.log, then trigger the issue and attach the created logfile.
Here is a journal https://pastebin.com/4ucR34NE Here is a kded.log https://pastebin.com/N01naPfv I think this one should be most interesting: kf.globalaccel: Failed to get dbus path for component "KDE Keyboard Layout Switcher" QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") This is related to Keyboard Daemon.
> Does this happen all the time when you switch VTs? Can you trigger the issue with "kded5 --replace"? Can you still trigger the issue after "killall kglobalaccel5"? This happens every time I switch back from the virtual console. After "kded5 --replace" whole Plasma freeze like after switching from the virtual console. After some time it's unblocking itself. Here is the log from the console: kf.kded: Couldn't register name "org.kde.kcookiejar5" with DBUS - another process owns it already! kcm_touchpad: Using X11 backend Width: 1084 height: 554 Approx. resX: 12 resY: 11 Touchpad resolution: x: 31 y: 31 Final resolution x: 31 y: 31 bluedevil: Created Installing the delayed initialization callback. kf.coreaddons: "Could not load plugin from colord: Biblioteka współdzielona niedostępna." kf.kded: found kded module "colord" by prepending 'kded_' to the library path, please fix your metadata. Using XRANDR extension 1.3 or greater. 7 Yes, this happens after "killall kglobalaccel5"
Does this happen with just "/usr/bin/xmodmap /home/qkiz/.Xmodmap"? lut 01 00:14:05 drag0n dbus-daemon[7769]: [session uid=1000 pid=7769] Activating service name='org.gnome.ScreenSaver' requested by ':1.253' (uid=1000 pid=57873 comm="/usr/lib/x86_64-linux-gnu/notify-osd " label="unconfined") indicates that you have some daemon running which starts the gnome screensaver and doesn't appear to be compatible with Plasma.
I'm using xmodmap to remap some keys on my laptop but I disabled it on autostart and it's doesn't change anything. When keyboard daemon is enabled issue still persists. I don't know why this appears in logs: lut 01 00:14:05 drag0n dbus-daemon[7769]: [session uid=1000 pid=7769] Activating service name='org.gnome.ScreenSaver' requested by ':1.253' (uid=1000 pid=57873 comm="/usr/lib/x86_64-linux-gnu/notify-osd " label="unconfined") Gnome-screensaver is not installed. It looks like notify-osd is trying to reach gnome-screensaver.
(In reply to QkiZ from comment #20) > I'm using xmodmap to remap some keys on my laptop but I disabled it on > autostart and it's doesn't change anything. When keyboard daemon is enabled > issue still persists. You mean you disabled xmodmap from autostart? The keyboard daemon calls xmodmap itself, so that won't have any effect. Please answer to: > Does this happen with just "/usr/bin/xmodmap /home/qkiz/.Xmodmap"?
> You mean you disabled xmodmap from autostart? Yes I'm not sure what you mean by asking > Does this happen with just "/usr/bin/xmodmap /home/qkiz/.Xmodmap"? The problem persists no matter if I run xmodmap on autostart or not.
(In reply to QkiZ from comment #22) > I'm not sure what you mean by asking > > Does this happen with just "/usr/bin/xmodmap /home/qkiz/.Xmodmap"? > The problem persists no matter if I run xmodmap on autostart or not. Whether the issue appears when you run the xmodmap command manually, outside of any autostart.
>Whether the issue appears when you run the xmodmap command manually, outside of any autostart. Yes. I didn't notice this before but when I'm running xmodmap manually Plasma hangs for 15-30 seconds too.
(In reply to QkiZ from comment #24) > >Whether the issue appears when you run the xmodmap command manually, outside of any autostart. > Yes. I didn't notice this before but when I'm running xmodmap manually > Plasma hangs for 15-30 seconds too. Each xmodmap entry triggers an x11/xkb map change notification to all applications, so the question is which one processes them that slowly. kglobalaccel5 is the usual candidate, can you re-test whether this still happens if kglobalaccel5 is not running? If yes, the easiest option is probably to kill processes one by one and check whether that fixed it...
(In reply to Fabian Vogt from comment #25) > Each xmodmap entry triggers an x11/xkb map change notification to all > applications, so the question is which one processes them that slowly. > kglobalaccel5 is the usual candidate, can you re-test whether this still > happens if kglobalaccel5 is not running? If yes, the easiest option is > probably to kill processes one by one and check whether that fixed it... I killed kglobalaccel5 and then run xmodmap and it still happens. Which processes do you mean?
Hello Could you please tell us which keyboard customization are you using? From the log I see: org.kde.kcm_keyboard: Skipping empty shortcut for "pl"
(In reply to QkiZ from comment #26) > (In reply to Fabian Vogt from comment #25) > > Each xmodmap entry triggers an x11/xkb map change notification to all > > applications, so the question is which one processes them that slowly. > > kglobalaccel5 is the usual candidate, can you re-test whether this still > > happens if kglobalaccel5 is not running? If yes, the easiest option is > > probably to kill processes one by one and check whether that fixed it... > > I killed kglobalaccel5 and then run xmodmap and it still happens. Which > processes do you mean? All user processes except for the essential ones like the terminal you're running and ksmserver. You might be able to find the culprit(s) by monitoring the CPU usage of processes when you run xmodmap.
(In reply to Fabian Vogt from comment #28) > All user processes except for the essential ones like the terminal you're > running and ksmserver. You might be able to find the culprit(s) by > monitoring the CPU usage of processes when you run xmodmap. There are a lot of processes to test. This takes a lot of time. But will try to figure out which one is causing trouble.
I think I found what is caused the problem. First I renamed .Xmodmap to something else. Then I removed ibus from the system. After restarting of system, I enabled Keyboard daemon in Background Services. Now I don't have lags during login to my account and when I'm switching between virtual console and KDE.
Additionally, I installed fcitx but I'm not sure if I really need it. I'm using only one keyboard layout.
(In reply to QkiZ from comment #30) > I think I found what is caused the problem. First I renamed .Xmodmap to > something else. Then I removed ibus from the system. After restarting of > system, I enabled Keyboard daemon in Background Services. Now I don't have > lags during login to my account and when I'm switching between virtual > console and KDE. But if I rename .Xmodmap back problem still persists.
I believe I'm experiencing something similar with a USB keyboard. This appears to happen after a suspend/resume because all the USB devices are re-detected, but also happens whenever I plugin in a keyboard. The laptop keyboard also stops working when a USB keyboard is plugged in. Switching to virtual console and back works with both keyboards while plasma is hung. Keyboard events seem to buffer, because after some period of time (1m?), the keyboard starts working again and all of the keypresses that were pressed while frozen all replay at once, followed by a brief pause and an error `kded5[1067]: org.kde.kcm_keyboard: Failed with return code: 1`. As mentioned in this post, disabling the keyboard background service and re-plugging the USB keyboard works as expected. Intel graphics, i915 chipset. If this is unrelated, let me know and I can file a new issue. This has been quite a chore to track down, but worth creating a bugs account for.
Disabling the daemon fixed my issues with Xorg breaking after switching to a vt from kde as of this comments date.
I have experienced the same issue on Debian 12, with plasma 5.27.5. I can confirm that disabling the keyboard daemon fixed it for me. An interesting thing to add: `gqrx` can also trigger this. I have some notes here: https://discuss.kde.org/t/plasma-takes-over-a-minute-to-load/10684/24