[RFC v2 0/1] drm/connector: Add support for privacy-screen properties
rajatja at google.com
Tue May 12 17:38:11 UTC 2020
On Tue, May 12, 2020 at 9:09 AM Hans de Goede <hdegoede at redhat.com> wrote:
> On 5/12/20 4:20 PM, Pekka Paalanen wrote:
> > On Tue, 12 May 2020 10:18:31 +0200
> > Hans de Goede <hdegoede at redhat.com> wrote:
> >> Hi,
> >> On 5/11/20 9:55 PM, Rajat Jain wrote:
> >>> Hi Hans,
> >>> On Mon, May 11, 2020 at 10:47 AM Hans de Goede <hdegoede at redhat.com <mailto:hdegoede at redhat.com>> wrote:
> >>> Hi All,
> >>> This RFC takes Rajat's earlier patch for adding privacy-screen properties
> >>> infra to drm_connector.c and then adds the results of the discussion from
> >>> the "RFC: Drm-connector properties managed by another driver / privacy
> >>> screen support" mail thread on top, hence the v2.
> >>> Thank you so much for doing this. I was following the said discussion and eventually it became quite complex for me to understand and follow :-)
> >> I hope the new doc text makes things clear again?
Yes it does.
> >>> The most important thing here is big kernel-doc comment which gets added in
> >>> the first patch-chunk modifying drm_connector.c, this summarizes, or at
> >>> least tries to summarize, the conclusions of our previous discussion on
> >>> the userspace API and lays down the ground rules for how the 2 new
> >>> "privacy-screen sw-state" and "privacy-screen hw-state" properties are
> >>> to be used both from the driver side as well as from the userspace side.
> >>> Other then that this modifies Rajat's patch to add 2 properties instead
> >>> of one, without much other changes.
> >>> Rajat, perhaps you can do a new version of your patch-set integration /
> >>> using this version of the properties and then if everyone is ok with
> >>> the proposed userspace API Jani can hopefully merge the whole set
> >>> through the i915 tree sometime during the 5.9 cycle.
> >>> SGTM. I have actually moved to working on something else now, so I will most likely wait for this patch to get merged, before rebasing my other / remaining patches on top of that.
> >> We have the rule that code like this will not be merged until it has at least
> >> one in kernel user. I plan to eventually use this too, but that is still
> >> a while away as I first need to write a lcdshadow subsystem which the
> >> thinkpad_acpi code can then use to register a lcdshadow device; and when
> >> that all is in place, then I can hook it up on the drm code.
OK. In that case, sure, I will respin my patchset with this patch once
we have some more comments from Jani et al, and thus a newer iteration
of this patch.
> > Hi,
> > I believe this falls under "new UAPI" rules, because this is adding new
> > KMS properties. Hence an in-kernel user is not enough:
> > https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements
The chrome browser currently uses the API exposed by my (previous)
patchset to control privacy screen.
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
> Hmm, I believe that that mostly applies to new DRI (ioclt) interfaces for
> submitting rendering commands to new GPUs and other complex new APIs and
> not necessarily to introducing new properties. Also note that all
> properties are exported under X through Xrandr, at least reading them,
> not sure about setting them.
> Anyways I do plan to write some mutter code to test my lcdshadow subsys <->
> DRM driver integration when that is all more then just vaporware. But I
> would prefer for Rajat's series to land before that so that I can build
> on top of it.
More information about the dri-devel