[lkml]   [2008]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Lenovo ThinkPads need acpi_osi="Linux"
    On Sat 2008-01-12 04:16:08, Len Brown wrote:
    > 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.

    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.

    (cesky, pictures)

     \ /
      Last update: 2008-01-13 18:01    [W:0.025 / U:7.204 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site