[Bug 222062] New: redmi-wmi: display-switch key (F7) dropped on Redmi Book Pro 16 2024 - firmware sends payload 0x00000101, keymap only has 0x00010101

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=222062

            Bug ID: 222062
           Summary: redmi-wmi: display-switch key (F7) dropped on Redmi
                    Book Pro 16 2024 - firmware sends payload 0x00000101,
                    keymap only has 0x00010101
           Product: Drivers
           Version: 2.5
    Kernel Version: 7.2.7 (also 7.2.2 and 7.2.6; mainline keymap unchanged
                    as of 2026-09-26)
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: uselessfire@gmail.com
        Regression: No

Hardware
--------
Xiaomi Redmi Book Pro 16 2024
DMI: sys_vendor XIAOMI, product_name "Redmi Book Pro 16 2024",
     board_name TM2309, bios_version RMAMT6B0P0B0B, bios_date 06/10/2025
Driver: redmi-wmi (WMI GUID 46C93E13-EE9B-4262-8488-563BCA757FEF)

Problem
-------
The dedicated display-switch key (F7, engraved with the external-display icon)
produces no input event at all. Every other hotkey on the same device works:
the settings key (F9) reports KEY_CONFIG, the screenshot key (F8) reports
KEY_SELECTIVE_SCREENSHOT, the "PC Manager" key reports KEY_ASSISTANT.

The firmware on this model emits payload 0x00000101 for the display-switch key,
while redmi_wmi_keymap only contains the long form 0x00010101. As a result
sparse_keymap_entry_from_scancode() returns NULL and redmi_wmi_notify() drops
the event:

  redmi-wmi 46C93E13-EE9B-4262-8488-563BCA757FEF-0: Unknown WMI event with
payload 257

(257 = 0x101; the message is visible after enabling dynamic debug for the
module.)

Note that the keymap already carries both the short and the long form for the
settings key -- 0x00001b01 and 0x00011b01 -- so the two-form behaviour of this
firmware is already known to the driver; the display-switch key simply lacks
its
short variant.

How it was verified
-------------------
1) Dynamic debug on the module prints the dropped payload:

   # echo "module redmi_wmi +p" > /sys/kernel/debug/dynamic_debug/control
   (press F7)
   redmi-wmi ...: Unknown WMI event with payload 257

2) A kprobe on the lookup function confirms that no matching entry is found:
   sparse_keymap_entry_from_scancode() is called with 0x101 and
   sparse_keymap_report_entry() is never reached afterwards.

   # echo "p:redmiscan sparse_keymap_entry_from_scancode payload=%si:x32" \
       > /sys/kernel/tracing/kprobe_events
   (press F7)
   redmiscan: (sparse_keymap_entry_from_scancode+0x4/0x40) payload=0x101
   (no report_entry event follows)

   For comparison, a working key produces both events:
   redmiscan:  payload=0x11601
   redmientry: type=0x4 scancode=0x11601 keycode=0

3) The keymap actually exposed by the device (read back with EVIOCGKEYCODE_V2
   over /dev/input/event7) contains 0x10101 -> 227 (KEY_SWITCHVIDEOMODE) and no
   0x101 entry.

Suggested fix
-------------
--- a/drivers/platform/x86/redmi-wmi.c
+++ b/drivers/platform/x86/redmi-wmi.c
@@
        {KE_KEY, 0x00010101,    {KEY_SWITCHVIDEOMODE}},
+       /* Redmi Book Pro 16 2024 sends the short form */
+       {KE_KEY, 0x00000101,    {KEY_SWITCHVIDEOMODE}},


Second, separate observation: unhandled Caps Lock LED echo
----------------------------------------------------------
While tracing, two more payloads showed up that the driver does not know:
0x00000901 and 0x00010901. They are not key presses. The EC echoes back the
Caps Lock LED state that the host itself has just set -- the third byte carries
the new state (1 = on, 0 = off), the same scheme the driver already documents
for the Fn Lock events (0x00000701 / 0x00010701).

Verified by switching between windows with per-window keyboard layouts, which
changes the LED without anyone touching the key: the events still arrive,
200-500 ms after the LED change, with 0x00010901 when the LED goes on and
0x00000901 when it goes off. On a system where Caps Lock switches the keyboard
layout this produces a steady stream of dev_dbg lines.

The kernel already knows this state (it set it), so these payloads only need to
be ignored:

+       /* Caps Lock LED echo: the EC reports back the LED state set by the
+        * host (third byte: 1 = on, 0 = off). Nothing to do for the kernel.
+        */
+       {KE_IGNORE, 0x00000901, {}},
+       {KE_IGNORE, 0x00010901, {}},


Third, minor: keyboard backlight comment is wrong for this model
---------------------------------------------------------------
The comment above the backlight entries reads "Off / Auto / Low / High".
On this model the cycle is, verified by pressing the key round the loop:

  0x00000501 -> off
  0x00050501 -> dim, switches itself off on the BIOS timer
  0x000a0501 -> bright, switches itself off on the BIOS timer
  0x00800501 -> bright, stays on permanently   (i.e. NOT "auto")

So 0x80 is the always-on state, and the automatic timeout is what 0x05 and 0x0a
do. The mapping to KEY_KBDILLUMTOGGLE is correct either way; only the comment
is
misleading. It may well differ on the Redmi Book Pro 15 2023 the driver was
originally tested on.

Maintainers
-----------
REDMIBOOK WMI DRIVERS
M: Gladyshev Ilya <foxido@foxido.dev>
L: platform-driver-x86@vger.kernel.org
F: drivers/platform/x86/redmi-wmi.c

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.