[RFC] drm: add overlays as first class KMS objects

[Jesse Barnes]

On Fri, 13 May 2011 18:16:30 +0200
Daniel Vetter <daniel.vetter at ffwll.ch> wrote:

> Hi Jesse,
> 
> Discussion here in Budapest with v4l and embedded graphics folks was
> extremely fruitful. A few quick things to take away - I'll try to dig
> through all
> the stuff I've learned more in-depth later (probably in a blog post or two):
> 
> - embedded graphics is insane. The output routing/blending/whatever
>   currently shipping hw can do is crazy and kms as-is is nowhere near up
>   to snuff to support this. We've discussed omap4 and a ti chip targeted at
>   video surveillance as use cases. I'll post block diagrams and explanations
>   some when later.

Yeah I expected that; even just TVs can have really funky restrictions
about z order and blend capability.

> - we should immediately stop to call anything an overlay. It's a confusing
>   concept that has a different meaning in every subsystem and for every hw
>   manufacturer. More sensible names are dma fifo engines for things that slurp
>   in planes and make them available to the display subsystem. Blend engines
>   for blocks that take multiple input pipes and overlay/underlay/blend them
>   together. Display subsytem/controller for the aggregate thing including
>   encoders/resizers/outputs and especially the crazy routing network that
>   connects everything.

How about just "display plane" then?  Specifically in the context of
display output hardware...

> 1) Splitting the crtc object into two objects: crtc with associated output mode
> (pixel clock, encoders/connectors) and dma engines (possibly multiple) that
> feed it. omap 4 has essentially just 4 dma engines that can be freely assigned
> to the available outputs, so a distinction between normal crtcs and overlay
> engines just does not make sense. There's the major open question of where
> to put the various attributes to set up the output pipeline. Also some of these
> attributes might need to be changed atomicly together with pageflips on
> a bunch of dma engines all associated with the same crtc on the next vsync,
> e.g. output position of an overlaid video buffer.

Yeah, that's a good goal, and pretty much what I had in mind here.
However, breaking the existing interface is a non-starter, so either we
need a new CRTC object altogether, or we preserve the idea of a
"primary" plane (whatever that means for a given platform) that's tied
to each CRTC, which each additional plane described in a separate
structure.  Z order and blend restrictions will have to be communicated
separately I think...

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center