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.
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 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.
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.
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.
i.e., don't check for the end of the list by ->name == NULL, since that
won't work now. Fix the consumers of xf86DefaultModes to use the new
explicit size as well.
In order to report accurate values to users of the RandR property interface,
it's sometimes necessary to ask the driver to update the value (for example
when backlight brightness changes without the server's knowledge, due to hotkey
events or direct sysfs banging).
This patch wires up the core server code with a new xf86CrtcFuncs callback,
get_property, to allow for this.
The new code is available under the RANDR_13_INTERFACE define, which in turn
depends on the RANDR_12_INTERFACE code.
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.
Due to an unwitting sense inversion when eliminating XkbFileInfo, we were
setting the complete wrong keymap on startup (non-XKB map if we had an XKB
map available, or the XKB map if we didn't have any available). Invert the
sense properly, and add two small bits that also went missing in that commit.
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.
