Re: [PATCH v1 3/4] drm/tegra: plane: Add custom colorkey properties for older Tegra's

From: Daniel Vetter
Date: Fri Apr 20 2018 - 03:31:30 EST

On Tue, Apr 17, 2018 at 08:08:27PM +0300, Dmitry Osipenko wrote:
> On 17.04.2018 12:00, Daniel Vetter wrote:
> > On Mon, Apr 16, 2018 at 03:16:27PM +0300, Dmitry Osipenko wrote:
> >> Colorkey'ing allows to draw on top of overlapping planes, like for example
> >> on top of a video plane. Older Tegra's have a limited colorkey'ing
> >> capability such that blending features are reduced when colorkey'ing is
> >> enabled. In particular dependent weighting isn't possible, meaning that
> >> cursors plane can't be displayed properly. In most cases it is more useful
> >> to display content on top of video overlay, sacrificing mouse cursor
> >> in the area of three planes intersection with colorkey mismatch. This
> >> patch adds a custom colorkey properties to primary plane and CRTC's of
> >> older Tegra's, allowing userspace like Opentegra Xorg driver to implement
> >> colorkey support for XVideo extension.
> >>
> >> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx>
> >
> > Since this is your own uapi, where's the userspace per
> >
> >
> Userspace patches for colorkey and CSC utilization are in my personal github
> repos for now [0][1]. The longterm plan is to get Opentegra driver / libdrm bits
> of [2] to repos on, which should be considered as upstream. We
> have everything depending on libdrm-tegra and it is currently on hold because of
> upcoming massive rework of Tegra DRM UAPI with further de-staging of jobs
> submission UAPI, that reworking should start with 4.18 kernel.
> For now I wanted to get initial input on the patches. Once everyone is in
> agreement, I'd like to have colorkey / CSC supported by the upstream DRM driver,
> so that at least grate-driver projects could utilize them right now.
> > And why wo we need a tegra-private colorkey property here? I thought
> > other's have been discussing this in the context of other drivers.
> At least older Tegra's have limitations in regards to colorkey, like planes
> blending capabilities are reduced a lot when colorkey'ing is enabled. I'm not
> sure whether we'd want to have it as a generic property, because generic
> userspace should be aware of those limitations, otherwise there is a good chance
> to get undesirable result using colorkey. Though I'm not really sure how widely
> colorkey property could be utilize by userspace and what kind of applications
> that userspace could have for it, maybe having colorkey as a generic property
> would be good enough after all.
> I've looked up the DRI ML archive and seems the most recent colorkey-related
> patches are [3]. These patches are a bit odd to me because by generic property I
> assume a property that is HW-agnostic and the patchset does opposite to it.
> Maybe I'm misunderstanding what is meant by 'generic' property then? Anyway I've
> applied [3] and made Tegra to use that generic property, it works fine. I'll be
> happy to switch to a generic property if we'll consider that it is a viable way.
> [0]
> [1]
> [2]
> [3]

Yes that's the patches I meant, thanks for surfacing them.

Please work together with Laurent, Maxime and Boris on this (jump on that
thread and Cc them on your own patches for the next round). And pls also
work together on a common userspace for this.
Daniel Vetter
Software Engineer, Intel Corporation