Re: [PATCH v3 7/7] HID: asus: Re-send the Zenbook Duo keyboard handshake after probe

[Denis Benato <denis.benato@linux.dev>]

On 10/20/26 09:42, Rebecca Mara Müller wrote:
> On Mon, Oct 19, 2026 at 10:38:11PM +0200, Denis Benato wrote:
>> Does this laptop have other lights? I wonder what that is changing...
> Three, none of them obviously software controlled:
>
> - the LED in the power button: white while running, orange while off
>   and charging;
> - an LED on the left side of the keyboard, white while the machine is
>   running, off otherwise;
> - a small LED in the F11 (Bluetooth) key that lights up white for a few
>   seconds when the keyboard is lifted off.
>
> I saw no LED change during the tests below. The firmware's own LED
> table agrees: GALE() checks a LEDS variable that is hard-coded to 0.
>
> I also tried the IDs directly through asus-nb-wmi debugfs:
>
> - 0x00050021: DSTS returns 0xFFFFFFFE, but DEVS still calls SLKB and
>   writes the EC. Writing 0x83, 0x00, 0x81 and 0x82 made no visible
>   difference anywhere on the machine.
> - 0x00050031/0x00050032 (ScreenPad): DSTS reports them as present, so
>   asus-wmi registers an asus_screenpad backlight. Writing bl_power and
>   brightness changes nothing on either panel. Harmless, but the
>   device should not be there on this model.
>
> That fits your point about code reuse. Two more fingerprints: 0x00060024
> returns a package containing 0x9D2F8086, the PCI ID of the Skylake-era
> Sunrise Point-LP xHCI controller, and 0x00050035 has unreachable code
> after a Return that writes the same EC registers as the ScreenPad IDs.
>
>> Doesn't look like something to be investigated further, perhaps try to see
>> if there is some unknown devid in wmi that does something cool.
> I read through the 45 IDs that WMNB answers but asus-wmi.h does not
> know. About half return constants. The one I find cool is 0x0006006C:
> it is set-only (no DSTS, so Linux treats it as absent) and takes
> 0..3, which it stores as 0/7/9/8 in the DTT variable ODV3 before
> notifying IETM. The DTT data vault (INT3400 data_vault, apct/apat)
> names what that means:
>
>   ODV3  targets (PL2/PL1 in W)
>   0     Whisper 35/30, Standard 55/42, Performance 64/55
>   7     Stand_Whisper, Stand_Standard, Stand_Performance (same)
>   8     Book2_Whisper 23/20, Book2_Standard 33/30
>   9     Book1_Whisper 23/20, Book1_Standard 33/30
>
> So it is a posture input. In the Book postures the firmware also
> refuses the performance profile in 0x00110019. thermald --adaptive
> applies these tables on Linux (intel-rapl-mmio currently reads 42/55 W,
> i.e. "Standard"), but nothing on Linux ever reports a posture, so the
> machine always runs the laptop table. I did not write the ID myself.
>
> Related: 0x0011001F writes ODV5, and ODV5 = 255 selects a "Check"
> target capped at 20 W, which looks like a factory or service mode.
>
> Two IDs I looked at and left alone: 0x00120061 reads EC 0x2C and would
> return 0x00010002 if it is set. I tried five chargers, down to a
> USB-A 5 V source where the battery was discharging at about 9 W, and it
> always returned 0x00010001. 0x00060059 is a generic pass-through for
> EC read/write commands 0xE0..0xEF.
>
> To report a posture you need the sensors, and those were dead too: the
> ISH rejects the generic intel/ish/ish_ptl.bin ("ISH loader: cmd 2
> failed 10"). ASUS's own SensorHub driver package (5.8.62.0) contains a
> signed image, AsusSign_ishS_SI_CommonPTL_5.8.1.7779_V0018.bin. Placed
> locally as intel/ish/ish_ptl_59b8d9f2_c68ec386.bin (vendor + product
> name CRCs) it loads, and accel_3d, als and hinge show up. s2idle
> hardware residency stays where it was: 27.6 s and 27.9 s out of 30 s
> with the ISH running, against 28.4 s without.
>
> HP, Dell and Lenovo ship their ISH images in linux-firmware, ASUS has
> none. Do you happen to know someone at ASUS who could submit theirs?
> That would give every Zenbook Duo working rotation, ambient light and
> the hinge angle, and with the hinge angle a small service could feed
> 0x0006006C as Windows does.


I certainly do. Next thing I'm gonna do is write to them. Note however
that unless they give me permission I won't be able to tell you the
outcome of my conversation. Hopefully one good day a certain file
appears in linux-firmware :)

>> in the OGC discord (ex asus-linux discord, you find it on our website) people
>> are planning a GUI redesign, perhaps if you have spare time you can add an option
>> to asusd to shutdown leds when entering sleep to have a GUI on a widely used tool
> Thank you for the pointer. I am not on Discord, and GUIs are not where
> I am useful. If the sleep option lands on the asusd side (daemon or
> CLI), I would be glad to test it on this machine.

Well asusctl has a daemon and a CLI too. I don't think it's much useful on zenbooks
due to missing TDP but it is a quick way to change supported firmware attributes
and bind epp policies to power profiles in case you are interested.

If for some reason the kernel can't feed sensor data to wmi properties asusd is
the right place for doing that (albeit I don't like when userspace does things that
the kernel should be doing on its own).

> Thanks,
> Rebecca