kmx git

Commit	Date	Message
132f87c3	2020-04-13T22:06:12	opengl: Don't try to do Desktop OpenGL stuff if support isn't available.
6f3fa02e	2020-04-13T18:25:38	Make sure we're using the bounds of the view for our mouse region
cab1ee9c	2020-04-13T15:57:04	Don't build iOS mouse support on Apple TV
e5d36299	2020-04-13T15:46:12	Added support for new mouse APIs in iOS 13.4
e96b05c3	2020-04-13T18:21:28	egl: Attempt to make this compile on WinRT, etc.
c0a875fa	2020-04-13T14:48:38	SDL_EGL_ChooseConfig: don't fall through if no matching format exists On Raspberry Pi 3 via the VC4 driver in firmware KMS mode, none of the found configs match the desired format, causing the function to fall through without any config being selected. Fix by first iterating over the found configs, and if no match exists, don't exclude the non-matching configs. This should fix RPI3 and possibly other targets without breaking targets that have a matching native format (such as RPI4).
64617d25	2020-04-13T14:45:40	opengl: Convert an int to an SDL_bool.
389c8995	2020-04-13T14:44:21	opengl: Allow SDL_GL_MakeCurrent() to accept a NULL window (thanks, Martin!). This allows you to bind surfaceless contexts on a background thread to, for example, load assets in a separate context, for platforms that have different requirements about sharing surfaces, etc. Martin's notes on the matter: "Here's a patch that enables passing NULL windows to SDL_GL_MakeCurrent, if the involved APIs allow it. Currently, this is only the case for EGL, and even then only if some specific extensions are present (which they usually are). If "surfaceless" contexts are not supported, SDL_GL_MakeCurrent continues to generate an error (albeit with a more specific error message than it used to), so this should not break anything that wasn't broken before." (Please see https://bugzilla.libsdl.org/show_bug.cgi?id=3695 for more discussion.) Fixes Bugzilla #3695.
8a5ee3fa	2020-04-12T00:55:52	video: NULL out pointer to freed window surface This behavior matches SDL_RecreateWindow and makes it less likely that another piece of code (e.g. a DestroyWindowFramebuffer implementation) will attempt to use or free the stale surface pointer.
a7916890	2020-04-10T00:37:35	metal: Added some support interfaces to Apple's Metal API (thanks, Caleb!). Caleb Cornett's comments: "A few weeks ago, Alex added a partial Metal API to SDL2: https://hg.libsdl.org/SDL/rev/22c8e7cd8d38 I noticed it was missing a few features that would help Metal become a first-class citizen in SDL, so I went ahead and wrote them! Here are the new APIs: 1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer to specify that they intend to create a window for use with SDL_MetalView. The flag is used to ensure correct usage of the API and to prevent accidentally defaulting to OpenGL on iOS. 2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a pointer to the view's backing CAMetalLayer. This simplifies things considerably, since in the current version of the SDL_Metal API the programmer is required to bridge-cast a SDL_MetalView handle to an NSView or UIView (depending on the platform) and then extract the layer from there. SDL_Metal_GetLayer automatically handles all of that, making the operation simple and cross-platform. 3. SDL_Metal_GetDrawableSize(). This function already exists in the current SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize on Apple platforms) but was not publicly exposed. My patch exposes this function for public use. It works just like you'd expect. Tested on macOS 10.14 and iOS 12.4." Fixes Bugzilla #4796.
258d4106	2020-04-09T15:57:12	emscripten: Add a few keyCode mappings for German keyboards From @sy2002 in https://github.com/emscripten-ports/SDL2/issues/108
babf010c	2020-04-09T15:01:47	emscripten: Pass canvas id to request_pointer_lock Fixes pointer lock with DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1
287772f5	2020-04-09T15:01:45	emscripten: Let SDL_GetDisplayUsableBounds return the size of the window This does not account for scrollbars nor margins. But is much better then returning the full display size when not running fullscreen, but for example in an iframe.
fb3df3a1	2020-04-09T15:01:41	emscripten: Fix the reported keys for the numpad. See https://github.com/emscripten-ports/SDL2/issues/94
44716b02	2020-04-09T15:01:37	emscripten: Send SDL_APP_TERMINATING before unload (#88)
0380cbd7	2020-04-09T15:01:32	emscripten: Typo
d4f1b520	2020-04-08T19:16:31	Added support for press/release hardware keyboard events in iOS 13.4
6e6b5177	2020-04-07T23:34:41	cocoa: Patched to compile.
8641f6e9	2020-04-07T14:03:13	emscripten: support KaiOS's Left Soft Key and Right Soft Key (thanks, pelya!). Fixes Bugzilla #5027.
309d6137	2020-04-07T14:01:25	cocoa: OpenGL setView and update must be used on main thread (thanks, Tim!). If called from background threads, use Grand Central Dispatch to use the main thread instead. On the main thread, just call them directly. Fixes Bugzilla #4932.
02469877	2020-04-07T13:30:46	wayland: Support wayland compositors with wl_seat version < 5 (thanks, Nia!). Fixes Bugzilla #5074.
b6afbe63	2020-04-07T09:38:57	Added SDL_log.h to SDL_internal.h so logging is available everywhere
488b94cb	2020-04-07T09:18:19	Don't interpret raw input messages with no mouse position This happens occasionally on touch devices when raw input is enabled
0721931f	2020-04-06T19:21:56	Avoid sending regular mouse messages for touch input
dad73b1f	2020-04-05T10:47:58	Fixed bug 5073 - SDL does not handle URL Schemes in MacOS Jason In iOS, URL Events trigger the DropFile event. I would also expect the same event to be fired on the macOS platform but this is not implemented at all in the AppDelegate.
e05d92a1	2020-04-05T09:01:33	Fixed bug 5075 - Don't assume a GL library version number on NetBSD. Nia Alarie If you install X as part of NetBSD, the GL library is libGL.so.3, but if you install the GL library later as a package, it's libGL.so.1.
6e7465bd	2020-03-28T15:43:55	Fixed Bug 4883, redux - connect SDL_GetDisplayDPI to UIKit_GetDisplayDPI SDL_GetDisplayDPI was failing on iOS, as UIKit_GetDisplayDPI was not getting assigned to SDL's internal field in SDL_VideoDevice: GetDisplayDPI.
f2ff953e	2020-03-26T13:42:56	cocoa: Just update the OpenGL context directly if on the main thread.
361417c0	2020-03-25T16:40:43	cocoa: allow calling CreateWindowFrom on an NSView This lets applications embed SDL with other widgets surrounding it. Already possible on Windows and X11. Fixes Bugzilla #5060.
9354aea1	2020-03-25T09:38:45	src/video/kmsdrm/SDL_kmsdrmvideo.c: fix build 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>
a4b0204b	2020-03-24T10:05:51	src/video/directfb/SDL_DirectFB_render.c: fix build 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>
1fd548b6	2020-03-23T11:42:44	Fixed building back to Mac OSX using the 10.7 SDK
e0a27056	2020-03-22T20:09:14	Do not overwrite window surface created by driver 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).
90f9e8f8	2020-03-20T15:13:09	egl: Don't use SDL_LoadFunction to get GL entry points on Emscripten. 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.
5b3b55a1	2020-03-20T11:52:18	[NSOpenGLContext update[ is prohibited outside the main thread
838bbf1f	2020-03-17T09:35:42	Fixed bug 5037 - Regression 2.0.12 Alpha value of 0 on palette may become opaque (see also bug 3827)
55a2a12d	2020-03-16T22:34:33	Fixed compile warning
4dea340c	2020-03-16T12:23:38	Fixed bug 4477 - Support more than 4 XInput-capable devices on Windows 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.
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.
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.
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
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
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 :)
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)
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.
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.
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.
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
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.
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
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
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).
4378fcd9	2020-02-10T23:48:06	wayland: Fix building with -fno-common (which is now the default in GCC 10). Fixes Bugzilla #4957.
3e935aec	2020-02-09T11:44:22	Fixed bug 4966 - KMSDRM: Add dynamic modeset support 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).
4b585e75	2020-02-03T08:06:52	Fixed bug 4833 - Use EGL for X11? 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
67f44788	2020-02-03T00:57:12	Fixed bug 4917 - Wayland: handle discrete pointer axis events 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.
62a3d6c0	2020-01-30T14:58:41	Fixed build
37278066	2020-01-30T14:51:33	Export SDL functions for iOS application delegates
c9c89783	2020-01-29T20:09:08	Miscellaneous pending fixes
39563b7b	2020-01-28T13:51:24	x11: Use XSync when changing window position instead of XFlush. Attempt to fix regression in Bugzilla #4646.
c7e1b289	2020-01-27T17:15:12	cocoa: Fix command line apps' menu bar not working on macOS Catalina. Fixes Bugzilla #4937.
b4c2e29e	2020-01-27T10:58:30	video: Added a hint to override the display's usable bounds.
b5e3d264	2020-01-23T01:00:52	Added a single SDL_LEAN_AND_MEAN define to turn on minimal SDL builds Protected more code with #ifdefs to reduce the size of minimal shared library builds
55afc281	2020-01-21T22:06:09	Add #define SDL_HAVE_BLIT_N_RGB565 to compile out RGB565 LUT
7df22cf2	2020-01-21T21:33:40	A few #defines to reduce SDL2 footprint. Only applied when library is statically linked
005e2dff	2020-01-17T12:41:54	Android: prevents rare crashes when app goes to background or ends. 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)
d52ba78b	2020-01-17T12:04:18	Fixed bug 4246 - Android: orientation between portrait<->landscape doesn't work 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).
a8780c6a	2020-01-16T20:49:25	Updated copyright date for 2020
572f4a85	2020-01-16T15:54:20	Fixed bug 4929 - Software renderer produces bugs when optimizations are turned on with Visual C++ 2019 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).
981e0d36	2020-01-16T08:52:59	Fixed bug 4903 - Lack of color multiply with alpha (SDL_BLENDMODE_MOD + SDL_BLENDMODE_BLEND) blending mode for all renderers 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.
2b1edf41	2020-01-04T11:05:06	X11_InitKeyboard: do not call XAutoRepeatOn unnecessarily 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.
ed514cd0	2020-01-04T11:03:04	have_mitshm: use XShmQueryExtension to check for MIT-SHM extension 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.
cdbeae52	2019-12-29T23:10:39	wayland: support wl_data_device_manager version < 3
9340cfa9	2019-12-27T23:01:10	SDL_x11events.c (X11_DispatchEvent): remove FIXME and use SDL_strtokr().
5e19e66c	2019-12-22T13:39:44	Fixed bug 4914 - Expose SDL_ScaleMode and add SDL_SetTextureScaleMode/SDL_GetTextureScaleMode 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.
d004cc70	2019-12-21T22:40:33	Android: same way as in nativePause(), resume events are sent from SDL thread
45a9b5fa	2019-12-21T21:18:02	Android: fix call of glFinish without context. 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.
95d40e8a	2019-12-19T21:47:43	kmsdrm: Fix busy-loop within libc's dlopen() 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>
20daf54f	2019-12-19T15:18:50	Added new HIDAPI driver files to the Xcode projects
bc430d40	2019-12-16T10:26:36	Update for bug 4883 - Add approximation for display DPI on iOS 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.
140918bb	2019-12-08T11:36:40	Fixed bug 4883 - Add approximation for display DPI on iOS 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.
54748a39	2019-12-08T11:33:06	Fixed bug 4890 - Add hint for SDL that the graphics context is externally managed 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)
597f11e5	2019-12-05T17:27:06	cocoa: Patched to compile on older compilers.
ca2c8609	2019-12-04T12:20:24	cocoa: SDL_GetDisplayDPI() should account for Retina displays. Fixes Bugzilla #4856.
b7576025	2019-12-03T22:07:58	Fixed bug 4882 - Fix build for iOS when disabling OpenGL 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.
7a3ae590	2019-12-03T07:12:55	Fixed bug 4877 - Add support for loading menus from a nib/xib instead of building a hardcoded minimum set 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.

