You are not logged in.
Pages: 1
Plugging in charger is being read as a key press and is activating a key bind.
Using libinput, I can see that it captures it as;
event4 KEYBOARD_KEY +0.000s KEY_UNKNOWN (240) pressed
event4 KEYBOARD_KEY +0.000s KEY_UNKNOWN (240) released
evtest;
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Key repeat handling:
Repeat type 20 (EV_REP)
Repeat code 0 (REP_DELAY)
Value 250
Repeat code 1 (REP_PERIOD)
Value 33
Properties:
Testing ... (interrupt to exit)
Event: time 1708877246.225034, type 4 (EV_MSC), code 4 (MSC_SCAN), value cf
Event: time 1708877246.225034, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1708877246.225034, -------------- SYN_REPORT ------------
Event: time 1708877246.225045, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1708877246.225045, -------------- SYN_REPORT ------------
How can i stop this from happening
Last edited by annihilator (2024-02-27 14:15:03)
Offline
Please use [code][/code] tags, not some highligting. Edit your post in this regard.
What keybind, why do you think it's triggered by that event?
It shows KEY_UNKNOWN, how did you bind that to what and why?
Is this https://forum.manjaro.org/t/window-cras … wer/152982 ?
Edit: you probably want to https://wiki.archlinux.org/title/Map_sc … o_keycodes and map that to 236 (KEY_BATTERY)
Last edited by seth (2024-02-25 16:31:51)
Online
I didn't bind it to anything but its registering as and triggering lid switch, i have lid switch bound to a script but it gets triggered when i plug in the charger.
Last edited by annihilator (2024-02-25 23:08:30)
Offline
its registering as and triggering lid switch
Not really.
i have lid switch bound to a script
How? acpid?
Post the script/bound.
And just map away the scancode from KEY_UNKNOWN
Online
The script is not the problem. Its the keybind. I'm using hyprland.
This bind for instance gets triggered when I plug in the charger:
bindl = , switch:on:Lid Switch, exec, hyprctl keyword monitor "eDP-1, disable"
This was the bind for the script:
bindl=,switch:Lid Switch, exec, $LidSwitch
and here is the actual script:
#!/bin/bash
if grep open /proc/acpi/button/lid/LID/state; then
hyprctl keyword monitor "eDP-1, preferred, auto, 1"
else
if [[ `hyprctl monitors | grep "Monitor" | wc -l` != 1 ]]; then
hyprctl keyword monitor "eDP-1, disable"
fi
fi
Last edited by annihilator (2024-02-25 23:08:11)
Offline
Please stop the top posting, there's no point in bloating the thread with full quotes.
You're not getting an EV_SW there, but an EV_KEY.
There's either a bug in hyprland/wlroots/libinput or your assumption of this being the critical event is wrong.
Does acpid report a lid switch event when you plug the charger?
Does acpid or logind or anything else act as if this was a lid switch event?
Do you get events on other devices?
Last edited by seth (2024-02-25 22:53:13)
Online
Acpid doesn't recognise it as a lid switch
acpi_listen
0B3CBB35-E3C2- 000000ff 00000000
ac_adapter ACPI0003:00 00000080 00000001
0B3CBB35-E3C2- 000000ff 00000000
0B3CBB35-E3C2- 000000ff 00000000
battery PNP0C0A:00 00000081 00000001
ac_adapter ACPI0003:00 00000080 00000001
battery PNP0C0A:00 00000080 00000001
From Journalctl
journalcl -f
Feb 25 23:30:22 ann kernel: asus_wmi: Unknown key code 0xcf
Feb 25 23:30:22 ann root[14860]: ACPI group/action undefined: 0B3CBB35-E3C2- / 000000ff
Feb 25 23:30:22 ann root[14864]: ACPI action undefined: ACPI0003:00
Feb 25 23:30:22 ann root[14866]: ACPI group/action undefined: 0B3CBB35-E3C2- / 000000ff
Feb 25 23:30:22 ann root[14868]: ACPI group/action undefined: 0B3CBB35-E3C2- / 000000ff
Feb 25 23:30:22 ann root[14870]: ACPI action undefined: PNP0C0A:00
Feb 25 23:30:22 ann root[14872]: ACPI action undefined: ACPI0003:00
Feb 25 23:30:22 ann root[14874]: ACPI action undefined: PNP0C0A:00
Feb 25 23:30:22 ann asusd[573]: INFO: PlatformPolicy unlinked from EPP
Feb 25 23:30:22 ann asusd[573]: INFO: PlatformPolicy unlinked from EPP
Offline
So a bug in ovrhypds dependency chain.
map away the scancode from KEY_UNKNOWN
Online
It doesn't matter what i map it to the behaviour doesn't change.
I used udev.
Last edited by annihilator (2024-02-26 11:48:16)
Offline
And does evtest/libinput debug events report the key, different from KEY_UNKNOWN?
Either way, you'll have to report the bug to hyprland, keyboard events on charger plugs are rather common and not a reason to make up a lid switch event,
Online
They both still report it as unknown no matter the mapping.
Could it be a kernel issue?
Offline
Ie. you're not mappign the key anywhere.
Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Detail your exact approach.
Online
Lol, alright.
Here's what i did:
# vi /etc/udev/hwdb.d/90-custom-map.hwdb
evdev:input:b0019v0000p0006e0000*
KEYBOARD_KEY_cf=reserved
then;
# systemd-hwdp update
# udevadm trigger
and i checked with;
# udevadm info /dev/input/event4
P: /devices/platform/asus-nb-wmi/input/input4/event4
M: event4
R: 4
U: input
D: c 13:68
N: input/event4
L: 0
S: input/by-path/platform-asus-nb-wmi-event
E: DEVPATH=/devices/platform/asus-nb-wmi/input/input4/event4
E: DEVNAME=/dev/input/event4
E: MAJOR=13
E: MINOR=68
E: SUBSYSTEM=input
E: KEYBOARD_KEY_cf=reserved
E: USEC_INITIALIZED=11500825
E: KEYBOARD_KEY_6b=f21
E: KEYBOARD_KEY_7c=f20
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=platform-asus-nb-wmi
E: ID_PATH_TAG=platform-asus-nb-wmi
E: LIBINPUT_DEVICE_GROUP=19/0/0:asus-nb-wmi
E: DMI_VENDOR=ASUSTeK COMPUTER INC.
E: DMI_FAMILY=ROG Zephyrus G15
E: DEVLINKS=/dev/input/by-path/platform-asus-nb-wmi-event
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:
Offline
Be aware that with udevadm only added or changed key mapping are loaded so if we delete a mapping from the configuration file, rebuild hwdb.bin and run udevadm trigger as the root user, then the deleted mapping still kept by the kernel, at least until a reboot.
Did you?
Does evtest report the proper key event afterwards?
And, reg. the original issue, did you check libinput debug-events to make sure the charger doesn't cause any other events?
Edit: your upstream bug for reference, https://github.com/hyprwm/Hyprland/issues/4836
There's no indication that anything but hyprland interprets this as lid switch, neither acpid nor (I assume) logind?
What if you disable the hyprland rule and add something obvious to either of those (eg. S3 w/ logind or some notification or even run your script (su'd as your uid) from acpid)?
Last edited by seth (2024-02-26 16:24:54)
Online
Yes, I checked. Before and after rebooting.
Nothing changes with both evtest and libinput, they both report the events as they did prior to the change in my initial post.
I actually submitted the bug report, https://github.com/hyprwm/Hyprland/issues/4836
The interesting thing is no service actually outputs it as a lid switch, not acpid, evtest or libinput, they either report it as unknown or unassigned.
For some reason hyprland is treating it as a lid switch. I don't have another WM/DE installed to test if the behaviour is the same.
Offline
update from the bug report:
Apparently its a kernel issue.
Offline
Because upstream said so, based on the vague memory that this is only a problem w/ recent kernels for them?
I don't buy that a a key event that's not interpreted by anything else as lid switch but seems to trigger a lid switch in hyprland isn't a problem in the hyprland userspace dependency chain.
Doesn't have to be hyprland itself, could be where it's getting the event from.
1. The upstream bug says that it wasn't an issue w/ older kernels - do you get the same (event and) behavior w/ the LTS kernel or maybe https://aur.archlinux.org/packages/linux-lts61 or https://aur.archlinux.org/packages/linux-lts515 ?
2. Maybe we're looking at a red herring here, if you consume the event w/ "evtest --grab /dev/input/event4", does hyprland still respond to some lid switch when you plug the charger?
Fwwi, 60-keyboard.hwdb has KEYBOARD_KEY_cf mapped to end for XO and DELL devices and on thinkpads it's apparently insert. So it's not a super-uncommon scancode.
Online
It was the same result with the lts kernel.
But this "evtest --grab /dev/input/event4" stopped it, the lid switch wasn't triggered.
Offline
You might have to use an even older kernel, but this isn't a kernel bug.
What might have changed is that the device emits an event at all
And something™ in the userspace (again: could be whatever Hyprland gets the event from) has a quirk to interpret all events out of that direction as lid switch.
If you enable the lid switch in logind.conf, does the system suspend when you plug the charger?
Wrt your script, does the /proc/acpi/button/lid/LID/state actually change w/ the charger? Why is it not inert on those events?
Online
I just checked and no plugging in the charger has no effect on /proc/acpi/button/lid/LID/state, the state doesn't change.
Offline
Then why does your script do anything?
Next to testing the behavior of logind, you'll probably want to inquire upstream what actually feeds their lid switch event to test that behavior directly.
Online
Good question.
Plugging in the charger seems to have no effect on logind.
Seeing as the device state doesn't actually change, that leaves hyprland, it has to be.
Thanks for your help. I'll mark this as solved.
Offline
Pages: 1