Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA

From: me
Date: Tue Oct 17 2023 - 20:19:17 EST

Next message: Jakub Kicinski: "Re: [PATCH v2 01/10] appletalk: make localtalk and ppp support conditional"
Previous message: Anton Yakovlev: "Re: [RFC PATCH] ALSA: virtio: use copy and fill_silence callbacks"
In reply to: Hans de Goede: "Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA"
Next in thread: Hans de Goede: "Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Hans,

I hope you are feeling better now.
Thank you so much for your support in resolving this.

I assume that the first "BACKLIGHT BUTTON" is the backlight DOWN button ?

Yes. Correct.

2. Can you please run:

sudo evtest and then select the "ACPI video bus" (or something
similar) device and see if that reports brightness up/down
keypresses? And then do the same thing for the
"Asus WMI hotkeys" device ? I expect the Asus WMI hotkeys
device to only report brightness up keypresses (after my
hwdb "fix") while I expect brightness-up events to get
reported twice, by both the "ACPI video bus" device and
the "Asus WMI hotkeys" device.

Done and attached.

Can you confirm this? This also means that brightness
up will take bigger steps (2 steps per keypress) then
brightness down, right ?

I am not sure I understand what you mean here. But I have attached the output here

3. Please run:

sudo acpidump -o acpidump.txt

and send me a private email with acpidump.txt attached.

Sent

4. Please with the kernel with the debug patch press brightness-up / -down repeatedly,
I assume this does actually change the brightness ?

Yes

Then look in dmesg and check that it consistently reports 0x2e
for brightness-down presses and 0x2f for brightness-up presses
independent of the brightness level being high or low when
pressing the key. Please confirm this behaves as expected.

Yes.brightness-down reports 0x2e while brightness-up reports 0x2f

5.1 capslock and printscreen now lead to: "Unknown key code 0x.."
messages in dmesg.

Yes, printscreen and caps lock now responds with:

CAPS LOCK
[ 122.965660] asus_wmi: raw event code 0x2c
[ 122.965705] asus_wmi: Unknown key code 0x2c
[ 122.965730] asus_wmi: raw event code 0xffffffffffffffff

PRTSCRN
[ 126.066419] asus_wmi: raw event code 0x2b
[ 126.066439] asus_wmi: Unknown key code 0x2b
[ 126.066451] asus_wmi: raw event code 0xffffffffffffffff

5.2 running evtest on "Asus WMI hotkeys" shows brightness
up and down presses when pressing the brightness keys.

Yes

Event: time 1697586223.014528, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2e
Event: time 1697586223.014528, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1
Event: time 1697586223.014528, -------------- SYN_REPORT ------------
Event: time 1697586223.014547, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0
Event: time 1697586223.014547, -------------- SYN_REPORT ------------
Event: time 1697586223.714462, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2f
Event: time 1697586223.714462, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697586223.714462, -------------- SYN_REPORT ------------
Event: time 1697586223.714471, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697586223.714471, -------------- SYN_REPORT ------------

After applying your patch, it seems to have fixed the issue!

On 2023-10-17 03:50, Hans de Goede wrote:

Hi James,

On 10/1/23 16:16, James John wrote:

Hello Hans,

Thank you. I applied the patch and I have the inputs attached here.

After setting the hwdb filter, all the hot keys are still working except that the LED notification light on Mute Hotkey (F9) is no longer turning up on mute.

The Screen Capture, Disable Camera, and MyASUS buttons are not mapped yet. I believe the Screen Capture button should map to PrntScrn button, and MyASUS with Disable Camera unmapped, obviously. I also have the codes in the attached log.

Screen Capture button is KEY_UNKNOWN to evtest.

So I missed the Screen Capture button so far.
I believe that the 0x2a code should be mapped to
KEY_SELECTIVE_SCREENSHOT (to differentiate it from
the printscreen key, this is also used on other laptops
for similar buttons).

I'm going to send out a RFC series of 3 patches,
the 2 patches which I send earlier + a patch to
add a mapping for this. I'll Cc you on this.

Please give this series a try (after removing the hwdb
change).

Regards,

Hans

On 01/10/2023 13:45, Hans de Goede wrote:

Hi James,

On 10/1/23 10:46, James John wrote:

Hello Han,

Thank you very much for this detailed steps. I was able to reproduce this with "evtest" and everything went okay.

