Backlight level is incremented every time laptop lid is closed

kopatops · 02-16-2011, 02:04 PM

Hi,

I recently did a full system upgrade (which makes this hard to point to a specific package). Also I opened the laptop for dusting.

Now, every time I close the laptop lid, when I open it again, the backlight level is lower than before I closed it. The value is incremented by a certain value, according to an unknown rule.

I start out at full brightness:

Code:

[stupijar][~]$ setpci -s 00:02.0 F4.B
ff

I close the lid and open it again. Now the screen has been dimmed, but:

Code:

[stupijar][~]$ setpci -s 00:02.0 F4.B
ff

Setpci thus reports an unchanged value. I set the permissions so any user can change the value:

Code:

[stupijar][~]$ ls -l "/sys/bus/pci/devices/0000:00:02.0/config" 
-rw-r--rw- 1 root root 256 Feb 16 20:39 /sys/bus/pci/devices/0000:00:02.0/config

When I do

Code:

setpci -s 00:02.0 F4.B=FF

The backlight level is back at maximum (for real) and setpci still reports a level of ff.

Furthermore, the dimming can be repeated by successive lid close/open operations, until it is completely dark.

Could this be a hardware problem? Should I roll back Xorg, or my Intel drivers? Anyone recognizes the symptoms?

Thanks!

EDIT: Since I dusted the interiors of the computer, the power LED is constantly on, even when it is shut down. This could support the hardware fault theory. Something has changed in there...

easuter · 02-17-2011, 08:38 AM

Quote:

Originally Posted by kopatops

Hi,

I recently did a full system upgrade (which makes this hard to point to a specific package). Also I opened the laptop for dusting.

Now, every time I close the laptop lid, when I open it again, the backlight level is lower than before I closed it. The value is incremented by a certain value, according to an unknown rule.

I start out at full brightness:

Code:

[stupijar][~]$ setpci -s 00:02.0 F4.B
ff

I close the lid and open it again. Now the screen has been dimmed, but:

Code:

[stupijar][~]$ setpci -s 00:02.0 F4.B
ff

Setpci thus reports an unchanged value. I set the permissions so any user can change the value:

Code:

[stupijar][~]$ ls -l "/sys/bus/pci/devices/0000:00:02.0/config" 
-rw-r--rw- 1 root root 256 Feb 16 20:39 /sys/bus/pci/devices/0000:00:02.0/config

When I do

Code:

setpci -s 00:02.0 F4.B=FF

The backlight level is back at maximum (for real) and setpci still reports a level of ff.

Furthermore, the dimming can be repeated by successive lid close/open operations, until it is completely dark.

Could this be a hardware problem? Should I roll back Xorg, or my Intel drivers? Anyone recognizes the symptoms?

Thanks!

EDIT: Since I dusted the interiors of the computer, the power LED is constantly on, even when it is shut down. This could support the hardware fault theory. Something has changed in there...

I didn't have this exact same problem, but a similar one on an old laptop I had. Every time I opened the lid, the backlight would be completely dimmed out, so as a workaround I put the command to restore the backlight brightness as an acpid event, activated whenever the laptop lid opened (see /etc/acpi/acpi_handler.sh)

Sorry, I know this isn't an ideal solution. The Arch wiki will probably have more specific info for you.

kopatops · 02-17-2011, 03:39 PM

Quote:

Originally Posted by easuter

I didn't have this exact same problem, but a similar one on an old laptop I had. Every time I opened the lid, the backlight would be completely dimmed out, so as a workaround I put the command to restore the backlight brightness as an acpid event, activated whenever the laptop lid opened (see /etc/acpi/acpi_handler.sh)

Sorry, I know this isn't an ideal solution. The Arch wiki will probably have more specific info for you.

Thanks anyway easuter, this works fine. Specifically, I did the following:
File: /etc/acpi/handler.sh

Code:

#!/bin/sh
# Default acpi script that takes an entry for all actions

# NOTE: This is a 2.6-centric script.  If you use 2.4.x, you'll have to
#       modify it to not use /sys

minspeed=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq`
maxspeed=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq`
setspeed="/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed"

set $*
[.........................................]
        case "$2" in
            BAT0)
                case "$4" in
                    00000000)   #echo "offline" >/dev/tty5
                    ;;
                    00000001)   #echo "online"  >/dev/tty5
                    ;;
                esac
                ;;
            CPU0)	
                ;;
            *)  logger "ACPI action undefined: $2" ;;
        esac
        ;;
    button/lid)
        #echo "LID switched!">/dev/tty5
        grep open /proc/acpi/button/lid/LID/state && ~/bin/blight max
        ;;
    *)
        logger "ACPI group/action undefined: $1 / $2"
        ;;
esac

, where ~/bin/blight max sets the brightness to maximum. In reality I used the absolute path to the blight script, I think handler.sh is executed as root (?).

Not marking as SOLVED.

cb474 · 03-03-2011, 07:33 PM

kopatops,

I am also on a fully upgraded Arch (x86_64) system and am having exactly the problem you describe (on a Thinkpad T61). It started a couple weeks ago, so probably at the same time as you.

I don't have the /etc/acpi/handler.sh script though and really know nothing about scripts. If I want to use your workaround and create the script and all I want is the fix for the lid brightness issue, what part of the script do I need? (I don't want to add any extra acpi events that I don't already have).

