https://bugs.freedesktop.org/show_bug.cgi?id=70207
Priority: medium Bug ID: 70207 Assignee: dri-devel@lists.freedesktop.org Summary: rs690: kernel can't bring lvds in dpms on mode Severity: normal Classification: Unclassified OS: Linux (All) Reporter: david.heidelberger@ixit.cz Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI
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.
https://bugs.freedesktop.org/show_bug.cgi?id=70207
--- Comment #1 from David "okias" Heidelberger david.heidelberger@ixit.cz --- In cases STR (using hibernate-ram) within console it work well too.
https://bugs.freedesktop.org/show_bug.cgi?id=70207
--- Comment #2 from David "okias" Heidelberger david.heidelberger@ixit.cz --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=70207
--- Comment #3 from David Heidelberger (okias) david.heidelberger@ixit.cz --- 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".
https://bugs.freedesktop.org/show_bug.cgi?id=70207
--- Comment #4 from Alex Deucher agd5f@yahoo.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70207
--- Comment #5 from David Heidelberger (okias) david.heidelberger@ixit.cz --- 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?)
https://bugs.freedesktop.org/show_bug.cgi?id=70207
--- Comment #6 from Alex Deucher agd5f@yahoo.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70207
--- Comment #7 from David Heidelberger (okias) david.heidelberger@ixit.cz --- well, as I noticed, there is very dark image on screen, so it's backlight.
https://bugs.freedesktop.org/show_bug.cgi?id=70207
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE
--- Comment #8 from Alex Deucher agd5f@yahoo.com ---
*** This bug has been marked as a duplicate of bug 81382 ***
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org