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 possuble 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 ...]  (impying yet another conponent 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