After editing /lib/udev/hwdb.d/60-keyboarrd.hwdb as you specified, the problem has been fixed, which I believe should revert on reboot?
No this will fix it until /lib/udev/hwdb.d/60-keyboarrd.hwdb gets overwritten by your
package-manager the next time the systemd packages get updated.

This is the content of /sys/class/dmi/id/modalias

dmi:bvnAmericanMegatrendsInternational,LLC.:bvrUX5304VA.304:bd05/16/2023:br5.27:svnASUSTeKCOMPUTERINC.:pnZenbookS13UX5304VA_UX5304VA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX5304VA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku:

Thanks.

Looking at:
https://bbs.archlinux.org/viewtopic.php?pid=2123716

I see that at least one other model Asus laptop is affected too. So rather then
adding a more specific hwdb rule for your model I would like to try and find
the root cause of these 0x20 event code events when pressing capslock
on your laptop.

Yes, I built my kernel. I wish I could parse this and write a proper quirk.
Good, I've written a small kernel patch to get to the bottom of this (attached)
can you please build a kernel with this. Then boot into this kernel and
then run dmesg -w

When you now press capslock you should see log lines show up which contain
"raw event code 0x..."

Please let me know what these lines show when pressing capslock.

Please also let me know what these lines show when pressing other
hotkeys which are handled by asus-nb-wmi (you can re-run "sudo evtest"
to check which keys that are).

I think the issue might be that the asus-wmi code is filtering out
the higher bits of the value, which causes some new events to
get mapped as just 0x20 instead of some-higher-bits + 0x20.

Also I'm wondering if everything else works as it should,
e.g. does changing the brightness with the brightness hotkeys
still work after setting up the hwdb filtering ?

And does the lid-switch (suspend the machine when the lid is closed)
work ?

Also, I don't know if this is related; the hotkeys should be enabled by default. Fn key should be for Function keys. But in the current state, it is reversed.
This is laptop models specific and not really controlled by Linux,
sometimes you can change the default in the BIOS. Or sometimes you
can change the default by pressing Fn + Esc.

Regards,

Hans

On 01/10/2023 09:28, Hans de Goede wrote:

Hi James,

On 10/1/23 10:11, James John wrote:

Hello,

First of all, thank you very much for the work you do with maintaining these drivers and supporting systems. It is not an easy one.

I have debugged this bug down to the asus_nb_wmi module. When I disable this module, the problem goes away, but then other hotkeys are not recognized. Attached is a debug event from libinput, where I pressed the capslock twice

I have tried to dabble around with asus-nb-wmi.c codes to see if I could fix it by luck, by adding UX5304VA to `static const struct dmi_system_id asus_quirks[]` but to no avail. And I have a very little knowledge of what "quirks" are.

I have attached some information regarding my hardware and kernel. I will be available to provide any more information that might be needed to resolve this.

A related open thread: https://bbs.archlinux.org/viewtopic.php?pid=2123716
First of all lets confirm that the KEY_BRIGHTNESSDOWN events are really coming from asus_nb_wmi.

Please install evtest and then run "sudo evtest" and then select the "Asus WMI hotkeys" device
by typing its number followed by enter.

After this reproduce the bug and see if the log shows KEY_BRIGHTNESSDOWN.

Since you said you tried playing around with the quirks, I assume you can build
your own kernel, please let me know if that is wrong.

If this confirms the KEY_BRIGHTNESSDOWN events are coming from the "Asus WMI hotkeys" device,
then please edit /lib/udev/hwdb.d/60-keyboard.hwdb

And search for "Asus WMI hotkeys", this should find this section:

evdev:name:Asus WMI hotkeys:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:*
evdev:name:Eee PC WMI hotkeys:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:*
evdev:name:Asus Laptop extra buttons:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:*
   KEYBOARD_KEY_6b=f21                                    # Touchpad Toggle
   KEYBOARD_KEY_7c=f20                                    # Remap micmute to f20

Change this to:

evdev:name:Asus WMI hotkeys:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:*
evdev:name:Eee PC WMI hotkeys:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:*
evdev:name:Asus Laptop extra buttons:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:*
   KEYBOARD_KEY_6b=f21                                    # Touchpad Toggle
   KEYBOARD_KEY_7c=f20                                    # Remap micmute to f20
   KEYBOARD_KEY_20=unknown

And then run "sudo udevadm hwdb --update" followed by "sudo udevadm trigger",
that should filter out the spurious keypresses.

