On Mon, 25 Apr 2011 20:28:20 -0400 Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 25 Apr 2011 16:16:18 -0700 > > Keith Packard <keithp@xxxxxxxxxx> wrote: > > > >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
