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 -- Daniel Vetter Mail: daniel@xxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
