Per CRTC pixmaps

[Keith Packard]

I've managed to get the bulk of the per-crtc pixmap code integrated this
evening, and hacked up xrandr to paint a nice gradient when asked to
create one.

As you note, the protocol for specifying the scanout pixmaps in mode
setting was actually added in the previous patch, it just didn't do
anything useful.

Here's the protocol spec changes for scanout pixmaps:

+5.4. Protocol Types added in version 1.4 of the extension
+
+SCANOUTPIXMAPINFO { format: PICTFORMAT
+                   maxWidth, maxHeight: CARD16
+                   rotations: SETofROTATION }
+                 

+7.3. Extension Requests added in version 1.4 of the extension.
+
+┌───
+    RRQueryScanoutPixmaps
+       window: WINDOW
+      ▶
+        infos: LISTofSCANOUTPIXMAPINFO
+└───
+       Errors: Window
+
+       This request returns information about the server support for
+       alternate scanout pixmaps. For each pictformat, there is a set
+       of rotations and a maximum supported size. The rotations here
+       are those provided by the scanout hardware itself, not by a
+       software emulation.
+
+┌───
+    RRCreateScanoutPixmap
+       pixmap: PIXMAP
+       drawable: DRAWABLE
+       width, height: CARD16
+       format: PICTFORMAT
+       rotations: SETofROTATION
+└───
+       Errors: Drawable, Match, Value
+
+       Creates a pixmap which can subsequently be used as a scanout
+       buffer for the screen associated with 'drawable'. 'rotations' is
+       the set of rotation values which may be used with the
+       resulting scanout buffer. 'rotations' must be a subset of the
+       supported rotations or a Match error results. width and height
+       must be within the supported range or a Value error
+       results. 'format' must be one of the supported formats or
+       Match error results.
+

The library interfaces use the XRenderPictFormat instead of just
PictFormat to make them a bit more compatible with Xrender.

Inside the server, the changes are all quite minor. Drivers supporting
per-crtc pixmaps are expected to call

        +void
        +xf86CrtcSetScanoutFormats(ScrnInfoPtr		scrn,
        +			  int			num_formats,
        +			  xf86CrtcScanoutFormat	*formats)

at startup time (the same time you'd call xf86CrtcSetSizeRange). The
xf86CrtcScanoutFormat structure has some fairly obvious fields:

        +typedef struct _xf86CrtcScanoutFormat {
        +    int		    depth;
        +    int		    bitsPerPixel;
        +    int		    maxWidth, maxHeight;
        +    Rotation	    rotations;
        +    PictFormatShort format;
        +} xf86CrtcScanoutFormat;
        +

The driver owns the storage for this structure, it is not freed by the
server.

Then, the driver adds a new function to the xf86CrtcConfigFuncsRec:

        +
        +    /**
        +     * Create a scanout pixmap
        +     */
        +    PixmapPtr
        +    (*create_scanout_pixmap)(ScrnInfoPtr		scrn,
        +			     int			width,
        +			     int			height,
        +			     Rotation			rotations,
        +			     xf86CrtcScanoutFormat	*format);

The driver should track which pixmaps are scanout pixmaps and reject
mode setting to any non-scanout pixmaps. DIX isn't currently tracking
which ones are 'magic'.

Once you've got these two pieces done, you can expect to see the
crtc->scanoutPixmap value point at real pixmaps during mode setting.

-- 
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/20101205/b820a225/attachment.pgp>