132f87c3

2020-04-13T22:06:12

opengl: Don't try to do Desktop OpenGL stuff if support isn't available.

6f3fa02e

2020-04-13T18:25:38

Make sure we're using the bounds of the view for our mouse region

cab1ee9c

2020-04-13T15:57:04

Don't build iOS mouse support on Apple TV

e5d36299

2020-04-13T15:46:12

Added support for new mouse APIs in iOS 13.4

e96b05c3

2020-04-13T18:21:28

egl: Attempt to make this compile on WinRT, etc.

c0a875fa

2020-04-13T14:48:38

SDL_EGL_ChooseConfig: don't fall through if no matching format exists On Raspberry Pi 3 via the VC4 driver in firmware KMS mode, none of the found configs match the desired format, causing the function to fall through without any config being selected. Fix by first iterating over the found configs, and if no match exists, don't exclude the non-matching configs. This should fix RPI3 and possibly other targets without breaking targets that have a matching native format (such as RPI4).

64617d25

2020-04-13T14:45:40

opengl: Convert an int to an SDL_bool.

389c8995

2020-04-13T14:44:21

opengl: Allow SDL_GL_MakeCurrent() to accept a NULL window (thanks, Martin!). This allows you to bind surfaceless contexts on a background thread to, for example, load assets in a separate context, for platforms that have different requirements about sharing surfaces, etc. Martin's notes on the matter: "Here's a patch that enables passing NULL windows to SDL_GL_MakeCurrent, if the involved APIs allow it. Currently, this is only the case for EGL, and even then only if some specific extensions are present (which they usually are). If "surfaceless" contexts are not supported, SDL_GL_MakeCurrent continues to generate an error (albeit with a more specific error message than it used to), so this should not break anything that wasn't broken before." (Please see https://bugzilla.libsdl.org/show_bug.cgi?id=3695 for more discussion.) Fixes Bugzilla #3695.

