v1->v2: Make one condition case for one quirk instead of merging them
together. This is based on the Keithp's suggestion.
Move the EDID quirk for Philips LCD LP154W01 as the panel reports the vertical
size in cm.
https://bugs.freedesktop.org/show_bug.cgi?id=24482
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The message ending up in the log is misleading as to what the quirk
actually does: It ignores the sizes in the detailed timings and
replaces them with the display "Max Image Size".
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If either width or height of DisplaySize is invalid, assume that the
configuration is invalid and use the DDC-reported values instead.
See Comment 9, Bug 9758.
http://bugs.freedesktop.org/show_bug.cgi?id=9758#c9
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Dave Airlie <airlied@redhat.com>
It reports vertical size in cm in the detailed mode.
X.Org bug#21750 <http://bugs.freedesktop.org/show_bug.cgi?id=21750>
Reported-by: Peter Poklop <Peter.Poklop@gmx.at>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This panel reports its vertical size in cm.
X.Org bug#21000 <http://bugs.freedesktop.org/show_bug.cgi?id=21000>
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
All you get for standard timing descriptors is horizontal size in
multiples of 8 pixels (which means you can't say 1366) and height in
terms of aspect ratio (which means you can't say 768). You'd like to
just fuzzy-match this by walking the DMT list for sufficiently close
modes, but you can't because DMT is useless and only defines a 1360x768
mode, because it's _also_ specified in terms of character cells despite
providing pixel exact timings. Neither can you use CVT or GTF to
generate the timings, because they _also_ believe that modes have to be
a multiple of 8 pixels.
You'd also hope you could find a timing definition for this in CEA, but
you can't because CEA only defines transmission formats that actually
exist. So there's 480p, 720p, and 1080p, but no 768p. And why would
there be, after all, the encoded signal is never 768p so obviously no
one would ever make a display in that format.
So instead, make a CVT mode since that's likely to be handled well by
just about everything, smash the horizontal active down by 2, and shift
the sync pulse by 1. Underscanning the hard way.
Pass the suicide.
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
This patch exports all symbols required by the compilable
(in a x86 linux computer) xorg/driver/* modules.
Still missing symbols worth mentioning are:
sunleo
miFindMaxBand no longer available
intel (uxa/uxa-accel.c)
fbShmPutImage no longer available (and should have been static)
mga
MGAGetClientPointer (should come from matrox's libhal)
This is not a definitive "visibility" patch, as all it does is to
export missing symbols, but the modules that current don't compile,
may require more symbols once fixed, and third party drivers should
also require more symbols exported.
A "definitive" patch should export symbols defined in the sdk.
Includes fixes for:
"xf86Config.c", line 2434: warning: argument #1 is incompatible with prototype:
prototype: pointer to struct _DisplayModeRec: "xf86.h", line 351
argument : pointer to const struct _DisplayModeRec
"xf86EdidModes.c", line 312: warning: argument #1 is incompatible with prototype:
prototype: pointer to struct _DisplayModeRec: "../../../hw/xfree86/common/xf86.h", line 351
argument : pointer to const struct _DisplayModeRec
"xf86EdidModes.c", line 438: warning: assignment type mismatch:
pointer to struct _DisplayModeRec "=" pointer to const struct _DisplayModeRec
"xf86Modes.c", line 701: warning: assignment type mismatch:
pointer to struct _DisplayModeRec "=" pointer to const struct _DisplayModeRec
- Use a single common function to compute reducedness.
- Call it from both the old-school and new-school mode validation paths.
- Define monitor reduced-blanking support in accord with EDID 1.4.
- Attempt to filter RB DMT modes away from the "standard" EDID pool if
the monitor doesn't claim RB support.
On some panels you end up with all of:
- No range descriptor
- No description of physical connectivity
- Native panel size mode in standard timings list
In principle you're supposed to use the timings for that mode from the DMT
spec, but in practice the DMT spec has timings for both 1920x1200 normal
and 1920x1200RB, and the standard timing field gives you no way to
distinguish. And, of course, the non-RB timings don't fit in a single
DVI link.
CVT is enough different from GTF that it should not be used on monitors
that aren't expecting it. This brings us closer to what the spec says
the correct behaviour is.
A lot of EDID writers apparently end up stuffing centimeters (like the
maximum image size field) into the detailed timings, instead of millimeters.
Some of them only get it wrong in one direction. Also, add a quirk to let
us mark the largest 75hz mode as preferred, which will often be used for
EDID 1.0 CRTs.
As a result, we can remove the quirks that existed to flip the bits back around
for us. This is not confirmed in all cases due to lack of bugs containing EDID
blocks associated with the quirks, but is likely true.
