Bug 488870

Cannot reproduce, and neither the applet (which lives in kdeplasma-addons) nor its C++ plugin (which lives in plasma-workspace) has any code in it that uses that key. They do consume key information from KModifierKeyInfo (which lives in kguiaddons) but it's pretty barebones.

This feels like it might be an issue with your distro. Can you check to see if there are any relevant-looking local patches to the widget or Qt? Also check to see if you might have a local fork of the widget in ~/.local/share/plasma/plasmoids that's getting used instead of the KDE version.

So, I checked and neither NixOS nor my own overlay add any patches to kdeplasma-addons whatsoever. For plasma-workspace, there is one patch from NixOS ( https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/kde/plasma/plasma-workspace/tool-paths.patch ) and I've included my open MR from here as well: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2178 - neither of those two have anything in them that stands out to me for this issue.

In my ~/.local/share/plasmoids I also don't have a directory for org.kde.plasma.keyboardindicator. I do have plenty of others though, but that shouldn't be a cause for interference? Also tried removing ~/.cache/plasmashell/qmlcache, but this didn't help either.

Then I'm out of ideas, sorry.

Hey I am having this bug as well. I have made a thread describing everything I know about it on the Garuda Linux Forums (which is the distro I'm running) here: https://forum.garudalinux.org/t/how-to-disable-remove-kde-plasma-keyboardindicator/37697

Here's an excerpt from it which I think might be useful:
***
I have seen it even on a fresh reboot so I cant tell when or how it starts but based on some testing I can say for sure opening new windows is not the only cause. For me any interaction with the kde/plasma ecosystem generates a fresh set of log spam, including but likely not limited to:
    - Opening new windows of kde apps like konsole and dolphin
    - Hovering over apps and widgets on the desktop panel long enough for the tooltip to generate
    - Switching between windows of kde apps like konsole and dolphin using icons on the desktop panel
    - Switching between windows of apps (any not just kde ones) by Alt-Tab-ing

Interactions within the apps doesnt generate anything so it’s either something related to the window manager or the main desktop panel that comes by default since I have a couple of side panels with a widget or two and they dont generate anything either when interacted with. 
***
I have also tried deleting the widget folder from /usr/share/plasma/plasmoids which, although removed the widget, didnt stop the spam.

Found it.

*** This bug has been marked as a duplicate of bug 484992 ***

@Nate are you sure that's the one?

Even when setting xwayland snooping to "Never", my logs are still flooded (fresh session of course)

Then I guess I'm not so sure. :/

Any chance you could test the patch that fixes it (linked to in Bug 484992) and see if it makes the log spam go away? If not, then it'll be a different issue.

Sure, I'll cherrypick it into my install and test it this weekend.

So, I'm getting the exact same thing in my Fedora install. I'll try to rebuild kwin with that commit in.

So, I cherrypicked the fix from 484992, but the issue persists, so I'm assuming this one is a different bug.

I'm having this too.   I run OpenSUSE Tumbleweed and I usually update daily so always on pretty recent versions.  

To add because someone else posted they weren't sure if their system was being slow or it was a placebo effect, the reason I started poking around my logs is because recently (last week or so) I've started getting random slowdowns and a general "lagginess" in my desktop.  I've even seen trails on my mouse (not reproducable, it just happens and I'm not sure why yet).  I'm also getting periodic "several seconds long" pauses in the system, to the point even the applets aren't updating, screen frozen, etc.  Then it comes back.  So when I did a `journalctl -f` to see what was going on that's when I noticed this.

My exact message (it comes in batches, 15-30 at a time all with same timestamp to the nearest second):
Jul 18 20:34:48 suse-dd plasmashell[2132]: org.kde.plasma.keyboardindicator: Unknown key Qt::Key_Alt

OpenSUSE Tumbleweed
KDE Plasma Version:  6.1.2
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.9.9-1-default (64-bit)
Graphics Platform: Wayland

To add one more thing to my above post:  Switching to Plasma on X11 I do not get these errors, nor have I gotten the screen artifacts I was getting or the general slowness.  I'm not sure if it's Wayland or Plasma, but Plasma with X11 seems to not display this behavior.

I am on KDE Neon and am having this too. With the same behavior of it happening with changes of window focus.

