| |||||||||||||
Writing a WMI driver - an introductionWriting a WMI driver - an introductionPosted Jun 10, 2010 10:25 UTC (Thu) by hadess (subscriber, #24252)Parent article: Writing a WMI driver - an introduction
How does one tie the UUIDs of the different objects in the DSDT to what they're supposed to do? Is it a load of guesswork?
(Log in to post comments)
Writing a WMI driver - an introduction Posted Jun 10, 2010 12:25 UTC (Thu) by iksaif (subscriber, #54284) [Link]
Yep, it is if you don't have any kind of documentation.
But the flags can help you (ACPI_WMI_METHOD, ACPI_WMI_EVENT).
A debug option was added to wmi.ko last month, the module will dump wmi informations on load, and it uses wmidump output format. So you don't have to search _WDG in your DSDT.
But even when you have found the correct UUID, you'll need to find/guess events code and methods id ...
Writing a WMI driver - an introduction Posted Jun 10, 2010 21:46 UTC (Thu) by cathectic (subscriber, #40543) [Link]
Basically, yes. Unless you can get your hands on the relevant MOF, which is a good step in the right direction in at least spelling out what the methods are for, even if it doesn't tell you the right arguments to pass (for newer Acer laptops, it was dug out of the Windows binaries using 'string').
One way I've used in the past was to use the Windows Kernel Debugger to trace ACPI and replicate the function calls.
In some cases, you can also guess based on the naming conventions used in the DSDT, and/ or seeing how arguments are handled when the are passed in.
|
|||||||||||||