Red Hat Bugzilla – Bug 464260
EeePC Backlight locks on resume from suspend (but on!)
Last modified: 2018-04-11 13:59:29 EDT
Description of problem:
On EeePC 1000 when you resume from suspend to ram the backlight restores to 100% brightness. This can not be changed by using the function keys to change the brightness. The only way to get normal brightness back and control of the brightness level is to switch to one of the alternate terminals via ALT-CTRL-F1 (for example) and then switch back to ALT-CTRL-F7. After the switch brightness returns to normal and the brightness adjustment keys work again.
Version-Release number of selected component (if applicable):
Fully updated current release of Fedora 9
100% of the time
Steps to Reproduce:
1. Suspend to RAM
2. Resume from RAM
3. Try to adjust brightness and fail
4. Switch Terminals
5. Switch back to X11 Terminal
6. Try to adjust brightness and succeed
Super bright no control
Normal bright full control
Confirmed on EeePC 1000 40G and EeePC 901. See here for more results:
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 322150 [details]
xorg.conf created by Anaconda
Created attachment 322151 [details]
Xorg.0.log using attached xorg.conf
Created attachment 322152 [details]
Xorg.0.log without xorg.conf
I am not the original reporter. I have attached my xorg.conf and Xorg.0.log as requested. These are for an EeePC 1000h, which should have identical graphics hardware to the 1000 and 901. This model is also affected by the bug described in this report. I am using Fedora 9 i386 (up to date).
$ uname -a
Linux ripley 188.8.131.52-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 2008 i686 i686 i386 GNU/Linux
Note also that:
(1) terminals Ctrl-Alt-F1 are blank
(2) Alt-F7 is sufficient to switch back (but sometimes this fails, display goes to sleep?)
Created attachment 322153 [details]
The bug reported xorg.con file
Created attachment 322154 [details]
xorg.conf related Xorg.0.log log file
Created attachment 322155 [details]
Xorg.0.log log file when no xorg.conf file is present
Sorry, I was away on business and unable to get the files. I've up loaded what you requested.
And as Ben said the Eeepc 1000H should have the same graphics card setup (same with the Eeepc 901).
Another Note Terminals Alt-Crtl-F1 through F6 are sometimes blank when switched too (actually, they aren't blank but for some reason the backlight turns off completely). In these conditions when returning to Alt-Crtl-F7 that terminal is blank as well. This is easily fixed by just hitting Fn-5 or Fn-6 to change the brightness which triggers it back to what it should be. This does not happen all the time.
Thanks, David, the Fn-F6 workaround to wake the backlight is just what I needed.
Developers, note that the blank (backlight off) terminal problem occurs only when logged in (in my case, a GNOME session). At the gdm prompt, there is no problem using Ctrl-Alt-1 to switch to a terminal, and Alt-1 to switch back. The blank terminal problem seems to occur only when I am logged in (power manager is active?). Perhaps this needs its own bugreport ...
Please change the component to xorg-x11-drv-i810. EeePC 901/1000/1000H have an Intel GMA 950 GPU (945GSE chipset). The driver for this is in the i810 package. Please see the Xorg.0.log for confirmation.
I've changed it to the intel based i810 driver since these are most definitely not amd chipsets. I'm not sure what else needs to be done as far as CC and such, but at least it's now marked under the correct driver structure.
It's correct, sorry I was too quick to assume that all XOs are xorg-x11-drv-amd.
EEEPC is not an XO.
This bug is not EEE specific. I suffer by exactly the same issue on HP NC6400 with intel 945. I suggest the topic is changed to "intel driver: brightness cannot be adjusted after resume" or similar.
I am running up-to-date Fedora 10 with 184.108.40.206-41.fc9.i686 kernel (please note that the kernel is fc9 because fc10 did not boot into X probably because of Plymouth issues). I can also confirm that switching to vt1 and back by the following lines added to the end of my suspend script workarounds the problem:
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.