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.

Dereferencing the NULL mode pointer would cause a crash. As these transform
matrices won't be used while the CRTC is disabled, just leave their values
alone.

Need to compute and save the global transform when the driver changes it.

When the transform management was moved from randrstr.h, the associated
header file became necessary to build drivers. Include it as a part of the
sdk headers.

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.

PictureTransformPoint computes homogeneous coordinates internally, but fails
to handle intermediate values larger than 16.16. Use 64 bit intermediate
values while computing the final result at 16.16 and only complain if that
result is too large.

PictureTransformIsIdentity was completely wrong -- it was not checking for
identity transforms at all.

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.

It is easier, and potentially more precise, to compute the inverse in the
server where everything can eventually be kept in floating point form.

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.

This reduces the matrix representation error after inverting a
transformation matrix (although it doesn't eliminate it entirely).

Perhaps we should extend Render to include 64-bit floating point transforms...

It doesn't make sense to have the client invert this matrix when the server
can do so reasonably efficiently. This avoids weird fixed point rounding
errors when testing the transform against its inverse. Now to fix the
protocol.

The obvious matrix inversion function, coded using doubles to avoid fiddling
with fixed point precision adventures.

This width/height value lets filter users know how far the filter spreads
into the source image.

Report transformed crtc sizes through RandR and Xinerama. Test screen size
against transformed mode sizes when configuring the Crtc.

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

To prepare for RandR using filters in transforms, split out
code paths so that the RandR code can validate the filter name and
parameters during the transform set operation so that use of the filter
later will not have unreportable errors.

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

The render extension uses many matrix operations internally, this change
exposes those functions to other parts of the server, drivers and
extensions. The change is motivated by the 'transform' additions to the
RandR extension but will likely be useful elsewhere.

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>

Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>

The xfree86 server previously hat NewInputDeviceRequest and InitInput, and
both basically did the same thing. Reduce NIDR to parameter checking and use
xf86NewInputDevice from both InitInput and NIDR to actually create the device.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>

VCP and VCK are always present, this comment is a leftover from earlier MPX
days.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>