Shift left/right not recognized anymore

[eigengrau]

Version

Version: 1.3.1 - 1.3.1-645-g252d89a1 (master)

Configuration

https://gist.github.com/anonymous/2060824de81bfb2f23d531692c503fb0

Steps to reproduce

Using the keyboard layout loaded from here, press shift + alt_gr+ qwertz-s.

KeyPress event, serial 28, synthetic NO, window 0x4800001,
    root 0x1fa, subw 0x0, time 6258852, (824,720), root:(871,767),
    state 0x0, keycode 108 (keysym 0xfe0c, ISO_First_Group), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x4800001,
    root 0x1fa, subw 0x0, time 6258853, (824,720), root:(871,767),
    state 0x82, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x4800001,
    root 0x1fa, subw 0x0, time 6260454, (824,720), root:(871,767),
    state 0x1, keycode 113 (keysym 0xff51, Left), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4800001,
    root 0x1fa, subw 0x0, time 6260593, (824,720), root:(871,767),
    state 0x1, keycode 113 (keysym 0xff51, Left), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4800001,
    root 0x1fa, subw 0x0, time 6260794, (824,720), root:(871,767),
    state 0x83, keycode 108 (keysym 0xfe0c, ISO_First_Group), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4800001,
    root 0x1fa, subw 0x0, time 6260830, (824,720), root:(871,767),
    state 0x1, keycode 62 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XKeysymToKeycode returns keycode: 50
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

What behaviour you see

Nothing happens.

What behaviour you expect to see

Switch to previous modi.

[DaveDavenport]

FWIW: Works for me on normal us keyboard layout.

[eigengrau]

Yea, works for me as well if I use the regular arrow key instead of the overlaid arrow key. The overlaid one used to work though at least in g0b03fc9. I’ll see if I can bisect.

[sardemff7]

At first glance, it looks a lot like #354, but you’re saying it works in 0b03fc9, which will probably lead to a breakage in a9199e3, or maybe in 6f117c3? If the latter, please try Shift+AltGr+Left as a binding. It would be a bit weird, but custom Neo layouts are not exactly libxkbcommon-friendly, as they rely on old and unmaintained XKB features. (I see redirects in your keymap.)

[eigengrau]

git bisect gave me a9199e3 as the first bad commit.

@sardemff7 If I bind Shift+AltGr+Left in keyb.c explicitly, the combo is recognized. As for libxkbcommon, in mpv (also using libxkbcommon for input) the overlay combo is transparently recognized (seems odd though seeing that libxkbcommon doesn’t support redirects). My generator script has an option to implement overlay control keys without redirects (as I did with the keypad keys back then), but while this seems to help rofi, it breaks functionality in some older X apps as well as GTK3+ (which is weird since GTK3 is also using libxkbcommon).

[sardemff7]

Can you test the wip/wayland branch, building with --with-display-backend=xcb? The code there is closer to the libnkutils code, so it if fails too, I’d have a better pointer at where to look.

Btw, GTK+3 uses libxkbcommon on Wayland, but the old X11 code on X11. :-)

[eigengrau]

@sardemff7 Thank you! On wip/wayland, the input isn’t recognized as well. When I explicitly bind Shift+AltGr+Left, rofi fails to launch with «The XCB connection to X server had a fatal error: 0».

[sardemff7]

So it’s an issue with how I detect pressed and consumed modifiers. I’ll try to get your layout working here and do some tests.

[eigengrau]

So that’s possible despite there being redirects? I mean, mpv seems to recognize the keys, but that seems surprising to me as well, in retrospect. In any case, if this only concerns adnw-gen generated layouts, don’t bother in case it’s too much work, since there’s probably only a handful of users. I’d go for the redirectless variant if this wouldn’t break other apps. The adnw variant shipped with Xorg seems to not suffer from this, but I was hoping I wouldn’t need to fork it (I have some keysym changes), and it looks like AdNW copy/paste keys (not supported by the stock Xorg layout) can only be implemented via redirects.

[sardemff7]

I just realised what your xev paste is telling us. Redirects are handled on the server side, and you can see keycode 113 is sent, not 39 as one would expect.
The real question is how did the previous code worked at all…

[sardemff7]

Hum, I get it, it doesn’t just send a fake keycode, it sends a fake keyboard state too. Previous code used that state while new code is using the cached state. So it’s once again a really annoying X11 design decision that’s getting in the way. I’ll add a workaround at some point, just need to design it properly to fit Wayland too.

[sardemff7]

Should be fixed in 8f8c43e, please let me know if it works.

[eigengrau]

Thank you so much sardemmf7! This resolves the arrow-key issue, and the copy-paste keys work now, as well! ❤️

So if I understand correctly this only works because Xorg handles the redirects on the server side, so it probably won’t work under Wayland. But this ought to buy me some time, at least. Thanks again!

[sardemff7]

Yes, on Wayland, clients just entirely rely on libxkbcommon to interpret keystrokes, and compositors too, actually, so redirects won’t work. But that means you can reliably test if things will work. :-)
Of course, the X11 clients you currently use (the one not loving the proper keymap) will probably not work via Xwayland either, though maybe you can still override the keymap stuff via xkbcomp, I don’t know.

[sardemff7]

FTR I reported a bug against Xorg server because key redirects should send a XKB_STATE_NOTIFY event according to a libxkbcommon developer.
Sadly, there would be quite a long time before a fix would spread, so we have to keep the workaround for a few more years, until we don’t care about Ubuntu LTS and Debian stable, I believe. :-)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.