[Intel-gfx] [PATCH v3 15/16] drm/i915/pxp: black pixels on pxp disabled

[Teres Alexis, Alan Previn]

On Fri, 2021-05-07 at 14:42 -0400, Rodrigo Vivi wrote:
> > 
> On Fri, Apr 30, 2021 at 03:55:28PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 30, 2021 at 07:12:53AM +0000, Gupta, Anshuman wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > Sent: Wednesday, April 28, 2021 12:26 AM
> > > > To: Gupta, Anshuman <anshuman.gupta at intel.com>
> > > > Cc: intel-gfx at lists.freedesktop.org; Vivi, Rodrigo <
> > > > rodrigo.vivi at intel.com>;
> > > > Gaurav, Kumar <kumar.gaurav at intel.com>; Shankar, Uma
> > > > <uma.shankar at intel.com>; Ceraolo Spurio, Daniele
> > > > <daniele.ceraolospurio at intel.com>
> > > > Subject: Re: [PATCH v3 15/16] drm/i915/pxp: black pixels on pxp
> > > > disabled
> > > > 
> > > > On Tue, Apr 27, 2021 at 04:15:04PM +0530, Anshuman Gupta wrote:
> > > > > When protected sufaces has flipped and pxp session is
> > > > > disabled,
> > > > > display black pixels by using plane color CTM correction.
> > > > > 
> > > > > v2:
> > > > > - Display black pixels in aysnc flip too.	
> > > > 
> > > > We can't change any of that with an async flip.
> > > I was thinking of an scenario , when application flip the
> > > protected surfaces with synchronous flips
> > > and driver has enable the plane decryption, can application issue
> > > an intermediate async flip with
> > > protected surfaces afterwards ?
> > > If above is possible, is it possible to display black pixels in
> > > case of pxp session invalidation at the time of
> > > Plane commit?   
> > 
> > We'll just have to refuse the async flip if the session has
> > been invalidated.
> 
> This seems the simplest way... but the effect would be different
> right?
> We wouldn't get the desired blank screen, but frozen screen?!
> 
> Any possibility of a blank screen on this scenario?
> 
Not sure if this opinion offers an option: I assume when we say "refuse
the async flip", we mean return a failure on but dont change the HW
state... this would mean the user observes a frozen-and-corrupted-
looking screen since all buffers in the app's swapchain would be
encrypted and invalid at once (the typical case) - including the
current frontbuffer. Along the same lines, if the app + compositor was
paused/idle with no async flips coming in momentarily, a pxp session
invalidation event would then cause the same symptom. Perhaps we need a
uevent drm-master can hook onto specifically for the pxp-teardown so
that drm-master would be able to replace the current front buffer so
long as the session hasnt been re-established. Although this might be
big enough to be seperate patch series after this?