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
Thank you!
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?
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:
Yes, I built my kernel. I wish I could parse this and write a proper quirk.
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.
Thank you
James
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
>
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
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.
Thank you!
James
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
>>>
Lid Close to Suspend still works as well.
On 01/10/2023 14: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.
>
>
> Thank you!
>
> James
>
>
> 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
>>>>
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
>>
>
> hot keys are still working except that the LED notification light on
Mute Hotkey (F9) is no longer turning up on mute.
Kindly ignore above. It is back working after a reboot.
On 01/10/2023 14:18, James John wrote:
> hot keys are still working except that the LED notification light on
> Mute Hotkey (F9) is no longer turning up on mute.
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.
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
>>>>
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
>>>>>
>
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
>>>>
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
>>>>>
Hi James,
On 10/18/23 02:17, [email protected] wrote:
> 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
The 2 evtest logs show that each brightness up/down keypress
gets reported twice, once by the "ACPI video bus" device and
once bythe "Asus WMI hotkeys" device.
This means that in e.g. GNOME the brightness will move
up / down by 2 steps for each step, reducing the amount
of steps from 20 to 10, or iow making each step twice
as big. Especially at the low end of the brightness
scale this may be an issue since steeping by 5% there
can already make a big difference and this double
key press reporting now changes this into stepping
by 10% at a time.
> After applying your patch, it seems to have fixed the issue!
Thank you for all the testing and other then the double
keypress issue + the unknown code messages everything
now looks good!
I have applied 2 more patches the first one fixes the
unknown code messages and adds a mapping for the
"Screen Capture" hotkey. The second test filters out
the duplicate (duplicate with the "ACPI video bus")
brightness up/down events.
It would be great if you can add these on top of
the previous 2 patches and then run one last
test for me:
Run evtest on the "Asus WMI hotkeys" device this should now:
1. Show no output for capslock / printscreen
2. Show KEY_SELECTIVE_SCREENSHOT events for the
"Screen Capture" hotkey.
3. Show no output for brightness up/down,
yet brightness up/down should still work since
these are also reported by the "ACPI video bus"
It would be great if you can confirm for each of these
that this behaves as expected with the 2 extra patches
applied on top of the previous patches.
Regards,
Hans
Hello Hans,
Thank you for your support so far. I really appreciate this.
I have always wanted to contribute to the kernel, so, this is fun for me! :)
The 2 evtest logs show that each brightness up/down keypress
gets reported twice, once by the "ACPI video bus" device and
once bythe "Asus WMI hotkeys" device.
I do not think these are multiple events. There are different. One has
the value of 0, the other has value of 1.
I am not sure what they mean. I initially thought it could be keydown
and keyup events, but it is not, because
on pressing the keydown, they are still both reported. I also think the
desktops handle this, maybe by filtering out
0 values. I use KDE Plasma, and I still have 5% step despite evtest
reporting these 2 events.
I have applied the last 2 patches.
1. Show no output for capslock / printscreen
Correct. These keys are no longer captured by Asus WMI hotkeys
2. Show KEY_SELECTIVE_SCREENSHOT events for the
"Screen Capture" hotkey.
I am not sure I am getting KEY_SELECTIVE_SCREENSHOT event for the
"Screen Capture" hotkey. This is what I get:
Event: time 1697757579.588239, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1697757579.588239, type 1 (EV_KEY), code 634 (?), value 1
Event: time 1697757579.588239, -------------- SYN_REPORT ------------
Event: time 1697757579.588244, type 1 (EV_KEY), code 634 (?), value 0
Event: time 1697757579.588244, -------------- SYN_REPORT ------------
And this is what I get for "Screen Capture" hotkey, from the debug you
placed
[ 1096.691389] asus_wmi: raw event code 0x2a
[ 1096.691446] asus_wmi: raw event code 0xffffffffffffffff
[ 1097.982976] asus_wmi: raw event code 0x2a
[ 1097.983032] asus_wmi: raw event code 0xffffffffffffffff
3. Show no output for brightness up/down,
yet brightness up/down should still work since
these are also reported by the "ACPI video bus"
Yes, correct. No output from Asus WMI hotkeys, but there an output from
Video bus
Thanks
James
On 18/10/2023 19:35, Hans de Goede wrote:
> Hi James,
>
> On 10/18/23 02:17, [email protected] wrote:
>> 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
> The 2 evtest logs show that each brightness up/down keypress
> gets reported twice, once by the "ACPI video bus" device and
> once bythe "Asus WMI hotkeys" device.
>
> This means that in e.g. GNOME the brightness will move
> up / down by 2 steps for each step, reducing the amount
> of steps from 20 to 10, or iow making each step twice
> as big. Especially at the low end of the brightness
> scale this may be an issue since steeping by 5% there
> can already make a big difference and this double
> key press reporting now changes this into stepping
> by 10% at a time.
>
>> After applying your patch, it seems to have fixed the issue!
> Thank you for all the testing and other then the double
> keypress issue + the unknown code messages everything
> now looks good!
>
> I have applied 2 more patches the first one fixes the
> unknown code messages and adds a mapping for the
> "Screen Capture" hotkey. The second test filters out
> the duplicate (duplicate with the "ACPI video bus")
> brightness up/down events.
>
> It would be great if you can add these on top of
> the previous 2 patches and then run one last
> test for me:
>
> Run evtest on the "Asus WMI hotkeys" device this should now:
>
> 1. Show no output for capslock / printscreen
>
> 2. Show KEY_SELECTIVE_SCREENSHOT events for the
> "Screen Capture" hotkey.
>
> 3. Show no output for brightness up/down,
> yet brightness up/down should still work since
> these are also reported by the "ACPI video bus"
>
> It would be great if you can confirm for each of these
> that this behaves as expected with the 2 extra patches
> applied on top of the previous patches.
>
> Regards,
>
> Hans
Hi James,
On 10/20/23 01:22, James John wrote:
> Hello Hans,
>
> Thank you for your support so far. I really appreciate this.
>
> I have always wanted to contribute to the kernel, so, this is fun for me! :)
That is great and thank you for all your help with solving this.
> The 2 evtest logs show that each brightness up/down keypress
> gets reported twice, once by the "ACPI video bus" device and
> once bythe "Asus WMI hotkeys" device.
>
> I do not think these are multiple events. There are different. One has the value of 0, the other has value of 1.
> I am not sure what they mean. I initially thought it could be keydown and keyup events, but it is not, because
> on pressing the keydown, they are still both reported. I also think the desktops handle this, maybe by filtering out
> 0 values. I use KDE Plasma, and I still have 5% step despite evtest reporting these 2 events.
The 1 / 0 events are indeed press / release events that is
not the problem, the problem is that a single keypress reports
these events on 2 different /dev/input/event# nodes.
Interesting that this is not a problem for KDE, I know it is
a problem for GNOME. I guess KDE may do some filtering of
the duplicate events itself.
> I have applied the last 2 patches.
>
> 1. Show no output for capslock / printscreen
>
> Correct. These keys are no longer captured by Asus WMI hotkeys
>
> 2. Show KEY_SELECTIVE_SCREENSHOT events for the
> "Screen Capture" hotkey.
>
> I am not sure I am getting KEY_SELECTIVE_SCREENSHOT event for the "Screen Capture" hotkey. This is what I get:
> Event: time 1697757579.588239, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
> Event: time 1697757579.588239, type 1 (EV_KEY), code 634 (?), value 1
> Event: time 1697757579.588239, -------------- SYN_REPORT ------------
> Event: time 1697757579.588244, type 1 (EV_KEY), code 634 (?), value 0
> Event: time 1697757579.588244, -------------- SYN_REPORT ------------
This is actually the correct output, 634 is 0x27a hexadecimal and:
/usr/include/linux/input-event-codes.h :
/* Select an area of screen to be copied */
#define KEY_SELECTIVE_SCREENSHOT 0x27a
This is a somewhat (but not really) recent addition to the list
of KEY_foo defines, so I guess you are just using a somewhat old
evtest which does not know this code yet.
>
> And this is what I get for "Screen Capture" hotkey, from the debug you placed
> [ 1096.691389] asus_wmi: raw event code 0x2a
> [ 1096.691446] asus_wmi: raw event code 0xffffffffffffffff
> [ 1097.982976] asus_wmi: raw event code 0x2a
> [ 1097.983032] asus_wmi: raw event code 0xffffffffffffffff
>
>
> 3. Show no output for brightness up/down,
> yet brightness up/down should still work since
> these are also reported by the "ACPI video bus"
>
> Yes, correct. No output from Asus WMI hotkeys, but there an output from Video bus
Great, that means that everything works as it should now, thank you.
Regards,
Hans
> On 18/10/2023 19:35, Hans de Goede wrote:
>> Hi James,
>>
>> On 10/18/23 02:17, [email protected] wrote:
>>> 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
>> The 2 evtest logs show that each brightness up/down keypress
>> gets reported twice, once by the "ACPI video bus" device and
>> once bythe "Asus WMI hotkeys" device.
>>
>> This means that in e.g. GNOME the brightness will move
>> up / down by 2 steps for each step, reducing the amount
>> of steps from 20 to 10, or iow making each step twice
>> as big. Especially at the low end of the brightness
>> scale this may be an issue since steeping by 5% there
>> can already make a big difference and this double
>> key press reporting now changes this into stepping
>> by 10% at a time.
>>
>>> After applying your patch, it seems to have fixed the issue!
>> Thank you for all the testing and other then the double
>> keypress issue + the unknown code messages everything
>> now looks good!
>>
>> I have applied 2 more patches the first one fixes the
>> unknown code messages and adds a mapping for the
>> "Screen Capture" hotkey. The second test filters out
>> the duplicate (duplicate with the "ACPI video bus")
>> brightness up/down events.
>>
>> It would be great if you can add these on top of
>> the previous 2 patches and then run one last
>> test for me:
>>
>> Run evtest on the "Asus WMI hotkeys" device this should now:
>>
>> 1. Show no output for capslock / printscreen
>>
>> 2. Show KEY_SELECTIVE_SCREENSHOT events for the
>> "Screen Capture" hotkey.
>>
>> 3. Show no output for brightness up/down,
>> yet brightness up/down should still work since
>> these are also reported by the "ACPI video bus"
>>
>> It would be great if you can confirm for each of these
>> that this behaves as expected with the 2 extra patches
>> applied on top of the previous patches.
>>
>> Regards,
>>
>> Hans
>
That is noted. I have learnt some things while solving this.
Thank you
On 21/10/2023 09:46, Hans de Goede wrote:
> Hi James,
>
> On 10/20/23 01:22, James John wrote:
>> Hello Hans,
>>
>> Thank you for your support so far. I really appreciate this.
>>
>> I have always wanted to contribute to the kernel, so, this is fun for me! :)
> That is great and thank you for all your help with solving this.
>
>> The 2 evtest logs show that each brightness up/down keypress
>> gets reported twice, once by the "ACPI video bus" device and
>> once bythe "Asus WMI hotkeys" device.
>>
>> I do not think these are multiple events. There are different. One has the value of 0, the other has value of 1.
>> I am not sure what they mean. I initially thought it could be keydown and keyup events, but it is not, because
>> on pressing the keydown, they are still both reported. I also think the desktops handle this, maybe by filtering out
>> 0 values. I use KDE Plasma, and I still have 5% step despite evtest reporting these 2 events.
> The 1 / 0 events are indeed press / release events that is
> not the problem, the problem is that a single keypress reports
> these events on 2 different /dev/input/event# nodes.
>
> Interesting that this is not a problem for KDE, I know it is
> a problem for GNOME. I guess KDE may do some filtering of
> the duplicate events itself.
>
>> I have applied the last 2 patches.
>>
>> 1. Show no output for capslock / printscreen
>>
>> Correct. These keys are no longer captured by Asus WMI hotkeys
>>
>> 2. Show KEY_SELECTIVE_SCREENSHOT events for the
>> "Screen Capture" hotkey.
>>
>> I am not sure I am getting KEY_SELECTIVE_SCREENSHOT event for the "Screen Capture" hotkey. This is what I get:
>> Event: time 1697757579.588239, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
>> Event: time 1697757579.588239, type 1 (EV_KEY), code 634 (?), value 1
>> Event: time 1697757579.588239, -------------- SYN_REPORT ------------
>> Event: time 1697757579.588244, type 1 (EV_KEY), code 634 (?), value 0
>> Event: time 1697757579.588244, -------------- SYN_REPORT ------------
> This is actually the correct output, 634 is 0x27a hexadecimal and:
>
> /usr/include/linux/input-event-codes.h :
>
> /* Select an area of screen to be copied */
> #define KEY_SELECTIVE_SCREENSHOT 0x27a
>
> This is a somewhat (but not really) recent addition to the list
> of KEY_foo defines, so I guess you are just using a somewhat old
> evtest which does not know this code yet.
>
>> And this is what I get for "Screen Capture" hotkey, from the debug you placed
>> [ 1096.691389] asus_wmi: raw event code 0x2a
>> [ 1096.691446] asus_wmi: raw event code 0xffffffffffffffff
>> [ 1097.982976] asus_wmi: raw event code 0x2a
>> [ 1097.983032] asus_wmi: raw event code 0xffffffffffffffff
>>
>>
>> 3. Show no output for brightness up/down,
>> yet brightness up/down should still work since
>> these are also reported by the "ACPI video bus"
>>
>> Yes, correct. No output from Asus WMI hotkeys, but there an output from Video bus
> Great, that means that everything works as it should now, thank you.
>
> Regards,
>
> Hans
>
>
>
>
>
>
>> On 18/10/2023 19:35, Hans de Goede wrote:
>>> Hi James,
>>>
>>> On 10/18/23 02:17, [email protected] wrote:
>>>> 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
>>> The 2 evtest logs show that each brightness up/down keypress
>>> gets reported twice, once by the "ACPI video bus" device and
>>> once bythe "Asus WMI hotkeys" device.
>>>
>>> This means that in e.g. GNOME the brightness will move
>>> up / down by 2 steps for each step, reducing the amount
>>> of steps from 20 to 10, or iow making each step twice
>>> as big. Especially at the low end of the brightness
>>> scale this may be an issue since steeping by 5% there
>>> can already make a big difference and this double
>>> key press reporting now changes this into stepping
>>> by 10% at a time.
>>>
>>>> After applying your patch, it seems to have fixed the issue!
>>> Thank you for all the testing and other then the double
>>> keypress issue + the unknown code messages everything
>>> now looks good!
>>>
>>> I have applied 2 more patches the first one fixes the
>>> unknown code messages and adds a mapping for the
>>> "Screen Capture" hotkey. The second test filters out
>>> the duplicate (duplicate with the "ACPI video bus")
>>> brightness up/down events.
>>>
>>> It would be great if you can add these on top of
>>> the previous 2 patches and then run one last
>>> test for me:
>>>
>>> Run evtest on the "Asus WMI hotkeys" device this should now:
>>>
>>> 1. Show no output for capslock / printscreen
>>>
>>> 2. Show KEY_SELECTIVE_SCREENSHOT events for the
>>> "Screen Capture" hotkey.
>>>
>>> 3. Show no output for brightness up/down,
>>> yet brightness up/down should still work since
>>> these are also reported by the "ACPI video bus"
>>>
>>> It would be great if you can confirm for each of these
>>> that this behaves as expected with the 2 extra patches
>>> applied on top of the previous patches.
>>>
>>> Regards,
>>>
>>> Hans
Hi Juri,
On 11/24/23 16:54, Juri Vitali wrote:
> Hi,
> Unfortunately those patches have broken the backlight reporting on older
> laptops, which do rely on the old mechanism.
Thank you for reporting this and sorry about the regression.
And thank you for writing a good bug report with as much info
included as possible, that is much appreciated.
> For instance, on my Asus UX32A/VD when pressing the backlight up/down button
> the backlight changes accordingly,
Ok, so the embedded-controller (EC) is adjusting the brightness
itself in reaction to the key presses, which means that
the old behavior of sending KEY_BRIGHTNESSDOWN /
KEY_BRIGHTNESSUP was not really correct because that will
cause e.g. GNOME to then increase the brightness itself
which means that if the new brightness is correctly reflected
when reading it GNOME may increase the brightness an
additional step on top of the step it has already been
increased by the EC itself.
Which makes me wonder how to properly solve this,
so I have a bunch of questions:
1. What desktop environment are you using ?
2. Assuming you are using GNOME (for now) I guess that with older
kernels you got an on-screen-display (OSD) notification about
the brightness changing? Do you notice any difference in how
many total steps you have going from min to max with older
kernels vs the new kernel ? If the double increase problem
happens I guess you only get 5 brightness levels in GNOME /
4 steps from going from minimal to maximum ?
Note below questions should all be answered with the new kernel
with the unknown key messages in dmesg.
3. Can you do:
ls /sys/class/backlight
And let me know the output, I wonder what method is being
used to control backlight on your machine.
4. Can you do:
cat /sys/class/backlight/$name/max_brightness
What does this say?
With $name being the name from 3.
5. Can you do:
cat /sys/class/backlight/$name/brightness
And then change the brightness using the keys, and then
again do:
cat /sys/class/backlight/$name/brightness
What are the values shown before / after changing it ?
6. Can you repeat 5 but then do:
cat /sys/class/backlight/$name/actual_brightness
7. Can you run:
sudo acpidump -o acpidump.txt
And then email me the generated acpidump.txt file
in a private email ?
> but the event is not caught by the system
> (more precisely, dmesg is complaining of unknown key codes):
>
>> [ 3167.842213] asus_wmi: Unknown key code 0x29
>> [ 3168.105096] asus_wmi: Unknown key code 0x28
>> [ 3168.142526] asus_wmi: Unknown key code 0x27
>> [ 3168.178860] asus_wmi: Unknown key code 0x26
>> [ 3168.216027] asus_wmi: Unknown key code 0x25
>> [ 3168.256511] asus_wmi: Unknown key code 0x24
>> [ 3168.292907] asus_wmi: Unknown key code 0x23
>> [ 3168.329704] asus_wmi: Unknown key code 0x22
>> [ 3168.366554] asus_wmi: Unknown key code 0x21
>> [ 3168.406681] asus_wmi: Unknown key code 0x20
>> [ 3168.443330] asus_wmi: Unknown key code 0x20
>> [ 3168.480900] asus_wmi: Unknown key code 0x20
>> [ 3168.516326] asus_wmi: Unknown key code 0x20
>> [ 3168.554006] asus_wmi: Unknown key code 0x20
>> [ 3168.593320] asus_wmi: Unknown key code 0x20
>> [ 3168.630108] asus_wmi: Unknown key code 0x20
>> [ 3168.670110] asus_wmi: Unknown key code 0x20
>> [ 3168.943217] asus_wmi: Unknown key code 0x11
>> [ 3169.203349] asus_wmi: Unknown key code 0x12
>> [ 3169.243239] asus_wmi: Unknown key code 0x13
>> [ 3169.279881] asus_wmi: Unknown key code 0x14
>> [ 3169.316311] asus_wmi: Unknown key code 0x15
>> [ 3169.352887] asus_wmi: Unknown key code 0x16
>> [ 3169.392806] asus_wmi: Unknown key code 0x17
>> [ 3169.429301] asus_wmi: Unknown key code 0x18
>> [ 3169.465843] asus_wmi: Unknown key code 0x19
>> [ 3169.502404] asus_wmi: Unknown key code 0x1a
>> [ 3169.542308] asus_wmi: Unknown key code 0x1a
>> [ 3169.578938] asus_wmi: Unknown key code 0x1a
>> [ 3169.615506] asus_wmi: Unknown key code 0x1a
>> [ 3169.652002] asus_wmi: Unknown key code 0x1a
>> [ 3169.692280] asus_wmi: Unknown key code 0x1a
>
> In this case it seems that the backlight-down codes go from 0x20 to 0x29 while
> the -up from 0x11 to 0x1a, so assuming they are not clamped somewhere else
> they should not conflict with the ones used on newer models.
Thanks, that (the codes not overlapping with newer models codes) is
useful information to have. With that it should be easy to restore
the old behavior of sending KEY_BRIGHTNESSDOWN / UP, my questions
above are mainly because I wonder if that is the right thing to do
taking into account that the EC already adjusts the brightness itself.
> By the way, I only found those codes to be reported by asus-wmi, while other
> inputs remain silent while pressing those keys.
Yes that is expected, for unknown asus-wmi events no events
are send to userspace.
Regards,
Hans
Hi Juri,
On 11/25/23 15:25, Hans de Goede wrote:
> Hi Juri,
>
> On 11/24/23 16:54, Juri Vitali wrote:
>> Hi,
>> Unfortunately those patches have broken the backlight reporting on older
>> laptops, which do rely on the old mechanism.
>
> Thank you for reporting this and sorry about the regression.
>
> And thank you for writing a good bug report with as much info
> included as possible, that is much appreciated.
>
>> For instance, on my Asus UX32A/VD when pressing the backlight up/down button
>> the backlight changes accordingly,
>
> Ok, so the embedded-controller (EC) is adjusting the brightness
> itself in reaction to the key presses, which means that
> the old behavior of sending KEY_BRIGHTNESSDOWN /
> KEY_BRIGHTNESSUP was not really correct because that will
> cause e.g. GNOME to then increase the brightness itself
> which means that if the new brightness is correctly reflected
> when reading it GNOME may increase the brightness an
> additional step on top of the step it has already been
> increased by the EC itself.
>
> Which makes me wonder how to properly solve this,
> so I have a bunch of questions:
>
> 1. What desktop environment are you using ?
>
> 2. Assuming you are using GNOME (for now) I guess that with older
> kernels you got an on-screen-display (OSD) notification about
> the brightness changing? Do you notice any difference in how
> many total steps you have going from min to max with older
> kernels vs the new kernel ? If the double increase problem
> happens I guess you only get 5 brightness levels in GNOME /
> 4 steps from going from minimal to maximum ?
>
>
> Note below questions should all be answered with the new kernel
> with the unknown key messages in dmesg.
>
>
> 3. Can you do:
>
> ls /sys/class/backlight
>
> And let me know the output, I wonder what method is being
> used to control backlight on your machine.
>
> 4. Can you do:
>
> cat /sys/class/backlight/$name/max_brightness
>
> What does this say?
>
> With $name being the name from 3.
>
> 5. Can you do:
>
> cat /sys/class/backlight/$name/brightness
>
> And then change the brightness using the keys, and then
> again do:
>
> cat /sys/class/backlight/$name/brightness
>
> What are the values shown before / after changing it ?
>
> 6. Can you repeat 5 but then do:
>
> cat /sys/class/backlight/$name/actual_brightness
>
> 7. Can you run:
>
> sudo acpidump -o acpidump.txt
>
> And then email me the generated acpidump.txt file
> in a private email ?
I guess you have not been able to make some time to answer
the above questions yet.
Any chance you can make some time to gather this info soon ?
Regards,
Hans
Hi,
On 12/4/23 14:06, [email protected] wrote:
> December 4, 2023 at 01:32, [email protected] wrote:
>>
>> Thank you for the reply, and sorry for the delay.
>>
>> As I was gathering the information you asked for I realized that the behavior has changed in the meantime, and I am not sure of the reason why (but I guess due to some package update, possibly unrelated to this).
>>
>> If I understand correctly, now the events are no longer reported by the Asus WMI driver, but by the Intel backlight driver. Because of this the backlight variations are once again reported by the DM (KDE Plasma 5, on Arch Linux) in 5% increments, and no longer seem to be under EC control (i.e. the backlight is no longer adjustable during boot, before the DE is up).
>> The new behavior persist even downgrading the kernel and the firmware package, so I'm not sure which package may be responsible for the change.
>>
>
> Investigating further I found that that the change was not due to an updated package, but because I mistakenly removed a kernel cmdline argument, i.e. `"acpi_osi=!Windows 2012"`. Restoring it the behavior returns to the same as before.
>
>> Booting into Debian Bookworm (v6.1.0-13) the old behavior is restored (i.e. the one before the previous patches), with Asus-WMI once again in control (so I guess that at least the change do not persist across reboots).
>>
>> For the aforementioned reasons I can no longer reproduce the issue on the original environment (KDE Plasma 5 on Arch Linux) but the behavior on Gnome on Debian is basically the same as before, so I'll be using that.
>> In both cases (now on Debian, and previously on Arch) the brightness has a granularity on 10-ish steps (0-100% in increments of 10% for KDE Plasma on Arch, and 9 unnamed steps on Gnome on Debian), and no "double-change" seem to be occurring.
>
>> On Debian:
>>>
>>> $ ls -l /sys/class/backlight/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 4 00:26 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
>>> lrwxrwxrwx 1 root root 0 Dec 4 00:26 acpi_video1 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
>>>
>>
>> On Arch:
>>>
>>> ls -l /sys/class/backlight/
>>> totale 0
>>> lrwxrwxrwx 1 root root 0 4 dic 00.43 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/intel_backlight
>>>
>>
>> On Debian:
>> * `max_brightness` is `10` on both devices;
>> * `brightness` goes from 1 to 10 following the screen brighness only for `acpi_video0`, while in `acpi_video1` it is stuck at `10`;
>> * `actual_brightness` follows the screen brightness on both devices.
>>
>> On Arch:
>> * `max_brighness` is 4296;
>> * `brightness` changes in steps of 215 units for each 5% reported increment;
>> * `actual_brightness` is the same as `brighness`.
>>
>> Notice that before the latest change in behavior the output on Arch was IIRC the same as now on Debian, but unfortunately I haven't recorded it so I cannot say with absolute certainty.
>
> Restoring `"acpi_osi=!Windows 2012"`, on Arch Linux the result is:
>> % uname -a
>> Linux Arch-Zenbook 6.1.64-1-lts #1 SMP PREEMPT_DYNAMIC Tue, 28 Nov 2023 19:37:35 +0000 x86_64 GNU/Linux
>> % ls -l /sys/class/backlight
>> totale 0
>> lrwxrwxrwx 1 root root 0 4 dic 13.41 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
>> lrwxrwxrwx 1 root root 0 4 dic 13.41 acpi_video1 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
>
> * `max_brightness` is `10` on both devices;
> * `brighness` is stuck at `10` on both;
> * `actual_brightness` goes from 0 to 10 only on `acpi_video1`, while is stuck at 10 on `acpi_video0`.
>
> Notice that with this kernel and configuration I again have the `unknown key code` messages and no OSD feedback, which I wasn't able to replicate in the previous message.
Ok, that is good to know. Is there any specific reason why you are passing
"acpi_osi=!Windows 2012" on the kernel commandline?
Generally speaking passing any other kernel arguments then those used
to specify the root filesystem and things like "quiet" is not advisable.
Everything should just work without passing any special options and if things
do not work without special options then that is a bug which needs to be fixed.
Regards,
hans