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 >>>>>