[RFC PATCH v2 1/2] drm: Add generic colorkey properties
Dmitry Osipenko
digetx at gmail.com
Wed Jun 20 12:20:31 UTC 2018
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 at armlinux.org.uk> 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).
More information about the dri-devel
mailing list