mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: Derek John Clark <derekjohn.clark@gmail.com>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Hans de Goede" <hansg@kernel.org>,
	"Pierre-Loup A . Griffais" <pgriffais@valvesoftware.com>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] platform/x86: msi-wmi: Add MSI Claw M-Center keys
Date: Fri, 12 Jun 2026 23:46:52 +0200	[thread overview]
Message-ID: <6100b6c3-2bee-48ec-918a-d6bc1862cde7@gmx.de> (raw)
In-Reply-To: <CAFqHKTn37uDm6ah-7XLtv-w6UCZKYxk5Tv7tbss-YmgsAYOqLA@mail.gmail.com>

Am 12.06.26 um 20:25 schrieb Derek John Clark:
> On Fri, Jun 12, 2026 at 10:54 AM Armin Wolf <W_Armin@gmx.de> wrote:
>>
>> Am 12.06.26 um 00:39 schrieb Derek J. Clark:
>>
>>> MSI Claw devices produce WMI events through the MSI WMI hotkeys GUID for
>>> some of their buttons. When pressed, these cause spam in the kernel. For
>>> the majority of devices these events can be safely ignored as they are
>>> duplicated by the AT Translated Set 2 Keyboard device exposed as an
>>> evdev. For the MSI Claw A8 BZ2EM model's M-Center Menu button (left of
>>> the screen) there is no associated keyboard event, so this event must be
>>> exposed. Map this button to the same scancode produced by the AT
>>> Keyboard device on other models. This does cause double F15 events on
>>> the A1M, 7 AI+ A2VM, and 8 AI+ A2VM, but it appears to be harmless in my
>>> testing.
>>>
>>> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
>>> ---
>>>    drivers/platform/x86/msi-wmi.c | 22 ++++++++++++++++++++++
>>>    1 file changed, 22 insertions(+)
>>>
>>> diff --git a/drivers/platform/x86/msi-wmi.c b/drivers/platform/x86/msi-wmi.c
>>> index d00ced756581..73a4f0d2dc04 100644
>>> --- a/drivers/platform/x86/msi-wmi.c
>>> +++ b/drivers/platform/x86/msi-wmi.c
>>> @@ -46,6 +46,12 @@ enum msi_scancodes {
>>>        WIND_KEY_WLAN           = 0x5f, /* Fn+F11 Wi-Fi toggle */
>>>        WIND_KEY_TURBO,                 /* Fn+F10 turbo mode toggle */
>>>        WIND_KEY_ECO            = 0x69, /* Fn+F10 ECO mode toggle */
>>> +     /* MSI Claw keys */
>>> +     CLAW_KEY_VOLUMEDOWN     = 0x21,
>>> +     CLAW_KEY_CENTER         = 0x29, /* MSI M-Center main menu */
>>> +     CLAW_KEY_QUICK_LONG     = 0x2a, /* MSI M-Center quick access long hold */
>>> +     CLAW_KEY_VOLUMEUP       = 0x32,
>>> +     CLAW_KEY_QUICK_SHORT    = 0x58, /* MSI M-Center quick access short press */
>>>    };
>>>    static struct key_entry msi_wmi_keymap[] = {
>>>        { KE_KEY, MSI_KEY_BRIGHTNESSUP,         {KEY_BRIGHTNESSUP} },
>>> @@ -69,6 +75,15 @@ static struct key_entry msi_wmi_keymap[] = {
>>>        { KE_KEY, WIND_KEY_TURBO,               {KEY_PROG1} },
>>>        { KE_KEY, WIND_KEY_ECO,                 {KEY_PROG2} },
>>>
>>> +     /* These are MSI Claw keys, used for MSI M-Center in Windows */
>>> +     { KE_KEY, CLAW_KEY_CENTER,              {KEY_F15} },
>>> +
>>> +     /* These MSI Claw keys work without WMI. Ignore them to avoid double keycodes */
>>> +     { KE_IGNORE, CLAW_KEY_QUICK_SHORT },
>>> +     { KE_IGNORE, CLAW_KEY_QUICK_LONG },
>>> +     { KE_IGNORE, CLAW_KEY_VOLUMEUP },
>>> +     { KE_IGNORE, CLAW_KEY_VOLUMEDOWN },
>>> +
>>>        { KE_END, 0 }
>>>    };
>>>
>>> @@ -183,6 +198,13 @@ static void msi_wmi_notify(union acpi_object *obj, void *context)
>>>                eventcode = obj->integer.value;
>>>                pr_debug("Eventcode: 0x%x\n", eventcode);
>>>                break;
>>> +     case ACPI_TYPE_BUFFER:
>>> +             if (!obj->buffer.length)
>>> +                     return;
>>> +
>>> +             eventcode = obj->buffer.pointer[0];
>>> +             pr_debug("Eventcode: 0x%x\n", eventcode);
>>
>> Can you share the BMOF associated with this event? I suspect that the buffer should
>> contain a u32.
> 
> The GUID's don't appear to contain any bmof data:
> 
> $ lsmod | grep bmof
> wmi_bmof               12288  0
> wmi                    32768  4 video,wmi_bmof,msi_wmi,msi_wmi_platform
> 
> $ tree -l -L 2
> .
> ├── 1E2A0DA0-2B9E-424F-9C87-B1DAC3F4E9DA-3 ->
> ../../../devices/pci0000:00/0000:00:02.3/0000:c3:00.0/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/1E2A0DA0-2B9E-424F-9C87-B1DAC3F4E9DA-3
> │   ├── driver_override
> │   ├── expensive
> │   ├── guid
> │   ├── instance_count
> │   ├── modalias
> │   ├── notify_id
> │   ├── power
> │   ├── subsystem -> ../../../../../../../../bus/wmi
> │   └── uevent
> ├── 5B3CC38A-40D9-7245-8AE6-1145B751BE3F-1 ->
> ../../../devices/pci0000:00/0000:00:14.3/PNP0C09:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/5B3CC38A-40D9-7245-8AE6-1145B751BE3F-1
> │   ├── driver_override
> │   ├── expensive
> │   ├── guid
> │   ├── instance_count
> │   ├── modalias
> │   ├── notify_id
> │   ├── power
> │   ├── subsystem -> ../../../../../../../../bus/wmi
> │   └── uevent
> ├── ABBC0F6E-8EA1-11D1-00A0-C90629100000-0 ->
> ../../../devices/pci0000:00/0000:00:14.3/PNP0C09:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/ABBC0F6E-8EA1-11D1-00A0-C90629100000-0
> │   ├── driver -> ../../../../../../../../bus/wmi/drivers/msi-wmi-platform
> │   ├── driver_override
> │   ├── expensive
> │   ├── guid
> │   ├── hwmon
> │   ├── instance_count
> │   ├── modalias
> │   ├── object_id
> │   ├── platform-profile
> │   ├── power
> │   ├── subsystem -> ../../../../../../../../bus/wmi
> │   └── uevent
> └── B2526ED4-CB45-49FA-9230-8D2FE8AFB8EC-2 ->
> ../../../devices/pci0000:00/0000:00:02.3/0000:c3:00.0/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/B2526ED4-CB45-49FA-9230-8D2FE8AFB8EC-2
>      ├── driver_override
>      ├── expensive
>      ├── guid
>      ├── instance_count
>      ├── modalias
>      ├── object_id
>      ├── power
>      ├── subsystem -> ../../../../../../../../bus/wmi
>      └── uevent
> 
> 16 directories, 28 files
> 
> 
> I extracted the _WED event method from the DSDT. I don't have a lot of
> experience with interpreting ACPI, but my understanding is that it
> returns u8[2] with index 0 being the keycode and index 1 being the
> state. Since we don't get events on release, that is essentially
> unused. I can do a .length != 2 in the validation step before I
> extract the keycode if desired.

Oh right, i forgot that the MSI software contains the necessary BMOF 
data xd.

Anyway, here it is for the WIND event:

[WMI, Dynamic, Provider("WmiProv"), Local("MS\\0x409"), 
Description("Event defined by MSI"), 
guid("{5B3CC38A-40D9-7245-8AE6-1145B751BE3F}")]
class MSI_Event : WMIEvent {
   [key, read] string InstanceName;
   [read] boolean Active;
   [WmiDataId(1), read, write, Description("Event defined by MSI")] 
uint32 MSIEvt;
};

So the event payload is indeed a plain u32. For some reason the Windows 
WMI stack accepts 2 byte buffers even when at least 4 are necessary. I 
have no idea why Windows does accept undersized data in this case, but
i suggest you do the same.

So a length < 2 check (not !=, we need to still accept oversized 
buffers) like you described earlier should be enough. Just drop a 
comment somewhere that explains the meaning of index 1.

Thanks,
Armin Wolf

> 
> Method (_WED, 1, NotSerialized)  // _Wxx: Wake Event, xx=0x00-0xFF
>              {
>                  If ((Arg0 == 0xC0))
>                  {
>                      Name (EVRT, Buffer (0x02)
>                      {
>                           0x00, 0x00                                       // ..
>                      })
>                      Name (TMPB, Zero)
>                      TMPB = WMRD (0xD8)
>                      EVRT [Zero] = TMPB /* \_SB_.PCI0.SBRG.EC__.SCM0._WED.TMPB */
>                      If ((TMPB == 0x08))
>                      {
>                          EVRT [One] = ((WMRD (0xE4) >> 0x03) & 0x1F
>                              )
>                      }
> 
>                      If ((TMPB == 0x56))
>                      {
>                          EVRT [One] = WMRD (0x2E)
>                      }
> 
>                      If ((TMPB == 0x57))
>                      {
>                          EVRT [One] = WMRD (0x2E)
>                      }
> 
>                      If ((TMPB == 0x5F))
>                      {
>                          EVRT [One] = WMRD (0x2E)
>                      }
> 
>                      If ((TMPB == 0x60))
>                      {
>                          EVRT [One] = (WMRD (0xE4) & 0x07)
>                      }
> 
>                      If ((TMPB == 0x62))
>                      {
>                          EVRT [One] = WMRD (0xD1)
>                      }
> 
>                      If ((TMPB == 0x63))
>                      {
>                          EVRT [One] = WMRD (0xD1)
>                      }
> 
>                      If ((TMPB == 0x73))
>                      {
>                          EVRT [One] = ((WMRD (0xE4) >> 0x03) & 0x1F
>                              )
>                      }
> 
>                      If ((TMPB == 0x79))
>                      {
>                          EVRT [One] = ((WMRD (0xE4) >> 0x03) & 0x1F
>                              )
>                      }
> 
>                      If ((TMPB == 0x7B))
>                      {
>                          EVRT [One] = WMRD (0x2E)
>                      }
> 
>                      If ((TMPB == 0x84))
>                      {
>                          EVRT [One] = WMRD (0x2E)
>                      }
> 
>                      If ((TMPB == 0x02))
>                      {
>                          EVRT [One] = ((WMRD (0xE4) >> 0x03) & 0x1F
>                              )
>                      }
> 
>                      WMWT (0xD8, Zero)
>                      Return (EVRT) /* \_SB_.PCI0.SBRG.EC__.SCM0._WED.EVRT */
>                  }
> 
>                  Return (Zero)
>              }
> 
> 
> Also  the _WDG that points the Wind GUID to arg 0xC0:
> 
> Name (_WDG, Buffer (0x64)
>              {
>                  /* 0000 */  0x6A, 0x0F, 0xBC, 0xAB, 0xA1, 0x8E, 0xD1,
> 0x11,  // j.......
>                  /* 0008 */  0x00, 0xA0, 0xC9, 0x06, 0x29, 0x10, 0x00,
> 0x00,  // ....)...
>                  /* 0010 */  0x41, 0x4B, 0x01, 0x01, 0x6B, 0x0F, 0xBC,
> 0xAB,  // AK..k...
>                  /* 0018 */  0xA1, 0x8E, 0xD1, 0x11, 0x00, 0xA0, 0xC9,
> 0x06,  // ........
>                  /* 0020 */  0x29, 0x10, 0x00, 0x00, 0x41, 0x4C, 0x01,
> 0x01,  // )...AL..
>                  /* 0028 */  0x6D, 0x0F, 0xBC, 0xAB, 0xA1, 0x8E, 0xD1,
> 0x11,  // m.......
>                  /* 0030 */  0x00, 0xA0, 0xC9, 0x06, 0x29, 0x10, 0x00,
> 0x00,  // ....)...
>                  /* 0038 */  0x41, 0x4A, 0x01, 0x02, 0x6E, 0x0F, 0xBC,
> 0xAB,  // AJ..n...
>                  /* 0040 */  0xA1, 0x8E, 0xD1, 0x11, 0x00, 0xA0, 0xC9,
> 0x06,  // ........
>                  /* 0048 */  0x29, 0x10, 0x00, 0x00, 0x41, 0x4D, 0x01,
> 0x02,  // )...AM..
>                  /* 0050 */  0x8A, 0xC3, 0x3C, 0x5B, 0xD9, 0x40, 0x45,
> 0x72,  // ..<[.@Er
>                  /* 0058 */  0x8A, 0xE6, 0x11, 0x45, 0xB7, 0x51, 0xBE,
> 0x3F,  // ...E.Q.?
>                  /* 0060 */  0xC0, 0x00, 0x01, 0x09
>        // ....
>            })
> ...
> 
> Thanks,
> Derek
> 
>> Thanks,
>> Armin Wolf
>>
>>> +             break;
>>>        default:
>>>                pr_info("Unknown event received\n");
>>>                return;
> 


  reply	other threads:[~2026-06-12 21:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 22:39 [PATCH 0/2] platform/x86: msi-wmi: Fix unknown wmi event messages on MSI Claw models Derek J. Clark
2026-06-11 22:39 ` [PATCH 1/2] platform/x86: msi-wmi: Reformat msi_wmi_notify() Derek J. Clark
2026-06-11 22:39 ` [PATCH 2/2] platform/x86: msi-wmi: Add MSI Claw M-Center keys Derek J. Clark
2026-06-12 17:54   ` Armin Wolf
2026-06-12 18:25     ` Derek John Clark
2026-06-12 21:46       ` Armin Wolf [this message]
2026-06-12 16:34 ` [PATCH 0/2] platform/x86: msi-wmi: Fix unknown wmi event messages on MSI Claw models Armin Wolf
2026-06-12 17:18   ` Derek John Clark
2026-06-12 17:52     ` Armin Wolf

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=6100b6c3-2bee-48ec-918a-d6bc1862cde7@gmx.de \
    --to=w_armin@gmx.de \
    --cc=derekjohn.clark@gmail.com \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pgriffais@valvesoftware.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /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®