Hi,
On Sun, 2008-01-20 at 17:49 -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 19 Jan 2008, Theodore Tso wrote:
> > Sure, and that means they have to *tell* *us* what they are doing so
> > we can be compatible with Windows. The concern is that they may be
> > doing stuff that isn't in the standard ACPI spec, but which needs to
> > be a certain way in order to be compatible with their proprietary
> > Windows drivers.
>
> Or to be compatible with both Windows XP and Vista ACPI subsystems, *and*
> the Windows XP and Vista versions of their proprietary drivers. This is
> probably where half the weirdness in Lenovo ThinkPads come from, IMHO.
The problem is that OSI is used by Windows to pass the exact Windows
(not OS) version they are running, this function should be called WOSI.
We of course want to run on the latest fix-ups here and should pass
"Windows 2006" (or whatever latest string there exists).
IMO we need the same for Linux.
We even have the advantage, that the string in LOSI(String) makes some
sense, e.g. 2.6.24, so why not use LOSI(int, int, int)
How the exact interface might look like I am not sure, just an idea.
> > The real problem comes when they decide to do things in a rush. That
> > is, Dell deciding they want to make their laptops compatible with an
> > already existing Ubuntu kernel, or Lenovo deciding they want to make
> > their laptops compatible with an already existing SUSE kernel. And,
> > so they decide to do a quick and dirty firmware release rather than
> > negotiating with the distribution to do an Errata kernel. If we don't
> > agressive move to nip this in the bud, even if a particular Thinkpad
> > kernel isn't in the whitelist, I can see them simply documenting a
> > workaround of setting acpi_osi=Linux in the boot command line, because
> > it's easier than getting a distro to release a new kernel with a patch
> > needed to support some new laptop....
>
> Well, in defense of Lenovo, at least they seem to be quite open to changing
> future BIOSes if we are really clear on what we request *and* we provide a
> solution that won't cause total breakage on the kernels already in the Wild.
>
> But asking any hardware vendor to do something that will work right with the
> next version of Linux but will break hideously what distros have been
> shipping already just won't fly. Anything we do has to work well on both
> past and current kernels, unfortunately.
I disagree.
AML is a whole language, you can add stuff like:
if (losi < 2.6.24)
Store (0x1, ecxy)
else if (losi > 2.6.25)
Store (0x3, ecxy)
A)
Vendors *must* have a flag for Linux to be able to provide proper
support for multiple kernels and to be able to provide easy and riskless
fixes for Linux at all.
B)
ACPI interpreter patches are mostly very intrusive and distros cannot
backport them. E.g. you don't want to add an EC fix which fixes all ASUS
machines, but possibly breaks some others..., you don't want to backport
suspend reordering, or a simple sizeOf (part of AML) enhancement which
fixes some machines, might break some very other specific ones. You
should nearly never ever backport an AML fix, better let vendors do
kernel specific workarounds if they are willing to.
I expect we now have this problem because nobody (including myself)
never dreamed of that it could ever happen that a vendor adds Linux
specific AML code.
But now that it happens we should react quickly and come up with a
robust interface for the future...
> Now, the real test will be if we ask for something that would require
> changing their Windows drivers. I sure hope they would do it, but...
Yep nobody would ever do this.
But it's no problem for vendors at all to add a hotfix like that to
their BIOS:
if (linux)
..
else if (windows)
..
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
