Jason Ekstrand <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
