X server 1.6 release schedule

[Adam Jackson]

On Wed, 2008-11-19 at 09:25 -0800, Keith Packard wrote:
> On Wed, 2008-11-19 at 10:12 -0500, Adam Jackson wrote:
> 
> > I think it's most natural to do this as additional border fields in a
> > MODEINFO.  Imagine a new definition:
> 
> I'd say adding a new border size and color request would be easier;
> you'd set the pending border size/color and then set the mode, just like
> properties. One question is whether we'd bother doing a driver-specific
> API or whether we'd just allocate the larger frame buffer, paint the
> border, and then just use a subset of that for the screen.

That works.  I hadn't really thought through the implication that
projective transforms meant modes != crtc sizes.

The advantage to letting the driver do explicit border control is that
it need only allocate enough memory for the active region.  Besides the
raw memory savings, it also means you save memory bandwidth (in the
absence of framebuffer compression, but even with it when the screen
changes), which in turn means lower power, and everybody loves that.

But the other way means the driver need not have any explicit border
knowledge, and that's also cool.  Also you could do some really crazy
hacks like specify the border as a pixmap instead of a color...

Could do either one as a first pass, I suppose.

- 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/406354b8/attachment.pgp>