This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 391601 - acpid breaks thinkpad T60 backlight controls
acpid breaks thinkpad T60 backlight controls
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: acpid (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Zdenek Prikryl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-20 02:22 EST by Chris Snook
Modified: 2008-08-14 02:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-14 02:44:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chris Snook 2007-11-20 02:22:45 EST
Description of problem:
When acpid is enabled, backlight buttons on my T60 are ignored or quickly reset,
except occasionally I can get it into one low setting.

Version-Release number of selected component (if applicable):
acpid-1.0.6-3.fc8

How reproducible:
90%

Steps to Reproduce:
1. Install F8 x86_64 on Thinkpad T60
2. Use backlight controls
  
Actual results:
Usually the backlight buttons are totally ignored.  Sometimes they're
momentarily honored and then reset.  Occasionally I can get it into a certain
low setting, but if I try to raise or lower it, it goes back to full power.

Expected results:
Backlight controls just work, as they did in F7.

Additional info:
Disabling acpid fixes this problem.
Comment 1 Chris Snook 2007-11-20 13:54:11 EST
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...
Comment 2 Zdenek Prikryl 2007-11-22 06:27:45 EST
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.
Comment 3 Chris Snook 2007-11-26 12:00:23 EST
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.
Comment 4 Chris Snook 2007-11-26 12:18:31 EST
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.
Comment 5 Zdenek Prikryl 2007-11-28 02:34:04 EST
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.
Comment 6 Zdenek Prikryl 2008-01-04 05:23:40 EST
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
Comment 7 Zdenek Prikryl 2008-01-16 07:23:15 EST
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)
Comment 8 Adam Hough 2008-03-17 12:03:49 EDT
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
Comment 9 Zdenek Prikryl 2008-03-25 09:10:38 EDT
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).
Comment 10 Chris Snook 2008-08-12 11:18:37 EDT
Working fine in F9.  Never got it straightened out in F8.
Comment 11 Zdenek Prikryl 2008-08-14 02:44:52 EDT
Ok, I'm closing this bug.

Note You need to log in before you can comment on or make changes to this bug.