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

On Thu, 9 Jul 2026 20:23:35 +0800, Mingyou Chen wrote:

Hi Mingyou,

I own a Redmi Book Pro 15 2023 (TM2209), one of the machines redmi-wmi
currently serves, and did a live test pass over the Redmibook side of
this series against WMI event traces from the actual firmware. A few
issues below, on top of what Nika already found. Happy to test v2 on
this hardware — just Cc me.

> +	{ KE_IGNORE, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0, 0), {} },
> +	{ KE_IGNORE, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0, 0x80), {} },
> +	{ KE_IGNORE, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 5, 0), {} },
> +	{ KE_IGNORE, BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0x0a, 0), {} },

The Auto entry has its value in the wrong byte. On the TM2209 the
backlight state arrives in value_low as 0x00 / 0x05 / 0x0a / 0x80;
a live trace of the backlight key cycling (payload bytes are
[type, id, value_low, value_high]):

  01 05 00 00   Off
  01 05 05 00   Low
  01 05 0a 00   High
  01 05 80 00   Auto

so the second entry needs to be
BI_HOTKEY_CODE(WMI_EVENT_KBD_BRIGHTNESS, 0x80, 0), otherwise the Auto
press falls through to the unknown-hotkey path.

> 	case WMI_EVENT_KBD_BRIGHTNESS:
> 		brightness = event->value_low;
> 		blocking_notifier_call_chain(&bitland_notifier_list,
> 					     BITLAND_NOTIFY_KBD_BRIGHTNESS,
> 					     &brightness);

Related: on the TM2209 these raw values (up to 0x80) end up in
led_classdev_notify_brightness_hw_changed() against a LED registered
with max_brightness = 3 — and the MIFS control methods behind that LED
do not work on this machine at all (the profile SET fails with
EOPNOTSUPP and the LED GET always returns 0; the SMM interface differs
from the gaming models). Both the LED and the platform profile probably
want to be gated on DMI (or on a probe-time functionality check) before
the event GUID starts feeding them.

> +		/* Redmi refresh rate toggle quirk */
> +		if (event->event_id == WMI_EVENT_CPU_FAN_SPEED &&
> +		    event->value_low == 0 && event->value_high == 0) {

Confirming the Redmibook side of Nika's concern: on the TM2209 Fn+S
really is event 0x1a with value_low always 0, so the quirk does work
here — but the event id spaces of the two device generations genuinely
collide (0x19 is the AI-button break event on Redmibooks vs
WMI_EVENT_REFRESH_RATE on yours; 0x1a is Fn+S here vs CPU fan speed on
yours). Rather than value-based quirks in the notify path, have you
considered selecting one of two keymaps at probe time by DMI? A single
merged table will keep growing special cases.

One more thing worth a comment somewhere in the merged driver: on the
TM2209 the ACPI event handler (EV20 in an OEM SSDT) cycles the EC
performance mode as a side effect of building the _WED payload for the
Fn+K event. Whatever driver owns the event GUID must keep reading
events, or Fn+K mode switching physically stops working.

Related: I have a pending redmi-wmi patch that reports these EC state
events (backlight / power mode / Fn lock) as input events so userspace
OSDs can react [1]. Whatever form the merged driver takes, please keep
these events observable rather than KE_IGNOREd.

[1] https://lore.kernel.org/r/[email protected]

Tested on Redmi Book Pro 15 2023 (TM2209, BIOS RMAPH5B0P0909).

--
Musaev Ibragim