This avoids the need to malloc something extra, use a semaphore, etc, and
fixes Emscripten with pthreads support, which might not spin up a web worker
until after SDL_CreateThread returns and thus can't wait on a semaphore at
this point in any case.
Fixes Bugzilla #5064.
Build is broken without EGL since version 2.0.12 and
https://hg.libsdl.org/SDL/rev/72cc4740dec2:
/home/giuliobenetti/autobuild/run/instance-1/output-1/build/sdl2-2.0.12/src/video/kmsdrm/SDL_kmsdrmvideo.c: In function 'KMSDRM_CreateSurfaces':
/home/giuliobenetti/autobuild/run/instance-1/output-1/build/sdl2-2.0.12/src/video/kmsdrm/SDL_kmsdrmvideo.c:394:5: error: unknown type name 'EGLContext'
EGLContext egl_context;
^
Fixes:
- http://autobuild.buildroot.org/results/fafd20a01591032662f9ca025fcea3478239cf3c
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Build with directfb is broken due to a spurious '}' and a missing 'E'
since version 2.0.12 and https://hg.libsdl.org/SDL/rev/4c2dcf490cba:
/home/buildroot/autobuild/run/instance-2/output-1/build/sdl2-2.0.12/src/video/directfb/SDL_DirectFB_render.c: In function 'SetBlendMode':
/home/buildroot/autobuild/run/instance-2/output-1/build/sdl2-2.0.12/src/video/directfb/SDL_DirectFB_render.c:202:9: error: case label not within a switch statement
202 | case SDL_BLENDMODE_MUL:
| ^~~~
/home/buildroot/autobuild/run/instance-2/output-1/build/sdl2-2.0.12/src/video/directfb/SDL_DirectFB_render.c:205:67: error: 'DSBF_DSTCOLOR' undeclared (first use in this function); did you mean 'DSBF_DESTCOLOR'?
205 | SDL_DFB_CHECK(destsurf->SetSrcBlendFunction(destsurf, DSBF_DSTCOLOR));
| ^~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/83ccefee68c2800c0544e6f40fa8bc8ee6b67b77
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Andrei Kortunov
Hello. I try to implement an application for Android, which uses a new sensors API from 2.0.9 to control a camera rotation via built-in gyroscope, using the code from the test/testsensor.c as an example.
Gyroscope input itself works well, but an interval between SDL_SENSORUPDATE events is about 200ms (the SENSOR_DELAY_NORMAL, I believe), when I need the interval about 20-40ms (the SENSOR_DELAY_GAME or SENSOR_DELAY_FASTEST).
If a driver's implementation of CreateWindowFramebuffer sets the window
surface, use that rather than overwriting it. A driver may set the window
surface if data cannot be passed via the CreateWindowFramebuffer output
parameters (e.g. surface palette colors).
Otherwise our cached state goes out of sync when updating a texture. Since
these state changes aren't necessary, they were removed instead of updating
the cached state.
Fixes Bugzilla #4998.
bluenaxela+sdl
I've noticed that the Switch Pro Controller hidapi driver does not report battery levels when connected via Bluetooth, despite having code for setting joystick->epowerlevel.
This is caused by the driver always using k_eSwitchInputReportIDs_SimpleControllerState via Bluetooth. Using that mode means that the state reports you get back from the controller do not include battery state. Not using the full controller state over Bluetooth effectively makes this driver's support for setting joystick->epowerlevel entirely pointless, only ever reporting SDL_JOYSTICK_POWER_WIRED.
Is there a reason this was set to only use SimpleControllerState via Bluetooth?
I've attached a patch I'm using to allow getting battery level for the Switch Pro Controller.
A couple notes about this patch:
1) It changes LoadStickCalibration to accept the input_mode that is selected, because that's really what should determine what is used for stick extents, since stick extents differ between the modes.
2) In my patch I only use FullControllerState when the vid/pid matches the official Switch Pro Controller, as a cautionary measure in case some third-party controllers have problems with FullControllerState mode via Bluetooth (I noticed a HORI Wireless Switch Pad I had seemed to not read controller calibration correctly for stick extents. Maybe it's calibration data was uninitialized on account of having never been used with a Switch? I'm unsure, though if that guess is right maybe SDL2 should be detecting an uninitiated calibration state and using some sensible defaults)
There are a number of poorly behaved HID devices that time out on attempts to
read various strings. Rather than end up on an endless treadmill of blacklisting
broken devices, reduce our risk by only querying devices that are gamepads.
SDL_hidapijoystick.c already checks these same usages, so we shouldn't
exclude any working HID devices (caveat below).
This also makes HidP_GetPreparsedData() and HidP_GetCaps() failure skip
the device entirely, but that seems desired. If a device can't even return basic
top-level collection data properly, we want nothing to do with that broken device.
If we do find devices that work with HIDAPI joystick and fail these calls, we can
add an exception via VID+PID matching.
bluenaxela+sdl
The HORI Wireless Switch Pad does not properly connect via bluetooth. I did some debugging and found that the code that tries to control the Home LED causes this controller to disconnect.
This results in a dlsym() call, which causes Emscripten to panic if the game
wasn't explicitly built dlopen support. eglGetProcAddress works just fine on
this platform, so just let that codepath handle it.
This is a multi-part fix, and is the 2nd attempt at a fix for Bug 5034. Here
are the problems being addressed:
1. On macOS 10.14.x and earlier, trying to call IOHIDDeviceUnscheduleFromRunLoop
without a prior, paired call to IOHIDDeviceScheduleWithRunLoop, appears to
lead to a crash. A per-device flag has been added to make sure that these
calls are paired.
2. DARWIN_JoystickDetect was free'ing its SDL_joystick's hwdata field
(via FreeDevice) without setting it to NULL, and DARWIN_JoystickRumble wasn't
checking for a NULL hwdata. FreeDevice will now set hwdata to NULL and
DARWIN_JoystickRumble will check for a NULL hwdata.
meyraud705
Added Linux implementation, otherwise you get "Unsupported direction type" error.
Added documentation to explain why one would use SDL_HAPTIC_FIRST_AXIS.
Mathieu Laurendeau
Consider a device supporting effects on multiple axes.
There's currently no way to play effects against a single-axis direction.
A device supporting effects against X and Y may not allow to play effects with a two-axis direction coordinate, even if one of the coordinates is null.
My current (ugly) work around for this is to add a direction type SDL_HAPTIC_X_FORCE to play effects against a X-axis only direction (patch attached).
This issue impacted two GIMX users using the following wheels:
- Leo Bodnar SimSteering force feedback wheel
- Accuforce direct drive wheel
Playing constant/spring/damper effects against a X-axis direction worked well for the first wheel, but not for the second one.
A better strategy seems to play the effects against the first axis reported by the DirectInput enumeration.
This strategy also works with Logitech wheels (at least the DFGT).
It's been more than a year that I have the latest patch (playing effects against the first axis only) in the GIMX software. It's being used by thousands of people, mostly for adapting their FFB wheel to the PS4. I had no report that proves this strategy to be wrong.
Jimb Esser
Add new RawInput controller API, and improved correlation with XInput/WGI
Reorder joystick init so drivers can ask the others if they handle a device reliably
Do not poll disconnected XInput devices (major perf issue)
Fix various cases where incorrect correlation could happen
Simple mechanism for propagating unhandled Guide button presses even before guaranteed correlation
Correlate by axis motion as well as button presses
Fix failing to zero other trigger
Fix SDL_HINT_JOYSTICK_HIDAPI not working if set before calling SDL_Init()
Add missing device to device names
Disable RawInput if we have a mismatch of XInput-capable but not RawInput-capable devices
Updated to SDL 2.0.13 code with the following notes:
New HID driver: xbox360w - no idea what that is, hopefully urelated
SDL_hidapijoystick.c had been refactored to couple data handling logic with device opening logic and device lists caused some problems, yields slightly uglier integration than previously when the 360 HID device driver was just handling the data.
SDL_hidapijoystick.c now often pulls the device off of the joystick_hwdata structure for some rumble logic, but it appears that code path is never reached, so probably not a problem.
Looks like joystick_hwdata was refactored to not include a mutex in other drivers, maintainers may want to do the same refactor here if that's useful for some reason.
Something changed in how devices get names, so getting generic names.
Had to fix a (new?) bug where removing an XInput controller caused existing controllers (that moved to a new XInput index) to get identified as 0x045e/0x02fd ("it's probably Bluetooth" in code), rendering the existing HIDAPI_IsDevicePresent and new RAWINPUT_IsDevicePresent unreliable.
Jimb Esser
Add new RawInput controller API, and improved correlation with XInput/WGI
Reorder joystick init so drivers can ask the others if they handle a device reliably
Do not poll disconnected XInput devices (major perf issue)
Fix various cases where incorrect correlation could happen
Simple mechanism for propagating unhandled Guide button presses even before guaranteed correlation
Correlate by axis motion as well as button presses
Fix failing to zero other trigger
Fix SDL_HINT_JOYSTICK_HIDAPI not working if set before calling SDL_Init()
Add missing device to device names
Disable RawInput if we have a mismatch of XInput-capable but not RawInput-capable devices
Updated to SDL 2.0.13 code with the following notes:
New HID driver: xbox360w - no idea what that is, hopefully urelated
SDL_hidapijoystick.c had been refactored to couple data handling logic with device opening logic and device lists caused some problems, yields slightly uglier integration than previously when the 360 HID device driver was just handling the data.
SDL_hidapijoystick.c now often pulls the device off of the joystick_hwdata structure for some rumble logic, but it appears that code path is never reached, so probably not a problem.
Looks like joystick_hwdata was refactored to not include a mutex in other drivers, maintainers may want to do the same refactor here if that's useful for some reason.
Something changed in how devices get names, so getting generic names.
Had to fix a (new?) bug where removing an XInput controller caused existing controllers (that moved to a new XInput index) to get identified as 0x045e/0x02fd ("it's probably Bluetooth" in code), rendering the existing HIDAPI_IsDevicePresent and new RAWINPUT_IsDevicePresent unreliable.
Malte Kie?ling
I get a build error in SDL_sysjoystick.c:74 for the merged patch, but its nothing to sweat about, just -Werror=declaration-after-statement doing its usual stuff.
David Ludwig
I have created a new driver for SDL's Joystick and Game-Controller subsystem: a Virtual driver. This driver allows one to create a software-based joystick, which to SDL applications will look and react like a real joystick, but whose state can be set programmatically. A primary use case for this is to help enable developers to add touch-screen joysticks to their apps.
The driver comes with a set of new, public APIs, with functions to attach and detach joysticks, set virtual-joystick state, and to determine if a joystick is a virtual-one.
Use of virtual joysticks goes as such:
1. Attach one or more virtual joysticks by calling SDL_JoystickAttachVirtual. If successful, this returns the virtual-device's joystick-index.
2. Open the virtual joysticks (using indicies returned by SDL_JoystickAttachVirtual).
3. Call any of the SDL_JoystickSetVirtual* functions when joystick-state changes. Please note that virtual-joystick state will only get applied on the next call to SDL_JoystickUpdate, or when pumping or polling for SDL events (via SDL_PumpEvents or SDL_PollEvent).
Here is a listing of the new, public APIs, at present and subject to change:
------------------------------------------------------------
/**
* Attaches a new virtual joystick.
* Returns the joystick's device index, or -1 if an error occurred.
*/
extern DECLSPEC int SDLCALL SDL_JoystickAttachVirtual(SDL_JoystickType type, int naxes, int nballs, int nbuttons, int nhats);
/**
* Detaches a virtual joystick
* Returns 0 on success, or -1 if an error occurred.
*/
extern DECLSPEC int SDLCALL SDL_JoystickDetachVirtual(int device_index);
/**
* Indicates whether or not a virtual-joystick is at a given device index.
*/
extern DECLSPEC SDL_bool SDLCALL SDL_JoystickIsVirtual(int device_index);
/**
* Set values on an opened, virtual-joystick's controls.
* Returns 0 on success, -1 on error.
*/
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualAxis(SDL_Joystick * joystick, int axis, Sint16 value);
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualBall(SDL_Joystick * joystick, int ball, Sint16 xrel, Sint16 yrel);
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualButton(SDL_Joystick * joystick, int button, Uint8 value);
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualHat(SDL_Joystick * joystick, int hat, Uint8 value);
------------------------------------------------------------
Miscellaneous notes on the initial patch, which are also subject to change:
1. no test code is present in SDL, yet. This should, perhaps, change. Initial development was done with an ImGui-based app, which potentially is too thick for use in SDL-official. If tests are to be added, what kind of tests? Automated? Graphical?
2. virtual game controllers can be created by calling SDL_JoystickAttachVirtual with a joystick-type of SDL_JOYSTICK_TYPE_GAME_CONTROLLER, with naxes (num axes) set to SDL_CONTROLLER_AXIS_MAX, and with nbuttons (num buttons) set to SDL_CONTROLLER_BUTTON_MAX. When updating their state, values of type SDL_GameControllerAxis or SDL_GameControllerButton can be casted to an int and used for the control-index (in calls to SDL_JoystickSetVirtual* functions).
3. virtual joysticks' guids are mostly all-zeros with the exception of the last two bytes, the first of which is a 'v', to indicate that the guid is a virtual one, and the second of which is a SDL_JoystickType that has been converted into a Uint8.
4. virtual joysticks are ONLY turned into virtual game-controllers if and when their joystick-type is set to SDL_JOYSTICK_TYPE_GAMECONTROLLER. This is controlled by having SDL's default list of game-controllers have a single entry for a virtual game controller (of guid, "00000000000000000000000000007601", which is subject to the guid-encoding described above).
5. regarding having to call SDL_JoystickUpdate, either directly or indirectly via SDL_PumpEvents or SDL_PollEvents, before new virtual-joystick state becomes active (as specified via SDL_JoystickSetVirtual* function-calls), this was done to match behavior found in SDL's other joystick drivers, almost all of which will only update SDL-state during SDL_JoystickUpdate.
6. the initial patch is based off of SDL 2.0.12
7. the virtual joystick subsystem is disabled by default. It should be possible to enable it by building with SDL_JOYSTICK_VIRTUAL=1
Questions, comments, suggestions, or bug reports very welcome!
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!
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.
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.
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.
Anthony Pesch
I was just communicating with one of the Retropie developers regarding this.
This change removed the forced window focus change on creation (3534cb3793) 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.
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.
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.
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.
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
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
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: ec4e88eb2d/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.
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
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).
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 :)
- 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)
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.
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.
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)
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
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.
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.
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.
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.
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.
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).
Add an include on SDL_error.h to avoid the following build failure
without threads:
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: build/.libs/SDL_threadprio.o: in function `SDL_LinuxSetThreadPriority_REAL':
SDL_threadprio.c:(.text+0x0): undefined reference to `SDL_Unsupported'
Fixes:
- http://autobuild.buildroot.org/results/7f7712c5bd47de4a3fcec1e0d0526fd5a3ecd532
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Likewise for the GLES1 and GLES2 renderers.
This solves the missing pixel at the end of a line and removes all the
heuristics for various platforms/drivers. It's possible we could still use
GL_LINE_STRIP with this and save some vertex buffer space, assuming this
doesn't upset some driver somewhere, but this seems to be a clean fix that
makes the GL renderers match the software renderer output.
Diamond-exit rule explanation:
http://graphics-software-engineer.blogspot.com/2012/04/rasterization-rules.html
Fixes Bugzilla #3182.
Anthony Pesch
* Remove triple buffering support. As far as I can tell, this goes against the libdrm API; the EGL implementations themselves control the buffering. Removing it isn't absolutely necessary as it seemingly works on the Pi at least, but I noticed this while doing my work and explained my reasoning in the commit.
* Replace the crtc_ready logic which allocates an extra bo to perform the initial CRTC configuration (which is required before calling drmModePageFlip) with a call to drmModeSetCrtc after the front and back buffers are allocated, avoiding this allocation.
* Standardized the SDL_*Data variable names and null checks to improve readability. Given that there were duplicate fields in each SDL_*Data structure, having generic names such as "data" at times was very confusing.
* Removed unused fields from the SDL_*Data structures and moves all display related fields out of SDL_VideoData and into SDL_DisplayData. Not required since the code only supports a single display right now, but this was helpful in reading and understanding the code initially.
* Implement KMSDRM_GetDisplayModes / KMSDRM_SetDisplayMode to provide dynamic modeset support.
These changes have been tested on a Raspberry Pi 4 and a Dell XPS laptop with an HD 520.
As an update, I went back over the triple buffer changes and left them in. I didn't entirely get the code originally, I had just seen it calling KMSDRM_gbm_surface_lock_front_buffer twice for a single swap and had removed it because I was paranoid of bugs stemming from it while working on the modeset changes.
I've made a few small changes to the logic that had thrown me off originally and rebased the changes:
* The condition wrapping the call to release buffer was incorrect.
* The first call to KMSDRM_gbm_surface_lock_front_buffer has been removed. I don't understand why it existed.
* Added additional comments describing what was going on in the code (as it does fix the buffer release pattern of the original code before it).
meyraud705
In SDL_hidapi_switch.c
line 443: Function BTrySetupUSB call WriteProprietary with pBuf=NULL and ucLen=0
line 376: WriteProprietary check its input (!pBuf && ucLen > 0) || ucLen > sizeof(packet.rgucProprietaryData): ucLen is 0 so it passes
line 382: WriteProprietary call memcpy with pBuf=NULL
meyraud705
Dualshock4 on bluetooth need 78 bytes for the rumble data while SDL_HIDAPI_RumbleRequest can only hold 64 bytes.
'volatile' is not meant for thread synchronization.
The list of rumble request could grow infinitely if user call SDL_JoystickRumble too much. The documentation says "Each call to this function cancels any previous rumble effect", so overwriting pending request seem like a good idea.
This fixes a crash whereby SDL could crash on macOS/Darwin, if and when a
USB game controller gets unplugged. SDL was not retaining a reference
to the controller's OS/IOKit-provided 'device object', and was capable
of trying to use it, after a device was hot-unplugged.
There is now a thread that handles all HIDAPI rumble requests and a lock that guarantees that we're not reading and writing the device at the same time.
The index and indices were swapped; Which is fine as long as there are
no gaps in the ABS_HAT* event availability but otherwise things do get confused.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Martin Fiedler
To be precise, this is about *desktop OpenGL* on X11. For OpenGL ES, EGL is already used (as it's the only way to get an OpenGL ES context), as Sylvain noted above.
To shine some light on why this is needed:
In 99% of all cases, using GLX on X11 is fine, even though it's effectively deprecated in favor of EGL [1]. However, there's at least one use case that *requires* the OpenGL context being created with EGL instead of GLX, and that's DRM_PRIME interoperability: The function glEGLImageTargetTexture2DOES simply doesn't work with GLX. (Currently, Mesa actually crashes when trying that.)
Some example code:
https://gist.github.com/kajott/d1b29c613be30893c855621edd1f212e
Runs on Intel and open-source AMD drivers just fine (others unconfirmed), but with #define USE_EGL 0 (i.e. forcing it to GLX), it crashes. The same happens when using SDL for window and context creation.
The good news is that most of the pieces for EGL support on X11 are already in place: SDL_egl.c is pretty complete (and used for desktop OpenGL on Wayland, for example), and SDL_x11opengl.c has the aforementioned OpenGL-ES-on-EGL support. However, when it comes to desktop OpenGL, it's hardcoded to fall back to GLX.
I'm not advocating to make EGL the default for desktop OpenGL on X11; don't fix what ain't broken. But something like an SDL_HINT_VIDEO_X11_FORCE_EGL would be very appreciated to make use cases like the above work with SDL.
[1] source: Eric Anholt, major Linux graphics stack developer, 7 years ago already - see last paragraph of https://www.phoronix.com/scan.php?page=news_item&px=MTE3MTI
Luis Caceres
The current handling of Wayland mouse pointer events only handles wl_pointer.axis events, which, according to the Wayland documentation, deal with mouse wheel scroll events on a continuous scale. While this is reasonable for some input sources (e.g. touchpad two-finger scrolling), it is not for mouse wheel clicks which generate wl_pointer.axis events with large deltas.
This patch adds handling for wl_pointer.axis_discrete and wl_pointer.frame events and prefers to report SDL_MouseWheelEvent in discrete units if they are available. This means that for mouse wheel scrolling we count in clicks, but for touchpad two-finger scrolling we still use whatever units Wayland uses. This behaviour is closer to that of the X11 backend.
Since these events are only available since version 5 of the wl_seat interface, this patch also checks for this and falls back to the previous behaviour if its not available. I also had to add definitions for some of the pointer and keyboard events specified in versions 2-5 but these are just stubs and do nothing.
Make sure the thread is actually paused, and context backep-up, before
SurfaceView is destroyed (eg surfaceDestroyed() actually returns).
Add a timeout when surfaceDestroyed() is called, and check 'backup_done' variable.
It prevents crashes like:
#00 pc 000000000000c0d0 /system/lib64/libutils.so (android::RefBase::incStrong(void const*) const+8)
#01 pc 000000000000c7f4 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::UpdateBufferList(ANativeWindowBuffer*)+284)
#02 pc 000000000000c390 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::DequeueBuffer()+240)
#03 pc 000000000000bb10 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::GetBuffer(EglSubResource*, EglMemoryDesc*)+64)
#04 pc 000000000032732c /vendor/lib64/egl/libGLESv2_adreno.so (EglWindowSurface::UpdateResource(EsxContext*)+116)
#05 pc 0000000000326dd0 /vendor/lib64/egl/libGLESv2_adreno.so (EglWindowSurface::GetResource(EsxContext*, EsxResource**, EsxResource**, int)+56)
#06 pc 00000000002ae484 /vendor/lib64/egl/libGLESv2_adreno.so (EsxContext::AcquireBackBuffer(int)+364)
#07 pc 0000000000249680 /vendor/lib64/egl/libGLESv2_adreno.so (EsxContext::Clear(unsigned int, unsigned int, unsigned int, EsxClearValues*)+1800)
#08 pc 00000000002cb52c /vendor/lib64/egl/libGLESv2_adreno.so (EsxGlApiParamValidate::GlClear(EsxDispatch*, unsigned int)+132)
Improve handling of landscape/portrait orientation. Promote to SCREEN_ORIENTATION_SENSOR_* when needed.
Android window can be somehow resizable.
If SDL_WINDOW_RESIZABLE is set, window size change is allowed, for instance when orientation changes (provided the hint allows it).
Konrad
I took the liberty of rewriting this function a bit as it seemed to be unnecessary extended with ifs regarding flags (we can check everything in one pass which seem to be the thing which confuses Visual C++ 2019 as well).
Also, I have made CPU features an int instead of uint because if we check it against flags which are all ints it might as well just be int (no signed/unsigned bitwise comparison).
Konrad
This kind of blending is rather quite useful and in my opinion should be available for all renderers. I do need it myself, but since I didn't want to use a custom blending mode which is supported only by certain renderers (e.g. not in software which is quite important for me) I did write implementation of SDL_BLENDMODE_MUL for all renderers altogether.
SDL_BLENDMODE_MUL implements following equation:
dstRGB = (srcRGB * dstRGB) + (dstRGB * (1-srcA))
dstA = (srcA * dstA) + (dstA * (1-srcA))
Background:
https://i.imgur.com/UsYhydP.png
Blended texture:
https://i.imgur.com/0juXQcV.png
Result for SDL_BLENDMODE_MOD:
https://i.imgur.com/wgNSgUl.png
Result for SDL_BLENDMODE_MUL:
https://i.imgur.com/Veokzim.png
I think I did cover all possibilities within included patch, but I didn't write any tests for SDL_BLENDMODE_MUL, so it would be lovely if someone could do it.
This sequence works across Microsoft, PowerA, PDP, and HORI controllers.
The newer Microsoft XBox firmware requires synchronizing the rumble sequence number, when SDL sees it after the initial connect
The Razer Wildcat controller requires waiting for init responses before continuing the initialization sequence.
The PDP Battlefield 1 controller takes over a second to be ready for initialization, and if initialization is attempted before then, it will fail.
Use XGetKeyboardControl to initialize the current XKeyboardState, and
skip XAutoRepeatOn invocation if global_auto_repeat is AutoRepeatModeOn.
This fixes SDL2 when the X11 client is untrusted.
Do not try to guess MIT_SHM extension availability from the string
returned by XDisplayName, use the appropriate API instead.
This fixes SDL2 inside hasher.
Murad
On my system, SDL_GetPowerInfo() returns -1 seconds of battery life left. I have quickly investigated that in my case SDL uses sys interface to get battery data. It tries to read "time_to_empty_now" file which is not always present. However, it is still possible to calculate remaining lifetime using "energy_now" and "power_now" files. This is what my simple patch (included as attachment) tries to accomplish.
Best wishes.
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 SDL_SetJoystickIDForPlayerIndex with MSVC x64 on Windows on latest default branch. And we found that it can be first reproduced on 0fff06175109 changeset. Could you please help have a look about this issue? Thanks in advance!
Steps to Reproduce:
1.hg clone https://hg.libsdl.org/SDL D:\SDL\src
2.Open a VS 2017 x64 command prompt as admin and browse to D:\SDL
3.msbuild /p:Configuration=Release /p:Platform=x64 /p:WindowsTargetPlatformVersion=10.0.17134.0 VisualC\SDL.sln /t:Rebuild
Actual result:
Creating library D:\SDL\src\VisualC\x64\Release\SDL2.lib and object D:\SDL\src\VisualC\x64\Release\SDL2.exp
SDL_joystick.obj : error LNK2019: unresolved external symbol memset referenced in function SDL_SetJoystickIDForPlayerIndex [D:\SDL\src\VisualC\SDL\SDL.vcxproj]
D:\SDL\src\VisualC\x64\Release\SDL2.dll : fatal error LNK1120: 1 unresolved externals [D:\SDL\src\VisualC\SDL\SDL.vcxproj]
Done Building Project "D:\SDL\src\VisualC\SDL\SDL.vcxproj" (Rebuild target(s)) -- FAILED.
The function we currently use, IOHIDDeviceRegisterRemovalCallback(), often
fails on Catalina with a "__CFRunLoopModeFindSourceForMachPort returned NULL"
error message. Once a removal callback is missed, we will eventually crash when
the joystick is closed attempting to use the invalid IOHIDDeviceRef.
https://forums.developer.apple.com/thread/124444
Konrad
This was something rather trivial to add, but asked at least several times before (I did google about it as well).
It should be possible to dynamically change scaling mode of the texture. It is actually trivial task, but until now it was only possible with a hint before creating a texture.
I needed it for my game as well, so I took the liberty of writing it myself.
This patch adds following functions:
SDL_SetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode scaleMode);
SDL_GetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode *scaleMode);
That way you can change texture scaling on the fly.
Using Wii U GameCube USB adapter with multiple controllers attached and
restarting SDL input in a game results in extra joysticks with NULL name.
HIDAPI_CleanupDeviceDriver() shut down joysticks by iterating through
device->num_joysticks but each HIDAPI_JoystickDisconnected() decreases
device->num_joysticks and shifts joysticks array down. Resulting in only
half of controllers being shutdown. It worked with only 1 controller
attached though.
Disconnect HIDAPI device joystick 0 until there are none left.
Message in the log, when going to background:
"call to OpenGL ES API with no current context (logged once per thread)"
Because of SDL_WINDOWEVENT_MINIMIZED is sent from the Java Activity thread.
It calls SDL_RendererEventWatch(), _WindowEvent() and glFinish() without context.
Solution is to move sending of SDL_WINDOWEVENT_MINIMIZED to the SDL thread.
Added the functions SDL_JoystickFromPlayerIndex(), SDL_JoystickSetPlayerIndex(), SDL_GameControllerFromPlayerIndex(), and SDL_GameControllerSetPlayerIndex()
For some obscure reason, the order in which the libdrm/libgbm libraries
are loaded matters.
Without this fix, the first call to check_modesetting() will work and
load then unload all symbols properly, but the second call to this
function will lock up as soon as dlopen() is called on libdrm.
Swapping the order in which the libdrm and libgbm libraries are loaded
is enough to fix (or work around?) this issue.
Fixes#4891:
https://bugzilla.libsdl.org/show_bug.cgi?id=4891
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Aaron Barany
I realized I made a minor mistake in my patch: I changed the constructor prototype for SDL_DisplayData, but didn't update the declaration in the .h file. The compiler and linker don't complain, but it would probably be best to fix in case a later change runs into a problem from the mismatch. I have attached a patch to fix this.
meyraud705
On a Dualshock 4 controller using hidapi driver, calling SDL_JoystickRumble with a duration too long (SDL_HAPTIC_INFINITY for example) causes the rumble to stop immediately.
This happens because of integer overflow on line 301 of SDL_hidapi_ps4.c
(https://hg.libsdl.org/SDL/file/a3077169ad23/src/joystick/hidapi/SDL_hidapi_ps4.c#l301), which sets expiration time in the past.
When we initialize the controller it has an internal rumble sequence number, and if our rumble sequence number doesn't match that, rumble won't happen. To fix that we cycle through the range of sequence numbers, and at some point we'll match up with the controller's sequence number and it'll roll forward until it matches our next rumble sequence number.
Aaron Barany
There appears to be no way to directly access the display DPI on iOS, so as an approximation the DPI for the iPhone 1 is used as a base value and is multiplied by the screen's scale. This should at least give a ballpark number for the various screen scales. (based on https://stackoverflow.com/questions/25756087/detecting-iphone-6-6-screen-sizes-in-point-values it appears that both 2x and 3x are used)
I have updated the patch to use a table of current devices and use a computation as a fallback. I have also updated the fallback computation to be more accurate.
Aaron Barany
Add SDL_HINT_VIDEO_EXTERNAL_CONTEXT hint to notify SDL that the graphics context is external. This disables the automatic context save/restore behavior on Android and avoids using OpenGL by default when SDL_WINDOW_VUKLAN isn't set.
When the application wishes to manage the OpenGL contexts on Android, this avoids cases where SDL unbinds the context and creates new contexts, which can interfere with the application's operation.
When using Vulkan and Metal renderer implementations, this avoids SDL forcing OpenGL to be enabled on certain platforms. While using the SDL_WINDOW_VULKAN flag can be used to achieve the same thing, it also causes Vulkan to be loaded. If the application uses Vulkan directly, this is not necessary, and fails window creation when using Metal due to Vulkan not being present. (assuming MoltenVK isn't installed)
Aaron Barany
Since OpenGL is deprecated on iOS, it is advantageous to be able to remove all OpenGL related code when building SDL for iOS. This patch adds the necessary #if checks to compile in this case.
SDL_SendWindowEvent will only send a RESTORED event if the window has
the minimized or maximized flag set. However, for a SHOWN event, it
will clear the minimized flag. Since the SHOWN event was being sent
first for a MapNotify event, the RESTORED event would never be sent.
Swapping the SendWindowEvent calls around fixes this.
https://bugzilla.libsdl.org/show_bug.cgi?id=4821
Calling open() on input devices can generate device I/O which blocks
the main thread and causes dropped frames. Using stat() we can avoid
opening anything unless /dev/input has changed since we last polled.
We could have used something fancy like inotify, but it didn't seem
worth the added complexity for this uncommon non-udev case.
Eric Shepherd
Currently, SDL on Cocoa macOS creates a rudimentary menu bar programmatically if none is already present when the app is registered during setup.
SDL could be much more easily and flexibly used on macOS if upon finding that no menus are currently in place, it first looked for the application's main menu nib or xib file and, if found, loaded that instead of programmatically building the menus.
This would then let developers simply drop in a nib file with a menu bar defined in it and it would be installed and used automatically.
Attached is a patch that does just this. It changes the SDL_cocoaevents.m file to:
* In Cocoa_RegisterApp(), before calling CreateApplicationMenus(), it calls a new function, LoadMainMenuNibIfAvailable(), which attempts to load and install the main menu nib file, using the nib name fetched from the Info.plist file. If that succeeds, LoadMainMenuNibIfAvailable() returns true; otherwise false.
* If LMMNIA() returns false, CreateApplicationMenus() is called to programmatically build the menus as before.
* Otherwise, we're done, and using the menus from the nib/xib file!
I made these changes to support a project I'm working on, and felt they were useful enough to be worth offering them for uplift. They should have zero impact on existing projects' behavior, but make Cocoa SDL development miles easier.
(note from PulkoMandy on Bugzilla #4442 about why this is a desirable patch:
"The event mask: note that the window and GL view run in their own thread
which I don't expect to be too much CPU bound, and will quickly pop these
messages and forward them to the main thread in our SDL code. Therefore the
B_NO_POINTER_HISTORY should be no problem, and is the default on Haiku
anyway (it was not in BeOS, but we changed that and added a
B_FULL_POINTER_HISTORY flag to request the old behavior explicitly). So, this
seems fine.")
Partially fixes Bugzilla #4442.
Michael Roe
The mappings for keyboard scancodes on Linux do not include keypad left and right parentheses (used on some Microsoft keyboard), keypad plus/minus, LANG1 and LANG2 (used on Korean keyboards), XK86MenuKB, and F20 (remapped to Audio Mic Mute in the usual X11 config).
Solra Bizna
I have written a program that, in the event that the user requests more MSAA samples than their hardware supports, attempts to gracefully fall back to the best MSAA available. This code works with my conventional OpenGL renderer, but if I change nothing about the code except to make it request an OpenGL ES profile instead, Xlib kills the program with an error that looks like:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 4 (X_DestroyWindow)
Resource id in failed request: 0x5c00008
Serial number of failed request: 188
Current serial number in output stream: 193
To trigger the bug, attempt to create a window with the SDL_WINDOW_OPENGL flag, with SDL_GL_CONTEXT_PROFILE_MASK set to SDL_GL_CONTEXT_PROFILE_ES, and with SDL_GL_MULTISAMPLESAMPLES set to any unsupported value. SDL_CreateWindow properly returns NULL, but at this point the program is already doomed. Xlib will shortly terminate the program with an error. Calling SDL_CreateWindow again will immediately trigger this termination.
I have attached a skeletal program that reproduces this bug for me. Replacing SDL_GL_CONTEXT_PROFILE_ES with SDL_GL_CONTEXT_PROFILE_COMPATIBILITY avoids the bug (but, obviously, doesn't create an OpenGL ES context).
As I suspected, the problem was with XDestroyWindow being called twice on the same window. The X11_CreateWindow function in src/video/x11/SDL_x11window.c calls SetupWindowData. If initialization fails after that point, XDestroyWindow gets called on the window by a subsequent call to X11_DestroyWindow. But, later in the same function, iff a GLES context is requested and initializing it fails, X11_XDestroyWindow (which wraps XDestroyWindow) is manually called. Shortly after, the intended call to X11_DestroyWindow occurs, which attempts to destroy the same window again. Boom.
(The above confusing summary involves three separate, similarly-named functions: XDestroyWindow, X11_DestroyWindow, X11_XDestroyWindow)
I have attached a simple patch that removes the redundant X11_XDestroyWindow calls. I've tested that XDestroyWindow still gets called for the windows in question, and that it only gets called once.
- _num_clips was not set in constructor, so a NULL _clips could be
mistakenly dereferenced.
- As _clips is accessible outside the class, it is not a good idea to
free/reallocate it. Try to limit this by reallocating only when it needs to
grow.
Partially fixes Bugzilla #4442.
warning: either cast from 'int' to 'size_t' (aka 'unsigned long') is ineffective, or there is loss of precision before the conversion [bugprone-misplaced-widening-cast]
This can happen if a window is still grabbed when we try to move it, or if
the X11 ecosystem is just in a bad mood, I guess.
This makes sure that SDL will report the correct position for a window;
otherwise, SDL_GetWindowPosition will just report whatever the last
SDL_SetWindowPosition call requested, even if the window didn't actually move.
Fixes Bugzilla #4646.
