On Tue, 26 Apr 2011 18:20:03 +0300 Ville Syrjälä syrjala@sci.fi wrote:
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Overlays are a bit like half-CRTCs. They have a location and fb, but don't drive outputs directly. Add support for handling them to the core KMS code.
Are overlays/underlays not associated with a specific CRTC? To my mind, overlays are another scanout buffer associated with a specific CRTC, so you'd create a scanout buffer and attach that to a specific scanout slot in a crtc, with the 'default' slot being the usual graphics plane.
And what if you don't have a "default" plane as such. For example, OMAP3 has one graphics plane and two video planes, and two output paths. Each of the planes can be assigned to zero or one outputs. To accomodate this, the design should allow for CRTCs without any scanout buffers.
Also a glance at DirectFB and OpenWF Display APIs might be helpful.
The current drm crtc code ties together a crtc and fb, but it wouldn't be too hard to split it out a little (such that passing a null fb on a mode set wouldn't disable the crtc, or attaching a new scanout surface to a crtc would enable it) to support something like that.