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@xxxxxxxxxxxxxxx> > > > > Sent: Wednesday, April 28, 2021 12:26 AM > > > > To: Gupta, Anshuman <anshuman.gupta@xxxxxxxxx> > > > > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Vivi, Rodrigo < > > > > rodrigo.vivi@xxxxxxxxx>; > > > > Gaurav, Kumar <kumar.gaurav@xxxxxxxxx>; Shankar, Uma > > > > <uma.shankar@xxxxxxxxx>; Ceraolo Spurio, Daniele > > > > <daniele.ceraolospurio@xxxxxxxxx> > > > > 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? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
