Bug 70207

Summary: rs690: kernel can't bring lvds in dpms on mode
Product: DRI Reporter: David Heidelberg (okias) <david>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: medium    
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description David Heidelberg (okias) 2013-10-06 18:27:34 UTC 
After some time, LVDS display get into off mode in console. After pressing keys it display stay black. Only way, how to get it working again is using "vbetool dpms on", then it lights up correctly.

It only applies in console, in X11 session is display powered just fine after passing event to key/mouse/touchpad.

This behaviour is here for long time, 100% since 3.9 to 3.11.4, but probably much more (I'd like to test, but it took lot of time).

This is laptop Toshiba A210-15j, RS690 card.
Comment 1 David Heidelberg (okias) 2013-10-07 11:44:57 UTC 
In cases STR (using hibernate-ram) within console it work well too.
Comment 2 David Heidelberg (okias) 2014-02-14 14:28:36 UTC 
Only difference I noticed is that in X is mode changed
mode 0 => 3 => 0

and in pure KMS console it's
mode 0 => 1 => 0
Comment 3 David Heidelberg (okias) 2014-06-07 19:47:09 UTC 
When issuing: "vbetool dpms on" without touching keys, screen goes just pure white. After pressing button, screen goes off again.

Seems like it goes from "any_state -> off" instead of "any_state -> on".
Comment 4 Alex Deucher 2014-06-09 01:08:38 UTC 
The driver only knows two states: on and off.  All of the other intermediate dpms states other than on map to off in the driver.  Note that vbetool goes behind the drivers back and messes with the hardware so it's likely to cause problems.
Comment 5 David Heidelberg (okias) 2014-06-27 13:32:16 UTC 
so bringing screen back fails somewhere on HW level?

in console:
  * driver set output=on, hw=on
  * result: output=on and hw=off stay
in X.org:
  * driver set output=on, hw=on
  * result: output=on and hw=on thanks to ? (some delay needed to resurrect lvds? or trigger additional register?)
Comment 6 Alex Deucher 2014-06-27 13:49:58 UTC 
It's the same code in the driver whether the console layer calls it or X calls it.  Maybe the console also mucks with the backlight?  You can use radeonreg (http://cgit.freedesktop.org/~airlied/radeontool/) to compare registers.
Comment 7 David Heidelberg (okias) 2014-06-27 15:00:45 UTC 
well, as I noticed, there is very dark image on screen, so it's backlight.
Comment 8 Alex Deucher 2014-07-15 13:37:37 UTC 

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

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.