I don't have any issues arrising from this or related to this other than the spam in the logs 
Operating System: KDE neon 6.0
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.5.0-45-generic (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 6700 XT
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X470 AORUS GAMING 5 WIFI

Same issue here.

Operating System: Arch Linux 
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.10.2-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 2600X Six-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600 XT

The error is triggered when the AppMenu plasmoid calls KeyboardIndicator.KeyState at line 130 (https://invent.kde.org/plasma/plasma-workspace/-/blame/2e75eb8b64c7915fc9c1c0452f6a5ea50d62fc39/applets/appmenu/package/contents/ui/main.qml#L130-133)

This happens regardless of whether AppMenus are enabled.

To be honest, I got completely lost trying to figure out the execution flow involved here. But changing "Qt.Key_Alt" to, say, "Qt.Key_Enter" changes the resulting error to
> org.kde.plasma.keyboardindicator: Unknown key Qt::Key_Enter

It looks like KeyboardIndicator can't resolve the Key enum from the Qt::Core namespace? I haven't wielded C++ in anger in a generation, so this bread trail is the best I can do at the moment.

It seems like this is triggered in Garuda KDE, as multiple users encounter it on this distro (me included)

I think I inadvertently fixed this by temporarily trying to merely *reduce* the number of errors by moving the KeyboardIndicator.KeyState element out of the Repeater element. Doing this didn't just reduce the errors, it eliminated them.

I hesitate to file a MR at the gitlab repo because I have no idea why moving the element up two levels in the hierarchy resolved the error. On the other hand, I think it's objectively correct to move the KeyboardIndicator.KeyState out of the Repeater element because there is no reason to run that code for each element in the app menu. 

Here is the relevant commit at my fork of the GitHub mirror of the official repo: https://github.com/rallyemax/plasma-workspace/commit/62c615773d7f4f618b44b6aa98c9becb1e55e3fa

You can try the fix yourself by modifying your installed QML file. In Arch, the file is at /usr/share/plasma/plasmoids/org.kde.plasma.appmenu/contents/ui/main.qml. You'll need to restart the session (log out and back in) for the change to become effective. Obviously changing system files like this can be risky, so proceed carefully and at your own risk. You can always safely restore by reinstalling the package.

Can anyone who knows QML explain why this change eliminated the error? I looked through QML docs and even the QML Book, but I didn't find any hints. It almost feels like KeyState being invoked from the MenuDelegate element scope is the issue, since MenuDelegate doesn't import KeyboardIndicator ... but that feels like a super restrictive interpretation of lexical scope and just feels like the wrong explanation.

I am hip-firing here while blindfolded without reading much of the codebase, but if you change it to Qt::Key_CapsLock instead of trying Enter, does it work?

If yes, https://invent.kde.org/libraries/plasma-wayland-protocols/-/merge_requests/82 is relevant.

If not, sorry, was just digging through both that PR and this issue by happenstance.

(In reply to Martin from comment #18)
> I am hip-firing here while blindfolded without reading much of the codebase,
> but if you change it to Qt::Key_CapsLock instead of trying Enter, does it
> work?
> 
> If yes,
> https://invent.kde.org/libraries/plasma-wayland-protocols/-/merge_requests/
> 82 is relevant.
> 
> If not, sorry, was just digging through both that PR and this issue by
> happenstance.

YES!
 
Changing to Qt.Key_CapsLock eliminates the error. Changing to any of the keys proposed for addition in that MR causes the error to reappear.

What confuses me is why merely lifting the element two levels in the hierarchy also prevents the error from appearing. But that feels like a red herring now, and likely due to my limited understanding of QML.

Nice catch! I was trying to chase it down and got as far KModifierKeyInfo in the KGuiAddons package. I got a bit stumped figuring out how the m_modifierStates hash gets populated. It looks like it gets populated from the keystate Wayland protocol you linked. I just can't keep up with these deep hierarchies of abstractions anymore.

So it looks like this set of changes (https://invent.kde.org/plasma/plasma-workspace/-/commit/72f1018f0c989ed2b316dff487c3b517b6b2e89d) changed the key lookup mechanism from something that worked to the incomplete keystate protocol that no longer does?

(In reply to rallyemax from comment #17)
> I think I inadvertently fixed this by temporarily trying to merely *reduce*
> the number of errors by moving the KeyboardIndicator.KeyState element out of
> the Repeater element. Doing this didn't just reduce the errors, it
> eliminated them.

This is incorrect. Moving the element two levels up caused it to be processed only a couple of times per session, it seems. The error appeared twice near the start of the session, and I missed it because I was "--following" the journal.

Please disregard this line of inquiry.

(In reply to rallyemax from comment #19)
> (In reply to Martin from comment #18)
> > https://invent.kde.org/libraries/plasma-wayland-protocols/-/merge_requests/
> 
> YES!
>  

Then I suppose this issue will fix itself™ when that PR is merged and the affected component is rebuilt, as alt is being added to the list of the state keys.

Whether that's a good thing or not, I do not know.

I'm also getting this after switching to Wayland, also plasmashell's memory usage grows over time, it's mandatory to keep restarting it periodically so it doesn't freeze the computer.

Between the sea of "org.kde.plasma.keyboardindicator: Unknown key Qt::Key_Alt" there are some:

kf.windowsystem: static void KX11Extras::forceActiveWindow(WId, long int) may only be used on X11

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: EndeavourOS
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2

I can no longer reproduce this after upgrading to 6.2

Operating System: Arch Linux 
KDE Plasma Version: 6.2.0
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.3
Kernel Version: 6.6.54-1-lts (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 7900X 12-Core Processor
Memory: 30.6 GiB of RAM
Graphics Processor: AMD Radeon RX 6800
Manufacturer: ASUS

Git commit 333ba248641023d80ced18012e8cef45bbb71edb by Nicolas Fella.
Committed on 04/11/2024 at 13:35.
Pushed by nicolasfella into branch 'master'.

kmodifierkeyinfo: Update to v5 of the Wayland protocol

This includes information about modifiers, not only lock keys, so we can e.g. query whether Alt is pressed
Related: bug 483657

M  +18   -1    src/util/kmodifierkeyinfoprovider_wayland.cpp

https://invent.kde.org/frameworks/kguiaddons/-/commit/333ba248641023d80ced18012e8cef45bbb71edb