* PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
@ 2023-10-01 8:11 James John
2023-10-01 9:28 ` Hans de Goede
0 siblings, 1 reply; 23+ messages in thread
From: James John @ 2023-10-01 8:11 UTC (permalink / raw)
To: Corentin Chary, Hans de Goede, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
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!
[-- Attachment #2: lininput.log --]
[-- Type: text/x-log, Size: 2232 bytes --]
libinput debug-events
-event2 DEVICE_ADDED Power Button seat0 default group1 cap:k
-event4 DEVICE_ADDED Video Bus seat0 default group2 cap:k
-event0 DEVICE_ADDED Lid Switch seat0 default group3 cap:S
-event1 DEVICE_ADDED Power Button seat0 default group4 cap:k
-event6 DEVICE_ADDED ASUE1214:00 04F3:328B Mouse seat0 default group5 cap:p left scroll-nat scroll-button
-event7 DEVICE_ADDED ASUE1214:00 04F3:328B Touchpad seat0 default group5 cap:pg size 129x79mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on dwtp-on
-event8 DEVICE_ADDED Asus WMI hotkeys seat0 default group6 cap:k
-event3 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group7 cap:k
event3 KEYBOARD_KEY +0.000s *** (-1) pressed
event3 KEYBOARD_KEY +0.064s *** (-1) released
-event8 KEYBOARD_KEY +0.075s KEY_BRIGHTNESSDOWN (224) pressed
event8 KEYBOARD_KEY +0.075s KEY_BRIGHTNESSDOWN (224) released
-event3 KEYBOARD_KEY +15.294s *** (-1) pressed
event3 KEYBOARD_KEY +15.382s *** (-1) released
-event8 KEYBOARD_KEY +15.396s KEY_BRIGHTNESSDOWN (224) pressed
event8 KEYBOARD_KEY +15.396s KEY_BRIGHTNESSDOWN (224) released
-event3 KEYBOARD_KEY +15.886s *** (-1) pressed
event3 KEYBOARD_KEY +15.987s *** (-1) released
-event8 KEYBOARD_KEY +15.998s KEY_BRIGHTNESSDOWN (224) pressed
event8 KEYBOARD_KEY +15.998s KEY_BRIGHTNESSDOWN (224) released
-event3 KEYBOARD_KEY +16.506s *** (-1) pressed
event3 KEYBOARD_KEY +16.603s *** (-1) released
-event8 KEYBOARD_KEY +16.617s KEY_BRIGHTNESSDOWN (224) pressed
event8 KEYBOARD_KEY +16.617s KEY_BRIGHTNESSDOWN (224) released
-event3 KEYBOARD_KEY +19.351s *** (-1) pressed
event3 KEYBOARD_KEY +19.583s *** (-1) pressed
[-- Attachment #3: proc-cpuinfo.log --]
[-- Type: text/x-log, Size: 20161 bytes --]
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 870.958
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 0
cpu cores : 10
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 400.000
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 0
cpu cores : 10
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 444.273
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 4
cpu cores : 10
apicid : 8
initial apicid : 8
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 400.000
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 4
cpu cores : 10
apicid : 9
initial apicid : 9
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 400.000
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 8
cpu cores : 10
apicid : 16
initial apicid : 16
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 678.394
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 9
cpu cores : 10
apicid : 18
initial apicid : 18
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 722.086
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 10
cpu cores : 10
apicid : 20
initial apicid : 20
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 783.639
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 11
cpu cores : 10
apicid : 22
initial apicid : 22
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 8
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 400.000
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 12
cpu cores : 10
apicid : 24
initial apicid : 24
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 9
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 1188.315
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 13
cpu cores : 10
apicid : 26
initial apicid : 26
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 10
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 400.000
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 14
cpu cores : 10
apicid : 28
initial apicid : 28
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 11
vendor_id : GenuineIntel
cpu family : 6
model : 186
model name : 13th Gen Intel(R) Core(TM) i7-1355U
stepping : 3
microcode : 0x410e
cpu MHz : 400.000
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 15
cpu cores : 10
apicid : 30
initial apicid : 30
fpu : yes
fpu_exception : yes
cpuid level : 32
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips : 5224.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
[-- Attachment #4: proc-iomem.log --]
[-- Type: text/x-log, Size: 4566 bytes --]
00000000-00000000 : Reserved
00000000-00000000 : System RAM
00000000-00000000 : Reserved
00000000-00000000 : Unusable memory
00000000-00000000 : Reserved
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : System ROM
00000000-00000000 : System RAM
00000000-00000000 : ACPI Tables
00000000-00000000 : System RAM
00000000-00000000 : Reserved
00000000-00000000 : System RAM
00000000-00000000 : Reserved
00000000-00000000 : System RAM
00000000-00000000 : Reserved
00000000-00000000 : ACPI Tables
00000000-00000000 : ACPI Non-volatile Storage
00000000-00000000 : USBC000:00
00000000-00000000 : Reserved
00000000-00000000 : System RAM
00000000-00000000 : Reserved
00000000-00000000 : Reserved
00000000-00000000 : Reserved
00000000-00000000 : Graphics Stolen Memory
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : 0000:00:1f.5
00000000-00000000 : 0000:00:1f.5 0000:00:1f.5
00000000-00000000 : 0000:00:0e.0
00000000-00000000 : VMD MEMBAR1
00000000-00000000 : PCI Bus 10000:e1
00000000-00000000 : 10000:e1:00.0
00000000-00000000 : nvme
00000000-00000000 : PCI Bus 0000:2b
00000000-00000000 : PCI Bus 0000:01
00000000-00000000 : PCI MMCONFIG 0000 [bus 00-e0]
00000000-00000000 : INTC1055:00
00000000-00000000 : INTC1055:00 INTC1055:00
00000000-00000000 : INTC1055:00
00000000-00000000 : INTC1055:00 INTC1055:00
00000000-00000000 : INTC1055:00
00000000-00000000 : INTC1055:00 INTC1055:00
00000000-00000000 : INTC1055:00
00000000-00000000 : INTC1055:00 INTC1055:00
00000000-00000000 : Reserved
00000000-00000000 : Reserved
00000000-00000000 : IOAPIC 0
00000000-00000000 : Reserved
00000000-00000000 : HPET 0
00000000-00000000 : PNP0103:00
00000000-00000000 : Reserved
00000000-00000000 : MSFT0101:00
00000000-00000000 : MSFT0101:00 MSFT0101:00
00000000-00000000 : dmar0
00000000-00000000 : dmar1
00000000-00000000 : pnp 00:03
00000000-00000000 : pnp 00:03
00000000-00000000 : pnp 00:03
00000000-00000000 : Reserved
00000000-00000000 : System RAM
00000000-00000000 : Kernel code
00000000-00000000 : Kernel rodata
00000000-00000000 : Kernel data
00000000-00000000 : Kernel bss
00000000-00000000 : RAM buffer
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : 0000:00:02.0
00000000-00000000 : 0000:00:02.0
00000000-00000000 : 0000:00:15.0
00000000-00000000 : lpss_dev
00000000-00000000 : i2c_designware.0 lpss_dev
00000000-00000000 : lpss_priv
00000000-00000000 : idma64.0
00000000-00000000 : idma64.0 idma64.0
00000000-00000000 : 0000:00:15.1
00000000-00000000 : lpss_dev
00000000-00000000 : i2c_designware.1 lpss_dev
00000000-00000000 : lpss_priv
00000000-00000000 : idma64.1
00000000-00000000 : idma64.1 idma64.1
00000000-00000000 : 0000:00:1e.0
00000000-00000000 : lpss_dev
00000000-00000000 : serial
00000000-00000000 : lpss_priv
00000000-00000000 : idma64.2
00000000-00000000 : idma64.2 idma64.2
00000000-00000000 : 0000:00:1e.3
00000000-00000000 : lpss_dev
00000000-00000000 : pxa2xx-spi.3 lpss_dev
00000000-00000000 : lpss_priv
00000000-00000000 : idma64.3
00000000-00000000 : idma64.3 idma64.3
00000000-00000000 : 0000:00:02.0
00000000-00000000 : PCI Bus 0000:2b
00000000-00000000 : PCI Bus 0000:01
00000000-00000000 : 0000:00:0e.0
00000000-00000000 : 0000:00:02.0
00000000-00000000 : 0000:00:1f.3
00000000-00000000 : Audio DSP
00000000-00000000 : 0000:00:0e.0
00000000-00000000 : VMD MEMBAR2
00000000-00000000 : 0000:00:0d.2
00000000-00000000 : thunderbolt
00000000-00000000 : 0000:00:04.0
00000000-00000000 : proc_thermal
00000000-00000000 : 0000:00:14.0
00000000-00000000 : xhci-hcd
00000000-00000000 : 0000:00:12.0
00000000-00000000 : intel_ish_ipc
00000000-00000000 : 0000:00:0d.0
00000000-00000000 : xhci-hcd
00000000-00000000 : 0000:00:0a.0
00000000-00000000 : telem0
00000000-00000000 : telem1
00000000-00000000 : intel_vsec.telemetry.0
00000000-00000000 : intel_vsec.telemetry.0
00000000-00000000 : intel_vsec.telemetry.0
00000000-00000000 : intel_vsec.telemetry.0
00000000-00000000 : 0000:00:1f.3
00000000-00000000 : Audio DSP
00000000-00000000 : 0000:00:14.3
00000000-00000000 : iwlwifi
00000000-00000000 : 0000:00:14.2
00000000-00000000 : 0000:00:1f.4
00000000-00000000 : 0000:00:16.0
00000000-00000000 : mei_me
00000000-00000000 : 0000:00:14.2
00000000-00000000 : 0000:00:0d.2
00000000-00000000 : 0000:00:08.0
[-- Attachment #5: proc-ioports.log --]
[-- Type: text/x-log, Size: 862 bytes --]
0000-0000 : PCI Bus 0000:00
0000-0000 : dma1
0000-0000 : pic1
0000-0000 : timer0
0000-0000 : timer1
0000-0000 : keyboard
0000-0000 : PNP0C09:01
0000-0000 : EC data
0000-0000 : keyboard
0000-0000 : PNP0C09:01
0000-0000 : EC cmd
0000-0000 : rtc_cmos
0000-0000 : rtc0
0000-0000 : dma page reg
0000-0000 : pic2
0000-0000 : dma2
0000-0000 : fpu
0000-0000 : iTCO_wdt
0000-0000 : iTCO_wdt
0000-0000 : pnp 00:00
0000-0000 : PCI conf1
0000-0000 : PCI Bus 0000:00
0000-0000 : pnp 00:00
0000-0000 : ACPI PM1a_EVT_BLK
0000-0000 : ACPI PM1a_CNT_BLK
0000-0000 : ACPI PM_TMR
0000-0000 : ACPI PM2_CNT_BLK
0000-0000 : pnp 00:01
0000-0000 : ACPI GPE0_BLK
0000-0000 : pnp 00:04
0000-0000 : 0000:00:02.0
0000-0000 : PCI Bus 0000:01
0000-0000 : PCI Bus 0000:2b
0000-0000 : 0000:00:1f.4
0000-0000 : i801_smbus
[-- Attachment #6: proc-modules.log --]
[-- Type: text/x-log, Size: 12673 bytes --]
asus_nb_wmi 32768 0 - Live 0x0000000000000000 (E)
asus_wmi 98304 1 asus_nb_wmi, Live 0x0000000000000000 (E)
ntfs3 323584 1 - Live 0x0000000000000000
ccm 20480 6 - Live 0x0000000000000000
rfcomm 102400 16 - Live 0x0000000000000000
snd_seq_dummy 12288 0 - Live 0x0000000000000000
snd_hrtimer 12288 1 - Live 0x0000000000000000
snd_seq 131072 7 snd_seq_dummy, Live 0x0000000000000000
snd_seq_device 16384 1 snd_seq, Live 0x0000000000000000
cmac 12288 4 - Live 0x0000000000000000
algif_hash 12288 1 - Live 0x0000000000000000
algif_skcipher 12288 1 - Live 0x0000000000000000
af_alg 36864 6 algif_hash,algif_skcipher, Live 0x0000000000000000
bnep 36864 2 - Live 0x0000000000000000
snd_ctl_led 24576 0 - Live 0x0000000000000000
snd_soc_skl_hda_dsp 24576 4 - Live 0x0000000000000000
snd_soc_intel_hda_dsp_common 16384 1 snd_soc_skl_hda_dsp, Live 0x0000000000000000
snd_sof_probes 24576 0 - Live 0x0000000000000000
snd_soc_hdac_hdmi 45056 1 snd_soc_skl_hda_dsp, Live 0x0000000000000000
snd_hda_codec_hdmi 94208 1 - Live 0x0000000000000000
iwlmvm 696320 0 - Live 0x0000000000000000
snd_hda_codec_realtek 192512 1 - Live 0x0000000000000000
snd_hda_codec_generic 114688 1 snd_hda_codec_realtek, Live 0x0000000000000000
snd_soc_dmic 12288 1 - Live 0x0000000000000000
snd_sof_pci_intel_tgl 12288 0 - Live 0x0000000000000000
snd_sof_intel_hda_common 249856 1 snd_sof_pci_intel_tgl, Live 0x0000000000000000
intel_uncore_frequency 12288 0 - Live 0x0000000000000000
intel_uncore_frequency_common 16384 1 intel_uncore_frequency, Live 0x0000000000000000
soundwire_intel 81920 1 snd_sof_intel_hda_common, Live 0x0000000000000000
intel_tcc_cooling 12288 0 - Live 0x0000000000000000
x86_pkg_temp_thermal 16384 0 - Live 0x0000000000000000
snd_sof_intel_hda_mlink 36864 2 snd_sof_intel_hda_common,soundwire_intel, Live 0x0000000000000000
intel_powerclamp 20480 0 - Live 0x0000000000000000
mac80211 1572864 1 iwlmvm, Live 0x0000000000000000
soundwire_cadence 45056 1 soundwire_intel, Live 0x0000000000000000
snd_sof_intel_hda 24576 1 snd_sof_intel_hda_common, Live 0x0000000000000000
snd_sof_pci 24576 2 snd_sof_pci_intel_tgl,snd_sof_intel_hda_common, Live 0x0000000000000000
snd_sof_xtensa_dsp 16384 1 snd_sof_intel_hda_common, Live 0x0000000000000000
snd_sof 425984 4 snd_sof_probes,snd_sof_intel_hda_common,snd_sof_intel_hda,snd_sof_pci, Live 0x0000000000000000
hid_sensor_als 16384 0 - Live 0x0000000000000000
hid_sensor_trigger 20480 2 hid_sensor_als, Live 0x0000000000000000
snd_sof_utils 16384 1 snd_sof, Live 0x0000000000000000
industrialio_triggered_buffer 12288 1 hid_sensor_trigger, Live 0x0000000000000000
snd_soc_hdac_hda 28672 1 snd_sof_intel_hda_common, Live 0x0000000000000000
coretemp 16384 0 - Live 0x0000000000000000
kfifo_buf 12288 1 industrialio_triggered_buffer, Live 0x0000000000000000
snd_hda_ext_core 36864 5 snd_soc_hdac_hdmi,snd_sof_intel_hda_common,snd_sof_intel_hda_mlink,snd_sof_intel_hda,snd_soc_hdac_hda, Live 0x0000000000000000
hid_sensor_iio_common 20480 2 hid_sensor_als,hid_sensor_trigger, Live 0x0000000000000000
snd_soc_acpi_intel_match 90112 2 snd_sof_pci_intel_tgl,snd_sof_intel_hda_common, Live 0x0000000000000000
kvm_intel 425984 0 - Live 0x0000000000000000
industrialio 131072 4 hid_sensor_als,hid_sensor_trigger,industrialio_triggered_buffer,kfifo_buf, Live 0x0000000000000000
snd_soc_acpi 16384 2 snd_sof_intel_hda_common,snd_soc_acpi_intel_match, Live 0x0000000000000000
hid_sensor_custom 28672 0 - Live 0x0000000000000000
soundwire_generic_allocation 12288 1 soundwire_intel, Live 0x0000000000000000
soundwire_bus 139264 3 soundwire_intel,soundwire_cadence,soundwire_generic_allocation, Live 0x0000000000000000
snd_soc_core 458752 8 snd_soc_skl_hda_dsp,snd_sof_probes,snd_soc_hdac_hdmi,snd_soc_dmic,snd_sof_intel_hda_common,soundwire_intel,snd_sof,snd_soc_hdac_hda, Live 0x0000000000000000
libarc4 12288 1 mac80211, Live 0x0000000000000000
hid_sensor_hub 32768 4 hid_sensor_als,hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_custom, Live 0x0000000000000000
snd_compress 28672 2 snd_sof_probes,snd_soc_core, Live 0x0000000000000000
kvm 1376256 1 kvm_intel, Live 0x0000000000000000
intel_ishtp_hid 28672 0 - Live 0x0000000000000000
ac97_bus 12288 1 snd_soc_core, Live 0x0000000000000000
snd_pcm_dmaengine 16384 1 snd_soc_core, Live 0x0000000000000000
iwlwifi 569344 1 iwlmvm, Live 0x0000000000000000
snd_hda_intel 65536 0 - Live 0x0000000000000000
joydev 24576 0 - Live 0x0000000000000000
btusb 86016 0 - Live 0x0000000000000000
mousedev 24576 0 - Live 0x0000000000000000
snd_intel_dspcfg 40960 3 snd_sof_intel_hda_common,snd_sof,snd_hda_intel, Live 0x0000000000000000
irqbypass 12288 1 kvm, Live 0x0000000000000000
uvcvideo 176128 8 - Live 0x0000000000000000
snd_intel_sdw_acpi 16384 2 snd_sof_intel_hda_common,snd_intel_dspcfg, Live 0x0000000000000000
btrtl 32768 1 btusb, Live 0x0000000000000000
crct10dif_pclmul 12288 1 - Live 0x0000000000000000
crc32_pclmul 12288 0 - Live 0x0000000000000000
snd_hda_codec 225280 8 snd_soc_skl_hda_dsp,snd_soc_intel_hda_dsp_common,snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_sof_intel_hda,snd_soc_hdac_hda,snd_hda_intel, Live 0x0000000000000000
btintel 57344 1 btusb, Live 0x0000000000000000
polyval_clmulni 12288 0 - Live 0x0000000000000000
videobuf2_vmalloc 20480 1 uvcvideo, Live 0x0000000000000000
btbcm 24576 1 btusb, Live 0x0000000000000000
polyval_generic 12288 1 polyval_clmulni, Live 0x0000000000000000
gf128mul 16384 1 polyval_generic, Live 0x0000000000000000
uvc 12288 1 uvcvideo, Live 0x0000000000000000
snd_hda_scodec_cs35l41_spi 12288 0 - Live 0x0000000000000000
videobuf2_memops 16384 1 videobuf2_vmalloc, Live 0x0000000000000000
ghash_clmulni_intel 16384 0 - Live 0x0000000000000000
snd_hda_core 151552 11 snd_soc_intel_hda_dsp_common,snd_soc_hdac_hdmi,snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_sof_intel_hda_common,snd_sof_intel_hda,snd_soc_hdac_hda,snd_hda_ext_core,snd_hda_intel,snd_hda_codec, Live 0x0000000000000000
btmtk 12288 1 btusb, Live 0x0000000000000000
snd_hda_scodec_cs35l41_i2c 12288 0 - Live 0x0000000000000000
videobuf2_v4l2 40960 1 uvcvideo, Live 0x0000000000000000
iTCO_wdt 16384 0 - Live 0x0000000000000000
sha512_ssse3 53248 0 - Live 0x0000000000000000
snd_hda_scodec_cs35l41 53248 2 snd_hda_scodec_cs35l41_spi,snd_hda_scodec_cs35l41_i2c, Live 0x0000000000000000
vfat 20480 1 - Live 0x0000000000000000
aesni_intel 360448 9 - Live 0x0000000000000000
spi_pxa2xx_platform 36864 0 - Live 0x0000000000000000
fat 106496 1 vfat, Live 0x0000000000000000
hid_multitouch 32768 0 - Live 0x0000000000000000
videodev 389120 6 uvcvideo,videobuf2_v4l2, Live 0x0000000000000000
dw_dmac 12288 0 - Live 0x0000000000000000
8250_dw 24576 0 - Live 0x0000000000000000
ledtrig_audio 12288 3 asus_wmi,snd_ctl_led,snd_hda_codec_generic, Live 0x0000000000000000
pmt_telemetry 12288 0 - Live 0x0000000000000000
processor_thermal_device_pci 12288 0 - Live 0x0000000000000000
intel_pmc_bxt 16384 1 iTCO_wdt, Live 0x0000000000000000
snd_hwdep 20480 1 snd_hda_codec, Live 0x0000000000000000
bluetooth 1114112 44 rfcomm,bnep,btusb,btrtl,btintel,btbcm,btmtk, Live 0x0000000000000000
snd_hda_cs_dsp_ctls 20480 1 snd_hda_scodec_cs35l41, Live 0x0000000000000000
crypto_simd 16384 1 aesni_intel, Live 0x0000000000000000
cfg80211 1335296 3 iwlmvm,mac80211,iwlwifi, Live 0x0000000000000000
cryptd 28672 3 ghash_clmulni_intel,crypto_simd, Live 0x0000000000000000
mei_hdcp 28672 0 - Live 0x0000000000000000
mei_pxp 16384 0 - Live 0x0000000000000000
snd_pcm 204800 12 snd_soc_hdac_hdmi,snd_hda_codec_hdmi,snd_sof_intel_hda_common,soundwire_intel,snd_sof,snd_sof_utils,snd_soc_core,snd_compress,snd_pcm_dmaengine,snd_hda_intel,snd_hda_codec,snd_hda_core, Live 0x0000000000000000
rapl 20480 0 - Live 0x0000000000000000
cs_dsp 86016 2 snd_hda_scodec_cs35l41,snd_hda_cs_dsp_ctls, Live 0x0000000000000000
pmt_class 16384 1 pmt_telemetry, Live 0x0000000000000000
sparse_keymap 12288 1 asus_wmi, Live 0x0000000000000000
processor_thermal_device 20480 1 processor_thermal_device_pci, Live 0x0000000000000000
iTCO_vendor_support 12288 1 iTCO_wdt, Live 0x0000000000000000
intel_rapl_msr 20480 0 - Live 0x0000000000000000
intel_cstate 20480 0 - Live 0x0000000000000000
videobuf2_common 94208 4 uvcvideo,videobuf2_vmalloc,videobuf2_memops,videobuf2_v4l2, Live 0x0000000000000000
snd_timer 53248 3 snd_hrtimer,snd_seq,snd_pcm, Live 0x0000000000000000
snd_soc_cs35l41_lib 45056 3 snd_hda_scodec_cs35l41_spi,snd_hda_scodec_cs35l41_i2c,snd_hda_scodec_cs35l41, Live 0x0000000000000000
spi_nor 143360 0 - Live 0x0000000000000000
processor_thermal_rfim 28672 1 processor_thermal_device, Live 0x0000000000000000
platform_profile 12288 1 asus_wmi, Live 0x0000000000000000
ucsi_acpi 12288 0 - Live 0x0000000000000000
mei_me 57344 2 - Live 0x0000000000000000
wmi_bmof 12288 0 - Live 0x0000000000000000
pcspkr 12288 0 - Live 0x0000000000000000
mc 90112 8 uvcvideo,videobuf2_v4l2,videodev,videobuf2_common, Live 0x0000000000000000
intel_uncore 258048 0 - Live 0x0000000000000000
typec_ucsi 65536 1 ucsi_acpi, Live 0x0000000000000000
processor_thermal_mbox 16384 2 processor_thermal_device,processor_thermal_rfim, Live 0x0000000000000000
intel_ish_ipc 40960 0 - Live 0x0000000000000000
snd 155648 27 snd_seq,snd_seq_device,snd_ctl_led,snd_soc_hdac_hdmi,snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_sof,snd_soc_core,snd_compress,snd_hda_intel,snd_hda_codec,snd_hda_scodec_cs35l41,snd_hwdep,snd_hda_cs_dsp_ctls,snd_pcm,snd_timer, Live 0x0000000000000000
thunderbolt 512000 0 - Live 0x0000000000000000
intel_lpss_pci 24576 2 - Live 0x0000000000000000
mei 200704 5 mei_hdcp,mei_pxp,mei_me, Live 0x0000000000000000
i2c_i801 40960 0 - Live 0x0000000000000000
typec 114688 1 typec_ucsi, Live 0x0000000000000000
intel_lpss 16384 1 intel_lpss_pci, Live 0x0000000000000000
processor_thermal_rapl 16384 1 processor_thermal_device, Live 0x0000000000000000
intel_ishtp 77824 2 intel_ishtp_hid,intel_ish_ipc, Live 0x0000000000000000
ecdh_generic 16384 2 bluetooth, Live 0x0000000000000000
mtd 110592 3 spi_nor, Live 0x0000000000000000
rfkill 40960 11 asus_wmi,iwlmvm,bluetooth,cfg80211, Live 0x0000000000000000
i2c_smbus 20480 1 i2c_i801, Live 0x0000000000000000
i2c_hid_acpi 12288 0 - Live 0x0000000000000000
intel_rapl_common 40960 2 intel_rapl_msr,processor_thermal_rapl, Live 0x0000000000000000
intel_vsec 20480 0 - Live 0x0000000000000000
roles 16384 1 typec_ucsi, Live 0x0000000000000000
idma64 20480 0 - Live 0x0000000000000000
soundcore 16384 2 snd_ctl_led,snd, Live 0x0000000000000000
i2c_hid 40960 1 i2c_hid_acpi, Live 0x0000000000000000
serial_multi_instantiate 16384 0 - Live 0x0000000000000000
int3403_thermal 16384 0 - Live 0x0000000000000000
int3400_thermal 20480 0 - Live 0x0000000000000000
acpi_pad 24576 0 - Live 0x0000000000000000
int340x_thermal_zone 16384 2 processor_thermal_device,int3403_thermal, Live 0x0000000000000000
acpi_tad 20480 0 - Live 0x0000000000000000
acpi_thermal_rel 20480 1 int3400_thermal, Live 0x0000000000000000
mac_hid 12288 0 - Live 0x0000000000000000
fuse 208896 3 - Live 0x0000000000000000
dm_mod 225280 0 - Live 0x0000000000000000
crypto_user 20480 0 - Live 0x0000000000000000
loop 40960 0 - Live 0x0000000000000000
ip_tables 36864 0 - Live 0x0000000000000000
x_tables 69632 1 ip_tables, Live 0x0000000000000000
ext4 1175552 2 - Live 0x0000000000000000
crc32c_generic 12288 0 - Live 0x0000000000000000
crc16 12288 2 bluetooth,ext4, Live 0x0000000000000000
mbcache 16384 1 ext4, Live 0x0000000000000000
jbd2 221184 1 ext4, Live 0x0000000000000000
i915 4136960 79 - Live 0x0000000000000000
nvme 65536 6 - Live 0x0000000000000000
nvme_core 245760 7 nvme, Live 0x0000000000000000
nvme_common 24576 1 nvme_core, Live 0x0000000000000000
i2c_algo_bit 20480 1 i915, Live 0x0000000000000000
drm_buddy 20480 1 i915, Live 0x0000000000000000
ttm 110592 1 i915, Live 0x0000000000000000
intel_gtt 28672 1 i915, Live 0x0000000000000000
drm_display_helper 229376 1 i915, Live 0x0000000000000000
serio_raw 16384 0 - Live 0x0000000000000000
atkbd 40960 0 - Live 0x0000000000000000
libps2 20480 1 atkbd, Live 0x0000000000000000
vivaldi_fmap 12288 1 atkbd, Live 0x0000000000000000
cec 86016 2 i915,drm_display_helper, Live 0x0000000000000000
crc32c_intel 16384 4 - Live 0x0000000000000000
video 77824 2 asus_wmi,i915, Live 0x0000000000000000
xhci_pci 28672 0 - Live 0x0000000000000000
spi_intel_pci 12288 0 - Live 0x0000000000000000
vmd 28672 0 - Live 0x0000000000000000
spi_intel 36864 1 spi_intel_pci, Live 0x0000000000000000
xhci_pci_renesas 24576 1 xhci_pci, Live 0x0000000000000000
i8042 53248 1 asus_nb_wmi, Live 0x0000000000000000
wmi 45056 3 asus_wmi,wmi_bmof,video, Live 0x0000000000000000
serio 28672 4 serio_raw,atkbd,i8042, Live 0x0000000000000000
[-- Attachment #7: proc-version.log --]
[-- Type: text/x-log, Size: 178 bytes --]
Linux version 6.6.0-rc36.6-rc3-fix-sound-dirty (donjajo@jajo-work2) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #6 SMP PREEMPT_DYNAMIC Sat Sep 30 20:13:01 GMT 2023
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-01 9:28 ` Hans de Goede
@ 2023-10-01 8:46 ` James John
2023-10-01 13:45 ` Hans de Goede
0 siblings, 1 reply; 23+ messages in thread
From: James John @ 2023-10-01 8:46 UTC (permalink / raw)
To: Hans de Goede, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-01 8:11 PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA James John
@ 2023-10-01 9:28 ` Hans de Goede
2023-10-01 8:46 ` James John
0 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-10-01 9:28 UTC (permalink / raw)
To: James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-01 8:46 ` James John
@ 2023-10-01 13:45 ` Hans de Goede
2023-10-01 14:16 ` James John
0 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-10-01 13:45 UTC (permalink / raw)
To: James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5384 bytes --]
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: 0001-platform-x86-asus-wmi-event-code-debug-patch.patch --]
[-- Type: text/x-patch, Size: 943 bytes --]
From d392204b9d909e45fc74be47ccfae7132ec298f0 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Sun, 1 Oct 2023 15:27:17 +0200
Subject: [PATCH] platform/x86: asus-wmi: event code debug patch
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/asus-wmi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 928fc74e79b4..e1727b80a898 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3937,9 +3937,10 @@ static int asus_wmi_get_event_code(u32 value)
obj = (union acpi_object *)response.pointer;
- if (obj && obj->type == ACPI_TYPE_INTEGER)
+ if (obj && obj->type == ACPI_TYPE_INTEGER) {
+ pr_info("raw event code 0x%llx\n", obj->integer.value);
code = (int)(obj->integer.value & WMI_EVENT_MASK);
- else
+ } else
code = -EIO;
kfree(obj);
--
2.41.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-01 13:45 ` Hans de Goede
@ 2023-10-01 14:16 ` James John
2023-10-01 14:18 ` James John
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: James John @ 2023-10-01 14:16 UTC (permalink / raw)
To: Hans de Goede, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6186 bytes --]
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
>>>
[-- Attachment #2: inputs.log --]
[-- Type: text/x-log, Size: 1879 bytes --]
CAPSLOCK BUTTON
[17163.666633] asus_wmi: raw event code 0x2c
[17163.666686] asus_wmi: raw event code 0xffffffffffffffff
[17171.479573] asus_wmi: raw event code 0x2c
[17171.479612] asus_wmi: raw event code 0xffffffffffffffff
PRNTSCRN BUTTON
[17515.104897] asus_wmi: raw event code 0x2b
[17515.104949] asus_wmi: raw event code 0xffffffffffffffff
[17520.733299] asus_wmi: raw event code 0x2b
[17520.733331] asus_wmi: raw event code 0xffffffffffffffff
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
SCREEN CAPTURE BUTTON
^X@ss[20299.678524] asus_wmi: raw event code 0x2a
[20299.678547] asus_wmi: raw event code 0xffffffffffffffff
^X@ss[20304.275840] asus_wmi: raw event code 0x2a
[20304.275913] asus_wmi: raw event code 0xffffffffffffffff
MyASUS BUTTON
[20362.322778] asus_wmi: raw event code 0xffffffffffffffff
[20362.622624] asus_wmi: raw event code 0x86
[20362.622728] asus_wmi: raw event code 0xffffffffffffffff
[20363.249205] asus_wmi: raw event code 0x86
[20363.249283] asus_wmi: raw event code 0xffffffffffffffff
MUTE BUTTON
[20942.489134] asus_wmi: raw event code 0x7c
[20942.489239] asus_wmi: raw event code 0xffffffffffffffff
[20943.222495] asus_wmi: raw event code 0x7c
[20943.222592] asus_wmi: raw event code 0xffffffffffffffff
DISABLE CAMERA BUTTON
[21002.582379] asus_wmi: raw event code 0x85
[21002.582475] asus_wmi: raw event code 0xffffffffffffffff
[21003.045881] asus_wmi: raw event code 0x85
[21003.046008] asus_wmi: raw event code 0xffffffffffffffff
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
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-17 8:50 ` Hans de Goede
2 siblings, 1 reply; 23+ messages in thread
From: James John @ 2023-10-01 14:18 UTC (permalink / raw)
To: Hans de Goede, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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
>>>>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-01 14:18 ` James John
@ 2023-10-01 15:09 ` James John
0 siblings, 0 replies; 23+ messages in thread
From: James John @ 2023-10-01 15:09 UTC (permalink / raw)
To: Hans de Goede, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
> 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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-01 14:16 ` James John
2023-10-01 14:18 ` James John
@ 2023-10-11 10:44 ` Hans de Goede
2023-10-11 15:43 ` Hans de Goede
2023-10-17 8:50 ` Hans de Goede
2 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-10-11 10:44 UTC (permalink / raw)
To: James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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
>>>>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-11 10:44 ` Hans de Goede
@ 2023-10-11 15:43 ` Hans de Goede
2023-11-24 15:54 ` Juri Vitali
0 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-10-11 15:43 UTC (permalink / raw)
To: James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 8948 bytes --]
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
>>>>>
>
[-- Attachment #2: 0001-platform-x86-asus-wmi-Change-ASUS_WMI_BRN_DOWN-code-.patch --]
[-- Type: text/x-patch, Size: 2554 bytes --]
From a30c93d8d6e50db9810579895e2308fad6cf114b Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 11 Oct 2023 16:54:24 +0200
Subject: [PATCH 1/2] platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code
from 0x20 to 0x2e
Older Asus laptops change the backlight level themselves and then send
WMI events with different codes for different backlight levels.
The asus-wmi.c code maps the entire range of codes reported on
brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
define NOTIFY_BRNUP_MIN 0x11
define NOTIFY_BRNUP_MAX 0x1f
define NOTIFY_BRNDOWN_MIN 0x20
define NOTIFY_BRNDOWN_MAX 0x2e
if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
code = ASUS_WMI_BRN_UP;
else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
code = ASUS_WMI_BRN_DOWN;
Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX
aka 0x20 - 0x2e events were mapped to 0x20.
This mapping is causing issues on new laptop models which actually
send 0x2b events for printscreen presses and 0x2c events for
capslock presses, which get translated into spurious brightness-down
presses.
The plan is disable the 0x11-0x2e special mapping on laptops
where asus-wmi does not register a backlight-device to avoid
the spurious brightness-down keypresses. New laptops always send
0x2e for brightness-down presses, change the special internal
ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in
preparation for fixing the spurious brightness-down presses.
This change does not have any functional impact since all
of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only
then checked against the keymap code and the new 0x2e
value is still in the 0x20 - 0x2e range.
Link: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Link: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Cc: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/asus-wmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 5fbdd0eafa02..adb67c925724 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -18,7 +18,7 @@
#include <linux/i8042.h>
#define ASUS_WMI_KEY_IGNORE (-1)
-#define ASUS_WMI_BRN_DOWN 0x20
+#define ASUS_WMI_BRN_DOWN 0x2e
#define ASUS_WMI_BRN_UP 0x2f
struct module;
--
2.41.0
[-- Attachment #3: 0002-platform-x86-asus-wmi-Only-map-brightness-codes-when.patch --]
[-- Type: text/x-patch, Size: 3585 bytes --]
From 06da58541c1a6d71703ef7f80827b80bfb77fe66 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 11 Oct 2023 17:24:38 +0200
Subject: [PATCH 2/2] platform/x86: asus-wmi: Only map brightness codes when
using asus-wmi backlight control
Older Asus laptops change the backlight level themselves and then send
WMI events with different codes for different backlight levels.
The asus-wmi.c code maps the entire range of codes reported on
brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
define NOTIFY_BRNUP_MIN 0x11
define NOTIFY_BRNUP_MAX 0x1f
define NOTIFY_BRNDOWN_MIN 0x20
define NOTIFY_BRNDOWN_MAX 0x2e
if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
code = ASUS_WMI_BRN_UP;
else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
code = ASUS_WMI_BRN_DOWN;
This mapping is causing issues on new laptop models which actually
send 0x2b events for printscreen presses and 0x2c events for
capslock presses, which get translated into spurious brightness-down
presses.
This mapping is really only necessary when asus-wmi has registered
a backlight-device for backlight control. In this case the mapping
was used to decide to filter out the keypresss since in this case
the firmware has already modified the brightness itself and instead
of reporting a keypress asus-wmi will just report the new brightness
value to userspace.
OTOH when the firmware does not adjust the brightness itself then
it seems to always report 0x2e for brightness-down presses and
0x2f for brightness up presses independent of the actual brightness
level. So in this case the mapping of the code is not necessary
and this translation actually leads to spurious brightness-down
presses being send to userspace when pressing printscreen or capslock.
Modify asus_wmi_handle_event_code() to only do the mapping
when using asus-wmi backlight control to fix the spurious
brightness-down presses.
Link: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Link: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Cc: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/asus-wmi.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 928fc74e79b4..6a79f16233ab 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3950,7 +3950,6 @@ static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
{
unsigned int key_value = 1;
bool autorelease = 1;
- int orig_code = code;
if (asus->driver->key_filter) {
asus->driver->key_filter(asus->driver, &code, &key_value,
@@ -3959,16 +3958,10 @@ static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
return;
}
- if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
- code = ASUS_WMI_BRN_UP;
- else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
- code = ASUS_WMI_BRN_DOWN;
-
- if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) {
- if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
- asus_wmi_backlight_notify(asus, orig_code);
- return;
- }
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor &&
+ code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNDOWN_MAX) {
+ asus_wmi_backlight_notify(asus, code);
+ return;
}
if (code == NOTIFY_KBD_BRTUP) {
--
2.41.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-01 14:16 ` James John
2023-10-01 14:18 ` James John
2023-10-11 10:44 ` Hans de Goede
@ 2023-10-17 8:50 ` Hans de Goede
2023-10-18 0:17 ` me
2 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-10-17 8:50 UTC (permalink / raw)
To: James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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
>>>>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-17 8:50 ` Hans de Goede
@ 2023-10-18 0:17 ` me
2023-10-18 19:35 ` Hans de Goede
0 siblings, 1 reply; 23+ messages in thread
From: me @ 2023-10-18 0:17 UTC (permalink / raw)
To: Hans de Goede
Cc: Corentin Chary, Ilpo Järvinen, Mark Gross,
platform-driver-x86, acpi4asus-user, linux-kernel
[-- 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 ------------
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-18 0:17 ` me
@ 2023-10-18 19:35 ` Hans de Goede
2023-10-19 23:22 ` James John
0 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-10-18 19:35 UTC (permalink / raw)
To: me
Cc: Corentin Chary, Ilpo Järvinen, Mark Gross,
platform-driver-x86, acpi4asus-user, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]
Hi James,
On 10/18/23 02:17, me@donjajo.com 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
[-- Attachment #2: 0001-platform-x86-asus-wmi-Map-0x2a-code-Ignore-0x2b-and-.patch --]
[-- Type: text/x-patch, Size: 1785 bytes --]
From a2533bd573eb7a762306e83d99f624cbabad7d19 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Tue, 17 Oct 2023 10:35:14 +0200
Subject: [PATCH 1/2] platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and
0x2c events
Newer Asus laptops send the following new WMI event codes when some
of the F1 - F12 "media" hotkeys are pressed:
0x2a Screen Capture
0x2b PrintScreen
0x2c CapsLock
Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys
are mapped on other laptops.
PrintScreem and CapsLock are also reported as normal PS/2 keyboard events,
map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log
messages.
Reported-by: James John <me@donjajo.com>
Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/asus-nb-wmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index d85d895fee89..df1db54d4e18 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -531,6 +531,9 @@ static void asus_nb_wmi_quirks(struct asus_wmi_driver *driver)
static const struct key_entry asus_nb_wmi_keymap[] = {
{ KE_KEY, ASUS_WMI_BRN_DOWN, { KEY_BRIGHTNESSDOWN } },
{ KE_KEY, ASUS_WMI_BRN_UP, { KEY_BRIGHTNESSUP } },
+ { KE_KEY, 0x2a, { KEY_SELECTIVE_SCREENSHOT } },
+ { KE_IGNORE, 0x2b, }, /* PrintScreen (also send via PS/2) on newer models */
+ { KE_IGNORE, 0x2c, }, /* CapsLock (also send via PS/2) on newer models */
{ KE_KEY, 0x30, { KEY_VOLUMEUP } },
{ KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
{ KE_KEY, 0x32, { KEY_MUTE } },
--
2.41.0
[-- Attachment #3: 0002-platform-x86-asus-wmi-Do-not-report-brightness-up-do.patch --]
[-- Type: text/x-patch, Size: 2620 bytes --]
From ec01cacaf68fc00c1d5fffd2ce8e0bd03d2753bd Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 18 Oct 2023 11:47:28 +0200
Subject: [PATCH 2/2] platform/x86: asus-wmi: Do not report brightness up/down
keys when also reported by acpi_video
For a long time now the acpi_video driver reports evdev brightness up/down
key events for the brightness hotkeys on most (non ancient) laptops.
asus-wmi also reports evdev brightness up/down key events for these
keys leading to each press being reported twice and e.g. GNOME increasing
the brightness by 2 steps instead of 1 step.
Use the acpi_video_handles_brightness_key_presses() helper to detect if
acpi_video is reporting brightness key-presses and if it is then don't
report the same events also from the asus-wmi driver.
Note there is a chance that this may lead to regressions where
the brightness hotkeys stop working because they are not actually
reported by the acpi_video driver. Unfortunately the only way to
find out if this is a problem is to try.
To at least avoid regressions on old hw using the eeepc-wmi driver,
implement this as a key filter in asus-nb-wmi so that the eeepc-wmi
driver is not affected.
Reported-by: James John <me@donjajo.com>
Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/asus-nb-wmi.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index df1db54d4e18..9aa1226e74e6 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -16,6 +16,8 @@
#include <linux/dmi.h>
#include <linux/i8042.h>
+#include <acpi/video.h>
+
#include "asus-wmi.h"
#define ASUS_NB_WMI_FILE "asus-nb-wmi"
@@ -606,6 +608,19 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
{ KE_END, 0},
};
+static void asus_nb_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code,
+ unsigned int *value, bool *autorelease)
+{
+ switch (*code) {
+ case ASUS_WMI_BRN_DOWN:
+ case ASUS_WMI_BRN_UP:
+ if (acpi_video_handles_brightness_key_presses())
+ *code = ASUS_WMI_KEY_IGNORE;
+
+ break;
+ }
+}
+
static struct asus_wmi_driver asus_nb_wmi_driver = {
.name = ASUS_NB_WMI_FILE,
.owner = THIS_MODULE,
@@ -614,6 +629,7 @@ static struct asus_wmi_driver asus_nb_wmi_driver = {
.input_name = "Asus WMI hotkeys",
.input_phys = ASUS_NB_WMI_FILE "/input0",
.detect_quirks = asus_nb_wmi_quirks,
+ .key_filter = asus_nb_wmi_key_filter,
};
--
2.41.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-18 19:35 ` Hans de Goede
@ 2023-10-19 23:22 ` James John
2023-10-21 9:46 ` Hans de Goede
0 siblings, 1 reply; 23+ messages in thread
From: James John @ 2023-10-19 23:22 UTC (permalink / raw)
To: Hans de Goede
Cc: Corentin Chary, Ilpo Järvinen, Mark Gross,
platform-driver-x86, acpi4asus-user, linux-kernel
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, me@donjajo.com 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-19 23:22 ` James John
@ 2023-10-21 9:46 ` Hans de Goede
2023-10-21 9:53 ` James John
0 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-10-21 9:46 UTC (permalink / raw)
To: James John
Cc: Corentin Chary, Ilpo Järvinen, Mark Gross,
platform-driver-x86, acpi4asus-user, linux-kernel
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, me@donjajo.com 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
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-21 9:46 ` Hans de Goede
@ 2023-10-21 9:53 ` James John
0 siblings, 0 replies; 23+ messages in thread
From: James John @ 2023-10-21 9:53 UTC (permalink / raw)
To: Hans de Goede
Cc: Corentin Chary, Ilpo Järvinen, Mark Gross,
platform-driver-x86, acpi4asus-user, linux-kernel
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, me@donjajo.com 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-10-11 15:43 ` Hans de Goede
@ 2023-11-24 15:54 ` Juri Vitali
2023-11-25 14:25 ` Hans de Goede
0 siblings, 1 reply; 23+ messages in thread
From: Juri Vitali @ 2023-11-24 15:54 UTC (permalink / raw)
To: James John, Corentin Chary, Ilpo Järvinen, Mark Gross,
Hans de Goede
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
Hi,
Unfortunately those patches have broken the backlight reporting on older
laptops, which do rely on the old mechanism.
For instance, on my Asus UX32A/VD when pressing the backlight up/down button
the backlight changes accordingly, 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.
By the way, I only found those codes to be reported by asus-wmi, while other
inputs remain silent while pressing those keys.
Let me know if I can help with some logs or anything.
Regards,
Juri
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-11-24 15:54 ` Juri Vitali
@ 2023-11-25 14:25 ` Hans de Goede
2023-12-03 15:44 ` Hans de Goede
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Hans de Goede @ 2023-11-25 14:25 UTC (permalink / raw)
To: Juri Vitali, James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
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
2 siblings, 0 replies; 23+ messages in thread
From: Hans de Goede @ 2023-12-03 15:44 UTC (permalink / raw)
To: Juri Vitali, James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
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
2 siblings, 0 replies; 23+ messages in thread
From: juri @ 2023-12-04 0:32 UTC (permalink / raw)
To: Hans de Goede, James John, Corentin Chary, Ilpo Järvinen,
Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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.
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).
November 25, 2023 at 15:25, "Hans de Goede" <hdegoede@redhat.com> 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 ?
>
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.
>
> 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
>
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
>
> 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
>
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.
>
> 7. Can you run:
>
> sudo acpidump -o acpidump.txt
>
> And then email me the generated acpidump.txt file
> in a private email ?
>
I'll send you a mail with the output on both Debian and Arch, in case there should be any significant differences.
>
> 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
>
Thank you again, and let me know if there is anything missing!
Juri
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
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
2 siblings, 1 reply; 23+ messages in thread
From: juri @ 2023-12-04 0:32 UTC (permalink / raw)
To: Hans de Goede, James John, Corentin Chary, Ilpo Järvinen,
Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
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.
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).
November 25, 2023 at 15:25, "Hans de Goede" <hdegoede@redhat.com> 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 ?
>
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.
>
> 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
>
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
>
> 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
>
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.
>
> 7. Can you run:
>
> sudo acpidump -o acpidump.txt
>
> And then email me the generated acpidump.txt file
> in a private email ?
>
I'll send you a mail with the output on both Debian and Arch, in case there should be any significant differences.
>
> 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
>
Thank you again, and let me know if there is anything missing!
Juri
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-12-04 0:32 ` juri
@ 2023-12-04 13:06 ` juri
2023-12-04 13:54 ` Hans de Goede
0 siblings, 1 reply; 23+ messages in thread
From: juri @ 2023-12-04 13:06 UTC (permalink / raw)
To: Hans de Goede, James John, Corentin Chary, Ilpo Järvinen,
Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
December 4, 2023 at 01:32, juri@dividebyzero.it 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.
Regards,
Juri
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-12-04 13:06 ` juri
@ 2023-12-04 13:54 ` Hans de Goede
2023-12-04 15:52 ` juri
0 siblings, 1 reply; 23+ messages in thread
From: Hans de Goede @ 2023-12-04 13:54 UTC (permalink / raw)
To: juri, James John, Corentin Chary, Ilpo Järvinen, Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
Hi,
On 12/4/23 14:06, juri@dividebyzero.it wrote:
> December 4, 2023 at 01:32, juri@dividebyzero.it 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA
2023-12-04 13:54 ` Hans de Goede
@ 2023-12-04 15:52 ` juri
0 siblings, 0 replies; 23+ messages in thread
From: juri @ 2023-12-04 15:52 UTC (permalink / raw)
To: Hans de Goede, James John, Corentin Chary, Ilpo Järvinen,
Mark Gross
Cc: platform-driver-x86, acpi4asus-user, linux-kernel
Thank you for the reply.
December 4, 2023 at 14:54, "Hans de Goede" <hdegoede@redhat.com> wrote:
>
> 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
>
Honestly I don't remember the exact reason, but I had it since the beginning, possibly due to not working hotkeys.
I removed it now, and everything seems to be working without any issue, other that now the brightness is no longer being controlled by the EC and cannot be adjusted outside of a graphical interface.
I'm going to keep it like this, I'll let you know if any issue should arise.
As for the other cmdline arguments (which I had quite too many) I realized that the only non-standard one I really need is `nouveau.modeset=0`, without which the driver - and sometimes the whole system - hangs (as this laptop has an old NVidia GPU I don't use but keep always disabled).
Do you suggest opening another thread regarding that on this mailing list, or should it be better somewhere else?
Regards,
Juri
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2023-12-04 15:52 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-01 8:11 PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).