Sprite transforms in RandR

[Ville Syrjälä]

On Tue, Dec 07, 2010 at 07:47:28AM -0800, ext Keith Packard wrote:
> On Tue, 7 Dec 2010 15:44:36 +0200, Ville Syrjälä <ville.syrjala at nokia.com> wrote:
> 
> > Say, for example, that you have a portrait scanned LCD (which has it's
> > own memory) and TV out, and let's say you want everything to be in
> > landscape all the time. The LCD could do the required 90/270 degree
> > rotation for free (since it has it's own memory), and for TV out you
> > then want no rotation. In this case you probably don't want to use VRFB
> > (the rotation thingy Daniel mentioned), since all memory access would
> > happen in landscape direction, and VRFB's tile format would make that
> > less efficient.
> 
> Does the TV out support rotation in hardware at all?

There are three places where you can do the rotation.

1. VRFB rotation in SDRAM controller. Physical memory in tiled layout,
accessed through mmio windows to make it look linear. The hardware
provides four windows for each VRFB context, one for each roation
angle.

2. DMA rotation in the display controller. Using this for 90/270 degree
rotation with SDRAM is a bad idea due to the sub optimal memory access
pattern. It's really meant to be used only if you put the framebuffer
into OMAP internal SRAM, but the SRAM is generally too small to be
useful.

3. Display rotation, in case the display has it's own memory.

1 and 2 are always available. 3 depends on the display hardware. For
example the N900 display doesn't support option 3, so VRFB is used.

> > So if you can specify 90 degree rotation for one CRTC and 0 degree for
> > another, the driver could allocate the pixmap in the most efficient
> > format. If you have just one rotation parameter the driver would have
> > no choice but to assume that rotation will be used even with the TV out,
> > and thus would be forced to use VRFB all the time.
> 
> Hrm. Right now, there is per-CRTC rotation support information, so you
> can tell whether a particular CRTC does rotation at all, of course
> that's all mixed in with the software rotation support in the server
> which I'm hoping to deprecate when compositing managers gain appropriate
> built-in rotation support.
> 
> If we remove the software rotation support, and expose only 'native'
> rotation in the per-CRTC information, then the question about
> SCANOUTPIXMAPINFO is whether two CRTCs need a *different* format for the
> same rotation.
> 
> In you case, I think you'd set the CRTC that could drive the TV as
> supporting only RR_Rotation_0 and the CRTC that could drive the LCD as
> supporting RR_Rotation_0|RR_Rotation_90|RR_Rotation_270.

That would work although perhaps it's a bit limiting.

I suppose you could have a device that supports two operation
modes, where in one you'd want to rotate only the LCD, and in the
other you'd want to rotate the TV out as well. So in this case the
driver would always need to use VRFB even in the LCD only rotation
mode.

If CreateScanoutPixmap would take a list of CRTCs, and for each
CRTC a list of rotations, then the driver could choose the optimal
format for the pixmap. Not sure if that's worth the effort though.

> Or do we need separate per-*output* rotation information which is
> distinct from the CRTCs too?

I don't think that's necessary, at least for OMAPs.

-- 
Ville Syrjälä