When using emulated display modes, the output size is often larger than the drawable buffer. As the surface damage region is automatically calculated from the smaller drawable buffer size, the damage region needs to be manually set to cover the entire viewport region or visual repaint artifacts can result.
Expose as many emulated display modes as possible. They will currently display stretched to the display's native desktop aspect, but if an application requires a hardcoded resolution, it will work at minimum.
Aside from the change in the emulated display mode list, the Wayland event handling code had to be updated to support separate scaling for the x and y axes, as square pixels are no longer guaranteed.
Wayland doesn't support mode switching, however Wayland compositors can support the wp_viewporter protocol, which allows for the mapping of arbitrarily sized buffer regions to output surfaces. Use this functionality, when available, for fullscreen output when using non-native display modes and/or when dealing with scaled desktops, which can incur significant overdraw without this extension.
This also allows for the exposure of arbitrarily sized, emulated display modes, which can be useful for legacy compatability.
If we get a SDL_SetWindowSize() call right after SDL_SetWindowFullscreen() but
before we've gotten a new configure event from the compositor, the attempt to
set our window size will silently fail (when libdecor is enabled).
Fix this by remembering that we need to commit a new size, so we can do that
in decoration_frame_configure().
Dispatching all events in Wayland_GLES_SwapWindow leads to resizes being
acked before the program has a chance to handle the resize. This change
reduces jumping on fullscreen transition with apps that call
SDL_PollEvent before issuing any render calls.
Commit 871c11191bfc7214061a3da37c112522a102ddf5 removed delayed
resize handling, but it left the whole structure untouched that
now became unnecessary. To help with code clarity, get rid
of the structure where pending resize state used to be stored
and pass all the data directly to Wayland_HandlePendingResize
(now renamed to Wayland_HandleResize, since it's not "pending"
anymore but applied immediately)
Some Wayland compositors send (0,0) as "suggested" configure event sizes to
indicate that the client has to decide on its own which sizes to used. This
is commonly done when restoring from maximised, fullscreen or tiles states
to fullscreen.
We now store the last known floating states in a new set of variables and
restore them when we receive such a (0,0) configure event.
If you hide a window on Mutter, for example, the compositor never requests
new frames, which will cause Mesa to block forever in eglSwapBuffers to
satisfy the swap interval.
We now always set the swap interval to 0 and manage this ourselves, handing
the frame to Wayland when it requests a new one, and timing out at 10fps just
to keep apps moving if the compositor wants no frames at all.
My understanding is that other protocols are coming that might improve upon
this solution, but for now it solves the total hang.
Fixes#4335.
KWin has supported the shared and formalised zxdg_decoration since
Plasma 5.16 which came out mid 2019.
Whilst it made sense to support them both for a while, it should not be
needed for future SDL releases.
This gives us flexibility to add others hints to control keyboard grab behavior
without having to touch all of the backends. It also allows us to possibly
expose keyboard grab separately from mouse grab for applications that want to
manage those independently.
We support both the org.freedesktop.ScreenSaver D-Bus API (same as the X11
backend) and the Wayland idle_inhibit_unstable_v1 protocol.
Some Wayland compositors only support one or the other, so we need both to
for broad compatibility.
Use zwp_keyboard_shortcuts_inhibit_manager_v1 to allow SDL applications
to capture system keyboard shortcuts like Alt+Tab when keyboard grab is
enabled via SDL_HINT_GRAB_KEYBOARD.
OpenGL apparently needs to not do any drawing between wl_egl_window_resize
and eglSwapBuffers, but Vulkan apps don't use SDL to present, so they
never call into an equivalent of SDL_GL_SwapWindow where our Wayland code
was handling pending resize work.
Fixes Bugzilla #4722.
For starters, we need to correctly respond to 0,0 configure after unsetting
fullscreen. Also, turns out that there should be no drawing calls at all
in between eglSwapBuffers and wl_egl_window_resize, as otherwise EGL can
already allocate a wrongly sized buffer for a next frame, so handle those
together.
This is just in parity with the existing zxdg-shell-unstable-v6 code. Making
the Wayland target robust (and uh, with title bars) is going to take a lot
of work on top of this.
This is meant to be the desktop-enhanced version of wl_shell. Right now we
just match what the existing wl_shell code does, but there are other areas of
functionality available to us now, that we can fill in later.
This uses the "unstable" API, since this is what ships in Ubuntu 17.10 (as
part of Wayland 1.10), but Wayland 1.12 promotes this to stable with extremely
minor changes. We will add support for the stable version when it makes sense
to do so.