Alternatively, I see on my system that there is already a /etc/acpi/actions/lm_lid.sh script. Can something be added to that to achieve the same workaround?

Thanks for any help.

cb474

kopatops · 03-05-2011, 02:51 AM

cb474,

(Do you have acpid installed?)

On my setup I have the file "/etc/acpi/events/anything" with the following content:

Code:

# Pass all events to our one handler script
event=.*
action=/etc/acpi/handler.sh %e

That is, whenever *any* acpi event is detected, handler.sh is called to execute some command (based on what event was detected). In handler.sh every event has a corresponding action. I basically set the action corresponding to the button/lid event (lid was opened) to

Code:

setpci -s 00:02.0 F4.B=ff

,where 00:02.0 is my display controller ID (check with lspci | grep VGA) and ff is the maximum brightness value. This might return a "permission denied" error on your system. You need to change the permissions for the config file mentioned in that message, so brightness can be changed by your user ID.

anything and handler.sh shoud be installed by the package acpid. This is described on the Arch Wiki here together with instructions on how to add your own custom event handlers (but acpid is required for the workaround):

https://wiki.archlinux.org/index.php..._configuration

Could you post the contents of that lm_lid.sh file?
___________________

I found it most easy to just use those files preinstalled by acpid, but I guess you can create your own event handler just for button/lid.

Now, if you want to do something based on the event that the lid state was changed, the first thing to do is identify that event. Assuming you have acpid installed, do

sudo acpi_listen

and close/open the laptop lid. I get

Code:

$ acpi_listen
button/lid LID 00000080 00000001
button/lid LID 00000080 00000002

, so I might create a file /etc/acpi/events/lidchange with the contents

Code:

event=button lid.*
action=/etc/acpi/actions/maxbright.sh "%e"

and a file /etc/acpi/actions/maxbright.sh with the contents

Code:

#!/bin/sh
grep open /proc/acpi/button/lid/LID/state && setpci -s 00:02.0 F4.B=ff  # If lid was opened, set brightness to max

Also make this last file (script) executable with

Code:

sudo chmod +x /etc/acpi/actions/maxbright.sh

cb474 · 03-05-2011, 04:04 PM

Thanks kopatops! I'll get to work on this and see if I can get it to work.

cb474 · 03-05-2011, 09:35 PM

So you were right that I did not have acpid installed. I didn't realize at first that acpid is a daemon related to acpi and not synonymous with the acpi module. Once I installed acpid, the handler.sh file showed up.

As I said, however, even before I installed acpid there was already a lm_lid.sh file on my system, found at: /etc/acpi/actions/lm_lid.sh.

lm_lid.sh had the following default contents in it:

Code:

#! /bin/sh

test -f /usr/sbin/laptop_mode || exit 0

# lid button pressed/released event handler

/usr/sbin/laptop_mode auto

I don't know if this is kosher or not, but all I did was after the last line of lm_lid.sh add:

Code:

setpci -s 00:02.0 F4.B=ff

So my whole lm_lid.sh now reads:

Code:

#! /bin/sh

test -f /usr/sbin/laptop_mode || exit 0

# lid button pressed/released event handler

/usr/sbin/laptop_mode auto
setpci -s 00:02.0 F4.B=ff

That seems to have solved the problem.

One question I have is that now that the handler.sh file is operating with acpid on my system, is that going to effect other settings I have on my machine, for the power button, ac adapter, etc (all things that the script looks like it effects)? If I don't need handler.sh, should I just comment it out in /etc/acpi/events/anything?

That aside, thanks super much again for this post and your help. I never would have figured this out on my own.

kopatops · 03-06-2011, 03:28 AM

Glad it worked!

The default handler.sh doesn't seem to do anything with the events detected, it only logs them happening (and even this is commented out in my file). That is, you may get an entry in /var/log/messages.log every time e.g. power button is being pressed. If you want any other command to be executed based on power button being pressed (e.g. shutdown/standby/hibernate), you need to insert that command in the proper row in handler.sh.

So no, handler.sh shouldn't interfere with your own settings in its default format, and you could let it be or comment it out of /etc/acpi/events/anything as you see fit.

kopatops · 03-06-2011, 03:45 AM

http://www.gentoo-wiki.info/HOWTO_Au...f_your_monitor

This document indeed describes /etc/acpi/actions/lm_lid.sh as an acpid script (executed by acpi daemon). However inserting the setpci line as you did:

Quote:

Originally Posted by cb474

I don't know if this is kosher or not, but all I did was after the last line of lm_lid.sh add:

Code:

setpci -s 00:02.0 F4.B=ff

So my whole lm_lid.sh now reads:

Code:

#! /bin/sh

test -f /usr/sbin/laptop_mode || exit 0

# lid button pressed/released event handler

/usr/sbin/laptop_mode auto
setpci -s 00:02.0 F4.B=ff

would probably set the backlight to max when lid is either closed or opened. If this is not the case you can just ignore this comment. Otherwise, check for state open by replacing

Code:

setpci -s 00:02.0 F4.B=ff

with

Code:

grep open /proc/acpi/button/lid/LID/state && setpci -s 00:02.0 F4.B=ff

and setpci will run only if LID state was changed and LID state is now open.

Good luck

cb474 · 03-07-2011, 06:37 PM

My backlight doesn't seem to be coming on when I shut the lid. It looks like it's off. But I changed the code in the script to "grep..." as you suggest, just in case. Thanks.