On jeu, 2008-08-07 at 01:33 -0400, Jim Paris wrote: > Hi Yves-Alexis, > > Thanks for the input. > > > I assume your x61 works the same as my T61 intel. > > > > The current status (aiui) is that, on 2.6.26 and previous, brightness > > won't work in-kernel. The only solution I found was to use > > gnome-power-manager and video.ko with parameter > > brightness_switch_enabled. In this case, it seems to work fine. > > Agreed. Just to be clear, I'm actually disabling it with > brightness_switch_enabled=false. Maybe that's what you mean? If you want control from userspace, yes. Maybe g-p-m should set it itself. > > > - After all this, brightness mostly works. There is still an issue with > > > plugging/unplugging the AC adapter. In single-user-mode: > > > > > > On AC: > > > # echo 0 > acpi_video1/brightness # dark > > > # echo 15 > acpi_video1/brightness # fully bright > > > Unplugged AC here # no change > > > # echo 15 > acpi_video1/brightness # no change > > > # echo 0 > acpi_video1/brightness # dark > > > # echo 15 > acpi_video1/brightness # --HALF-- bright > > > Plugged AC here # no change > > > # echo 15 > acpi_video1/brightness # no change > > > # echo 0 > acpi_video1/brightness # dark > > > # echo 15 > acpi_video1/brightness # fully bright > > > > > > Basically removing the AC adapter reduces the available brightness > > > range, BUT doesn't take effect until I actually try to change the > > > brightness. > > > > Check first in your bios the options for that. > > It works before Linux (grub prompt, etc) so the BIOS should be OK. > > The behavior (brightness range reduced on battery) is what I expect, > but it's buggy. Reducing brightness is probably a BIOS option but I > don't think "be slow in noticing it" is configurable :) Hmh yeah. Not really sure, maybe it'll settle down when fixes will be incorporated in the kernel. > > > > By the way, the Debian package "acpi-support" also sets up a > > > modprobe.d file containing: > > > options thinkpad_acpi hotkey=enable,0xffffbf experimental=1 > > > which I have removed. Another broken userspace package? > > > Apparently this file was placed here to fix problems on someone's > > > x60; this whole setup is so complicated it seems like it would > > > be an endless problem of fixing one laptop by breaking another. > > > > I guess it'd be nice if you could file bugs saying a package shouldn't > > mess with hotkey. > > Yeah I'd like to make sure I have the right solution before I file > bugs, though. As I mentioned it seems the hack was removed before, > and reinstated when someone complained that their x60 broke. Maybe > this is just a kernel version issue, and the hotkey mask should be set > for old versions and left alone for new versions? Aiui, a package should never touch hotkey mask. An user might want to, for his particular thinkpad, but that's all. At least if it mess with the hotkey, it should identify the running thinkpad. But basically, thinkpad-acpi loads the correct default for the thinkpad and one shouldn't mess with it. Or so I guess. Cheers, -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
