The default timeout value of 14ms is ideal when querying clipboard data while polling events, to prevent excessive lag if the source takes a long time to respond, however, when reading from SDL_GetClipboardData(), the timeout can be too short if a large amount of data must be processed or transferred. SDL_GetClipboardData() is not called while polling events, so using a longer read timeout to greatly increase the chance of success is acceptable.
Use a 5 second timeout when reading from SDL_GetClipboardData() and GetPrimarySelectionText() to greatly increase the chances of a successful read, even if the requested format requires heavy processing.
(cherry picked from commit 2a0d04613c)
Clients that defer repainting may hang in SDL_WaitEvent() while interactively resizing if they only redraw when an appropriate event is received, as resizing defers the new state until a frame callback is received, and if too much time elapsed since the last redraw, the last frame callback may have already occurred. Send an exposure event when deferring resizes so the client will make forward progress and trigger a frame callback to ack the pending configure state.
(cherry picked from commit 2212c4f085)
Prevent mouse and keyboard events from being processed twice by
skipping [super sendEvent:] for events SDL has already handled via
Cocoa_DispatchEvent. Other event types still go through AppKit's
normal handling.
(cherry picked from commit dd52dd8995)
In rare cases, a leave event can be grouped with relative motion in a frame. Ensure a valid focus window when dispatching relative motion.
(cherry picked from commit fab42a1432)
hid.dll simply cannot send 7 bytes reports unlike other platforms
It enforces full length repots of 17 from the device's descriptor,
which does not work on the device.
This breaks ffb and led control, so we disable this by default on
windows.
(cherry picked from commit 6c2f9bc41e)
CGDisplayPixelsHigh(kCGDirectMainDisplay) involves an IPC call to the
Window Server on each invocation. Cache the main display height in
SDL_CocoaVideoData and update it only when display configuration changes,
reducing overhead during high-frequency mouse event processing.
(cherry picked from commit 3ee8d1406c)
It turns out the reason this function was having so many overread issues was because our row copies were wrong - for compressed images we also need to reduce the row count based on the block size, similar to what we already do for pitch calculation - these copies are byte copies, not pixel copies!
(cherry picked from commit f472f93db8)
The event core will do so automatically, and this may end up dropping events in rare cases when exiting fullscreen if an event with the final bordered window size is sent before the event notifying that the borders have come back on.
Don't decide if the button is pressed by the `buttons` bitmask, but rather by
event type. On macOS, the trackpad might produce a mousedown event with taps
instead of full clicks--if tapping is enabled in System Preferences--and in
this case might not set the flag in the bitmask.
Fixes#14640.
Events won't be delivered to the regular event watcher list callbacks if a client event filter discards events. Use the special window event watcher list to watch for resizes in the GPU renderers, as events are delivered to this list before a client can potentially discard them.
Anecdotally, some force-feedback wheels have been reported to experience a
reduced "definition", "texture", "precision", or "je ne sais quoi", which
appears to be caused by sending more update flags than necessary to
DirectInput.
This may be related to the fact that there are two USB PID packets that are
sent when updating a device: One contains the "general" force data, and the
other contains the "type-specific" data. My speculation is that many wheels
expect to only receive the latter, and misbehave when receiving both.
This has been tested and validated anecdotally by others who have received
a hacked-together version of PCSX2 that corrects the flags sent to DirectInput,
who noted a significant improvement in the "feeling" of the FFB effects.
The only way to validate this at a technical level is to grab a wheel that uses
the "generic" DirectInput FFB drivers (which map nearly 1:1 with the USB PID
specification), and inspect the USB packets (e.g. with USBPcap) to check whether
redundant data is being sent.
This upsets things, because you end up calling a javascript function with
more arguments than it expects, and if asserts are enabled, Emscripten notices
this and aborts the program when you hit this code.
Reference Issue #14670.
Wayland icons must be square, so scale non-square images to fit a square region instead of failing. This matches X11 behavior.
A warning that the image will be scaled will be logged.
As in the previous commit, loading GTK while setuid or setgid would
result in the process exiting. This is equally true if it's loaded
indirectly, for a libdecor plugin.
libdecor doesn't currently have any API by which it can be asked to
avoid specific plugins, but its GTK plugin declines to initialize if it
detects a non-main thread (because GTK documents that it must only be
used from the main thread), resulting in libdecor falling back to the
lower-priority Cairo plugin. We can make use of this by intentionally
initializing libdecor on another thread if we have been asked to avoid
GTK. This is a bit of a hack, but at worst it should be harmless.
Resolves: https://github.com/libsdl-org/sdl2-compat/issues/564
Signed-off-by: Simon McVittie <smcv@debian.org>
GTK explicitly doesn't support being used setuid or setgid, and if SDL
loads and initializes GTK, GTK will exit the process if it
detects a setgid executable. This is incompatible with the historical
practice of making game executables setgid in order to write out a
shared high-score table on multi-user systems (which is security theatre
at best, because typical game runtime libraries are not hardened against
an untrusted caller, but making it regress would be a user-observable
regression in sdl2-compat).
Helps: https://github.com/libsdl-org/sdl2-compat/issues/564
Signed-off-by: Simon McVittie <smcv@debian.org>
