On Wed, 10 May 2023 09:59:21 +0200 Jonas Ådahl <jadahl@xxxxxxxxxx> wrote: > On Tue, May 09, 2023 at 08:22:30PM +0000, Simon Ser wrote: > > On Tuesday, May 9th, 2023 at 21:53, Dave Airlie <airlied@xxxxxxxxx> wrote: > > > > > There are also other vendor side effects to having this in userspace. > > > > > > Will the library have a loader? > > > Will it allow proprietary plugins? > > > Will it allow proprietary reimplementations? > > > What will happen when a vendor wants distros to ship their > > > proprietary fork of said library? > > > > > > How would NVIDIA integrate this with their proprietary stack? > > > > Since all color operations exposed by KMS are standard, the library > > would just be a simple one: no loader, no plugin, no proprietary pieces, > > etc. > > > > There might be pipelines/color-ops only exposed by proprietary out of > tree drivers; the operation types and semantics should ideally be > defined upstream, but the code paths would in practice be vendor > specific, potentially without any upstream driver using them. It should > be clear whether an implementation that makes such a pipeline work is in > scope for the upstream library. > > The same applies to the kernel; it must be clear whether pipeline > elements that potentially will only be exposed by out of tree drivers > will be acceptable upstream, at least as documented operations. In my opinion, a COLOROP element definition can be accepted in the upstream kernel documentation only if there is also an upstream driver implementing it. It does not need to be a "direct" hardware implementation, it could also be the upstream driver mapping the COLOROP to whatever hardware block or block chain it has. For the userspace library I don't know. I am puzzled whether people want to allow proprietary components or deny them. Thanks, pq
Attachment:
pgpr7BG3hqx5t.pgp
Description: OpenPGP digital signature
