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

[Anton Karasev]

Hi Mingyou,

To Ilpo's question on v7 about e0d6312578e1 ("platform/x86: redmi-wmi:
report EC state change events"): v9 restores its keymap entries, but of
the three kinds of events that commit reports (keyboard backlight,
performance mode and Fn Lock), only the performance mode one still
reaches userspace as a key. I tested v9 on a Redmi Book Pro 16 2024
(TM2309, BIOS RMAMT6B0P0B0B), built as a module for 7.2.8 with
redmi-wmi unloaded, with dyndbg on and the input device recorded; the
payloads below match what EV20 in its SSDT (OEM Table ID XMCC1806) puts
into the event buffer. Adding Ibragim Musaev, the author of
e0d6312578e1, to Cc, as Ilya did on v6.

> +	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_SWITCHVIDEOMODE, 1, 0), { KEY_SWITCHVIDEOMODE } },

The short form of the display-switch key, 0x00000101, is still
missing; on this machine the key only produces the debug message
"Unknown WMI hotkey with payload 0x00000101". Since 4/5 drops
redmi-wmi, Ilya's fix for it [1] would have to move here; he offered to
rebase it onto this driver if this series lands first [2].

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

These four entries are never reached, because of this hunk in
bitland_mifs_wmi_notify():

>  		blocking_notifier_call_chain(&bitland_notifier_list,
>  					     BITLAND_NOTIFY_KBD_BRIGHTNESS,
>  					     &brightness);
> -		break;
> +		return;

The backlight event returns before the keymap lookup at the end of the
function, so the input device advertises KEY_KBDILLUMTOGGLE but never
sends it: cycling F10 here gave 0x00800501, 0x00000501, 0x00050501 and
0x000a0501, and nothing reached the input device. If the key is meant
to be reported, as redmi-wmi does today, this has to stay a break;
otherwise the entries can go. Either way, the LED is still handed
0/5/10/128 for max_brightness 3, as noted in my v6 reply.

> +	/* OEM preset power mode */
> +	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_KEY_PERFORMANCE, 1, 0), { KEY_PERFORMANCE } },

On this firmware, event 0x16 is raised not only by Fn+K but by every
SET of WMI_FN_SYSTEM_PER_MODE other than 5 and 7, which WMAA writes to
SMMD instead: WMAA writes QFAN and calls QV20(1, 0x16), and EV20 then
reports the new mode. In a trace on 7.2 the echo arrives within a few
milliseconds of the write. So with v9 every profile write that reaches
the firmware also produces KEY_PERFORMANCE, whether it comes from
power-profiles-daemon, a direct write to platform_profile, or
bitland_mifs_wmi_resume() restoring the saved profile. With v9 here,
low-power, balanced-performance and performance each gave
KEY_PERFORMANCE; balanced (0) comes back as 0x00001601 and hits the
KE_IGNORE entry. (The writes return -ENOMSG without Chris's GET-only
patch, but the firmware applies them.) The same is true of redmi-wmi in
7.3-rc since e0d6312578e1, so this is not new in v9.

KEY_PERFORMANCE was added for a key that asks for a mode change
(89c521463929, "Input: add keycode for performance mode key": "so
userspace can act upon it"). If userspace handles it by toggling
performance or by stepping to the next profile, then with a map that
never writes 0, as proposed for the TM2307/TM2309, a single Fn+K press
on AC starts a loop that never stops: the EC changes mode,
KEY_PERFORMANCE, userspace writes a profile, the write raises 0x16,
KEY_PERFORMANCE again, and so on. With the default map of v9 the loop
ends when it writes balanced.

This is not just theoretical. On 7.2, with redmi-wmi owning the event
GUID and a local build of this driver owning the method GUID, a small
helper of mine that read 0x16 through a kprobe and set the
power-profiles-daemon profile from it started switching between
balanced and performance about three times a second after a resume,
because every write came back as an event and two opposite events were
queued. It went on for about 46 minutes, over 8000 switches, until it
died out by itself.

Since the event reports a change that has already happened,
platform_profile_notify() is the natural way to pass it on, as
suggested in my v6 reply: power-profiles-daemon then re-reads the
profile, which is harmless after the driver's own writes too. If
KEY_PERFORMANCE should stay for on-screen displays (Ibragim asked to
keep these events observable), it may be worth not reporting it for the
event that echoes the driver's own write, or at least saying in a
comment that it reports a mode change that already happened. On
Ibragim's TM2209 the profile SET is reported not to work [3], so there
0x16 can only come from Fn+K and the echo does not exist; Ibragim, can
you confirm?

> +	/* Fn Lock state */
> +	{ KEY_FN_ESC, BI_HOTKEY_CODE(WMI_EVENT_FNLOCK_STATE, 0, 0), {} },
> +	{ KEY_FN_ESC, BI_HOTKEY_CODE(WMI_EVENT_FNLOCK_STATE, 1, 0), {} },

KEY_FN_ESC ended up in the type field, and the keycode is 0.
sparse_keymap_entry_from_scancode() still finds these entries for
0x00000701 and 0x00010701, but sparse_keymap_report_entry() knows only
KE_KEY, KE_SW and KE_VSW, so it reports nothing, and
sparse_keymap_setup() does not advertise the key either. Here Fn+Esc
gives 0x00010701 and 0x00000701, and nothing reaches the input device,
without even the "Unknown WMI hotkey" message. redmi-wmi has
{KE_KEY, 0x00000701, {KEY_FN_ESC}}, so these should be

	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_FNLOCK_STATE, 0, 0), { KEY_FN_ESC } },
	{ KE_KEY, BI_HOTKEY_CODE(WMI_EVENT_FNLOCK_STATE, 1, 0), { KEY_FN_ESC } },

Unrelated to this series but for the same machines: I have sent a patch
that hides kb_mode where the firmware does not answer its GET [4]; v9
2/5 still applies on top of it with "git am -3".

[1] https://lore.kernel.org/all/20260928221417.37875-1-ilya.gladyshev@xxxxxxxxx/
[2] https://lore.kernel.org/all/759c1ed3a7733afdc3056de952edc4e776dc8b15@xxxxxxxxx/
[3] https://lore.kernel.org/all/178444076601.4076.16818759313258005640@xxxxxxxxx/
[4] https://lore.kernel.org/all/20261008-bitland-kb-mode-v1-uselessfire@xxxxxxxxx/

Thanks,
Anton Karasev