[RFC v2 0/1] drm/connector: Add support for privacy-screen properties

Pekka Paalanen ppaalanen at gmail.com
Thu May 14 08:11:21 UTC 2020


On Wed, 13 May 2020 11:28:38 -0700
Rajat Jain <rajatja at google.com> wrote:

> On Wed, May 13, 2020 at 12:49 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:

...

> > On Tue, 12 May 2020 10:38:11 -0700
> > Rajat Jain <rajatja at google.com> wrote:
> >  
> > > The chrome browser currently uses the API exposed by my (previous)
> > > patchset to control privacy screen.
> > > https://source.chromium.org/chromium/chromium/src/+/master:ui/ozone/platform/drm/common/drm_util.cc;l=180?q=%22privacy-screen%22%20-f:third_party%2Fkernel%2Fv&originalUrl=https:%2F%2Fcs.chromium.org%2F
> > >
> > > I know this doesn't help directly, but just to say that there are
> > > users waiting to use an API that we release. If these changes are
> > > accepted, I expect to see the change in browser again, to match the
> > > new API,  although that will be not until we decide to uprev our
> > > kernel again.  
> >
> > Chromium counts as userspace, I think many new features have landed
> > with it as the userspace.
> >
> > Is that from some development branch, not actually merged or released
> > yet? If yes, very good.  
> 
> No, it's released (in Chromium for chromeOS platforms).

That is really, really bad.

You are lucky that the upstream discussions ended up changing all the
property names anyway, since now there is no way to ever use the
original names you used. Changing their meaning would have broken your
released userspace, and the kernel is simply not allowed to do that.

So that's a door closed for the kernel. Thankfully we didn't want to go
through that door in the end.

> > When you submit kernel patches with new UAPI,
> > it would be nice to point to the userspace review discussion where the
> > userspace patches have been reviewed and accepted but not merged.  
> 
> I doubt if that would happen - because they won't do it unless a
> feature is available in the kernel they are using. I can definitely
> create a public bug about what they need to do though.

Sorry, but that is the DRM development policy. Point your people to
https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements

I have the feeling that the doc in the link does not underline enough
"fully reviewed but NOT merged to something that will release".


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200514/9a15b9bc/attachment.sig>


More information about the dri-devel mailing list