On Tue, 12 May 2020 10:18:31 +0200 Hans de Goede <hdegoede@xxxxxxxxxx> 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@xxxxxxxxxx <mailto:hdegoede@xxxxxxxxxx>> 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? > > > > 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. 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 Thanks, pq
Attachment:
pgp4nNALZsQM4.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
