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 > > 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
