Lenovo ThinkPads need acpi_osi="Linux"
Henrique de Moraes Holschuh
that the Lenovo BIOSes need the OSI string Linux defined to behave properly
in Linux.
Lenovo has been attempting to make things a bit easier for Linux on their
ThinkPads, by disabling the more obnoxious behaviours of the firmware (used
by their Windows drivers) when in Linux. It looks like they used the OSI
string for that.
It is probably worthwhile to give a head's up: regressions involving
thinkpads and 2.6.23+ should probably have a 'please test with
acpi_osi="Linux"' step added if there is any chance ACPI AML code, BIOS or
SMBIOS code, or EC behaviour could be involved.
The most concrete example I have right now of changed behaviour is the Mute
key on the T61, which just plain disappears if acpi_osi="!Linux" (2.6.23
default).
I have also seen some hacked DSDTs around (mostly for older T4x models)
which used the Linux OSI string to fix or work around AML weirdness. Those
would break in 2.6.23 (and 2.6.24?) as well.
Now, what should we do about it? Add a quirk to always define the Linux OSI
string on ThinkPads (based on DMI information)? All IBM ones (which won't
have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones
seem to benefit from it.
We could also ask Lenovo to change the BIOS to stop paying attention to that
OSI string, but they will likely want/need a trigger for the AML code to
know it should change behaviour anyway, and the OSI string *does* look like
the proper thing to use IMHO. I don't know if we could get them to arrive
to a behaviour that is acceptable both to us, and also to their Windows
drivers...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Len Brown
I discussed this with Lenovo a few months ago
and made it clear that Linux will unlikely
default to answer yes to OSI(Linux) in the future --
for all the reasons I stated when I disabled it.
However, they told me they wanted to use OSI(Linux)
to enable the backlight (via video re-post) on S3 resume,
and the problem at hand was a distro kernel which still
had OSI(Linux), so that is what they did.
I was unaware that they're using it for anything else,
and the fact that they are lends further support to
the case that as an OS interface string "Linux"
is too vague to be meaningful.
They seemed open to looking for another string, say
"Needs S3 video re-post". However, we didn't
agree on such a string, and so it isn't in Linux
or the Lenovo BIOS.
I think until we have native Linux graphics driver for (fast)
backlight restore, we need to add a DMI to enable OSI(Linux)
for the offending Lenovo models. We'll need to have
some coordination with the graphics guys so that they
can turn this off from user-space when they don't need it.
The reason it shoudl be turned off is that backlight enabling
backlight from a native graphics driver is much faster than running
through the video BIOS POST. So if we keep the OSI(Linux)
video BIOS POST workaround in place permanently, it would
put Linux at a permanent performance disadvantage to Windows.
cheers,
-Len
Alan Cox
> string on ThinkPads (based on DMI information)? All IBM ones (which won't
> have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones
> seem to benefit from it.
If Lenovo systems do the right thing then I guess submit a patch which
checks for a DMI identifier string for Lenovo and if so don't lie to the
ACPI interpreter.
Alan
Henrique de Moraes Holschuh
> > Lenovo has been attempting to make things a bit easier for Linux on their
> > ThinkPads, by disabling the more obnoxious behaviours of the firmware (used
> > by their Windows drivers) when in Linux. It looks like they used the OSI
> > string for that.
[...]
> > The most concrete example I have right now of changed behaviour is the Mute
> > key on the T61, which just plain disappears if acpi_osi="!Linux" (2.6.23
> > default).
[...]
> I discussed this with Lenovo a few months ago
> and made it clear that Linux will unlikely
> default to answer yes to OSI(Linux) in the future --
> for all the reasons I stated when I disabled it.
>
> However, they told me they wanted to use OSI(Linux)
> to enable the backlight (via video re-post) on S3 resume,
> and the problem at hand was a distro kernel which still
> had OSI(Linux), so that is what they did.
>
> I was unaware that they're using it for anything else,
> and the fact that they are lends further support to
> the case that as an OS interface string "Linux"
> is too vague to be meaningful.
>
> They seemed open to looking for another string, say
> "Needs S3 video re-post". However, we didn't
> agree on such a string, and so it isn't in Linux
> or the Lenovo BIOS.
>
> I think until we have native Linux graphics driver for (fast)
> backlight restore, we need to add a DMI to enable OSI(Linux)
> for the offending Lenovo models. We'll need to have
> some coordination with the graphics guys so that they
> can turn this off from user-space when they don't need it.
Unless we get them to lay off using OSI(Linux) altogether, that won't work
well. You'd stop the slow POST on S3 resume, but you'd also change the
behaviour of the firmware somewhere else too (not to mention it is useless
to change the OSI string in most AML code I've seen after you ran the _INI
stuff).
It would have been way easier if ACPI had a more complete and thought-out
video control API. There should be a way to request a BIOS re-post of the
video hardware through an optional ACPI call.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Pavel Machek
Hmm, they should not need to do anything.
When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they
should turn on backlight and put video into text mode. They should
also make sure mode setting works after that.
I don't see how ACPI fits into this picture, and I think it can work
well without ACPI tricks.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Henrique de Moraes Holschuh
> > The reason it shoudl be turned off is that backlight enabling
> > backlight from a native graphics driver is much faster than running
> > through the video BIOS POST. So if we keep the OSI(Linux)
> > video BIOS POST workaround in place permanently, it would
> > put Linux at a permanent performance disadvantage to Windows.
>
> Hmm, they should not need to do anything.
>
> When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they
> should turn on backlight and put video into text mode. They should
> also make sure mode setting works after that.
IMHO, in that case, we should probably be whitelist-enabling that on
thinkpads (and allow for acpi_sleep=none to override it), or letting
userspace change it at runtime.
> I don't see how ACPI fits into this picture, and I think it can work
> well without ACPI tricks.
It fits because Lenovo did it in ACPI (or used to do it in ACPI, whatever).
We can ask them to not do it, I suppose. But without some sort of
autodetection on our part, I doubt they will remove it.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Matthew Garrett
> On Sun, 13 Jan 2008, Pavel Machek wrote:
> > When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they
> > should turn on backlight and put video into text mode. They should
> > also make sure mode setting works after that.
>
> IMHO, in that case, we should probably be whitelist-enabling that on
> thinkpads (and allow for acpi_sleep=none to override it), or letting
> userspace change it at runtime.
No. This breaks on the R50e, at least - I suspect it'd also have
problems on any nvidia based machines, but I don't have one to hand at
the moment. It can be set at runtime already.
--
Matthew Garrett | mj...@srcf.ucam.org
Henrique de Moraes Holschuh
> On Mon, Jan 14, 2008 at 12:35:54AM +0000, Matthew Garrett wrote:
> > No. This breaks on the R50e, at least - I suspect it'd also have
> > problems on any nvidia based machines, but I don't have one to hand at
> > the moment. It can be set at runtime already.
>
> not going to want the low-level ACPI code to do anything video-related
> on a lot of hardware. The in-kernel modesetting code for Intel machines
> will be able to handle this significantly more effectively.
Yeah, but we have a ton of machines (thinkpads among them) with ATI, and
other GPUs.
Whitelists would need to be reasonably specific, anyway (not "all
thinkpads"), so it just means "don't do it on certain R50e", or whatever.
It is no easy problem, and the fix might not be as simple as one could wish,
either.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Matthew Garrett
> On Mon, 14 Jan 2008, Matthew Garrett wrote:
> > not going to want the low-level ACPI code to do anything video-related
> > on a lot of hardware. The in-kernel modesetting code for Intel machines
> > will be able to handle this significantly more effectively.
>
> Yeah, but we have a ton of machines (thinkpads among them) with ATI, and
> other GPUs.
The ATI case is certainly more of an issue, but I'm becoming more
optimistic about that being workable in the near future - certainly on
machines with ATOM-based BIOSes.
> Whitelists would need to be reasonably specific, anyway (not "all
> thinkpads"), so it just means "don't do it on certain R50e", or whatever.
I'd prefer not to push this policy into the kernel, since the right
thing to do depends on which graphics drivers you're using and so on.
Userspace is in a better position to make this determination. Of course,
this also means not passing the Linux OSI to the firmware. Our hardware
interaction is sufficiently in flux that any attempt to work around it
in the firmware is just going to lead to bizarre breakage down the road.
--
Matthew Garrett | mj...@srcf.ucam.org
Henrique de Moraes Holschuh
> Userspace is in a better position to make this determination. Of course,
That's fine with me.
> this also means not passing the Linux OSI to the firmware. Our hardware
> interaction is sufficiently in flux that any attempt to work around it
> in the firmware is just going to lead to bizarre breakage down the road.
The Linux OSI string does more. I just found out that it also drives the
MUTE key behaviour (and you want the behaviour *with* the Linux OSI string
loaded).
Some of the behaviours are actually linux-version agnostic. E.g. we'll
always prefer that the Mute key send a KEY_MUTE event over the keyboard
controller *without* touching the hardware (which is what it does if the
Linux OSI string is *present*) in ThinkPads where there is no
firmware-specific mixer hardware (i.e. the T61 and probably X61). For such
uses, the OSI string is fine.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh