LVDS Undetected

LVDS Undetected

[Travis Allen]

I am using a D945GSEJT motherboard which has onboard LVDS.  Unfortunately whatever I do the LVDS output is not listed in xrandr nor Xorg.  It will only list the VGA, DVI, and TV outputs.  I have tried using the "nomodeset" option, however that removes *all* outputs from xrandr and only lists a "default" output.

Kernel version: 2.6.38
Intel driver version: 2.14.0


I attached a dmesg output with drm.debug=0x04.  The line which strikes me is:

	[drm:intel_lvds_init], LVDS is not present in VBT

I have two questions:
	1) Why doesn't it still list the output so it can be manually configured?
	2) If there is a valid reason for 1, how can I force the output to be listed.  Maybe by kernel parameters, for example.  I have full specs for the panel so if required I can manually specify them all.


-Travis

Re: LVDS Undetected

[Oliver Seitz]

> 	2) If there is a valid reason for 1, how can I force the output to be listed.

Short answer: You can't.

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.

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

Greets,
Kiste

Re: LVDS Undetected

[Mike Isely]

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

Re: LVDS Undetected

[Travis Allen]

I am now using a nightly build of the driver from last night. 

> 
> video=LVDS-1:e

Unfortunately this didn't enable the LVDS output (at least xrandr doesn't show it as an available output with a default boot - ie no xorg customization).  Does this require an xorg.conf for the output to show up?

 
> 
> 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.

So I don't have to go searching through the archives, can you give me an approximate date you posted this patch so I can try it out?

Re: LVDS Undetected

[Oliver Seitz]

>> video=LVDS-1:e
>
> Unfortunately this didn't enable the LVDS output (at least xrandr doesn't show it as an available output with a default boot - ie no xorg customization).  Does this require an xorg.conf for the output to show up?

Some months ago I've tried that, I also had no success, with or without 
xorg.conf.

Greets,
Kiste

Re: LVDS Undetected

[Mike Isely]

On Wed, 11 May 2011, Oliver Seitz wrote:

> 
> > > video=LVDS-1:e
> > 
> > Unfortunately this didn't enable the LVDS output (at least xrandr doesn't
> > show it as an available output with a default boot - ie no xorg
> > customization).  Does this require an xorg.conf for the output to show up?
> 
> Some months ago I've tried that, I also had no success, with or without
> xorg.conf.

Really?  This is interesting.  I'm relying on this behavior because the 
display here is otherwise not detected.  However in my case I'm also 
specifying timing info.  Oh wait, that could be it.  I think the logic 
disables the head if it can't determine a usable mode.  So you need a 
patch AND you need the video=LVDS-1 option setting to turn it on.

  -Mike


-- 

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

Re: LVDS Undetected

[Mike Isely]

On Wed, 11 May 2011, Travis Allen wrote:

> I am now using a nightly build of the driver from last night. 
> 
> > 
> > video=LVDS-1:e
> 
> Unfortunately this didn't enable the LVDS output (at least xrandr 
> doesn't show it as an available output with a default boot - ie no 
> xorg customization).  Does this require an xorg.conf for the output to 
> show up?

Not strictly.  You can also exercise the head with just the framebuffer 
console since every DRM-driven device can also be made to operate as a 
framebuffer device.  I've successfully done testing that way.

You're probably going to need more info for how to actually control the 
video timings.  Before KMS came along you did everything in xorg.conf.  
With KMS in the picture and the ability to use this stuff outside of 
xorg, there's actually a whole 'nother way to set the video mode, via 
that "video=" kernel parameter syntax.


> 
>  
> > 
> > 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.
> 
> So I don't have to go searching through the archives, can you give me 
> an approximate date you posted this patch so I can try it out?

Look for a patch series posted by me to this list back on March 17th.  
There are 3 patches in 4 posts.  The first post explains everything so 
you'll definitely want to look at that as well.  The patch series 
implements the ability to disable scaling - the first solution I 
mentioned earlier.

IIRC, two of the three patches have been merged, the controversial one 
that actually enables fixed mode timing however has not been merged.  

I also have this stuff rebased against a 2.6.38.5 vanilla kernel, if 
interested.

  -Mike


-- 

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