Re: [PULL] drm-misc-next

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 18/10/2019 23:11, Sean Paul wrote:
On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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?

There were new review rounds for the series this summer & autumn, but no, nothing else. I haven't specifically pinged anyone about the UAPI changes.

This series introduces three new flags to an already existing UAPI, and, for whatever reason, this didn't register to me as a new UAPI, even if Laurent asked about it some years back.

So, my mistake.

The flags are added in a single patch, so I can easily push a revert for that if this patch is not acceptable. The rest of the series is cleanup.

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.

Ok. Well, I know and understand the general rule here. But perhaps I haven't taken it as strictly as needed.

I have to say I don't quite understand why this rule would be always strictly held, though.

These flags, for example, what should we do with them?
- They provide a proven, real use-case benefit.
- They are specific to SoCs with OMAP DSS and DMM IPs.
- They are relatively simple.
- All the details, including the details about the HW, are public.
- Using them makes sense only in cases where you are tuning your system to your application, and you must know the resource needs of all the apps in your system. So they cannot really be used in any generic setup, or at least I have no idea how.

Does the history and experience say that such specific case as above cases don't really exist, and we can always have a generic UAPI (or, in worst case, a device specific UAPI) which can be used from X/Weston/or-such?

Or do things like above exist, but they need to carried in vendors' kernels?

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux