A program is incorrectly resetting a laptop backlight

Bug #332264 reported by cfox
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
acpi (Ubuntu)
New
Undecided
Unassigned

Bug Description

Kubuntu 9.04 current as of 2009.02.20

Lenovo SL 400 laptop with Intel integrated x4500 graphics.

Symptoms:
   -- Change the brightness of the LCD backlight to any value above the minimum value (using KDE's own controls or xbacklight, or even piping a number via sysfs it does not matter). The backlight will adjust, but several seconds later the backlight ALWAYS gets reset to 0, yielding a very dim screen.

What DOES work:
   -- The backlight CAN be adjusted via the /sys/devices/virtual/backlight/acpi_video0/brightness interface manually, and the standard GUI tools from KDE 4.2 also DO work. This bug is NOT about the adjustment not working, it is about a rogue program that is incorrectly dimming the screen every several seconds.

What is Broken:
   -- Some program, I do not know which one, is automatically setting the backlight brightness to 0 every several seconds.
      -- Here is what I know the problem is NOT:
           -- It is NOT in the HAL backlight modules, since I have turned off HAL temporarily and the problem persists
           -- It is NOT in KDE's powerdevil, I turned that service off entirely and the problem persists
           -- Turning off DPMS and using the NoPM flags in the Xserver itself do NOT fix the problem
           -- It MIGHT be coming from events triggered by interaction with the Xserver. When I set the brightness from
              a vterm it did not get reset until I switched back to the Xdesktop

What is the current work-around:
   -- I was able to manually echo a desired brightness level into the /sys/devices/virtual/backlight/acpi_video0/brightness file, and then IMMEDIATELY revoke write permissions for EVERYONE (including root) from the file to prevent whatever program is resetting the brightness to 0 from being able to write:
      example as root: echo 10 > brightness && chmod 000 brightness

Revision history for this message
jj.myrup (jj-myrup) wrote :

Could you provide the output from "ps" this might help narrow down which application it could be.

Revision history for this message
jj.myrup (jj-myrup) wrote :

Maybe lsof or strace could be used to find out which program it is. I haven't tried using the commands myself, but I found a link with an example:

http://linux.derkeiler.com/Mailing-Lists/SuSE/2006-06/msg02110.html

Revision history for this message
jj.myrup (jj-myrup) wrote :

It's me again ;-). I investigated a bit on strace. You can use strace with -p option to trace system call on a running process. Use "ps -e" to find out which processes you have.

Revision history for this message
cfox (cfox04) wrote :

Thanks for the tips on strace, I will try to use it later today when I get to my laptop.
I was also wondering about using inotify on the actual sysfs file. Is it possible for inotify to tell you which process is causing a
write to a file?

Revision history for this message
jj.myrup (jj-myrup) wrote :

I haven't been able to find a way to get inotify to tell which process is causing file access, I took a quick glance at "man inotifywait". But I am not experienced in inotify - I can see it would be very usefull for this situation, so let me know if you find a way to use inotify.

Revision history for this message
Kenny Kaczor (lordken) wrote :

Does disabling the KDE screensaver stop the reverting to dimmest setting?

Revision history for this message
cfox (cfox04) wrote :

Kenny:
    I disabled the screensaver and that did the trick! In retrospect it makes sense because the screen seemed to dim immediately upon certain X events like clicking the mouse that would be the types of things a screensaver would be checking for to reset its internal timer.
   Is this a Kubuntu specific bug that can be patched here, or should I report this problem upstream to the KDE developers? Turning off these unnecessary writes should help things out.

  Thanks to both you guys for helping me work around this.

Revision history for this message
Kenny Kaczor (lordken) wrote :

Hold on, I'm not done with you yet :)

Does starting up a game like neverball or any other SDL or OpenGL or whatever game dim your laptop, and does running a movie in VLC or Dragon Player also dim it...?

Revision history for this message
cfox (cfox04) wrote :

Kenny:
   I ran an SDL game in fullscreen mode and looked at some videos in VLC & Mplayer: No problems with the brightness. Thanks for helping me, if you want me to do anything else just post!

Revision history for this message
Kenny Kaczor (lordken) wrote :

OK.

I am having the same screensaver problem as you, and found it out by coming across a post on the ubuntu forums about it. Apparently this bug was reintroduced? I'm not sure, but regardless, yeah, I have the same bug too.

Apparently this bug is separate from another one I am having--you can probably guess what that is :(

I haven't seen other people complain about the screensaver bug. I wonder why....

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.