From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Musaev Ibragim <atomicus.xyz@gmail.com>
Cc: Gladyshev Ilya <foxido@foxido.dev>,
Hans de Goede <hansg@kernel.org>,
Mingyou Chen <qby140326@gmail.com>,
platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] platform/x86: redmi-wmi: report EC state change events
Date: Tue, 21 Jul 2026 19:47:39 +0300 (EEST) [thread overview]
Message-ID: <0dccec1c-d0f2-f043-3176-728c53791f3d@linux.intel.com> (raw)
In-Reply-To: <178405473606.25865.4048095379503614221@gmail.com>
[-- 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}},
>
next prev parent reply other threads:[~2026-07-21 16:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 18:45 Musaev Ibragim
2026-07-21 16:47 ` Ilpo Järvinen [this message]
2026-07-21 17:31 ` Musaev Ibragim
2026-08-18 14:33 ` Ilpo Järvinen
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=0dccec1c-d0f2-f043-3176-728c53791f3d@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=atomicus.xyz@gmail.com \
--cc=foxido@foxido.dev \
--cc=hansg@kernel.org \
--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
all inboxes | Powered by JetHome®