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?