Bug 503781

After diagnosing an apparently unrelated problem of my Shift keys getting stuck in RDP in Remmina, and also showing as stuck (pressed when they're not) on webpage keyboard tester sites, I disabled the option "Shift cancels Caps Lock" that I had enabled, and all my problems disappeared.

I have renamed the bug accordingly. This option is apparently very buggy.

I cannot reproduce. It may depend on the keyboard layouts you are using.

Could you provide the content of your configuration in `~/.config/kxkbrc` ? Do you use a Wayland or X11 session?

(In reply to Wismill from comment #2)
> I cannot reproduce. It may depend on the keyboard layouts you are using.
> 
> Could you provide the content of your configuration in `~/.config/kxkbrc` ?
> Do you use a Wayland or X11 session?

I'm on a Wayland session. I'd be happy to provide any other details you need to diagnose the problem.

Here is my kxkbrc config (with the problematic option turned on):
___
[Layout]
DisplayNames=EN,BG
LayoutList=us,bg
Options=caps:ctrl_shifted_capslock,shift:breaks_caps
ResetOldOptions=true
SwitchMode=WinClass
Use=true
VariantList=,phonetic
___

I just tested another option that is similar -  "Both shifts together enable Caps Lock; one Shift Key disables it"
This again causes problems when switching input modes - Shift+Ctrl works, but not the other way around.
However, this option doesn't seem to get the shift key stuck in keyboard tester apps (and Remmina RDP sessions) like the "Shift cancels Caps Lock" options does. (I'm using https://en.key-test.ru/ to test due to high visibility when a key is held pressed, but all of the ones I tested show this bug)
Funnily enough, with BOTH of these options enabled, the "shift stuck" problem goes away, but you can no longer enable caps with both shifts (I suspect one option enables it, the other instantly disables it, since the second shift press is still a shift press, lol).

Hope this is useful.

And upon further further investigation, "Both shift together enable Caps Lock" breaks switching too. I've tested all the other checkboxes under "compatiblity options" and "caps lock behavior" just in case - only those 3 break it:

"Shift cancels Caps Lock"
"Both shift together enable Caps Lock"
"Both shifts together enable Caps Lock; one Shift Key disables it"

I've additionally tried removing the normal hotkey for switching and using the checkbox under the "Switching to another layout" section - "Ctrl+Shift", and it's again affected by the aforementioned 3 options in the same way. I've also tried the same under "Configure Switching" > "Legacy Shortcuts", same result.

Sorry for the 3-comment spam, but users should really be able to edit their post on here :D

Don’t you miss the option to switch layouts with `Ctrl+Shift`: `grp:ctrl_shift_toggle` in the config file? Or do you set the shortcut manually?

What happens is that the option `shift:breaks_caps` is incompatible with the option `grp:ctrl_shift_toggle`. 

But I also suspect that the “stuck” behavior is due to `shift:breaks_caps` not setting the `Shift` symbol, only the action that breaks caps, so that apps that rely on symbol detection rather than modifier state may have issues. If so, this can be fixed upstream in xkeyboard-config.

Could you create the file `~/.config/xkb/symbols/shift` with the following content:

    partial modifier_keys
    xkb_symbols "breaks_caps" {
        key <LFSH> {
    	type[group1] = "ALPHABETIC",
    	symbols[1]= [Shift_L, Shift_L],
    	actions[1] = [ SetMods(modifiers=Shift), SetMods(modifiers=Shift+Lock,clearLocks) ]
        };
        key <RTSH> {
    	type[group1] = "ALPHABETIC",
    	symbols[1]= [Shift_R, Shift_R],
    	actions[group1] = [ SetMods(modifiers=Shift), SetMods(modifiers=Shift+Lock,clearLocks) ]
        };
    };

then restart your session with the `shift:breaks_caps` option activated and test the behavior in RDP in Remmina again?

(In reply to Wismill from comment #6)
> Don’t you miss the option to switch layouts with `Ctrl+Shift`:
> `grp:ctrl_shift_toggle` in the config file? Or do you set the shortcut
> manually?
> 
> What happens is that the option `shift:breaks_caps` is incompatible with the
> option `grp:ctrl_shift_toggle`. 
> 
> But I also suspect that the “stuck” behavior is due to `shift:breaks_caps`
> not setting the `Shift` symbol, only the action that breaks caps, so that
> apps that rely on symbol detection rather than modifier state may have
> issues. If so, this can be fixed upstream in xkeyboard-config.
> 
> Could you create the file `~/.config/xkb/symbols/shift` with the following
> content:
> 
>     partial modifier_keys
>     xkb_symbols "breaks_caps" {
>         key <LFSH> {
>     	type[group1] = "ALPHABETIC",
>     	symbols[1]= [Shift_L, Shift_L],
>     	actions[1] = [ SetMods(modifiers=Shift),
> SetMods(modifiers=Shift+Lock,clearLocks) ]
>         };
>         key <RTSH> {
>     	type[group1] = "ALPHABETIC",
>     	symbols[1]= [Shift_R, Shift_R],
>     	actions[group1] = [ SetMods(modifiers=Shift),
> SetMods(modifiers=Shift+Lock,clearLocks) ]
>         };
>     };
> 
> then restart your session with the `shift:breaks_caps` option activated and
> test the behavior in RDP in Remmina again?

 `grp:ctrl_shift_toggle` is the legacy shortcut, which I also tried and had the same behavior. I guess the non-legacy one is handled like any other KDE global shortcut.

Soo, I did as you said (had to create those folders, they weren't there by default), and hot damn, that fixed BOTH the "shift stuck" in Remmina AND the keyboard switching shinanegans. You're a magician, sir.

Glad to know it fixed your issue! I filed a bug fix upstream: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/823; it should be available in the upcoming xkeyboard-config 2.45 release.

FYI the `shift:breaks_caps` still has the issue that it may stuck the Caps, see: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/74#note_2191670. 

The trick is to press *no other key* until you *release* `Shift`.

I will work on a fix for xkbcommon 1.10, but it will require a major update of xkeyboard-config, so be patient 😅

(In reply to Wismill from comment #9)
> FYI the `shift:breaks_caps` still has the issue that it may stuck the Caps,
> see:
> https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/
> 74#note_2191670. 
> 
> The trick is to press *no other key* until you *release* `Shift`.
> 
> I will work on a fix for xkbcommon 1.10, but it will require a major update
> of xkeyboard-config, so be patient 😅

Yes, I noticed this behavior during my testing. I was wondering if it was a bug or a "feature". Glad it turns out to be a bug, since people who are used to how this option functions on Windows might be baffled at how it works on Linux.
Good luck with that fix, and thanks again for fixing my problems with this feature. :)

(In reply to Wismill from comment #9)
> I will work on a fix for xkbcommon 1.10, but it will require a major update
> of xkeyboard-config, so be patient 😅

Hello! It seems this issue has cropped up again, and this time "Shift cancels Caps Lock" doesn't seem to be the culprit.
I recently updated my KDE version to 6.5.3, and there are problems with both the legacy and non-legacy ways of switching input methods:

NON-LEGACY (binding Ctrl+Shift or any other key combination directly in the "Keyboard" settings menu) has the problem of not releasing either one of the two keys after executing the command, which is apparent on this test website (en.key-test.ru/), and creates problems in applications like Remmina and Aseprite.

LEGACY (from the "key bindings" checkboxes submenu) has a different problem entirely - It executes the switch on KEY DOWN, not on key UP, which screws with other keyboard combinations that use the two modifier keys (for example Ctrl+Shift+Z to "Redo" in Aseprite - it doesn't recognize the last modifier keypress)

Both of these cases were tested with and without the hacky "shift" file you gave me, and without any "Shift cancels Caps" options. It happens with other keybinds too, like the default Alt+Shift, which makes the issue actually kinda severe (assuming it affects everyone?).