Bug 70207 - rs690: kernel can't bring lvds in dpms on mode
Summary: rs690: kernel can't bring lvds in dpms on mode
Status: RESOLVED DUPLICATE of bug 81382
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-06 18:27 UTC by David Heidelberg (okias)
Modified: 2014-07-15 13:37 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

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.