On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
quoted text
> 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.

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.

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