[PATCH 09/10] MCDE: Add build files and bus

[Rob Clark]

On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
>> This doesn't seem that different from the graphics chips we support
>> with kms.  I don't think it would require much work to use KMS.  One
>> thing we considered, but never ended up implementing was a generic
>> overlay API for KMS.  Most PC hardware still has overlays, but we
>> don't use them much any more on the desktop side.  It may be
>> worthwhile to design an appropriate API for them for these type of
>> hardware.
>
> Just fyi about a generic overlay api: I've looked a bit into this when
> doing the intel overlay support and I think adding special overlay crtcs
> that can be attached real crtcs gives a nice clean api. We could the reuse
> the existing framebuffer/pageflipping api to get the buffers to the
> overlay engine.

btw, has there been any further thought/discussion on this topic..
I've been experimenting with a drm driver interface on the OMAP SoC.
It is working well now for framebuffer type usage (mode setting,
virtual framebuffer spanning multiple diplays, and those types of
xrandr things)..  the next step that I've started thinking about is
overlay (or underlay.. the z-order is flexible) support..

I was thinking in a similar direction (ie. a special, or maybe not so
special, sort of crtc) and came across this thread, so I thought I'd
resurrect the topic.

In our case, most of the CRTCs in our driver could be used either with
(A)RGB buffers as a traditional framebuffer, or with a few different
formats of YUV as video under/overlays.  So if you had one display
attached, you might only use one CRTC for traditional GUI/gfx layer,
and the rest are available for video.  If you had two displays, then
you'd steal one of the video CRTCs and use it for the gfx layer on the
second display.  And so on.

Rough thinking:
+ add some 'caps' to the CRTC to indicate whether it can handle YUV,
ARGB, scaling
+ add an x/y offset relative to the encoder (as opposed to the
existing x/y offset relative to the framebuffer)
+ add a z-order parameter

Not sure about intel hw if it is supporting clip-rects.. if so, maybe
need to add something about that.  In our case we jut put the video
behind the gfx layer and use the alpha channel in the gfx framebuffer
to clip/blend rather than using clip-rects.


> The real pain starts when we want format discovery from userspace with all
> the alignement/size/layout constrains. Add in tiling support and its
> almost impossible to do in a generic way. But also for kms userspace needs
> to know these constrains (implemented for generic use in libkms). I favor
> such an approach for overlays, too (if it ever happens) - i.e. a few
> helpers in libkms that allocate an appropriate buffer for a given format
> and size and returns the buffer, strides and offsets for the different
> planes.

hmm, I guess I know about the OMAP display subsystem, and it's overlay
formats/capabilities.. but not enough about other hw to say anything
intelligent here.  But I guess even if we ignore the format of the
data in the buffer, at least the APIs to setup/attach overlay CRTCs at
various positions could maybe be something we can start with as a
first step.  At least standardizing this part seems like a good first
step.  But I'm definitely interested if someone has some ideas.

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>