[Intel-gfx] LVDS Undetected

Mike Isely isely at isely.net
Wed May 11 18:14:24 CEST 2011


On Wed, 11 May 2011, Oliver Seitz wrote:

> 
> > 	2) If there is a valid reason for 1, how can I force the output to be
> > listed.
> 
> Short answer: You can't.

Actually, you already CAN force it on, no patches needed.  Adding this 
to the kernel command line should probably do it:

video=LVDS-1:e


> 
> It is being discussed to implement kernel parameters to force a 
> certain LVDS mode, abd there do exist some patches. But as much as I 
> know there hasn't been a decision made if it even should be allowed to 
> force LVDS on.

The issue all comes down to being able to force specific video timings 
to the LVDS output.  There are two possible ways to do it, one involves 
simply shutting off the automatic scaling and letting the normal 
modeline stuff do its job - as had been done for years back in the days 
of CRT monitors.  The other involves a means to directly specify a 
second set of timings to the back end itself - which is more flexible 
than simply killing the scaling.

I posted a patch to implement the first approach, which works, and 
exactly mimics what had been previously fixed in the UMS method a little 
over 3 years ago.

Chris posted a patch to make the second approach work.  Chris's patch 
has two problems: (1) It doesn't do anything if the DRM driver thinks it 
already "knows" what the timings should be, for example if it pulls 
erroneous data from the hardware.  That's a showstopper for us, though 
some here think this is a feature not a bug.  (At best, having this new 
interface is now misleading since the driver can silently ignore it.) 
(2) There's an uninitialized variable in the mode parser that screws it 
up anyway, resulting ultimately in the calculation of incorrect video 
timing parameters.  The error is also in the version of the mode parser 
before Chris made his changes, but apparently it was somehow benign 
before now.  I posted a patch last week that fixes this, though I 
haven't seen anyone ack the patch.


> 
> For now, I'm really thinking about using a EDID hardware chip to tell the
> software what to do.

Won't work if there's no EDID available.  LVDS is an unusual case since 
most of the time it pertains to built-in hardwired LCD panels in 
laptops.  In those cases I would expect that the video BIOS does the 
heavy lifting to initialize things, and the i915 module has been 
assuming this to be the case.  EDID doesn't come into play.  There are 
some less common cases - like for example the situation posted by the 
author of this latest thread - where the LVDS panel is not integral to 
the system.  If the video BIOS tries to configure such an output anyway, 
it will likely get it wrong, then i915 comes along and takes that wrong 
information as gospel and makes the panel useless in Linux as well.

I've said my bit about this already several times and I imagine I'm 
probably just going to annoy folks by further repeating what I think is 
perfectly valid reasoning for including the ability to manually set the 
LVDS video timings.  Probably too late :-(

But right now since the project I'm on absolutely needs this ability, 
then we're probably just going to end up maintaining the (pretty simple) 
patch out-of-tree.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8



More information about the Intel-gfx mailing list