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!!!