Problem with laptop xbindkeys not returning correct values

matcharles · 2021-03-26 23:19:48

Hello,

I don't know how to troubleshoot this problem. A couple weeks ago I started having trouble with my laptop (T490) because both of my "Brightness up/down" keys stopped working, but the command in the CLI still worked.After further investigations, I noticed that when running

 xbindkeys -k

and pressing both button, instead of getting the normal XF86MonBrightnessDown and XF86MonBrightnessUp, I would get nothing the Down button and XF86WakeUp for the Up button.

I tried booting a Fedora Live and xbindkeys recognize both as the same (Wakeup and nothing) but the brightness toggle works (presumably because it's using Gnome and I use bspwm)?

Anyways I'm pretty lost and while not a huge problem because I use aliases at the moment, it's still annoying knowing the buttons aren't correct.

I would assume it's related to the firmware maybe? In which case it would be a problem with Lenovo, but in case someone has an idea and wants to spare me the pain of dealing with them, I'd appreciate!

Thanks!

seth · 2021-03-27 07:03:51

Do you get output from "showkey" (on the console, don't run X11 at all)
They might be ACPI events rather than IO, https://wiki.archlinux.org/index.php/Ac … ht_control
Did you previously bind them to shortcuts?

matcharles · 2021-03-27 14:20:14

Hey thanks for this.

So running showkey in another TTY I get keycode 224 for Brightness Down and 225 for Brightness Up.

It's funny you mention ACPI because I seem to have an unrelated problem lately where once I unplug my AC adapter, every once in a while my CPU will turn crazy and there's nothing I can do but reboot to fix it. Suspend won't work either in this state. But this happens only once every couple of weeks and I can't seem to reproduce. But I digress!

They were indeed mapped using xbindkeys and stopped working one day (I don't use them very often, which is why I can't say if this was following an update or what).

seth · 2021-03-27 14:49:14

xmodmap -pke | grep -E '224|225|bright'
xdotool key "XF86LogGrabInfo"
xev -event keyboard
setxkbmap -print -query

The first one will print some relevant bits about the current keymap, the second prints all grabs into the xorg log (if you sleep 5; … and press one backlight key before xdotool fires, it should™ end up as active grab, what will make it easier to look for it) and the third one prints what X11 sees - if it's grabbed, you'll only see some "KeymapNotify events", otherwise hopefully some key.
The last command prints your keyboard layout & variant.

The next step could be to xmodmap the brightness symbols to the provided keycodes, but first let's gather more data.
The inet layout has them at 232,234,237 & 238 - so there's a mismatch.

You've seen https://wiki.archlinux.org/index.php/Le … _T490#ACPI ?

matcharles · 2021-03-28 01:49:47

matcharles@Krusty ~ $ xmodmap -pke | grep -E '224|225|bright'
keycode 224 = XF86Messenger NoSymbol XF86Messenger
keycode 225 = XF86Search NoSymbol XF86Search

That doesn't seem right!

matcharles@Krusty ~ $ sleep 5; xdotool key "XF86LogGrabInfo"

Wouldn't return anything unfortunately.

xev -event keyboard

Produced some things I can't make sense of which is what you were describing I think. For instance I seem to get the same return whether I press FN+BrightnessUp or Down:

KeymapNotify event, serial 43, synthetic NO, window 0x0,
    keys:  1   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

matcharles@Krusty ~ $ setxkbmap -print -query
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+ca:2+inet(evdev)+group(alt_shift_toggle)"        };
        xkb_geometry  { include "pc(pc105)"     };
};
rules:      evdev
model:      pc105
layout:     us,ca
options:    grp:alt_shift_toggle

matcharles@Krusty ~ $ xmodmap
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

On the ACPI I did saw that when I first install Arch on it, but since I didn't have a problem at first I figured I wouldn't bother. Will make the change now though, great catch.

So anything in there that pops out? Thanks for doing this btw!

Last edited by matcharles (2021-04-18 01:23:16)

seth · 2021-03-28 06:48:58

layout: us,ca
options: grp:alt_shift_toggle

Is this intentional?
(There's a weird gnome bug where it slaps you w/ a second layout which impedes certain shortcuts)

KeymapNotify event, serial 43, synthetic NO, window 0x0,
keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

seth wrote:

if it's grabbed, you'll only see some "KeymapNotify events"

xbindkeys still running?

Wouldn't return anything unfortunately.

seth wrote:

prints all grabs into the xorg log

https://wiki.archlinux.org/index.php/Xorg#General

Please post the xorg log including the grabs, ensure the grabbing client (xbindkeys?) is no longer running (kill it) and re-try xev.

matcharles · 2021-03-28 23:08:53

Alright, my bad!

Yes the keyboard layout is intentional.

Here's the xorg.log after doing the keypresses. xbindkeys was killed to make sure it was not running. It's all giberish to me but I pressed the keys towards the end.

https://privatebin.net/?0822b1725818ac2 … evG45MN3xb

This time xev gave me this for BrightnessDown:

KeyRelease event, serial 30, synthetic NO, window 0x3200001,
    root 0x79c, subw 0x0, time 17108879, (371,169), root:(402,736),
    state 0x0, keycode 151 (keysym 0x1008ff2b, XF86WakeUp), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

MappingNotify event, serial 30, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeymapNotify event, serial 30, synthetic NO, window 0x0,
    keys:  1   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

and BrightnessUp

KeymapNotify event, serial 36, synthetic NO, window 0x0,
    keys:  1   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

Let me know if this is alright!

seth · 2021-03-29 06:10:45

BrightnessUp is still bound to some shortcut, the key is *not* dead.
BrightnessDown produces keycode 151
The posted xorg log looks truncated and does not include any grabs - do you have xdotool installed?

Wild guess:

setxkbmap -model evdev

?

Arch Linux

#1 2021-03-26 23:19:48

Problem with laptop xbindkeys not returning correct values

#2 2021-03-27 07:03:51

Re: Problem with laptop xbindkeys not returning correct values

#3 2021-03-27 14:20:14

Re: Problem with laptop xbindkeys not returning correct values

#4 2021-03-27 14:49:14

Re: Problem with laptop xbindkeys not returning correct values

#5 2021-03-28 01:49:47

Re: Problem with laptop xbindkeys not returning correct values

#6 2021-03-28 06:48:58

Re: Problem with laptop xbindkeys not returning correct values

#7 2021-03-28 23:08:53

Re: Problem with laptop xbindkeys not returning correct values

#8 2021-03-29 06:10:45

Re: Problem with laptop xbindkeys not returning correct values

Board footer