[SOLVED] Asus wmi issues

annihilator · 2024-02-25 16:11:02

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)

seth · 2024-02-25 16:27:35

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)

annihilator · 2024-02-25 17:11:54

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)

seth · 2024-02-25 20:59:21

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

annihilator · 2024-02-25 22:40:48

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)

seth · 2024-02-25 22:52:46

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)

annihilator · 2024-02-25 23:33:21

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

seth · 2024-02-26 09:32:47

So a bug in ovrhypds dependency chain.

seth, multiple times, wrote:

map away the scancode from KEY_UNKNOWN

annihilator · 2024-02-26 11:47:50

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)

seth · 2024-02-26 13:37:15

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,

annihilator · 2024-02-26 15:24:27

They both still report it as unknown no matter the mapping.
Could it be a kernel issue?

seth · 2024-02-26 15:34:36

Ie. you're not mappign the key anywhere.
Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Detail your exact approach.

annihilator · 2024-02-26 15:57:50

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:

seth · 2024-02-26 16:19:13

the wiki wrote:

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)

annihilator · 2024-02-26 16:50:59

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.

annihilator · 2024-02-26 17:40:21

update from the bug report:

Apparently its a kernel issue.

seth · 2024-02-26 20:14:03

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.

annihilator · 2024-02-27 03:07:33

It was the same result with the lts kernel.
But this "evtest --grab /dev/input/event4" stopped it, the lid switch wasn't triggered.

seth · 2024-02-27 07:54:15

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?

annihilator · 2024-02-27 13:29:32

I just checked and no plugging in the charger has no effect on /proc/acpi/button/lid/LID/state, the state doesn't change.

seth · 2024-02-27 13:32:58

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.

annihilator · 2024-02-27 14:12:58

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.

Arch Linux

#1 2024-02-25 16:11:02

[SOLVED] Asus wmi issues

#2 2024-02-25 16:27:35

Re: [SOLVED] Asus wmi issues

#3 2024-02-25 17:11:54

Re: [SOLVED] Asus wmi issues

#4 2024-02-25 20:59:21

Re: [SOLVED] Asus wmi issues

#5 2024-02-25 22:40:48

Re: [SOLVED] Asus wmi issues

#6 2024-02-25 22:52:46

Re: [SOLVED] Asus wmi issues

#7 2024-02-25 23:33:21

Re: [SOLVED] Asus wmi issues

#8 2024-02-26 09:32:47

Re: [SOLVED] Asus wmi issues

#9 2024-02-26 11:47:50

Re: [SOLVED] Asus wmi issues

#10 2024-02-26 13:37:15

Re: [SOLVED] Asus wmi issues

#11 2024-02-26 15:24:27

Re: [SOLVED] Asus wmi issues

#12 2024-02-26 15:34:36

Re: [SOLVED] Asus wmi issues

#13 2024-02-26 15:57:50

Re: [SOLVED] Asus wmi issues

#14 2024-02-26 16:19:13

Re: [SOLVED] Asus wmi issues

#15 2024-02-26 16:50:59

Re: [SOLVED] Asus wmi issues

#16 2024-02-26 17:40:21

Re: [SOLVED] Asus wmi issues

#17 2024-02-26 20:14:03

Re: [SOLVED] Asus wmi issues

#18 2024-02-27 03:07:33

Re: [SOLVED] Asus wmi issues

#19 2024-02-27 07:54:15

Re: [SOLVED] Asus wmi issues

#20 2024-02-27 13:29:32

Re: [SOLVED] Asus wmi issues

#21 2024-02-27 13:32:58

Re: [SOLVED] Asus wmi issues

#22 2024-02-27 14:12:58

Re: [SOLVED] Asus wmi issues

Board footer