Re: platform/x86: asus-wmi: SW_TABLET_MODE is always 1 on some devices

From: Hans de Goede
Date: Wed Sep 02 2020 - 07:52:47 EST


Hi,

On 9/1/20 11:55 PM, Samuel Čavoj wrote:
Hello!

A bug was introduced with the following commit[1]:

b0dbd97de: platform/x86: asus-wmi: Add support for SW_TABLET_MODE

The SW_TABLET_MODE switch seems to be always 1 on some devices,
including my UX360CA and a UX390UAK[2].

This can be seen in the output of evtest:

# evtest /dev/input/by-path/platform-asus-nb-wmi-event
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 5 (EV_SW)
Event code 1 (SW_TABLET_MODE) state 1

And directly results in libinput disabling the trackpad and keyboard via
its tablet-mode mechanism, rendering X.org and Wayland unusable (not even
switching to VT works without sysrq+r):

# libinput debug-events
(...)
-event8 DEVICE_ADDED Asus WMI hotkeys seat0 default group10 cap:kS
event8 SWITCH_TOGGLE +0.000s switch tablet-mode state 1
(...)

I have been using the following workaround to get my input working
again:

# cat /usr/share/libinput/50-system-asus.quirks
(...)
[Asus WMI hotkeys]
MatchName=*Asus WMI hotkeys*
ModelTabletModeSwitchUnreliable=1

Another option would be to rmmod asus_nb_wmi and blacklist it for now.

I am not sure what the solution would be as I am not acquainted with the
WMI module. However, I can provide some information about my hardware:

The UX360CA fully disables the keyboard in hardware(firmware?) when the
lid is flipped beyond 180 degrees (tablet mode). The trackpad is not
disabled. A KEY_PROG2 event is generated by the same "Asus WMI hotkeys"
input device at this moment, it however does not carry the actual state
-- a 1 is sent and a 0 follows immediately[3]. The same KEY_PROG2
sequence is generated when the lid is returned back to laptop position.
The SW_TABLET_MODE switch does not change state at all during this.
Thank you.

Thank you for your detailed bug report.

I have only tested the new TABLET_MODE support on Bay Trail and
Cherry Trail based devices. So one possible solution would be to
limit the support based on cpu-id.

But I would rather try to figure out a better way. Can you
create an acpidump, by as root running:

acpidump -o acpidump.asus-UX360CA

And then send me a direct (so without including the list)
email with the generated acpidump.asus-UX360CA file attached please?

Also, if necessary are you capable of building your own
kernel with a (test)patch applied ?

Regards,

Hans