From: me@donjajo.com
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Corentin Chary" <corentin.chary@gmail.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Mark Gross" <markgross@kernel.org>,
platform-driver-x86@vger.kernel.org,
acpi4asus-user@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
Date: Tue, 17 Oct 2023 19:17:32 -0500 [thread overview]
Message-ID: <6c97dc9e9cfea6e18c59d717e5973255@donjajo.com> (raw)
In-Reply-To: <938c83c4-973d-ac23-bfb6-53c63c153d81@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 10213 bytes --]
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
>>>>>
[-- Attachment #2: evtest-asus-wmi.txt --]
[-- Type: text/plain, Size: 3047 bytes --]
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Asus WMI hotkeys"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 113 (KEY_MUTE)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 140 (KEY_CALC)
Event code 148 (KEY_PROG1)
Event code 149 (KEY_PROG2)
Event code 150 (KEY_WWW)
Event code 152 (KEY_SCREENLOCK)
Event code 163 (KEY_NEXTSONG)
Event code 164 (KEY_PLAYPAUSE)
Event code 165 (KEY_PREVIOUSSONG)
Event code 166 (KEY_STOPCD)
Event code 169 (KEY_PHONE)
Event code 183 (KEY_F13)
Event code 185 (KEY_F15)
Event code 190 (KEY_F20)
Event code 191 (KEY_F21)
Event code 202 (KEY_PROG3)
Event code 203 (KEY_PROG4)
Event code 212 (KEY_CAMERA)
Event code 215 (KEY_EMAIL)
Event code 225 (KEY_BRIGHTNESSUP)
Event code 226 (KEY_MEDIA)
Event code 227 (KEY_SWITCHVIDEOMODE)
Event code 229 (KEY_KBDILLUMDOWN)
Event code 230 (KEY_KBDILLUMUP)
Event code 237 (KEY_BLUETOOTH)
Event code 238 (KEY_WLAN)
Event code 240 (KEY_UNKNOWN)
Event code 247 (KEY_RFKILL)
Event code 470 (KEY_FN_F5)
Event code 531 (KEY_TOUCHPAD_ON)
Event code 560 (KEY_ALS_TOGGLE)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Key repeat handling:
Repeat type 20 (EV_REP)
Repeat code 0 (REP_DELAY)
Value 250
Repeat code 1 (REP_PERIOD)
Value 33
Properties:
Testing ... (interrupt to exit)
Event: time 1697583236.975661, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time 1697583236.975661, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1697583236.975661, -------------- SYN_REPORT ------------
Event: time 1697583236.975674, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1697583236.975674, -------------- SYN_REPORT ------------
Event: time 1697583238.413018, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2f
Event: time 1697583238.413018, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583238.413018, -------------- SYN_REPORT ------------
Event: time 1697583238.413036, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583238.413036, -------------- SYN_REPORT ------------
Event: time 1697583239.472226, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time 1697583239.472226, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1697583239.472226, -------------- SYN_REPORT ------------
Event: time 1697583239.472237, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1697583239.472237, -------------- SYN_REPORT ------------
Event: time 1697583241.599500, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2f
Event: time 1697583241.599500, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583241.599500, -------------- SYN_REPORT ------------
Event: time 1697583241.599511, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583241.599511, -------------- SYN_REPORT ------------
[-- Attachment #3: evtest-video-bus.txt --]
[-- Type: text/plain, Size: 1791 bytes --]
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x6 version 0x0
Input device name: "Video Bus"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 224 (KEY_BRIGHTNESSDOWN)
Event code 225 (KEY_BRIGHTNESSUP)
Event code 227 (KEY_SWITCHVIDEOMODE)
Event code 241 (KEY_VIDEO_NEXT)
Event code 242 (KEY_VIDEO_PREV)
Event code 243 (KEY_BRIGHTNESS_CYCLE)
Event code 244 (KEY_BRIGHTNESS_ZERO)
Event code 245 (KEY_DISPLAY_OFF)
Properties:
Testing ... (interrupt to exit)
Event: time 1697583061.695285, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1
Event: time 1697583061.695285, -------------- SYN_REPORT ------------
Event: time 1697583061.695303, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0
Event: time 1697583061.695303, -------------- SYN_REPORT ------------
Event: time 1697583062.935233, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583062.935233, -------------- SYN_REPORT ------------
Event: time 1697583062.935248, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583062.935248, -------------- SYN_REPORT ------------
Event: time 1697583065.169344, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1
Event: time 1697583065.169344, -------------- SYN_REPORT ------------
Event: time 1697583065.169364, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0
Event: time 1697583065.169364, -------------- SYN_REPORT ------------
Event: time 1697583065.748833, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1697583065.748833, -------------- SYN_REPORT ------------
Event: time 1697583065.748863, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1697583065.748863, -------------- SYN_REPORT ------------
next prev parent reply other threads:[~2023-10-18 0:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-01 8:11 James John
2023-10-01 9:28 ` Hans de Goede
2023-10-01 8:46 ` James John
2023-10-01 13:45 ` Hans de Goede
2023-10-01 14:16 ` James John
2023-10-01 14:18 ` James John
2023-10-01 15:09 ` James John
2023-10-11 10:44 ` Hans de Goede
2023-10-11 15:43 ` Hans de Goede
2023-11-24 15:54 ` Juri Vitali
2023-11-25 14:25 ` Hans de Goede
2023-12-03 15:44 ` Hans de Goede
2023-12-04 0:32 ` juri
2023-12-04 0:32 ` juri
2023-12-04 13:06 ` juri
2023-12-04 13:54 ` Hans de Goede
2023-12-04 15:52 ` juri
2023-10-17 8:50 ` Hans de Goede
2023-10-18 0:17 ` me [this message]
2023-10-18 19:35 ` Hans de Goede
2023-10-19 23:22 ` James John
2023-10-21 9:46 ` Hans de Goede
2023-10-21 9:53 ` James John
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6c97dc9e9cfea6e18c59d717e5973255@donjajo.com \
--to=me@donjajo.com \
--cc=acpi4asus-user@lists.sourceforge.net \
--cc=corentin.chary@gmail.com \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®