[Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>
> Hi Sean,
>
> On 17/10/2019 22:26, Sean Paul wrote:
>
> > concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
> > really reached non-TI eyes. There's no link in the commit message to a UAPI
> > implementation and the only reference I could find is libkmsxx which can set
> > them through the python bindings. Since this is TI-specific gunk in TI-specific
> > headers I'm inclined to let it pass, but I would have liked to have this
> > conversation upfront. I figured I'd call this out so you have final say.
>
> There was some discussion about that a few years back when I initially
> sent the patches, but now that I look, the discussion died before really
> even starting.
>
> This is what I said about userspace implementation:
>
> > Yes, unfortunately that is not going to happen. I don't see how this
> > could be used in a generic system like Weston or X. It's meant for very
> > specific use cases, where you know exactly the requirements of your
> > application and the capabilities of the whole system, and optimize based
> > on that.

Thanks for the context, Tomi.

Indeed it looks like the discussion died, but Laurent still brought up
the u/s requirement and the patch was effectively dead until Daniel or
Dave weighed in. I'd expect at least some outreach before pushing the
patch directly 2+ years later. Has anything changed since then?


> I know this feature is used by customers, but I don't have access to
> their applications.

Unfortunately, and as you know, that is insufficient/irrelevant for
introducing new UAPI. So the question is if the libkmsxx bindings
constitute opensource userspace, it's really thin IMO.

Sean


>
>   Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki