+++ This bug was initially created as a clone of Bug #640421 +++

Description of problem:

The X display backlight can be lost, and is not able to be recovered under certain common scenarios.  The most obvious one is simply running: system-config-display.  In some cases, when a new settings file is tested, the backlight is turned off, and not re-enabled. 


Version-Release number of selected component (if applicable):

version 1.6.5
release 9.36


hardware:
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02 )

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Dell Unknown device 041b
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 1800 [size=8]
        Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
                Address: 00000000 Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] 0000013 [0306]

===================

also it seems a brightness issue us being seen in this report:

Is this issues related to my problem, i.e. a new Toshiba A665 laptop with Intel built-in graphics, attempts to install CentOS server 64 bit results in a black screen at the point of 'select language', if you look closely the screen is faintly visible at 1/10 brightness and if you squint hard enough you can give input (mouse etc is active) and the install dutifully proceeds to the 'partition selection' option.


Note: 

looks like this may be some new feature bleeding through that Linux did not 'get the memo' on yet

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539477 [^]
http://mjg59.livejournal.com/121851.html [^] 


How reproducible:

1. Run: s.c.d
2. The backlight goes off
3. To recover, one has to ssh into the machine and reboot it, as one simply cannot read the screen


Steps to Reproduce:

   as above

  
Actual results:

Some Intel based laptop video chipsets of recent vintage have a problem with the backlighting not being sufficient (i.e., turned off) in some cases

When manually configured from a 'no prior /etc/X11/xorg.conf' state, low resolution configurations with adequate light can be produced.

When using s-c-d cannot get the backlight work at the end of the config, or a reconfig process

Noting this bug as a tracking point to run this down, to research froward from, and hopefully find a fix or workaround 


Expected results:

desired: the backlight simply works in all cases unless explicity turned off (Xscreen saver type actions for power mgt, etc)

minimal: the backlight is at least minimally on [so that a recovery is possible without rebooting the unit], and a preferred recovery process or tool documented


Additional info:

A. similar 'control of the display bugs here include: #468448  [Lenovo Thinkpad notebooks]
... this bug also implies a later: hal-info may help

B. The reporter on #470455  suggests toggling setting in: adjusting the
/sys/class/backlight/thinkpad_screen/brightness flag (from 0 to 15)

C1. another bug #437267 suggests:  recovered by switching to a VT,
logging in as root and executing:

export DISPLAY=:0
vbetool dpms on

[not possible here, due to the absence of backlight on.  The local unit under test does not have a backlight come on with a switch into a lower VT ...]  (implying yet another component in play -- probably 'kernel' as it controls the local display VT repaints, as I recall)

C2. It also suggests opening a X terminal and:

can you recover by doing 'xset dpms force on' from within the X
session?  (yes, blindly)

again, not possible as one cannot see where to 'mouse to' to fall within a console window ... something like:  F2 konsol <tab> [enter] <on the OK>  [position indeterminate] ... cannot run the xset  ;(

D.  The rebase in #432404 (rhel 5.1) is assumedly fully present, and so no joy there

E.  The Intel drivers seem to be something of a moving target, as the problem of #244933 seems partially relevant here as to a regression slipping in (although, with no backlight, a differing issue)

F. The close of #556385 seems to be a close of an open issue for non-technical reasons (timing) rather than after a fix -- I would clone and reopen it, but it is not my precise case


Endnote:

I file this after seeing a Fedora thread today on this general topic of Intel i810 drivers, and certainly understand that Intel provides lots of ship variations, and so makes for a moving target.  Perhaps some more formal form of drivers updates program is needed? -- I see folks in a couple of the bugs asking for access to testing released on the enterprise platform

If you need specifics, please ask and I will supply as I can

-- Russ herrold

--- Additional comment from herrold on 2012-01-12 14:49:44 EST ---

We find this issue on this same hardware, in the latest kernels in RHEL 6, in that the backlight is not toggled on in 6.2 .... it was fine in 6.0   is this possibly a kernel issue in play>