Bug 391601

Might be a kpowersave bug.  In F7 I used klaptop instead, which doesn't seem to
be available in F8.  I deliberately disabled kpowersave in F7 for some reason,
but I don't remember what it was.  I'll check this out...

This is strange, because acpid doesn't do anything with a backlight (unless you
wrote your own script in /etc/acpi/events/). I tried to reproduce this bug on
same model, but I was unsuccessfully. I tried many different orders of a
execution of acpid/kpowersave/hald, but it works always. 

Do you have set default settings for a kpowersave? Maybe a kpowersave sets the
high backlight because of those settings.

One of another possible solution is upgrade BIOS (some ASUS laptops have to
update BIOS, otherwise changing backlight doesn't work). Nice utility for
display what thinkpad buttons do, is called "tpb", so try to install it too and
you'll see what happen.

The default BIOS setting is to lower the backlight level when running on
battery.  I disabled this, and it works somewhat more reliably, but I think
there's still a race between acpid and kpowersave.  I'm currently using
non-default kpowersave settings.  I have set it to not change brightness when
running on battery, though it remembers whatever backlight setting each state
was manually set to with the buttons.

I just tried to re-enable acpid for another test, and got this:

# service acpid start
Starting acpi daemon: acpid: can't open /proc/acpi/event: Device or resource busy
                                                           [FAILED]

Clearly something is conflicting...

# lsof | fgrep /proc/acpi/event
hald-addo  2365 haldaemon    4r      REG                0,3        0 4026531940
/proc/acpi/event

So, it seems hal is doing something uncool here.

Yea, I know about this. It is caused by this: if hald don't recognize that some
application is listening on /proc/acpi/event, then will start listening by self.
And then, if you try to run apcid, you get this conflict. But if you start acpid
before hald, then acpid starts listening on /proc/acpi/event, hald will
recognize it and starts listening on acpid socket /var/run/acpid.socket and
there is no conflict. For the first time, you have to kill a process, which is
listening on /proc/acpi/event (some hald-addon-acpi) to start acpid properly.
Every time after this step, acpid will start first and there is no more conflict.

But I'm not sure, if this solve something.

Does changing the brightness work via /proc/acpi/ibm/brightness? If you haven't
tried it, please do this:

echo "level <num>" > /proc/apci/ibm/brightness, where <num> is 0..7

And what driver do you use in the /etc/X11/xorg.conf? If you use radeonhd, then
this driver breaks changing brightness, it is known bug
(http://wiki.x.org/wiki/radeonhd#head-d0cfd39d1b149a43f0c1d862f21f4b3ddcb43ae2)

I was having the same issue with my T60 as well (Intel graphics chipset).

I found another entry in the Redhat bugzilla as well that describes the issues I
was seeing as well, but turning off acpid did fix the problem for me as well.

What is the importance of acpid these days? is it still useful for it to be run?

https://bugzilla.redhat.com/show_bug.cgi?id=363261
http://bugzilla.gnome.org/show_bug.cgi?id=483428

It is useful in cases, that you don't have some desktop environment (gnome,
kde,...). In these environment usually are some power-managers or something
which catches acpi events or watching DBus. But if you do not have a desktop at
all or you want to specify special action on some function key, your only choice
is acpid.

Anyway it's strange. Because I have T60 with ATI card, but everything work fine
even with acpid (X driver vesa or fglrx).

Working fine in F9.  Never got it straightened out in F8.

Ok, I'm closing this bug.