>>> Could it be that using 95F24279-4D7B-4334-9387-ACCDC67EF61C is a mistake? >>> Or do you know of a machine which indeed uses this GUID to deliver sensor events? >>> Because it not, then we can just avoid this GUID conflict entirely by using the >>> other GUID. >>> >> No, it's not a mistake, it's HP reusing GUIDs. Both my test machines use >> 95F24279-4D7B-4334-9387-ACCDC67EF61C for \\.\root\WMI\HPBIOS_BIOSEvent. >> >> Previously I examined a sample of ACPI dumps from machines with both >> hpqBEvnt and HPBIOS_BIOSEvent, and concluded: >> >> - hpqBEvnt is for various events on both business and non-business >> machines that are of no interest to hp-wmi-sensors (e.g. hotkeys) >> >> - some machines with hpqBEvnt also have HPBIOS_BIOSEvent at GUID >> 2B814318-4BE8-4707-9D84-A190A859B5D0 >> >> - no machines with both hpqBEvnt and HPBIOS_BIOSEvent actually surface >> relevant sensor events (e.g. fan speed too high) via HPBIOS_BIOSEvent; >> they only surface non-sensor events (e.g. BIOS setting was changed) >> that are of no interest to hp-wmi-sensors >> >> - therefore, 2B814318-4BE8-4707-9D84-A190A859B5D0 does not need to be >> handled in hp-wmi-sensors >> >> But this time I have done an exhaustive examination and concluded that a >> few machines with both events do surface sensor events via HPBIOS_BIOSEvent. > > This would have interesting implications for the WMI subsystem. Can you send me > the output of "acpidump" on those test machines? > > It also seems that there are machines which do use the other GUID, see here: > https://github.com/lm-sensors/lm-sensors/issues/471 (acpidump at the bottom) Here are examples of machines in the Linux Hardware Database with HPBIOS_BIOSEvent at 95F24279-4D7B-4334-9387-ACCDC67EF61C: Compaq 8100 Elite SFF PC EliteDesk 800 G1 SFF Z400 Workstation https://github.com/linuxhw/ACPI/blob/master/Desktop/Hewlett-Packard/Compaq/Compaq%208100%20Elite%20SFF%20PC/AB6EADEE22B9 https://github.com/linuxhw/ACPI/blob/master/Desktop/Hewlett-Packard/EliteDesk/EliteDesk%20800%20G1%20SFF/F13506CA489E https://github.com/linuxhw/ACPI/blob/master/Desktop/Hewlett-Packard/Z400/Z400%20Workstation/FF7C21B8CB39 Here are examples of machines that have hpqBEvnt and HPBIOS_BIOSEvent at 95F24279-4D7B-4334-9387-ACCDC67EF61C and 2B814318-4BE8-4707-9D84-A190A859B5D0 but do not surface sensor events via HPBIOS_BIOSEvent. See PEVT and how it dereferences into CBWE, which is HPBIOS_PlatformEvents giving information about the types of _WED/HPBIOS_BIOSEvent that may occur: ZBook 2015 G4 ZBook Studio G5 https://github.com/linuxhw/ACPI/blob/master/Notebook/Hewlett-Packard/ZBook/ZBook%2015%20G4/89F9520CDC60 https://github.com/linuxhw/ACPI/blob/master/Notebook/Hewlett-Packard/ZBook/ZBook%20Studio%20G5/39AAE603D78B An example of a machine that has hpqBEvnt and HPBIOS_BIOSEvent at 95F24279-4D7B-4334-9387-ACCDC67EF61C and 2B814318-4BE8-4707-9D84-A190A859B5D0 and does surface sensor events via HPBIOS_BIOSEvent is the ProDesk 405 G6 from https://github.com/lm-sensors/lm-sensors/issues/471 in your previous message. I found a reason to reply to the GitHub issue with the decompiled ASL for easy reference. See PEVT and how it dereferences into EVNT, which is HPBIOS_PlatformEvents giving information about the types of _WED/HPBIOS_BIOSEvent that may occur. Currently hp-wmi-sensors would not recognize that this BIOS supports reporting alarm and intrusion events. And finally, a machine that embodies "weird behavior from a HP BIOS". It has hpqBEvnt and HPBIOS_BIOSEvent at 95F24279-4D7B-4334-9387-ACCDC67EF61C and 2B814318-4BE8-4707-9D84-A190A859B5D0, and has HPBIOS_BIOSNumericSensor at 8F1F6435-9F42-42C8-BADC-0E9424F20C9A. However, it looks like it just defines these in BMOF without providing any instances during runtime, or maybe it generates them in some convoluted non-obvious way: ZHAN 99 Mobile Workstation G1 https://github.com/linuxhw/ACPI/blob/master/Notebook/Hewlett-Packard/ZHAN/ZHAN%2099%20Mobile%20Workstation%20G1/CB1EEAC36F91 >>>>> I thing it would be best to create a separate WMI driver for the event and >>>>> use a notifier chain (see include/linux/notifier.h) to distribute the event data. >>>>> >>>>> In case of event GUID 95F24279-4D7B-4334-9387-ACCDC67EF61C, both hp-wmi and >>>>> hp-wmi-sensors can subscribe on this notifier and receive event data without >>>>> stepping on each other's toes. >>>>> >>>>> The same can be done for the event GUID 2B814318-4BE8-4707-9D84-A190A859B5D0, >>>>> with a separate notifier chain. >>>>> >>>>> This would decouple the event handling from the event data consumers, allowing >>>>> both hp-wmi and hp-wmi-sensors to coexist. >>>> No objections from me for this specific use case to work around the GUID conflict. >>>> hp-wmi-sensors should indeed subscribe on 2B814318-4BE8-4707-9D84-A190A859B5D0 >>>> for some of those machines. >>>> >>>> Any ideas for getting rid of wmi_query_block() for fetching >>>> \\.\root\HP\InstrumentedBIOS\HPBIOS_PlatformEvents? I know other drivers are >>>> also using it for getting blocks other than their "main" GUID. >>> Good question, it seems that HPBIOS_PlatformEvents is optional, so using the component >>> framework will not work. >>> >> Yes, HPBIOS_PlatformEvents is optional, but it's pretty much necessary for >> alarm and intrusion events. Without it, it's not possible to know whether a >> machine even reports such events until after they occur (rare). We'd have >> to assume that all machines always support such events. >> >>> If those WMI data blocks are always associated with the same ACPI device used by the >>> sensors GUID, then maybe i could create some sort of API for checking if a given GUID >>> exists the ACPI device associated with a WMI device. >> For all HP machines in the Linux Hardware Database, all machines with >> HPBIOS_PlatformEvents also have HPBIOS_BIOSNumericSensor. The reverse is >> not true. Neither WMI object appears under multiple GUIDs. >> >>> However i thing the event GUID issue is more important right now. >> Sure. I also wonder if your idea could be expanded into a generic driver >> for publishing simple WMI events. This would be usable in other drivers >> that are currently using legacy handlers for receiving event data. > > You are completely right, this driver could allow clients to register a > notifier block for a event identified by a GUID, and this notifier block > is then called every time this event is received. > >> More broadly, if hp-wmi-drivers is any indication, aggregate WMI devices >> could be a pain. Primary WMI object, associated WMI objects (optional or >> mandatory), multiple aggregate devices allowed to bind to the same >> objects. And if using GUIDs for identification, multiple allowable GUIDs. > > I agree, part of it stems from many OEMs designing their interfaces in such > a way that it is impossible to discover if some optional features are present. > > I suspect this happens because under Windows, the OEMs just check all GUIDs > once the system has "finished booting" (aka reached the login screen), and > this is afaik not possible with device drivers. > > However we cannot export WMI method/events/etc to userspace, as this would > be a security nightmare (random RPC with buggy ACPI firmware, yay!). Interesting info here. I assumed they just worked with string names for objects and properties and didn't care about GUIDs. > In the future we might need an API for at least discovering and interacting > with WMI devices backed by the same ACPI device, however this might take some > time. > > I will focus on this WMI event driver for now. Looking forward to it. Maybe tell platform-driver-x86 about it too. Thanks, James
