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.
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