Even without the thread, it'll do an initial hardware detection at startup,
but there won't be any further hotplug events after that. But for many cases,
that is likely complete sufficient.
In either case, this cleaned up the code to no longer need a semaphore at
startup.
Fixes#4862.
We can have spurious wakeups in WaitEventTimeout() due to Wayland events
that don't end up causing us to generate an SDL event. Fortunately for us,
SDL_WaitEventTimeout_Device() handles this situation properly by calling
WaitEventTimeout() again with an adjusted timeout.
There are two issues which are stopping the SDL tests from building on
my machine:
- libunwind is not being linked
- Even if it is, it is missing several symbols.
The first is fixed by having the test programs link against libunwind if
available. Technically, SDL2_test should be linking against it, as it's
used in SDL_test_memory.c, but as SDL2_test is a static library, it
can't itself import libunwind. We just assume that if it's present on
the system, we should link it directly to the test programs. This should
strictly be an improvement, as the only case where this'd fail is if
SDL2 was compiled when libunwind was present, but the tests are being
compiled without it, and that'd fail anyway.
The second is fixed by #define-ing UNW_LOCAL_ONLY before including
libunwind.h: this is required to make libunwind link to predicatable
symbols, in what can only be described as a bit of a farce. There are a
few more details in the libunwind man page, but the gist of it is that
it disables support for "remote unwinding": unwinding stack frames in a
different process (and possibly from a different architecture?):
http://www.nongnu.org/libunwind/man/libunwind(3).html
Note that I haven't tried this with CMake: I suspect that it'll work,
though, as the CMakeLists.txt seems to have SDL2 link against libunwind if
it's present. This adds an ugly extra dependency to SDL2, but does mean
that issue 1 isn't present. The UNW_LOCAL_ONLY change shouldn't be
build-system-specific.
Wayland provides the prepare_read()/read_events() family of APIs for
reading from the display fd in a deadlock-free manner across multiple
threads in a multi-threaded application. Let's use those instead of
trying to roll our own solution using a mutex.
This fixes an issue where a call to SDL_GL_SwapWindow() doesn't swap
buffers if it happens to collide with SDL_PumpEvents() in the main
thread. It also allows coexistence with other code or toolkits in
our process that may want read and dispatch events themselves.
- Factorize PrepQueueCmdDraw{,DrawTexture,Solid) into one single function
- Change SDL_Texture/Renderer r,g,b,a Uint8 into an SDL_Color, so that it can be passed directly to RenderGeometry
- Don't automatically queue a SET_DRAW_COLOR cmd for RenderGeometry (and update GLES2 renderer)
Instead of taking a direct copy of the mouse cursor surface, and then
premultiplying on every BO upload (using the custom
legacy_alpha_premultiply_ARGB8888 function), use the new
SDL_PremultiplySurfaceAlphaToARGB8888() function, which converts a whole
surface at a time, once and save the result.
The already-premultiplied data is then copied from that to the BO on
each upload, adjusting for the stride (which the previous implementation
required to be equal to the width), thereby making the extra copy
slightly useful..
This also adds support for non-SDL_PIXELFORMAT_ARGB8888 surfaces.
It turns out that Wayland's WL_SHM_FORMAT_ARGB8888 format (and, indeed,
all wayland RGBA formats) should be treated as premultiplied. SDL
surfaces tend not to be premultiplied, and this is assumed by other
backends when dealing with cursors.
This change premultiplies the cursor surface in Wayland_CreateCursor()
using the new SDL_PremultiplySurfaceAlphaToARGB8888(). In so doing, it
also adds support for a wider range of input surfaces, including those
with non-ARGB8888 pixel formats, and those which don't have
pitch==width.
This should fix#4856
A number of video backends need to get ARGB8888 formatted surfaces with
premultiplied alpha, typically for mouse cursors. Add a new function to
do this, based loosely on legacy_alpha_premultiply_ARGB8888() from the
KMSDRM backend.
The new function, SDL_PremultiplySurfaceAlphaToARGB8888() takes two
arguments:
- src: an SDL_Surface to be converted.
- dst: a buffer which is filled with premultiplied ARGB8888 data of the
same size as the surface (assuming pitch = w).
This is not heavily optimised: it just repeatedly calls SDL_GetRGBA() to
do the conversion, but should do for now.
This fixes a specific issue seen on macOS 10.14.6 where a DELL E248WFP
Display connected to a 2014 Mac Mini with a scaled 1920x1080 resolution
selected and SDL_Init(SDL_INIT_VIDEO) failed with the error: "The video
driver did not add any displays".
The underlying cause was that the current 1080p display mode did not
have the flag kDisplayModeSafeFlag, the check for which was added in
a963e36, with the idea that certain display modes should not be
candidates for switching to in fullscreen exclusive mode. That may well
be the right thing to do for filtering down a list of candidate modes,
but it doesn't pay to be so picky about the current mode. After all,
this current mode was set by System Preferences, the picture does appear
correctly on screen, and other non-SDL based applications launch and run
correctly in this mode.
Therefore the fix is to have GetDisplayMode only filter out a mode based
on flags if it's part of a candidate list, but if it's the current mode
and it can possibly be converted to an SDL_DisplayMode, do so.
* Avoid unnecessary SDL_PumpEvents calls in SDL_WaitEventTimeout
* Add a sentinel event to avoid infinite poll loops
* Move SDL_POLLSENTINEL to new internal event category
* Tweak documentation to indicate SDL_PumpEvents isn't always called
* Avoid shadowing event variable
* Ignore poll sentinel if more (user) events have been added after
Co-authored-by: Sam Lantinga <slouken@libsdl.org>
Instead do an absolute elapsed time check since the start of the wait. If that is exceeded during any iteration the routine exits as the timeout has elapsed.
The observed behavior is that any nonzero timeout value would hang until the device was paused and resumed. And a zero timeout value would always return 0 frames written even when audio fragments could be heard. Making a manual timeout system unworkable.
None of the straightforward systems imply that there's a detectable problem before the call to AAudioStream_write(). And the callback set within AAudioStreamBuilder_setErrorCallback() does not get called as we enter the hang state.
I've found that AAudioStream_getTimestamp() will report an error state from another thread. So this change codifies that behavior a bit until a better fix or more root cause can be found.
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.
This has been better fixed by b28ed02 or another related relative mouse mode change of @slouken in SDL 2.0.17 and as such can be reverted to reduce unneeded processing in WM_MOUSEMOVE
wl_display_dispatch() will block if there are no events available, and
while we try to avoid this by using SDL_IOReady() to verify there are
events before calling it, there is a race condition between
SDL_IOReady() and wl_display_dispatch() if multiple threads are
involved.
This is made more likely by the fact that SDL_GL_SwapWindow() calls
wl_display_dispatch() if vsync is enabled, in order to wait for frame
events. Therefore any program which pumps events on a different thread
from SDL_GL_SwapWindow() could end up blocking in one or other of them
until another event arrives.
This change fixes this by wrapping wl_display_dispatch() in a new mutex,
which ensures only one thread can compete for wayland events at a time,
and hence the SDL_IOReady() check should successfully prevent either
from blocking.
Direct3D 9 dictates that caps.NumSimultaneousRTs must always be at least 1,
which is to say that Direct3D 9 level hardware must always support render
targets.
(caps.NumSimultaneousRTs is meant to show if you can draw to multiple render
targets in a single draw call.)
We had already hardcoded SDL_RENDERER_TARGETTEXTURE as available earlier in
the function anyhow.
Fixes#4781.
Some wayland compositors report the refresh rate as 0. Since we want to
force a minimum refresh rate of 10 frames worth, we were dividing by the
reported refresh rate, causing a divide-by-zero.
If the refresh rate is 0, instead force a frame every second if no frame
callbacks are received.
This fixes bug #4785
This will still happen occasionally as the mouse is whipped around, if there is a window overlapping the game window, but it should happen less often now. This could even happen with the original code that warped the mouse every frame, so this should be a good compromise where we don't warp the mouse continously and we still keep the mouse in the safe area of the game window.
Note that notifications can be any size, so the safe area may need to be adjusted or even dynamically defined via a hint.
We don't use it, it was a leftover from 1.2, I think, and it doesn't exist
on Solaris, so this should hopefully fix the build there.
This also means we don't need the configure/cmake checks for
SDL_VIDEO_DRIVER_X11_CONST_PARAM_XEXTADDDISPLAY, so that was removed also.
Fixes#1666.
One place known to differ in a significant way is a single line segment that
starts and ends on the same point; the GL renderers will light up a single
pixel here, whereas the software renderer will not. My current belief is this
is a bug in the software renderer, based on the wording of the docs:
"SDL_RenderDrawLine() draws the line to include both end points."
You can see an example program that triggers that difference in Bug #2006.
As it stands, the GL renderers might _also_ render diagonal lines differently,
as the the Bresenham step might vary between implementations (one does three
pixels and then two, the other does two and then three, etc). But this patch
causes those lines to start and end on the correct pixel, and that's the best
we can do, and all anyone really needs here.
Not closing any bugs with this patch (yet!), but here are several that it
appears to fix. If no other corner cases pop up, we'll call this done.
Reference Bug #2006.
Reference Bug #1626.
Reference Bug #4001.
...and probably others...
Vista and later provide the SleepConditionVariableCS() function for this.
Since SDL_syscond_srw.c doesn't require SRW locks anymore, rename it to
SDL_syscond_cv.c which better reflects the implementation of condition
variables rather than the implementation of mutexes.
Fixes#4051.
* Fixed: Whitespace being striped from the end of IME strings incorrectly
* Fixed: Google IME Candidate Window not placing correctly
* Why are PostBuild events stored in the vcxproj and not a user file?
* Revert SDL.vcxproj properly...
* Remove whitespace as per code review
* Fix Werror=declaration-after-statement error in code
In the future, we might want to support special swap intervals. To
prevent applications from expecting nonzero values of vsync to be the
same as "on", fail with SDL_Unsupported() if the value passed is neither
0 nor 1.
Currently, if an application wants to toggle VSync, they'd have to tear
down the renderer and recreate it. This patch fixes that by letting
applications call SDL_RenderSetVSync().
This is the same as the patch in #3673, except it applies to all
renderers (including PSP, even thought it seems that the VSync flag is
disabled for that renderer). Furthermore, the renderer flags also change
as well, which #3673 didn't do. It is also an API instead of using hint
callbacks (which could be potentially dangerous).
Closes#3673.
See SDL bug #4703. This implements two new hints:
- SDL_APP_NAME
- SDL_SCREENSAVER_INHIBIT_ACTIVITY_NAME
The former is the successor to SDL_HINT_AUDIO_DEVICE_APP_NAME, and acts
as a generic "application name" used both by audio drivers and DBUS
screensaver inhibition. If SDL_AUDIO_DEVICE_APP_NAME is set, it will
still take priority over SDL_APP_NAME.
The second allows the "activity name" used by
org.freedesktop.ScreenSavver's Inhibit method, which are often shown in
the UI as the reason the screensaver (and/or suspend/other
power-managment features) are disabled.
The recent change to make SDL_AUDIODRIVER support comma-separated lists
broke the previous behavior where an SDL_AUDIODRIVER that was empty
behaved the same as if it was not set at all. This old behavior was
necessary to paper over differences in platforms where SDL_setenv may
or may not actually delete the env var if an empty string is specified.
This patch just adds a simple check to ensure SDL_AUDIODRIVER is not
empty before using it, restoring the old interpretation of the empty
var.
Originally, SDL 1.2 used "pulse" as the name for its PulseAudio driver.
While it now supports "pulseaudio" as well for compatibility with SDL
2.0 [1], there are still scripts and distro packages which set
SDL_AUDIODRIVER=pulse [2]. While it's possible to remove this in most
circumstances or replace it with "pulseaudio" or a comma-separated list,
this may still conflict if the environment variable is set globally and
old binary builds of SDL 1.2 (e.g. packaged with older games) are being
used.
To fix this on SDL 2.0, add a hardcoded check for "pulse" as an audio
driver name, and replace it with "pulseaudio". This mimics what SDL 1.2
does (but in reverse). Note that setting driver_attempt{,_len} is safe
here as they're reset correctly based on driver_attempt_end on the next
loop.
[1] d951409784
[2] https://bugzilla.opensuse.org/show_bug.cgi?id=1189778
This change corrects the mappings for the Atari gamecontroller and
adds support for the Atari Xbox 360 compatible gamecontroller. The Atari
game controller can switch between Atari and Xbox 360 mappings.
This might have changed at some point in the Pulse API, or this might have
always been wrong, but we didn't notice because the dynamic loading code
hides it by casting things to void *. The static path, where it
assigns the function pointer directly, puts out a clear compiler warning,
though.
With Dear ImGui + software renderer, it draws:
- by default at 250 fps
- drops to 70 fps if you show the color picker
- drops to 10 fps if put the color picker fullscreen
There were a few places throughout the SDL code where values were
clamped using SDL_min() and SDL_max(). Now that we have an SDL_clamp()
macro, use this instead.
This was the original intent (note SDL_UpdateWindowGrab() in SDL_OnWindowFocusGained() and SDL_OnWindowFocusLost()) and fixes a bug where relative motion unexpectedly stops if the task bar is covering the bottom of the game window and the mouse happens to move over it while relative mode is enabled.
Another alternative would be to confine the mouse when relative mode is enabled, but that generates mouse motion which would need to be ignored, and it's possible for the user moving the mouse to combine with the mouse moving into the confined area so you can't easily tell whether to ignore the mouse motion. See https://github.com/libsdl-org/SDL/issues/4165 for a case where this is problematic.
This is the mouse focus except in the case where relative motion is enabled and the mouse is over a window floating on top of the application window (e.g. the taskbar)
This fixes restoring the cursor clip rectangle after the mouse has moved off of the window.
Also try to better synchronize cursor visibility with mouse position changes when changing relative mode. This doesn't work perfectly, but it seems to improve things on Windows.
Don't rely on checking __clang_major__ since it is not comparable
between different vendors. Don't use "#pragma clang attribute" since it
is only available in relatively recent versions, there's no obvious way
to check if it's supported, and just using __attribute__ directly (for
gcc as well) results in simpler code anyway.
If we are already in the desired mode, changing it is a no-op at best,
and harmful at worst: on Xwayland, it sometimes happens that we disable
the crtc and cannot re-enable it.
Resolves: https://github.com/libsdl-org/SDL/issues/4630
Signed-off-by: Simon McVittie <smcv@collabora.com>
- cmake, configure (CheckDLOPEN): --enable-sdl-dlopen is now history..
detach the dl api discovery from SDL_LOADSO_DLOPEN functionality.
define HAVE_DLOPEN. also define DYNAPI_NEEDS_DLOPEN (CheckDLOPEN is
called only for relevant platforms.)
- update SDL_config.in and SDL_config.cmake accordingly.
- SDL_dynapi.h: set SDL_DYNAMIC_API to 0 if DYNAPI_NEEDS_DLOPEN is
defined, but HAVE_DLOPEN is not.
- pthread/SDL_systhread.c: conditionalize dl api use to HAVE_DLOPEN
- SDL_x11opengl.c, SDL_DirectFB_opengl.c, SDL_naclopengles.c: rely
on HAVE_DLOPEN, not SDL_LOADSO_DLOPEN.
- SDL_config_android.h, SDL_config_iphoneos.h, SDL_config_macosx.h,
SDL_config_pandora.h, and SDL_config_wiz.h: define HAVE_DLOPEN.
Closes: https://github.com/libsdl-org/SDL/pull/4351
Without this change, driver names don't get matched correctly;
for example "a" can get matched with "alsa" since it only checks
whether the string matches up to the length of the requested
driver name.
Without this change, driver names don't get matched correctly;
for example "x" can get matched with "x11" since it only checks
whether the string matches up to the length of the requested
driver name.
b08b1bde introduced a subtle bug. Despite not using D-Bus types directly,
the code used the SDL_USE_LIBDBUS definition set by SDL_dbus.h to conditionally
compile calls SDL_DBus_ScreensaverTickle() and SDL_DBus_ScreensaverInhibit().
As a result, it still compiled without SDL_dbus.h included, but screensaver
suspension silently failed to work.
The D-Bus stuff could probably use some tweaks to be harder to accidentally
break, but for now just restore the header includes.
Configure events from compositors have an extremely annoying habit of giving us
completely bogus sizes, from all sorts of places. Thankfully, the protocol
gives us the ability to completely ignore the width/height and just stick with
what we know, so for all windows that are not meant to be resized, pretend we
never even got the width/height at all, the compositor is required to respect
our dimensions whether they match configure's suggestion or not.
Otherwise only the display resolution is changed, but the SDL window size
(and for example the window-surface size) aren't adjusted accordingly
and thus don't fill the whole screen.
See #3313
.. and maybe other platforms as well (though X11 was not affected)?
The issue was that passing a higher resolution than the current desktop
resolution to SDL_CreateWindow() with SDL_WINDOW_FULLSCREEN didn't switch
to that resolution (even though it did switch to lower resolutions).
When creating a fullscreen window, window->fullscreen wasn't even set
at all (only zeroed out), setting it only happened if the user explicitly
called SDL_SetWindowDisplayMode(). So without that, SDL_CreateWindow()
-> SDL_UpdateFullscreenMode() -> SDL_GetWindowDisplayMode() used the
resolution from window->windowed.w/h which were limited to the desktop size
due to some weird combination of WIN_AdjustWindowRectWithStyle() and
WIN_WindowProc() being called after a call to SetWindowPos().
fixes#3313
This prevents a race if two threads that need d-bus try to init it at the
same time. Note that SDL_Init will likely handle this from a single thread
at startup, but there are places outside of init where one might trigger
D-Bus init, like setting thread priority (a common first thing for a new
thread to do) resulting in SDL trying to use RTKit.
Fixes#4587.
This reintroduces the fix from 0e16ee8330, but just marks
the viewport state as dirty after a clear that needs to expand the
viewport to fill the render target, as we'll need to also reset
the orthographic projection state elsewhere, and that won't
happen if we clear the dirty flag here.
Fixes#4210.
(again.)
(...sorry...!)
The Renderer logical scaling code scales mouse coordinates, and needs to
take the window DPI into account on HIGHDPI windows. However, the
variable which tracks this, renderer->dpi_scale, is set once when the
renderer is created, and then not updated. In the event that the window
is moved to another screen, or the screen DPI otherwise changes, this
will be outdates, and potentially the coordinates will be all wrong.
So let's update the dpi_scale on the SIZE_CHANGED event: it's at least a
possibility that this will be issued on some OSes when DPI changes, and
it's otherwise already handled by SDL_Renderer's event filter.
Cameron Gutman
Ryan C. Gordon
Sam Lantinga
Ivan Epifanov
David Gow
Sylvain
Ozkan Sezer
Tanuj Bagaria
Alex Szpakowski
uyjulian
Cacodemon345
James Howard
DomGries
shaquan-omari
Brick
Rémy Tassoux
Erik Soma
Cameron Cawley
Väinö Mäkelä
Ethan Lee
Martin Mauersics
Northfear
pkubaj
Alex R
Zach Reedy
Misa
Jaylon Gowie
Zach Reedy
Rokas Kupstys
Lee Salzman
Vanfanel
Eric Engestrom
Shawn Ellis
Oschowa
Aleksey Rybalkin
Jānis Rūcis
Joseph Kogut
Charlie Birks
Charlie Birks
Joshua Root
Simon McVittie
Andrei Alexeyev
hgs3
Sebastian Krzyszkowiak
Daniel Gibson