[SOLVED] super+shift+2 interpreted incorrectly on xorg

sairuiu · 2020-12-06 03:03:42

super+shift+2 does not appear to be interpreted correctly on xorg, despite the modifier combination working correctly with any other key. The following is the xev output from holding shift+super and pressing and releasing 1, 2 and 3 in sequence with sxhkd off:

KeyPress event, serial 55, synthetic NO, window 0x2200001,
    root 0x7e2, subw 0x0, time 6541747, (629,1737), root:(2749,1808),
    state 0x43, keycode 10 (keysym 0x21, exclam), same_screen YES,
    XLookupString gives 1 bytes: (21) "!"
    XmbLookupString gives 1 bytes: (21) "!"
    XFilterEvent returns: False

KeyRelease event, serial 55, synthetic NO, window 0x2200001,
    root 0x7e2, subw 0x0, time 6541836, (629,1737), root:(2749,1808),
    state 0x43, keycode 10 (keysym 0x21, exclam), same_screen YES,
    XLookupString gives 1 bytes: (21) "!"
    XFilterEvent returns: False

KeyRelease event, serial 55, synthetic NO, window 0x2200001,
    root 0x7e2, subw 0x0, time 6542152, (629,1737), root:(2749,1808),
    state 0x43, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 55, synthetic NO, window 0x2200001,
    root 0x7e2, subw 0x0, time 6542271, (629,1737), root:(2749,1808),
    state 0x42, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 55, synthetic NO, window 0x2200001,
    root 0x7e2, subw 0x0, time 6542617, (629,1737), root:(2749,1808),
    state 0x43, keycode 12 (keysym 0x23, numbersign), same_screen YES,
    XLookupString gives 1 bytes: (23) "#"
    XmbLookupString gives 1 bytes: (23) "#"
    XFilterEvent returns: False

KeyRelease event, serial 55, synthetic NO, window 0x2200001,
    root 0x7e2, subw 0x0, time 6542706, (629,1737), root:(2749,1808),
    state 0x43, keycode 12 (keysym 0x23, numbersign), same_screen YES,
    XLookupString gives 1 bytes: (23) "#"
    XFilterEvent returns: False

Interestingly super+shift+2 press is interpreted as a KeyRelease event for Shift_L, and the release is interpreted as a KeyPress event for Shift_L. I assume there might be some conflict with this specific key combination, but I am not sure how I would investigate this. What would be a good place to start?

Last edited by sairuiu (2020-12-06 10:56:08)

seth · 2020-12-06 07:54:30

If the combo was grabbed, you'd still get a KeyamapNotify event.

See https://en.wikipedia.org/wiki/Rollover_(key) - what keyboard is this specifically and do you have another one available to test this (or did you test shift_r or a second super key)?

sairuiu · 2020-12-06 08:34:27

I'm using this keyboard. I suspected it may have been a rollover issue specific to the hardware for this exact key combination, but I tried with the built-in laptop keyboard and experienced the same behaviour.

For the previous testing, I was using caps_lock with `setxkbmap -option caps:super`and `xcape -e "Super_L=Escape"`, however using the actual super key and/or shift_r seem to work properly. It seems like it may be a more complicated issue. I am also using a jp106 keyboard layout.

To clarify:
caps+shift_L+2 doesn't work
caps+shift_R+2 works
super+shift_L+2 works
super+shift_R+2 works

This behaviour is observed on both the bluetooth and built-in keyboard. I am using an identical software configuration on another machine with no issue as well. Is there any other information I can provide?

seth · 2020-12-06 08:58:09

You could try "sudo libinput debug-events" to test the behavior below X11, but a HW conflict between caps and shift doesn't sound too exotic (because it's a wire that you won't need on their regular maps)
Just making caps:escape probably won't suit you as much?

sairuiu · 2020-12-06 10:12:49

Just tested with libinput debug-events. It appears to produce the same results (key release event on key press). I doubt it is a hardware issue as caps+shift+any_other_key functions as intended, as well as the same issue occurring on the built-in keyboard.

And yeah, caps:super is my primary usage. Using it as escape is almost exclusively for vi-like programs.

seth · 2020-12-06 10:34:41

Try a completely different software stack (old - or debian based ;-) live distro or windows) to test the keyboard.
The base of the rollover limitation is an incomplete matrix and it is "normal" to have some 3-key combos work while others don't.

sairuiu · 2020-12-06 10:55:54

I just tried the keyboard on another machine and that specific key combination did not work either... Thank you for the help and suggestions; I wouldn't have thought to confirm this otherwise. I am curious why it doesn't behave correctly on the built-in keyboard either, but maybe it's just a coincidence. I suppose it is just a hardware issue I can't get around, so I'll just have to get used to a different keybind for that one case. I will mark the thread as solved.

serxxx · 2022-07-27 10:37:00

FWIW, I have the same issue. Which laptop/window manager are you using? Here, I have:

- XPS13
- bspwm -- but it has also been doing this for a couple years with i3, so I think it's not related to the WM

xev shows events for the super and shift, but it does *not* show an event for 2 when those modifiers are pressed. 2 works fine otherwise, and all of the other numbers in the number row work fine.

Because xev doesn't show an event, I think it must be an issue with the X configuration on Arch.

2ManyDogs · 2022-07-27 12:27:50

serxxx, this topic is almost two years old and marked [SOLVED]. Please do not necrobump.

If you need help, please start a new topic and refer back to this one if you think it applies.

Closing.

Arch Linux

#1 2020-12-06 03:03:42

[SOLVED] super+shift+2 interpreted incorrectly on xorg

#2 2020-12-06 07:54:30

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

#3 2020-12-06 08:34:27

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

#4 2020-12-06 08:58:09

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

#5 2020-12-06 10:12:49

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

#6 2020-12-06 10:34:41

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

#7 2020-12-06 10:55:54

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

#8 2022-07-27 10:37:00

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

#9 2022-07-27 12:27:50

Re: [SOLVED] super+shift+2 interpreted incorrectly on xorg

Board footer