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

[Dmitry Osipenko]

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 at gmail.com>
> 
> Since this is your own uapi, where's the userspace per
> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

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 freedesktop.org, 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] https://github.com/digetx/xf86-video-opentegra/commits/ckey
[1] https://github.com/digetx/libvdpau-tegra/commits/ckey
[2] https://github.com/grate-driver
[3] https://patchwork.kernel.org/patch/10117593/