This device is a copy of the Xbox Controller S and currently the one most sold
when shopping for a 'new' Xbox gamepad on eBay and AliExpress.
Except for the quirky USB ID id behaves just like a normal Xbox controller (when
ignoring the subpar build quality)
LinGao
We build SDL with Visual studio 2017 compiler on Windows Server 2016, but it failed to build due to error LNK2019: unresolved external symbol _memset referenced in function _IMA_ADPCM_Decode on latest default branch. And we found that it can be first reproduced on ca7283111ad0 changeset. Could you please help have a look about this issue? Thanks in advance!
Caleb Cornett
On iOS 12, creating a window with the SDL_WINDOW_FULLSCREEN flag does not dim the home indicator or defer system gestures. The same goes for setting the SDL_HINT_IOS_HIDE_HOME_INDICATOR to "2" -- it has no effect at all.
I've tracked down the source of this misbehavior to a timing issue. The initial `setNeedsUpdate...` calls were happening too early and getting applied to the launch screen by mistake. In the attached patch, I've added a call to those functions right after the launch screen is hidden so that they apply to the main view controller instead. This appears to fix the issue, at least on my iPhone 6s Plus.
Simon Hug
Attached is a minor cleanup patch. It changes the option name of one hint to something better, puts one or two more checks in, and adds explicit casting where warnings could appear otherwise.
I hope the naming of the hints and their options is acceptable. It would be kind of awkward to change them after they get released with an official SDL version.
Simon Hug
I had a look at this and made some additions to SDL_wave.c.
The attached patch adds many checks and error messages. For some reason I also added A-law and ?-law decoders. Forgot exactly why... but hey, they're small.
The WAVE format is seriously underspecified (at least by the documents that are publicly available on the internet) and it's a shame Microsoft never put something better out there. The language used in them is so loose at times, it's not surprising the encoders and decoders behave very differently. The Windows Media Player doesn't even support MS ADPCM correctly.
The patch also adds some hints to make the decoder more strict at the cost of compatibility with weird WAVE files.
I still think it needs a bit of cleaning up (Not happy with the MultiplySize function. Don't like the name and other SDL code may want to use something like this too.) and some duplicated code may be folded together. It does work in this state and I have thrown all kinds of WAVE files at it. The AFL files also pass with it and some even play (obviously just noise). Crafty little fuzzer.
Any critique would be welcome. I have a fork of SDL with a audio-loadwav branch over here if someone wants to use the commenting feature of Bitbucket:
https://bitbucket.org/ChliHug/SDL
I also cobbled some Lua scripts together to create WAVE test files:
https://bitbucket.org/ChliHug/gendat
Sylvain
On Android, if you set no attribute using SDL_GL_SetAttribute(), and try to create a SDL Render OpenGLES 1:
- it loads first by default GLESv2 libraries
- creates the rendere OpenGLES 1
- recreates the Window to have a context 1.1 ( https://hg.libsdl.org/SDL/file/4db4cfd59470/src/render/opengles/SDL_render_gles.c#l298 )
But it doesn't unload libraries, then reload GLESv1 lib. So the SDL_Renderer OpenGLES 1 is working with GLES 2 libs, which seems inconsistent.
If you, at first, set
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
It will correctly load GLES v1 libraries.
Here's a small patch to reload egl libs when SDL_RecreateWindow() is called.
It fixes the issue, also the case from bug 4042
( SDL_RecreateWindow() is used by SDL_Renderer gl, gles1, gles2. )
janisozaur
There are many cases which are not able to be handled by SDL's audio conversion routines, including too low (negative) rate, too high rate (impossible to allocate).
This patch aims to report such issues early and handle others in a graceful manner. The "INT32_MAX / RESAMPLER_SAMPLES_PER_ZERO_CROSSING" value is the conservative approach in terms of what can _technically_ be supported, but its value is 4'194'303, or just shy of 4.2MHz. I highly doubt any sane person would use such rates, especially in SDL2, so I would like to drive this limit further down, but would need some assistance to do that, as doing so would have to introduce an arbitrary value. Are you OK with such approach? What would a good value be? Wikipedia (https://en.wikipedia.org/wiki/High-resolution_audio) lists 96kHz as the highest sampling rate in use, even if I quadruple it for a good measure, to 384kHz it's still an order of magnitude lower than 4MHz.
If IMA ADPCM format chunk was too short, InitIMA_ADPCM() parsing it
could read past the end of chunk data. This patch fixes it.
CVE-2019-7578
https://bugzilla.libsdl.org/show_bug.cgi?id=4494
Signed-off-by: Petr P?sa? <ppisar@redhat.com>
ace
I got this bug in SDL_ttf:
https://bugzilla.libsdl.org/show_bug.cgi?id=4524
Sylvain proposed solution:
SDL_RWseek(RWops, 0, RW_SEEK_SET);
And it works, but i can use it my project, because it written in C# with SDL2-CS wrapper and there not export for macroses:
#define SDL_RWsize(ctx) (ctx)->size(ctx)
#define SDL_RWseek(ctx, offset, whence) (ctx)->seek(ctx, offset, whence)
#define SDL_RWtell(ctx) (ctx)->seek(ctx, 0, RW_SEEK_CUR)
#define SDL_RWread(ctx, ptr, size, n) (ctx)->read(ctx, ptr, size, n)
#define SDL_RWwrite(ctx, ptr, size, n) (ctx)->write(ctx, ptr, size, n)
#define SDL_RWclose(ctx) (ctx)->close(ctx)
Therefore, I suggest replacing this macros with functions so that they can be exported and used in bindings
This device is a copy of the Xbox Controller S and currently the one most sold
when shopping for a 'new' Xbox gamepad on eBay and AliExpress.
Except for the quirky USB ID id behaves just like a normal Xbox controller (when
ignoring the subpar build quality)
Noam Preil
In src/joystick/linux/SDL_sysjoystick.c:
The ConfigJoystick function's axes detection starts with a for loop using an index i for Linux's axes names. When i gets to ABS_HAT0X, it's set to ABS_HAT3Y and a continue statement appears, to skip the hats. This makes sense, as SDL handles hats separately from axes.
However, in PollAllValues, *two* indices are used: a and b. Both start out the same, and remain so until the hats are reached. At that point, a becomes identical to the i from ConfigJoystick's loop, but b is equal to a - (ABS_HAT3Y - ABS_HAT0X), or a - 8.
While all the joystick->hwdata->abs_* structures in ConfigJoystick used i - which would here be a - as both the index and the ioctl argument, PollAllValues uses b for the structure index and a as the ioctl argument.
It would appear, however, that no joystick HAS such axes, and that the b index is entirely unnecessary.
I tested three separate joysticks, and while that was far from a complete listing, I was unable to find a joystick with an axis above 0x08.
Dexter Friedman
When using a Dualshock 4 controller (model numbers CUH-ZCT1U and CUH-ZCT2U), pressing anywhere on the center touchpad does not send an SDL_JOYBUTTONDOWN event. I have verified this with testjoystick:
Repro steps:
1. Plug in a DS4 over USB
2. Compile testjoystick and run: testjoystick.exe 0
3. Press and hold the touchpad. Observe that no lime green box appears
Expected behavior:
A lime green box appears while the touchpad is pressed.
Notes:
I've attached a patch here that works on my PC and produces the expected behavior in testjoystick, for both DS4 model numbers I listed earlier.
If I understand correctly, by exposing this as a joystick button, the gamecontroller API mapping can be modified with a change to gamecontrollerdb.txt in the future.
Matt Brocklehurst
We've noticed that if you are playing audio on Windows via the WASAPI interface and you unplug and reconnect the device a few times the program hangs.
We've debugged the problem down to
static void
WASAPI_WaitDevice(_THIS)
{
... snip ...
if (WaitForSingleObjectEx(this->hidden->event, INFINITE, FALSE) == WAIT_OBJECT_0) {
... snip ...
}
This WaitForSingleObjectEx does not havbe a time out defined, so it hangs there forever.
Our suggested fix we found was to include a time out of say 200mSec
We have done quite a bit of testing with this fix in place on various hardware configurations and it seems to have resolved the issue.
The Nintendo USB GameCube adapter has four controller ports. Return
the port number as 0 to 3 from SDL_JoystickGetPlayerIndex() and
SDL_JoystickGetDevicePlayerIndex().
Nia Alarie
The NetBSD audio driver has a few problems. Lots of obsolete code, and extremely bad performance and stuttering.
I have a patch in NetBSD's package system to improve it. This is my attempt to upstream it.
The changes include:
* Removing references to defines which are never used.
* Using the correct structures for playback and recording, previously they were the wrong way around.
* Using the correct types ('struct audio_prinfo' in contrast to 'audio_prinfo')
* Removing the use of non-blocking I/O, as suggested in #3177.
* Removing workarounds for driver bugs on systems that don't exist or use this driver any more.
* Removing all usage of SDL_Delay(1)
* Removing pointless use of AUDIO_INITINFO and tests that expect AUDIO_SETINFO to fail when it can't.
These changes bring its performance in line with the DSP audio driver.
bplu4t2f
When num lock is on, the scancode reported for numpad 5 is SDL_SCANCODE_KP_5, which is correct. However, when num lock is off, windows reports the VK_CLEAR virtual key code, which is incorrectly translated into SDL_SCANCODE_CLEAR inside of the VKeytoScancode(WPARAM vkey) function.
Jan Martin Mikkelsen
The file src/core/linux/SDL_evdev.c uses the Linux specific types __u32 and __s32. This breaks things on FreeBSD when building with evdev.
Cameron Gutman
I was trying to use SDL_GetQueuedAudioSize() to ensure my audio latency didn't get too high while streaming data in from the network. If I get more than N frames of audio queued, I know that the network is giving me more data than I can play and I need to drop some to keep latency low.
This doesn't work well on WASAPI out of the box, due to the addition of GetPendingBytes() to the amount of queued data. As a terrible hack, I loop 100 times calling SDL_Delay(10) and SDL_GetQueuedAudioSize() before I ever call SDL_QueueAudio() to get a "baseline" amount that I then subtract from SDL_GetQueuedAudioSize() later. However, because this value isn't actually a constant, this hack can cause SDL_GetQueuedAudioSize() - baselineSize to be < 0. This means I have no accurate way of determining how much data is actually queued in SDL's audio buffer queue.
The SDL_GetQueuedAudioSize() documentation says: "This is the number of bytes that have been queued for playback with SDL_QueueAudio(), but have not yet been sent to the hardware." Yet, SDL_GetQueuedAudioSize() returns > 0 value when SDL_QueueAudio() has never been called.
Based on that documentation, I believe the current behavior contradicts the documented behavior of this function and should be changed in line with Boris's patch.
I understand that exposing the IAudioClient::GetCurrentPadding() value is useful, but a solution there needs to take into account what of that data is silence inserted by SDL and what is actual data queued by the user with SDL_QueueAudio(). Until that happens, I think the best approach is to remove the GetPendingBytes() call until SDL is able to keep track of queued data to make sense of it. This would make SDL_GetQueuedAudioSize() possible to use accurately with WASAPI.
Closing the window is asynchronous, but we free the window data immediately,
so we can get an updateLayer callback before the window is really destroyed which
will cause us to access the freed memory.
Clearing the content view will cause it to be immediately released, so no further
updateLayer callbacks will occur.
Sylvain
Currently SDL_CreateTextureFromSurface picks first valid format, and do a conversion.
format = renderer->info.texture_formats[0];
for (i = 0; i < renderer->info.num_texture_formats; ++i) {
if (!SDL_ISPIXELFORMAT_FOURCC(renderer->info.texture_formats[i]) &&
SDL_ISPIXELFORMAT_ALPHA(renderer->info.texture_formats[i]) == needAlpha) {
format = renderer->info.texture_formats[i];
break;
It could try to find a better format, for instance :
if SDL_Surface has no Amask, but a colorkey :
if surface fmt is RGB888, try to pick ARGB8888 renderer fmt
if surface fmt is BGR888, try to pick ABGR8888 renderer fmt
else
try to pick the same renderer format as surface fmt
if no format has been picked, use the fallback.
I think it goes with bug 4290 fastpath BlitNtoN
when you expand a surface with pixel format of size 24 to 32, there is a fast path possible.
So with this issue:
- if you have a surface with colorkey (RGB or BGR, not palette), it takes a renderer format where the conversion is faster.
(it avoids, if possible, RGB -> ABGR which means switching RGB to BGR)
- if you have a surface ABGR format, it try to take the ABGR from the renderer.
(it avoids, if possible, ABGR -> ARGB, which means switch RGB to BGR)
Thomas Frohwein
Hi,
If a gamepad lists the Dpad as 4 buttons (Dpad Up,Down, Left, Right) like with the Xbox 360 gamepad / XInput report descriptor used by OpenBSD (https://github.com/openbsd/src/blob/master/sys/dev/usb/uhid_rdesc.h#L184), this is not recognized by the SDL BSD backend and no hat or any other listing for the D-pad exists, e.g. in sdl2-jstest (https://gitlab.com/sdl-jstest/sdl-jstest).
The attached diff fixes this and makes the D-pad on my Xbox 360 and Logitech F310 controllers usable. It adds a hat to nhats when usage HUG_DPAD_UP is found, reads the state of the D-pad buttons into array dpad[], and turns the value of dpad[] into an SDL hat direction (dpad_to_sdl()).
Tested and works with Xbox 360 controller and Logitech F310 in XInput mode. Software-side tested with sdl2-jstest and Owlboy where this worked without problems or regressions.
I don't know if this would be applicable to other *BSDs and don't have an install to test it with, therefore wrapped it in __OpenBSD__ ifdefs.
Thanks,
thfr
Removed incorrect call to SDL_SendWindowEvent(window, SDL_WINDOWEVENT_MOVED, x, y);
If the position of the window isn't adjusted in the SetWindowPosition() call, then sending the window event would have no effect because x and y equals the window x and y. If the position of the window is adjusted in the SetWindowPosition() call, then we don't want to clobber it with values that the user passed in.
Sylvain
OpenGLES2 SDL renderer has support for textures ARGB, ABGR, RGB and BGR, whereas OpenGL SDL renderer only had ARGB.
If you think it's worth adding it, here's a patch. I quickly tried and it worked, but there may be missing things or corner case.
Andrei Drexler
For X11 GenericEvents, the associated data is only available between a call to XGetEventData and the matching XFreeEventData, i.e. in X11_HandleGenericEvent. Trying to call XGetEventData a second time on the same event will fail, so an application that wants to inspect XInput2 events (e.g. for stylus pressure) has no way of retrieving its data from queued SYSWM events.
The attached patch (based on SDL-2.0.7-11629) sends SYSWM messages from X11_HandleGenericEvent while the data is still available, allowing client code to register an event filter/watcher and process the event inside the callback.
Vivante drivers use the VK_KHR_display extension for rendering directly
to the frame buffer. This patch adds support to the video driver for
Vulkan rendering using that method.
- Add an utility function SDL_Vulkan_Display_CreateSurface that creates
a surface using this extension. The display to use (if there are
multiple) can be overridden using the environment variable
"SDL_VULKAN_DISPLAY".
- Use this function in a new compilation unit SDL_vivantevideo.c,
which implements the SDL_VIDEO_VULKAN methods of the driver structure.
Dan Ginsburg
I've seen this on several devices including Moto Z running Android 7 and a Snapdragon 845 running Android 9.
What happens is as follows:
SDLActivity.onWindowFocusChanged(true) happens pretty early on, but it's before we've done SDL_CreateWindow and so Android_Window is 0x0 thus this message does not get sent:
JNIEXPORT void JNICALL SDL_JAVA_INTERFACE(nativeFocusChanged)(
JNIEnv *env, jclass cls, jboolean hasFocus)
{
SDL_LockMutex(Android_ActivityMutex);
if (Android_Window) {
__android_log_print(ANDROID_LOG_VERBOSE, "SDL", "nativeFocusChanged()");
SDL_SendWindowEvent(Android_Window, (hasFocus ? SDL_WINDOWEVENT_FOCUS_GAINED : SDL_WINDOWEVENT_FOCUS_LOST), 0, 0);
}
SDL_UnlockMutex(Android_ActivityMutex);
}
When the window does get created, in Android_CreateWindow it does this:
window->flags &= ~SDL_WINDOW_RESIZABLE; /* window is NEVER resizeable */
window->flags &= ~SDL_WINDOW_HIDDEN;
window->flags |= SDL_WINDOW_SHOWN; /* only one window on Android */
window->flags |= SDL_WINDOW_INPUT_FOCUS; /* always has input focus */
/* One window, it always has focus */
SDL_SetMouseFocus(window);
SDL_SetKeyboardFocus(window);
The SDL_SetKeyboardFocus does send an SDL_WINDOWEVENT_FOCUS_GAINED message, but it gets eaten in SDL_SendWindowEvent because we've forced SDL_WINDOW_INPUT_FOCUS beforehand:
case SDL_WINDOWEVENT_FOCUS_GAINED:
if (window->flags & SDL_WINDOW_INPUT_FOCUS) {
return 0;
}
window->flags |= SDL_WINDOW_INPUT_FOCUS;
SDL_OnWindowFocusGained(window);
break;
I can fix the problem if I comment out this line from Android_CreateWindow:
window->flags |= SDL_WINDOW_INPUT_FOCUS; /* always has input focus */
I would propose that as a fix unless there is a reason not to.
Sylvain 2019-04-18 21:22:59 UTC
Changes:
- SDL_WINDOWEVENT_FOCUS_GAINED and SDL_WINDOWEVENT_FOCUS_LOST are sent when the java method onWindowFocusChanged() is called.
- If we have support for MultiWindow (eg API >= 24), SDL event loop is blocked/un-blocked (or simply egl-backed-up or not), when java onStart()/onStop() are called.
- If not, this behaves like now, SDL event loop is blocked/un-blocked when onPause()/onResume() are called.
So if we have two app on screen and switch from one to the other, only FOCUS events are sent (and onPause()/onResume() are called but empty. onStart()/onStop() are not called).
The SDL app, un-focused, would still continue to run and display frames (currently the App would be displayed, but paused).
Like a video player app or a chronometer that would still be refreshed, even if the window hasn't the focus.
It should work also on ChromeBooks (not tested), with two apps opened at the same time.
I am not sure this fix Dan's issue. Because focus lost event triggers Minimize function (which BTW is not provided on android).
https://hg.libsdl.org/SDL/file/bb41b3635c34/src/video/SDL_video.c#l2653https://hg.libsdl.org/SDL/file/bb41b3635c34/src/video/SDL_video.c#l2634
So, in addition, it would need to add by default SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS to 0.
So that the lost focus event doesn't try to minimize the window. And this should fix also the issue.
SDL_GetWindowDisplayMode was returning an incorrect result on iPhone Plus devices (tested on iOS 12.1/12.2). The problem was that the value returned by UIScreenMode was assumed to be the physical pixels on the display, rather than the scaled retina pixels. The fix is to use the scale returned by UIScreen.scale rather than the nativeScale.
java layer runs as if separate mouse and touch was 1,
Use SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS
for generating synthetic touch/mouse events
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.
