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 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
