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. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