8a5ee3fa

2020-04-12T00:55:52

video: NULL out pointer to freed window surface This behavior matches SDL_RecreateWindow and makes it less likely that another piece of code (e.g. a DestroyWindowFramebuffer implementation) will attempt to use or free the stale surface pointer.

a7916890

2020-04-10T00:37:35

metal: Added some support interfaces to Apple's Metal API (thanks, Caleb!). Caleb Cornett's comments: "A few weeks ago, Alex added a partial Metal API to SDL2: https://hg.libsdl.org/SDL/rev/22c8e7cd8d38 I noticed it was missing a few features that would help Metal become a first-class citizen in SDL, so I went ahead and wrote them! Here are the new APIs: 1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer to specify that they intend to create a window for use with SDL_MetalView. The flag is used to ensure correct usage of the API and to prevent accidentally defaulting to OpenGL on iOS. 2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a pointer to the view's backing CAMetalLayer. This simplifies things considerably, since in the current version of the SDL_Metal API the programmer is required to bridge-cast a SDL_MetalView handle to an NSView or UIView (depending on the platform) and then extract the layer from there. SDL_Metal_GetLayer automatically handles all of that, making the operation simple and cross-platform. 3. SDL_Metal_GetDrawableSize(). This function already exists in the current SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize on Apple platforms) but was not publicly exposed. My patch exposes this function for public use. It works just like you'd expect. Tested on macOS 10.14 and iOS 12.4." Fixes Bugzilla #4796.

