On Mon, 31 Dec 2007, Theodore Tso wrote: > On Mon, Dec 31, 2007 at 07:24:40PM -0200, Henrique de Moraes Holschuh wrote: > > No bugs, then. It is a Lenovo BIOS issue. Which doesn't mean we can't do > > anything about it (besides asking Lenovo for a fix), but I am not sure of > > what. > > > > It is probably best if thinkpad-acpi switches the ThinkPad to ACPI > > brightness mode, and report this on syslog... but I have to think about it > > first, and ask around for a bit. > > Wouldn't it just be better to disable both the ACPI brightness > altogether (for both the thinkpad-acpi and video modules), and use > xbacklight instead? To quote from http://www.lesswatts.org/tips/graphics.php: That's exactly what I mean. When one switches the thinkpad (Lenovo new BIOS ONLY, the older ones simply do not have this functionality) to ACPI mode, the BIOS/AML just issues the standard ACPI brightness change *request* events, and doesn't do anything else. So, if thinkpad-acpi would place the thinkpad in ACPI brightness mode, it could still not export the backlight interface, and xbacklight could be used instead, hooked to something that listen to acpi events (hal, acpid or even xorg itself). It would be a trivial change: I'd just change the way thinkpad-acpi detects the ACPI support to use _BCL, and add a printk. Now, if one does load ACPI video.c, one has to tell that driver to hands off the active brightness changes. But that's outside my direct control. > brightness of the LCD panel. Unfortunately, these often use > model-specific drivers that are only available for other operating I'd even add: "It can be even worse. Some laptops use SMBIOS SMI mode routines that change directly the hardware, with no override capabilities (all reasonably new IBM thinkpads)". > Interestingly, in our measurements we have found that, at least on > newer laptops, the kernel sysfs method (which tends to use the > BIOS on the machine) seems to not control the actual backlight, > but rather change the colors of the pixels on the screen to appear > darker. Using darker pixels obviously doesn't save as much power > as reducing the intensity of the backlight. I have no idea if that's what happens in thinkpads (probably depends on GPU model...). > So if you have an Intel graphics card for your thinkpad, it's not > clear that any solution involving the BIOS is the right one.... I'd say we should get away from the SMBIOS as much as we can. But that does mean the framebuffer drivers need to start being cared for a lot more, or the console will become a second class citizen. IMHO, this means we need to actually stop and think up a proper, *complete* backlight interface that allows userspace to really understand and control what is happening, let it know which entry drives which physical device, which one to use if there are multiple entries for the same physical device, and make the entire interface a full read/write, shadow concurrency-aware API at the kernel side, instead of assuming "simple devices" where you don't have X.org or the SMBIOS poking at the hardware behind your back. -- "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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
