Bug 478208 - Caps Lock assigned to Last used shortcut still acts as a Caps Lock
Summary: Caps Lock assigned to Last used shortcut still acts as a Caps Lock
Status: REOPENED
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: 5.90.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: qt6, usability
Depends on:
Blocks:
 
Reported: 2023-12-07 12:40 UTC by Notare Alname
Modified: 2024-11-23 17:36 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
How related section of keyboard settings look now, for reference (22.47 KB, image/png)
2023-12-07 12:40 UTC, Notare Alname
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Notare Alname 2023-12-07 12:40:01 UTC
Created attachment 163976 [details]
How related section of keyboard settings look now, for reference

SUMMARY
The bug is directly related to this feature: https://bugs.kde.org/show_bug.cgi?id=403281
If I set Caps Lock as my preferred method of choosing the last layout, it does change the layout to the previous one, but also toggles Caps Lock, thus encompassing both functions. Since the main purpose of this feature is to allow the user to work with two layouts mainly, while still making other layouts available, its behavior should match the main keyboard layout switch which can be mapped to Caps Lock and pressing it won't trigger the initial Caps Lock functionality. 


STEPS TO REPRODUCE
1. Start a Plasma Wayland session 
2. Add 3 layouts
3. Bind "Last used shortcut" to Caps Lock
4. Press the Caps Lock key

OBSERVED RESULT
1. Layout changes to the previous one
2. But Caps Lock is also triggered, so now you have all your letters capitalized

EXPECTED RESULT
1. Layout changes to the previous one without triggering the native Caps Lock functionality

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux/KDE Plasma 5.90
(available in About System)
KDE Plasma Version: 5.90.0
KDE Frameworks Version: 5.246.0
Qt Version: 6.6.1

ADDITIONAL INFORMATION
I have tried Caps Lock behavior modifiers in Advanced section and none of them mitigates the issue, for example, "Caps Lock is disabled" does disable the Caps Lock key completely, providing neither of aforementioned functions.
Comment 1 Akseli Lahtinen 2024-02-29 10:04:41 UTC
Can confirm the bug on Plasma 6.

If i set main shortcut to capslock, this doesnt happen, but with last used shortcut it does.
Comment 2 Akseli Lahtinen 2024-03-01 11:20:43 UTC
I think this needs to be reported to upstream, since the XKB system is missing a rule for setting capslock non-toggling (acts like shift but doesnt remap to shift). I can disable capslock, but then the key does not work at all. Alternatively, XKB system could provide the "switch to last layout" option completely, and we could just use that like with layout switching.

One can modify `/usr/share/X11/xkb/compat/caps` to make capslock work like shift, but I think there should be easier way to do this provided by upstream, and I don't feel comfortable making a special case for capslock that modifies the aforementioned file. Besides, modifying this file requires root permissions.

Current workaround for anyone wishing to use capslock without it toggling capital letters:

1. Open `/usr/share/X11/xkb/compat/caps`
2. Change `LockMods` to `SetMods`
3. Log out and log back in
Comment 3 Nate Graham 2024-03-01 15:53:21 UTC
Excellent investigation. Akseli, would you be willing to file that bug report upstream, given that you've investigated and root-caused the issue already?
Comment 4 Akseli Lahtinen 2024-03-01 16:18:14 UTC
Yeah i can do that
Comment 5 Akseli Lahtinen 2024-03-04 08:49:14 UTC
I've reported it here to upstream https://github.com/xkbcommon/libxkbcommon/issues/464
Comment 6 Akseli Lahtinen 2024-03-04 16:17:23 UTC
I am actually unsure if this is upstream bug after all. We need to see if there is already a way to disable capslock toggling from KDE framework/plasma/etc. side.

If not, we probably need to ask for API implementation. See the linked github issue above.
Comment 7 Notare Alname 2024-03-18 22:35:11 UTC
So, reading the issue linked below, XKB guys point at Plasma and Plasma points at XKB, but from what I see Plasma can actually do something about it. Maybe the issue needs reopening? User experience with 3+ layouts is quite irritating without this feature working alright.
Comment 8 Wismill 2024-06-25 12:30:59 UTC
This cannot be implemented in XKB, because there is no support for “last *used* layout”.

The issue seems to be that Plasma intercepts the keysym Caps_Lock but not its *action*. Plasma should probably handle this at a lower level, before the modifiers state is propagated.
Comment 9 Valentin 2024-10-28 10:02:42 UTC
It still exists in Kubuntu KDE Plasma 6.1.5, so it blocks the feature for limiting the number of layouts for people who use Caps Lock to switch languages.
Comment 10 Nate Graham 2024-10-28 13:50:02 UTC
No need to change the version field; please leave those alone. Thanks.
Comment 11 Wismill 2024-10-28 16:37:44 UTC
As written above, this is Plasma bug, not an XKB one: the XKB action (locking Caps) is resolved while it should not, when Caps key is bound to a shortcut.

In order to mitigate this, you may:
1. Use one of the XKB options to switch layouts. There are located in “Key bindings” (top right button from keyboard config), then look for the group “Switching to another layout”. The “Caps Lock” option in this group allow you to switch to cycle the  layouts. But they are many other options which may fit better to your needs.
2. For power users: Tweak the XKB keymap by creating your own option. Follow the guide at: https://xkbcommon.org/doc/current/user-configuration.html#autotoc_md16:

cat $XDG_CONFIG_HOME/xkb/rules/evdev
! option = symbols
  custom:caps    = +my-caps

! include %S/evdev

$ cat $XDG_CONFIG_HOME/xkb/symbols/my-caps
partial alphanumeric_keys
xkb_symbols "deactivate caps" {
    key <CAPS> {        [   F35    ]       };
};

and adapt the “Discoverable layouts” section of the linked example with the files above. Now re-open the keyboard settings and activate your brand new option: you should be able to bind the CapsLock *key* as described in this issue, *without* locking the Caps. It does not mess with systems files and it will survive an update of those.

Note that I will not assist you further with tweaking XKB, so if you do not feel comfortable please stick with temp solution 1) and wait for the KDE devs to fix the issue.
Comment 12 Valentin 2024-10-31 09:18:32 UTC
Wismill, thank you so much. 
The first option is not okay for me because it doesn't allow me to set Caps Lock to change between the last used layouts, so the spare layouts feature becomes useless. 
But the second one is the real solution. Also here is the content of xkb/rules/envdev.xml for someone to copy. You can find this option in the Key Bindings -> Miscellaneous options. 
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xkbConfigRegistry SYSTEM "xkb.dtd">
<xkbConfigRegistry version="1.1">
    <optionList>
        <group allowMultipleSelection="true">
            <configItem>
                <name>custom</name>
                <description>Custom options</description>
            </configItem>
            <option>
                <configItem>
                    <name>custom:my-caps</name>
                    <description>Disable Caps Lock function</description>
                </configItem>
            </option>
        </group>
    </optionList>
</xkbConfigRegistry>
```
Comment 13 Dmitry Nezhevenko 2024-11-23 17:36:59 UTC
Same thing happens when using "Caps Lock" to switch keyboard layout: layout is switched, but also caps lock is toggled. 
It's possible to workaround this by using "Key bindings" page and assign Caps Lock as layout switcher. But unfortunately there is no way to assign it to "switch to last used layout"