258d4106

2020-04-09T15:57:12

emscripten: Add a few keyCode mappings for German keyboards From @sy2002 in https://github.com/emscripten-ports/SDL2/issues/108

babf010c

2020-04-09T15:01:47

emscripten: Pass canvas id to request_pointer_lock Fixes pointer lock with DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1

287772f5

2020-04-09T15:01:45

emscripten: Let SDL_GetDisplayUsableBounds return the size of the window This does not account for scrollbars nor margins. But is much better then returning the full display size when not running fullscreen, but for example in an iframe.

fb3df3a1

2020-04-09T15:01:41

emscripten: Fix the reported keys for the numpad. See https://github.com/emscripten-ports/SDL2/issues/94

44716b02

2020-04-09T15:01:37

emscripten: Send SDL_APP_TERMINATING before unload (#88)

0380cbd7

2020-04-09T15:01:32

emscripten: Typo

d4f1b520

2020-04-08T19:16:31

Added support for press/release hardware keyboard events in iOS 13.4

6e6b5177

2020-04-07T23:34:41

cocoa: Patched to compile.

8641f6e9

2020-04-07T14:03:13

emscripten: support KaiOS's Left Soft Key and Right Soft Key (thanks, pelya!). Fixes Bugzilla #5027.

309d6137

2020-04-07T14:01:25

cocoa: OpenGL setView and update must be used on main thread (thanks, Tim!). If called from background threads, use Grand Central Dispatch to use the main thread instead. On the main thread, just call them directly. Fixes Bugzilla #4932.

02469877

2020-04-07T13:30:46

wayland: Support wayland compositors with wl_seat version < 5 (thanks, Nia!). Fixes Bugzilla #5074.

b6afbe63

2020-04-07T09:38:57

Added SDL_log.h to SDL_internal.h so logging is available everywhere

488b94cb

2020-04-07T09:18:19

Don't interpret raw input messages with no mouse position This happens occasionally on touch devices when raw input is enabled

0721931f

2020-04-06T19:21:56

Avoid sending regular mouse messages for touch input

dad73b1f

2020-04-05T10:47:58

Fixed bug 5073 - SDL does not handle URL Schemes in MacOS Jason In iOS, URL Events trigger the DropFile event. I would also expect the same event to be fired on the macOS platform but this is not implemented at all in the AppDelegate.

e05d92a1

2020-04-05T09:01:33

Fixed bug 5075 - Don't assume a GL library version number on NetBSD. Nia Alarie If you install X as part of NetBSD, the GL library is libGL.so.3, but if you install the GL library later as a package, it's libGL.so.1.

6e7465bd

2020-03-28T15:43:55

Fixed Bug 4883, redux - connect SDL_GetDisplayDPI to UIKit_GetDisplayDPI SDL_GetDisplayDPI was failing on iOS, as UIKit_GetDisplayDPI was not getting assigned to SDL's internal field in SDL_VideoDevice: GetDisplayDPI.

f2ff953e

2020-03-26T13:42:56

cocoa: Just update the OpenGL context directly if on the main thread.

361417c0

2020-03-25T16:40:43

cocoa: allow calling CreateWindowFrom on an NSView This lets applications embed SDL with other widgets surrounding it. Already possible on Windows and X11. Fixes Bugzilla #5060.

9354aea1

2020-03-25T09:38:45

src/video/kmsdrm/SDL_kmsdrmvideo.c: fix build 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>

a4b0204b

2020-03-24T10:05:51

src/video/directfb/SDL_DirectFB_render.c: fix build 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>

1fd548b6

2020-03-23T11:42:44

Fixed building back to Mac OSX using the 10.7 SDK

e0a27056

2020-03-22T20:09:14

Do not overwrite window surface created by driver 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).

