Am 22.07.25 um 14:48 schrieb Nikita Krasnov:
On Mon, Jul 21, 2025 at 02:23:32AM +0300 Armin Wolf wrote:
please share the whole output of acpidump as the DSDT contains only two unrelated
WMI devices.
Sure! I've attached a ZIP archive with the output of the `acpidump -b`.
I think that we do not need another driver in this case, as the xiaomi-wmi driver
is responsible for handling WMI events on Xiaomi devices. I can check what needs
to be done in order to add support for those additional keyboard events, but for
that i need the full output of acpidump.
Btw, I'd appreciate if you didn't patch the driver yourself and instead
let me do it. This is a golden opportunity for me to gain some
experience! :D
Sure, but you have to develop a new WMI driver for your device because after looking at the
ACPI tables (SSDT20 in particular) i came to the conclusion that the xiaomi-wmi driver cannot
be used in this case.
If you may, there are some questions I have about this issue:
1. From what I saw on the internet, ACPI is a protocol
(specification?) for how the power management is done on the modern
hardware. What do keyboard events have to do with ACPI? Is it
because the keypress here is handled by the firmware?
The hotkey events cannot be delivered over the standard keyboard interface as there are no scan codes
defined for all of those events. Because of this the platform firmware (in this case ACPI) provides a
virtual device (the WMI device) for receiving those events from the (embedded) keyboard controller.
2. Where in the kernel source tree can I seem some similar drivers?
Something to understand there general structure and internals.
Take a look at https://docs.kernel.org/wmi/driver-development-guide.html.
In your case you need to write a WMI event driver for the following WMI device:
class WMIEvent : __ExtrinsicEvent {
};
[WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x40A"), Description("Root WMI HID_EVENT20"), guid("{46c93e13-ee9b-4262-8488-563bca757fef}")]
class HID_EVENT20 : WmiEvent {
[key, read] string InstanceName;
[read] boolean Active;
[WmiDataId(1), read, write, Description("Package Data")] uint8 EventDetail[32];
};
The event data of this WMI event device is a buffer with a size of 32 bytes. The "EV20" ACPI control method
is responsible for filling this buffer with information regarding hotkey events. I suggest that you write a
skeleton driver first that basically prints the content of this buffer to the kernel log using print_hex_dump_bytes().
This way you can determine the mapping between WMI event numbers and the hotkeys. In your case the event data seems
to be structured like this:
1. byte: event class
2. byte: event number
3. byte: event payload
If you need further help just ask me :).
3. What is WMI? Primarily in the context of the Linux kernel, of
course There is Documentation/driver-api/wmi.rst, but it hard to
understand what exactly is it talking about if you had no prior
experience with writing drivers.
ACPI-WMI is a Windows-specific extension of the ACPI interface. It
allows the firmware to expose custom management interfaces (WMI objects)
of the Windows Management Interface (WMI). We implement a subset of the
WMI interface inside the Linux kernel to be able to control the various
platform-specific settings being exposed this way. Thanks, Armin Wolf
