Created attachment 17645 [details] xorg.conf Computer uses Intel GM965. Problem is "fixed" if module video is blacklisted. This machine supports 8 levels of backlight. At various times, the system decides to reset LCD brightness to maximum. It happens after a screen blank (for example, lid closed and opened). also, on ubuntu xset dpms force on set the backlight to max brightness (although not on Debian). On Debian unstable, simply opening the Gnome Power Management preferences application causes the screen to reset to maximum brightness, although this doesn't happen on Ubuntu. Users of other systems report to Ubuntu bug reporting that under similar circumstances, their backlights become too dim, not too bright. I guess (wild speculation) that there is a hardcoded value for brightness being used somewhere that for some people is a low number compared to their maximum brightness, and for me where 7 is the max value, it is high. I will research how to file bug reports and make some attachments.
how to file bug report: http://www.intellinuxgraphics.org/how_to_report_bug.html
First, some more narrative. My next comment will follow the bug reporting template. My earlier comments about resetting to maximum brightness are too specific. I hope that the investigation below will mean something to someone. On my machine, I discovered that I can predict the brightness level change (the bug) by using xbacklight. I don't know how xbacklight works, but it does not follow the brightness changes I get when pressing hotkeys. But the value of backlight brightness that xbacklight reports is always the brightness level that is set when a) starting a virtualbox-ose virtual machine b) restoring the screen after closing and opening the lid c) doing xset dpms force on Also, if the backlight hotkeys changed backlight brightness via xbacklight, then there would be no bug (that is, if what xbacklight agreed with the actual screen about backlight levels, there would no bug) ----- I have 8 levels of brightness, so my first steps in % are 0, 14, 29 via the hotkeys, I make the display 100% bright # xbacklight -get 0.000000 : so it doesn't know the screen has changed # xbacklight -set 10 : no change; the backlight stays at 100% #xbacklight -set 20 : the backlight dims to the second lowest level (that is, it goes to level 14%) #xbacklight -get 14.285714 again, use the hotkeys to go to 100%. Then ... #xbacklight -get 14.285714 #xbacklight -set 20 :doesn't do anything, the screen is still 100% bright but #xbacklight -set 50 #xbacklight -set 20 does get my back to the second level of brightness. alternatively, I can do #xset dpms force on because this always forces the backlight to be the same value as xbacklight -get; it overrides whatever setting the user has chosen via the hotkeys. Or to put it another way, however xbacklight works does not update itself when the user changes the backlight with the hotkeys. and here is the link to the original bug report: the brightness level that you get by starting a virtual machine is the same as you get by xset dpms force on That is, you can always predict the brightness level you will get when starting a virtualbox-ose virtual machine (or closing and opening the laptop lid) by first checking xbacklight -get and another way of stating the problem is that xbacklight -get is wrong.
System environment: -- chipset: GM965 on a Toshiba u400 Satellite notebook -- system architecture: Intel Core Duo T8300 2.4 GHz, 2 GB Ram uname-m i686 -- xf86-video-intel: xserver-xorg-video-intel 2:2.2.1-1ubuntu13.5 -- xserver: xserver-xorg-core 2:1.4.1~git20080131-1ubuntu9.2 -- mesa: -- drm: -- kernel: 2.6.24-19-generic -- Linux distribution: Ubuntu 8.04 Hardy -- Machine or mobo model: Toshiba Satellite U400 (version PSU40A-01M001) Steps to reproduce 1. Boot machine, enter gnome 2. Note default brightness level of the screen. 2a. Note the value reported by xbacklight -get 3. Using keyboard hotkeys, adjust the brightness. Make it really different (eg, completely dim) 3a. run xbacklight -get and note that the reported value is the same as 2a despite the change of step 3. 4. Do a "reset event". One of 4a. Start a virtual machine from virtualbox-ose 1.6.2 4b. xset dpms force on 4c. Close and open lid (have gnome power management settings to be "blank screen" when closing lid) 5, Note that after all of these reset events, the backlight brightness is set to the value of 2a, not to the user-initiated setting of step 3.
Created attachment 17653 [details] Xorg.0.log
Created attachment 17654 [details] dmesg
> --- Comment #2 from Tim Richardson <tim@tim-richardson.net> 2008-07-13 06:32:33 PST --- > I hope that the investigation below will mean something to someone. > > On my machine, I discovered that I can predict the brightness level change (the > bug) by using xbacklight. > > I don't know how xbacklight works, but it does not follow the brightness > changes I get when pressing hotkeys. > But the value of backlight brightness that xbacklight reports is always the > brightness level that is set when > a) starting a virtualbox-ose virtual machine > b) restoring the screen after closing and opening the lid > c) doing xset dpms force on > > Also, if the backlight hotkeys changed backlight brightness via xbacklight, > then there would be no bug (that is, if what xbacklight agreed with the actual > screen about backlight levels, there would no bug) > This sounds like it should be fixed by ca616b902b2c5d0f046c7a042c11f045479e373a in the server and be08b61540e1edbb7673f0b6add0f1e32b136b3c in xf86-video-intel. Cheers, Julien
On my machine, there are two scripts that is executed by acpid when brightness hotkeys are changed (one for brightness up, one for brightness down) I have modified these to call xbacklight to sycnhronise it with the actual_backlight setting but the acpid log file states No protocol specified Cannot open display ":0.0" My forum research indicates that what I am doing should work, so perhaps this is another face of the bug?
Answer to my last post, I put it here in case it helps anyone else. this script below sychronizes xbacklight on my machine. I have modified /etc/acpi/video_brightnessup.sh and video_brightnessdown.sh to call this script, and now my brightness levels don't jump around when opening the lid or when starting a virtual machine. Also a case study in the value of open source.I haven't written a shell script for 15 years. #!/bin/bash value=`cat /sys/class/backlight/acpi_video0/actual_brightness` value3=`echo 100 / 7 \* $value + 1| bc -l` . /usr/share/acpi-support/power-funcs # value 3 is a correct decimal. The rounding up (+1) makes sure that the threshold is reached. for x in /tmp/.X11-unix/*; do displaynum=`echo $x | sed s#/tmp/.X11-unix/X##` getXuser; if [ x"$XAUTHORITY" != x"" ]; then export DISPLAY=":$displaynum" su $user -c "/usr/bin/xbacklight -set $value3 -steps 1 -time 1" fi done
I fixed a similar issue in the upstream X server & driver code awhile back, but since X server 1.5 isn't released yet, you may not have the code. Can you try upgrading to 1.5 to see if things work better for you?
Given the report, I'll assume this is fixed with the next X server. If you test and find out that's not the case, please re-open. Thanks, Jesse
xorg-server-1.5.1 intel drivers 2.4.2 Display brightness resets to maximum after xset -display :0 dpms force off and re-enabling the monitor if initial brightness value is 0 (minimum). Other modes and brightness levels work fine.
This has been fixed in git master or xf86-video-intel-2.6-branch. Note that to report any backlight issue, please provide xrandr --verbose output or X log.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.