Bug 209011 - asus-wmi always reports tablet mode on a ZenBook UX390UAK
Summary: asus-wmi always reports tablet mode on a ZenBook UX390UAK
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform_x86 (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Hans de Goede
Depends on:
Reported: 2020-08-23 13:54 UTC by hexchain
Modified: 2021-07-29 12:37 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.8.3
Regression: No
Bisected commit-id:

platform/x86: asus-wmi: Fix SW_TABLET_MODE always reporting 1 on the Asus UX360CA (4.24 KB, patch)
2020-09-10 17:46 UTC, Hans de Goede
Details | Diff
[PATCH] platform/x86: asus-wmi: Fix SW_TABLET_MODE always reporting 1 on many different models (5.40 KB, patch)
2020-09-16 15:53 UTC, Hans de Goede
Details | Diff
dmesg output - TP412UA (78.02 KB, text/plain)
2021-07-28 12:31 UTC, Julius Lehmann
acpidump - TP412UA (1.26 MB, text/plain)
2021-07-28 12:31 UTC, Julius Lehmann
dmesg output 2 - TP412UA (78.26 KB, text/plain)
2021-07-28 13:02 UTC, Julius Lehmann
[PATCH] platform/x86: Add and use a dual_accel_detect() helper (11.25 KB, patch)
2021-07-28 18:10 UTC, Hans de Goede
Details | Diff

Description hexchain 2020-08-23 13:54:40 UTC
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.
Comment 1 Hans de Goede 2020-09-10 17:46:12 UTC
Thank you for your bug-report, the same issue has also been reported on the mailinglist and is being discussed there:

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.
Comment 2 Hans de Goede 2020-09-10 17:46:57 UTC
Created attachment 292453 [details]
platform/x86: asus-wmi: Fix SW_TABLET_MODE always reporting 1 on the Asus UX360CA
Comment 3 hexchain 2020-09-16 12:56:17 UTC
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.
Comment 4 Hans de Goede 2020-09-16 13:03:22 UTC
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:


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 .
Comment 5 Hans de Goede 2020-09-16 15:53:08 UTC
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).
Comment 6 Julius Lehmann 2021-07-26 22:20:02 UTC
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.
Comment 7 Hans de Goede 2021-07-28 11:39:48 UTC
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.
Comment 8 Julius Lehmann 2021-07-28 12:31:00 UTC
Created attachment 298073 [details]
dmesg output - TP412UA
Comment 9 Julius Lehmann 2021-07-28 12:31:30 UTC
Created attachment 298075 [details]
acpidump - TP412UA
Comment 10 Julius Lehmann 2021-07-28 12:35:21 UTC
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
Comment 11 Hans de Goede 2021-07-28 12:43:59 UTC
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 ?
Comment 12 Julius Lehmann 2021-07-28 13:02:31 UTC
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_vendor:American Megatrends Inc.
/sys/class/dmi/id/board_vendor:ASUSTeK COMPUTER INC.
/sys/class/dmi/id/chassis_asset_tag: No  Asset  Tag 
/sys/class/dmi/id/chassis_vendor:ASUSTeK COMPUTER INC.
/sys/class/dmi/id/product_family:VivoBook Flip
/sys/class/dmi/id/product_name:VivoBook Flip 14_ASUS Flip TP412UA
/sys/class/dmi/id/sys_vendor:ASUSTeK COMPUTER INC.
Comment 13 Hans de Goede 2021-07-28 13:20:34 UTC
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.
Comment 14 Hans de Goede 2021-07-28 18:10:55 UTC
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.
Comment 15 Julius Lehmann 2021-07-28 20:25:36 UTC
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!
Comment 16 Hans de Goede 2021-07-28 20:38:00 UTC
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) ?
Comment 17 Julius Lehmann 2021-07-28 20:39:13 UTC
Comment 18 Hans de Goede 2021-07-28 20:40:35 UTC

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.
Comment 19 Hans de Goede 2021-07-29 12:37:45 UTC
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:


So lets close this.

Note You need to log in before you can comment on or make changes to this bug.