It is called from WGI before the normal joystick detection has been run, so it needs to actually enumerate currently connected devices.
We can skip the logic checking for other drivers also supporting this device, because that logic is duplicated from the call site.
Not only is it more efficient to batch process pending events, it is
necessary for correctness with the Win32 backend. WIN_PumpEvents() runs
periodic updates of the cursor clip region and disambiguation of
left and right shift keys in addition to standard event processing.
SDL_GetBasePath grows its path buffer for long paths, but GetModuleFileNameExW always truncates and succeeds,
so `len` was always equal to (buflen - 1) which is 127. This is easily fixed by checking for (buflen - 1) instead of buflen.
For paths longer than MAX_PATH, this problem sometimes got hidden by Windows path shortening ("C:\PROGRA~1\" etc.).
Tested on Windows 10 x64 19041 and 10586.
SDL_JoystickSetVirtualAxisInner() and SDL_JoystickSetVirtualHatInner()
did not properly sanitize the 'axis' and 'hat' parameters.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Based on a patch by Jochen Schäfer <josch1710@live.de> :
The problem is, that in the initialization code uses the same structure for
desktop_mode and current_mode. See SDL_os2video.c:OS2_VideoInit():
stSDLDisplay.desktop_mode = stSDLDisplayMode;
stSDLDisplay.current_mode = stSDLDisplayMode;
...
stSDLDisplayMode.driverdata = pDisplayData;
Then, if you call GetDisplayModes, current_mode will added to the modes
list, with the same driverdata pointer to desktop_mode.
SDL_AddDisplayMode( display, &display->current_mode );
When VideoQuit gets called, first the modes list gets freed including the
driverdata, the desktop_mode gets freed. See SDL_video.c:SDL_VideoQuit():
for (j = display->num_display_modes; j--;) {
SDL_free(display->display_modes[j].driverdata);
display->display_modes[j].driverdata = NULL;
}
SDL_free(display->display_modes);
display->display_modes = NULL;
SDL_free(display->desktop_mode.driverdata);
display->desktop_mode.driverdata = NULL;
So, the display_modes[j].driverdata gets freed, but desktop_mode->driverdata
points to the same memory, but is not NULL'ed. When desktop_mode->driverdata
gets freed the memory is already freed, and libcx crashes the application on
SDL_Quit.
Based on a patch by Jochen Schäfer <josch1710@live.de> :
On a T420 pressing the ACPI button for volume control, big scancodes
were emitted. This was causing an overflow, because missing guards.
- Do not call IDirectInputDevice8_QueryInterface(device, &IID_IDirectInputDevice8,...) on DIRECTINPUTDEVICE8 device
- Get joystick VendorID and ProductID via IDirectInputDevice8_GetProperty(.., DIPROP_VIDPID, ..) call instead of messing with DIDEVICEINSTANCE.guidProduct
- Normalize HID device interface path to upper case for stable operation of XInput check
- Remove useless RawInput calls in SDL_IsXInputDevice() - just check for "IG_" string in HID device interface path that we already have
There shouldn't be any observable behavior changes.
We can be in a situation where we receive a win32 hook callback on the same
thread that is currently waiting. In that case, we do still need to trigger
a wakeup when an event is pushed because the hook itself won't necessarily
do that (depending on what we return from the hook).
When possible use native os functions to make a blocking call waiting for
an incoming event. Previous behavior was to continuously poll the event
queue with a small delay between each poll.
The blocking call uses a new optional video driver event,
WaitEventTimeout, if available. It is called only if an window
already shown is available. If present the window is designated
using the variable wakeup_window to receive a wakeup event if
needed.
The WaitEventTimeout function accept a timeout parameter. If
positive the call will wait for an event or return if the timeout
expired without any event. If the timeout is zero it will
implement a polling behavior. If the timeout is negative the
function will block indefinetely waiting for an event.
To let the main thread sees events sent form a different thread
a "wake-up" signal is sent to the main thread if the main thread
is in a blocking state. The wake-up event is sent to the designated
wakeup_window if present.
The wake-up event is sent only if the PushEvent call is coming
from a different thread. Before sending the wake-up event
the ID of the thread making the blocking call is saved using the
variable blocking_thread_id and it is compared to the current
thread's id to decide if the wake-up event should be sent.
Two new optional video device methods are introduced:
WaitEventTimeout
SendWakeupEvent
in addition the mutex
wakeup_lock
which is defined and initialized but only for the drivers supporting the
methods above.
If the methods are not present the system behaves as previously
performing a periodic polling of the events queue.
The blocking call is disabled if a joystick or sensor is detected
and falls back to previous behavior.
This add controller mappings for the Atari vcs (modern) controller as
well as the classic controller, for both bluetooth and USB connectivity.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
At least on bluetooth the guid user the version reported by the
bluetooth device. Which for Atari vcs controllers is the firmware
version. However the mapping will stay the same regardless of firmware
version, so ignore the version entirely to avoid needing a new mapping
entry for each firmware version.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
this variable was added in commit 2067a7db8e and
ultimately tracks if this is a surface's first present. checking if the current
bo is NULL provides the same functionality and cuts down on a redundant piece
of state potentially getting out of sync in the future
SetDisplayMode needs to recreate the EGL surfaces, which then need to be
bound along with the correct context in each rendering thread
commit 3a1d7d9c9a removed this behavior which
has broken using SetDisplayMode when rendering with multiple contexts
the commit message was rather vague, but if the surfaces do need to be
created immediately, this process probably needs to be split such that
surface is created immediately, but the binding is deferred
and remove duplicate SDL_WINDOWEVENT_RESIZED event
commit 2067a7db8e made SDL_SetWindowSize and
SDL_SetWindowFullscreen modify the display mode previously set by a call to
SDL_SetWindowDisplayMode
as far as I understand the SDL API, calling SDL_SetWindowDisplayMode followed
by calling SDL_SetWindowFullscreen(..., SDL_WINDOW_FULLSCREEN) is the correct
way to mode set / switch to fullscreen
this change restores that functionaliy when switching to SDL_WINDOW_FULLSCREEN,
but other cases are still modifying the display mode set by the user. rather
than modifying the display mode set by the user, it seems this logic inside of
KMSDRM_ReconfigureWindow should be pushed further down into KMSDRM_CreateSurfaces
(as it was originally) to only modify the final mode that's set (based on the
fullscreen flags), but not override the mode requested by the user
commit 2067a7db8e introduced new surface_w and surface_h
variables which were passed to gbm_surface_create rather than the dimensions from the
drmModeModeInfo structure. commit 5105ecf8b1 further
refactored this code and no longer synchronized these variables inside
KMSDRM_SetDisplayMode, breaking it
this change removes the variables since they're seemingly redundant to begin with
When Xbox One/Series Controllers are connected via USB on Windows they all are using `XBOXGIP` driver and produce a special ProductID `0x02FF` (GIP software PID) for any connected controller.
On the other hand `Xbox 360 Wireless Controller Reciever` (PID 0x0719) is using `XUSB` driver and produces special ProductID `0x02A1` (XUSB software PID) for each connected Xbox 360 Wireless Controller.
Also fixed Xbox One Series X Controller comment.
Only adjust the biClrUsed field if it is set to zero in the bitmap, and make
some effort to make sure we don't overflow a buffer in any case.
This was triggering an issue with the sailboat bmp used for testpalette.c in
SDL 1.2, which is an 8-bit paletted image with 66 palette entries instead of
256. See discussion at https://github.com/libsdl-org/sdl12-compat/issues/63
This change might be a problem, but there's no indication this code, which
originally landed in SDL_image 17 years ago with a large rewrite, is actually
fixing a specific issue. I'm also not sure we should actually make an effort
to accept a bmp that has a biClrUsed field that is both non-zero and _also_
incorrect.
Details:
Currently doing 4 system calls per WM_INPUT message, which can cause the thread handling the message loop to be swapped out several times:
* GetProp - to get window data from the window handle
* GetRawInputData - to retrieve the raw input data
* 2 calls to GetMessageExtraInfo - to ignore synthetic mouse events generated for touchscreens
In this change:
* Replaced GetProp by iterating the list of windows maintained by SDL (with a fallback to GetProp). Note that this will affect all messages and not just WM_INPUT
* only calling GetMessageExtraInfo if a touchscreen has been detected
Fix for https://jira.valve.org/browse/CSGO-4855
@saml
- especially because we can be promoted to true color 888
make sure we don't select a potentially software implementation
- hopefully fix bug #1482 (EGL ChooseConfig selects software renderer on Android)
If you hide a window on Mutter, for example, the compositor never requests
new frames, which will cause Mesa to block forever in eglSwapBuffers to
satisfy the swap interval.
We now always set the swap interval to 0 and manage this ourselves, handing
the frame to Wayland when it requests a new one, and timing out at 10fps just
to keep apps moving if the compositor wants no frames at all.
My understanding is that other protocols are coming that might improve upon
this solution, but for now it solves the total hang.
Fixes#4335.
These would accidentally get a titlebar because the "borderless" style mask
is zero but the resizable attribute adds a bit. I assume this happens because
you used to need window decoration to resize a window in macOS, but this
changed in later releases.
This only caused problems when recreating a window (you had an
SDL_WINDOW_OPENGL window and tried to create a Metal SDL_Renderer on it, etc).
Fixes#4324.
It doesn't appear to work anymore, and was disabled by default anyhow, since
the needed APIs are forbidden on the Mac App Store.
A better solution to lock the mouse to the window on macOS would still be
welcome. CGAssociateMouseAndMouseCursorPosition() works fine for relative
mouse mode, this was just a question of SDL_SetWindowGrab(). As it stands
now, a grabbed mouse can briefly break out of the window, causing varying
degrees of chaos.
This can give some performance boost, and save some resources, as there's no
reason to keep a copy of an SDL window's contents on the server: most SDL
apps are redrawing completely every frame, and the API allows for expose
events to tell an app a redraw is needed anyhow.
(And compositors are free to ignore this setting if it makes sense to do so,
according to the Xlib docs.)
Reference Issue #3776.
If a developer uses SDL_SetMemoryFunctions, we can't rely on SDL_free()
working when SDL_main() returns.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
The get_usb_string call is rather expensive on some USB devices, so we
cache the vendor/product strings for future lookups (e.g. when
hid_enumerate is invoked again later).
This way, we only need to ask libusb for strings for devices we haven't
seen since before we started.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
I have a buggy system which reports a udev "change" event for an empty
USB-C port every 0.14 seconds, which causes annoying frame hitches
because SDL decides that means it needs to do a libusb hid_enumerate,
which is slow (~25ms!) because of the get_usb_string() calls in there.
We only need to re-enumerate if we've seen a device added or removed, so
let's filter out the change event first.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
It's already set with ANativeWindow_setGeometry, and eventually set/changed also by eglCreateWindowSurface.
- avoid issues with older device where SurfaceView cycle create/changed/destroy appears broken:
calling create/changed/changed, and leading to "deuqueBuffer failed at server side, error: -19", with black screen.
- re-read the format after egl window surface is created, to report the correct one (sometimes, changed from RGBA8888 to RGB24)
Previous version used 'popen' which required to sanitize user provided text. Not
sanitizing text could cause failure if user provided text included a " or command
injection with `cmd`.
There is an error "E libEGL : validate_display:91 error 3008 (EGL_BAD_DISPLAY)"
that occurs when calling "eglQueryString(display, EGL_VERSION)", with EGL_NO_DISPLAY.
Khronos says "EGL_BAD_DISPLAY is generated if display is not an EGL display connection, unless display is EGL_NO_DISPLAY and name is EGL_EXTENSIONS."
but this was added in SDL with "EGL 1.5 allows querying for client version"
( 56363ebf61 )
In fact:
- it actually doesn't work on Android that has 1.5 egl client
- it works on desktop X11 (using SDL_VIDEO_X11_FORCE_EGL=1)
The commit moves the version call where it's used, eg inside the "if (platform) {"
and checks that "eglGetPlatformDisplay" has been correctly loaded.
This unearthed an unspeakably large amount of bugs in the wl_output enumerator,
notably the fact that the wl_output user pointer was to temporary memory!
This was "fixed" in e862856, and was then pointed out as a leak in 4183211,
which was undone in d9ba204. The busted fix was correct that the malloc was an
issue, but wrong about _why_; SDL_AddVideoDisplay copies by value and does not
reuse the pointer, so generally you want your VideoDisplay to be on the stack,
but of course the callbacks don't allow that, so a malloc was a workaround. But
we can do better and just host our temporary display inside WaylandOutputData
because that will be persistent while also not leaking.
Wait, wasn't I talking about move events? Right, that: wl_surface_listener does
at least give us the ability to know what monitor we're on, even though we have
no idea where we are on the monitor. All we need to do is check the wl_output
against the display list and then push a move event that both indicates the
correct display while also not being _too_ much of a lie (but enough of a lie
to where our event doesn't get discarded as "undefined" or whatever). The index
check for the video display is what spawned the great nightmare you see before
you; aside from the bugfix this is actually a really basic patch.
The information whether a specific joystick can be used as a gamepad is
not going to change every frame, so we can cache the result into a
variable.
This dramatically reduces the performance impact of SDL2 on small
embedded devices, since the code path that is now avoided was quite
heavy.
Fixes#4229.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
- Only focus a new window when one closes if the window that was closed was an SDL window
- If the application already has a key window set that is not an SDL window, don't replace it when the application is activated
- Only register the URL event handler when SDLAppDelegate is going to be set as the applications app delegate. This is to
be consistent with previous behavior that would only register the handler in -[SDLAppDelegate applicationDidFinishLaunching:]
and allows the running app to opt out of the behavior by setting its own app delegate.
- The URL event handler is now removed if it was set on SDLAppDelegate dealloc
There is no guarantee on what order the Wayland interfaces will come in, but the
callbacks were assuming that wl_data_device_manager would could before wl_seat.
This would cause certain desktops to not have any data_device to work with,
meaning certain features like the clipboard would silently no-op.
On windows, when toggling the state of RelativeMode rapidly, there is a
high chance that SDL_WINDOWEVENT_ENTER / SDL_WINDOWEVENT_LEAVE events
will stop firing indefinitely.
This aims to resolve that shortcoming by ensuring mouse focus state is
correctly updated via WM_MOUSELEAVE events arriving via the windows
event hook.
KWin has supported the shared and formalised zxdg_decoration since
Plasma 5.16 which came out mid 2019.
Whilst it made sense to support them both for a while, it should not be
needed for future SDL releases.
Because Wayland only supports FULLSCREEN_DESKTOP, fullscreen_mode never gets
assigned at all, meaning driverdata is always NULL! Depending on what the
compositor does this can lead to dramatically different results. GNOME was fine
without this, but Plasma would trip an event that unintentionally unset the
fullscreen mode and caused the game to fire a configure event _every frame_,
and of course the configure would send the fullscreen_mode output which was
still empty. The fix is to just use the SDL_VideoDisplay directly, which will
always have a valid wl_output.
Rename locally-defined Interface ID symbols to avoid conflict with
locally linked dxgi library. Prefixed with `SDL_` to match with
other references in render_d3d11 or wasapi.
If app requested <= 16 color depth and there is a 24-bit config available,
favor that. This fixes things that quietly expect to get truecolor output
but don't request it (...like SDL's render api...) and things that are
probably requesting 16-bit color as a fallback but expecting reasonable
systems to give them full depth.
Specifically, this fixes Life is Strange on Wayland, which uses the latter
approach, and anything using SDL_Render on Wayland, which uses the former.
Fixes#4056.
Fixes#4132.
- Move an immutable condition out of a for loop.
- Add a break statement to that loop when we find what we're looking for.
- Add an assert to make sure we don't overflow a buffer.
- Wrap a single-statement if block in braces.
- Adjust some whitespace.
Note that this is purely to make it possible to enter text that requires
composition - for example, before this commit Kanji input didn't work at all.
The big problem this still has is that we need the window position, and this is
still not implemented. Once we have this information we can do the equivalent
of XTranslateCoordinates to put the rectangle where we want it.
While we should normally expect _something_ from the stream based on the
AudioStreamAvailable check, it's possible for a device change to flush the
stream at an inconvenient time, causing this function to return 0.
Thing is, this is harmless. Either data will be NULL and the result won't matter
anyway, or the data buffer will be zeroed out and the output will just be
silence for the brief moment that the device change is occurring. Both scenarios
work themselves out, and testing on Windows shows that this behavior is safe.
