> 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? > 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? * Do you have any expectations on when would that API be released? * Would the new API deprecate the previous one? 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? 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? > 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)! -- Nikita Krasnov
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