If that helps, please run:

cat /sys/class/dmi/id/modalias

So that a proper DMI based quirk to only to the filtering on your model
can be written.

Regards,

Hans

Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Asus WMI hotkeys"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 113 (KEY_MUTE)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 140 (KEY_CALC)
Event code 148 (KEY_PROG1)
Event code 149 (KEY_PROG2)
Event code 150 (KEY_WWW)
Event code 152 (KEY_SCREENLOCK)
Event code 163 (KEY_NEXTSONG)
Event code 164 (KEY_PLAYPAUSE)
Event code 165 (KEY_PREVIOUSSONG)
Event code 166 (KEY_STOPCD)
Event code 169 (KEY_PHONE)
Event code 183 (KEY_F13)
Event code 185 (KEY_F15)
Event code 190 (KEY_F20)
Event code 191 (KEY_F21)
Event code 202 (KEY_PROG3)
Event code 203 (KEY_PROG4)
Event code 212 (KEY_CAMERA)
Event code 215 (KEY_EMAIL)
Event code 225 (KEY_BRIGHTNESSUP)
Event code 226 (KEY_MEDIA)
Event code 227 (KEY_SWITCHVIDEOMODE)
Event code 229 (KEY_KBDILLUMDOWN)
Event code 230 (KEY_KBDILLUMUP)
Event code 237 (KEY_BLUETOOTH)
Event code 238 (KEY_WLAN)
Event code 240 (KEY_UNKNOWN)
Event code 247 (KEY_RFKILL)
Event code 470 (KEY_FN_F5)
Event code 531 (KEY_TOUCHPAD_ON)
Event code 560 (KEY_ALS_TOGGLE)
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 1697583236.975661, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time 1697583236.975661, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1697583236.975661, -------------- SYN_REPORT ------------
Event: time 1697583236.975674, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1697583236.975674, -------------- SYN_REPORT ------------
Event: time 1697583238.413018, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2f
Event: time 1697583238.413018, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583238.413018, -------------- SYN_REPORT ------------
Event: time 1697583238.413036, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583238.413036, -------------- SYN_REPORT ------------
Event: time 1697583239.472226, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time 1697583239.472226, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1697583239.472226, -------------- SYN_REPORT ------------
Event: time 1697583239.472237, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1697583239.472237, -------------- SYN_REPORT ------------
Event: time 1697583241.599500, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2f
Event: time 1697583241.599500, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583241.599500, -------------- SYN_REPORT ------------
Event: time 1697583241.599511, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583241.599511, -------------- SYN_REPORT ------------
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x6 version 0x0
Input device name: "Video Bus"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 224 (KEY_BRIGHTNESSDOWN)
Event code 225 (KEY_BRIGHTNESSUP)
Event code 227 (KEY_SWITCHVIDEOMODE)
Event code 241 (KEY_VIDEO_NEXT)
Event code 242 (KEY_VIDEO_PREV)
Event code 243 (KEY_BRIGHTNESS_CYCLE)
Event code 244 (KEY_BRIGHTNESS_ZERO)
Event code 245 (KEY_DISPLAY_OFF)
Properties:
Testing ... (interrupt to exit)
Event: time 1697583061.695285, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1
Event: time 1697583061.695285, -------------- SYN_REPORT ------------
Event: time 1697583061.695303, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0
Event: time 1697583061.695303, -------------- SYN_REPORT ------------
Event: time 1697583062.935233, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583062.935233, -------------- SYN_REPORT ------------
Event: time 1697583062.935248, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583062.935248, -------------- SYN_REPORT ------------
Event: time 1697583065.169344, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1
Event: time 1697583065.169344, -------------- SYN_REPORT ------------
Event: time 1697583065.169364, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0
Event: time 1697583065.169364, -------------- SYN_REPORT ------------
Event: time 1697583065.748833, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583065.748833, -------------- SYN_REPORT ------------
Event: time 1697583065.748863, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583065.748863, -------------- SYN_REPORT ------------

Next message: Jakub Kicinski: "Re: [PATCH v2 01/10] appletalk: make localtalk and ppp support conditional"
Previous message: Anton Yakovlev: "Re: [RFC PATCH] ALSA: virtio: use copy and fill_silence callbacks"
In reply to: Hans de Goede: "Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA"
Next in thread: Hans de Goede: "Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]