|
4fb06a2a
|
2020-03-10T18:25:47
|
|
Updated SDL to version 2.0.13 for development builds
|
|
|
5c87b8e1
|
2020-03-10T18:17:41
|
|
Added tag release-2.0.12 for changeset 6915d6569091
|
|
|
fe979921
|
2020-03-10T17:35:14
|
|
Read the buttons on Nintendo Switch and GameCube controllers as they are labeled, and swap them if the applications wants positional button data instead.
|
|
|
4caa6a06
|
2020-03-10T16:41:42
|
|
Fixed bug 4921 - Do not swap B/X buttons on GameCube controller unless it's requested
Ethan Lee
Basically replicating the solution of the Switch Controller's button label issue. Physical layout should take priority unless it's explicitly requested by the user or application!
|
|
|
342f62ca
|
2020-03-10T16:29:28
|
|
Fixed bug 5022 - SDL_iconv_string can get stuck in an infinite loop when encountering invalid characters
ciremo6483
In `SDL_iconv_string` the `while (inbytesleft > 0)` loop can end up in a state where it never terminates because the library `iconv` function called from `SDL_iconv` doesn't consume any bytes.
This happened when a `WCHAR_T` input string was being converted to `UTF-8` but contained invalid characters. It would first It would first skip a few bytes due to `case SDL_ICONV_EILSEQ` but when there were 3 bytes remaining of `inbytesleft` `iconv` just didn't consume anything more (but didn't throw an error either).
It just so happens that the Microsoft Classic IntelliMouse `product_string` contains such invalid characters (`"Microsoft? Classic IntelliMouse?"`), meaning the function would get stuck with said mouse plugged in.
A fix for this would be to check if `inbytesleft` was unchanged after an iteration and in that case either decrement the counter like when `SDL_ICONV_EILSEQ` is returned or simply break the loop.
|
|
|
1f4965c8
|
2020-03-08T21:24:06
|
|
Fixed warnings building with mingw64
|
|
|
611403dd
|
2020-03-08T21:02:40
|
|
Clarified that the clip rectangle is defined relative to the viewport, and added a clip test to testviewport.c
|
|
|
c8c05a9f
|
2020-03-08T19:23:21
|
|
Fixed bug 4991 - Pixel shader problem when recreating a texture for direct3d renderer
cmediaplayer
Hi, i already mentioned in the SDL discourse a bug that recreating of a texture occours pixel shader problem on direct3d renderer. There is no problem for direct3d11. You can see the issue by using my app named C Media Player which is available for Windows for free using my web site www.cmediaplayer.com. Just follow the steps:
*Open a media file
*When playing the file change the scale quality under the video menu.
*You will see the problem.
|
|
|
367a3561
|
2020-03-08T18:56:07
|
|
Don't release the backbuffer on error, we didn't acquire it.
|
|
4e0fb110
|
2020-03-07T19:21:21
|
|
Clear the old player index slot when moving to a new one
|
|
|
165ccaa8
|
2020-03-07T17:20:04
|
|
Fix incorrect player index when assigning a joystick the same index twice
Prior to this fix, we would hit the existing_instance >= 0 case and move the joystick
again to a different index than the one requested by the caller. It also breaks the assumption
that a SDL_JoystickID is only present in SDL_joystick_players at one location.
|
|
|
e152a3ce
|
2020-03-07T13:59:42
|
|
direct3d: Don't attempt to create zero sized vertex buffer
|
|
|
467434b9
|
2020-03-07T13:17:28
|
|
Added support for indicating player index on DS4 controllers
|
|
|
82be6dd7
|
2020-03-07T08:48:04
|
|
Fixed regression in bug 4966 - KMSDRM: Add dynamic modeset support
Anthony Pesch
I was just communicating with one of the Retropie developers regarding this.
This change removed the forced window focus change on creation (https://github.com/inolen/SDL-mirror/commit/3534cb3793f4744509f020f1267f510ec7099366) as part of the change no longer assumes there's only a single window being created. This was perhaps an over-aggressive removal.
Due to that change, joystick events are only received if SDL_SetKeyboardFocus is called explicitly, or if the app has specified SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS.
I think that part of my change should be reverted to continue setting mouse / keyboard focus to the window being created. If SDL_WINDOW_INPUT_FOCUS is to be used as an input flag the code could be conditional, but that would still leave existing software broken.
|
|
|
37faac0d
|
2020-03-05T08:43:16
|
|
Fixed java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.WindowManager android.app.Activity.getWindowManager()' on a null object reference
|
|
|
e9bc21fb
|
2020-03-04T17:10:37
|
|
Fixed rumble for third-party Nintento Switch Pro controllers
The 8BitDo SF30 Pro Gamepad will generate a single motor pulse for each rumble message, so we need to do this frequently to have continous rumble on this device.
|
|
|
428cfddb
|
2020-03-04T14:59:44
|
|
Fixed crash when a controller is disconnected while rumble is pending
|
|
|
281d05a6
|
2020-03-04T09:42:10
|
|
Fixed handling the guide button with both V1 and V2 of the Xbox One Bluetooth wireless protocols
|
|
|
69a8c846
|
2020-03-04T09:42:08
|
|
Fixed using more than one Xbox Bluetooth controller
Don't prevent duplicate devices using hidraw, instead libusb takes precedence and all hidraw devices that aren't handled by libusb are available
|
|
|
2a91f682
|
2020-03-03T17:56:33
|
|
Fixed bug 5012 - KaiOS keycodes support
pelya
KaiOS is an OS for feature phones, with numeric keypad and non-touch screen, and typically 512 Mb RAM and 4 Gb flash.
It is based on Firefox OS, all apps are made with HTML5 and Javascript. SDL can be cross-compiled using emscripten and packaged as native app.
This patch adds support for star '*' and pound '#' keys on such phones to generate SDL events.
|
|
27889d02
|
2020-03-03T12:31:41
|
|
winrt: Wait for EnumerationCompleted before leaving WASAPI_EnumerateEndpoints
|
|
|
96836ec6
|
2020-03-03T09:22:43
|
|
Add 500ms max wait time for hid_write to complete on Windows
It appears that with some (presumably) flaky drivers or hardware that the WriteFile in hid_write never completes leading to GetOverlappedResult to block forever waiting for it.
|
|
|
07000bfc
|
2020-03-02T17:31:58
|
|
Fixed bug 5010 - SDL_Init with SDL_INIT_JOYSTICK hangs for 10 seconds when playing audio from another application
Jake Breen
I have tracked it down to a call on
hid_device_info() -> HidD_GetManufacturerString (Line 499 in src\hidapi\windows\hid.c)
|
|
|
c7a739be
|
2020-03-02T15:24:10
|
|
Fixed bug 4643 - Append EGL CFLAGS in CheckOpenGLESX11
Danilo Spinella
EGL need -DMESA_EGL_NO_X11_HEADERS in systems without X11 installed. Make CMake checks import EGL CFLAGS.
Relevant bug: https://bugzilla.libsdl.org/show_bug.cgi?id=4243
|
|
|
aa384ad0
|
2020-03-02T15:21:07
|
|
Fixed bug 5001 - Feature request: SDL_isupper & SDL_islower
|
|
|
a8f91340
|
2020-03-02T15:14:52
|
|
Updated configure with change from last commit
|
|
11b63fac
|
2020-03-02T15:14:02
|
|
Prevent Mesa from including X11 headers if X11 is disabled
This fixes compilation errors that occur when trying to compile SDL2 for
a X11-less target. The errors were due to the fact that Mesa will
include X11 headers unless a couple of macros are defined.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
|
|
|
3b3ae4d1
|
2020-03-02T15:06:47
|
|
Possible fix for bug 5010 - SDL_Init with SDL_INIT_JOYSTICK hangs for 10 seconds when playing audio from another application
Jake Breen
When I run SDL_INIT with SDL_INIT_JOYSTICK it stalls for about 10 seconds (last report was 10,615ms), but only if I'm currently playing audio. (Like in Spotify for example.)
querying something related to device access (last dll loaded)
'BabbysFirst64.exe' (Win32): Loaded 'C:\Windows\SysWOW64\deviceaccess.dll'.
I use a USB DAC because my mobo's audio out is pretty not great. And I've noticed unplugging it seems to solve the issue. I haven't noticed any other issues that are caused by my DAC.
My DAC is the Sound BlasterX G1 https://us.creative.com/p/gaming-headsets/sound-blasterx-g1
Vid = 041E
PID = 3249
My system specs:
- Windows 10 Pro
- Ryzen 2700x
- 16GB Ram
- Nvidia 2070 RTX
Additional USB devices plugged in:
- Valve Index
- Xbox One Elite Controller
|
|
|
a19757ac
|
2020-03-02T14:55:40
|
|
Fixed bug 5007 - Segfault in KMSDRM_VideoQuit() on Raspberry Pi Zero with no display attached
Charles Huber
This patch fixes the segfault on my Pi, though the valid display index range reported by the CHECK_DISPLAY_INDEX() macro in src/video/SDL_video.c is a little weird:
$ SDL_VIDEO_EGL_DRIVER=libEGL.so SDL_VIDEO_GL_DRIVER=libGLESv2.so ./a.out
SDL_Init(): displayIndex must be in the range 0 - -1
|
|
|
f00ddd0a
|
2020-03-02T11:39:44
|
|
Updated WhatsNew.txt with SDL 2.0.12 release notes
|
|
|
25061816
|
2020-03-02T10:58:08
|
|
Fixed compile warning
|
|
|
eb19631a
|
2020-03-02T10:57:57
|
|
This controller firmware is supported on Windows, and is covered by the Bluetooth check on Mac OSX
|
|
|
49564c8b
|
2020-03-02T10:47:48
|
|
Added support for the PDP Victrix Pro FS with Touch Pad for PS4
|
|
|
4572dd2a
|
2020-03-02T10:37:28
|
|
Fixed bug 4854 - Add a way to extend the values in controller_type.h
Added a hint SDL_HINT_GAMECONTROLLERTYPE to allow overriding the built-in controller type database
|
|
|
27f346a0
|
2020-03-02T09:46:37
|
|
Fixed compile warning
|
|
|
339612d5
|
2020-03-02T09:35:12
|
|
ControllerList: add support for Victrix Pro FS w/ Touchpad for PS4
|
|
|
52be6633
|
2020-03-02T09:35:09
|
|
Use SDL math functions in Steam Controller support
|
|
|
756d2073
|
2020-03-02T09:26:12
|
|
Updated the HIDAPI Xbox One driver with support for Bluetooth Xbox One controllers
|
|
|
997f3e9e
|
2020-03-02T09:03:55
|
|
Fixed build warnings
|
|
|
11a84e4f
|
2020-03-01T18:16:15
|
|
Make sure hidapi is built for the release DMG
|
|
|
bebc4867
|
2020-03-01T17:53:30
|
|
We already have a hidapi implementation for Windows, we don't need libusb
|
|
|
74ed2156
|
2020-03-01T14:58:16
|
|
Updated version to 2.0.12 for release candidate build
|
|
|
6590d078
|
2020-03-01T14:52:49
|
|
Fixed bug 4996 - Mac: XBoxOne Bluetooth rumble isn't working
rofferom
I have an annoying issue on MacOS about XBoxOne Bluetooth rumble (Vendor: 0x045e, Product: 0x02fd).
When 360controller is installed, rumble is working correctly. However, Bluetooth rumble isn't working at all, with or without 360controller installed (although it is working with Chrome + https://html5gamepad.com).
I looked at the code, and it seems that XBox controllers are managed in MacOS in this file: SDL_hidapi_xbox360.c. The XBoxOne file is disabled for MacOS in SDL_hidjoystick_c.h.
The function HIDAPI_DriverXbox360_Rumble() is called correctly, and hid_write() returns no error.
I have tried a stupid test. I took the rumble packet from 360controller: https://github.com/360Controller/360Controller/blob/ec4e88eb2d2535e9b32561c702f42fb22b0a7f99/XBOBTFF/FFDriver.cpp#L620. With the patch I have attached, I manage to have rumble working on Bluetooth (with some stupid vibration level, but it proves it can if the packet is changed).
But it breaks the USB rumble with 360controller. A comment in the function makes an explicit reference to 360controller, I think that's why I have broken this specific usecase.
I don't know what is the correct way to fix this, but it seems that the current implementation has a missing case for Bluetooth support.
Note that I also tested master this morning, and I have another issue:
if (!device->ffservice) {
return SDL_Unsupported();
}
test fails in DARWIN_JoystickRumble(). This test has been done quickly, I'm not totaly confident about its accuracy.
|
|
53462163
|
2020-03-01T13:01:53
|
|
mac: Fix gamepad detection
|
|
|
51e9e984
|
2020-03-01T13:00:50
|
|
Fixed whitespace
|
|
|
8a6f1aa5
|
2020-03-01T12:58:50
|
|
Fixed bug 4369 - Going fullscreen with green knob in MacOS freezes app for 15 seconds.
Elmar
creating a fullscreen window with SDL_CreateWindow(..SDL_WINDOW_FULLSCREEN_DESKTOP..) in MacOS works fine, except if it was triggered by the user with the green knob in the top left window title bar.
Then "something" is different, and SDL_CreateWindow hangs for 15-20 seconds (tested in MacOS 10.13 and 10.14).
Responsible for the hang is this code in SDL_cocoawindow.m - Cocoa_SetWindowFullscreenSpace:
const int maxattempts = 3;
int attempt = 0;
while (++attempt <= maxattempts) {
/* Wait for the transition to complete, so application changes
take effect properly (e.g. setting the window size, etc.)
*/
const int limit = 10000;
int count = 0;
while ([data->listener isInFullscreenSpaceTransition]) {
if ( ++count == limit ) {
/* Uh oh, transition isn't completing. Should we assert? */
break;
}
SDL_Delay(1);
SDL_PumpEvents();
}
if ([data->listener isInFullscreenSpace] == (state ? YES : NO))
break;
/* Try again, the last attempt was interrupted by user gestures */
if (![data->listener setFullscreenSpace:(state ? YES : NO)])
break; /* ??? */
}
One trivial workaround is to change 'const int limit = 10000' to 500. Then the freeze is so short that it doesn't look like a freeze to the user.
Looking further into the problem, I observed that the function Cocoa_SetWindowFullscreenSpace recursively calls itself via some ObjectiveC messages. I managed to extract a callstack for this (copied below): Note how Cocoa_SetWindowFullscreenSpace in stack line 22 calls SDL_PumpEvents, which eventually arrives at SDL_SendWindowEvent, which calls SDL_UpdateFullscreenMode (stack line 0), which then calls Cocoa_SetWindowFullscreenSpace again (not shown). This recursive second call is the one that hangs.
Another "solution" that worked for me was to add a flag to SDL_Window that is set in Cocoa_SetWindowFullscreenSpace and causes this function to return immediately if called from itself.
Obviously, this is also an ugly hack, but I don't have enough time to dive into this crazy Cocoa/ObjectiveC business deep enough to find a proper solution. But hopefully it's easy for one of the experts around.
Note that there is a "failure to go fullscreen"-message involved, maybe using the green knob causes this failure at first.
I can unfortunately not provide a minimum example.
Best regards,
Elmar
0 com.yasara.View 0x00000001007495af SDL_UpdateFullscreenMode + 207
1 com.yasara.View 0x00000001006e2591 SDL_SendWindowEvent + 401
2 com.yasara.View 0x0000000100775a72 -[Cocoa_WindowListener windowDidResize:] + 370
3 com.yasara.View 0x0000000100776550 -[Cocoa_WindowListener windowDidExitFullScreen:] + 512
4 com.apple.AppKit 0x00007fff3180a2a4 -[_NSWindowEnterFullScreenTransitionController failedToEnterFullScreen] + 692
5 com.apple.AppKit 0x00007fff31c59737 -[_NSEnterFullScreenTransitionController _doFailedToEnterFullScreen] + 349
6 com.apple.AppKit 0x00007fff3172aa53 __NSFullScreenDockConnectionSendEnterForSpace_block_invoke + 135
7 libxpc.dylib 0x00007fff6114b9b1 _xpc_connection_reply_callout + 36
8 libxpc.dylib 0x00007fff6114b938 _xpc_connection_call_reply_async + 82
9 libdispatch.dylib 0x00007fff60ec7e39 _dispatch_client_callout3 + 8
10 libdispatch.dylib 0x00007fff60ede3b0 _dispatch_mach_msg_async_reply_invoke + 322
11 libdispatch.dylib 0x00007fff60ed2e25 _dispatch_main_queue_callback_4CF + 807
12 com.apple.CoreFoundation 0x00007fff33d39e8b __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
13 com.apple.CoreFoundation 0x00007fff33d3959a __CFRunLoopRun + 2335
14 com.apple.CoreFoundation 0x00007fff33d38a28 CFRunLoopRunSpecific + 463
15 com.apple.HIToolbox 0x00007fff32fd1b35 RunCurrentEventLoopInMode + 293
16 com.apple.HIToolbox 0x00007fff32fd1774 ReceiveNextEventCommon + 371
17 com.apple.HIToolbox 0x00007fff32fd15e8 _BlockUntilNextEventMatchingListInModeWithFilter + 64
18 com.apple.AppKit 0x00007fff3128deb7 _DPSNextEvent + 997
19 com.apple.AppKit 0x00007fff3128cc56 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362
20 com.yasara.View 0x000000010076fab2 Cocoa_PumpEvents + 290
21 com.yasara.View 0x00000001006dd1c7 SDL_PumpEvents_REAL + 23
22 com.yasara.View 0x00000001007795cf Cocoa_SetWindowFullscreenSpace + 223
23 com.yasara.View 0x000000010074970b SDL_UpdateFullscreenMode + 555
24 com.yasara.View 0x00000001006e2476 SDL_SendWindowEvent + 118
25 com.yasara.View 0x0000000100774ff7 -[Cocoa_WindowListener resumeVisibleObservation] + 135
26 com.yasara.View 0x000000010077664c Cocoa_ShowWindow + 188
27 com.yasara.View 0x0000000100749492 SDL_FinishWindowCreation + 546
28 com.yasara.View 0x0000000100748da5 SDL_CreateWindow_REAL + 1573
29 com.yasara.View 0x000000010010d9b1 vga_setvideomode + 1347
30 com.yasara.View 0x00000001003f0d46 mod_initscreen + 2614
31 com.yasara.View 0x00000001003f344b mod_reinitscreen + 460
32 com.yasara.View 0x00000001003f370d mod_resizescreen + 383
33 com.yasara.View 0x0000000100418e39 mod_main + 815
34 com.yasara.View 0x000000010029ca5d main2 + 5766
35 com.yasara.View 0x000000010011d1b7 main.main_cpuok + 19
|
|
|
bd5da73a
|
2020-03-01T12:50:42
|
|
Fixed bug 4992 - UWP/WinRT does not set thread priority when using SDL_SetThreadPriority
Ethan Lee
Attached is a diff that I used to get SetThreadPriority working locally. I still have no idea what the minimum SDK version is since Microsoft never documented it, but it's worth pointing out that they're much more aggressive about using the latest VS and UWP SDK anyway (for example, an updated Xbox is no longer compatible with VS2017, and updates are required to have a network connection of any kind).
|
|
|
1af31a26
|
2020-02-27T13:53:32
|
|
Fixed trying to handle the HORI Wireless Switch Pad when connected via USB
|
|
|
20d67446
|
2020-02-27T09:33:32
|
|
Xbox One controller rumble doesn't need synchronization if you use a packet counter of 0
|
|
|
2cd88ddf
|
2020-02-27T09:32:03
|
|
Temporarily disabled NEON optimizations added for bug 4365
The ABGR to ARGB blit results in an empty surface, this needs to be looked at.
|
|
|
9013c916
|
2020-02-27T08:20:34
|
|
Fixed bug 5005 - warnings in kmsdrm
Malte Kie?ling
At the moment i get following warnings from kmsdrm:
* in SDL_kmsdrmvideo.c KMSDRM_DestroySurfaces is return type int, but thats never returned or checked against
* in SDL_kmsdrmvideo.c KMSDRM_DestroySurfaces the variable viddata is not used
* in SDL_kmsdrmopengles.c KMSDRM_GLES_LoadLibrary a cast to NativeDisplayType is missing
I attached a patch for them :)
|
|
|
7f26ff23
|
2020-02-27T08:18:20
|
|
Fixed bug 4987 - Can't build on MinGW a recent state (15'th February, 2020): conflicting types
|
|
cbd1a2f7
|
2020-02-25T14:52:03
|
|
cmake: Forgot to add this file to revision control.
Fixes Bugzilla #5003.
|
|
21a2e0c7
|
2020-02-25T06:53:51
|
|
Fix compilation C90 mixed declarations and code (Thanks Cameron Gutman !)
|
|
|
e2b132ca
|
2020-02-24T21:57:03
|
|
Better fix to set the palette opaque, when there is also a colorkey
(see bug 3827)
|
|
|
e3b0713e
|
2020-02-24T12:07:18
|
|
Don't call setPreferredOutputNumberOfChannels on iOS, it breaks audio output
|
|
|
2c9871a4
|
2020-02-24T10:25:57
|
|
Fixed surround sound support on Apple TV
|
|
|
f4857660
|
2020-02-23T23:07:15
|
|
Fix: set to opaque when a palette surface is converted to an alpha format.
|
|
|
bf8aa1ed
|
2020-02-23T22:38:08
|
|
Fix regression: when a palette + colorkey is converted, it needs a blend mode.
- Regression of test_1.c of bug 3827, after fix from bug 4798.
- Blending is also needed when the palette contains alpha value, but not necessarily colorkey.
- Clean up SDL_ConvertColorkeyToAlpha which doesn't seem to need 'ignore_alpha' parameter any-more.
(see bug 3827)
|
|
|
094655cf
|
2020-02-23T14:49:03
|
|
cocoa: Make sure wait for button enable can't be infinite.
|
|
|
72316518
|
2020-02-23T14:48:48
|
|
cocoa: Removed a debug printf that was accidentally committed.
|
|
|
9a7c2b22
|
2020-02-23T09:59:52
|
|
Fixed bug 4999 - Palette surface always promoted to alpha (Thanks Cameron Gutman!)
MSVC Static analysis: Incorrect alpha_value check in SDL_render.c
(see also bug 4425)
|
|
|
dd1d8ab6
|
2020-02-21T15:52:35
|
|
cmake: more proper sdl2-config.cmake work (thanks, Alexander!)
Fixes Bugzilla #4970.
|
|
|
be4d488e
|
2020-02-21T15:51:04
|
|
cmake: Backed out changeset 9009d85d3762
This is being replaced by a different patch (see Bugzilla #4970).
|
|
|
4d9e6e5f
|
2020-02-21T14:50:09
|
|
cocoa: When exiting a fullscreen space, wait for window state to normalize.
A good metric of this is when the titlebar's "minimize" button is reenabled,
which doesn't happen by the time windowDidExitFullscreen triggers.
This fixes minimizing a fullscreen window on macOS.
Fixes Bugzilla #4177.
|
|
|
8d146363
|
2020-02-19T08:26:00
|
|
Fixed support for third party Xbox 360 wireless controller dongle
|
|
|
44698c49
|
2020-02-18T01:44:07
|
|
dynapi: Fixed build on non-Android platforms.
|
|
|
ad225047
|
2020-02-17T14:15:47
|
|
Added Android SDK conditionals to game controller mappings
The Nintendo Switch Pro controller has a different mapping on Android 10 and newer
|
|
|
d7ece7ee
|
2020-02-17T13:54:45
|
|
Made SDL_GetAndroidSDKVersion() available for applications
|
|
|
93b26f17
|
2020-02-17T16:15:04
|
|
opengl: Backed out hg changeset 94f9f40a957f
This is the OpenGL line drawing fix for Bugzilla #3182, but there's some
disagreement about what the renderers should do here, so I'm backing this out
until after 2.0.12 ships, and then we'll reevaluate all the renderer backends
to decide what's correct, and make them all work the same.
|
|
|
1b82606e
|
2020-02-17T16:11:18
|
|
x11: Wait a bit in SDL_SetWindowSize() to see if window manager vetoed change.
Same idea as the fix for Bugzilla #4646.
Fixes Bugzilla #4727.
|
|
|
e7315225
|
2020-02-17T15:02:37
|
|
x11: Don't delay an extra 10ms if we were just going to break out of the loop.
|
|
|
367a8b97
|
2020-02-17T15:00:02
|
|
x11: Don't wait for the window to move if it's already in the place we want it.
|
|
|
1d624aa5
|
2020-02-16T00:08:36
|
|
Further improvements for bug 4128 - CMAKE: Generated target import file contains incorrect include path
Mohamed
It would be useful to be able to do either `#include "SDL2/SDL.h"` or `#include "SDL.h"`. This patch allows that and adds compatibility with other build systems. It also allows differentiating between SDL1 and SDL2.
|
|
|
4a9dbfef
|
2020-02-15T16:39:38
|
|
Fixed bug 4987 - Can't build on MinGW a recent state: conflicting types
Vitaly Novichkov
Recent attempt to build a recent HG state of SDL2 via AppVeyor gives the failure:
https://ci.appveyor.com/project/Wohlstand/sdl-mixer-x/builds/30821858/job/359gqvypi2f18nok
```
C:\projects\sdl-mixer-x\build-MinGW-w32-MinSizeRel-Win32-VB6-Binding\external\AudioCodecs\src\AudioCodecs-build\external\SDL2\src\SDL2HG\src\dynapi\SDL_dynapi_procs.h:56:29: error: conflicting types for 'SDL_CreateThread'
SDL_DYNAPI_PROC(SDL_Thread*,SDL_CreateThread,(SDL_ThreadFunction a, const char *b, void *c),(a,b,c),return)
|
|
|
dc54add5
|
2020-02-14T18:21:58
|
|
Added some extra permissions and features likely to be used by SDL applications
|
|
|
35704c98
|
2020-02-14T16:17:17
|
|
Fixed bug 4980 - Build fails for SDL_kmsdrm*.c
Malte Kie?ling
Since https://hg.libsdl.org/SDL/rev/f908bd722523 / bug 4966 i cannot build SDL anymore. The error i get is, essentially, caused by -Werror=declaration-after-statement in SDL_kmsdrmvideo.c and SDL_kmsdrmopengles.c
|
|
|
715f8d42
|
2020-02-14T16:15:46
|
|
Fixed bug 4986 - Memory leak in HIDAPI_JoystickConnected
meyraud705
Memory allocated for device->joysticks on line 589 of SDL_hidapijoystick.c is never freed.
Also, use memmove because memory is overlapping.
|
|
|
f4e23553
|
2020-02-14T15:19:34
|
|
Fixed audio not coming out of the phone speakers while recording on iOS
|
|
|
922b3dc3
|
2020-02-14T14:18:12
|
|
Fixed re-setting the audio session category when closing an audio device
|
|
|
229c2f8f
|
2020-02-14T13:37:32
|
|
cmake: Add PACKAGE_VERSION and SDL2_VERSION to sdl2-config.cmake.in
Fixes Bugzilla #4970.
|
|
|
d1df3437
|
2020-02-14T13:17:18
|
|
x11: SDL_SetWindowPosition should try to wait for the window manager.
Wait up to 100 milliseconds, since the window manager might alter or
outright veto the window change...or not respond at all.
In a well-functioning system, though, this should help make sure
that SDL_SetWindowPosition's results match reality.
Fixes Bugzilla #4646.
|
|
|
7ad77bcc
|
2020-02-14T01:08:21
|
|
wayland: Don't force the window into OpenGL mode if we want Vulkan.
|
|
|
a77a890d
|
2020-02-14T00:58:36
|
|
wayland: Don't delay pending surface resize handling on Vulkan.
OpenGL apparently needs to not do any drawing between wl_egl_window_resize
and eglSwapBuffers, but Vulkan apps don't use SDL to present, so they
never call into an equivalent of SDL_GL_SwapWindow where our Wayland code
was handling pending resize work.
Fixes Bugzilla #4722.
|
|
|
14bf532d
|
2020-02-13T16:10:52
|
|
Fixed opening audio on Android from the Steam Link shell activity
|
|
033aa51d
|
2020-02-13T22:58:04
|
|
testfilesystem: Don't exit the application if SDL_GetBasePath isn't supported
|
|
|
8f1a916a
|
2020-02-13T20:50:47
|
|
Add basic support for compiling on RISC OS
|
|
|
b4312864
|
2020-02-13T10:19:05
|
|
Resolved conflict and added Android_JNI_RequestPermission()
|
|
|
e261bd42
|
2020-02-12T12:26:27
|
|
Improved fix for bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work
|
|
|
afb70f26
|
2020-02-12T13:09:38
|
|
test: Reimplemented SDLTest_CommonUsage() to restore binary compatibility.
Fixes Bugzilla #4975.
|
|
|
0a6d80ab
|
2020-02-12T13:08:29
|
|
mac: Wait a bit before activating app at startup.
This is obnoxious and wrong, but the patch that activates the Dock before
activating the app fixes the _menu_ not responding on Catalina, but the
first window created by the app won't have keyboard focus without a small
delay inserted.
This obviously needs a better solution, but it gets it limping along correctly
for now.
|
|
|
6fe6946a
|
2020-02-11T21:19:05
|
|
Fixed relative mode mouse events stopping if you click on the title bar
|
|
|
6ec14b7f
|
2020-02-11T16:23:43
|
|
Fixed iOS and Android build
|
|
|
4bb95e84
|
2020-02-11T16:14:02
|
|
Implemented OpenSL-ES audio recording on Android
|
|
|
fe8ce66b
|
2020-02-11T10:35:14
|
|
Attempt to make version detection safe for Mac OS X < 10.10
|
|
|
52b410ab
|
2020-02-11T10:21:31
|
|
Workaround for bug 4822 - Broken visual output in full screen mode with OS X 10.15
sjordan
We did some investigations into a different direction which I would like to share. As mentioned previously the scaling setting in the preferences play an important role for our problem and they also hint towards an issue with point/pixel scaling factors.
We found an interesting correlation between our fail case and the behavior of [nsWindow.screen backingScaleFactor]. It turns out that whenever we encounter the fail case the scale factor is zero when we print it quickly after calling SDL_CreateWindow. After some time the value changes to a non-zero value. In the success case the scaling factor is nonzero 'immediately'. Note that we don't use that factor. We also find that the window backingScaleFactor does not show the strange behavior even in the fail case.
We have also attempted to find out whether any event triggers the transition from zero to non-zero. We found the transition happening when we call SDL_PollEvent. We can even force this to happen by explicitly adding a SDL_PollEvent at an early stage, but it will only happen if a certain amount of time elapsed, so we need to add some sleep before the call to trigger the transition at an earlier stage. All that seems to imply that the transition happens async and that SDL_PollEvent merely causes the system to update its internal state at that time.
We have also verified that the scaling setting in the preferences does NOT directly correlate to the scaling factor behavior. We find that a particular scaling setting can lead to a fail case for one resolution and a success case for another resolution. This shows that the scaling setting alone does not determine whether the problem will appear or not.
We have also verified on another Mac with 10.14 that the scaling factor is always non-zero and we always have the success case.
I have no idea how to interpret this initial-zero behavior and haven't found any usable information on the screen backing scale factor. It seems as 10.15 does some stuff more async than before and maybe the problem could be caused by unfortunate timings. I would be very interested to hear your opinion about that.
...
Finally we found the cause of all our problems: it's the origin hack in Cocoa_SetWindowFullscreen:
/* Hack to fix origin on Mac OS X 10.4 */
NSRect screenRect = [[nswindow screen] frame];
if (screenRect.size.height >= 1.0f) {
rect.origin.y += (screenRect.size.height - rect.size.height);
}
If we comment this one out our game and testdraw2 do behave correctly.
It turns out that if a window is not fully contained in the screen, it's screen property becomes zero and therefore we saw a zero when printing the backing scale factor (although it's not clear why it became nonzero later).
We suggest to add a runtime check which skips this code for 10.15 (or possibly earlier if you happen to know that the hack is not needed for certain older versions).
More info: consider the line
NSRect screenRect = [[nswindow screen] frame];
in Cocoa_SetWindowFullscreen. We found that this rect has the dimensions of the desktop
on our OS X 10.15 setup. This is true both for the success case and the fail case. It seems as the success case is actually a fail case in disguise.
On the other Mac with OS X 10.14 the same rect has the dimension of the newly created screen. This is what I would expect, because at that time the window has already been created successfully and there should be a newly created screen associated to the window.
What are the cases in which the whole origin conversion code for the fullscreen case is supposed to have a non-trivial result?
Today we found that if we print the dimensions of [nswindow screen] later, then we find them to be correct. So the conclusion seems to be that OS X 10.15 does indeed do the window/screen setup more async than before and that the origin correction code uses the [nswindow screen] at a time where the window/screen setup isn't finalized yet.
|
|
|
c31727c7
|
2020-02-11T10:08:22
|
|
Fixed bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work
The problem here was calling ClipCursor() continuously in a tight loop. Fixed by only calling ClipCursor() if the clip area needs to be updated.
|
|
|
668276fe
|
2020-02-11T09:41:55
|
|
Don't add a frame to borderless windows.
It was done to allow hotkey resizing of borderless windows, but Windows will sometimes draw it, regardless of our WM_* message handling. See bug 4466 for more details.
|
|
|
f867cebb
|
2020-02-11T08:36:13
|
|
Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys
Alex Denisov
When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events.
Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++:
WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1
Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly.
With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes).
|
|
|
232b7fee
|
2020-02-11T08:26:46
|
|
Make it possible for the application to use different C runtime begin/end thread functions
|