Messages in this thread | | | Subject | Re: platform/x86: asus-wmi: SW_TABLET_MODE is always 1 on some devices | From | Hans de Goede <> | Date | Wed, 2 Sep 2020 13:52:13 +0200 |
| |
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
| |