| Message ID | 20250319191320.10092-1-lkml@antheas.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | HID: asus: hid-asus and asus-wmi backlight unification, Z13 QOL improvements | expand |
On Wed, 19 Mar 2025 at 22:38, Antheas Kapenekakis <lkml@antheas.dev> wrote: > > This is a three part series that does the following: first, it cleans up > the hid-asus driver initialization, preventing excess renames and dmesg > errors on ROG devices. Then, it adds support for the Z13 2025 keyboard, > by fixing its keyboard to not be stuck in BIOS mode and enabling its fan > key. Finally, the bigger piece of this series is the unification of the > backlight controls between hid-asus and asus-wmi. > > <snip> > -- > 2.48.1 > Update on this. I made a minor refactor today to fix some edge cases where it was obvious the mutex was not guarding stuff and ended up locking during unregistering in this series. So skip testing it. I'll send the fixed version tomorrow, in the meantime you can find it here [1]. Fixes were very minor, moving the mutexes around in 2 places, so feel free to comment on this series. Also, the init delay seems to not have worked for the mouse touchpad bug. Seems like 5 reboots were not enough testing. I will say it is peculiar that hid-generic works properly, when this series makes hid-asus mimic it very closely. Also, one rmmod to hid-asus fixes this, regardless of how many times hid-asus is reloaded afterwards. Antheas +CC Mario in case you want to review [1] https://github.com/bazzite-org/patchwork/tree/upstream/asusrgb
Hi Antheas, On Thu, 20 Mar 2025, at 8:13 AM, Antheas Kapenekakis wrote: > This is a three part series that does the following: first, it cleans up > the hid-asus driver initialization, preventing excess renames and dmesg > errors on ROG devices. Then, it adds support for the Z13 2025 keyboard, > by fixing its keyboard to not be stuck in BIOS mode and enabling its fan > key. Finally, the bigger piece of this series is the unification of the > backlight controls between hid-asus and asus-wmi. > > This requires some context. First, some ROG devices expose both WMI and > HID controls for RGB. In addition, some ROG devices (such as the Z13) > have two AURA devices where both have backlight controls (lightbar and > keyboard). Under Windows, Armoury Crate exposes a single brightness control > for all Aura devices. > > However, currently in the linux kernel this is not the case, with asus-wmi > and hid-asus relying on a quirk system to figure out which should control > the backlight. But what about the other one? There might be silent > regressions such as part of the RGB of the device not responding properly. > > In the Z13, this is the case, with a race condition causing the lightbar > to control the asus::kbd_backlight device most of the time, with the > keyboard being renamed to asus::kbd_backlight_1 and not doing anything > under KDE controls. > > Here, we should note that most backlight handlers are hardcoded to check > for backlight once, and for one backlight, during boot, so any other > solution would require a large rewrite of userspace. This makes me wish there was better standardization. Maybe filing some reports upstream to those various projects could get the ball rolling? > Even when brightness controls are fixed, we still have the problem of the > backlight key being on/off when controlled by KDE and 0/33/66/100 when > the device has a WMI keyboard. Ideally, we would like the 0/33/66/100 to > be done under hid as well, regardless of whether the backlight of the > device is controlled by WMI or HID. > > Therefore, this is what the third part of this series does. It sets up > asus-wmi to expose accepting listeners for the asus::kbd_backlight device > and being the one that sets it up. Then, it makes hid-asus devices > register a listener there, so that all of them are controlled by > asus::kbd_backlight. Finally, it adds an event handler for keyboard keys, > so that HID led controls are handled by the kernel instead of userspace. > This way, even when userspace is not active the key works, and we get the > desired behavior of 0/33/66/100 across all Aura devices (currently, that > is keyboards, and embedded devices such as lightbars). This results > removing the quirk system as well, eliminating a point of failure. Nice, I'd been looking at doing something similar but unfortunately hadn't the time for it, nor the device appropriate for testing (keyboard, detachable, lightbar). TBH I wish there was a much better way in kernel to handle these sorts of lighting situations, especially given that we have laptops across vendors and models with different modes, zones, per-key, MCU mode vs software mode etc etc. There is a *very* long thread on lkml bikeshedding it all too - see https://lore.kernel.org/lkml/20231011190017.1230898-1-wse@tuxedocomputers.com/ The LampArray thing is out of scope for this, but I thought maybe worth mentioning in case you weren't aware. The major pitfall of it is that per-key devices update per-row and when you do a single key update to update a whole keyboard it sends N-Key amounts of packets.. Off-topic though. But if you have some ideas please email me. > I tested this on an Asus Z13 2025, and testing by other devices would be > appreciated for sure. This series is designed to be transparent to > userspace behavior-wise compared previous kernels, with all existing > laptops either having the same behavior or being better. I have a handful of laptops I can test, including my old GA501, I'll get on it. > The Z13 keyboard folio RGB controls work beautifully, with KDE led > notifications working and doing 0/33/66/100 as expected. This also happens > with hotplugging, as the lightbar is always available and keeps the > endpoint alive from boot, even if the folio is not connected (a quirk > can be added later if there is a device where this is not the case). Very good. This will make a lot of folks happy, I suspect the Z13 is going to be a very popular device. > The first two parts of the series can also be merged independently of the > third part, so we can iterate on that more. Perhaps there is a better way > to handle this cohesion, After a quick cursory look, this looks good so far. Perhaps after review and iteration you could submit as an independent series to get those parts in quicker - but hey we can cross that when we get to it. > Oh, by the way Luke, I developed this series with a variant of > your Armoury series merged, and only switched to 6.14-v7 for this > submission. You will be happy to know that there are no conflicts :) > (at least with that version from ~January). Also, please factcheck > my initialization sequence is correct in the 0x5d and 0x5e devices > you added when you made that refactor last year. Are those handshakes > needed? I would hope the armoury driver stays out of the way of most things, I tried to make it independent. The handshakes are needed for sure, depending on device it may be partial or more, but it's always been the same ASCII right back to when I first started on this with a 2018 laptop - we never bothered with the response check though. I do forget what required the 0x5e init, I'll need to check through some old notes. I'll apologize in advance for the time it might take me to review - I'll attempt some now for the smaller patches, but hopefully I can get some time in this weekend and we can work together to make asus stuff even better. Cheers, Luke. > Antheas Kapenekakis (11): > HID: asus: refactor init sequence per spec > HID: asus: cleanup keyboard backlight check > HID: asus: prevent binding to all HID devices on ROG > HID: asus: rename keyboard3 to Z13_FOLIO > HID: asus: add Asus Z13 2025 Fan key > HID: asus: introduce small delay on Asus Z13 RGB init > platform/x86: asus-wmi: Add support for multiple kbd RGB handlers > HID: asus: listen to the asus-wmi brightness device instead of > creating one > platform/x86: asus-wmi: remove unused keyboard backlight quirk > platform/x86: asus-wmi: add keyboard brightness event handler > HID: asus: add support for the asus-wmi brightness handler > > drivers/hid/hid-asus.c | 220 ++++++++++++--------- > drivers/hid/hid-ids.h | 2 +- > drivers/platform/x86/asus-wmi.c | 137 +++++++++++-- > include/linux/platform_data/x86/asus-wmi.h | 66 +++---- > 4 files changed, 279 insertions(+), 146 deletions(-) > > > base-commit: 4701f33a10702d5fc577c32434eb62adde0a1ae1 > -- > 2.48.1
On Thu, 20 Mar 2025 at 07:10, Luke Jones <luke@ljones.dev> wrote: > > Hi Antheas, > > On Thu, 20 Mar 2025, at 8:13 AM, Antheas Kapenekakis wrote: > > This is a three part series that does the following: first, it cleans up > > the hid-asus driver initialization, preventing excess renames and dmesg > > errors on ROG devices. Then, it adds support for the Z13 2025 keyboard, > > by fixing its keyboard to not be stuck in BIOS mode and enabling its fan > > key. Finally, the bigger piece of this series is the unification of the > > backlight controls between hid-asus and asus-wmi. > > > > This requires some context. First, some ROG devices expose both WMI and > > HID controls for RGB. In addition, some ROG devices (such as the Z13) > > have two AURA devices where both have backlight controls (lightbar and > > keyboard). Under Windows, Armoury Crate exposes a single brightness control > > for all Aura devices. > > > > However, currently in the linux kernel this is not the case, with asus-wmi > > and hid-asus relying on a quirk system to figure out which should control > > the backlight. But what about the other one? There might be silent > > regressions such as part of the RGB of the device not responding properly. > > > > In the Z13, this is the case, with a race condition causing the lightbar > > to control the asus::kbd_backlight device most of the time, with the > > keyboard being renamed to asus::kbd_backlight_1 and not doing anything > > under KDE controls. > > > > Here, we should note that most backlight handlers are hardcoded to check > > for backlight once, and for one backlight, during boot, so any other > > solution would require a large rewrite of userspace. > > This makes me wish there was better standardization. Maybe filing some reports upstream to those various projects could get the ball rolling? I think KDE has some improvements for it for multi-device support. But specifically for brightness, it seems that all currently supported manufacturers work fine with this so it would be a lot of work just for asus to do this through userspace. > > Even when brightness controls are fixed, we still have the problem of the > > backlight key being on/off when controlled by KDE and 0/33/66/100 when > > the device has a WMI keyboard. Ideally, we would like the 0/33/66/100 to > > be done under hid as well, regardless of whether the backlight of the > > device is controlled by WMI or HID. > > > > Therefore, this is what the third part of this series does. It sets up > > asus-wmi to expose accepting listeners for the asus::kbd_backlight device > > and being the one that sets it up. Then, it makes hid-asus devices > > register a listener there, so that all of them are controlled by > > asus::kbd_backlight. Finally, it adds an event handler for keyboard keys, > > so that HID led controls are handled by the kernel instead of userspace. > > This way, even when userspace is not active the key works, and we get the > > desired behavior of 0/33/66/100 across all Aura devices (currently, that > > is keyboards, and embedded devices such as lightbars). This results > > removing the quirk system as well, eliminating a point of failure. > > Nice, I'd been looking at doing something similar but unfortunately hadn't the time for it, nor the device appropriate for testing (keyboard, detachable, lightbar). TBH I wish there was a much better way in kernel to handle these sorts of lighting situations, especially given that we have laptops across vendors and models with different modes, zones, per-key, MCU mode vs software mode etc etc. There is a *very* long thread on lkml bikeshedding it all too - see https://lore.kernel.org/lkml/20231011190017.1230898-1-wse@tuxedocomputers.com/ > > The LampArray thing is out of scope for this, but I thought maybe worth mentioning in case you weren't aware. The major pitfall of it is that per-key devices update per-row and when you do a single key update to update a whole keyboard it sends N-Key amounts of packets.. > > Off-topic though. But if you have some ideas please email me. For me, I think when it comes to Asus, getting the brightness to work is 90% of the way. Then, getting simple RGB that works with KDE but if the KDE option is ticked off it defers to other userspace programs such as your own is the other 10%. And for that, I think having hid-asus create its own handlers in addition to the one for backlight in WMI would be appropriate > > I tested this on an Asus Z13 2025, and testing by other devices would be > > appreciated for sure. This series is designed to be transparent to > > userspace behavior-wise compared previous kernels, with all existing > > laptops either having the same behavior or being better. > > I have a handful of laptops I can test, including my old GA501, I'll get on it. > > > The Z13 keyboard folio RGB controls work beautifully, with KDE led > > notifications working and doing 0/33/66/100 as expected. This also happens > > with hotplugging, as the lightbar is always available and keeps the > > endpoint alive from boot, even if the folio is not connected (a quirk > > can be added later if there is a device where this is not the case). > > Very good. This will make a lot of folks happy, I suspect the Z13 is going to be a very popular device. > > > The first two parts of the series can also be merged independently of the > > third part, so we can iterate on that more. Perhaps there is a better way > > to handle this cohesion, > > After a quick cursory look, this looks good so far. Perhaps after review and iteration you could submit as an independent series to get those parts in quicker - but hey we can cross that when we get to it. > > > Oh, by the way Luke, I developed this series with a variant of > > your Armoury series merged, and only switched to 6.14-v7 for this > > submission. You will be happy to know that there are no conflicts :) > > (at least with that version from ~January). Also, please factcheck > > my initialization sequence is correct in the 0x5d and 0x5e devices > > you added when you made that refactor last year. Are those handshakes > > needed? > > I would hope the armoury driver stays out of the way of most things, I tried to make it independent. The handshakes are needed for sure, depending on device it may be partial or more, but it's always been the same ASCII right back to when I first started on this with a 2018 laptop - we never bothered with the response check though. I do forget what required the 0x5e init, I'll need to check through some old notes. > > I'll apologize in advance for the time it might take me to review - I'll attempt some now for the smaller patches, but hopefully I can get some time in this weekend and we can work together to make asus stuff even better. > > Cheers, > Luke. > > > Antheas Kapenekakis (11): > > HID: asus: refactor init sequence per spec > > HID: asus: cleanup keyboard backlight check > > HID: asus: prevent binding to all HID devices on ROG > > HID: asus: rename keyboard3 to Z13_FOLIO > > HID: asus: add Asus Z13 2025 Fan key > > HID: asus: introduce small delay on Asus Z13 RGB init > > platform/x86: asus-wmi: Add support for multiple kbd RGB handlers > > HID: asus: listen to the asus-wmi brightness device instead of > > creating one > > platform/x86: asus-wmi: remove unused keyboard backlight quirk > > platform/x86: asus-wmi: add keyboard brightness event handler > > HID: asus: add support for the asus-wmi brightness handler > > > > drivers/hid/hid-asus.c | 220 ++++++++++++--------- > > drivers/hid/hid-ids.h | 2 +- > > drivers/platform/x86/asus-wmi.c | 137 +++++++++++-- > > include/linux/platform_data/x86/asus-wmi.h | 66 +++---- > > 4 files changed, 279 insertions(+), 146 deletions(-) > > > > > > base-commit: 4701f33a10702d5fc577c32434eb62adde0a1ae1 > > -- > > 2.48.1
Hi Antheas, On 19-Mar-25 20:13, Antheas Kapenekakis wrote: > This is a three part series that does the following: first, it cleans up > the hid-asus driver initialization, preventing excess renames and dmesg > errors on ROG devices. Then, it adds support for the Z13 2025 keyboard, > by fixing its keyboard to not be stuck in BIOS mode and enabling its fan > key. Finally, the bigger piece of this series is the unification of the > backlight controls between hid-asus and asus-wmi. Thank you for your work on this. > This requires some context. First, some ROG devices expose both WMI and > HID controls for RGB. In addition, some ROG devices (such as the Z13) > have two AURA devices where both have backlight controls (lightbar and > keyboard). Under Windows, Armoury Crate exposes a single brightness control > for all Aura devices. > > However, currently in the linux kernel this is not the case, with asus-wmi > and hid-asus relying on a quirk system to figure out which should control > the backlight. But what about the other one? There might be silent > regressions such as part of the RGB of the device not responding properly. > > In the Z13, this is the case, with a race condition causing the lightbar > to control the asus::kbd_backlight device most of the time, with the > keyboard being renamed to asus::kbd_backlight_1 and not doing anything > under KDE controls. > > Here, we should note that most backlight handlers are hardcoded to check > for backlight once, and for one backlight, during boot, so any other > solution would require a large rewrite of userspace. Note that work is actually ongoing to add support for multiple kbd backlights to upower: https://gitlab.freedesktop.org/upower/upower/-/merge_requests/258 But that is intended for when there are 2 kbds with a controllable backlight, e.g. a docked laptop with a gaming kbd with RGB backlight connected to the dock. Where as here we seem to have 2 controls which ideally should be set to the same value if I understand things correctly ? > Even when brightness controls are fixed, we still have the problem of the > backlight key being on/off when controlled by KDE and 0/33/66/100 when > the device has a WMI keyboard. Ideally, we would like the 0/33/66/100 to > be done under hid as well, regardless of whether the backlight of the > device is controlled by WMI or HID. Hmm, ideally we want this sort of policy to be in userspace, this sounds more like it is a keycode problem and we maybe need KEY_KBDILLUMCYCLE next to the existing KEY_KBDILLUMTOGGLE. For the existing toggle doing on/off obviously is the correct userspace behavior. Anyways I can see how Asus is special here and on laptops the cycling is typically handled by the EC and we have chosen to emulate EC behavior in the kernel before to keep things consistent amongst models. Still generally speaking we do prefer to just send keypresses when possible and let userspace set the policy, but I guess we can make an exception here. > Therefore, this is what the third part of this series does. It sets up > asus-wmi to expose accepting listeners for the asus::kbd_backlight device > and being the one that sets it up. Then, it makes hid-asus devices > register a listener there, so that all of them are controlled by > asus::kbd_backlight. Finally, it adds an event handler for keyboard keys, > so that HID led controls are handled by the kernel instead of userspace. > This way, even when userspace is not active the key works, and we get the > desired behavior of 0/33/66/100 across all Aura devices (currently, that > is keyboards, and embedded devices such as lightbars). This results > removing the quirk system as well, eliminating a point of failure. I've taken a quick look at the new API between asus-wmi and asus-hid and this looks good to me, thank you for your work on this. Regards, Hans
On Mon, 24 Mar 2025 at 13:10, Hans de Goede <hdegoede@redhat.com> wrote: > > Hi Antheas, > > On 19-Mar-25 20:13, Antheas Kapenekakis wrote: > > This is a three part series that does the following: first, it cleans up > > the hid-asus driver initialization, preventing excess renames and dmesg > > errors on ROG devices. Then, it adds support for the Z13 2025 keyboard, > > by fixing its keyboard to not be stuck in BIOS mode and enabling its fan > > key. Finally, the bigger piece of this series is the unification of the > > backlight controls between hid-asus and asus-wmi. > > Thank you for your work on this. > > > This requires some context. First, some ROG devices expose both WMI and > > HID controls for RGB. In addition, some ROG devices (such as the Z13) > > have two AURA devices where both have backlight controls (lightbar and > > keyboard). Under Windows, Armoury Crate exposes a single brightness control > > for all Aura devices. > > > > However, currently in the linux kernel this is not the case, with asus-wmi > > and hid-asus relying on a quirk system to figure out which should control > > the backlight. But what about the other one? There might be silent > > regressions such as part of the RGB of the device not responding properly. > > > > In the Z13, this is the case, with a race condition causing the lightbar > > to control the asus::kbd_backlight device most of the time, with the > > keyboard being renamed to asus::kbd_backlight_1 and not doing anything > > under KDE controls. > > > > Here, we should note that most backlight handlers are hardcoded to check > > for backlight once, and for one backlight, during boot, so any other > > solution would require a large rewrite of userspace. > > Note that work is actually ongoing to add support for multiple kbd > backlights to upower: > > https://gitlab.freedesktop.org/upower/upower/-/merge_requests/258 > > But that is intended for when there are 2 kbds with a controllable backlight, > e.g. a docked laptop with a gaming kbd with RGB backlight connected to the dock. > > Where as here we seem to have 2 controls which ideally should be set to > the same value if I understand things correctly ? Yes, there can be a HID device and a WMI device or multiple HID devices, and currently the driver is quirked to either select HID or WMI based on laptop model. There is also a deviation between how WMI is handled and how HID is handled. This way we unify all of it. In addition, on the Z13, we have a lightbar and a keyboard backlight (both HID/separate USB devices). And the keyboard is removable. On the Ally, we have a backlight but the controller disappears before sleep because WIndows does not support selective suspend for xinput. By placing the handler on WMI we ensure it is always active and the state does not get lost. > > Even when brightness controls are fixed, we still have the problem of the > > backlight key being on/off when controlled by KDE and 0/33/66/100 when > > the device has a WMI keyboard. Ideally, we would like the 0/33/66/100 to > > be done under hid as well, regardless of whether the backlight of the > > device is controlled by WMI or HID. > > Hmm, ideally we want this sort of policy to be in userspace, this sounds > more like it is a keycode problem and we maybe need KEY_KBDILLUMCYCLE next > to the existing KEY_KBDILLUMTOGGLE. For the existing toggle doing on/off > obviously is the correct userspace behavior. > > Anyways I can see how Asus is special here and on laptops the cycling is > typically handled by the EC and we have chosen to emulate EC behavior in > the kernel before to keep things consistent amongst models. > > Still generally speaking we do prefer to just send keypresses when possible > and let userspace set the policy, but I guess we can make an exception here. Yeah I agree with this, but now the WMI driver sets a bit of a precedent. > > Therefore, this is what the third part of this series does. It sets up > > asus-wmi to expose accepting listeners for the asus::kbd_backlight device > > and being the one that sets it up. Then, it makes hid-asus devices > > register a listener there, so that all of them are controlled by > > asus::kbd_backlight. Finally, it adds an event handler for keyboard keys, > > so that HID led controls are handled by the kernel instead of userspace. > > This way, even when userspace is not active the key works, and we get the > > desired behavior of 0/33/66/100 across all Aura devices (currently, that > > is keyboards, and embedded devices such as lightbars). This results > > removing the quirk system as well, eliminating a point of failure. > > I've taken a quick look at the new API between asus-wmi and asus-hid and > this looks good to me, thank you for your work on this. > > Regards, > > Hans > >
This is a three part series that does the following: first, it cleans up the hid-asus driver initialization, preventing excess renames and dmesg errors on ROG devices. Then, it adds support for the Z13 2025 keyboard, by fixing its keyboard to not be stuck in BIOS mode and enabling its fan key. Finally, the bigger piece of this series is the unification of the backlight controls between hid-asus and asus-wmi. This requires some context. First, some ROG devices expose both WMI and HID controls for RGB. In addition, some ROG devices (such as the Z13) have two AURA devices where both have backlight controls (lightbar and keyboard). Under Windows, Armoury Crate exposes a single brightness control for all Aura devices. However, currently in the linux kernel this is not the case, with asus-wmi and hid-asus relying on a quirk system to figure out which should control the backlight. But what about the other one? There might be silent regressions such as part of the RGB of the device not responding properly. In the Z13, this is the case, with a race condition causing the lightbar to control the asus::kbd_backlight device most of the time, with the keyboard being renamed to asus::kbd_backlight_1 and not doing anything under KDE controls. Here, we should note that most backlight handlers are hardcoded to check for backlight once, and for one backlight, during boot, so any other solution would require a large rewrite of userspace. Even when brightness controls are fixed, we still have the problem of the backlight key being on/off when controlled by KDE and 0/33/66/100 when the device has a WMI keyboard. Ideally, we would like the 0/33/66/100 to be done under hid as well, regardless of whether the backlight of the device is controlled by WMI or HID. Therefore, this is what the third part of this series does. It sets up asus-wmi to expose accepting listeners for the asus::kbd_backlight device and being the one that sets it up. Then, it makes hid-asus devices register a listener there, so that all of them are controlled by asus::kbd_backlight. Finally, it adds an event handler for keyboard keys, so that HID led controls are handled by the kernel instead of userspace. This way, even when userspace is not active the key works, and we get the desired behavior of 0/33/66/100 across all Aura devices (currently, that is keyboards, and embedded devices such as lightbars). This results removing the quirk system as well, eliminating a point of failure. I tested this on an Asus Z13 2025, and testing by other devices would be appreciated for sure. This series is designed to be transparent to userspace behavior-wise compared previous kernels, with all existing laptops either having the same behavior or being better. The Z13 keyboard folio RGB controls work beautifully, with KDE led notifications working and doing 0/33/66/100 as expected. This also happens with hotplugging, as the lightbar is always available and keeps the endpoint alive from boot, even if the folio is not connected (a quirk can be added later if there is a device where this is not the case). The first two parts of the series can also be merged independently of the third part, so we can iterate on that more. Perhaps there is a better way to handle this cohesion, Oh, by the way Luke, I developed this series with a variant of your Armoury series merged, and only switched to 6.14-v7 for this submission. You will be happy to know that there are no conflicts :) (at least with that version from ~January). Also, please factcheck my initialization sequence is correct in the 0x5d and 0x5e devices you added when you made that refactor last year. Are those handshakes needed? Antheas Kapenekakis (11): HID: asus: refactor init sequence per spec HID: asus: cleanup keyboard backlight check HID: asus: prevent binding to all HID devices on ROG HID: asus: rename keyboard3 to Z13_FOLIO HID: asus: add Asus Z13 2025 Fan key HID: asus: introduce small delay on Asus Z13 RGB init platform/x86: asus-wmi: Add support for multiple kbd RGB handlers HID: asus: listen to the asus-wmi brightness device instead of creating one platform/x86: asus-wmi: remove unused keyboard backlight quirk platform/x86: asus-wmi: add keyboard brightness event handler HID: asus: add support for the asus-wmi brightness handler drivers/hid/hid-asus.c | 220 ++++++++++++--------- drivers/hid/hid-ids.h | 2 +- drivers/platform/x86/asus-wmi.c | 137 +++++++++++-- include/linux/platform_data/x86/asus-wmi.h | 66 +++---- 4 files changed, 279 insertions(+), 146 deletions(-) base-commit: 4701f33a10702d5fc577c32434eb62adde0a1ae1