On Fri, 13 May 2011 18:16:30 +0200 Daniel Vetter <daniel.vetter@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
