Re: [Intel-gfx] [PATCH] drm: Add support for integrated privacy screens

From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Rajat Jain <rajatxjain@gmail.com>,
	Sean Paul <seanpaul@google.com>, David Airlie <airlied@linux.ie>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Rajat Jain <rajatja@google.com>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Jesse Barnes <jsbarnes@google.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Mat King <mathewk@google.com>, Maxime Ripard <mripard@kernel.org>,
	Duncan Laurie <dlaurie@google.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Pavel Machek <pavel@denx.de>
Subject: Re: [Intel-gfx] [PATCH] drm: Add support for integrated privacy screens
Date: Sat, 26 Oct 2019 19:18:54 +0200	[thread overview]
Message-ID: <CAKMK7uGjd1CJ+XDWPQShV_fADC5ndxdf_ecO61K4VDi6EZyMEQ@mail.gmail.com> (raw)
In-Reply-To: <CAPj87rNe20nFcFNcijFwOZLQU_E+C2HyzEjtigJ-ehiLCq42iA@mail.gmail.com>

On Sat, Oct 26, 2019 at 1:07 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> Hi Thierry,
>
> On Fri, 25 Oct 2019 at 12:36, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote:
> > > I did think about having a state variable in software to get and set
> > > this. However, I think it is not very far fetched that some platforms
> > > may have "hardware kill" switches that allow hardware to switch
> > > privacy-screen on and off directly, in addition to the software
> > > control that we are implementing. Privacy is a touchy subject in
> > > enterprise, and anything that reduces the possibility of having any
> > > inconsistency between software state and hardware state is desirable.
> > > So in this case, I chose to not have a state in software about this -
> > > we just report the hardware state everytime we are asked for it.
> >
> > So this doesn't really work with atomic KMS, then. The main idea behind
> > atomic KMS is that you apply a configuration either completely or not at
> > all. So at least for setting this property you'd have to go through the
> > state object.
> >
> > Now, for reading out the property you might be able to get away with the
> > above. I'm not sure if that's enough to keep the state up-to-date,
> > though. Is there some way for a kill switch to trigger an interrupt or
> > other event of some sort so that the state could be kept up-to-date?
> >
> > Daniel (or anyone else), do you know of any precedent for state that
> > might get modified behind the atomic helpers' back? Seems to me like we
> > need to find some point where we can actually read back the current
> > "hardware value" of this privacy screen property and store that back
> > into the state.
>
> Well, apart from connector state, though that isn't really a property
> as such, there's the link_state property, which is explicitly designed
> to do just that. That has been quite carefully designed for the
> back-and-forth though.

connector state is an immutable property, which is a hilarious way to
say that "only the driver can update it, userspace only reads it". So
not a good template here. But yeah link_state is a good example of
what we need here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch