Did you remove the match to test whether it's actually the trigger?
No, I didn't. But this line was the only one in the whole file which could map scancode 81 to rfkill kecode.
I was looking for something like turning on sort of debugging log where the matching process is a bit more clear.
idk how sharp the matching is tuned, but afaiu the "pn" would be matched against the XXXX and the modalias(es) against VVVV in "evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV"
bZZZZvYYYYpXXXXeWWWW - is matched against product, bus etc which are hex numbers and, in my case, are just some generic numbers not in any way specific to my laptop
georgy@shashurup-ip5 ~> ls /sys/class/input/event3/device/id
bustype product vendor version
georgy@shashurup-ip5 ~> cat /sys/class/input/event3/device/id/*
0011
0001
0001
ab41
In my case, I believe, the match happens against dmi stuff (contents of modalias). If I were to develop this I would just split the whole pattern by ":" and check that each resulting part has a corresponding match in one of the string resulting from splitting modalias by ":"
However, what I see contradicts this simple model, it looks like "pn*IdeaPad*" is also matched against "pvr..." and "sku..." strings from modalias.
Insert should™ be 118, 255 is actually XF86RFKill - something™ must be mapping around stuff here.
Arguebly the correcter™ match would beevdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*-*IdeaPad*:*
but that should still hit your device, does it?
I still cannot understand how "pn:*IdeaPad*" can match one of
pn82L7
pvrIdeaPad5Pro14ACN6
skuLENOVO_MT_82L7_BU_idea_FM_IdeaPad5Pro14ACN6
I expect that pn, pvr or sku prefixes matter. At least I as a developer would have made it this way.
]]>My guesstimate is that it didn't produce the desired symbol.
Either it didn't produce any symbol or it was already rfkill and what has recently changed is that rfkill is intercepted by some daemon that actually soft-blocks the NIC.
Yes, now I also think this was the reason. Forgetting all this little config fixes is really a problem for me
Either way, you probably want to file a bug against the hwdb
https://github.com/systemd/systemd/issues/25968
Thank you for your patience!
]]>Either way, you probably want to file a bug against the hwdb
]]>xkbcomp -i $BUILTIN_KBD_ID - $DISPLAY <<EOF
xkb_keymap {
xkb_keycodes {
include "evdev+aliases(qwerty)"
<LALT> = 37;
<LCTL> = 64;
<RCTL> = 108;
<RALT> = 105;
<INS> = 255;
alias <ALGR> = <RALT>;
};
xkb_types { include "complete" };
xkb_compat {
include "complete"
indicator "Caps Lock" { groups = 2; };
};
xkb_symbols { include "pc+us+ru:2+inet(evdev)+group(caps_toggle)" };
xkb_geometry { include "pc(pc105)" };
};
EOF
The problem is I cannot recollect why and when I did something to <INS>
]]>What brings us to
I swap Ctrl and Alt, plus I use Caps lock for group switching.
How? Cause it's not reflected in the setxkbmap output.
Arguebly the correcter™ match would be
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*-*IdeaPad*:*
but that should still hit your device, does it?
]]>Probably "evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*IdeaPad*:*"
The description in 60-keyboard.hwdb is quite misleading. I expect that pn*IdeaPad* would match the contents of the pn field, not the other fields (pvr and sku in my case)
]]>Same issue w/ the LTS kernel?
I'm on LTS kernel. Will check 6.x kernels
What does xev report exactly
KeyPress event, serial 36, synthetic NO, window 0x3200001,
root 0x6ad, subw 0x0, time 8879780, (211,1321), root:(1655,1325),
state 0x0, keycode 255 (keysym 0xff63, Insert), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 36, synthetic NO, window 0x3200001,
root 0x6ad, subw 0x0, time 8879784, (211,1321), root:(1655,1325),
state 0x0, keycode 255 (keysym 0xff63, Insert), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 36, synthetic NO, window 0x3200001,
root 0x6ad, subw 0x0, time 8881316, (211,1321), root:(1655,1325),
state 0x0, keycode 255 (keysym 0xff63, Insert), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 36, synthetic NO, window 0x3200001,
root 0x6ad, subw 0x0, time 8881324, (211,1321), root:(1655,1325),
state 0x0, keycode 255 (keysym 0xff63, Insert), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
what's the output of "setxkbmap -print -query"
georgy@shashurup-ip5 ~> setxkbmap -print -query
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
rules: evdev
model: pc105
layout: us
# Supported hardware matches are:
# - Generic input devices match:
# evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
# This matches on the kernel modalias of the input-device, mainly:
# ZZZZ is the bus-id (see /usr/include/linux/input.h BUS_*), YYYY, XXXX and
# WWWW are the 4-digit hex uppercase vendor, product and version ID and VVVV
# is an arbitrary length input-modalias describing the device capabilities.
# The vendor, product and version ID for a device node "eventX" is listed
# in /sys/class/input/eventX/device/id.
pn* matches pn82L7 and you do have 2 *IdeaPad*'s in the modalias.
Same issue w/ the LTS kernel?
Edit: xkb layout? What does xev report exactly and what's the output of "setxkbmap -print -query"?
Also look around in "xmodmap -pk"
# lenovo-ideapad
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*IdeaPad*:*
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnS10-*:*
KEYBOARD_KEY_81=rfkill # does nothing in BIOS
This explanation has just one problem - my laptop has "pn82L7" and it must not match the patterns above. I suspect that something has changed in a recent version which affects the way matching works, probably it is a bug.
So I fixed it with custom config:
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn82L7:*
KEYBOARD_KEY_81=insert
Another unanswered question is how Xorg understands it is Insert - it uses the same libinput to handle keyboards.
]]>libinput debug-events --show-keycodes
This man option seems quite reasonable until you try and realize it doesn't work - it just doesn't affect the output.
]]>]]>Is there a way to have libinput print scancodes