Bug 209011

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.