xorg-video-intel: Update man page to document LVDSFixedMode option From: Mike Isely This is a companion to the driver patch that implements control over fixed mode determination for the LVDS output (LVDSFixedMode); it adds corresponding documentation to the driver man page. Signed-off-by: Mike Isely --- Note: This patch was composed against the 2.2.1 driver as patch in Debian 2.2.1-1. However it should apply reasonably well against the upstream tree (I hope). man/intel.man | 87 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) Index: man/intel.man =================================================================== --- man/intel.man (.../patch-lvdsfixedmode) (revision 48) +++ man/intel.man (.../patch-man-lvdsfixedmode) (revision 48) @@ -182,6 +182,15 @@ causing a crash. If you find that your platform needs this option, please file a bug against xf86-video-intel at http://bugs.freedesktop.org which includes the output of 'lspci -v' and 'lspci -vn'. +.TP +.BI "Option \*qLVDSFixedMode\*q \*q" boolean \*q +Use a fixed set of timings for the LVDS output, independent of normal +xorg specified timings. The default value if left unspecified is +true, which is what you want for a normal LVDS-connected LCD type of +panel. If you are not sure about this, leave it at its default, which +allows the driver to automatically figure out the correct fixed panel +timings. See further in the section about LVDS fixed timing for more +information. .SH OUTPUT CONFIGURATION On 830M and better chipsets, the driver supports runtime configuration of @@ -255,6 +264,84 @@ with each output can be helpful if you need to ignore a specific output, for example, or statically configure an extended desktop monitor layout. +.SH HARDWARE LVDS FIXED TIMINGS AND SCALING + +Following here is a discussion that should shed some light on the +nature and reasoning behind the LVDSFixedMode option. + +Unlike a CRT display, an LCD has a "native" resolution corresponding +to the actual pixel geometry. A graphics controller under all normal +circumstances should always output that resolution (and timings) to +the display. Anything else and the image might not fill the display, +it might not be centered, or it might have information missing - any +manner of strange effects can happen if an LCD panel is not fed with +the expected resolution and timings. + +However there are cases where one might want to run an LCD panel at an +effective resolution other than the native one. And for this reason, +GPUs which drive LCD panels typically include a hardware scaler to +match the user-configured frame buffer size to the actual size of the +panel. Thus when one "sets" his/her 1280x1024 panel to only 1024x768, +the GPU happily configures a 1024x768 frame buffer, but it scans the +buffer out in such a way that the image is scaled to 1280x1024 and in +fact sends 1280x1024 to the panel. This is normally invisible to the +user; when a "fuzzy" LCD image is seen, scaling like this is why this +happens. + +In order to make this magic work, this driver logically has to be +configured with two sets of monitor timings - the set specified (or +otherwise determined) as the normal xorg "mode", and the "fixed" +timings that are actually sent to the monitor. But with xorg, it's +only possible to specify the first user-driven set, and not the second +fixed set. So how does the driver figure out the correct fixed panel +timings? Normally it will attempt to detect the fixed timings, and it +uses a number of strategies to figure this out. First it attempts to +read EDID data from whatever is connected to the LVDS port. Failing +that, it will check if the LVDS output is already configured (perhaps +previously by the video BIOS) and will adopt those settings if found. +Failing that, it will scan the video BIOS ROM, looking for an embedded +mode table from which it can infer the proper timings. If even that +fails, then the driver gives up, prints the message "Couldn't detect +panel mode. Disabling panel" to the X server log, and shuts down the +LVDS output. + +Under most circumstances, the detection scheme works. However there +are cases when it can go awry. For example, if you have a panel +without EDID support and it isn't integral to the motherboard +(i.e. not a laptop), then odds are the driver is either not going to +find something suitable to use or it is going to find something +flat-out wrong, leaving a messed up display. Remember that this is +about the fixed timings being discussed here and not the +user-specified timings which can always be set in xorg.conf in the +worst case. So when this process goes awry there seems to be little +recourse. This sort of scenario can happen in some embedded +applications. + +The LVDSFixedMode option is present to deal with this. This option +normally enables the above-described detection strategy. And since it +defaults to true, this is in fact what normally happens. However if +the detection fails to do the right thing, the LVDSFixedMode option +can instead be set to false, which disables all the magic. With +LVDSFixedMode set to false, the detection steps are skipped and the +driver proceeds without a specified fixed mode timing. This then +causes the hardware scaler to be disabled, and the actual timings then +used fall back to those normally configured via the usual xorg +mechanisms. + +Having LVDSFixedMode set to false means that whatever is used for the +monitor's mode (e.g. a modeline setting) is precisely what is sent to +the device connected to the LVDS port. This also means that the user +now has to determine the correct mode to use - but it's really no +different than the work for correctly configuring an old-school CRT +anyway, and the alternative if detection fails will be a useless +display. + +In short, leave LVDSFixedMode alone (thus set to true) and normal +fixed mode detection will take place, which in most cases is exactly +what is needed. Set LVDSFixedMode to false and then the user has full +control over the resolution and timings sent to the LVDS-connected +device, through the usual means in xorg. + .SH "SEE ALSO" __xservername__(__appmansuffix__), __xconfigfile__(__filemansuffix__), xorgconfig(__appmansuffix__), Xserver(__appmansuffix__), X(__miscmansuffix__) .SH AUTHORS