Sprite transforms in RandR

I can't remember whether it was Aaron or Andy, but a couple of years ago
they talked about not being able to move the nVidia driver to RandR 1.2
because it didn't want to get the mode setting instructions in pieces.
Memory allocation and various hardware limits meant that there were many
configurations which could be satisfied, but only if the whole
configuration could be reviewed by the driver.
As a part of the RandR 1.4 work, I've added a new request,
RRSetCrtcConfigs which sends all of the changes at one time:
Here's what you send for each CRTC to be configured:
+CRTCCONFIG { crtc: CRTC
+ x, y: INT16
+ mode: MODE
+ rotation: ROTATION
+ sprite_position_transform: TRANSFORM
+ sprite_image_transform: TRANSFORM
+ outputs: LISTofOUTPUT
+ pixmap: PIXMAP
+ pixmap_x, pixmap_y: INT16 }
And here's the new request.
+┌───
+ RRSetCrtcConfigs
+ drawable: DRAWABLE
+ screen-pixmap-width: CARD16
+ screen-pixmap-height: CARD16
+ screen-width: CARD16
+ screen-height: CARD16
+ width-in-millimeters: CARD32
+ height-in-millimeters: CARD32
+ configs: LISTofCRTCCONFIG
+ ▶
+ status: RRCONFIGSTATUS
+└───
+ Errors: Value, Match
+
+ This works much like RRSetScreenSize followed by a sequence of
+ RRSetCrtcConfig, except that the entire configuration is set
+ in a single operation, either succeeding or failing without
+ any partial execution. In particular, the requested screen pixmap
+ size need only be large enough to hold the final
+ configuration, not the starting or any intermediate
+ configuration. Note that the sprite transforms are also included
+ in this request making for truely one-stop shopping.
This has some extra stuff for per-crtc pixmaps which isn't merged into
the server yet, otherwise it's just a complete list of all of the stuff
that you need to send to configure a screen.
One interesting change here is that it includes separate screen and
screen-pixmap size information. That allows you to create a larger
virtual space than is supported by the hardware, again for per-crtc
pixmap stuff. This also isn't implemented yet, although it won't be all
that difficult, just need to trim the root clip lists to the screen
pixmap as well as the root window size.
For drivers, very little has changed. Drivers are given the opportunity
to add a hook that will be called during operation of the new
request. This lives in the xf86CrtcConfigFuncsRec which is passed from
the driver when it calls xf86CrtcConfigInit:
xf86SetConfigResponse
(*set_config) (ScrnInfoPtr scrn,
RRScreenConfigPtr screen_config,
xf86CrtcSetConfigPtr crtc_configs,
int num_configs);
This function can do one of four things:
1) Not exist at all. If set_config is NULL, the server
will just invoke the existing mode setting hooks in
sequence, recovering if any of them return an error
and restoring the previous configuration.
2) Return xf86SetConfigFailed. In this case, the server
abandons attempts to do the mode setting and returns
a failure indication back to the client.
3) Return xf86SetConfigDone. If the driver can handle
the whole mode setting operation internally, it may
return this value, at which point the server just tells
the client the happy news without doing anything to the
hardware itself.
4) Return xf86SetConfigChecked. This says that the driver has
validated the arguments, and things look fine, but it
hasn't done any mode setting. In this case, the server
will use the existing mode setting hooks and try to
configure the device, as in case 0) above.
Would it be useful to be able to return more information from the server
to the application? How would such information get encoded?
I've changed 'xrandr' to always use this new function if available.
As with the sprite transform changes, everything here is available from:
Protocol changes:
git://people.freedesktop.org/~keithp/randrproto master
Library changes:
git://people.freedesktop.org/~keithp/libXrandr master
xrandr changes:
git://people.freedesktop.org/~keithp/xrandr master
xserver changes:
git://people.freedesktop.org/~keithp/xserver randr-1.4-subwork
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101204/5888f99a/attachment.pgp>