90f9e8f8

2020-03-20T15:13:09

egl: Don't use SDL_LoadFunction to get GL entry points on Emscripten. 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.

5b3b55a1

2020-03-20T11:52:18

[NSOpenGLContext update[ is prohibited outside the main thread

838bbf1f

2020-03-17T09:35:42

Fixed bug 5037 - Regression 2.0.12 Alpha value of 0 on palette may become opaque (see also bug 3827)

55a2a12d

2020-03-16T22:34:33

Fixed compile warning

4dea340c

2020-03-16T12:23:38

Fixed bug 4477 - Support more than 4 XInput-capable devices on Windows 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.

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.

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.

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

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

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 :)

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)

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.

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.

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.

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

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.

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

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

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).

4378fcd9

2020-02-10T23:48:06

wayland: Fix building with -fno-common (which is now the default in GCC 10). Fixes Bugzilla #4957.

3e935aec

2020-02-09T11:44:22

Fixed bug 4966 - KMSDRM: Add dynamic modeset support 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).

4b585e75

2020-02-03T08:06:52

Fixed bug 4833 - Use EGL for X11? 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

67f44788

2020-02-03T00:57:12

Fixed bug 4917 - Wayland: handle discrete pointer axis events 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.

62a3d6c0

2020-01-30T14:58:41

