Andreas Falkenhahn
When compiling SDL for the Raspberry Pi, I have to use the --host parameter to enable compilation of the native Raspberry Pi video driver, like so:
--host=arm-raspberry-linux-gnueabihf
It took me a while to figure out that this was necessary in order to have the native Raspberry Pi video driver compiled in. I think it would be better if there was an option like --enable-video-rpi that could be passed to configure and that would also show up when saying configure --help. Currently, it?s rather difficult to figure out that you have to use the --host parameter with arm-raspberry-linux-gnueabihf in order to get Raspberry Pi video support. It?s also somewhat inconsistent because most other video drivers can in fact be enabled/disabled through specific configure parameters but there is no such parameter for the native Raspberry Pi video driver.
Simon Hug
These are the remaining compiler warnings I see in the current tip cb049cae7c3c.
- SDL_test_log.c defines _CRT_SECURE_NO_WARNINGS without checking if it was already set.
- SDL_windowskeyboard.c converts integers to pointers without going over the (U)INT_PTR types. That bothers MSVC.
Now we try the new (hardware-specific) pathnames first, and if those fail to
load, we'll try the more generic names that earlier versions of Raspbian used.
Fixes Bugzilla #3800.
Mart?n Golini
I'm having a very slow initialization of the video subsystem that locks the window creation for about 500 ms ( tested in at least 4 different systems ). What i found is that X11_InitModes_XRandR is using XRRGetScreenResources, that explicitly ask to poll the hardware for changes. This is not really necessary since if the data is already available you can use XRRGetScreenResourcesCurrent.
I attached a tentative patch that fix this issue. With the patch there's no lock when the subsystem is initialized and the window creation is instant in my applications. The patch only uses XRRGetScreenResourcesCurrent in X11_InitModes_XRandR but it could be potentially used in X11_GetDisplayModes and X11_SetDisplayMode.
bastien.bouclet
When creating two surfaces and blitting them onto the other, SDL's internal reference counting fails, and one of the surfaces is not freed when calling SDL_FreeSurface.
Example code :
SDL_Surface *s1 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888);
SDL_Surface *s2 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888);
SDL_BlitSurface(s1, NULL, s2, NULL);
SDL_BlitSurface(s2, NULL, s1, NULL);
SDL_FreeSurface(s2);
SDL_FreeSurface(s1);
With this example, s1 is not freed after calling SDL_FreeSurface, its refcount attribute is still positive.
This also seems to fix the follow-up issue in bug #3719, whereby the initial fix caused the SDL window to move, after transitioning from fullscreen to windowed-mode
This is necessary because the Raspberry Pi is a strange beast, that believes
it has OpenGL support (through glX?) but generally has GLES2 support.
So when using the raspberry video target, we need to force this to default
to a GLES2 context, or by default SDL_CreateWindow() will fail, deep down
when it tries to load the proper GL library.
Fixes testsprite2 (and basically everything else that wasn't testgles2) when
run on a Raspberry Pi without a X server.
Please note that other targets might also need this filled in, the Raspberry
Pi is just the most prominent and readily-available System-On-A-Chip style
thing on my desk. :)
Romain Tisserand
Using KMS/DRM driver from WIP SDL2.0.6 on Linux/ARM SoC RockChip RK3328 (ARM Mali 450 MP2 GPU).
The current code is using GBM_BO_FORMAT_XRGB8888 as GBM buffer format specifier.
The Mali driver (it has been confirmed some other vendor implementations too) expects GBM_FORMAT_XRGB8888.
The Mesa implementation is actually handling both values as the same, but it's not implemented like this into every gbm.h vendor header.
https://github.com/ideak/mesa/blob/master/src/gbm/backends/dri/gbm_dri.c
So with stock SDL2 on my card (Mali vendor implementation), it does not work, eglCreateWindowSurface fails, and gbm_is_format_supported fails too (with the BO variant).
It runs fine with GBM_FORMAT_XRGB8888.
Here is a link of the gbm.h from Mali user-space driver :
https://github.com/rockchip-linux/libmali/blob/rockchip/include/gbm.h
This is necessary because we need to see if GLES compat extensions exist.
All of this code (including ShouldUseTextureFramebuffer()) should be
revisited after 2.0.6 ships; ideally we don't make throwaway contexts if
we can avoid it...but maybe we can't. I hear Vulkan is pretty cool.
Fixes Bugzilla #3725.
benjamin.feng
Probable underlying cause: https://bugzilla.libsdl.org/show_bug.cgi?id=3124#c5
"If you download and build the HID Calibrator sample you can see that these are totally legitimate HID devices (except for inverting the Y-axis of joysticks, which is contrary to the HID specification but does make them more compatible with games compiled expecting XBOX controllers)."
Colin Barrett
Using the pre-built x86 devel libs from here:
https://www.libsdl.org/release/SDL2-devel-2.0.5-VC.zip
If I have:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_DEBUG_FLAG);
and I'm using ANGLE/(a GL driver that doesn't provide an ES2 context) such that SDL_EGL_CreateContext is called by SDL_GL_CreateContext, I get the error "Could not create EGL context (context attributes are not supported)" and no context is created.
Looking at the code in SDL_EGL_CreateContext - if gl_config.flags is non-zero, it looks like the code in the section guarded with "#ifdef EGL_KHR_create_context" should be executed - but it apparently isn't.
Is it possible this section hasn't been compiled into the pre-built libraries? If I build SDL2.dll myself using the Visual C++ solution (VS2015 Community Update 3) then the call succeeds as I expect
bastien.bouclet
When exiting a "fullscreen space" on OS X, windows don't go to their defined "windowed mode size", but go back to their previous size.
Steps to reproduce:
1. Create a windowed mode SDL window
2. Toggle it to fullscreen with the SDL_WINDOW_FULLSCREEN_DESKTOP flag
3. While in fullscreen, change the windowed mode size using SDL_SetWindowSize
4. Toggle the window back to windowed mode
Expected result:
- The window has the size specified during step 3.
Actual result:
- The window has the size specified when creating the window in step 1.
Attached is a minimal reproduction test case.
The attached test case works as expected on X11 and Windows.
Ozkan Sezer
fix windows build after revision 11382: commit 2026e42e377a renamed
_SDL_msctf_h to SDL_msctf_h_ . SDL_windowskeyboard.c relies on that
macro, so update it accordingly.
Ozkan Sezer
Since the Vulkan merge, building against a Mac OS X SDM older than
10.11 fails in SDL_cocoametalview.m because Metal.framework is not
present. There is no conditional compiling in SDL_cocoametalview.m
either, so --disable-video-vulkan doesn't help with anything. (The
configury doesn't check darwin for x86_64 either, but it's another
story.)
I cross-build against 10.8 SDK on linux using clang-3.4.2 and this
is a problem for me. Will this be fixed?
Simon Hug
This issue actually raises the question if this API change (requirement of initialized audio subsystem) is breaking backwards compatibility. I don't see the documentation saying it is needed in 2.0.5.
"Major changes, roughly in order of appearance:
- Use float math everywhere, instead of promoting to double and casting back
all the time.
- Conserve sound energy when downmixing any channel into two other channels.
- Add a QuadToStereo filter. (The previous technique of reusing StereoToMono
never worked, since it assumed an incorrect channel layout for 4.0.)
- Add a 71to51 filter. This removes just under half of the cases the previous
code would silently break in.
- Add a QuadTo51 filter. More silent breakage fixed.
- Add a 51to71 filter, removing another almost-half of the silently broken
cases.
- Add 8 to the list of values SDL_SupportedChannelCount will accept.
- Change SDL_BuildAudioCVT's channel-related logic to handle every case, and
to actually fail if it fails instead of silently corrupting sound data and/or
crashing down the road."
(Note that SDL doesn't otherwise support 7.1 audio yet, but hopefully it will
soon and the 7.1 converters are an important piece of that. --ryan.)
Fixes Bugzilla #3727.
Sam Lantinga
Ryan C. Gordon
David Ludwig
Alex Szpakowski