GitLab

This involved removing a pile of matrix code from the DDX,
as well as moving a bit of transform logic from DDX to DIX.

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 an EDID is present, only add the default mode pool if the
continuous-frequency bit is set in the EDID.  Should fix bugs
like 18512.

If there's no preferred mode, but only one monitor, pick the
biggest mode for its aspect ratio, assuming one exists.

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 case no enabled outputs, we will reference wrong index of
output array.

- Fix is courtesy of math_b.

This was all kinds of broken, we ignored user preferred modes for multiple
monitors and also for side-by-side configurations.

this fixes a crash I was getting on radeon rotate when gnome is running.
I'm sure g-s-d was doing something bad, but really not crashing ftw.

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.

Seems to have been accidentally lost by commit 	76943fec860315f3c93539e59a59080b8a7b3e75

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 fix in fa19e847 was incomplete,
as it was still using the wrong output's initial rotation to compute
the position.

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.

Necessary to allow drivers to be run-time backwards compatible when using the
modes/ functions w/o providing their own copy.

Thanks to Zhenyu Wang for finding this.

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.

For kernel modesetting work we need a bigger stick to beat the modesetting path

Some modes claimed in monitor EDID data may not be supported by
the monitor. So also validating the max clock for probed modes.

max clock from EDID data is in MHz, while we need KHz to validate modes.

quite how this has worked I've no idea.

Otherwise you end up with a confusing initial geometry, and xscreensaver
and friends get very angry.

Fixes memory corruption if a too small "Virtual" was specified in xorg.conf
for the selected multi-monitor configuration.