On an ASUS ZenBook UX390UAK, with Arch Linux kernel v5.8.3, touchpad and keyboard do not work in X or Wayland. libinput debug-events shows a tablet-mode event from event7 (Asus WMI hotkeys): % sudo libinput debug-events -event3 DEVICE_ADDED Power Button seat0 default group1 cap:k -event6 DEVICE_ADDED Asus Wireless Radio Control seat0 default group2 cap:k -event5 DEVICE_ADDED Video Bus seat0 default group3 cap:k -event0 DEVICE_ADDED Lid Switch seat0 default group4 cap:S -event2 DEVICE_ADDED Power Button seat0 default group5 cap:k -event1 DEVICE_ADDED Sleep Button seat0 default group6 cap:k -event16 DEVICE_ADDED USB2.0 VGA UVC WebCam: USB2.0 V seat0 default group7 cap:k -event14 DEVICE_ADDED ELAN1301:00 04F3:3035 Mouse seat0 default group8 cap:p left scroll-nat scroll-button -event15 DEVICE_ADDED ELAN1301:00 04F3:3035 Touchpad seat0 default group8 cap:pg size 103x57mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on -event7 DEVICE_ADDED Asus WMI hotkeys seat0 default group9 cap:kS event7 SWITCH_TOGGLE +0.000s switch tablet-mode state 1 -event4 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group10 cap:k The last time I run Linux on this machine was before v5.8, and this problem didn't occur at that time. Looking from the git log this seems particularly suspicious: * b0dbd97de1f1 - platform/x86: asus-wmi: Add support for SW_TABLET_MODE (3 months ago) <Hans de Goede> Please let me know what can I do to fix this problem.
Thank you for your bug-report, the same issue has also been reported on the mailinglist and is being discussed there: https://www.spinics.net/lists/platform-driver-x86/msg22655.html Based on that discussion I've prepared a patch which hopefully fixes this. It would be great if you can also test this patch on your model. I will attach the patch here.
Created attachment 292453 [details] platform/x86: asus-wmi: Fix SW_TABLET_MODE always reporting 1 on the Asus UX360CA
Thank you for the patch! Unfortunately I don't have that device at hand for the moment. I'll test as soon as I have the chance.
The patch is based on preferring a newer ASUS WMI device-id for the switch when present. It has been confirmed that this works on a ASUS ZenBook Flip UX360CA. But recently there have been more bug-reports about this and at least the Asus E200HA laptop does not have the newer ASUS WMI device-id in its DSDT: https://bugzilla.redhat.com/show_bug.cgi?id=1875339 https://bugzilla.redhat.com/show_bug.cgi?id=1875828 https://bugzilla.redhat.com/show_bug.cgi?id=1876997 So I'm preparing a new patch which uses a DMI based whitelist for the SW_TABLET_MODE functionality, Using the existing DMI quirks mechanism in asus-nb-wmi.c .
Created attachment 292519 [details] [PATCH] platform/x86: asus-wmi: Fix SW_TABLET_MODE always reporting 1 on many different models Here is the new patch. Note this uses a DMI sys_vendor and product_name allow-list based approach only registering the new SW_TABLET_MODE support on devices where it is known to work. So unless there is something really weird going on this is guaranteed to fix the issue on your laptop (unlike the previous version which has shown to not be enough on some Asus models).
Not entirely sure if this is the correct place to post this, but the issue described is still present on my device. Touchpad and keyboard are disabled in libinput. Using Archlinux 5.13.5-arch1 on Asus TP412UA. Output of libinput is pretty much the same as in the first comment. With linux-lts (5.10) there is no SWITCH_TOGGLE device and keyboard/touchpad are working without issues.
Julius, thank you for your bug report. 5.13.5 does contain the fix for the origin bug reported here. For a while now the kernel's asus-wmi code will only report SW_TABLET_MODE on devices on which it is explicitly enabled by a DMI match, on all other models the asus-wmi code will not report SW_TABLET_MODE at all. So I wonder if the SW_TABLET_MODE is perhaps being reported by another driver such as the intel-hid or intel-vbtn code. If you look at the libinput output in comment 0: -event7 DEVICE_ADDED Asus WMI hotkeys seat0 default group9 cap:kS event7 SWITCH_TOGGLE +0.000s switch tablet-mode state 1 Then the "event7" on the beginning of the line is the same for both devices. I suspect that if you look-up the DEVICE_ADDED line for the "event#" with which the SWITCH_TOGGLE which you are seeing is prefixed, then it will be another device then the "Asus WMI hotkeys" device. If the DEVICE_ADDED with the matching "event#" is the "Asus WMI hotkeys" device, then something weird is going on with the DMI matching, in that case please provide the output of: "cat /sys/class/dmi/id/sys_vendor /sys/class/dmi/id/product_name" If the DEVICE_ADDED with the matching "event#" is for another device, which I expect, please provide the following info: 1. Can you please add "wmi.debug_event=1 wmi.debug_dump_wdg=1" to your kernel commandline (see your distro's documentation) and then reboot and fold the device into tablet-mode and back to laptop-mode once. After this run "dmesg > dmesg.txt" and attach the generated dmesg.txt file here. 2. Run "sudo acpidump -o acpidump.txt" and attach the generated acpidump.txt file here. 3. Run "ls -l /sys/bus/iio/devices > ls-bus-iio.txt" and attach the generated ls-bus-iio.txt file here.
Created attachment 298073 [details] dmesg output - TP412UA
Created attachment 298075 [details] acpidump - TP412UA
Thank you so much for your reply, it was another device after all. Very important detail! I should add that in 5.10 the device wasn't even added, so this seems to be originating from something different. Anyway, the DEVICE_ADDED is for an "Intel Virtual Switch". Added the dmesg output and acpidump as attachments. % ls-bus-iio total 0 lrwxrwxrwx 1 root root 0 Jul 28 14:10 iio:device0 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-4/i2c-BOSC0200:00/iio:device0 lrwxrwxrwx 1 root root 0 Jul 28 14:10 iio:device1 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-4/i2c-BOSC0200:base/iio:device1
Thank you for the logs. I think I know what is going on here. 2 more questions: 1) Did you do "fold the device into tablet-mode and back to laptop-mode once" before collecting the dmesg.txt ? 2) Can you run "grep . /sys/class/dmi/id/* 2> /dev/null" and copy and paste the output here ?
Created attachment 298077 [details] dmesg output 2 - TP412UA 1) Yes, I did that. To be sure, I redid the 360 turn and posted another dmesg. 2) output of "grep . /sys/class/dmi/id/* 2> /dev/null" /sys/class/dmi/id/bios_date:07/25/2019 /sys/class/dmi/id/bios_release:5.12 /sys/class/dmi/id/bios_vendor:American Megatrends Inc. /sys/class/dmi/id/bios_version:TP412UA.308 /sys/class/dmi/id/board_asset_tag:ATN12345678901234567 /sys/class/dmi/id/board_name:TP412UA /sys/class/dmi/id/board_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/board_version:1.0 /sys/class/dmi/id/chassis_asset_tag: No Asset Tag /sys/class/dmi/id/chassis_type:31 /sys/class/dmi/id/chassis_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/chassis_version:1.0 /sys/class/dmi/id/ec_firmware_release:1.7 /sys/class/dmi/id/modalias:dmi:bvnAmericanMegatrendsInc.:bvrTP412UA.308:bd07/25/2019:br5.12:efr1.7:svnASUSTeKCOMPUTERINC.:pnVivoBookFlip14_ASUSFlipTP412UA:pvr1.0:sku:rvnASUSTeKCOMPUTERINC.:rnTP412UA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct31:cvr1.0: /sys/class/dmi/id/product_family:VivoBook Flip /sys/class/dmi/id/product_name:VivoBook Flip 14_ASUS Flip TP412UA /sys/class/dmi/id/product_version:1.0 /sys/class/dmi/id/sys_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnAmericanMegatrendsInc.:bvrTP412UA.308:bd07/25/2019:br5.12:efr1.7:svnASUSTeKCOMPUTERINC.:pnVivoBookFlip14_ASUSFlipTP412UA:pvr1.0:sku:rvnASUSTeKCOMPUTERINC.:rnTP412UA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct31:cvr1.0:
Thanks, I'm pretty sure I know what is going on here. I'm writing a kernel patch to fix this now. If you are curious what is going on here is a comment which I just wrote to document the code/fix I'm working on: /* * Helper code to detect 360 degree hinges (yoga) style 2-in-1 devices using 2 accelerometers * to allow the OS to determine the angle between the display and the base of the device. * * On Windows these are read by a special HingeAngleService process which calls undocumented * ACPI methods, to let the firmware know if the 2-in-1 is in tablet- or laptop-mode. * The firmware may use this to disable the kbd and touchpad to avoid spurious input in * tablet-mode as well as to report SW_TABLET_MODE info to the OS. * * Since Linux does not call these undocumented methods, the SW_TABLET_MODE info reported * by the intel-hid / intel-vbtn drivers is incorrect. These drivers use the detection * code in this file to disable SW_TABLET_MODE reporting to avoid reporting broken info * (instead userspace can derive the status itself by directly reading the 2 accels). */ Now I just need to actually write the mentioned detection code, test it on one of my own devices and then hook it up in the intel-vbtn.c and intel-hid drivers.
Created attachment 298093 [details] [PATCH] platform/x86: Add and use a dual_accel_detect() helper Ok, this patch should fix this for you (I've already tested the BOSC0200 dual-accel detection part on a similar device). Please build a 5.13 kernel with this patch added and see if that fixes things.
Tested the patch on mainline (5.14) instead of 5.13 because I can't read. The patch seems to work anyway, although libinput reports no tablet mode switch device and keyboard/touchpad won't be disabled when turning 360 degrees. This is the behavior from before 5.11. I am not even sure my device has such a sensor, unfortunately I don't have Windows installed to test it. Either way, great work and thanks for the patch!
Testing in mainline is fine too :) Thanks for testing. Is it ok if I add a reported-and-tested-by tag to the (public) commit msg like this: ? Reported-and-tested-by: Julius Lehmann <julius@devxx.yy> But then with your actual email (the one you use for bugzilla.kernel.org) ?
Absolutely!
Thanks. p.s. Things working as before 5.11 is expected here. The tablet-mode detection for devices with 2 accelerometers like your device will be done in userspace by iio-sensor-proxy: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/216 This is currently being worked on, I don't know when this will be ready though.
The patch fixing this has been added to the fixes branch of the platform-drivers-x86 git tree and will be included in the next pull-req to Linus: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=fixes So lets close this.