Re: Missing ACPI driver for a keyboard button in Xiaomi RedmiBook Pro 16

[Armin Wolf <W_Armin@gmx.de>]

Am 28.07.25 um 01:36 schrieb Nikita Krasnov:

>> No, it is because your device is using a different WMI interface for delivering events. Device manufacturers
>> are not exactly known for using the same WMI interfaces for a long time :(.
> By the way, how would we call this driver? xiaomi-2-wmi?

Another user just submitted a WMI driver for this WMI event device called "redmi-wmi". I think that
name sounds good enough.

>> Personally i have no problem with you writing a WMI driver in Rust, but currently we have
>> no suitable bindings for the WMI driver API. Additionally i am currently designing a new
>> WMI driver API that will make it easier to implement the necessary Rust bindings, so the
>> whole thing might take some time.
> Well, I am fine with having to implement the missing Rust bindings — no
> problem there. I was actually looking forward to it. But if the API's
> going to change... Oof.
>
>   * Would the API change be _that_ drastic?

Not really. Basically all usages of acpi_object would be replaced with a struct wmi_buffer that
acts like a sized buffer containing binary data. The big changes happen inside the underlying
WMI subsystem itself.

>   * Do you have any expectations on when would that API be released?

I plan to submit the patch series in a couple of weeks, but it might take some time before said
patch series is accepted upstream.

>   * Would the new API deprecate the previous one?

Yes, but the old API would not be removed until all existing drivers have migrated to the new API.

> Maybe I could do this in Rust right now and then simply update the
> bindings to the new API? That way it would be possible to write the
> driver in Rust. If the API is going to change — the C code would have to
> be updated either way, right? Maybe updating C driver versus updating
> Rust bindings+driver is not that big of a difference. What do you think?

The old API uses a data structure called acpi_object that might be difficult to safely
use inside Rust, so only developing bindings for the new API would avoid this.

> I doubt there are going to be so many Rust WMI users that it would get
> really difficult to move anyone to the bindings with a new API..? How
> active is the WMI submodule (is it actually a submodule or just a
> component of ACPI) really is?

The WMI submodule itself is not that active, but the drivers using it are different in that regard.

>> Would it be possible for you to implement the WMI driver in C?
> Yea, absolutely! I'm totally fine with writing this in C. I just really
> don't want to miss the opportunity to use Rust here (is it's actually
> feasible)!

Since another user recently submitted a WMI driver for the WMI event device in question i suggest
that you instead focus on bringing this driver into the mainline kernel. You could for example test
this driver on your device and report back if everything works.

Thanks,
Armin Wolf

> --
> Nikita Krasnov