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.
pixman 0.13.2 now holds all of the matrix operations. This leaves
the protocol conversion routines and some ABI stubs in place
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of using a separate function to notify DIX about transform changes,
add the transform to RRCrtcNotify so that the whole Crtc state changes
atomically.
RandR matrix computations lose too much precision in fixed point;
computations using the inverted matrix can be as much as 10 pixels off.
Convert them to double precision values and pass those around. These API
changes are fairly heavyweight; the official Render interface remains fixed
point, so the fixed point matrix comes along for the ride everywhere.
Add APIs to xf86RandR12 support and randr extension to record whether the
driver supports transforms, report that value in the RRGetCrtcTransform
reply.
Drivers that care about crtc positions on the screen to ensure that vblank
works correctly need to be notified when crtcs are changed.
Provide a hook in the mode setting code that is invoked whenever any
configuration is done to the screen.
Use this new hook in the DRI code so that DRI clients are notified and
receive updated information.
Signed-off-by: Keith Packard <keithp@keithp.com>
When a user specifies the position of an output for which no modes exist
(for whatever reason) assume that the width and height of this output
is 0. The result will be the same as if this output isn't taken into
consideration at all and thus should be sane. It will prevent a segfault
when trying to determine the width and height of a non-existent mode.
In the single output enabled case we never enter the loop and test
never gets set and so we fail to match a good mode.
This was causing my 2560x1600 to end up at 2048x1536.
If the monitor isn't reduced-blanking (either through EDID logic, or
config file setting), then remove RB modes from the default pool. Any
RB modes from the driver and config file pools will stick around though;
you asked for them, you got them.
The first guess used to be "is the preferred mode for one output the
preferred mode on all outputs". Instead, do "find the largest mode that's
preferred for at least one output and available on all outputs".
Old logic was just the first one that happened to have an associated
CRTC. The new logic tries to find one that's definitely connected, has
probed modes, and has the largest candidate mode.
Should have done this in the first place. Since we're checking for the absence
of the get_crtc callback in the first place, we'll short circuit the later call
and disable the output, so the ugly "continue" block is unnecesary.
By adding a new output callback, ->get_crtc, xf86SetDesiredModes is able to
avoid turning off outputs & CRTCs if the current output<->CRTC mappings are the
same as the desired configuration. This helps avoid flickering displays at
startup time, which speeds things up a little and looks better.
Actually more like in the mainline case, where the ideal mode happens to
be the very first aspect match on the first monitor. But let's not
split hairs.
Old heuristic was to find the first monitor that expressed a preference,
then attempt to get all other monitors to agree. This doesn't work
particularly well when the two sets of modes don't precisely intersect,
you get overlapping-but-not-identical output geometry and things go wrong.
New heuristic is:
- Exact user preference, if given
- Exact output preference, if the same for all outputs
- Best (largest) mode of modes common to all outputs:
- with the same aspect ratio as all outputs (may be NULL)
- with 4:3 aspect ratio
- Then the old heuristic to try to get something lit
Note that it is simply not doable to have a reliable initial output guess if
you insist on trying to clone all outputs together. It's far too easy to
end up with displays that simply don't have modes in common. We need to
switch to right-of placement someday, once we're not limited to CRTC size
limits and we have working multi-GPU in RANDR.
If you don't do this, then Modes "800x600" in the Display subsection will
be dutifully ignored and the driver will start at whatever resolution it
feels like.
