On Sunday 31 August 2008 19:25:47 Matthew Garrett wrote:
Of course we should, therefore it is called guidline for *Linux*.
Everything recommended there should just work fine on Linux.
E.g. it is all about implementation details, which differ from
the ACPI spec (and WMI clearly does) and all other kind of pits you
can fall in with ACPI on Linux.
Half a year ago we couldn't serve any WMI devices.
Until WMI autoloading is available in stable distributions it still takes
at least half a year.
E.g. that is why video posting after suspend should still
work until modesetting works in kernel.
If there would be enough time, I'd add that Intel graphics
Op Region support is partly (only backlight, not video output, right?)
implemented and this support is scheduled to be added for .28
(didn't make it into .27?).
This is IMO what should get documented, like that vendors can
count on what works on which distribution based on which kernel
(without going throug kernel sources, which is impossible for
BIOS writers, they have to rely on some things written down).
-- Be careful ad in between --
E.g. look at that machine coming with Linux:
http://www.engadget.com/2008/08/31/msis-8-9-inch-wind-u90-in-the-flesh-linux-version-s...
and have a look at that green sticker:
http://www.engadget.com/photos/msis-8-9-inch-wind-u90-in-the-flesh-linux-version-shipp...
That means it is shipped with a 2.6.16 kernel without any WMI support.
-- Be careful ad in between --
I don't want to go that far back, but start from now on.
Vendors should be able to
read out from which kernel version they can rely on what kind of
ACPI implementations/features.
If something is not supported in a Linux version or has "out of spec"
or say "Windows compatibility" relevant implementations introduced, you should
find it there.
The latter info is rather important for non-Microsoft machines, or e.g. using coreboot
BIOSes (AFAIK they also start to hack in the first ACPI tables).
Thomas
PS: I agree that if WMI works now since kernel xy, this should be documented.
It would be great if you could send a patch against the guidline describing
what kind of WMI support came in and in which kernel version. And for what pits vendors
still have to take care for (I am sure there still are some).
(from git commit):
What it won't do:
Unicode - The MS article[1] calls for converting between ASCII and Unicode (or
vice versa) if a GUID is marked as "string". This is left up to the calling
driver.
Handle a MOF[1] - the WMI mapper just exports methods, data and events to
userspace. MOF handling is down to userspace.
Userspace interface - this will be added later.
-------
AFAIK MOF files are and will be for long term or ever not
be used in Linux at all? This is the connection to CIM?
Should this be docuemented?
--
