[Mesa-dev] [PATCH mesa] vulkan/wsi_common_display: Return SURFACE_LOST for fatal DRM errors

[Jason Ekstrand]

Sounds fine to me.  I just wanted to confirm that they are unrecoverable.

Reviewed-by: Jason Ekstrand <jason at jlekstrand.net>

On Wed, Jun 27, 2018 at 9:13 AM, Keith Packard <keithp at keithp.com> wrote:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> > Is this the same thing that happens on VT switch?  If so, we may want to
> > return SURFACE_LOST for leases and OUT_OF_DATE for things running
> directly
> > on the display.
>
> No, on VT switch, my code currently sits in the driver and waits for the
> VT to return. The errors here are unexpected and the driver doesn't
> currently have any way to recover from them. This patch came from
> reviewing the valid error returns from these functions with my broader
> understanding of Vulkan and evaluating which error message most
> accurately described the situation. SURFACE_LOST is more accurate than
> OUT_OF_DATE as a DRM lease termination (the only "normal" cause of these
> errors) definitely requires the application create a new surface.
>
> If there were errors we knew how to handle, and the way to handle them
> was to re-query the surface and re-create the swap chain, then we should
> return OUT_OF_DATE.
>
> On another note, I re-read the spec for vkAcquireXlibDisplayEXT when
> looking at this and found that it explicitly calls out VT switch as a
> case where the driver is supposed to return 'an appropriate error', but
> I can't see an error which would be appropriate in this case --
> DEVICE_LOST and SURFACE_LOST are both effectively fatal errors to the
> application while OUT_OF_DATE requires the application to re-query the
> surface and re-construct the swap chain. I guess we could have the
> surface query block until the VT returns? Is that better than just
> having the presentation block?
>
> --
> -keith
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180627/fdde84e7/attachment.html>