| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
ba2d39dd5428cb5922b797a1d4ea45b859412b40 introduced warnings:
xf86Mode.c: In function ‘xf86CheckModeForDriver’:
xf86Mode.c:986: warning: passing argument 1 of ‘modeInClockRange’ from incompatible pointer type
xf86Mode.c:253: note: expected ‘ClockRangePtr’ but argument is of type ‘ClockRangesPtr’
xf86Mode.c:1002: warning: passing argument 1 of ‘modeInClockRange’ from incompatible pointer type
xf86Mode.c:253: note: expected ‘ClockRangePtr’ but argument is of type ‘ClockRangesPtr’
Because I foolishly didn't notice that we had types with nearly
identical members named ClockRange and ClockRanges. The latter
contained an extra 'strategy' member at the end, which claimed to be
needed by the vidmode extension. Of course, this was a lie: the only time
we'd use it was in mode validation, for drivers using LOOKUP_CLKDIV2 with
non-programmable clocks. The only driver using LOOKUP_CLKDIV2 is
rendition, which has a programmable clock. The only driver using the
ClockRanges type was smi, which did not use it for its 'strategy' member,
so has been fixed to use ClockRange instead.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
This code all lives in xf86Modes.c now anyway
|
|
This was a vestige from the days before we'd make the mode list from the
EDID data, and from CRT technology when you could reasonably assume that
higher refresh rates were better. Also it did not function as advertised,
acting as a high-pass filter instead of a band-pass.
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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).
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
cosmetic.
|
|
linePitch.
|
|
Code added in hw/xfree86/modes came from the server-1.3-branch.
Portions of this code had previously been integrated into xf86Mode.c
and edid_modes.c.
To preserve hw/xfree86/modes as much as possible, the duplicate code from
the other files has been disabled; a more careful review would figure out
where that code actually belonged.
|
|
Typical results were failure to sync, and a black screen.
|
|
Our modes typically come from EDID or default modes, and when the monitor
asks for a specific mode, deciding to tweak it usually results in incorrect
display. And if the user is specifying a mode by hand, tweaking it then is
still pretty rude.
Reviewed by: ajax
|
|
|
|
Conflicts:
dix/events.c
dix/getevents.c
hw/xfree86/common/xf86Mode.c
hw/xfree86/dri/Makefile.am
hw/xfree86/os-support/drm/xf86drm.c
hw/xfree86/os-support/xf86drm.h
|
|
This also removes static from some other functions that had been copied out
to at least the intel driver, but perhaps others that were doing mode list
handling.
|
|
CVT reduced blanking modes are typically only seen on digital connections to
LCDs, but there are some monitors that report them as supported over the
VGA connector too, which is perfectly legitimate, electrically speaking.
|
|
Well, kinda. Strictly we prefer M_T_BUILTIN strongest since those are modes
where the driver has said it absolutely can't do anything else (VBE). Then
we look for user-defined modes, ie, modelines from the config file. Then
we consider modes reported by the monitor via EDID. Finally if nothing has
matched yet we consider the default mode pool.
Within each of the above-mentioned classes, modes with the M_T_PREFERRED bit
take priority over other modes in the same class.
This logic ensures that the timings sent to the monitor exactly match the
timings it reported as supported, which occasionally don't match the numbers
you might get for that mode from CVT or GTF.
|
|
This allows the server to guess an appropriate initial virtual size and
resolution. The heuristic is to select the largest driver-reported mode
that matches the monitor's physical aspect ratio. We revalidate this
estimate after mode validation, since we may have filtered away all
modes that would fill that size.
Also, the EDID preferred timing is now marked as M_T_PREFERRED as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gtf timing to below 25%), only stop cvt reduced blanking. Users should
be free to blow up their monitors if they so choose.
|
|
- add hw/xfree86/utils/cvt/, cvt.c, cvt.man.pre and Makefile.am.
- Adjust configure.ac and hw/xfree86/utils/Makefile.am for cvt.
- Add MonPtr->reducedblanking and Option "ReducedBlanking" to the Monitor
section.
- Check for reduced blanking in xf86CheckModeForMonitor and disallow modes
with less than 25% blanking otherwise.
- Fix some warnings in hw/xfree86/common/xf86Config.c.
|
|
|
|
Add XSERV_t, TRANS_SERVER, TRANS_REOPEN to quash warnings.
Add #include <dix-config.h> or <xorg-config.h>, as appropriate, to all
source files in the xserver/xorg tree, predicated on defines of
HAVE_{DIX,XORG}_CONFIG_H. Change all Xfont includes to
<X11/fonts/foo.h>.
|
|
|
|
number of preallocated slots. We should really make this dynamic - but
I don't think this ever caused a problem so it's more or less academic.
A. Avoid that *SyncStart starts before *BlankStart. If *BlankStart >
*SyncStart it is made = *SyncStart and its width is made maximal but such
that the blank does not exceed *Total. Since the Sync width has the
same restrictions as the Blank width monitors should still be able to
clamp after the sync pulse. B. Over time mode validation has become
inconsistent when people started to add additional features to the mode
validation. One such feature is that the mode->Crtc* values have been
(ab)used to allow the driver ValidMode() function to pass driver
normalized timing values back to the validation function. The
introduction of these features made the code less readable and created
numerous possibly unintended side effects in the validation semantics.
I've attempted to consolidate these changes making the code more
consistent and eliminating a number of side effects. This should not
cause problems for the majority of drivers, still it should receive
testing - especially with ATi Mach64 and Radeon code. (Bugzilla #3325).
|
|
change "foo.h" to <X11/foo.h> for core headers, e.g. X.h, Xpoll.h;
change "foo.h", "extensions/foo.h" and "X11/foo.h" to
<X11/extensions/foo.h> for extension headers, e.g. Xv.h;
change "foo.[ch]" to <X11/Xtrans/foo.[ch]> for Xtrans files.
|
|
|
|
|
|
|
