Re: [PATCH v6 2/5] platform/x86: bitland-mifs-wmi: Merge the function of redmi-wmi into the bitland driver

[Anton Karasev]

Hi,

On a Xiaomi Redmi Book Pro 16 2024 (DMI: XIAOMI / TM2309, BIOS
RMAMT6B0P0B0B) the display-switch key sends payload 0x00000101 -- the
short form. The merged keymap in this patch only carries the long one:

  { KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_RESERVED_1, 1, 0), { KEY_SWITCHVIDEOMODE } },

With WMI_EVENT_RESERVED_1 = 1 and WMI_EVENT_TYPE_HOTKEY = 1 that expands
to 0x00010101, so on this model the key produces no input event at all:
sparse_keymap_entry_from_scancode() finds nothing and the event is
dropped.

redmi-wmi has exactly the same gap; it is being fixed there by

  https://lore.kernel.org/platform-driver-x86/20260928221417.37875-1-ilya.gladyshev@xxxxxxxxx/

which I tested on this machine: with that patch the key reports
KEY_SWITCHVIDEOMODE and the desktop reacts to it. If this series lands as
is, that fix is lost again for this model. The equivalent here would be
one more line:

  { KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_RESERVED_1, 0, 0), { KEY_SWITCHVIDEOMODE } },

Note that the keymap already carries both forms for the settings key
(0x1b with low 0 and low 1), so the two forms are already known to the
driver; the display-switch key is simply missing its short variant.

While tracing this firmware, two more payloads showed up that neither
driver handles: 0x00000901 and 0x00010901. They are not key presses. The
EC echoes back the Caps Lock LED state that the host itself has just set
-- the third byte carries the new state (1 = on, 0 = off), the same
scheme as the Fn Lock events at 0x00000701 / 0x00010701. Verified by
switching between windows with per-window keyboard layouts, which changes
the LED without anyone touching the key: the events still arrive,
200-500 ms after the LED change. On a system where Caps Lock switches the
keyboard layout, each of them ends up in the "Unknown WMI hotkey"
dev_dbg path. If you agree they are just an echo, KE_IGNORE would
silence them:

  { KE_IGNORE, BI_HOTKEY_CODE(WMI_EVENT_CAPSLOCK_STATE, 0, 0), {} },
  { KE_IGNORE, BI_HOTKEY_CODE(WMI_EVENT_CAPSLOCK_STATE, 1, 0), {} },

Two more things about how this patch treats events from this firmware.
The observations below were made on 7.2.7, with redmi-wmi owning the
event GUID and a local build of bitland-mifs-wmi bound only to the
method GUID, reading the EC registers while doing it; what this patch
would do is from reading it. The ACPI references are to the SSDT with
OEM Table ID XMCC1806 (\_SB.PC00.WMID) and to the DSDT.

1. Fn+K. This firmware never sends WMI_EVENT_PERFORMANCE_PLAN (0x0f);
   QV20(1, 0x0f) is not called anywhere in its tables. A mode change is
   reported as event 0x16 with the new EC mode (register QFAN) in
   value_low: the Fn+K query handler in the DSDT (_Q24) calls
   QV20(1, 0x16) and then NTDP(QFAN), and the MIFS SET of
   WMI_FN_SYSTEM_PER_MODE in WMAA sends the same QV20(1, 0x16) after
   writing QFAN. EV20 fills value_low only for QFAN 1..4, so after a SET
   of 0 -- what the default Bitland map writes for balanced -- the event
   is 0x00001601.

   This patch maps 0x16 with value_low 1..4 to KE_IGNORE, has no entry
   for 0x00001601, and calls platform_profile_notify() only for 0x0f.
   So after Fn+K userspace is told nothing: the EC mode and the DPTF
   policy applied by thermald --adaptive change, and so does the value
   read back from platform_profile, but power-profiles-daemon keeps the
   old profile. That is already the case today; in my test PPD stayed
   on balanced while the EC ran in Turbo. But redmi-wmi at least reports
   KEY_PERFORMANCE for these events, as it reports KEY_KBDILLUMTOGGLE
   and KEY_FN_ESC for the backlight and Fn Lock events. With this patch
   they all become KE_IGNORE, so userspace gets neither a key nor a
   profile notification.

   Treating 0x16 as a profile change -- value_low 0..4, including
   0x00001601 -- and calling platform_profile_notify() for it would
   close the gap. It would also fire after the driver's own writes,
   because the SET sends the same event: when userspace writes the
   profile through bitland-mifs-wmi right after Fn+K, two 0x16 events
   arrive 0.2-1 s apart. That is harmless.

2. Keyboard backlight (F10). On this model the event's value_low
   cycles 0x00 -> 0x05 -> 0x0a -> 0x80 -> 0x00: off, dim with the BIOS
   idle timeout, bright with the idle timeout, bright and always on.
   The EC keeps the same state as 1 / 2 / 4 / 8, and EV20 translates
   it into value_low. In this patch
   BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0, 0x80) is 0x80000501,
   while the firmware (and redmi-wmi's 0x00800501) has 0x80 in
   value_low. All four KBD_BRIGHTNESS entries are unreachable anyway:
   notify() returns for WMI_EVENT_KBD_BRIGHTNESS before the keymap
   lookup, so the KEY_KBDILLUMTOGGLE that redmi-wmi reports today is
   gone. That early path passes value_low (0, 5, 10 or 128) to
   led_classdev_notify_brightness_hw_changed() for an LED with
   max_brightness 3, and on this BIOS the LED has nothing behind it,
   because WMAA does not implement WMI_FN_RGB_KB_BRIGHTNESS (0x12) and
   answers 0xE000.

The full acpidump of this machine is attached to the bug:
https://bugzilla.kernel.org/attachment.cgi?id=310971

Details, traces and the exact verification steps for the key events:
https://bugzilla.kernel.org/show_bug.cgi?id=222062

I am happy to test patches on this model.

Thanks,
Anton Karasev