On Wednesday, 20 June 2018 13:10:07 MSK Daniel Vetter wrote: > On Wed, Jun 20, 2018 at 11:33 AM, Russell King - ARM Linux > > <linux@xxxxxxxxxxxxxxx> wrote: > > On Wed, Jun 20, 2018 at 11:17:50AM +0200, Daniel Vetter wrote: > >> Yes -modesetting (or whichever other driver) would need to set up the > >> properties correctly for Xvideo color keying. Since default assumption > >> for > >> all other (generic) compositors is that planes won't do any color keying > >> in the boot-up state. > > > > Thanks, is that documented anywhere? > > With the standardization of properties I'm also trying to get these > expectations better documented, e.g. > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-prop > erties > > But I think we're not doing a good job yet documenting default > expectations. But the above would be a good place to get that fixed - > this patch here should do that, at least for color keying. > -Daniel There is a comment in this patch that says: + * colorkey.mode: + * The mode is an enumerated property that controls how color keying + * operates. The "disabled" mode that disables color keying and is + * very likely to exist if color keying is supported, it should be the + * default mode. So the default-disabled state is kinda documented. Though that comment is omitted in the v3, I'll correct that in the next revision. For now one question that keeps this patchset in RFC state is about how to expose the color key value properties to userspace, whether having drivers to perform RGB->YUV conversion is a viable way (see the v3 of the patchset).
