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