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

[Dmitry Osipenko <digetx@gmail.com>]

Daniel,

Oddly thunderbird and gmail webinterface are refusing to add your 'Daniel Vetter
<daniel@ffwll.ch>' to list of recipients automatically.

On 17.04.2018 20:08, 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@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/
>