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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