Fixed build

37278066

2020-01-30T14:51:33

Export SDL functions for iOS application delegates

c9c89783

2020-01-29T20:09:08

Miscellaneous pending fixes

39563b7b

2020-01-28T13:51:24

x11: Use XSync when changing window position instead of XFlush. Attempt to fix regression in Bugzilla #4646.

c7e1b289

2020-01-27T17:15:12

cocoa: Fix command line apps' menu bar not working on macOS Catalina. Fixes Bugzilla #4937.

b4c2e29e

2020-01-27T10:58:30

video: Added a hint to override the display's usable bounds.

b5e3d264

2020-01-23T01:00:52

Added a single SDL_LEAN_AND_MEAN define to turn on minimal SDL builds Protected more code with #ifdefs to reduce the size of minimal shared library builds

55afc281

2020-01-21T22:06:09

Add #define SDL_HAVE_BLIT_N_RGB565 to compile out RGB565 LUT

7df22cf2

2020-01-21T21:33:40

A few #defines to reduce SDL2 footprint. Only applied when library is statically linked

005e2dff

2020-01-17T12:41:54

Android: prevents rare crashes when app goes to background or ends. 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)

d52ba78b

2020-01-17T12:04:18

Fixed bug 4246 - Android: orientation between portrait<->landscape doesn't work 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).

a8780c6a

2020-01-16T20:49:25

572f4a85

2020-01-16T15:54:20

Fixed bug 4929 - Software renderer produces bugs when optimizations are turned on with Visual C++ 2019 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).

981e0d36

2020-01-16T08:52:59

Fixed bug 4903 - Lack of color multiply with alpha (SDL_BLENDMODE_MOD + SDL_BLENDMODE_BLEND) blending mode for all renderers 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.

2b1edf41

2020-01-04T11:05:06

X11_InitKeyboard: do not call XAutoRepeatOn unnecessarily 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.

ed514cd0

2020-01-04T11:03:04

have_mitshm: use XShmQueryExtension to check for MIT-SHM extension 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.

cdbeae52

2019-12-29T23:10:39

wayland: support wl_data_device_manager version < 3

9340cfa9

2019-12-27T23:01:10

SDL_x11events.c (X11_DispatchEvent): remove FIXME and use SDL_strtokr().

5e19e66c

2019-12-22T13:39:44

Fixed bug 4914 - Expose SDL_ScaleMode and add SDL_SetTextureScaleMode/SDL_GetTextureScaleMode 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.

d004cc70

2019-12-21T22:40:33

Android: same way as in nativePause(), resume events are sent from SDL thread

45a9b5fa

2019-12-21T21:18:02

Android: fix call of glFinish without context. 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.

95d40e8a

2019-12-19T21:47:43

kmsdrm: Fix busy-loop within libc's dlopen() 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>

20daf54f

2019-12-19T15:18:50

Added new HIDAPI driver files to the Xcode projects

bc430d40

2019-12-16T10:26:36

Update for bug 4883 - Add approximation for display DPI on iOS 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.

140918bb

2019-12-08T11:36:40

Fixed bug 4883 - Add approximation for display DPI on iOS 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.

54748a39

2019-12-08T11:33:06

Fixed bug 4890 - Add hint for SDL that the graphics context is externally managed 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)

597f11e5

2019-12-05T17:27:06

cocoa: Patched to compile on older compilers.

ca2c8609

2019-12-04T12:20:24

cocoa: SDL_GetDisplayDPI() should account for Retina displays. Fixes Bugzilla #4856.

b7576025

2019-12-03T22:07:58

Fixed bug 4882 - Fix build for iOS when disabling OpenGL 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.

7a3ae590

2019-12-03T07:12:55

Fixed bug 4877 - Add support for loading menus from a nib/xib instead of building a hardcoded minimum set 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.

kc3-lang/SDL/src/video

src/video

Log