You are not logged in.
@lavish_jaat wrote "I mean Audio Up and Audio Down."
Interesting that is new. Please run "sudo evtest" this will give you a list of input devices, then for each listed input device select it and then press the audio up/down keys to see if that device reports audio up/down presses.
I expect you will find 2 input devices which will report the audio up/down events. Please write down the name of the input-devices which cause these audio up/down events and please also save the full evtest output (showing the audio up/down key presses) for these 2 input devices.
And then report back here with the name of the 2 input devices as well as copy and paste or attach the evtest output for the 2 input devices.
Offline
@lavish_jaat wrote "I mean Audio Up and Audio Down."
Interesting that is new. Please run "sudo evtest" this will give you a list of input devices, then for each listed input device select it and then press the audio up/down keys to see if that device reports audio up/down presses.
I expect you will find 2 input devices which will report the audio up/down events. Please write down the name of the input-devices which cause these audio up/down events and please also save the full evtest output (showing the audio up/down key presses) for these 2 input devices.
And then report back here with the name of the 2 input devices as well as copy and paste or attach the evtest output for the 2 input devices.
Here is the output of "sudo evtest" with "/dev/input/event6: Asus WMI hotkeys":
https://pastebin.com/X1GLtEmf
And here is with "/dev/input3: AT Translated Set 2 keyboard":
Offline
Here is the output of "sudo evtest" with "/dev/input/event6: Asus WMI hotkeys":
https://pastebin.com/X1GLtEmfAnd here is with "/dev/input3: AT Translated Set 2 keyboard":
Thank you.
Can you please also try the speaker-mute key in evtest for the "AT Translated Set 2 keyboard" and "Asus WMI hotkeys" and see if that reports double events too ?
Ok so the logs show what I expected / hoped for. We can detect the double key-presses inside the kernel and then filter them out.
I have prepared a series of patches implementing this, please give a kernel with these 4 patches added (see Arch docs on building a patched kernel) a try:
https://fedorapeople.org/~jwrdegoede/asus-wmi/
With this series the "Asus WMI hotkeys" /dev/input/event# node should no longer report volume key-presses.
Note depending on in which order the PS/2 data vs the WMI event are handled the first volume key press may still be reported twice. This is a compromise versus DMI quirks (unmaintainable) or other more complex solutions.
Offline
lavish_jaat wrote:Here is the output of "sudo evtest" with "/dev/input/event6: Asus WMI hotkeys":
https://pastebin.com/X1GLtEmfAnd here is with "/dev/input3: AT Translated Set 2 keyboard":
Thank you.
Can you please also try the speaker-mute key in evtest for the "AT Translated Set 2 keyboard" and "Asus WMI hotkeys" and see if that reports double events too ?
Ok so the logs show what I expected / hoped for. We can detect the double key-presses inside the kernel and then filter them out.
I have prepared a series of patches implementing this, please give a kernel with these 4 patches added (see Arch docs on building a patched kernel) a try:
https://fedorapeople.org/~jwrdegoede/asus-wmi/With this series the "Asus WMI hotkeys" /dev/input/event# node should no longer report volume key-presses.
Note depending on in which order the PS/2 data vs the WMI event are handled the first volume key press may still be reported twice. This is a compromise versus DMI quirks (unmaintainable) or other more complex solutions.
Thanks for your effort but I think I will wait for the solution to get merged in the Kernel itself.
Offline
Thanks for your effort but I think I will wait for the solution to get merged in the Kernel itself.
Hmm, 2 questions:
1. Can you please still answer: "Can you please also try the speaker-mute key in evtest for the "AT Translated Set 2 keyboard" and "Asus WMI hotkeys" and see if that reports double events too ?" depending on the answer the patches may need to be modified.
2. Would it help of I ask an Arch developer to prepare an Arch kernel build for you to test? I prefer not to submit the patches upstream until I have confirmation that they fix things.
Offline
linux 6.5.9.arch2 built with the four patches from https://fedorapeople.org/~jwrdegoede/asus-wmi/ applied:
https://drive.google.com/file/d/1uJurjU … sp=sharing linux-6.5.9.arch2-1.1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1t70YEJ … sp=sharing linux-headers-6.5.9.arch2-1.1-x86_64.pkg.tar.zst
Last edited by loqs (2023-10-30 17:24:00)
Offline
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.
Offline