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

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

[Musaev Ibragim]

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@gmail.com>
---
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.

 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}},
-- 
2.54.0

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 4253 bytes --]

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@gmail.com>
> ---
> 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}},
> 

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

[Musaev Ibragim]

On Tue, 21 Jul 2026, Ilpo Järvinen wrote:

> 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?

Yes, that's fine with me -- landing the GUID-fix series first makes
sense. I've already reviewed the Redmibook side of it on my TM2209 and
left comments on patch 2/4, including a request to keep these EC state
events observable rather than KE_IGNOREd. Happy to test v2 on this
hardware.

If the series misses the cycle, picking this patch up at the end of it
works for me.

Thanks,
Ibragim

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

[Ilpo Järvinen]

On Wed, 15 Jul 2026 00:45:36 +0600, 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.
> 
> [...]

Thank you for your contribution, it has been applied to my local
review-ilpo-next branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-next branch only once I've pushed my
local branch there, which might take a while.

FYI [if applicable to your patch], as per Linus' policy change, also
fixes are mostly routed through for-next unless the fix is for a
commit introduced in the most recent cycle or is clearly a regression
fix.

The list of commits applied:
[1/1] platform/x86: redmi-wmi: report EC state change events
      commit: e0d6312578e1fd03738fc2ac8ac21c8bd84e965e

--
 i.