Bug 33702

Summary: Screen becomes blank if you switch display mode between single internal and external with the same resolution
Product: Drivers Reporter: Michael Chang (mchang)
Component: Video(DRI - Intel)Assignee: drivers_video-dri-intel (drivers_video-dri-intel)
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.39-rc3 Subsystem:
Regression: No Bisected commit-id:

Description Michael Chang 2011-04-19 08:33:38 UTC 
Distro: SLED11-SP1
Kernel: 2.6.39-rc3

Reproduce step:

CASE A: The internal LVDS output will become blank

 $ xrandr --output LVDS1 --mode <COMMON RESOLUTION>  --output VGA1 --off
 $ xrandr --output VGA1 --mode <COMMON RESOLUTION> --output LVDS1 --off
 $ xrandr --output LVDS1 --mode <COMMON RESOLUTION> --output VGA1 --off

CASE B: The external VGA output will become blank

 $ xrandr --output VGA1 --mode <COMMON RESOLUTION> --output LVDS1 --off
 $ xrandr --output LVDS1 --mode <COMMON RESOLUTION> --output VGA1 --off
 $ xrandr --output VGA1 --mode <COMMON RESOLUTION> --output LVDS1 --off

The <COMMON RESOLUTION> is any one of the common resolutions of internal LVDS and
external VGA monitor. If you use different resolution, the issue will not be able to reproduce.

For example, in my testing case the monitor and notebook has following common modes and any one of them can reproduce the blank screen using above procedure.

 1024x768
 800x600
 640x480

Reproduce rate : 100%

Reproduced on : PinTrail (PineView), HuronRiver (SandyBridge)
Comment 1 Michael Chang 2011-05-09 06:45:16 UTC 
Finally I get workaround this issue by reverting two xorg intel driver (xf86-video-intel) commits. 

 - Mark outputs as DPMSModeOn and restore backlight at mode set

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=33c08882c0d551afb28baef643279901dcc65fa9

 - display: outputs are enabled automatically by KMS

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=19c48d3b3f33582baa87a9b3a9189e320e4cea45

This leads to the commit below revived. By reading the code I think it forces to set DPMS to ON after the CRTC set. This special handling for DPMS was considered redundant to recent kernels because KMS do it automatically.

 - Re-enable disabled outputs after rotation
The server may have made a DPMS call before doing rotation, so after we do the mode set with the rotated framebuffer, we need to re-enable the corresponding output(s). Fixes bug #20573. 

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bedc894a565ce3c7a50990e3f78953fc2432ad40

Maybe the kernel still have discrepancy in DPMS that's not addressed ..
Comment 2 Michael Chang 2011-05-09 06:50:32 UTC 
Since this is a problem of inconsistent kernel DPMS property.  Mark this as dup of bko#24982.

*** This bug has been marked as a duplicate of bug 24982 ***