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.
Instead of removing the preference bit marking the hardware declared mode
preference, leave it in place and just move the user preferred mode to the
front of the list while marking it with the USERPREF bit which will cause it
to be selected by the initial mode selection code.
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.
When the PreferredMode option is selected in the config file, remove the
M_T_PREFERRED bit from all other preferred modes to force the config file
mode to be selected.
Code that disabled mode detection on disabled outputs would confuse
applications by listing said outputs as connected but without any modes.
This makes the disabled state in the config file affect only the initial
configuration and not subsequent modifications by RandR.
I made a mistake in some new code using MakeAtom, passing the size of the
string instead of the length of the string. Figuring there might be other
such mistakes, I reviewed the server code and found four bugs of the same
form.
at server startup, and not against the virtual X/Y parameters
as they can change.
This fixes an issue when canGrow is TRUE and modes get dropped
when using the virtual X/Y parameters.
Leaving devices enabled during server startup can cause problems during the
initial mode setting in the server, especially when they are used for
different purposes by the X server than by the BIOS. Disabling all of them
before any mode setting is attempted provides a stable base upon which the
remaining mode setting operations can be built.
Option "Enable" "True" will force the server to enable an output at startup
time, even if the output is not connected. This also causes the default
modes to be added for this output, allowing even sync ranges to be used to
pick out standard modes.
(cherry picked from commit a3d73ba2cb)
By default, use the screen monitor section for output 0, however, a driver
can change which output gets the screen monitor by calling
xf86OutputUseScreenMonitor.
(cherry picked from commit f4a8e54caf)
xf86SetSingleMode tries to resize all crtcs to match the selected mode. When
a CRTC has no matching mode, it now disables the CRTC (instead of crashing).
Also, poke the RandR extension when xf86SetSingleMode is done so that
appropriate events can be delivered, and so that future RandR queries return
correct information.
(cherry picked from commit dc6c4f6989)
Yes, two changes in one commit. Sorry 'bout that.
The first change ensures that when pending property values have been
changed, a mode set to the current mode will actually do something, rather
than being identified as a no-op. In addition, the driver no longer needs to
manage the migration of pending to current values, that is handled both
within the xf86 mode setting code (to deal with non-RandR changes) as well
as within the RandR extension itself.
The second change eliminates the two-call Create/AttachScreen stuff that was
done in a failed attempt to create RandR resources before the screen
structures were allocated. Merging these back into the Create function is
cleaner.
(cherry picked from commit 57e87e0d00)
Conflicts:
randr/randrstr.h
randr/rrcrtc.c
I think master and server-1.3-branch are more in sync now.
desiredX and desiredY were not recorded during xf86InitialConfiguration.
desiredX, desiredY and desiredRotation were not recorded during
xf86SetSingleMode.
(cherry picked from commit 36e5227215)
Pending Properties take effect when the driver says they do, so provide an
API to tell DIX when a property effect is made. Also, allow driver
to reject property values in RRChangeOutputProperty.
(cherry picked from commit 8eb288fbd6)
The rotation state is stored in the xf86_config structure which is not
re-initialized at server reset time. Clean it up at CloseScreen time.
(cherry picked from commit f8db7665dc)
Previous version used monitor identifiers if present, otherwise output
names. That caused existing working configurations to break when additional
information was added to the configuration file.
(cherry picked from commit 3f5cedf00a)
xf86SetDesiredModes applies the desired modes to each crtc (as selected by
xf86InitialConfiguration initially and modified by successful mode settings
afterwards). For crtcs without a desired mode, pScrn->currentMode is used to
select something workable.
(cherry picked from commit bcade98cca)
This function applies a single mode to the screen (as from RandR 1.1,
XFree86-VidModeExtension or XFree86-DGA) using a policy that selects one
output to reconfigure to the requested mode and then makes all other outputs
fit within that size.
(cherry picked from commit 5a595c1f76)
canGrow indicates to the DDX that the driver can enlarge the desktop via the
xf86_config->funcs->resize hook. If so, xf86InitialConfiguration will set
virtual[XY] to match the configuration it chooses and will leave the crtc config
size ranges alone. If FALSE, it will bloat the screen to fit the largest probed
mode and also set the crtc config max size to limit the desktop to the initial
virtual[XY] size.
This hook is called when the DDX needs to resize the screen. The driver is
responsible for changing virtualX and virtualY, along with any other related
screen properties (devPrivate.ptr, devKind, displayWidth, etc.).
Use the size range from the crtc config instead of randrp->virtual[XY] when
reporting the min and max screen sizes to the DDX.
in xf86CrtcSetMode, scrn->pScreen will be NULL during server startup time,
so don't try to set the subpixel order. subpixel order will be set in the
randr initialization anyways.
(cherry picked from commit 5f6f8616d8)
New modes header files required a few minor changes to be used by external
drivers, the most notable of which is the publication of the config file
parser header files.
Add monitor "Rotate" option taking one of "normal", "left", "inverted" or
"right". However, because initial mode selection is made before the screen
is completely initialized, we cannot create the shadow pixmap object at this
point. Pend the shadow pixmap creation until the block handler.
Note that this code is not completely functional yet.
RandR 1.0 sizeID must be computed the same way every time, so when reporting
it in the ScreenChangeNotify event, just construct the usual 1.0 data block
and use that.
subpixel geometry information can be computed by looking at the connected
outputs and finding any with subpixel geometry and using one of those for
the global screen subpixel geometry. This might be improved by reporting
None if more than one screen has information and they conflict.
This code comes from the intel driver, so there's no history in this tree.
As the crtc/output-based mode selection code uses ddc, the ddc and i2c
modules have been merged into the server. Attempts to load them are safely
ignored now.