This was meant to migrate CoreAudio onto the same SDL_RunAudio() path that
most other audio drivers are on, but it introduced a bug because it doesn't
deal with dropped audio buffers...and fixing that properly just introduces
latency.
I might revisit this later, perhaps by reworking SDL_RunAudio to allow for
this sort of API better, or redesigning the whole subsystem or something, I
don't know. I'm not super-thrilled that this has to exist outside of the usual
codepaths, though.
Fixes Bugzilla #4481.
Max Waine
SDL_mouse.c, if compiled for Windows, requires GetDoubleClickTime to compile (available from winuser.h). Without Vulkan present this fails to compile as the include chain for winuser.h is the following.
SDL_mouse.c -> SDL_sysvideo.h -> SDL_vulkan_internal.h -> SDL_windows.h -> windows.h -> winuser.h.
Problem is that SDL_vulkan_internal.h doesn't include SDL_windows.h if Vulkan isn't present, so under MinGW/GCC it will give a -Wimplicit-function-declaration warning for GetDoubleClickTime, and under MSVC fails to compile completely.
The solution to this would be to simplify the include chain: including SDL_windows.h under the same condition as GetDoubleClickTime (#ifdef __WIN32__) in SDL_mouse.c (or another file that isn't quite so indirectly included).
Anthony Pesch
Fix snd_device_name_hint return value check
According to the ALSA documentation, snd_device_name_hint returns 0 on
success, otherwise a negative error code. The code previously only
considered -1 to be an error, which let other error codes through
resulting in a segfault when hints (which was NULL) was dereferenced
Petr Pisar
The root cause is that the POC BMP file declares 3 colors used and 4 bpp palette, but pixel at line 28 and column 1 (counted from 0) has color number 3. Then when the image loaded into a surface is passed to SDL_DisplayFormat(), in order to convert it to a video format, a used bliting function looks up a color number 3 in a 3-element long color bliting map. (The map obviously has the same number entries as the surface format has colors.)
Proper fix should refuse broken BMP images that have a pixel with a color index higher than declared number of "used" colors. Possibly more advanced fix could try to relocate the out-of-range color index into a vacant index (if such exists).
Note that a single USB device is responsible for all 4 joysticks, so a large
rewrite of the DeviceDriver functions was necessary to allow a single device to
produce multiple joysticks.
This lets you build a custom embedded device that roughly offers the "this
process is going to the background NOW" semantics of SDL on a mobile device.
Only two chars are used but the full prototype is:
int tioclinux(struct tty_struct *tty, unsigned long arg)
==5010== Syscall param ioctl(TIOCLINUX) points to uninitialised byte(s)
==5010== at 0x53E73C7: ioctl (syscall-template.S:78)
==5010== by 0x4A887DA: SDL_EVDEV_Init (SDL_evdev.c:163)
==5010== by 0x4A7D157: KMSDRM_VideoInit (SDL_kmsdrmvideo.c:509)
==5010== by 0x497D959: SDL_VideoInit_REAL (SDL_video.c:529)
==5010== by 0x487ACBC: SDL_InitSubSystem_REAL (SDL.c:171)
==5010== by 0x487B052: SDL_Init_REAL (SDL.c:256)
==5010== by 0x488F7D6: SDL_Init (SDL_dynapi_procs.h:85)
This lets apps see and choose between both an HDMI and DSI-connected display,
such as a television and the Pi Foundation's official touchscreen. It only
exposes the second display if the hardware reports that it is connected.
Petr Pisar
The reproducer has these data in BITMAPINFOHEADER:
biSize = 40
biBitCount = 8
biClrUsed = 131075
SDL_LoadBMP_RW() function passes biBitCount as a color depth to SDL_CreateRGBSurface(), thus 256-color pallete is allocated. But then biClrUsed colors are read from a file and stored into the palette. SDL_LoadBMP_RW should report an error if biClrUsed is greater than 2^biBitCount.
Surfaces are allocated using SDL_SIMDAlloc()
They are marked with SDL_SIMD_ALIGNED flag to appropriatly free them with SDL_SIMDFree()
(Flag is cleared when pixels is free'd in RLE, in case user would hijack the pixels ptr)
When providing its own memory pointer (SDL_CreateRGBSurfaceFrom()) and clearing
SDL_PREALLOC to delegate to SDL the memory free, it's the responsability of the user
to add SDL_SIMD_ALIGNED or not, whether the pointer has been allocated with SDL_malloc() or
SDL_SIMDAlloc().
Some blit combination are not supported (eg ARGB8888 -> SDL_PIXELFORMAT_INDEX1MSB)
So prevent SDL_ConvertSurface from creating a broken surface, which cannot be blitted
It was calling glClear without a context. The issue it was trying to
solve was actually that after destroying a window and creating a new one
, the contents of the old window were preserved. This no longer happens
since we resize the window to nothing on destroy.
If the browser left fullscreen mode by the user pressing ESC, the next
call to SDL_SetWindowFullscreen(1) will fail as it thinks the window is
already fullscreen. (#65)
by checking Android_Window validity
- SDLThread: user application is exiting:
SDL_VideoQuit() and clearing SDL_GetVideoDevice()
- ActivityThread is changing orientation/size
surfaceChanged() > Android_SetScreenResolution() > SDL_GetVideoDevice()
- Separate function into Android_SetScreenResolution() and Android_SendResize(),
formating, and mark Android_DeviceWidth/Heigh as static
This also solves reports of this log message:
"INFO: The key you just pressed is not recognized by SDL. To help get this
fixed, please report this to the SDL forums/mailing list
<https://discourse.libsdl.org/> EVDEV KeyCode 330"
(EVDEV KeyCode 330 is BTN_TOUCH.)
Fixes Bugzilla #4147.
- If you call onPause() before CreateWindow(), SDLThread will run in infinite loop in background.
- If you call onPause() between a DestroyWindow() and a new CreateWindow(), semaphores are invalids.
SDLActivity.java: the first resume() starts the SDLThread, don't call
nativeResume() as it would post ResumeSem. And the first pause would
automatically be resumed.
- Currently, it tries to Attach the JVM first and update the thread local storage, which are two operations.
Now, it simply gives back the JNI Env stored for the thread.
- Android_JNI_SetupThreadi() should only be used for external.
For internal SDL thread, it's already called in RunThread() (SDL_systhread.c),
and other thread are Java threads which don't need to be attached. i
(even if it doesn't hurt to do it, since it's a no-op).
- JNI_OnLoad is filled with pthread_create, GetEnv, AttachCurrentThread...
It's called for all shared libraries which may don't want this setup,
and loading libraries can be also modified to be done from a static context,
or with relinker. So it's not really clear how, who and what it sets up.
=> Reduce this function to the minimal
SDLThread is a Java Thread, it's not needed to call 'Detach' from the JVM.
Clear mThreadKey, so that the pthread_create destructor is not called for this
thread.
SDLActivity thread priority is unchanged, by default -10 (THREAD_PRIORITY_VIDEO).
SDLAudio thread priority was -4 (SDL_SetThreadPriority was ignored) and is now -16 (THREAD_PRIORITY_AUDIO).
SDLThread thread priority was 0 (THREAD_PRIORITY_DEFAULT) and is -4 (THREAD_PRIORITY_DISPLAY).
- destroy Android_ActivityMutex
- display any SDL error message that may have occured in this thread,
since SDL_GetError() is thread specific, and user has no access to it.
In the usual case, first call to onNativeOrientationChanged() is done before
SDL has been initialised and would just set an error message
"Video subsystem has not been initialized" without sending the event.
First error could happen if Android_SetWindowFullscreen somehow gets
called between SurfaceDestroyed() and SurfaceCreated()
Second error should not happen has native_window validity is guaranteed.
(It would happens previously with error -19)
It accesses data->native_window, which can be changed by onNativeSurfacedChanged().
Currently, Android_SetWindowFullscreen() may access data->native_window after it
has been released, and before a new reference is acquired.
(can be reproduced by adding some SDL_Delay() in onNativeSurfacedChanged and
Android_SetWindowFullscreen() ).
Make sure there is not pending Pause accumulated, so the the application doesn't
remain paused and stucked in onDestroy().
Can be tested by adding:
SDLActivity.nativePause();
SDLActivity.nativePause();
mSingleton.finish();
Doesn't seem to happen manually, but symetrical to the pause handling.
Can be tested by adding:
mNextNativeState = SDLActivity.NativeState.PAUSED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.RESUMED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.PAUSED;
handleNativeState();
mNextNativeState = SDLActivity.NativeState.RESUMED;
handleNativeState();
Before, it ends in 'paused' state.
Now, it ends in 'resumed' state.
It may happen to have the sequence pause()/resume()/pause(), before polling
any events.
Before, it ends in 'resumed' state because as the check is greedy.
Now, always increase the Pause semaphore, and stop at each pause.
It ends in 'paused' state.
Related to bug 3250: set up a reconfiguration of SurfaceView holder.
Turn the screen off manually before the app starts
(repro rate is not 100%..)
"Pause" transition will add events:
SDL_WINDOWEVENT_ENTER
SDL_WINDOWEVENT_FOCUS_LOST
SDL_WINDOWEVENT_MINIMIZED
SDL_APP_WILL ENTER BACKGROUND
SDL_APP_DID ENTER BACKGROUND
"Resume" transition will add events:
SDL_APP_WILL ENTER FOREGROUND
SDL_APP_DID ENTER FOREGROUND
SDL_WINDOWEVENT_FOCUS_GAINED
SDL_WINDOWEVENT_RESTORED
If Android application doesn't empty the event loop in between, it enters in
"paused" state when SDL_WINDOWEVENT_RESTORED is fetched.
See bug 3250 for pratical case.
Occurs when application goes to background:
- Java activity is destroying SurfaceView holder and "egl_surface" (in onNativeSurfaceDestroyed())
- While native thread is in Android_GLES_SwapWindow(), prepared to call SDL_EGL_SwapBuffers()
The error is "call to eglSwapBuffers failed, reporting an error of EGL_BAD_SURFACE"
It an be reproduced easily by adding a SDL_Delay(100) at the begining of SDL_EGL_SwapBuffers(),
and putting the application into background.
Use a semaphore to prevent concurrency issues between Java Activity and Native thread code, when using 'Android_Window'.
(Eg. Java sending Touch events, while native code is destroying the main SDL_Window. )
This is the best option for macOS and iOS, the only platforms with Metal.
Pre-Metal versions of these platforms will fall back to OpenGL (ES), as
appropriate.
Huge thanks to Alexander Szpakowski, who worked incredibly hard to get the
Metal renderer to such a high-quality state!
Not only does this fix macOS 10.14 ("Mojave")'s broken NSOpenGLCPSwapInterval
support, it also lets us implement "adaptive vsync" on macOS!
CVDisplayLink is supported back to macOS 10.4 ("Tiger"), so we just use it
universally without version checks and dump NSOpenGLCPSwapInterval, Mojave or
not.
Switching between renderers "software -> opengl -> opengles2 -> software" fails.
"opengl -> opengles2" calls SDL_RecreateWindow() and frees "window->surface"
without marking it as "surface_invalid".
foo.null
I'm on macOS 10.14 and I think I'm using or around SDL 2.0.9. This is about the menu bar that SDL sets up which looks like:
<App Name> <Window> <View>
1. View menu never proceeds after the Window menu in any Mac application (it is always before).
2. For SDL, the only purpose of the View menu is for a single fullscreen menu item, which is not justifiable enough to reserve space for a menu. The View menu should thus be removed, and the full screen menu item should be added at the end inside of Window's menu. See built in apps like Dictionary, Chess, App Store (on 10.14) that do this.
3. SDL should add a "Close" menu item to the Window's submenu, and it should be the first item. Its key equivalent should map to command w. Without this, you cannot close the game window via this shortcut, and you cannot close the app's About window via this shortcut.
4. Apps typically use "Enter Full Screen" or "Exit Full Screen" depending on context, not "Toggle Full Screen" which is less user friendly -- I personally care about this point the least.
This happens if you try to lock the pointer and (caps & WL_SEAT_CAPABILITY_POINTER) is false
Leading to input->pointer being NULL which ends up bringing the wayland client down (at lease on weston)
Visual Studio doesn't define __ARM_ARCH nor _ARM_NEON, but _M_ARM and _M_ARM64,
so SDL_HasNEON() was bypassed.
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE doesn't see to be defined (but still works
when defined as 19).
Only __ARM_NEON is defined with Android NDK and arm64-v8a
Tested on ndk-r18, ndk-r13 and also Xcode.
(Visual Studio needs a different fix).
Fixes Bugzilla #4409.
* Search for valid encoder in connector when it doesn't have an
encoder ID set.
* Search for valid CRTC in resources and encoder's possible CRTCs
when encoder doesn't have one set.
* Select default mode if CRTC doesn't have a valid one.
* Pick current_mode's W/H/Refresh Rate basing on current and
valid CRTC mode, not the saved one.
Cameron Gutman
After updating to SDL 2.0.9, I got a user report that my app was crashing when closing a SDL_WINDOW_FULLSCREEN window to return to my Qt-based UI. It looks like the dead SDL window is getting a spurious updateLayer call which is causing SDL to dereference a null SDL_WindowData pointer.
For some reason, this only happens when using SDL_WINDOW_FULLSCREEN and not windowed or SDL_WINDOW_FULLSCREEN_DESKTOP. I was also unsuccessful in my attempt to get a simple reproducer for this crash. The Session.cpp code is available 688c4a90d9/app/streaming/session.cpp but I slightly modified it (adding a SDL_PumpEvents() call at 1179 to immediately trigger the issue, otherwise it happened when Qt next pumped the event loop).
The crashing line is:
NSMutableArray *contexts = data->nscontexts;
Daniel Gibson
Even though my game (dhewm3) doesn't use SDL_INIT_JOYSTICK, SDL_PumpEvent() calls SDL_JoystickUpdate() which ends up calling hid_enumerate() every three seconds, and sometimes on my Win7 box hid_enumerate() takes about 5 seconds, which causes the whole game to freeze for that time.
maxxus
The Dualshock 3's motion sensors don't seem to be reported by the call to EVIOCGBIT but they still send EV_ABS events. Because they're not reported by EVIOCGBIT they're not assigned a proper axis ids and the default of 0 is used, which is the valid id for the left analog sticks left/right axis.
midwan
When trying to compile on a Raspberry Pi 3, running Raspbian Stretch (fully updated), a warning appears:
/home/pi/projects/SDL/src/test/SDL_test_memory.c: In function ?SDL_TrackAllocation?:
/home/pi/projects/SDL/src/test/SDL_test_memory.c:112:109: warning: format ?%llx? expects argument of type ?long long unsigned int?, but argument 5 has type ?unw_word_t {aka unsigned int}? [-Wformat=]
snprintf(entry->stack_names[stack_index], sizeof(entry->stack_names[stack_index]), "%s+0x%llx", sym, offset);
Touch device types include SDL_TOUCH_DEVICE_DIRECT (a touch screen with window-relative coordinates for touches), SDL_TOUCH_DEVICE_INDIRECT_ABSOLUTE (a trackpad-style device with absolute device coordinates), and SDL_TOUCH_DEVICE_INDIRECT_RELATIVE (a trackpad-style device with screen cursor-relative coordinates).
Phone screens are an example of a direct device type. Mac trackpads are the indirect-absolute touch device type. The Apple TV remote is an indirect-relative touch device type.
For starters, we need to correctly respond to 0,0 configure after unsetting
fullscreen. Also, turns out that there should be no drawing calls at all
in between eglSwapBuffers and wl_egl_window_resize, as otherwise EGL can
already allocate a wrongly sized buffer for a next frame, so handle those
together.
Sylvain
SDL_android.c
src/core/android/SDL_android.c:1302:5: warning: variable 'br' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default:
^~~~~~~
src/core/android/SDL_android.c:1306:12: note: uninitialized use occurs here
return br;
^~
src/core/android/SDL_android.c:1270:12: note: initialize the variable 'br' to silence this warning
jint br;
^
Maybe we could add some basics warning flags, not to see all warnings, but so that new warnings are caught sooner.
I would go for -Wall -Wextra, and some -Wno-warning for the allowed warnings.
./src/render/SDL_render.c(2168): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2168): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2175): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2175): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
Adds controller bindings to support the "Xbox One Wireless Controller
(Model 1708)" on Linux. The Model 1708 was released in 2016 alongside the
Xbox One S. It is the current model being sold by Microsoft as of writing.
(October 22, 2018)
src/vendor/SDL2/src/joystick/bsd/SDL_sysjoystick.c:353:5: error:
ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
reported by 'bch' at https://discourse.libsdl.org/t/25231
https://bugzilla.libsdl.org/show_bug.cgi?id=4350
We can't safely call GL_DestroyRenderer() until GL_LoadFunctions()
succeeds because we will be missing functions that we try to use
when activating the renderer for destruction if we have an GL context.
Rainer Sabelka
After I did an upgrade of my arch Linux installation (resulting in an update of Mesa to version 18.2.3), all my SDL2 applications which use the KMS/DRM driver stopped working.
Reason: Creating a Window with SDL_CreateWindow failed because the call to EGL
eglCreateWindowSurface() returns an error "EGL_BAD_MATCH".
After investigating with the debugger I figured, that the configuration, which has been selected from the output of eglChooseConfig(), has an "EGL_NATIVE_VISUAL_ID" which does not match the "format" of the underlying gbm surface.
The attached patch fixes the problem. It does so, by mimicking Weston's behavior.
All configurations returned from eglChooseConfig() which have an visual_id different from the gbm format are discarded, and only from the remaining ones the "best" match is selected.
Rainer Sabelka
When using SLD2 on a Linux console with the KMS/DRM video backend and Linux evdev keyboard support, the caps lock, scroll lock, and num lock leds do not work.
The attached patch adds ioctls for setting the LED state in SDL_evdev_kbd.c
Sylvain
Re-opening this issue.
It fixes the test-case, but it introduces a regression with another bug (bug #4313).
So here's a new patch that activate cropping of the source surface to solve the issue.
It also reverts the wrong changeset.
It prevents unneeded colorkey error message.
Otherwise, we are using the allocator before the app can set up its own hooks.
Now we use VirtualAlloc, and WideCharToMultiByte (because SDL_iconv uses
SDL_malloc, too!) to get ready to call into SDL_main.
This also makes console_wmain() call into the same routines as everything
else, so we don't have to deal with those allocations, too. Hopefully we
end up with the same results from GetCommandLine() as we do in wargv.
Fixes Bugzilla #4340.
Include guards in most changed files were missing, I added them keeping
the same style as other SDL files. In some cases I moved the include
guards around to be the first thing the header has to take advantage of
any possible improvements compiler may have for inclusion guards.
If we run into problems where these events aren't dispatched (initialized on a different thread than the main thread?) we may need to create a separate thread to handle device notifications like we do with the windows joystick subsystem.
If you enable this, you'll need to link with CoreBluetooth.framework and add something like this to your Info.plist:
<key>NSBluetoothPeripheralUsageDescription</key>
<string>MyApp would like to remain connected to nearby bluetooth Game Controllers and Game Pads even when you're not using the app.</string>
It needs to use Bool (which is an int) and not BOOL (which is CARD8), which
causes problems on platforms with different byte order and alignment, etc.
Fixes Bugzilla #4326.
On Mojave, this will report large numbers for retina displays in fullscreen
mode, which isn't how it works on previous versions.
(transplanted from c6c1731780e2bef94f944a4795e2dfbba46d9500)
I have no idea if this works (or if it ever worked, having now examined this
code), as I have no way to compile or test this.
If it's broken, send patches. :)
This means it doesn't have to block while the current frame finishes using the
vertex buffer; it just moves on to the next, probably-not-in-use buffer.
- high-level filters out duplicate render commands from the queue so
backends don't have to.
- Setting draw color is now a render command, so backends can put color
information into the vertex buffer to upload with everything else instead
of setting it with slower dynamic data later.
- backends can request that they always batch, even for legacy programs,
since the lowlevel API can deal with it (Metal, and eventually Vulkan
and such...)
- high-level makes sure the queue has at least one setdrawcolor and
setviewport command before any draw calls, so the backends don't ever have
to manage cases where this hasn't been explicitly set yet.
- backends allocating vertex buffer space can specify alignment, and the
high-level will keep track of gaps in the buffer between the last used
positions and the aligned data that can be used for later allocations
(Metal and such need to specify some constant data on 256 byte boundaries,
but we don't want to waste all that space we had to skip to meet alignment
requirements).
It now uses a growable linked list that keeps a pool of allocated items for
reuse, and reallocs the vertex array as necessary. Testsprite2 can scale to
20,000 (or more!) draws now without drama.
This moves all the rendering to a command list that is flushed to the GL as
necessary, making most common activities upload a single vertex buffer per
frame and dramatically reducing state changes. In pathological cases,
like Emscripten running on iOS's Safari, performance can go from a dozen
draw calls killing your performance to 1000 draw calls running smoothly.
This is work in progress, and not ready to ship. Among other things, it has
a hardcoded array that isn't checked for overflow. But the basic idea is
sound!
Sylvain Becker
Sam Lantinga
Ryan C. Gordon
Sebastian Krzyszkowiak
Silent
Jimb Esser
Ethan Lee
Alex Szpakowski
Alon Zakai
Charlie Birks
kichikuou
Sylvain Beucler
Brandon Schaefer
Sergey Zhuravlevich
Ozkan Sezer
Steven M. Vascellaro
Cameron Gutman
Micha? Janiszewski