Bug 1000035 - Screen goes blank from Power settings tool
Screen goes blank from Power settings tool
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-22 10:23 EDT by wdc
Modified: 2013-09-27 22:18 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-27 22:18:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wdc 2013-08-22 10:23:02 EDT
Description of problem:

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.
Comment 1 wdc 2013-08-31 09:50:53 EDT
Added upstream Gnome.org bug ID in "See Also".  (Hope I put it in the right place.)
Comment 2 wdc 2013-08-31 09:54:19 EDT
Upstream they asked me to run xbacklight (which is not installed in Fedora by default, but IS available as a yum package.  (Thank you koji packageinfo and auisl!))

This may be a kernel driver problem because when one uses xbacklight to VIEW the display brightness the brightness is CHANGED to be the complement of what it was.

As I said in my upstream report:

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.
Comment 3 wdc 2013-09-27 22:18:27 EDT
Good news!  I just took updates today and with the 3.11.1.-200 kernel, the problem is fixed.  Now calling xbacklight -get only gets and does not set the brightness.

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