cce6fffe18
If an application was transitioning out of fullscreen exclusive display mode, the wsi_display_connector->active state was not reset in vkReleaseDisplay() from fullscreen. When the app then later tried to go to fullscreen display mode again on the same display output with the same video mode, this caused _wsi_display_queue_next() to skip a required drmModeSetCrtc() during the first vkQueuePresent() after entering direct display mode. While this often worked by pure luck on a single-display setup, it goes sideways on a multi-display setup where the viewport of the associated crtc does not have a (x,y) offset of (0,0). E.g., XOrg/X11 RandR output leasing of an output whose viewport starts at x = 1920: 1. X-Server has RandR outputs viewport at x = 1920, in a shared framebuffer, shared across all crtc's on a X-Screen. 2. Application leases that output for direct display mode, 1st vkQueuePresent() triggers drmModeSetCrtc() of output to (x,y) = 0,0, as required for Vulkan/wsi/direct framebuffer setup. 3. Application does rendering and presenting. 4. Application vkReleaseDisplay() the output, terminates the RandR lease. X-Server takes over again. 5. X-Server modesets to reconfigure output back to viewport with (x,y) = 1920, 0. 6. Application leases same output again later on, and tries vkQueuePresent() again. Because of the bug fixed in this commit, the required drmModeSetCrtc() to (x,y) = 0,0 is erroneously skipped due to the stale cached connector state. 7. drmModePageflip() fails due to the wrong crtc viewport (x,y) = 1920, 0, mismatched for the need of the Vulkan framebuffer of (x,y) = 0,0. Kernel returns -ENOSPACE, Swapchain goes into permanent VK_ERROR_SURFACE_LOST state. Destroying and recreating the swapchain, as recommended by the Vulkan spec for error handling won't help. Game over! Resetting wsi_display_connector->active = false; fixes the problem of wrong / stale connector state and Vulkan/wsi/display clients are happy on multi-display setups again, as tested in various single- and multi-display configurations. This bug affects all Mesa releases with Vulkan/WSI/Display support and should therefore be backported. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Fixes:352d320a07("vulkan: Add EXT_direct_mode_display [v2]") Cc: mesa-stable Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19484> (cherry picked from commit24094ee03d)
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.