[RFC] drm: add overlays as first class KMS objects
jbarnes at virtuousgeek.org
Fri May 13 18:02:56 PDT 2011
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...
Jesse Barnes, Intel Open Source Technology Center
More information about the dri-devel