Hi,
On 10/11/23 12:44, Hans de Goede wrote:
> Hi,
>
> On 10/1/23 16:16, James John wrote:
>> Hello Han,
>>
>> 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.
>>
>> Don't hesitate to let me know if you need anything else.
>
> Sorry for being slow to respond (I was out sick for a week).
>
> I think I know what is going on here but I'm not sure how to fix it yet.
> I'll get back to you.
>
> Some more questions to clarify things:
>
> 1. in your log you write:
>
> BACKLIGHT BUTTON
> [17299.166313] asus_wmi: raw event code 0x2e
> [17299.166370] asus_wmi: raw event code 0xffffffffffffffff
> [17302.386607] asus_wmi: raw event code 0x2e
> [17302.386663] asus_wmi: raw event code 0xffffffffffffffff
>
> BACKLIGHT UP BUTTON
> [17332.080632] asus_wmi: raw event code 0x2f
> [17332.080727] asus_wmi: raw event code 0xffffffffffffffff
> [17332.497118] asus_wmi: raw event code 0x2f
> [17332.497192] asus_wmi: raw event code 0xffffffffffffffff
>
> I assume that the first "BACKLIGHT BUTTON" is the backlight DOWN button ?
>
>
> 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.
>
> Can you confirm this? This also means that brightness
> up will take bigger steps (2 steps per keypress) then
> brightness down, right ?
>
> 3. Please run:
>
> sudo acpidump -o acpidump.txt
>
> and send me a private email with acpidump.txt attached.
Two more things for you to test:
4. Please with the kernel with the debug patch press brightness-up / -down repeatedly,
I assume this does actually change the brightness ?
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.
5. Assuming 4. above confirms things behave as I expect
please give the attached 2 patches a try. Please undo the hwdb
change and run "sudo udevadm hwdb --update" before rebooting
into the patched kernel. After that please confirm that:
5.1 capslock and printscreen now lead to: "Unknown key code 0x.."
messages in dmesg.
5.2 running evtest on "Asus WMI hotkeys" shows brightness
up and down presses when pressing the brightness keys.
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
>>>>>
>
From a30c93d8d6e50db9810579895e2308fad6cf114b Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@xxxxxxxxxx>
Date: Wed, 11 Oct 2023 16:54:24 +0200
Subject: [PATCH 1/2] platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code
from 0x20 to 0x2e
Older Asus laptops change the backlight level themselves and then send
WMI events with different codes for different backlight levels.
The asus-wmi.c code maps the entire range of codes reported on
brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
define NOTIFY_BRNUP_MIN 0x11
define NOTIFY_BRNUP_MAX 0x1f
define NOTIFY_BRNDOWN_MIN 0x20
define NOTIFY_BRNDOWN_MAX 0x2e
if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
code = ASUS_WMI_BRN_UP;
else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
code = ASUS_WMI_BRN_DOWN;
Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX
aka 0x20 - 0x2e events were mapped to 0x20.
This mapping is causing issues on new laptop models which actually
send 0x2b events for printscreen presses and 0x2c events for
capslock presses, which get translated into spurious brightness-down
presses.
The plan is disable the 0x11-0x2e special mapping on laptops
where asus-wmi does not register a backlight-device to avoid
the spurious brightness-down keypresses. New laptops always send
0x2e for brightness-down presses, change the special internal
ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in
preparation for fixing the spurious brightness-down presses.
This change does not have any functional impact since all
of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only
then checked against the keymap code and the new 0x2e
value is still in the 0x20 - 0x2e range.
Link: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@xxxxxxxxxxx/
Link: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Cc: Luke D. Jones <luke@xxxxxxxxxx>
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
drivers/platform/x86/asus-wmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 5fbdd0eafa02..adb67c925724 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -18,7 +18,7 @@
#include <linux/i8042.h>
#define ASUS_WMI_KEY_IGNORE (-1)
-#define ASUS_WMI_BRN_DOWN 0x20
+#define ASUS_WMI_BRN_DOWN 0x2e
#define ASUS_WMI_BRN_UP 0x2f
struct module;
--
2.41.0
From 06da58541c1a6d71703ef7f80827b80bfb77fe66 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@xxxxxxxxxx>
Date: Wed, 11 Oct 2023 17:24:38 +0200
Subject: [PATCH 2/2] platform/x86: asus-wmi: Only map brightness codes when
using asus-wmi backlight control
Older Asus laptops change the backlight level themselves and then send
WMI events with different codes for different backlight levels.
The asus-wmi.c code maps the entire range of codes reported on
brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
define NOTIFY_BRNUP_MIN 0x11
define NOTIFY_BRNUP_MAX 0x1f
define NOTIFY_BRNDOWN_MIN 0x20
define NOTIFY_BRNDOWN_MAX 0x2e
if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
code = ASUS_WMI_BRN_UP;
else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
code = ASUS_WMI_BRN_DOWN;
This mapping is causing issues on new laptop models which actually
send 0x2b events for printscreen presses and 0x2c events for
capslock presses, which get translated into spurious brightness-down
presses.
This mapping is really only necessary when asus-wmi has registered
a backlight-device for backlight control. In this case the mapping
was used to decide to filter out the keypresss since in this case
the firmware has already modified the brightness itself and instead
of reporting a keypress asus-wmi will just report the new brightness
value to userspace.
OTOH when the firmware does not adjust the brightness itself then
it seems to always report 0x2e for brightness-down presses and
0x2f for brightness up presses independent of the actual brightness
level. So in this case the mapping of the code is not necessary
and this translation actually leads to spurious brightness-down
presses being send to userspace when pressing printscreen or capslock.
Modify asus_wmi_handle_event_code() to only do the mapping
when using asus-wmi backlight control to fix the spurious
brightness-down presses.
Link: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@xxxxxxxxxxx/
Link: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Cc: Luke D. Jones <luke@xxxxxxxxxx>
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
drivers/platform/x86/asus-wmi.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 928fc74e79b4..6a79f16233ab 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3950,7 +3950,6 @@ static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
{
unsigned int key_value = 1;
bool autorelease = 1;
- int orig_code = code;
if (asus->driver->key_filter) {
asus->driver->key_filter(asus->driver, &code, &key_value,
@@ -3959,16 +3958,10 @@ static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
return;
}
- if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
- code = ASUS_WMI_BRN_UP;
- else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
- code = ASUS_WMI_BRN_DOWN;
-
- if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) {
- if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
- asus_wmi_backlight_notify(asus, orig_code);
- return;
- }
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor &&
+ code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNDOWN_MAX) {
+ asus_wmi_backlight_notify(asus, code);
+ return;
}
if (code == NOTIFY_KBD_BRTUP) {
--
2.41.0
