This was causing configure events to not inform SDL of window size
changes, even when they were based on resizes that we fully expected. The
result was fullscreen->windowed not working at all, because it would
retain the desktop resolution instead of reverting to the floating size
that it had before moving to fullscreen mode.
Fixes Super Hexagon fullscreen toggling.
The flush has been removed in e5f9fae034.
Unfortunately, even though ideally the flush shouldn't be necessary,
our resize sequence isn't... well, perfect, and removing that flush causes
tons of troubles.
We're also still flushing in other paths where the window size can be
changed by the compositor and where we may potentially have to obey that
change, like in Wayland_MaximizeWindow.
This also removes the hack introduced in 7f261d3b76,
which introduces problems with protocol violations and seems to not be
necessary when flushing.
We have issues with correct resize sequence and happen to commit old-sized
buffers even after configure event for the new size has been already
acknowledged. While the reason for that stays unknown, let's at least
workaround the problem by faking window geometry into expected size.
This does not fix visual glitch on e.g. fullscreen toggling, but having
a split-second glitch is still a much better outcome than being
terminated by the compositor for protocol violation.
This was causing window changes to completely break, resulting in broken
decorations and bizarre frame timing, I don't know what exactly it's doing
but it's not good. Kept the libdecor_frame_is_floating logic, at least.
Commit 871c11191b 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)
Otherwise our windows have no window decoration on compositors that
support xdg-decoration-unstable-v1, but default to client-side mode.
Contrary to what the comment was stating, there is nothing in the protocol
that would make redundant calls to zxdg_toplevel_decoration_v1::set_mode
problematic.
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.
This fixes a crash on pressing keyboard button when compositor sends
zero as repeat rate, indicating that key repeat should be disabled.
From Wayland protocol spec:
> Negative values for either rate or delay are illegal. A rate of zero
> will disable any repeating (regardless of the value of delay).
When we removed the OpenGL resize workaround it introduced a problem for
fullscreen windows in particular: When leaving fullscreen we tried to send a
resize event, but UpdateFullscreenMode would send a SIZE_CHANGED immediately
after, deleting our resize event and causing the following configure event's
resize to be ignored. This timing issue resulted in fullscreen windows not
being resized at all when becoming a floating window.
By always forcing resize events from configure events, we ensure that RESIZED
always makes it through. SetWindowSize-type changes should be unaffected as
they do not fire configure events.
As of [1], SDL now compiles with a warning in SDL_waylandevents.c on
32-bit systems under gcc 10.3.0:
/tmp/SDL/src/video/wayland/SDL_waylandevents.c: In function 'seat_handle_capabilities':
/tmp/SDL/src/video/wayland/SDL_waylandevents.c:958:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
958 | SDL_AddTouch((SDL_TouchID)seat, SDL_TOUCH_DEVICE_DIRECT, "wayland_touch");
| ^
/tmp/SDL/src/video/wayland/SDL_waylandevents.c:964:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
964 | SDL_DelTouch((SDL_TouchID)seat);
| ^
This is due to SDL_TouchID always being 32-bit, but seat being a pointer
which is (obviously) only 32-bit on 32-bit systems. The conversion is
therefore harmless, so silence it with an extra cast via intptr_t.
This is what the cocoa backend does (and is similar to what the Win32
backend does, except with size_t).
Fixes: 03c19efbd1 ("Added support for multiple seats with touch input on Wayland")
[1]: 03c19efbd1
When wayland is not dynamically loaded (--enable-wayland-shared=no)
libdecor.h is not included unless SDL_VIDEO_DRIVER_WAYLAND_DYNAMIC
is set, so it fails to build. We can't simply move the libdecor.h
include above the #ifdef SDL_VIDEO_DRIVER_WAYLAND_DYNAMIC block, as
libdecor.h itself #includes wayland headers we need to replace with
#defines. Instead, duplicate the #include.
Fixes https://github.com/libsdl-org/SDL/issues/4543
Note that this doesn't fix any of the underlying issues of libdecor
being treated as part of wayland, it just fixes the build. A better
solution would probably be to decouple the wayland dynamic loading
from the libdecor dynamic loading completely, though that is a lot
more work...
Each window can have at most one zxdg toplevel decoration, but as of
[1], we accidentally create two. (If libdecor is not in use). This
causes wayland windows with server-side decorations (e.g. on KDE/KWin)
to crash with the message:
zxdg_decoration_manager_v1@7: error 1: decoration has been already constructed
This extra zxdg_decoration_manager_v1.get_toplevel_decoration() call was
introduced while deprecating wl-shell and xdg-shell-stable[1] support,
and possibly was a bad interaction with [2], which moved the decoration
creation around.
Fixes: 6aae5b44f8 ("Remove wl-shell and xdg-shell-unstable-v6 support (#4323)")
[1]: https://github.com/libsdl-org/SDL/pull/4323
[2]: https://github.com/libsdl-org/SDL/pull/4374
Wayland video subsystem uses a mix of libc and SDL function.
This patch switches libc functions to SDL ones and fixes a mismatch in memory
allocation/dealoccation of SDL_Cursor in SDL_waylandmouse.c (calloc on line 201
and SDL_free on line 313) which caused memory corruption if custom memory
allocator where provided to SDL.
