Layout toggle prevents shortcuts from going through

[YaLTeR]

Hello! Sorry if this isn't the correct place to report this issue.

I'm using sway (a Wayland compositor), which uses libxkbcommon for keyboard layout configuration, and I'm hitting what seems like the same issue as this one in xserver. I'm using two keyboard layouts and switch between them with Alt+Shift, so the settings are as follows:

xkb_layout us,ru
xkb_options grp:alt_shift_toggle

Unfortunately, this prevents me from using any Alt+Shift+something hotkeys. Running interactive-wayland and pressing Shift then Alt then Down produces the following output:

seat0: keysyms [ Shift_L          ] unicode [  ] layout [ English (US) (0) ] level [ 0 ] mods [ Mod2 ] leds [ Num Lock ]
seat0: keysyms [ ISO_Next_Group   ] unicode [  ] layout [ English (US) (0) ] level [ 1 ] mods [ -Shift Mod2 ] leds [ Num Lock ]
seat0: keysyms [ Down             ] unicode [  ] layout [ English (US) (0) ] level [ 0 ] mods [ Shift Mod2 ] leds [ Num Lock Group 2 ]

so Alt immediately switches the layout on press and Down doesn't get it as a modifier. The expected behavior is for the hotkey to work and for the layout to switch only on Alt+Shift by itself without additional keys.

[bluetech]

Yes, this is the infamous "need to kick hotkeys" issue of the XKB specification. xkbcommon is already mentioned in that issue, so I'll close this one in order to keep the discussion in one place.

[YaLTeR]

So... what's the status on at least fixing it in xkbcommon? It's not very clear from that issue.

[whot]

The issue is that the XKB spec explicitly says "you need to do it on press". That bug says "please do it on release". And while there's a patch, there hasn't been (afaict) a good analysis of what would get affected and where it would break beyond a "works for me!".

XKB is nasty enough as it is and subtle things like this have a tendency to come back 5 years later when we realised we've badly broken something. And then you're stuck between reverting to the old behaviour (and thus breaking the last 5 years) or keeping the new behaviour (and thus breaking everything before).

[xyzz]

Is there a similar patch for libxkbcommon? I looked at the codebase for a bit and it's all very different from xorg, no idea how the referenced xorg patch would apply. (& I don't care if that out-of-spec behavior breaks other stuff on my system)

[bluetech]

There is no similar patch to xkbcommon. If someone wants to work on it, I at least would certainly consider/evaluate it. A good place to start is probably work done by Andreas Wettstein for xorg: https://bugs.freedesktop.org/show_bug.cgi?id=865#c159

[xyzz]

Thanks! For now, with help from sway's IRC, I've managed to workaround it in sway (and for benefit of people coming through google):

input "type:keyboard" {
    xkb_layout us,ru
}

bindsym --release Ctrl+Shift_L input * xkb_switch_layout next

hopefully somebody could figure how to do it in libxkbcommon properly.

[leonardopsantos]

The issue is that the XKB spec explicitly says "you need to do it on press".

OK, but has that considered the modifier keys? Action on press for modifier keys makes no sense at all.

XKB is nasty enough as it is and subtle things like this have a tendency to come back 5 years later when we realised we've badly broken something.

As a developer I completely understand where you're coming from. but I also think we should be able to confidently improve the user experience. I don't think this bug should have been closed as the problem itself still exists. By closing the bug the maintainers are essentially saying they don't care for the users who are facing this problem.

Please re-open the bug.

[bam80]

Please re-open and let's reconsider.

[bam80]

The issue is that the XKB spec explicitly says "you need to do it on press". That bug says "please do it on release". And while there's a patch, there hasn't been (afaict) a good analysis of what would get affected and where it would break beyond a "works for me!".

If there are some real concerns, let's discuss them. But that formal statement maybe didn't include modifier keys in mind, as noted above.
Anyway, we could make the new behavior opt-in or opt-out.

[technic]

Bug is not fixed. Reopen!

[guss77]

@bluetech (The xkbcommon maintainer that originally closed this issue) said:

There is no similar patch to xkbcommon. If someone wants to work on it, I at least would certainly consider/evaluate it. A good place to start is probably work done by Andreas Wettstein for xorg: https://bugs.freedesktop.org/show_bug.cgi?id=865#c159

Which sound promising. I'm not actually volunteering the do that work - I don't have either the knowledge nor the time for that, but considering the 2 year cycle that this issue crops up for me, maybe I will be able to next time - in about 2 years. I hope that it won't be that long until we get some more movement and IMHO reopening this ticket and discussing what ever concerns people have about rocking the boat - will be a good first step.

[SlowTypist]

Any chance of reopening this? Now it migrated to Wayland with the same bug from TWENTY YEARS AGO!!!

[guss77]

The recent Plasma 6.1 introduced a very good workaround using the "multi-modifier-only shortcuts" feature for Plasma's KGlobalAccel daemon. With that configuration, and under KDE Plasma, the libxkbcommon configuration can be removed and replaced with something that works.

I would still love to see this issue resolved - for the sake of non-Plasma libxkbcommon users - but for me this issue is obsolete.

[ezhan]

In KDE 6.1 Beta nothing changes for me using CTRL-Shift as language modifier - CTRL-T does not reopens closed tab, CTRL-Shift-cursor keys do not select the text...

Should I enable some setting?

[wismill]

@guss77 That’s great news, thank for sharing this.

I would still love to see this issue resolved - for the sake of non-Plasma libxkbcommon users

Agreed, but workaround is not easy as we’ll have to go against the XKB protocol without breaking anything else.

@ezhan Please report to the KDE team directly, using their website.

[guss77]

In KDE 6.1 Beta nothing changes for me using CTRL-Shift as language modifier - CTRL-T does not reopens closed tab, CTRL-Shift-cursor keys do not select the text...

Should I enable some setting?

You will need to change your configuration - you can review the discussion in the link that I shared, or do this:

1. In the system settings' keyboard, disable the "main shortcuts"
2. Setup the shortcut you want using "alternative shortcut".

[ezhan]

It seems it fixes some other issues, but not CTRL-Shift one. What combination do you use for language change?

[wismill]

Please do not use our repo for KDE issues. While the first comment was very welcome, the next ones are out of topic here. Thank you for your understanding.

[ezhan]

Now I have the exact guide to workaround this problem in KDE 6.1 and newer (release is scheduled for next week, 18.06.2024).

1. Open Settings -> Keyboard -> Layouts
2. Delete the assigned MAIN shortcut (CTRL-Shift or ALT-Shift), you may have to uncheck it in "Key Bindings" and apply.
3. Assign Ctrl+Shift as ALTERNATIVE shortcut and apply.

Now it works as desired!

@wismill Please do not delete this comment, as it will help many people to override XKB defaults. Please copy this guide to #420 as well, so more affected users can find it easily. Thank you.

[wismill]

@ezhan I have edited you first post in #420, thanks for the feedback.

Please note that my previous comment about “out of topic” what about KDE debugging session. I do not mind a few messages, but your issue did not seem to be solved that easily, thus my request to use a canal better fitted for it. On the other hand the conclusion is welcome here.

@guss77 By the way I am a KDE user too and I always welcome the many fixes and features KDE team offers us regularly. Keep up the great work!

As for the deleted post, it was just hate speech. For those I do apply the maximum moderation: delete the message. I do not take lightly such measure. As you can see in #420, most comments are negative but are still there, because I cannot expect people to know the whole story. I did not until relatively recently either (my first contribution in this project was in 2021). But I locked #420 because I am not going to justify how I use my free time to people that do not understand altruism.