Keyboard input regressions

[eigengrau]

Sorry for the generic title, but I’m not quite sure yet how these observations pattern, or what I might have missed upon first inspection. After upgrading to gd5be6d2, I’ve observed the following thus far:

Return key not working

My return-key doesn’t work anymore. I have return mapped into the alphabetic keys (in combination with a modifier). On d5be6d2, the enter key now produces a character in the Unicode private use plane, namely U+10AD13. The xev sequence for return is as follows:

KeyPress event, serial 25, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2373118, (890,460), root:(934,528),
    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 0x2600001,
    root 0x49b, subw 0x0, time 2373414, (890,460), root:(934,528),
    state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
"   XmbLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2373494, (890,460), root:(934,528),
    state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2373774, (890,460), root:(934,528),
    state 0x82, keycode 108 (keysym 0xff7f, Num_Lock), same_screen YES,
    XKeysymToKeycode returns keycode: 94
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2374686, (890,460), root:(934,528),
    state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Numblock not working

My numblock is also accessed via the alphabetic keys in combination with a modifier. However, this doesn’t produce any output anymore as of d5be6d2. xev example for the numeral 1 below.

KeyPress event, serial 32, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2444858, (713,570), root:(757,638),
    state 0x0, keycode 94 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2445115, (713,570), root:(757,638),
    state 0x0, keycode 87 (keysym 0xffb1, KP_1), same_screen YES,
    XLookupString gives 1 bytes: (31) "1"
    XmbLookupString gives 1 bytes: (31) "1"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2445242, (713,570), root:(757,638),
    state 0x0, keycode 87 (keysym 0xffb1, KP_1), same_screen YES,
    XLookupString gives 1 bytes: (31) "1"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x2600001,
    root 0x49b, subw 0x0, time 2446107, (713,570), root:(757,638),
    state 0x82, keycode 94 (keysym 0xff7f, Num_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Compose sequences producing more than one character

While compose-sequences which only produce a single character still work, all sequences that produce more than one character don’t produce any output anymore. Can you advise whether this might be an upstream issue? I don’t absolutely need these sequences in rofi, but if this is a problem in libxkbcommon, I might want to tickle them about it.

What still works

At first I was afraid all the extra shift levels might be broken, but most things still appear to work. So, the control key plane mostly works (with exception of the enter key and the numblock), as do the greek/maths and puncuation symbol levels.

[sardemff7]

My return-key doesn’t work anymore. I have return mapped into the alphabetic keys (in combination with a modifier).

How is that “mapping” done exactly?

Which keymap are you using? Is this a setup we can test on any keyboard or is it a specific hardware with Fn-like key?

[eigengrau]

Which keymap are you using? Is this a setup we can test on any keyboard or is it a specific hardware with Fn-like key?

This is using a variant of the AdNW layout, for regular keyboards. I’m not super versed in XKB things, but @DaveDavenport might have an idea what’s wrong. At least last time when the levels didn’t work he got it figured out somehow. Though this issue might be different.

My exact layout can be got by running this script, (layout reference). The return keysym can be triggered with the red modifier + comma.

[sardemff7]

Can you check if binding "Alt+return" works?
You use ISO_First_Group, which your keymap file aliases to Mod5, I think.
We have Mod5 as another Alt value (AltGr from most of keymap files), so while xev says state is 0x0, we may detect it as Alt being down.

[eigengrau]

Can you check if binding "Alt+return" works?

When I try Alt + (regular) Return (<LALT> + <RTRN>; reference), nothing happens (no private use plane character either). <RALT> + <RTRN> will cause the rofi selection to be executed.

[sardemff7]

Let’s be crystal-clear here.

You are:

• running rofi -show run -kb-accept-entry Alt+Return,
• and using your expected key sequence, i.e. ISO_First_Group (from your xev output) + an alphabetic key?

And you get:

• no more unexpected character (U+10AD13),
• the expected “accept-entry” rofi action.

Is that right?

[eigengrau]

You are:

running rofi -show run -kb-accept-entry Alt+Return,
and using your expected key sequence, i.e. ISO_First_Group (from your xev output) + an alphabetic key?

Okay, I tried this as specified (didn’t know about -kb-accept-entry, it’s not in the manpage), and what I get is the U+10AD13 character.

[DaveDavenport]

thanks for testing this! was afraid we had to re-spend part of the effort going to the xkb.

hopefully we can get it fixed quickly :D.

[sardemff7]

I tried the Neo and AdNW layouts, from upstream xkeyboard-config (i.e. those installed on my system already) and they work correctly with rofi.
I read your script, and you can find in it the reference to that U+10AD13 character (0x110AD13 actually) in the definition of Return.
Edit: Where did you get that script, or at least the layout part?

Still investigating the Numlock issue.

[sardemff7]

Fixed the multi-character compose sequences in abe4447.

[eigengrau]

I tried the Neo and AdNW layouts, from upstream xkeyboard-config (i.e. those installed on my system already) and they work correctly with rofi.
I read your script, and you can find in it the reference to that U+10AD13 character (0x110AD13 actually) in the definition of Return.
Edit: Where did you get that script, or at least the layout part?

Ohh, thanks for looking into this so much. I took another look at that script myself, and I remembered there’s something special about the implementation of those keys, namely: I’ve been told they’ve been implemented as redirects. In the script, there’s the XKB statement interpret 0x110AD13 { action= Redirect(key=<KPEN>, clearMods=Lock+Mod3+Mod5); };. Can you advise whether this might be an upstream issue in libxkbcommon with interpreting these redirect mechanisms? (Edit: this is because the enter key works pretty much everywhere else)

The script is generated using a tool from AdNW-layout’s upstream. While a default version of that layout has been pushed into Xorg, the script shipped by them will generate XKB-definitions or script files to use some layout variants.

Still investigating the Numlock issue.

FWIW, this issue might be related to Return not working, since, or so I’ve read, the overlay numblock is implemented via redirects as well.

[eigengrau]

Hm, though it’s weird. Because the combination I’m pressing shouldn’t trigger that redirect. In fact xev reports it as regular Enter, not KP_Enter.

[sardemff7]

FWIW, this issue might be related to Return not working, since, or so I’ve read, the overlay numblock is implemented via redirects as well.

Just for the record, the Neo layout has the same issue with Numlock, and not only the special one, but also the dedicated key. I tested against the pre-GLib/XCB rofi, and it has the same issue.

I tested with Geany (a GTK+3 client, which is also using libxkbcommon). The (special) Return key works in Neo, not with script. However, the character seems to be a special character that the text editor widget treats as a line return.
Numlock is interpreted as Tab with both Neo and your script.

[eigengrau]

Numlock is interpreted as Tab with both Neo and your script.

That’s actually expected, if you’re talking about the physical numlock key. Both AdNW and Neo2 don’t have a classical numlock. Instead they use numlock like a regular key, with different shift levels.

The redirect-related stuff with the keypad doesn’t affect the physical keypad, but only the one that is superimposed on the alphabetic keys, and engaged with a modifier (or locked, when both modifiers are pressed at the same time).

[eigengrau]

Just for the record, the Neo layout has the same issue with Numlock, and not only the special one, but also the dedicated key. I tested against the pre-GLib/XCB rofi, and it has the same issue.

I checked again which version I had been upgrading from. The “special” enter key and the overlaid numblock were last functioning with rofi 5a20482, but I guess that’s not much help since the keyboard handling was totally different?

[sardemff7]

Do you use any other libxkbcommon client, like any GTK+3 or Qt 5 client? If they are getting everything right, then it’s probably on our side.

[eigengrau]

With GTK+3, everything works as expected. I also tried with geany, just in case not all GTK3-apps use libxkbcommon. I then tried with Calibre (Qt5) text entry fields, and I can see similar, but non-identical issues (return doesn’t do anything, the overlay numblock is interpreted like arrow-keys).

[eigengrau]

Hmm, seems that libxkbcommon doesn’t implement support for interpret actions… :(

Though I believe this still leaves the Return issue unexplained, since that’s not implemented as a redirect afaict. Hmm.

Also, I wonder why the overlay numpad still work in Geany then…

[sardemff7]

Sorry for the delay.

I think the proper solution is to use a less hacky way to get your variant. Base Neo and AdNW have the Return key working, so it is the variant that fails, and since the key is at the same place, I am not sure why. (I misread the dependency list and GTK+3 is not using libxkbcommon for the X11 backend, but Qt5 does.)
Are there many changes between AdNW and your variant? It could be trivial to just override a few keys with a proper keymap file.

As for the numlock, since it fails with Neo too, and more and more software are porting to libxkbcommon, I hope they will find a way to do it “correctly”.

[sardemff7]

Can we consider this as “should be fixed in AdNW/Neo and/or libxkbcommon”?

[eigengrau]

Hi, sorry for not reacting sooner. I think AdNW might not want to fix the redirect stuff upstream, since the definitions are okay as per xkb. I might need to try to change the script on my machines to not use redirects if libxkbcommon doesn’t support them. In any case this can’t be addressed in rofi.

This leaves the overlaid return key, which doesn’t use redirects. Unfortunately I don’t have the expertise to say whether this is a problem in libxkbcommon or rather in rofi.

[sardemff7]

More and more applications are being ported to libxkbcommon. Qt5 uses it for both X11 and Wayland. GTK+3 uses it for Wayland and GNOME will eventually default to Wayland.
The point is: layouts will have to update sooner or later.

For your specific use case, do not forget that the overlay Return key is working in plain AdNW, only your variant is getting that weird character. And looking at your script, it does a lot of thing for little gain.
I really think there is a better way to use your variants, by modifying way less things from the base AdNW layout. And considering the xkb keymap file format, you could probably just “source” the base file then modify only what you need on top of it.

About numlock, the hardware key (on the numpad) using either the Neo or AdNW layout is not working here, with a GTK+3 app or old (non-xkbcommon) rofi. So I am not sure that is xkbcommon-related at all.

[eigengrau]

Thanks for your input @sardemff7. I finally got around to regenerating the layout without redirects for the overlay keypad, and these keys seem to work fine now (including keypad enter, so it seems redirects were playing nito this issue as well). Thanks for helping me investigate this, since this also resolves a similar issue I’ve observed in some Qt applications.

The point is: layouts will have to update sooner or later.

Yea, I was a bit disappointed at first that they wound up throwing some xkb features out. Given the somewhat precarious ecosystem changes entailed in wayland, xkbcommon was something that reassured me that things wouldn’t be stirred up without some forethought. Then again I don’t know enough about xkb to judge whether redirects are so useful, so maybe nothing is lost. In the script docs it said were meant for compatibility with older, non-xkb clients, so if that’s all maybe it won’t be noticable.

Anyway, I think we have everything covered (KP return, numblock, multi-char composé sequences), so I’m closing this. Thanks again for giving us rofi.

[DaveDavenport]

@eigengrau thanks for all your work!

[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.