On Wed, May 10, 2023 at 9:59 AM 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. > they aren't. All code in the kernel needs to be used by in-tree drivers otherwise it's fair to delete it. DRM requires any UAPI change to have a real open source user in space user. Nvidia knows this and they went to great lengths to fulfill this requirement in the past. They'll manage. > > Jonas >
