GitLab

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>

PictureTransformBounds can fail, when this happens, damage the entire screen
so that the shadow gets repainted correctly.

Doing projective transforms required repositioning the cursor using the
hotspot, but that requires relocating the upper left corner in terms of said
hotspot.

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.

Track curent transform down in the mode setting code so that it may be set
separately from RandR.

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.

This eliminates some ugly flashing, as well as clearing the borders when the
shadow will not be completely painted.

Create new RRTransform datatype to hold all of the transform related
information, use that in lots of places to pass filters around.

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

New RRCrtcGetTransform function in DIX that DDX can use to get the pending
transform. The DDX code should be complete; the DIX code is just a stub at
this point.

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.

- Redo damage naming for more consistency.
- Call post submission functions only where appropriate.
- EXA can now live without it's odd damage workarounds.

TODO: static indices can be made just an int; some indices
can be combined.

Replaces the use of the screen pointer itself as the key, which was
nice but won't work now that an array index is being stored.

- 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.

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