Re: [PATCH] platform/x86: redmi-wmi: report EC state change events

[Ilpo Järvinen]

On Wed, 15 Jul 2026, Musaev Ibragim wrote:

> The Redmibook EC/firmware fully handles the keyboard backlight cycle,
> the OEM preset power mode (Fn+K) and the Fn lock toggle by itself, and
> sends a WMI event carrying the resulting state in the third payload
> byte. These events are currently swallowed with KE_IGNORE, so userspace
> never learns that the state changed and cannot give the user any
> feedback (OSD), even though the WMI event is the only notification
> channel for these EC-driven changes.
> 
> Report them as key presses instead:
> 
>   - keyboard backlight cycle -> KEY_KBDILLUMTOGGLE
>   - OEM preset power mode    -> KEY_PERFORMANCE
>   - Fn lock toggle           -> KEY_FN_ESC
> 
> Desktops that only look at the keycode get the usual hotkey behaviour;
> since sparse-keymap emits MSC_SCAN with the raw payload before the key
> event, an OSD daemon can additionally recover the exact new state from
> byte 2 (e.g. backlight Off/Low/High/Auto is 0x00/0x05/0x0a/0x80).
> 
> Note that the power mode event must keep being read from the WMI device
> in any case: on the TM2209 the ACPI event handler (EV20) applies the
> mode change as a side effect of building the event payload for _WED.
> 
> Tested on Redmi Book Pro 15 2023 (TM2209).
> 
> Signed-off-by: Musaev Ibragim <atomicus.xyz@xxxxxxxxx>
> ---
> A related problem noticed while testing this: bitland-mifs-wmi lists the
> same event GUID (46C93E13-EE9B-4262-8488-563BCA757FEF, BITLAND_EVENT_GUID)
> in its wmi_device_id table, so on a Redmibook both drivers race for the
> event device at boot and whichever probes first wins. When bitland-mifs-wmi
> wins, the "Redmibook WMI keys" input device never appears, and since the
> MIFS control methods don't work on this machine either (different SMM
> interface — platform_profile writes fail, the kbd_backlight LED always
> reads 0), the laptop is left with no working Fn events at all until
> bitland_mifs_wmi is blacklisted. Should bitland-mifs-wmi gate its binding
> on DMI, or is another way to resolve the overlap preferred? Happy to test
> patches on TM2209.

Hi,

Like you've now noticed (I think), there's another series attempting to 
fix the GUID problem.

I'd primarily prefer taking the GUID problem fixing series (but it 
should make sure this too is addressed).

If the GUID problem series not finished in this cycle, I can consider this 
patch instead towards the end of the cycle.

Is that fine with you?

-- 
 i.


>  drivers/platform/x86/redmi-wmi.c | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/platform/x86/redmi-wmi.c b/drivers/platform/x86/redmi-wmi.c
> index 5889863..cc82ef5 100644
> --- a/drivers/platform/x86/redmi-wmi.c
> +++ b/drivers/platform/x86/redmi-wmi.c
> @@ -29,24 +29,24 @@ static const struct key_entry redmi_wmi_keymap[] = {
>  	{KE_KEY, 0x00011801,	{KEY_ASSISTANT}},
>  	{KE_KEY, 0x00011901,	{KEY_ASSISTANT}},
>  
> -	/* Keyboard backlight */
> -	{KE_IGNORE, 0x00000501, {}},
> -	{KE_IGNORE, 0x00800501, {}},
> -	{KE_IGNORE, 0x00050501, {}},
> -	{KE_IGNORE, 0x000a0501, {}},
> +	/* Keyboard backlight: Off / Auto / Low / High (new state in byte 2) */
> +	{KE_KEY, 0x00000501,	{KEY_KBDILLUMTOGGLE}},
> +	{KE_KEY, 0x00800501,	{KEY_KBDILLUMTOGGLE}},
> +	{KE_KEY, 0x00050501,	{KEY_KBDILLUMTOGGLE}},
> +	{KE_KEY, 0x000a0501,	{KEY_KBDILLUMTOGGLE}},
>  
>  	/* Xiaomi G Command Center */
>  	{KE_KEY, 0x00010a01,	{KEY_VENDOR}},
>  
> -	/* OEM preset power mode */
> -	{KE_IGNORE, 0x00011601, {}},
> -	{KE_IGNORE, 0x00021601, {}},
> -	{KE_IGNORE, 0x00031601, {}},
> -	{KE_IGNORE, 0x00041601, {}},
> +	/* OEM preset power mode: 1=Balanced 2=Silent 3=Turbo 4=Full speed */
> +	{KE_KEY, 0x00011601,	{KEY_PERFORMANCE}},
> +	{KE_KEY, 0x00021601,	{KEY_PERFORMANCE}},
> +	{KE_KEY, 0x00031601,	{KEY_PERFORMANCE}},
> +	{KE_KEY, 0x00041601,	{KEY_PERFORMANCE}},
>  
> -	/* Fn Lock state */
> -	{KE_IGNORE, 0x00000701, {}},
> -	{KE_IGNORE, 0x00010701, {}},
> +	/* Fn Lock state: 1=on 0=off */
> +	{KE_KEY, 0x00000701,	{KEY_FN_ESC}},
> +	{KE_KEY, 0x00010701,	{KEY_FN_ESC}},
>  
>  	/* Fn+`/1/2/3/4 */
>  	{KE_KEY, 0x00011101, {KEY_F13}},
>