[PATCH 0/2] platform/x86: asus-wmi: make the tablet switch work on the ProArt PX13

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------d14ad7a7338fa1315514c5d7cb901469e2c4f802e727c51bf072394e47cf949a
Content-Type: multipart/mixed;
 boundary=42ff71c49c2c7741efb6d6c75c100335502352523641475b02a3c07cafde
From: Robin Everaars <[email protected]>
To: [email protected],
	[email protected]
Cc: [email protected],
	[email protected],
	[email protected],
	[email protected],
	[email protected]
Subject: [PATCH 0/2] platform/x86: asus-wmi: make the tablet switch work on the ProArt PX13
Date: Wed,  5 Aug 2026 12:15:00 +0200
Message-ID: <[email protected]>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0

--42ff71c49c2c7741efb6d6c75c100335502352523641475b02a3c07cafde
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

SW_TABLET_MODE never moves on an ASUS ProArt PX13 (HN7306EAC), and no
tablet_mode_sw value fixes it, because two independent things are in the way.

The first is a devstate quirk. The lid-flip devstate on this machine sets
ASUS_WMI_DSTS_UNKNOWN_BIT alongside the state bit while folded, so
ASUS_WMI_DEVID_LID_FLIP_ROG answers 0x00010000 open and 0x00010003 folded.
asus_wmi_get_devstate_simple() reads that bit as "state not known" and fails
with -ENODEV, throwing away a valid state that is sitting in bit 0.

The second is the devid/notify pairing. asus-wmi ties the devid it polls to the
one notify code it listens for, and tablet_mode_sw only offers fixed pairings.
This chassis reads the hinge at LID_FLIP_ROG but notifies with NOTIFY_LID_FLIP,
a combination no value covers: tablet_mode_sw=2 pins the switch on and suspends
the internal keyboard for good, while tablet_mode_sw=3 polls the right devid but
never hears the event.

Patch 1 adds a tablet-specific read that gates on
 the presence bit only, used
from the two tablet-switch paths and leaving every other
asus_wmi_get_devstate_simple() caller alone. Patch 2 accepts either lid-flip
notify code once a lid-flip switch is registered; both are the same "lid flip
action" event and both already map to KEY_PROG2 in the sparse keymap.

Machines with a keyboard-dock switch notify with 0x75 and are unaffected, and
with no switch registered the event code is 0 so the old equality test is what
still runs.

Tested on the one machine I have, an ASUS ProArt PX13 HN7306EAC: six clean
SW_TABLET_MODE transitions over three fold cycles with no stray KEY_PROG2, and
libinput suspends the internal keyboard and touchpad on fold and restores them
on unfold. I do not have another convertible to check the untouched paths on
hardware, so review of the dock case would be welcome.

Robin Everaars (2):
  platform/x86: asus-wmi: keep the lid-flip state when UNKNOWN is set
  platform/x86: asus-wmi: accept either lid-
flip notify code

 drivers/platform/x86/asus-wmi.c | 55 +++++++++++++++++++++++++++++++--
 1 file changed, 52 insertions(+), 3 deletions(-)


base-commit: aca39607c1734ed976fdd65deb75b3555a5a0326
-- 
2.55.0


--42ff71c49c2c7741efb6d6c75c100335502352523641475b02a3c07cafde
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - [email protected] -
 0x8B6BA132.asc"; name="publickey - [email protected] - 0x8B6BA132.asc"
Content-Type: application/pgp-keys; filename="publickey -
 [email protected] - 0x8B6BA132.asc"; name="publickey -
 [email protected] - 0x8B6BA132.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCkNvbW1lbnQ6IGh0dHBzOi8vZ29w
ZW5wZ3Aub3JnClZlcnNpb246IEdvcGVuUEdQIDIuMTAuMAoKeGpNRWFoOGxaUllKS3dZQkJBSGFS
dzhCQVFkQWFSa3p2ZTQ5ckJFSk1LSkg3NDZSWEhZKzJmVDc3b3hST2k1ZAo4SnBMKzY3TktYSnZZ
bWx1WlhabGNtRmhjbk5BY0cwdWJXVWdQSEp2WW1sdVpYWmxjbUZoY25OQWNHMHViV1UrCndzQVJC
Qk1XQ2dDREJZSnFIeVZsQXdzSkJ3a1FIY1YvYThzR0dvcEZGQUFBQUFBQUhBQWdjMkZzZEVCdWIz
UmgKZEdsdmJuTXViM0JsYm5CbmNHcHpMbTl5Wng2VjVxUzg5dzdDRFlTSXNjNU54dVBKSTFyZ29F
eVkvdjhkYlAzSApxa29OQXhVS0NBUVdBQUlCQWhrQkFwc0RBaDRCRmlFRWkydWhNcmIyWHVqRm5G
akxIY1YvYThzR0dvb0FBQVpzCkFQOXpJS1d3dWJDbEZFczBKNmpwUUhUS1hGVHErOTlNUmtmREtx
SVRidW1RelFEL1IyT2F6VHA0b0NKTzJiT0QKTkZsaVZBbTh5WFA2QSs1ODZ6UjJZS3QwUkFiT09B
UnFIeVZsRWdvckJnRUVBWmRWQVFVQkFRZEEzcDVGN2I1TwpGc1dLclNXRW1FSGlhL29lN25vLyta
MVcwT1BmZllyRFB5OERBUWdId3I0RUdCWUtBSEFGZ21vZkpXVUpFQjNGCmYydkxCaHFLUlJRQUFB
QUFBQndBSUhOaGJIUkFibTkwWVhScGIyNXpMbTl3Wlc1d1ozQnFjeTV2Y21ldlVkUisKViszVWd2
SVZqcURMRk9XeXlHcDVoNEpYQVBmWVpzRC8vUkhndlFLYkRCWWhCSXRyb1RLMjlsN294WnhZeXgz
RgpmMnZMQmhxS0FBQm9GZ0VBOGU0ZVNMU2FMbXY4L2UyVzFMOS9WS0FiajJaN0pFUzZLQXBpOUJa
Nm5RZ0JBTmhaCkZoTUZ6c3l6dTJZWXRhQjhTWXRWdGhKSjYvZUlRVFQ2VWRRRUlZc0YKPVlLaE0K
LS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ==
--42ff71c49c2c7741efb6d6c75c100335502352523641475b02a3c07cafde--

--------d14ad7a7338fa1315514c5d7cb901469e2c4f802e727c51bf072394e47cf949a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wqsEARYIAF0FgmpzDSkJEB3Ff2vLBhqKNRQAAAAAABwAEHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmeNHj29M5dFxqRf0yjRRGSqFiEEi2uhMrb2XujF
nFjLHcV/a8sGGooAABkEAP4poX3ECepIrNMqPnnTfdyUn+WunjLv+zC6xFOT
QWUHCAEAtPlThBGmtDAlEcOY3J85rOXbXtE89zzYOUYDIpYCcg4=
=Uc2B
-----END PGP SIGNATURE-----


--------d14ad7a7338fa1315514c5d7cb901469e2c4f802e727c51bf072394e47cf949a--