mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Musaev Ibragim <atomicus.xyz@gmail.com>
To: Gladyshev Ilya <foxido@foxido.dev>
Cc: Hans de Goede <hansg@kernel.org>,
	Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>,
	Mingyou Chen <qby140326@gmail.com>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] platform/x86: redmi-wmi: report EC state change events
Date: Wed, 15 Jul 2026 00:45:36 +0600	[thread overview]
Message-ID: <178405473606.25865.4048095379503614221@gmail.com> (raw)

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


                 reply	other threads:[~2026-07-14 18:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178405473606.25865.4048095379503614221@gmail.com \
    --to=atomicus.xyz@gmail.com \
    --cc=foxido@foxido.dev \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=qby140326@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome