We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4722

Summary: [REGRESSION] Resizing windows no-longer works with Wayland & Vulkan.
Product: SDL Reporter: David Gow <david>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 Keywords: target-2.0.12
Version: 2.0.10   
Hardware: x86_64   
OS: Linux   

Description David Gow 2019-07-13 18:52:33 UTC 
With SDL_VIDEODRIVER=wayland, even when creating a window with SDL_WINDOW_RESIZABLE, it's not possible for a Vulkan window to be resized.

This "worked" in 2.0.9 (though, due to the lack of window decorations, resizing had to be triggered from the WM). In latest hg, though, while KWin thinks the window is resizable, any attempt to resize it will fail — the window will stay the same size regardless.

This can be reproduced with ./testvulkan --resize when SDL_VIDEODRIVER=wayland

This _seems_ to be because of https://hg.libsdl.org/SDL/rev/28303fca62bd — which delays actually resizing until Wayland_GLES_SwapWindow(), which never gets called on Vulkan windows (which don't call into SDL to present at all, using vkQueuePresentKHR() instead).

Copying the code handling 'data->resize.pending == true' from Wayland_GLES_SwapWindow() into another function that's called frequently (I used Wayland_Vulkan_GetDrawableSize()) seemed to get things working, though it doesn't seem like it's a proper fix.
Comment 1 Ryan C. Gordon 2019-07-30 17:49:36 UTC 
(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.
Comment 2 Ryan C. Gordon 2019-07-30 17:52:21 UTC 
Moving all the remaining target-2.0.10 bugs to target-2.0.11. If these still aren't resolved when 2.0.11 ships, we should probably remove the keyword altogether.

--ryan.
Comment 3 Ryan C. Gordon 2019-09-20 20:47:34 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 4 Ryan C. Gordon 2019-09-20 20:48:43 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 5 Ryan C. Gordon 2020-02-14 06:30:01 UTC 
Fixed in https://hg.libsdl.org/SDL/rev/963f11dbf153, thanks!

--ryan.