Hi,

while arguing about current _OSI Linux implementation,
I realized this is complex and absolutely undocumented.

I started to write this up properly.
This was the point when I realized adding
some major general ACPI things OEMs should consider on
Linux is urgently missing and should get published.

Many thanks to Andi Kleen and Pavel Machek who already
reviewed an early version some weeks ago. I still changed
a lot since then (also corrected a lot considering your
corrections, thanks it probably was a lot work going through
this that detailed!).

I like to get as much feedback for this as possible.
Be sure I will go through this attentively and add or
modify whatever makes sense.

I mainly try to get feedback from OEMs and BIOS developers,
I am going to and I also like you to point to this. They
are the main audience for this paper.
Currently OEMs start to take care or at least look at Linux
for the future even in the laptop area (this is why every latest
ACPI BIOS checks whether Linux is running...).
This should give them a documentation and an overview for
what they should take care for. Until a BIOS hits the
customer takes a lot time, so they need stability and a
general policy they can count on.

You find the paper here:
ftp://ftp.suse.com/pub/people/trenn/ACPI_BIOS_on_Linux_guide/acpi_guideline_for_vendor...

At the end are the sources of the original document for
better commenting of special parts of the document.

I am looking forward for a lot feedback.

Thanks,

            Thomas


\documentclass[10pt,a4paper]{article}

\usepackage{hyperref}
\usepackage[numbers]{natbib}

\title{ACPI BIOS Guideline for Linux}
\author{Thomas Renninger - Copyright SUSE Linux GmbH, 2008}


\begin{document}
\maketitle

\begin{abstract}
This specification is intended for PC hardware vendors and PC BIOS
developers. It documents and describes ACPI implementations of the
Linux kernel which are important for BIOS developers. Irregularities
to the ACPI ...
[ message continues ]

It is not an ACPI specification violation that Linux
(and ACPICA) claim compatibility with the interfaces
advertised by one or multiple versions of Windows.

Yes, there are be cases where BIOS vendors will want
to know if the running version of Linux supports,
or does not support, an interface/feature.

We (the Linux community that maintain Linux/ACPI) are
eager to support them in this.  However, the interface
needs to be sufficiently defined so that we know when
to _not_ advertise that feature.

eg. There are proposals for

_OSI("Linux-Needs ATI S3 video re-POST")
_OSI("Linux-Needs NVIDIA S3 video re-POST")
_OSI("Linux-Native IPMI Support")

and we'd compile these into Linux based on the capabilities
of the build.  I'm sure that these would not be perfect --
as the BIOS would probably query these at _INI time before
the (likely loadable module) drivers that influence these
features would be loaded.  So we'd probably have to build
them into the core based on the assumption that the driver
built with the core will actually get loaded.

But this is the kind of Linux-specific OSI string we can advertise,
and choose not to advertise -- depending on the build.

thanks,
-Len
--

[ message continues ]

Great!
Please add me to CC as soon as you agreed to something and
I'll pick those up.

Thanks,

       Thomas
--

[ message continues ]

Perhaps it would be more useful to suggest to vendors/ BIOS writers what they 
should use here instead?

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
--

[ message continues ]

They can use their own devices.
There is a section about if you provide your own device, document it, etc.:

2 Vendor specific ACPI implementations
...
2. If new devices or functions are introduced, document how to use them. A
   short specification or a request for comments (RFC) can form the basis of
   a new standard which follows your needs.


But yes, it could be pointed out clearer.
I'll look closer at it when I touch it the next time.
Text snippets/suggestions are also appreciated.

Thanks,

     Thomas
--

[ message continues ]

A documented WMI interface is easier to use than an entirely custom 
documented interface, and reduces the amount of work the vendor has to 
do in Windows. To be honest, I think it's the sort of thing we should be 
encouraging.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

IMO WMI should not exist.
A lot laptop BIOSes do not use it at all, unfortunately it seems to get
more common again.
What advantage do you get on Linux using WMI?

For example HP is using WMI to export a WLAN (or bluetooth?) button on
some machines.
They should not do that, right?

AFAIK most vendors tend to send an ordinary key event again for most
extra buttons. Is this the way to go for the future? This probably
should also be mentioned then.

    Thomas
--

[ message continues ]

Little. But what advantage do we get in the same functionality being 

The HP wlan button is a hardware event. There's no need for it to be 
sent via the keyboard controller. Some of the other keys would be easier 
to deal with if they were sent via the keyboard controller, yes, but 
that's not the full set of what the WMI functionality gives us. How do 
you want kill switches to be controlled? I'd be happier with it being 

Some vendors do, and I agree that it's preferable.
-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

It is all about documentation, right.

Feel free to send text snippets, e.g. about the preferable way of key events.
Best a diff against the .tex file, but I can do the work and integrate it, np.

Thanks,

      Thomas
--

[ message continues ]

Not really. It provides approximately no complexity for Linux drivers, 
and makes it easier for vendors to provide Windows support. WMI has not 
been the hard bit of the drivers I've written. I don't see any reason to 
ask vendors not to use it, as long as they're willing to document their 
implementation.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

Autoloading does not work yet?
I'll point that out, something like:
If you really have to use WMI for Windows compatibility reason, make
sure the important parts (is there already something to mention?
Against what is the driver loaded -> autoloading?) are documented well.

      Thomas
--

[ message continues ]

That's an implementation detail. We shouldn't be making recommendations 

There's no valid reason to suggest that vendors use an entirely custom 
solution over using WMI. In some ways, reverse engineering is easier - 
we can see all the entry points. But yes, vendors who want to support 
Linux should document their firmware interfaces.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

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 ...
[ message continues ]