LKML Archive on
help / color / mirror / Atom feed
From: Len Brown <>
To: Henrique de Moraes Holschuh <>
Subject: Re: Lenovo ThinkPads need acpi_osi="Linux"
Date: Sat, 12 Jan 2008 04:16:08 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Friday 11 January 2008 21:23, Henrique de Moraes Holschuh wrote:
> While helping a user find out what happened to his mute key, I found out
> 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...

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.


  reply	other threads:[~2008-01-12  9:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-12  2:23 Lenovo ThinkPads need acpi_osi="Linux" Henrique de Moraes Holschuh
2008-01-12  9:16 ` Len Brown [this message]
2008-01-12 20:23   ` Henrique de Moraes Holschuh
2008-01-13 16:58   ` Pavel Machek
2008-01-13 23:41     ` Henrique de Moraes Holschuh
2008-01-14  0:35       ` Matthew Garrett
2008-01-14  1:50         ` Matthew Garrett
2008-01-14  1:57           ` Henrique de Moraes Holschuh
2008-01-14  2:03             ` Matthew Garrett
2008-01-14 13:06               ` Henrique de Moraes Holschuh
2008-01-12 15:49 ` Alan Cox
2008-01-14  0:10 ` Henrique de Moraes Holschuh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).