On Mon, 25 Apr 2011 20:28:20 -0400 Alex Deucher alexdeucher@gmail.com wrote:
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 16:16:18 -0700 Keith Packard keithp@keithp.com 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.
Yes, that matches my understanding as well. I've deliberately made the implementation flexible there though, under the assumption that some hardware allows a plane to be directed at more than one CRTC (though probably not simultaneously).
A lot of older hardware had one overlay that could be sourced to any crtc, just not simultaneously. The tricky part is the formats and capabilities: alpha blending, color/chromakey, gamma correction, etc. Even the current crtc gamma stuff is somewhat lacking in in terms of what hardware is capable of (PWL vs. LUT, user defined conversion matrices, gamut remapping, etc.).
Right, this implementation allows an overlay to be tied to any crtc listed in the possible_crtcs mask (matching the other possible_* fields), but only one at a time. I think that's fairly common.
Agree about formats and capabilities. I think enumerating available formats is best, perhaps making that a driver specific array if we can't agree on a common set.
Dealing with color correction could also be driver specific; once the client has an overlay id it can use driver specific ioctls to get/set specifics.