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? > > - Gnome-power-manager saw the hotkeys but didn't change the > > backlight. > > When using video.ko, you need the brightness_switch_enabled for the > event to be passed userspace. I'm not sure how they are passed since > wether or not brightness_switch_enabled is enabled (:) we see something > in /proc/acpi/events. >From what I determined, it's an ACPI event generated by video.ko that gets picked up by acpid, and passed to userspace as KEY_BRIGHTNESSUP/KEY_BRIGHTNESSDOWN using acpi_fakekey. I didn't notice that brightness_switch_enabled caused any difference in how things got passed to usespace -- it only affects whether the value in /sys/class/backlight/acpi_video*/actual_brightness changes by the kernel when you press the hotkey. > > - 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 :) > > 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? -jim ------------------------------------------------------------------------- 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
