You are not logged in.
After one of the recent updates I discovered that pressing Insert key disables Wifi. rfkill shows that it is softly blocked. The issue reproduces when a desktop environment and X aren't loaded. Unloading ideapad_laptop kernel module disables Fn+F8, but Insert still blocks WiFi. I don't see anything related in either kernel's change log nor in systemd's. So, I'm a bit out of ideas.
My laptop is Lenove Ideapad 5 14ACN6.
Last edited by shashurup (2023-01-06 11:02:04)
Offline
issue reproduces when a desktop environment and X aren't loaded
Keyboard looks like https://i.ebayimg.com/images/g/9MUAAOSw … -l1600.jpg ?
98% a hardware problem.
Try the behavior of some life distro (grml, knoppix, whatever) and an external keyboard.
In that case pushing and squeezing F8 (all keys in that row) a bit might help (depending on what alters the signal)
Offline
> Keyboard looks like https://i.ebayimg.com/images/g/9MUAAOSw … -l1600.jpg ?
Yes, this keyboard. However I'm not sure how this could be a hardware issue:
1. It definitely started to happen after an upgrade.
2. xev shows that it is still just an Insert key, nothing else and it works that way (and F8 reports it is XF86RFKill).
The external keyboard's Insert doesn't block WiFi. Looking for a suitable distro.
Offline
I've just checked on old Arch linux install usb thumb - pressing Insert doesn't block WiFi (and Fn+F8 does)
Offline
'key, not the HW.
The issue reproduces when a desktop environment and X aren't loaded.
…
xev shows that it is still just an Insert key, nothing else and it works that way (and F8 reports it is XF86RFKill).
To be clear: this happens during a console login (while there's no display server) AND in an X11 session?
Or only on the console?
But
The external keyboard's Insert doesn't block WiFi.
What do evtest and "libinput debug-events" report for the key?
Do you run acpid?
Offline
To be clear: this happens during a console login (while there's no display server) AND in an X11 session?
Both
What do evtest and "libinput debug-events" report for the key?
[root@shashurup-ip5 georgy]# libinput debug-events
-event4 DEVICE_ADDED Video Bus seat0 default group1 cap:k
-event2 DEVICE_ADDED Power Button seat0 default group2 cap:k
-event0 DEVICE_ADDED Lid Switch seat0 default group3 cap:S
-event1 DEVICE_ADDED Sleep Button seat0 default group4 cap:k
-event7 DEVICE_ADDED Integrated Camera: Integrated C seat0 default group5 cap:k
-event8 DEVICE_ADDED Integrated Camera: Integrated I seat0 default group5 cap:k
-event9 DEVICE_ADDED Ideapad extra buttons seat0 default group6 cap:k
-event11 DEVICE_ADDED MSFT0004:00 04F3:31BE Mouse seat0 default group7 cap:p left scroll-nat scroll-button
-event12 DEVICE_ADDED MSFT0004:00 04F3:31BE Touchpad seat0 default group7 cap:pg size 101x68mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on dwtp-on
-event3 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group8 cap:k
event3 KEYBOARD_KEY +0.000s KEY_RFKILL (247) pressed
^[[2~ event3 KEYBOARD_KEY +0.008s KEY_RFKILL (247) released
event3 KEYBOARD_KEY +5.789s KEY_RFKILL (247) pressed
^[[2~ event3 KEYBOARD_KEY +5.793s KEY_RFKILL (247) released
event3 KEYBOARD_KEY +15.660s *** (-1) pressed
event3 KEYBOARD_KEY +15.862s *** (-1) pressed
^C
I'm puzzled....
Do you run acpid?
Yes, I do.
I stopped it but it didn't help.
Last edited by shashurup (2023-01-04 14:25:13)
Offline
Well, yeah - since you're actually pressing KEY_RFKILL acpid is less reelvant
Let's see what has stuff in hwdb.d
pacman -Qo /usr/lib/udev/hwdb.d
Did "one of the recent updates" bump systemd?
Try to fish /usr/lib/udev/hwdb.d/60-keyboard.hwdb out of an older release
Offline
georgy@shashurup-ip5 ~> pacman -Qo /usr/lib/udev/hwdb.d
/usr/lib/udev/hwdb.d/ принадлежит libgphoto2 2.5.30-1
/usr/lib/udev/hwdb.d/ принадлежит libwacom 2.5.0-1
/usr/lib/udev/hwdb.d/ принадлежит sane 1.1.1-1
/usr/lib/udev/hwdb.d/ принадлежит systemd 252.4-2
/usr/lib/udev/hwdb.d/ принадлежит upower 1.90.0-1
Did "one of the recent updates" bump systemd?
Yes, systemd definitely changed, I remember checking its changelog.
Try to fish /usr/lib/udev/hwdb.d/60-keyboard.hwdb out of an older release
Got the idea, will check the history.
Offline
Brought back 60-keyboard.hwdb from systemd-251, rebuilt hwdb.bin.
Unfortunately this didn't fix the problem
Actually I don't see any model matches in hwdb. Here is what /sys/class/dmi/id/modalias contains ( : replaced with \n):
dmi
bvnLENOVO
bvrGECN30WW(V1.14)
bd03/04/2022
br1.30
efr1.30
svnLENOVO
pn82L7
pvrIdeaPad5Pro14ACN6
rvnLENOVO
rnLNVNB161216
rvrNoDPK
cvnLENOVO
ct10
cvrIdeaPad5Pro14ACN6
skuLENOVO_MT_82L7_BU_idea_FM_IdeaPad5Pro14ACN6
Is there a way to have libinput print scancodes, so I can figure what KEYBOARD_KEY_* to match in hwdb?
Offline
Is there a way to have libinput print scancodes, so I can figure what KEYBOARD_KEY_* to match in hwdb?
https://wiki.archlinux.org/title/Keyboa … ng_showkey
https://wiki.archlinux.org/title/Keyboa … ing_evtest
Offline
Is there a way to have libinput print scancodes, so I can figure what KEYBOARD_KEY_* to match in hwdb?
libinput debug-events --show-keycodes
Offline
Is there a way to have libinput print scancodes
Offline
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.
Offline
It looks like the problem is caused by this line in 60-keyboard.hwdb (it is actually 9 years old already)
# 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.
Last edited by shashurup (2023-01-06 11:03:59)
Offline
Probably "evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*IdeaPad*:*"
# 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"
Last edited by seth (2023-01-06 11:16:26)
Offline
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
Offline
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)
Offline
I do have changes in xkb layout but they don't seem to be related - I swap Ctrl and Alt, plus I use Caps lock for group switching.
Offline
Insert should™ be 118, 255 is actually XF86RFKill - something™ must be mapping around stuff here.
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?
Offline
Oops. This is a bit awkward ..
It looks like I've broken it myself
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>
Offline
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.
Either way, you probably want to file a bug against the hwdb
Offline
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!
Offline
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.
Offline
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"
Did you remove the match to test whether it's actually the trigger?
Offline
Not quite.
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.
Offline