Bug 1000035
| Summary: | Screen goes blank from Power settings tool | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | wdc |
| Component: | gnome-power-manager | Assignee: | Richard Hughes <rhughes> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | rhughes |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-09-28 02:18:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Added upstream Gnome.org bug ID in "See Also". (Hope I put it in the right place.) 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. 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. |
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.