If the app requested a specific renderer, even if it's not the optimal path,
let them have it, because they might want to render with a specific GPU API
on top of the framebuffer pixels.
This fixes DosBox-X crashing on startup, which forces the hint to "opengl".
Now we see if we can create an SDL_Renderer, and if that renderer reports
itself as "accelerated," and added some initial heuristics to the OpenGL
renderer to make better decisions about what qualifies as "accelerated."
This adds some FIXMEs that might be merely hypothetical, and removes the
old OpenGL checks from the video subsystem that probably weren't meaningful
in modern times. This will definitely need to improve the existing list
in the GL renderer, to catch things like llvmpipe, etc.
Reference issue #4624.
- always set error message in SDL_EGL_ChooseConfig / SDL_EGL_CreateContext
- assume SDL_EGL_DeleteContext does not alter the error message
- sync generic error message of SDL_EGL_MakeCurrent with SDL_EGL_Get/SetSwapInterval
- do not overwrite error message of SDL_EGL_ChooseConfig in WINRT_CreateWindow
- add missing error-message in SDL_LoadBMP_RW
- check return value of SDL_RWtell in SDL_LoadBMP_RW
- use standard SDL_EFREAD error instead of custom strings
+ adjust return type of readRlePixels
- allocate ime_candidates on demand
- allow write to the whole allocated memory of ime_candidates
- ensure ime_candcount is set to zero in case the candidates can not be queried for any reason
- move IME_ShowCandidateList, ImmGetContext and ImmReleaseContext to this function
- set ime_candpgsize to MAX_CANDLIST if dwPageSize is zero
- comment out deselection of ime_candsel in case of korean language for the moment (LANG_CHT does not work anyway)
- use assert instead of a check (it is a static function with constant parameter)
- assume it is called with 0 first (simplifies the logic)
- reuse dwLang value instead of a new 'call' to LANG()
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().
This prevents SDL from making an OpenGL context and maybe throwing it away
immediately by default. It will now only do it when trying to request a
window framebuffer directly, or creating an SDL_Renderer with the "software"
backend, which makes that request itself.
The way SDL decides if it should use a "texture framebuffer" needs dramatic
updating, but this solves the immediate problem.
Reference Issue #4624.
First window is created and it triggers and 'EnterNotify' event
which calls SDL_SetMouseFocus() and X11_ShowCursor() while the second
windows hasn't finished to be created (eg window->driverdata isn't set)
Just check for a valid 'driverdata'
The issue is that MS Windows synthesizes a mouse-move event in response
to touch-move events, and those mouse-move events are NOT labeled as
coming from a touch (e.g. GetMouseMessageSource() will not return
SDL_MOUSE_EVENT_SOURCE_TOUCH for those synthesized mouse-move events).
In addition, there seems to be no way to prevent this from happening;
https://gist.github.com/vbfox/1339671 claims to demonstrate a technique
to prevent it, but in my experience, it doesn't work.
Because of this, the "fallthrough" case can't test that the synthesized
mouse-move came from a touch-move, and starts erroneously pressing down
the mouse-button, leading to massive confusion in the client
application.
This caused some weird stuff to happen in the libdecor path, probably because
the window hasn't actually been mapped yet. It ends up calling stuff that
should not yet apply, and so fullscreen in particular would have a really
messed up titlebar.
The good news is, libdecor is good about tracking fullscreen state, so we can
let the callback do this for us. Keep this for xdg_shell because we actually
map the window ourselves, so we know this call is valid for that path.
Previous to this commit, key repeats events were typically generated when
pumping events, based on the time of when the events are pumped. However,
if an application doesn't call `SDL_PumpEvents` for some seconds, this time
can be multiple seconds in the future compared to the actual key up event time,
and generates key repeats even if a key was pressed only for an instant.
In practice, this can happen when the user presses a key which causes the
application to do something without pumping events (e.g. load a level).
In Crispy Doom & PrBoom+, when the user presses the key bound to "Restart
level/demo", the game doesn't pump events during the "screen melt" effect,
and the level is restarted multiple times due to spurious repeats.
To fix this, if the key up event is among the events to be pumped, we generate
the key repeats there, since in the Wayland callback we receive the time when
the key up event happened. Otherwise, we know no key up event happened and we
can generate as many repeats as necessary after pumping.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Refactorization with no functional changes.
Instead of `next_repeat_ms` containing a timestamp based on SDL ticks, we make
it zero-based relative to the key press time, and we store the key press time in
SDL ticks in a new field.
This refactorization is groundwork for future commits which need to use the
key press and release timestamps provided by the Wayland API, which are also
expressed in milliseconds, but whose base does not match the one for SDL ticks.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
If `repeat_info->next_repeat_ms` overflows, many key presses will be generated.
In the worst case, `now = 0xFFFFFFFFU` and the loop will never terminate.
Rearrange the comparison in order to gracefully handle the overflow case.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
If that condition was reachable, the return value should be negative to indicate that waiting for the timeout failed.
Otherwise, SDL_WaitEventTimeout would incorrectly return early.
When mouse buttons are swapped, right mouse button down is the same value as raw mouse button up, and conceptually the two systems use different button masks, so never cache state between the two.
Fixes https://github.com/libsdl-org/SDL/issues/5108
Program received signal SIGILL, Illegal instruction.
X11_InitKeyboard (_this=0x1001f8f0)
at /home/sdl/SDL_git/src/video/x11/SDL_x11keyboard.c:273
273 XKeyboardState values = { .global_auto_repeat = AutoRepeatModeOff };
If the X server's byte order is different from the client, things might
display in the wrong colour.
Apparently we can just set the byte_order field to the client's byte
order, and the X server will adjust everything automatically:
https://xorg.freedesktop.narkive.com/GbSD1aPq/ximage-s-byte-order-field
Rounding the scroll deltas from trackpads causes jerky scrolling behavior
by artificially amplifying the effects of very small scroll movements.
We should only round events from devices with discrete scroll wheels,
because we know the smallest unit of movement there is a single tick.
The xdg_shell spec seems to state[1] that xdg_toplevel_configure events can
always provide a 0×0 width/height to signal that the compositor doesn't
care. SDL previously assumed the provided width/height was always valid
for fullscreen windows, and so applied it as-is.
This broke SDL applications on KDE/KWin 5.23, which now sends 0×0
configure events (and, in 5.23.3, 1×1 events for some reason), breaking
all SDL applications in fullscreen[2].
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/6
[2]: https://bugs.kde.org/show_bug.cgi?id=444962#c6
gbm_device_get_fd() in at least some libmali versions duplicates handle.
Other implementations do not do duplication. To prevent handle leak save
drm_fd in SDL_DisplayData.
When our keyboard grab hook is installed, GetKeyState() will return 0 for the
GUI keys even when they are pressed. This leads to spurious key up events when
holding down the GUI keys and the inability to use any key combos involving
those modifier keys.
This fixes a compile warning — and possible invalid memory read —
introduced in 9c03d255 ("Add back X11 legacy WM_NAME encodings"), which
was part of PR #5029, fixing Bug #4924.
The issue is with one of the added warnings in X11_GetWindowTitle().
Basically, the "title" variable passed to SDL_LogError() hasn't been
initialised yet: we could pass propdata in directly, but it's better to
move the SDL_LogError() call until after title is set, IMHO.
This fixes the following warning from gcc (SUSE Linux) 11.2.1:
In file included from /home/david/Development/SDL/src/video/x11/../../SDL_internal.h:45,
from /home/david/Development/SDL/src/video/x11/SDL_x11window.c:21:
/home/david/Development/SDL/src/video/x11/SDL_x11window.c: In function 'X11_GetWindowTitle':
/home/david/Development/SDL/src/video/x11/../../dynapi/SDL_dynapi_overrides.h:33:22: warning: '%s' directive argument is null [-Wformat-overflow=]
33 | #define SDL_LogDebug SDL_LogDebug_REAL
/home/david/Development/SDL/src/video/x11/SDL_x11window.c:720:13: note: in expansion of macro 'SDL_LogDebug'
720 | SDL_LogDebug(SDL_LOG_CATEGORY_VIDEO, "Failed to convert WM_NAME title expecting UTF8! Title: %s", title);
| ^~~~~~~~~~~~
Closes#4924.
Based on patches of the past, such as this work by James Cloos in July
2010:
d7d98751b7,
as well as code comments in the Perl module X11::Protocol::WM
(https://metacpan.org/pod/X11::Protocol::WM) and even the code to Xlib
itself, which taught me that we should never have been using
`XStoreName`, all it does is call `XChangeProperty`, hardcoded to
`XA_STRING`!
What can I say, when the task is old school, the sources are too 😂
macOS 10.6 has some touch NSEvents which do not have a subtype
(Begin/EndGesture, Magnify, Rotate, Swipe) and cause an uncaught
exception which triggers SIGABRT and the program exits.
As it is, none of the macOS 10.6 touch events are detected as a
trackpad (including Gesture due to using different subtypes).
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Clang before Clang 10 and GCC before GCC 7 have problems with using
__attribute__ as a sole statement and warn about a "declaration not
declaring anything", so fall back to using the /* fallthrough */ comment
if we are using those older compiler versions.
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
This causes lots of spam in test automation and it's not clear it's useful to developers. If we need this level of validation, we should add a log category for it.
A racing reader could read from our fd between SDL_IOReady()/X11_Pending()
and our call to XNextEvent() which will cause XNextEvent() to block for
more data. Avoid this by using XCheckIfEvent() which will never block.
This also fixes a bug where we could poll() for data, even when events were
already read and pending in the queue. Unlike the Wayland implementation,
this isn't totally thread-safe because nothing prevents a racing reader
from reading events into the queue between our XCheckIfEvent() and
SDL_IOReady() calls, but I think this is the best we can do with Xlib.
This API and implementation comes from the Unreal Engine branch of SDL, which
originally called this "SDL_ConfineCursor".
Some minor cleanup and changes for consistency with the rest of SDL_video, but
there are two major changes:
1. The coordinate system has been changed so that `rect` is _window_ relative
and not _screen_ relative, making it easier to implement without having
global access to the display.
2. The UE version unset all rects when passing `NULL` as a parameter for
`window`, this has been removed as it was an unused feature anyhow.
Currently this is only implemented for X, but can be supported on Wayland and
Windows at minimum too.
In this case we'll get WM_KILLFOCUS when the child window is focused, but we'll retain focus on the top level window, but when we Alt-Tab away, we won't get another WM_KILLFOCUS or WM_NCACTIVATE, we get WM_ACTIVATE instead, so we need to check for focus updates in response to that as well.
Add a new flag to avoid suppressing EINTR in SDL_IOReady(). Pass the
flag in WaitEventTimeout() to ensure that a SIGINT will wake up
SDL_WaitEvent() without another event coming in.
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.
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.
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.
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.
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.
* 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
Sylvain
Mahyar Koshkouei
Cameron Cawley
Ryan C. Gordon
waddlesplash
Ozkan Sezer
pionere
SonicMastr
Weng Xuetian
Cameron Gutman
Ethan Lee
ulatekh
Mathieu Eyraud
kenmays
Joan Bruguera
Sam Lantinga
Wouter Wijsman
stdgregwar
rohlem
shinyquagsire23
Edward Li
Erik Soma
Alex Szpakowski
David Redondo
David Gow
Hanseul Jun
Valentin Hăloiu
Sergio Padrino
Davis Mosenkovs
Fredrick Brennan
Zack Middleton
Misa
Susko3
Yufei Huang
Thomas Ballinger
Ivan Epifanov
uyjulian
Cacodemon345
James Howard
DomGries
Brick
Rémy Tassoux
Väinö Mäkelä
Martin Mauersics
Zach Reedy