[BUG] Intel HD Graphic QM57 chipset: Dell U3011 monitor turns to power saving mode

[Daniel Vetter]

On Wed, Feb 15, 2012 at 03:16:52PM -0500, Mathieu Desnoyers wrote:
> * Mathieu Desnoyers (mathieu.desnoyers at efficios.com) wrote:
> > Hi Keith,
> > 
> > * Keith Packard (keithp at keithp.com) wrote:
> > > On Sat, 21 Jan 2012 13:56:21 -0500, Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> > > 
> > > > Dell U3011 monitor turns to power saving mode when resolution set to 2560 x 1600
> > > > (intermittent)
> > > > 
> > > > Reproduced with:
> > > > Linux 2.6.38-1-amd64 (Debian kernel)
> > > > Linux 3.1.0-1-amd64  (Debian kernel)
> > > > Linux 3.2.0-1-amd64  (Debian kernel)
> > > > 
> > > > The computer is a Lenovo X201 Tablet (Intel QM57 chipset), on a X200
> > > > docking station. The docking station uses a DisplayPort cable to connect
> > > > to the monitor.  I tried upgrading my Bios from 1.34/1.13 to 1.38/1.14
> > > > (latest), which did not fix the problem. I cannot use anything else
> > > > than DisplayPort in this case to connect the monitor at 2560 x 1600,
> > > > because this resolution requires either the bandwidth provided by a
> > > > dual-link DVI (which I cannot connect in my docking station), or
> > > > DisplayPort.
> > > 
> > > I use this same monitor, and have run it with an X200 in the past.
> > > 
> > > Can you capture a dmesg output with the kernel parameter drm.debug=0xe
> > > set? That will let us see the DP link training adventure and see what's
> > > broken. If you can, separate traces of working and non-working tries
> > > would be nice.
> > > 
> > > And, of course, trying 3.3-rc1 would be helpful as that's what any
> > > test patches would be developed on top of.
> > 
> > I've compiled and launched a 3.3-rc1 kernel for the following tests. The
> > dmesg log follows.
> > 
> > FWIW, when I get the screen to run, if I launch this 1080p video with
> > either mplayer or vlc (http://www.bigbuckbunny.org/index.php/download/,
> > 1920x1080, mp4 format) in full screen, I get an horizontal line of blur
> > at about 7/8 of the screen (from the top) when there is a lot of
> > movement in the movie.  This looks like a vertical refresh sync issue
> > and/or too small buffers for double(/triple)-buffering. I'm aware that
> > this is a separate issue, but it might help the current investigation.
> > The xrandr -q --verbose gives "+HSync -VSync" for the monitor, even
> > though its EDID (taken with get-edid/parse-edid) specifies "Flags
> > "-HSync" "+VSync"". So hsync and vsync +/- seems to be mixed up.
> 
> Another piece of information on this issue: I tried the monitor with an
> Apple PowerBook running MacOS X, and the monitor works flawlessly
> (monitor always brought up, and the same video works without glitch with
> vlc).
> 
> I also simplified my routine that successfully bring the monitor into a
> working state: running 5 to 20 times the following script ends up doing
> the trick:
> 
> xrandr --output DP1 --off
> sleep 1
> xrandr --output DP1 --mode 2560x1600
> 
> Please let me know if I can provide more information on the issue than
> the detailed logs (success/fail) below. I would also like to know if
> there is a knob somewhere in the Intel driver I could play with to
> provide more time for the screen to send its EDID information. Based on
> this info: http://www.intel.com/support/graphics/sb/CS-028366.htm, Intel
> provide a modified Windows driver that might target this kind of issue,
> and I assume they possibly let more time than the spec requires for the
> screen to send EDID info.

Well, we unfortunately have a bunch of dp link training issues left. But
currently I'm not aware of any patches that might help. The best way
forward is likely to file a bugzilla on bugs.freedesktop.org with all the
information you've already gathered (against DRI, DRM/Intel) so that this
won't get lost.

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48