X server 1.6 release schedule

[Adam Jackson]

On Tue, 2008-11-18 at 16:25 -0800, Keith Packard wrote:
> On Tue, 2008-11-18 at 18:23 -0500, Adam Jackson wrote:
> 
> > Overscan correction?  I don't think this counts as a subset of
> > projective transforms, but I could be wrong.
> 
> No, not a part of projective transforms as it doesn't change the
> pixel->pixel mapping.
> 
> It sounds useful; get some code together along with a spec update and we
> can ship it too.

I'm not hurting for it, so I'm not likely to kill myself to get it into
1.3.  But, maybe!  Or maybe someone else feels inspired.

I think it's most natural to do this as additional border fields in a
MODEINFO.  Imagine a new definition:

MODEINFO { id: MODE
           name: STRING
           width, height: CARD16
           dotClock: CARD32
           hSyncStart, hSyncEnd, hTotal, hSkew, hBorder: CARD16
           vSyncStart, vSyncEnd, vTotal, vBorder: CARD16
           borderColor: COLOR
           modeFlags: SETofMODEFLAG }

800x600 active area in a standard 1920x1200RB timing would then be:

{
	xid,
	"800x600u1920x1200",
	800, 600,
	154000,
	1968, 2000, 2080, 0, 560,
	1203, 1209, 1235, 300,
	0x00000000,
	HSyncPositive, VSyncNegative
}

Note that borders are symmetric, and are specified as the distance
between timing active area and pixel active area.

There's sort of a tight binding in randr between (width,height) of a
mode and the CRTC dimensions, so while you _could_ do it the other way
around and give a plain 1920x1200 mode in the timings plus oh yeah
here's some border fields, it would make computing the rest of the world
more complicated.

Also you'd have to accomodate the older MODEINFO wire encoding for older
clients, but that's nothing new.  Since you can't modify modes in place
this works out fine: a 1.2 client against an otherwise 1.3 server just
never sees the border fields, always create modes with 0 borders, and
applies modes including hidden border fields if the mode happens to have
them since you apply by XID not by full timing.

Then, of course, there's the problem of defining how bordered modes are
represented internally.  The DisplayModeRec does have border fields, but
only in the hardware representation set, not in the user visible set.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081119/7f7cbe3d/attachment.pgp>