GNOME Bugzilla – Bug 706589
Screen goes blank on startup of Power settings tool
Last modified: 2013-09-04 20:18:32 UTC
Opening "Power Settings" from either the Settings tool or the "Power Settings" menu item under the battery widget in the panel causes the screen to go dark. There is a work-around: Manually suspend and resume the machine. Version-Release number of selected component (if applicable): uname -sr info: Linux 3.10.7-200.fc19.x86_64 System Settings Details: Memory: 3.8 GiB Intel Core i3-3217U CPU @1.80 GHz x 4 OS Type 64-bit Graphics: Intel Ivybridge Mobile GNOME Version 3.8.2 How reproducible: Always Steps to Reproduce: 1. Start "Settings" Activity (found under "Utilities") 2. Click on "Power" (found under "Hardware") 3. Actual results: Screen goes black Expected results: Power management tool starts up and is visible. Additional info: The "Screen Brightness" control under "Power Saving" seems to keep getting reset to 0. Whenever the Power management tool starts, it seems always to use that setting and put the screen to that brightness level. It seems incorrect always to change the screen brightness setting from the "Power Saving" values at start-up time for the tool. Using <Fn><f5> (dim screen) and <Fn><F6> (brighten screen) it seems that the power save value CHANGES to the inverse of the regular screen setting. So I think this means that ANY time you set the screen brightness to maximun with the keyboard controls, the Power Saving brightness will be pushed to 0. And when you visist power saving, it will then blank your screen. Note also that the sceen brightness changes upon entering the Power pane REGARDLESS of whether the Laptop is on Battery or Line power. There also seems to be some strangeness in the application of the Brightness keys, since pressing <Fn><F5> multiple times toggles between brightening and dimming the screen. The work-around for this state of affairs is to suspend and resume the Laptop. That sets a visible amount of screen brightness. I am not sure how to prioritize this bug. Although it does not cause data loss, it could, if a user panics when the screen goes blank in the course of what they think is a normal act of changing settings. They may think the machine has died and power cycle, destroying any existing in-progress work.
What's the output of xbacklight before and after entering the panel?
Sorry for the delay in replying. I think I see the problem.... Is xbacklight -get supposed, ever to CHANGE the backlight value? To attempt your test, I ran xbacklight in an xterm window, just before attempting to enter the power management control panel. Basically, every time I run xbacklight, either with no arguments or with the -get argument, it sets the backlight value to the complement of what it was. IE: $ xbacklight 11.000000 $ xbacklight 90.000000 $ xbacklight -get 11.000000 $xbacklight -get 90.000000 If the library call to get the value is changing the value, from no matter where you issue the library call, that would tend to create problems.
(In reply to comment #2) > Sorry for the delay in replying. > > I think I see the problem.... > > Is xbacklight -get supposed, ever to CHANGE the backlight value? No. > To attempt your test, I ran xbacklight in an xterm window, just before > attempting to enter the power management control panel. > > Basically, every time I run xbacklight, either with no arguments or with the > -get argument, it sets the backlight value to the complement of what it was. > IE: > > $ xbacklight > 11.000000 > $ xbacklight > 90.000000 > $ xbacklight -get > 11.000000 > $xbacklight -get > 90.000000 > > If the library call to get the value is changing the value, from no matter > where you issue the library call, that would tend to create problems. This is a bug in the Xorg driver for your video card, or the kernel driver for the backlight. You should bring this up with your distribution.