The destination rectangle passed to SDL_BlitSurface() and SDL_BlitSurfaceScaled() is non-const and filled in with the final destination rectangle after clipping, and now documented as such.
Fixes https://github.com/libsdl-org/SDL/issues/7911
This reverts commit 55c3c1b05c.
It turns out many Linux distributions are shipping zenity which doesn't support the new --icon option. We'll need a more robust fix for this.
On 32-bit platforms such as i386, if SDL is compiled with -D_TIME_BITS=64
to opt-in to ABIs that will not stop working in 2038, the fields in
this struct change their naming and interpretation.
The Linux header <linux/input.h> defines macros input_event_sec and
input_event_usec which resolve to the right struct field to look at.
The actual field names and types are an implementation detail,
historically signed 32-bit time.tv_sec and time.tv_usec on 32-bit
platforms, but becoming unsigned __sec and __usec when using 64-bit
time (which makes them able to represent times up to 2106).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add a DBus message handler to watch and respond to changes to the system cursor size and theme properties. Upon these settings being changed, a cursor refresh will be triggered so the new changes will take effect immediately, without the cursor having to leave and re-enter the window surface.
Applications that don't specify a rendering flag are likely handling Vulkan/GL themselves, so SDL loading OpenGL by default in this case is unnecessary overhead, and if a render backend requires it, the window will be recreated with the appropriate flags when the renderer is initialized.
This allows the application to tell when a joystick polling cycle is complete and can process state changes as a single atomic update. It is disabled by default, at least for now.
It is possible for retrieving the machine ID to fail, either because
dbus was installed incorrectly (machine ID absent or corrupt), or in
32-bit builds, because stat() on the machine ID fails with EOVERFLOW
if it has an out-of-range timestamp or inode number.
dbus has historically treated this as a faulty installation, raising
a warning which by default causes the process to crash. Unfortunately,
dbus_get_local_machine_id() never had a way to report errors, so it has
no alternative for that (bad) error handling.
In dbus >= 1.12.0, we can use dbus_try_get_local_machine_id() to get
the same information, but with the ability to cope gracefully with
errors. ibus won't work in this situation, but that's better than
crashing.
Mitigates: https://github.com/ValveSoftware/steam-for-linux/issues/9605
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it so you can interact with sensors on multiple threads, as long as only one thread initializes and cleans up the sensor subsystem.
This also has the benefit that sensor data is available as soon as possible.
