Manuel
The attached patch adds support for KMS/DRM context graphics.
It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation.
Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition.
X86 systems use KMS right away in every current GNU/Linux system.
Simple build instructions:
$./autogen.sh
$./configure --enable-video-kmsdrm
$make
Simon Hug
SDL_GL_GetAttribute doesn't check if a video driver has been initialized and will access the SDL_VideoDevice pointer, which is NULL at that point.
I think all of the attributes require an initialized driver, so a simple NULL check should fix it. Patch is attached.
Holger Schemel
Summary: This patch adds support for key events for the "rewind" and "fast forward" media keys on the Amazon Fire TV remote control.
How to reproduce the problem: Run Android build of SDL2 application on the Amazon Fire TV (tested with "stick" version) and log key events.
Expected behaviour: Every key pressed on the Fire TV remote control should result in a corresponding key event (pressed/released).
Observed behaviour: Of the bottom row of buttons on the Fire TV remote control, only the "play/pause" (middle) button generates a key event, while the "rewind" (left) and "fast forward" (right) buttons to not generate any event at all.
The attached patch adds support for these two missing buttons/keys.
Note 1: Some missing definitions were added for the already existing key codes SDL_SCANCODE_APP1 and SDL_SCANCODE_APP2 (to keep up the correct order of enumerations / array positions when adding the two new key codes).
Note 2: Definitions in "scancodes_linux.h" and "scancodes_xfree86.h" (to also add support for these keys on other platforms) were added without testing. However, I was unable to find corresponding definitions for these two media keys for Windows and Mac OS X.
Note 3: I have also updated the (broken) link to the USB usage page standard PDF document (comment in "include/SDL_scancode.h").
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/117d4ce1390e ...can
> you verify this works on the latest MinGW?
>
> Thanks,
> --ryan.
This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)
Simon Hug
There's a chance that an audio conversion from many channels to a few can use more than 9 audio filters. SDL_AudioCVT has 10 SDL_AudioFilter pointers of which one has to be the terminating NULL pointer. The SDL code has no checks for this limit. If it overflows there can be stack or heap corruption or a call to 0xa.
Attached patch adds a function that checks for this limit and throws an error if it is reached. Also adds some documentation.
Test parameters that trigger this issue:
AUDIO_U16MSB with 224 channels at 46359 Hz
V
AUDIO_S16MSB with 6 channels at 27463 Hz
The fuzzer program I uploaded in bug 3667 has more of them.
This only affects Wayland and DirectFB, as a Unix system generally has X11
support. Other platforms also have different sizes for the C union in
question, but are likely the only target for that platform, etc.
Apps that might run on Wayland or DirectFB will need to be compiled against
new headers from an official 2.0.6 release, or be prepared to force the x11
target, or not use SDL_GetWindowWMInfo().
Fixes Bugzilla #3428.
--HG--
extra : rebase_source : 281e37767b92a1a0b9ddbf3efb246d4932126412
Now the compiler might say this:
'SDL_compile_time_assert_mytest' declared as an array with a negative size
instead of
'SDL_dummy_mytest' declared as an array with a negative size
--HG--
extra : rebase_source : 3f7355099cc59118ed4aa39c4a9935f2bf17698f
http://jackaudio.org/
Fixes Bugzilla #2163.
(with several more commits following to improve this code.)
--HG--
extra : rebase_source : 5d0d44fcca077c41c56381575a45184bdc050003
It's easier for Visual Studio users that want this information to turn it on
or live without it, than it is to explain why every debugger that isn't Visual
Studio crashes out here. Eventually SetThreadDescription() will be the thing
everyone uses anyhow.
Fixes Bugzilla #3645.
(and several others).
Apparently this is no longer a generic BSD audio target, and hasn't been for
years, so rename it for NetBSD.
--HG--
rename : src/audio/bsd/SDL_bsdaudio.c => src/audio/netbsd/SDL_netbsdaudio.c
rename : src/audio/bsd/SDL_bsdaudio.h => src/audio/netbsd/SDL_netbsdaudio.h
"In particular, only one VkSurfaceKHR can exist at a time for a given window. Similarly, a native window cannot be used by both a VkSurfaceKHR and EGLSurface simultaneously"
CR: SamL
These don't have to be power-of-2 sizes anymore because of SDL_AudioStream,
and the new resampler, but also, many platforms don't give you power-of-2 DMA
buffer in the first place!
--HG--
extra : rebase_source : ec43e17a761b218f314092952ea5d3861a00b7af
This should remain binary compatible with Windows XP, as we dynamically
load anything we need and fall back to DirectSound/WinMM/XAudio2 if not
available.
This defaults to the internal SDL resampler, since that's the likely default
without a system-wide install of libsamplerate, but those that need more can
tweak this.
--HG--
extra : amend_source : 804f3d3dc636b5f28f7194b48b492c6c3fe05bf5
Mark Callow
The attached patch does the following for the X11 and Windows platforms, the only ones where SDL attempts to use context_create_es_profile:
- Adds SDL_HINT_OPENGL_ES_DRIVER by which the application can
say to use the OpenGL ES driver & EGL rather than the Open GL
driver. (For bug #2570)
- Adds code to {WIN,X11}_GL_InitExtensions to determine the maximum
OpenGL ES version supported by the OpenGL driver (for bug #3145)
- Modifies the test that determines whether to use the OpenGL
driver or the real OpenGL ES driver to take into account the
hint, the requested and supported ES version and whether ES 1.X
is being requested. (For bug #2570 & bug #3145)
- Enables the testgles2 test for __WINDOWS__ and __LINUX__ and adds
the test to the VisualC projects.
With the fix in place I have run testdraw2, testgl and testgles2 without any issues and have run my own apps that use OpenGL, OpenGL ES 3 and OpenGL ES 1.1.
