Anthony
This is what's making the software renderer crash with rotated destination rectangles of w or h = 0:
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "2");
This time it's using real math from a real whitepaper instead of my previous
amateur, fast-but-low-quality attempt. The new resampler does "bandlimited
interpolation," as described here: https://ccrma.stanford.edu/~jos/resample/
The output appears to sound cleaner, especially at high frequencies, and of
course works with non-power-of-two rate conversions.
There are some obvious optimizations to be done to this still, and there is
other fallout: this doesn't resample a buffer in-place, the 2-channels-Sint16
fast path is gone because this resampler does a _lot_ of floating point math.
There is a nasty hack to make it work with SDL_AudioCVT.
It's possible these issues are solvable, but they aren't solved as of yet.
Still, I hope this effort is slouching in the right direction.
This would cause playback problems in certain situations, such as on the
Raspberry Pi. The device that the wait was added for seems to not benefit from
it in modern times, and standard desktop Linux seems to do the right thing
when a USB device is unplugged now, without this patch.
Fixes Bugzilla #3599.
Andreas Falkenhahn
My app opens a 640x480 window. When I click on the window's maximize button, the window correctly fills the entire screen and loses its borders. But clicking on the restore button now doesn't restore the window to its original 640x480 size. Instead, the window size is identical to the screen size now. The only difference to the previous state is that the window now has borders again but it isn't restored to 640x480.
bastien.bouclet
The window is now resized to its specified size, but it moves to the top left corner of the screen. That is unexpected because neither the user nor the program moved it there. Test program attached (the same one as before).
Simon Hug
When RWops seeks with fseek or fseeko it uses the types long or off_t which can be 32 bits on some platforms. stdio_seek does not check if the 64-bit integer for the offset fits into a 32-bit integer. Offsets equal or larger than 2 GiB will have implementation-defined behavior and failure states would be very confusing to debug.
The attached patch adds range checking by using the macros from limits.h for long type and some bit shifting for off_t because POSIX couldn't be bothered to specify min and max macros.
It also defines HAVE_FSEEKI64 in SDL_config_windows.h so that the Windows function gets picked up automatically with the default config.
And there's an additional error message for when ftell fails.
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.
David Brady
When I attempted to make a mapping file for Android gamepads, I quickly discovered that most of the ones that I have here show up as the same device (Broadcom Bluetooth HID), meaning that it was impossible to make mappings on Android, since every device looked the same.
This patch will check for the existence of the getDescriptor function added in Jelly Bean, and use it if it's there. The Android Dashboard says that the majority of Android phones should support this function, and doing it this way will not force us to bump up our API version.
Clayton Craft
The default path used by directfb for libGL is different than the default path used by x11 in SDL2:
./src/video/directfb/SDL_DirectFB_opengl.c:
path = "libGL.so";
./src/video/x11/SDL_x11opengl.c:
#define DEFAULT_OPENGL "libGL.so.1"
On at least one distro (Alpine Linux), libGL.so is not created (or more accurately the symlink to libGL.so.1 is not created). For consistency, the 'path' variable in SDL_DirectFB_opengl.c should patch the DEFAULT_OPENGL in SDL_x11opengl.c ("libGL.so.1")
Error message was:
[mvk-info] MoltenVK version 0.18.2. Vulkan version 1.0.51.
[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: On-screen rendering requires a view that is backed by a layer of type CAMetalLayer.
2017-08-28 02:17:29.579 testvulkan[95627:1716939] ERROR: SDL_Vulkan_CreateSurface(): vkCreateMacOSSurfaceMVK failed: VK_ERROR_INITIALIZATION_FAILED
David Ludwig
I've created a new set of patches. I am happy to create more, if it would help.
One version only copies 'size'.
A second version copies both 'size' and 'silence'. When looking over the documentation for SDL_OpenAudio in SDL_audio.h, it mentioned that both 'size' and 'silence' were things that SDL_OpenAudio would calculate.
Regarding *both* patches, I did notice that SDL 1.2 appears to have always modified desired's size and silence fields. The SDL wiki, at https://wiki.libsdl.org/SDL_OpenAudio#Remarks , does note:
Carlos
We would like to add a switch (define) that allows us to compile Angle statically with SDL. That is, getting rid of the OpenGL DLL. Usually you need OpenGL to be loaded dynamically as DLL because implementation is provided by the system but no need with Angle.
Only 2 files need modification and it shouldn't affect current behaivor:
include/SDL_egl.h and src/video/SDL_egl.c, as in here
https://github.com/native-toolkit/sdl/pull/10/files
The flag name could be SDL_VIDEO_STATIC_ANGLE (instead of NATIVE_TOOLKIT_STATIC_ANGLE) as discussed here https://github.com/native-toolkit/sdl/pull/10
We have tested this with both Windows and UWP, using NME engine (https://github.com/haxenme/nme).
Releated issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1820
Sylvain
Hi! here's a patch for that with two class loaded regarding API level.
Test both case : before API 11 and after.
I also remove now unused GetSystemServiceFromUIThread() and minor clean-up (haptic warning prototype).
This fixes a strange corner case (notes appended below), and should be
safe to do anyhow.
Fixes Bugzilla #3674.
"I did more tests.
It appears the bug only happens if there is
another window on the screen that has "always
on top" property. For me it is xawtv - it is
always opened in a screen corner. Closing
xawtv or removing "always on top" property
from it makes the problem to go away.
Plus, it doesn't appear like the buttons are
not delivered at all. It appears that instead
the button presses are delivered on some mouse
positions, but not delivered when you move the
mouse to other part of the window... So this is
really weird and is likely somewhere deep in the
Xorg.
Maybe somehow it happens that the cursor is
actually above the xawtv window, but, because
my app uses grab, it is not visible there, and
in that case the events are not delivered to
my app?
But with my patch the button events are
always delivered flawlessly, it seems.
Hmm, and that indeed seems to explain my problem:
if the mask is set properly and my app uses
grab, then, even if the mouse is above some
other window, the events would still be delivered
to the grabbing app, which is what actually wanted
because my app uses relative mouse mode, so it
doesn't know the pointer can cross some other window
(my app draws the pointer itself).
So my current theory is that my patch only enforces
the mouse grab, which otherwise can be tricked by
some other window preventing the button events
delivery (but motion events are still delivered
via xinput2, which makes it all look very obscure)."
This patch was originally written by Marc Di Luzio for glX and enhanced by
Maximilian Malek for WGL, etc. Thanks to both of you!
Fixes Bugzilla #3643.
Fixes Bugzilla #3735.
Pegasus Epsilon
With the system dialog font set to Arial or Tahoma or another variable-width font, everything works just as expected. When using a fixed-width font, like Courier or DejaVu Sans Mono, the text gets cut off. Example screenshots attached.
Martijn Courteaux
I implemented precise scrolling events. I have been through all the folders in /src/video/[platform] to implement where possible. This works on OS X, but I can't speak for others. Build farm will figure that out, I guess. I think this patch should introduce precise scrolling on OS X, Wayland, Mir, Windows, Android, Nacl, Windows RT.
The way I provide precise scrolling events is by adding two float fields to the SDL_MouseWheelScrollEvent datastructure, called "preciseX" and "preciseY". The old integer fields "x" and "y" are still present. The idea is that every platform specific code normalises the scroll amounts and forwards them to the SDL_SendMouseWheel function. It is this function that will now accumulate these (using a static variable, as I have seen how it was implemented in the Windows specific code) and once we hit a unit size, set the traditional integer "x" and "y" fields.
I believe this is pretty solid way of doing it, although I'm not the expert here.
There is also a fix in the patch for a typo recently introduced, that might need to be taken away by the time anybody merges this in. There is also a file in Nacl which I have stripped a horrible amount of trailing whitespaces. (Leave that part out if you want).
manuel.montezelo
Original bug report (note that it was against 2.0.0, it might have been fixed in between): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733015
--------------------------------------------------------
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch
I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number (> 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.
Attached is a possible workaround patch.
Please also keep in mind that fd_set are also used in following files which
may have similar problems.
src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c
--------------------------------------------------------
On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
> I have occasional crashes here caused by the X11 backend of SDL2. It seems
> to be caused by the X11_Pending function trying to add a high number (>
> 1024) file descriptor to a fd_set before doing a select on it to avoid busy
> waiting on X11 events. This causes a buffer overflow because the file
> descriptor is larger (or equal) than the limit FD_SETSIZE.
I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.
Martin Gerhardy
just for easier debugging issues in the own code...
SDL_CreateRenderer should maybe also use this macro
Ryan C. Gordon
I'll go one better: it should have an SDL_assert().
Leonardo
Structure SDL_gestureTouch gets reallocated for every new added gesture but its never freed.
Proposed patch add the function SDL_GestureQuit() that takes care of doing that and gets called when TouchQuit is called.
Gabriel Jacobo
Thanks for the patch. I think it needs a bit of extra work though, looking at the code in SDL_gesture.c , I see that SDL_numGestureTouches only goes up, I think the right fix here involves adding SDL_GestureDelTouch (hooked into SDL_DelTouch) as well as SDL_GestureQuit (as you posted in your patch).
Rainer Deyke
I've written a small patch that adds a small SDL_DuplicateSurface function to SDL. I've written the function as part of a larger (as yet unfinished) patch, but I think this function is useful enough that it merits inclusion in SDL on its own.
Alvin
I'm interested in this bug as well. I have experienced it when trying to embed an SDL_Window into a FLTK application. To do this, I create a FLTK window (window inside a window - think video player) and then use SDL_CreateWindowFrom() on the inner most window's Xlib Window*. After which, I create a renderer.
In my situation I am using the FLTK GUI toolkit.
What I have experienced is that the SDL_CreateRender() will recreate the window in order to properly setup OpenGL capability. As part of this process, the window is hidden and a call is executed that waits indefinitely for an acknowledgement that the window was indeed unmapped. This is where my program hangs.
Please correct me if I am wrong, but should SDL2 not make Xlib calls that effect the Xlib Window in this situation (e.g. When SDL_CreateWindowFrom() is used)? The toolkit being used typically assumes responsibility and, I presume, tracks all Xlib Windows it creates.
On line src/video/SDL_video.c:1372 the comment associated with setting SDL_WINDOW_FOREIGN reads:
/* Can't destroy and re-create foreign windows, hrm */
Since I do not know the reason for hiding the window in the first place, the attached patch simply does not wait for a response when X11_XWithdrawWindow() and X11_XMapRaised() are issued by X11_HideWindow() and X11_ShowWindow(), respectively. I presume that the GUI toolkit (GTK, FLTK, etc.) has or will consume the acknowledging event as it is managing the Xlib Window (or it thinks it is).
I have tested the patch against hg 5c645d037de2 and I have successfully tested:
* Embedding the SDL_Window inside a FLTK application.
* Calling SDL_SetWindowSize() when FLTK resizes the window (e.g. dragging cursor on the edge of the window).
* Filling the renderer's default target blue and drawing a red fill square at the centre (exciting, I know!)
* Calling SDL_Quit() when the application terminates
I do not receive any Xlib erorr messages (BadWindow, etc.) in any of those situations.
UX-admin
I am compiling with the Sun Studio 12 u2 compiler. There are multiple issues with the build, but this particular issue appears to be that it is illegal to declare a union of a struct of floats and a float. While GCC 4.8.1 does not flag this as an error, Sun Studio is much more standards compliant and strict, halting further compilation with an error.
afwlehmann
Sorry for re-opening, but it turns out that the current interval is indeed not updated. I've just checked the source code of the 2.0.3 release again:
163 if (current->canceled) {
164 interval = 0;
165 } else {
166 interval = current->callback(current->interval, current->param);
167 }
168
169 if (interval > 0) {
170 /* Reschedule this timer */
171 current->interval = interval; // <-- this line is missing
172 current->scheduled = tick + interval;
173 SDL_AddTimerInternal(data, current);
174 } else {
According to the documentation: "The callback function is passed the current timer interval and the user supplied parameter from the SDL_AddTimer() call and returns the next timer interval. If the returned value from the callback is 0, the timer is canceled."
If I understand the text correctly, then the current interval should in fact be updated according to the returned value. Otherwise there would be a discrepancy between the next time for which the timer is actually re-scheduled and the value that's passed to the callback once the timer fires again.
This could be fixed by adding line #171.
Ozkan Sezer
The attached patch removes SDLCALL attribute from SDL_BlitFunc() funcptr.
As far as I can see, *SDL_BlitFunc() is completely internal to SDL with
no specific calling convention requirements. The actual functions assigned
to SDL_BlitFunc seem to not have any calling conventions specified. So,
easy solution is simply removing the strict calling convention from the
type.
Sylvain
Here's a patch.
It tries to get the hint first. Resizable will allow any orientation. Otherwise it uses width/height window.
setOrientation method is splitted in static and non-static, so that it can be overloaded in a user subclass.
Some artefact observed :
surfaceChanged() can be called twice at the beginning. When the phone starts in portrait and run a landscape application.
Clayton Craft
linux_input module is disabled by default, despite the comments in source code that it is otherwise:
src/video/directfb/SDL_DirectFB_video.c:
devdata->use_linux_input = readBoolEnv(DFBENV_USE_LINUX_INPUT, 0); /* default: on */
src/video/directfb/SDL_DirectFB_video.h:
#define DFBENV_USE_LINUX_INPUT "SDL_DIRECTFB_LINUX_INPUT" /* Default: on */
When using the directfb driver, the linux_input module is suppressed unless the SDL app is started with "SDL_DIRECTFB_LINUX_INPUT=1" set in the environment. I recall seeing at one point that the directfb folks recommended using linux_input over the other input drivers, but I am having trouble locating this recommendation. In any case, I believe that this should really be defaulted to 'on' since it's vastly superior to the other dfb input drivers!
Jimb Esser
Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...). XInput does not seem to have the problem below, only DirectInput.
I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3. Direct Input shows them as having GUIDs G1, G2, G3. I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2! Not so "unique"... I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3. Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened! So I end up with two instances of J3 opened, and none of J1. "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this. This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)).
The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks. GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed. This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened). If your app only ever opens one joystick, this will do more work at startup than it did previously.
Jonas Kulla
This eliminates the need to manually compile in SDL_main_android.c.
Instead, add "-lSDL2main -Wl,-u,SDL_main_dummy" when linking.
I don't know how the nkd-build process works, but unless it was
for some reason linking libSDL2main.a it should be unaffected.
Alexey
Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.
Edward Rudd
Device: Logitech Rumble Gamepad F510 in Xinput mode.
Upon opening the joystick the values of the axes are queried via PollAllValues are not actually set on the device all the time.
This can easily be seen in the testjoystick or testgamecontroller test programs,as the testjoystick shows all axes in the center until one 'tickles' the triggers., and the testgamecontroller will show the triggers as 'on' until on 'tickles' the triggers.
Upon further research the culprit is the SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS hint. In the default value events are ignored until there is an active window, Thus in cases where the joystick system is initialized and controllers opened before the initial window is created & focuses, the initial values will be incorrect.
Here is my current workaround in the game I'm working on porting..
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "1");
SDL_GameController* gamepad = SDL_GameControllerOpen(index);
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "0");
Edmund Horner
When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency. If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels. It may not blit correctly, because the colour key does not match the right pixels.
In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82. Blitting the converted image did not use transparency where expected.
I have attached a test case. The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).
malferit
Hello, I began a little program with SDL2 on Linux in C, and when I call SDL_Init(SDL_INIT_VIDEO) I get an error and this is printed in the console:
XDM authorization key matches an existing client!
I searched through Internet, and found that some people suggest to run 'xhost +' or to specify this in /etc/X11/xdm/xdm-config:
DisplayManager*authName: MIT-MAGIC-COOKIE-1
I don't think an end user needs to know that...
But what bothered me is that first I started this little program in Pascal using the Freepascal compiler and it works. In freepascal you only use some thin header bindings in Pascal and then it links with the dynamic SDL library, so I don't understood why it worked with Freepascal and not in C.
I run ldd to the two generated applications:
Application in C:
linux-gate.so.1 (0xffffe000)
libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb76ac000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb766e000)
libc.so.6 => /lib/libc.so.6 (0xb74e2000)
libm.so.6 => /lib/libm.so.6 (0xb74a0000)
libdl.so.2 => /lib/libdl.so.2 (0xb749a000)
librt.so.1 => /lib/librt.so.1 (0xb7491000)
/lib/ld-linux.so.2 (0xb77b3000)
Application compiled with Freepascal:
linux-gate.so.1 (0xffffe000)
libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb762a000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb74f3000)
libc.so.6 => /lib/libc.so.6 (0xb7367000)
libm.so.6 => /lib/libm.so.6 (0xb7325000)
libdl.so.2 => /lib/libdl.so.2 (0xb731f000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7305000)
librt.so.1 => /lib/librt.so.1 (0xb72fc000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72dc000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb72d9000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb72d3000)
/lib/ld-linux.so.2 (0xb7755000)
It seems that Freepascal is linking with libX11, libxcb, libXau and libXdmcp .
Linking my C application with libxcb solved the problem (linking with libXau and/or libXdmcp without libxcb didn't work). Linking with X11 links all the other libraries and works as well.
So I fill this bug report mainly to let you know about this. I don't know if it is a problem that can be solved on the libSDL side or not, but at least I hope it will help.
Hi, some tests:
1. Disabled XDM. Login in console and running 'startx'. The program works without having to link with X11.
2. Enabled XDM. Added 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' to /etc/X11/xdm/xdm-config.The program works without having to link with X11.
3. Enabled XDM without 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' in /etc/X11/xdm/xdm-config . I get the authentication error unless I link with X11.
Coriiander
There's a slight mistake in the function "GetWindowStyle" found in file "SDL_windowswindow.c".
When a window is marked to be resizable, the resizable style is being added regardless of whether the window has a border or not. While for some arcane, hidden semantics this can be ok, it's still inconsistent in this case.
Witek Jachimczyk
I'm using SDL to develop a video viewer for MATLAB. The window is scrambled while using thightVNC with its default mode of RGB656.
SDL does not correctly recognize the pixel mode.
I found a solution for this problem. The solution involves modifying
SDL/src/video/SDL_pixels.c
Adding the following "if statement" under case 16: of SDL_MasksToPixelFormatEnum resolves the issue:
if (Rmask == 0x003F &&
Gmask == 0x07C0 &&
Bmask == 0xF800 &&
Amask == 0x0000) {
return SDL_PIXELFORMAT_RGB565;
}
I hope that this helps someone. I took me a while to figure it out.
Yann Dirson
When SDL_GL_GetProcAddress returns in error, the cause of the error is overwritten
in GL_GL_GetAttribute, reporting to the user "Failed getting OpenGL glGetString entry point", whereas the original "OpenGL library not loaded" never makes it
to the user.
Pushed a fix to:
f94cb13708
Note that the "OpenGL library not loaded" error looks like no root cause either,
and I'm still puzzled by the code path used: I'm forcing opengles2 renderer on
the x11 video driver on a rpi2, as in https://bugzilla.libsdl.org/3169, and although I now know that I must force the use of the RPI video driver instead
of the x11 one, I suspect even more accurate info can be given to user.
Daniel Gibson
AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ?, &, ?", ', (, -, ?_, ??), = (with small differences between the France and Belgian variants). Numbers are reached via shift.
On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ?232 for ?tc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.
So we have two problems:
1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)
It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?
This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).
Sylvain
Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation.
When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255).
I think SDL_ConvertSurface should strictly keeps the input format.
example
=======
SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod
SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags);
// "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).
Simon Hug
The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.
The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.
Adam M.
The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued".
For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key.
If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT).
You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event.
Not only is it inconsistent with itself, I think it makes keyboard processing harder.
The problem is near line 740 in SDL_keyboard.c:
if (SDL_KEYDOWN == type) {
modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN?
switch (keycode) {
case SDLK_NUMLOCKCLEAR:
keyboard->modstate ^= KMOD_NUM;
break;
case SDLK_CAPSLOCK:
keyboard->modstate ^= KMOD_CAPS;
break;
default:
keyboard->modstate |= modifier;
break;
}
} else {
keyboard->modstate &= ~modifier;
modstate = keyboard->modstate;
}
In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.
owen
I removed all the static variables from SDLActivity.java
Updated all the SDL_android.c jni calls as well
I added a new function to SDL_android.c/ h
void Android_JNI_SeparateEventsHint(const char* c);
This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.
Philipp Wiesemann
There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.
Ian Abbott
I just spotted what I think is a bug in "src/thread/pthread/SDL_sysmutex.c" in the SDL_TryLockMutex function when FAKE_RECURSIVE_MUTEX is defined (for an implementation of Pthreads with no recursive mutex support). It calls pthread_mutex_lock instead of pthread_mutex_trylock, so it will block until the mutex is available instead of returning SDL_MUTEX_TIMEDOUT if it cannot lock the mutex immediately.
Coriiander
Here is a minor correction for a non-breaking mistake in SDL_setenv for __WIN32__ platform. See below for details.
FILE:
"SDL/src/stdlib/SDL_getenv.c"
FUNCTION: (__WIN32__ platform)
int SDL_setenv(const char *name, const char *value, int overwrite)
CODE:
if (!overwrite) {
char ch = 0;
const size_t len = GetEnvironmentVariableA(name, &ch, sizeof (ch));
if (len > 0) {
return 0; /* asked not to overwrite existing value. */
}
}
WHAT'S WRONG:
The 3th argument to GetEnvironmentVariable (being DWORD nSize) must be the number of characters, not the number of bytes. SDL currently passes "the size of 1 char", rather "1". While it is non-breaking (1=1 after all), it is incorrect. Furthermore there is no need to specify the 2nd and 3th arguments at all.
CORRECTION 1: (corrected argument_
if (!overwrite) {
char ch = 0;
const size_t len = GetEnvironmentVariableA(name, &ch, 1);
if (len > 0) {
return 0; /* asked not to overwrite existing value. */
}
}
CORRECTION 2: (stripped of unneeded code)
if (!overwrite) {
if (GetEnvironmentVariableA(name, NULL, 0) > 0) {
return 0; /* asked not to overwrite existing value. */
}
}
Juha Niemim?
On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.
Littlefighter19
When trying to mirror something on the PSP, I've stumbled upon the problem,
that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally.
Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c
romain.lacroix
For the windows implementation of SDL_ShowMessageBox() : ./src/video/windows/SDL_windowsmessagebox.c:345 WIN_ShowMessageBox()
The implementation in 2.0.4 uses "button index" for parameter "id" of function AddDialogButton().
It then expects the value provided in param wParam of function MessageBoxDialogProc() to be a valid index of a button.
It uses this value to index in the array of buttons when DialogBoxIndirect() returns (line 474 : *buttonid = buttons[which].buttonid;)
However, when dismissing this box with Escape, the return value of DialogBoxIndirect will be SDL_MESSAGEBOX_BUTTON_ESCAPEKEY_DEFAULT (=2) which is not always a valid index of array buttons.
When the array buttons has a length less or equal than 2, the memory access is invalid; I can see that the value written to *buttonId is uninitialized memory (random value).
The fix I propose : use value "buttonid" (field of button) for parameter "id" of AddDialogButton(), then copy return value of DialogBoxIndirect() in *buttonid. This way, we will not use an out-of-bounds index in array buttons.
Simon Hug
The RGBA_FROM_PIXEL macro in src/video/blit.h [1] is not designed to work with more than 8 bits per channel and the ARGB2101010 format makes it read outside of the array bounds causing access violations. This can happen during blitting with the BlitNtoNPixelAlpha and SDL_Blit_Slow functions.
When SDL_InitFormat tries to calculate the loss of the channels [2], the Uint8 will wrap around and it will end up at 254 for the 10-bit channels. Clearly way over the 9 entries of the SDL_expand_byte array. (Not that a signed integer would help.) Then the macro tries to access the lookup table with the channel value which could be up to 1023. If the previous indirection didn't cause an access violation this one will.
I guess it's not worth modifying this macro for a format that only a few will use. It will only make the other blitters slower. I don't have good ideas to solve this issue.
Attached is a test case that does three blits. A copy one that work and the two that use the functions mentioned above.
[1] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_blit.h#l303
[2] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_pixels.c#l540
Daniel
SDL_RenderReadPixels with SDL_RENDERER_SOFTWARE reads pixels from wrong coordinates.
SW_RenderReadPixels adjusts the rect coordinates according to the viewport. But since this is already done by SDL_RenderReadPixels, the final rect has x2 bigger X and Y.
Fabian Greffrath
we use SDL_GetPrefPath() in Chocolate Doom to get a reasonable directory to save and restore config files and savegames:
https://github.com/chocolate-doom/chocolate-doom/blob/sdl2-branch/src/m_config.c#L2162
However, since there is no "organization" behind Chocolate Doom and there is really only one "product" called Chocolate Doom, we pass an empty string for the org parameter and the package string for app.
This leads to two consecutive slashes in the path returned by SDL_GetPrefPath() like this:
/home/user/.local/share//chocolate-doom/
While this is harmless, it sure looks bad.
I believe that it should be possible to either pass a NULL pointer for the org parameter or at least have the function detect an empty string as a means to express "there is no origanization, just a single product". The generation of the path string to be returned by the function will have to get adapted accordingly.
Eric Wasylishen
Alt-Up/Down/Left/Right switches between displays using SDL_WINDOWPOS_CENTERED_DISPLAY
Shift-Up/Down/Left/Right shifts the window by 100px
Simon Hug
Some code in SDL loads libraries with SDL_LoadObject to get more information or use newer APIs. SDL_LoadObject may fail, set an error message and SDL will continue with some fallback code. Since SDL will overwrite the error or exit the function with a return value that indicates success, the error form SDL_LoadObject for the optional stuff might as well be cleared right away.
Eric Wasylishen 2017-07-26 18:42:58 UTC
I set up an (admittedly exotic) 3-monitor setup, and when I enter fullscreen-desktop on the middle display (#2), the SDL window is off center. (covers half of monitor #2 and most of monitor #3).
The displays are arranged from left to right:
Display #1 (main): 2880x1800, 200% scaling
Display #2: 1920x1200, 150% scaling
Display #3: 1920x1080, 100% scaling
SDL display bounds:
INFO: Bounds: 1440x900 at 0,0
INFO: Bounds: 1281x801 at 1921,0 (these are incorrect)
INFO: Bounds: 1920x1080 at 4800,0
Correct bounds reported by calling EnumDisplayMonitors and printing the LPRECT param of the callback:
1440x900 at (0, 0)
1280x800 at (2880, 0)
1920x1080 at (4800, 0)
It seems like you need 3 displays to reproduce this, and the left two need DPI scaling, and the 3rd display needs to have a different scale factor than the others.
Related: https://bugzilla.libsdl.org/show_bug.cgi?id=3709
SDL: current hg (11235:6a587b9e0ec8)
Windows 10, Version 10.0.15063 Build 15063
Tested with testdraw2 and testgl2, and pressing alt+enter to enter fullscreen desktop.
This patch reworks SDL_windowsmodes.c to use EnumDisplayMonitors instead of EnumDisplayDevices, so we always have an HMONITOR for each SDL display.
With access to an HMONITOR, we can get the monitor bounds in virtual screen coordinates the proper way, by calling GetMonitorInfo. (whereas the original code was doing some calculations - e.g. "data->DeviceMode.dmPosition.x * data->ScaleX" - to try to get virtual screen coordinates. These worked in simple cases, but failed in more complex cases like this bug)
The one potential problem with my patch is, the ChangeDisplaySettingsEx docs say that you're supposed to get the display name from EnumDisplayDevices, but I'm getting the display name from GetMonitorInfo now.
Simon Hug
KMSDRM_VideoInit allocates and frees some connectors and encoders but doesn't set the pointer to NULL after freeing. The cleanup code at the end may free one of those garbage pointer should an error happen in the initialization.
Simon Hug
When WIN_WindowProc processes the WM_TOUCH message, it doesn't check if the touch functions have been properly loaded and may call a NULL pointer. It's probably an extremely rare case, but here's a patch that adds some checks anyway.
Eric wing
Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark.
I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template.
Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part).
When you click/touch, it will draw one more happy face where your button point is.
If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.)
Alex Szpakowski on the mailing list suggests the problem is
"I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)."
Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".
Levi Bard
In some environments, xrandr modes initialization can fail even though xrandr support is present and of a sufficient version.
(The one I encountered was an AWS instance running a virtual display)
The attached patch allows SDL to keep trying other methods if xrandr modes initialization fails (still subject to SDL_VIDEO_X11_REQUIRE_XRANDR).
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
Now the clipboard isn't lost if you destroy a specific SDL_Window, as it
works on other platforms. You will still lose the clipboard data on
SDL_Quit() or process termination, but that's X11 for you; run a
Clipboard Manager daemon.
Fixes Bugzilla #3222.
Fixes Bugzilla #3718.
Eric Wasylishen
I think I found a better fix.
The problem with https://hg.libsdl.org/SDL/rev/ebdc0738b1b5 is setting the styleMask to 0 clears the NSWindowStyleMaskFullScreen bit, which then confuses Cocoa later when you try to leave fullscreen. Instead I'm just clearing the NSWindowStyleMaskResizable bit, although SetWindowStyle(window, NSWindowStyleMaskFullScreen); seems to also work.
Eric Wasylishen
Unfortunately this commit seems to have broken exiting desktop-fullscreen.
- Launch testgl2.
- Press alt+enter to go fullscreen-desktop
- Press alt+enter again. The spinning cube will freeze, and the window stays fullscreen desktop.
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.
Jason Wyatt
After hiding the window, SDL_WINDOW_HIDDEN/SDL_WINDOW_SHOWN flags on a window are correctly updated. However on the next SDL_PumpEvents, they are set incorrectly.
This appears to be because X11_GetNetWMState does not check whether the _NET_WM_STATE property exists (it shouldn't on unmapped windows, see https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336). This results in an empty list of atoms for the state, which would imply that the window is not hidden.
(Seen on Fedora 24, Gnome)
--
Dan Ginsburg
More details on my proposed patch: I am on Kubuntu 16.04.2. I ran into this same bug, but with Jason's patch I found that actualType != None was true so the SDL_WINDOW_HIDDEN would still not be set. My fix instead is to explicitly check for whether the window is unmapped rather than relying on the returned values in XGetWindowProperty.
felix
The functions in src/render/SDL_yuv_mmx.c contain the following inline assembly snippet:
/* tap dance to workaround the inability to use %%ebx at will... */
/* move one thing to the stack... */
"pushl $0\n" /* save a slot on the stack. */
"pushl %%ebx\n" /* save %%ebx. */
"movl %0, %%ebx\n" /* put the thing in ebx. */
"movl %%ebx,4(%%esp)\n" /* put the thing in the stack slot. */
"popl %%ebx\n" /* get back %%ebx (the PIC register). */
Here's how it ended up in a binary on my old laptop:
0xb5c17dbd <ColorRGBDitherYV12MMX1X+93>: push $0x0
0xb5c17dbf <ColorRGBDitherYV12MMX1X+95>: push %ebx
0xb5c17dc0 <ColorRGBDitherYV12MMX1X+96>: mov 0xc(%esp),%ebx
0xb5c17dc4 <ColorRGBDitherYV12MMX1X+100>: mov %ebx,0x4(%esp)
0xb5c17dc8 <ColorRGBDitherYV12MMX1X+104>: pop %ebx
Apparently the compiler, oblivious to the fact that the assembly snippet manipulates the %esp register, decided to refer to the operand via that same register instead of via %ebp (I believe -fomit-frame-pointer enables this). This causes %ebx to be loaded with the wrong value, which later leads to a null pointer dereference.
Recent GCC can use the %ebx register normally: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602#c16>. There is even an explicit constraint "b" for allocating it.
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").
kdrakehp
The attached patch adds capture support to the sndio backend.
The patch also allows the `OpenDevice' function to accept arbitrary device names.
Bogomancer
On X11, windows created using the shaped window API appear distorted unless the width of the shape surface is divisible by 8.
Steps to reproduce:
1) Use your favorite image editor to resize one of the images in test/shapes/ to a width that's not a multiple of 8.
2) Compile and run test/testshape.c on the image you edited.
3) The shaped window will appear twisted and distorted.
It appears the bug was not caught sooner because all the test images are either 640 or 256 pixels wide.
I tracked down the bug to SDL_CalculateShapeBitmap() in SDL_shape.c. The shape surface is reduced to a 1-bit-per-pixel mask, but the original code doesn't take into account that X11 apparently wants each scanline to begin on a new byte.
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/7213ae46e870 ...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.)
Mark Callow
SDL_ShowMessageBox calls SDL_CaptureMouse which, in the UIKit driver, raises a ?That operation is not supported? error, overwriting the SDL error that an application may be trying to report.
This is because UIKit SDL_CaptureMouse returns SDL_Unsupported() which ends up calling SDL_SetError() which has the following code:
/* If we are in debug mode, print out an error message */
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", SDL_GetError());
The SDL_GetError call here overwrites the static buffer?..
Although an application can avoid this by using SDL_GetErrorMsg(char* errstr, int maxlen) to avoid the static buffer, SDL should be fixed.
The fix is simple. In SDL_SetError change
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", SDL_GetError());
to
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", error);
where error is the pointer to the buffer where it assembled the message.
Amruth Raj
- My app runs in full screen to play video(I use SDL_WINDOW_FULLSCREEN_DESKTOP)
- Cmd-tab to go out of full screen to another app
- Cmd-tab again to get back to my app
- Press left mouse button at one of the edges of the screen, don't release yet.
After this point the main thread is stuck until I release the left mouse button and hence video rendering doesn't happen anymore.
On debugging more, I see that thread 0 is stuck as shown below with sendEvent processing left mouse down. It comes out only after it receives a left mouse up. There are some frames below which show NSWindowResizing, but my window flag doesn't have SDL_WINDOW_RESIZABLE set.
Thread 0:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fffbe13d34a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fffbe13c797 mach_msg + 55
2 com.apple.CoreFoundation 0x00007fffa889d434 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fffa889c8c1 __CFRunLoopRun + 1361
4 com.apple.CoreFoundation 0x00007fffa889c114 CFRunLoopRunSpecific + 420
5 com.apple.HIToolbox 0x00007fffa7dfdebc RunCurrentEventLoopInMode + 240
6 com.apple.HIToolbox 0x00007fffa7dfdcf1 ReceiveNextEventCommon + 432
7 com.apple.HIToolbox 0x00007fffa7dfdb26 _BlockUntilNextEventMatchingListInModeWithFilter + 71
8 com.apple.AppKit 0x00007fffa6396a54 _DPSNextEvent + 1120
9 com.apple.AppKit 0x00007fffa6b127ee -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
10 com.apple.AppKit 0x00007fffa66f568d +[NSWindow(NSWindowResizing) _mouseHysteresisCheck:withExpiration:andDistance:finalMouseLocation:] + 525
11 com.apple.AppKit 0x00007fffa65eedb5 -[NSWindow(NSWindowResizing) _hitTestWithHysteresisCheck:forEvent:allowWindowDragging:] + 394
12 com.apple.AppKit 0x00007fffa6c8f0db -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 1873
13 com.apple.AppKit 0x00007fffa6c8ca6c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 1942
14 com.apple.AppKit 0x00007fffa6c8bf0a -[NSWindow(NSEventRouting) sendEvent:] + 541
15 org.libsdl.SDL2 0x000000010d46d74a -[SDLWindow sendEvent:] + 90
16 com.apple.AppKit 0x00007fffa6b10681 -[NSApplication(NSEvent) sendEvent:] + 1145
17 org.libsdl.SDL2 0x000000010d46532b -[SDLApplication sendEvent:] + 139
18 org.libsdl.SDL2 0x000000010d466b2f Cocoa_PumpEvents + 495
19 org.libsdl.SDL2 0x000000010d44c1d5 SDL_PumpEvents_REAL + 53
20 org.libsdl.SDL2 0x000000010d44c2f5 SDL_WaitEventTimeout_REAL + 53
21 org.libsdl.SDL2 0x000000010d44c2b7 SDL_PollEvent_REAL + 23
22 org.libsdl.SDL2 0x000000010d51bb24 SDL_PollEvent + 36
23 libTest.dylib 0x000000010cf3e0e8 SDLEventProcessor::processEvents(int) + 568
24 Test 0x000000010cde6bba BrowserApp::RunAppMessageLoop(BAInstData*, CefStringBase, CefStringBase) + 810
25 Test 0x000000010ce04bbc main + 17980
26 libdyld.dylib 0x00007fffbe016235 start + 1
I further noticed that while entering full screen in SDL_cocoawindow.m NSResizableWindowMask is set. If I clear it inside windowDidEnterFullScreen, then, the issue doesn't repro.
This is discussed at https://discourse.libsdl.org/t/main-thread-gets-stuck-on-left-mouse-down/22753/3 and thanks to Eric for the pointers.
The Xlib documentation demands that 32-bit values here be passed in a long,
even when long itself isn't a 32-bit value. Otherwise libx11 might read
memory incorrectly.
Fixes Bugzilla #3692.
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.
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).
Failing to check if a key was known to be pressed by SDL was causing
SDL_SendKeyboardKey to send duplicate key pressed events with the repeat
property set to true.
Fixes Bugzilla #3637.
The message sent upon the window being activated or deactivated, to trigger
the call to SDL_SetKeyboardFocus was missing a mandatory parameter. So
keyboard focus was never properly set.
Fixes Bugzilla #3658.
We don't fill buffers just to throw them away during shutdown now, we let the
AudioQueue free its own buffers during disposal (which fixes possible warnings
getting printed to stderr by CoreAudio), and we stop the queue after running
any queued audio during shutdown, which prevents dropping the end of the
audio playback if you opened the device with an enormous sample buffer.
Fixes Bugzilla #3555.
We need more than two buffers to flip between if they are small, or CoreAudio
won't make any sound; apparently it needs X milliseconds of audio queued when
it needs to play more or it drops any queued buffers. We are currently
guessing 50 milliseconds as a minimum, but there's probably a more proper
way to get the minimum time period from the system.
Fixes Bugzilla #3656.
"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
If an Emscripten app is in relative mouse mode and the user presses Escape
(or whatever is appropriate), then the pointer lock is broken by the browser.
This keeps track of those losses, and next time the user presses a mouse
button down on the canvas, if the app is still meant to be in relative mouse
mode, we will attempt to regrab the pointer.
This makes it much more seamless for things like first-person shooters, and
the app doesn't need any manual intervention.
Samuel Hopkins
Just confirming that the patch from Andreas (attachment 1715 [details]) works for me under SDL 2.0.3 with xmonad.
Stas Sergeev
Confirming that the patch in this ticket fixes the full-screen switching for dosemu2 on ubuntu-16.04. Note that I am not using xmonad, so this bug appears to be generic.
This gracefully recovers when a device format is changed, and will switch
to the new default device if the current one is unplugged, etc.
This does not handle when a new default device is added; it only notices
if the current default goes away. That will be fixed by implementing the
stubbed-out MMNotificationClient_OnDefaultDeviceChanged() function.
"ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]"
Moving some variable declarations to the top of Android_SetScreenResolution()
* alsa hotplug thread is low priority
* give a chance for other threads to catch up when audio playback is not progressing
* use nonblocking for alsa audio capture
There is a bug with SDL hanging when an audio capture USB device is removed, because poll never returns
We will throw away the data anyhow, but some apps depend on the callback
firing to make progress; testmultiaudio.c, if nothing else, is an example
of this.
Capture also will now fire the callback in these conditions, offering nothing
but silence.
Apps can check SDL_GetAudioDeviceStatus() or listen for the
SDL_AUDIODEVICEREMOVED event if they want to gracefully deal with
an opened audio device that has been unexpectedly lost.
This is just enough to get you through a file that just used the extended
header for float or int data. It doesn't handle all the other things that
you expect from this header, like 24-bit samples inside a 32-bit container
or speaker masks.
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.
Like other C runtimes, it should probably produce the string "(null)".
This bug probably only affected Windows, as most platforms use their standard
C runtime's snprintf().
Walter van Niftrik
We have found that since SDL 2.0.5 the audio callback thread is created with a very small stack size. In our application this is leading to stack overflows.
We believe there is a bug at http://hg.libsdl.org/SDL/file/391fd532f79e/src/audio/SDL_audio.c#l1132, where the is_internal_thread flag appears to be inverted.
Volumetric
In X11 the SDL error "Unknown touch device" can occur after which the application stops recognizing touch events. For a kiosk-type application this results in a hang as far as the user is concerned. This is reproducible on HP Z220/Z230/Z240 workstations by swapping USB cables for a while and it also occurs with no physical changes, probably due to USB device power management. A workaround is to make SDL re-enumerate the touch devices like it does at startup. A patch is attached.
Matthew
Its possible to set SDL_CaptureMouse() so you continue receiving mouse input while the mouse is outside your window. This works however There is then a gap where no messages send, which is when the mouse is hovering the title bar and the window edges.
X11 seemed to be confused by the broad definition, so WEIGHT_NAME,
SLANT and SETWIDTH_NAME were defined, thus fixing the font lookup
on some systems (tested on Mageia 6 with X11 1.19.1).
Fixes bug 3571.
Tom Seddon
GL_ActivateRenderer may call GL_UpdateViewport, which leaves the GL_PROJECTION matrix selected. But after GL_ResetState, the GL_MODELVIEW matrix is selected, suggesting that's the intended default state.
It seems at least like these should be consistent. Presumably GL_UpdateViewport should be doing a glMatrixMode(GL_MODELVIEW) before it finishes.
Also updates the naming of these Xbox Wireless Controllers connected via USB (and thus the third-party Xbox Controller Driver) to match.
The Xbox Wireless Controller entries are now listed, in order, via USB, bia Bluetooh (with older firmware) and via Bluetooth (with firmware 3.1.1221.0).
This is a bleeding edge API, added to Windows 10 Anniversary Edition (build
1607, specifically).
https://msdn.microsoft.com/en-us/library/windows/desktop/mt774976(v=vs.85).aspx
Nothing supports this yet, including WinDbg, Visual Studio, minidumps, etc,
so we still need to also use the RaiseException hack. But presumably tools
will use this API as a more robust and universal way to get thread names
sooner or later, so we'll start broadcasting to it now.
Firmware revision 3.1.1221.0 changes the mapping of the Xbox One S
controller in Bluetooth mode. Aside from changing the layout of
other buttons, this revision also changes the triggers to act as
Accelerator and Brake axes from the simulation controls page.
The Darwin sysjoystick code didn't previously map anything at these
axes, making it impossible to detect input on these two buttons.
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.
This currently favors libsamplerate over the fast path (quality over speed),
but I'm not sure that's the correct approach, as there may be surprising
changes in performance metrics depending on what packages are available on
a user's system. That being said, currently, the only thing with access to
SDL_AudioStream is an SDL audio device's thread, and it might be mostly idle
otherwise, so maybe this is generally good.
Turns out that iterating from 0 to channels-1 was a serious performance hit!
These cases now tend to match or beat the original audio resampler's speed!
This allows us to avoid an extra copy, allocate less memory and reduce cache
pressure. On the downside: we have to do a lot of tapdancing to resample the
buffer in reverse when the output is growing.
It's expensive and (hopefully) unnecessary. If this becomes an overflow
problem, we could multiply both values by 0.5f before adding them, but let's
see if we can get by without the extra multiplication first.
We never seem to overflow the source buffer now; this might have been a
leftover from a bug that was covered by Vitaly's fixes?
Removing this conditional makes the resampler 10-20% faster. Left an
assert in there for debug builds, in case this still happens.
white.magic
The logic which decides if a device enumerated via the direct input system in the function EnumJoysticksCallback in SDL_dinputjoystick.c is processed is discarding valid joystick devices due to the assumption that devices of the type DI8DEVTYPE_SUPPLEMENTAL are not valid devices.
This change was added with 2.0.4 with this commit http://hg.libsdl.org/SDL/rev/1b9d40126645 that is linked to this bug report https://bugzilla.libsdl.org/show_bug.cgi?id=2460 which indicates that in that case devices of the type DI8DEVTYPE_SUPPLEMENTAL were not desirable as they caused a singular device to emit multiple "device added" events.
Since then there appear to have been a few fixes to handle devices that fall into various other classes in the following two commits:
http://hg.libsdl.org/SDL/rev/10ffb4787d7a and http://hg.libsdl.org/SDL/rev/6a2bbac05728
Two devices I have reports of failing to be listed when the DI8DEVTYPE_SUPPLEMENTAL type is excluded are ECS Gametric Throttle and Thrustmaster MFD Cougar.
Sam Lantinga
I verified that the OUYA controller shows up as a single device with this change, so I've reverted the change to ignore supplemental devices, leaving framework in place to easily add devices that we want to ignore.
Removed some needless things ("len / sizeof (Uint8)"), and made sure the
int32 -> float code uses doubles to avoid working with large integer values
in a 32-bit float.
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.
Lukasz Biel
Tried to compile SDL2 using newest version of VS.
Got:
SDL_audiocvt.obj : error LNK2019: unresolved external symbol memcpy referenced in function SDL_ResampleCVT
1>E:\Users\dotPo\Lib\SDL\VisualC\x64\Release\SDL2.dll : fatal error LNK1120: 1 unresolved externals
whole compilation process: http://pastebin.com/eWDAvBce
Steps to reproduce:
clone http://hg.libsdl.org/SDL using tortoise hg,
open SDL\VisualC\SDL.sln,
when promted if should retarget solution click ok,
select release x64 build type,
Build/Build Solution
attempt 2, using Visual Studio cmake support:
open folder SDL\
select release x64 build type,
run CMake\Build CMakeLists.txt
build fails
When switched to debug build type, buils succeeds in both cases.
VS 2017 is still beta.
It causes audio pops if you're converting in chunks (and needs to
allocate/initialize/free on each convert). We'll either adjust this interface
when we break ABI for 2.1 to make this usable, or publish the SDL_AudioStream
API for those that want a streaming solution.
In the meantime, the "simple" resampler produces "good enough" audio without
pops and doesn't have to be initialized, so that'll do for now on the
SDL_AudioCVT interface.
K_NORMTAB, K_SHIFTTAB, K_ALTTAB, K_ALTSHIFTTAB
In the normal case we'll load all the keymaps from the kernel, but this reduces the size of the SDL library for the fallback case when we can't get to the tty.
Mark Logan 2015-08-24 15:57:50 UTC
In SDL_windowsopengles.c, WIN_GLES_SetSwapInterval is as follows:
WIN_GLES_SetSwapInterval(_THIS, int interval)
{
/* FIXME: This should call SDL_EGL_SetSwapInterval, but ANGLE has a bug that prevents this
* from working if we do (the window contents freeze and don't swap properly). So, we ignore
* the request for now.
*/
SDL_Log("WARNING: Ignoring SDL_GL_SetSwapInterval call due to ANGLE bug");
return 0;
}
With a recent version of ANGLE (early July) calling SDL_EGL_SetSwapInterval with a D3D11 backend appears to work just fine. I am working on testing this with D3D9.
--
Alex Szpakowski
I found the bug, it was fixed in 2013. https://bugs.chromium.org/p/angleproject/issues/detail?id=481
In my opinion it should be safe to unconditionally use SetSwapInterval now. Anyone who encounters the bug should update their ANGLE to a version less than 3 years old, especially since they'd be using a SDL version that's 3+ years newer than their ANGLE version.
Rob
I've ran into an issue where I successfully receive SDL_KEY[UP,DOWN] events but not SDL_TEXTINPUT or SDL_TEXTEDITING. In my case the code in SDL_EVDEV_do_text_input() is returning early (on error) prior to calling SDL_SendKeyboardText(). I'm running on the RaspberryPi 3, without X11.
In SDL_EVDEV_do_text_input() there is a condition to check keysyms with a type value below 0xf0, then subtract 0xf0 from type. Without understanding the purpose of this code, I disabled it, recompiled, and I'm getting correct SDL_TEXTINPUT events. I'm going to guess that my hack/fix is going to be problematic in some other environment, but after some initial testing it looks like everything is running fine in my setup.
Richard Russell
Resuming from a suspended state results in a black screen. This only happens when using GLES 1.1 (GLES 2 resumes correctly) and when the render target has been changed using SDL_SetRenderTarget. This problem is new in 2.0.4.
The attached test case demonstrates the issue.
Sylvain Becker has apparently found a fix as follows:
"In the opengles leaf function (in 'src/render/opengles/SDL_render_gles.c'), it appears there is a call to 'GLES_ActivateRenderer' in 'GLES_SetRenderTarget', which is not present in opengles2. When commenting out this 'GLES_ActivateRenderer', it seems to resume fine".
This appears to fix the testcase perfectly, but I don't know whether it could have any undesirable side-effects.
tvc
I believe this patch should fix it, instead of looping through all the tty's and seemingly selecting the wrong one and corrupting the console I've just made SDL open /dev/tty which is the console attached to the current process anyway.
felix
Here's a snippet of SDL_DestroyRenderer from hg revision 10746:7540ff5d0e0e:
SDL_Texture *texture = NULL;
SDL_Texture *nexttexture = NULL;
/* ... */
for (texture = renderer->textures; texture; texture = nexttexture) {
nexttexture = texture->next;
SDL_DestroyTexture(texture);
}
SDL_DestroyTexture removes the texture from the linked list pointed to by the renderer and ends up calling SDL_DestroyTextureInternal, which contains this:
if (texture->native) {
SDL_DestroyTexture(texture->native);
}
If it happens that texture->native is an alias of nexttexture two stack frames up, SDL_DestroyRenderer will end up trying to destroy an already freed texture. I've had this very situation happen in dosemu2.
Bug introduced in revision 10650:a8253d439914, which has a somewhat ironic description of "Fixed all known static analysis bugs"...
Rob
When calling ioctl(fd, KDGKBTYPE, &type) in SDL_EVDEV_is_console(), we declare type as an 'int'. This should be a 'char'. The subsequent syscall, and kernel code, only writes the lower byte of the word.
See: http://lxr.free-electrons.com/source/drivers/tty/vt/vt_ioctl.c?v=4.4#L399
ucval = KB_101;
ret = put_user(ucval, (char __user *)arg);
I've observed intermittent behavior related to this, and I can force an error condition by using an int initialized to 0xFFFFFFFF. The resulting ioctl will set type to 0XFFFFFF02, and the conditional return in SDL_EVDEV_is_console() will fail.
Recommend changing to char, or masking off unused bits.
There was a draft of this where it did audio conversion into the final buffer,
if there was enough room available past what you asked for, but that interface
got removed, so the parameters didn't make sense (and we were using the
wrong one in any case, too!).
For example, if sR is 0 and dR is 255, we will get -255*sA casted to an unsigned value. Basically results are quite large numbers instead of the expected 0-255 range.
Fixed a case where partial trigger pull could be bound to another button
There is a fundamental problem not resolved by this commit:
Some controllers have axes (triggers, pedals, etc.) that don't start at zero, but we're guaranteed that if we get a value that it's correct. For these controllers, the current code works, where we take the first value we get and use that as the zero point and generate axis motion starting from that point on.
Other controllers have digital axes (D-pad) that assume a zero starting point, and the first value we get is the min or max axis value when the D-pad is moved. For these controllers, the current code thinks that the zero point is the axis value after the D-pad motion and this doesn't work.
My hypothesis is that the first class of devices is more common and that we should solve for that, and add an exception to SDL_JoystickAxesCenteredAtZero() as needed for the second class of devices.
Ryan C. Gordon
Kristian says you can't do it with Wayland, and that going forward, it'll just handle whatever you throw at it anyhow.
https://twitter.com/hoegsberg/status/816148272402165761
So I say we mark it SDL_PIXELFORMAT_RGB888, which is what my X11 display currently reports, and leave it at that.
kaisyu
In case of OpenGLES, the sequences of loading and unloading driver library should be like that:
SDL_Init
...
SDL_GL_LoadLibrary
SDL_EGL_LoadLibrary
...
SDL_Quit
...
SDL_GL_UnloadLibrary
SDL_EGL_UnloadLibrary
...
However, according to my test results, the varible '_this->gl_config.driver_loaded' does not allow 'SDL_GL_UnloadLibrary' to call 'SDL_EGL_UnloadLibrary'.
Coriiander
This notice is about a misplaced comment.
Often times when we use an #if #endif sequence, the #endif is followed by a comment to indicate what #if statement it belonged to. The SDL_xaudio2.c file contains a misplaced comment, as follows (I stripped the other comments):
#ifdef __GNUC__
# define SDL_XAUDIO2_HAS_SDK 1
#elif defined(__WINRT__)
# define SDL_XAUDIO2_HAS_SDK
#include "SDL_xaudio2.h"
#else
#if 0
#include <dxsdkver.h>
#if (!defined(_DXSDK_BUILD_MAJOR) || (_DXSDK_BUILD_MAJOR < 1284))
# pragma message("Your DirectX SDK is too old. Disabling XAudio2 support.")
#else
# define SDL_XAUDIO2_HAS_SDK 1
#endif
#endif
#endif /* 0 */
That final /* 0 */ should be moved one line up. Like this (I tabbed it out for you to make it more clear):
Tristan
The internal SDL_vsnprintf implementation accesses memory outside buffer. The bug existed also inside the format (%) processing, which was fixed with Bug 3441.
But there is still an invalid access, if we do not have any format inside the source string and the destination string is shorter than the format string. You can use any string for this test, as long it is longer than the buffer.
Example:
va_list argList;
char buffer[4];
SDL_vsnprintf(buffer, sizeof(buffer), "Testing", argList);
The bug is located on the 'else' branch of the format char test:
while (*fmt) {
if (*fmt == '%') {
...
} else {
if (left > 1) {
*text = *fmt;
--left;
}
++fmt;
++text;
}
}
if (left > 0) {
*text = '\0';
}
As you can see that text is always incremented, even when left is already one. When then on the last lines, *text is assigned the NULL char, the pointer is located outside bounds.
Intellectual Kitty
In SDL_video.c, on line #1756, in SDL_SetWindowPosition (from today's distribution, 12-31-2016, https://hg.libsdl.org/SDL/shortlog/bf19e0c84483):
if (displayIndex > _this->num_displays) {
should be:
if (displayIndex >= _this->num_displays) {
felix
Compiling even a simple SDL2 'hello world' program with gcc -Wstrict-prototypes (GCC 6.2.1) results in warnings like:
/usr/include/SDL2/SDL_gamecontroller.h:143:1: attention : function declaration isn't a prototype [-Wstrict-prototypes]
extern DECLSPEC int SDLCALL SDL_GameControllerNumMappings();
^~~~~~
It seems there is a missing 'void' between the parentheses.
This was a leftover of simplifying the resamplers down from autogenerated
code; I forgot to make something that the generator hardcoded into something
variable.
Fixes Bugzilla #3507.
Ozkan Sezer
http://hg.libsdl.org/SDL/rev/464a2676d8ab seems to have
forgotten removing the return from SDL_dynapi_procs.h, and this patch
does that. Without it, MSVC warns:
c:\sdl2\src\dynapi\SDL_dynapi_procs.h(598) : warning C4098:
'SDL_GL_SwapWindow_DEFAULT' : 'void' function returning a value
c:\sdl2\src\dynapi\SDL_dynapi_procs.h(598) : warning C4098:
'SDL_GL_SwapWindow' : 'void' function returning a value
Ozkan Sezer
This adds the name 'ad' to two unnamed unions in edid.h
and adjusts edid-parse.c for it. Nameless unions are not supported in
ancient gcc, which I happened to use on one of my ancient setups.
These fixes are lumped into two categories:
1. add new file, SDL_dataqueue.c, to UWP/WinRT build-inputs (via MSVC project
files)
2. implement a temporary, hack-fix for a build error in SDL_xinputjoystick.c.
Win32's Raw Input APIs are, unfortunately, not available for use in UWP/WinRT
APIs. There does appear to be a replacement API, available in the
Windows.Devices.HumanInterfaceDevice namespace.
This fix should be sufficient to get SDL compiling again, without affecting
Win32 builds, however using the UWP/WinRT API (in UWP/WinRT builds) would
almost certainly be better (for UWP/WinRT builds).
TODO: research Windows.Devices.HumanInterfaceDevice, and use that if and as
appropriate.
This currently doesn't affect absolute motion, which would need to be implemented on each windowing system so the cursor matches the reported mouse coordinates.
Diego
I was previously unaware that rotating the device to a different orientation when the keyboard is shown causes a keyboardWillHide followed by a keyboardWillShow notification. The previous patch would then mistakenly StopTextInput when rotating. This patch fixes that by checking if the device is rotating before stopping text input.
Ozkan Sezer
With rev. 10651, i.e. http://hg.libsdl.org/SDL/rev/747a6a795b21 ,
SDL2 - OS X builds fail to run on 10.6 (my setup: i686 / 10.6.8)
because the symbol _IOPMAssertionCreateWithDescription is missing.
The SDK listing it for 10.7+ does seem correct. Reverting r10651
and rebuilding makes it to function again.
Simon Hug
The SDL_BlitScaled function runs into an access violation for specific blit coordinates and surface sizes. The attached testcase blits a 800x600 surface to a 1280x720 surface at the coordinates -640,-345 scaled to 1280x720. The blit function that moves the data then runs over and reads after the pixel data from the src surface causing an access violation.
I can't say where exactly it goes wrong, but I think it could have something to do with the rounding in SDL_UpperBlitScaled. final_src.y is 288 and final_src.h is 313. Together that's 601, which I believe is one too much, but I just don't know the code enough to make sure that's the problem.
Sylvain
I think this patch fix the issue, but maybe it's worth re-writing "SDL_UpperBlitScaled" using SDL_FRect.
The non-deprecated approach (IOPMAssertion) already exists in SDL, and is
available in Mac OS X 10.6 and later (although it was incorrectly listed as
10.7 and later in SDL). Since SDL now requires 10.6 or later, this is no
longer conditionally used.
realitix
SDL2 allows to create widow and to get information through SDL_SysWMinfo.
But it misses something, with Vulkan, you need the HWND and HINSTANCE of the window for Win32 system.
Sadly, SDL2 provides only HWND but not HINSTANCE.
In some context, it can be difficult to get the HINSTANCE, indeed, I'm using pySDL2 (Python) and I can only access properties that SDL2 gives me.
I have to use a dirty trick like that to get the HINSTANCE: (https://raw.githubusercontent.com/bglgwyng/pyVulkan/master/examples/win32misc.py)
felix
Building SDL 2.0.5, or even the Mercurial snapshot (r10608) with GCC 6.2.1 and --enable-video-directfb generates a number of compiler diagnostics and fails.
Simon Hug
The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.)
Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient.
The following blend modes have issues when drawn at an angle.
NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode.
MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations.
BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is.
This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function.
There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers.
The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode...
It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster?
As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode.
I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
Vitaly Novichkov
Okay, when I researched code and algorithm, I tried to replace condition "while(dst >= target)" with "while(dst > target)" and crashes are gone.
Seems on some moments it tries to write into the place before memory block begin, therefore phantom crashes appearing after some moments.
Sylvain 2016-11-07 08:49:34 UTC
when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey.
if you set a dummy colorkey, it will remove the line ...
if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...
x414e54
It is a bit of a pain to update the library or rely on whatever version the user has on their computer for default mappings.
So providing an easily updatable text file via SDL_GameControllerAddMappingsFromFile is still currently the most viable way. However using this replaces all mappings provided by the SDL_HINT_GAMECONTROLLERCONFIG environment variable which may have come from the user's custom Steam mapping.
There should be an easy way for games to supply extra game controller mappings to fill in the differences between SDL versions without it clobbering the SDL_HINT_GAMECONTROLLERCONFIG environment variable.
Internally the mappings could use a priority system and if the priority is lower then it will not overwrite the mappings.
For now it just assumes SDL_HINT_GAMECONTROLLERCONFIG is the highest priority, the default hardcoded are the lowest and anything set via the API is medium.
Mark Pizzolato
On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c.
One of these, _allshr() is not properly implemented and fails for some input. As a result, some operations on 64bit data elements (long long) don't always work.
I classified this bug as a blocker since things absolutely don't work when the affected code is invoked. The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library. This build environment isn't common, and hence the bug hasn't been noticed previously.
I reopened#2537 and mentioned this problem and provided a fix. That fix is provided again here along with test code which could be added to some of the SDL test code. This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler. The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code. Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers. The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.
Ozkan Sezer
On systems with old glibc, such mine with glibc-2.8, the following warning
is issued and is fixed easily by defining _GNU_SOURCE:
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c: In function 'CalculateXRandRRefreshRate':
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: implicit declaration of function 'round'
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: incompatible implicit declaration of built-in function 'round'
x414e54
I have implemented Drag and Drop and Clipboard support for Wayland.
Drag and dropping files from nautilus to the testdropfile application seems to work and also copy and paste.
This no longer uses a script to generate code for every possible type
conversion or resampler. This caused a bloat in binary size and and compile
times. Now we use a handful of more generic functions and assume staying in
the CPU cache is the most important thing anyhow.
This shrinks the size of the final build (in this case: macOS X amd64, -Os to
optimize for size) by 15%. When compiling on a single core, build times drop
by about 15% too (although the previous cost was largely hidden by multicore
builds).
Alex Baines
I realized overnight that my patch probably broke text input events with UIM, and I confirmed that it does. Can't believe I overlooked that... I've been making stupid mistakes in these patches recently, sorry.
Anyway, *this* one seems to fix it properly. Knowing my luck it probably breaks something else.
Patch uses XkbFreeKeyboard to free the memory returned by XkbGetMap.
Earlier implementation called XkbFreeClientMap which frees all the maps
but not data->xkb structure itself, XkbFreeKeyboard will free maps and
the structure.
Kai Sterker
SDL2 on Haiku so far uses Haiku-specific APIs for loading dynamic objects as add-ons, instead of using dlopen to load them as libraries. This, for example, leads to SDL_mixer not being able to load its audio backends, when compiled with standard settings.
As discussed at https://www.freelists.org/post/haikuports/SDL2-mixer-ogg-music-not-playing-and-other-stuff,2 , the best way to deal with this would be using dlopen instead of load_add_on. The following patch implements this change by dropping the Haiku-specific bits and using dlopen instead.
/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c: In function 'calc_swizzle32':
/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c:127:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
const vector unsigned char plus = VECUINT8_LITERAL(0x00, 0x00, 0x00, 0x00,
^
Kai Sterker
Apparently, SDL2 on Haiku does not generate SDL_TEXTINPUT events.
Attached is a patch that adds this functionality.
Tested with SDLs own checkkeys program and different keymaps as well as my own SDL application and German keyboard layout to verify it generates the expected input.
Albert Casals
On a RaspberryPI, it might become convenient to specify the Dispmanx layer SDL uses.
Currently, it is hardcoded to be 10000 to sit above most applications.
This can be specially useful when integrating other graphical apps and frameworks like OMXplayer, QT5 etc.. in order to have more flexibility on their Z-order.
ny00
Unfortunately, simply checking the return codes of "onNativePadDown/Up" as previously done has its own issue:
If an SDL joystick is connected *and* opened, then a proper KeyEvent, say with keycode KEYCODE_BUTTON_1, should lead to an SDL joystick button event as expected.
If, however, the joystick was *not* opened, then "onNativePadDown/Up" will return a negative value, so before the commit from bug 3426, you could unexpectedly get a keyboard event. (In practice, you'll just get a log message, since KEYCODE_BUTTON_1 has no mapping to a proper SDL_ScanCode value, but it's still an problem).
What should still be done, though, is checking the key code itself. We do have the KeyEvent.isGamepadButton method, but according my test, it returns "true" exactly (and only) for the KEYCODE_BUTTON* values, and not for KEYCODE_DPAD* or any other key code.
Here is a possible solution:
- Do check the return codes of "onNativePadDown/Up" as previously done.
- In addition, in "Android_OnPadDown/Up" from src/joystick/android/SDL_sysjoystick.c, 0 should *always* be returned in case the key code can be translated to an SDL_joystick button; Even if no matching joystick can be found.
Philipp Wiesemann
Maybe the fault is in the SDL_VIDEO_DRIVER_WINDOWS section in SDL_InitSubSystem() of "src/SDL.c". Because there only SDL_INIT_JOYSTICK is checked. The flags are adapted for SDL_INIT_GAMECONTROLLER afterwards.
Eric Wasylishen
The patch makes StartTextInput/StopTextInput call Xutf8ResetIC ( https://www.x.org/releases/X11R7.5/doc/man/man3/XmbResetIC.3.html ) on the XIC of all SDL windows.
This fixes my use case in Quakespasm (Ubuntu 16.04, system keyboard layout set to German. Type the '^' dead key, which opens Quakespasm's developer console and calls SDL_StartTextInput, then press 'e'. I expect the dead key to be ignored.)
Also, here is a patch for sdl2's "checkkeys" for testing this: https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2451
Olav Sorensen
After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a *second* time generates an event like it should.
Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.
Simon Hug
There are currently three entry points in the SDL2_main code for windows: main, wmain and WinMain. Only the latter two properly convert the arguments to UTF-8.
Console applications linked with MSVC will always link with the main entry point (wmain has to be selected by manually setting the entry point). This makes it likely that such programs will not have proper unicode arguments.
Sylvain
After a long time, I found out more clearly what was going wrong.
The native libraries should be built with a "APP_PLATFORM" as low as possible.
Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml
So that the application never runs on a lower APP_PLATFORM than it has been built for.
An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10
(If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10.
And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".)
to precise what happened in the initial reported test-case:
Let say the "c" code contains a call to "srand()".
with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()".
with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()".
but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()).
So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10.
That was the issue. The path tried to fix this by in fact always calling srand48().
SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform.
It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions.
Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.
Robert Folland
When running this little test program with SDL2 on Wayland it often crashes in SDL_Init.
From a backtrace it is apparent that there is a race condition in creating a xkb_context_ref. Sometimes it is 0x0.
By moving the relevant lines higher up in Wayland_VideoInit (in SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302) this seems to get fixed.
I moved the call to WAYLAND_xkb_context_new() up to before the call to WAYLAND_wl_display_connect().
Here is the test program (just a loop of init and quit), and a backtrace from gdb:
#include <cstdio>
#include <stdlib.h>
#include <SDL2/SDL.h>
#include <unistd.h>
#include <iostream>
int main(int argc, char **argv)
{
int count = atoi(argv[1]);
for (int i = 0; i < count; i++) {
std::cout << "Init " << i << std::endl;
if (SDL_Init(SDL_INIT_VIDEO) < 0) {
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION,
"Couldn't initialize SDL: %s\n",
SDL_GetError());
return 1;
}
std::cout << "Quit" << std::endl;
SDL_Quit();
}
return 0;
}
Init 12
Quit
Init 13
Program received signal SIGSEGV, Segmentation fault.
xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156
156 ctx->refcnt++;
(gdb) bt
#0 xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156
#1 0x00007ffff5e1cd4c in xkb_keymap_new (ctx=0x0, format=XKB_KEYMAP_FORMAT_TEXT_V1, flags=flags@entry=XKB_KEYMAP_COMPILE_NO_FLAGS) at src/keymap-priv.c:65
#2 0x00007ffff5e1c6cc in xkb_keymap_new_from_buffer (ctx=<optimized out>,
buffer=0x7ffff7fd5000 "xkb_keymap {\nxkb_keycodes \"(unnamed)\" {\n\tminimum = 8;\n\tmaximum = 255;\n\t<ESC>", ' ' <repeats 16 times>, "= 9;\n\t<AE01>", ' ' <re
peats 15 times>, "= 10;\n\t<AE02>", ' ' <repeats 15 times>, "= 11;\n\t<AE03>", ' ' <repeats 15 times>, "= 12;\n\t<AE04>", ' ' <repeats 12 times>..., length=48090,
format=<optimized out>, flags=<optimized out>) at src/keymap.c:191
#3 0x00007ffff7b8ea4e in keyboard_handle_keymap (data=0x6169b0, keyboard=<optimized out>, format=<optimized out>, fd=5, size=48091)
at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandevents.c:269
#4 0x00007ffff64501f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#5 0x00007ffff644fc58 in ffi_call () from /usr/lib/libffi.so.6
#6 0x00007ffff665be3e in wl_closure_invoke (closure=closure@entry=0x61f000, flags=flags@entry=1, target=<optimized out>, target@entry=0x616d20,
opcode=opcode@entry=0, data=<optimized out>) at src/connection.c:949
#7 0x00007ffff6658be0 in dispatch_event (display=<optimized out>, queue=<optimized out>) at src/wayland-client.c:1274
#8 0x00007ffff6659db4 in dispatch_queue (queue=0x617398, display=0x6172d0) at src/wayland-client.c:1420
#9 wl_display_dispatch_queue_pending (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1662
#10 0x00007ffff665a0cf in wl_display_roundtrip_queue (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1085
#11 0x00007ffff7b8faa0 in Wayland_VideoInit (_this=<optimized out>) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302
#12 0x00007ffff7b7aed6 in SDL_VideoInit_REAL (driver_name=<optimized out>, driver_name@entry=0x0) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/SDL_video.c:513
#13 0x00007ffff7ae0ee7 in SDL_InitSubSystem_REAL (flags=16416) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/SDL.c:173
#14 0x0000000000400b24 in main (argc=2, argv=0x7fffffffebb8) at vplay-init.cpp:13
(gdb)
Eric wing
Sometimes an SDL_assert triggers at RPI_WarpMouseGlobal
src/video/raspberry/SDL_rpimouse.c:232 'update'.
It doesn't always reproduce, but it seems to happen when you really bog down the system and the event loop can't update for awhile.
The first time I hit this, I wasn't even using the mouse. I don't call any warp mouse functions either.
I can usually reproduce with a simple program that runs an expensive blocking CPU series of functions which blocks the main loop until complete (can be up to 10 seconds).
Sometimes this assertion gets triggered after that. I'm not sure if
they are related or coincidental.
Disabling the SDL_asserts when compiling SDL will avoid this problem. I actually haven't seen any problems with the mouse when I do this.
On a Raspberry Pi 2 running Raspbian Jessie.
Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.
Daniel Gibson
Ok, I followed the simple approach of just making SDL_PIXELFORMAT_RGBA32 an alias of SDL_PIXELFORMAT_RGBA8888/SDL_PIXELFORMAT_ABGR8888, depending on endianess. And I did the same for SDL_PIXELFORMAT_ARGB32, .._BGRA, .._ABGR.
SDL_GetPixelFormatName() will of course return SDL_PIXELFORMAT_RGBA8888 (or SDL_PIXELFORMAT_ABGR8888) instead of SDL_PIXELFORMAT_RGBA32, but as long as that's mentioned in the docs it shouldn't be a problem.
Apparently some systems see "hw:", some see "default:" and some see
"sysdefault:" (and maybe others!). My workstation sees both "hw:" and
"sysdefault:" ...
Try to find a prefix we like and prioritize the prefixes we (think) we want
most. If everything else fails, if there's a "default" (not a prefix) device
name, list that by itself so the user gets _something_ here.
If we can't find a prefix we like _and_ there's no "default" device, report
no hardware found at all.
Weitian Leung
Just moved ibus direct call to SDL_IME_* related functions, and adds fcitx IME support (uses DBus, too),
enable with env: SDL_IM_MODULE=fcitx (ibus still the default one)
D39 does not support negative viewport values which the current implementation relies on.
D3D11 does support negative viewport values so that will continue working.
Refer to Bug 2799.
x414e54
Wayland will sometimes send empty resize events (0 width and 0 height) to the client. I have not worked out the exact conditions a client would receive these but I can assume it might be if the window is offscreen or not mapped yet.
This causes issues with some SDL clients as they receive the 0x0 event and unexpected resize event or might not request to resize back to the correct size.
As per the wl_shell Wayland spec configure events are only a suggestion and the client is free to ignore or pick a different size (this is how min/max and fixed aspect ratio is supped to be implemented).
A patch is attached but is just the first iteration and I will fix any issues such as checking for FULLSCREEN/MAXIMIZED or RESIZABLE flags unless someone else fixes this first.
I have update to take into account non resizable and fullscreen windows. Also adding in maximize/restore and title functions for Wayland.
Darren Kulp
The dummy video driver is not available on Mac OS X if SDL_VIDEO_OPENGL is set at library compilation time.
In src/video/SDL_video.c, there is a compile-time check in SDL_CreateWindow() for (SDL_VIDEO_OPENGL && __MACOSX__). When it succeeds, SDL_WINDOW_OPENGL is always requested. Since the dummy video driver does not supply an OpenGL implementation, the error "No OpenGL support in video driver" is supplied to the user, and SDL_CreateWindow() is exited early.
Adam M.
When doing a rotated texture copy with the software renderer, where the angle is a multiple of 90 degrees, one or two edges of the image get cut off. This is because of the following line in sw_rotate.c:
if ((unsigned)dx < (unsigned)sw && (unsigned)dy < (unsigned)sh) {
which is effectively saying:
if (dx >= 0 && dx < src->w-1 && dy >= 0 && dy < src->h-1) {
As a result, it doesn't process pixels in the right column or bottom row of the source image (except when they're accessed as part of the bilinear filtering for nearby pixels). This causes it to look like the edges are cut off, and it's especially obvious with an exact multiple of 90 degrees.
Nitz
In function SDLgfx_rotateSurface:
rz_dst =
SDL_CreateRGBSurface(SDL_SWSURFACE, dstwidth, dstheight + GUARD_ROWS,
rz_src->format->Rmask, rz_src->format->Gmask,
rz_src->format->Bmask, rz_src->format->Amask);
Here rz_src get De-referenced without NULL check, which is risky.
Simon Sandstr?m
As stated in Summary. The switch statement will execute the default case and set a SDL error message: "SDL_MixAudio(): unknown audio format".
There are atleast two more problems here:
1. SDL_MixAudioFormat does not notify the user that an error has occured and that a SDL error message was set. It took me awhile to understand why I couldn't mix down the volume on my AUDIO_U16LSB formatted audio stream.. until I started digging in the SDL source code.
2. The error message is incorrect, it should read: "SDL_MixAudioFormat(): unknown audio format".
Daniel Gibson
Currently, SDL_CreateRGBSurface() and SDL_CreateRGBSurfaceFrom() take Uint32 masks for RGBA to "describe" the Pixelformat of the surface.
Internally those value are only used to map to one of the SDL_PIXELFORMAT_* enum values that are used for further processing.
I think it would be both handy and more efficient to be able to specify SDL_PIXELFORMAT_* yourself without using SDL_PixelFormatEnumToMasks() to create masks first, so I implemented functions that do that:
SDL_CreateRGBSurfaceWithFormat() and SDL_CreateRGBSurfaceWithFormatFrom() which are like the versions without "WithFormat" but instead of taking 4 Uint32s for R/G/B/A masks, they take one for a SDL_PIXELFORMAT_* enum value.
Together with https://bugzilla.libsdl.org/show_bug.cgi?id=2923 creating a SDL_Surface* from RGBA data (e.g. from stb_image) is as easy as
surf = SDL_SDL_CreateRGBSurfaceWithFormat(0, w, h, bppToUse*8, SDL_PIXELFORMAT_RGBA32);
Ryan C. Gordon
We still include iconv.h in SDL_stdinc.h, probably because this header might have referenced the native iconv functions and types directly. Since these are hidden behind a stable ABI now and never just a #define for the system iconv, we shouldn't need this header included from a public SDL header anymore, slowing down external apps compiles and pulling tons of stuff into the namespace.
Jan Klass
Not sure if this is limited to the joystick subsystem,
but I created a minimal program for reproducibility,
which is attached.
The issue occurs with my gamepad Razer Onza (an xbox-style gamepad) plugged in.
On initialization, the gamepad is being recognized.
After quitting the subsystem, the poll will receive the joystick added event,
which it instantly handles itself, calling SDL_SYS_JoystickDetect again,
which this time calls IDirectInput8_EnumDevices with dinput = NULL (after it was released on quit).
This seems to lead to an access violation within said function, which I have no source for.
Jan Hellwig
On Windows, you are able to navigate between the buttons on a MessageBox that was created using SDL_ShowMessageBox using the arrow keys. However, if you press the left arrow key, the selection jumps to the button on the right of the currently selected one (and vice versa).
This can be fixed by reversing the order in which the buttons are added to the dialog.
The attached patch files fixes this problem. However the first press of an arrow key leads to the selection of the leftmost or rightmost button on the MessageBox, not to the selection of the button left/right of the one that is selected by default.
Ryochan7
I have been using SDL 2 for a little project that I have been developing for a while. My project is called antimicro and it takes gamepad input and then translates gamepad events into keyboard and mouse events. SDL is used to read the input from an XInput gamepad and it works great for the most part. However, there is one glaring problem that I have encountered.
When a device is unplugged and SDL sends the centered value release events for all axes, buttons, and hats, SDL does not use the proper centered value for the triggers. It pushes an SDL_JOYAXISMOTION event onto the queue with a value of 0 for all axes. That value is converted to around 16,000 for a Game Controller. That value is incorrect for triggers and, in my program, that causes any bindings that are assigned to the triggers to get activated. With most profiles, that will typically mean that a mouse right click and left click will be activated before the device is finally seen as removed and then those bindings are released by antimicro.
Jonas Kulla
At startup time, the single android window is assigned a "windowed" (window->windowed.{w,h}) size based on the current orientation of the mobile device; this size is never updated throughout the lifetime of the app.
This becomes problematic when the app is paused and then resumed in an orientation that it did not start up in. Eventually, 'SDL_OnWindowRestored()' is called, which calls 'SDL_UpdateFullscreenMode()'. This function is very problematic because it is written with a desktop monitor in mind: it tries to find a matching display mode for the windowed size, doesn't find any, and finally applies the windowed size as the fullscreen one. In the end, the windowed size is reported in a RESIZED event, which doesn't correspond to the actual surface size.
To see this in action: Start an orientation aware SDL app in eg. portrait mode, suspend the app, put the device into landscape orientation and resume the app. It will erroneously render in portrait mode (until the device is rotated again).
This tends to be a frequent spot where drivers hang, and the waits were
often unreliable in any case.
Instead, our audio thread now alerts the driver that we're done streaming audio
(which currently XAudio2 uses to alert the system not to warn about the
impending underflow) and then SDL_Delay()'s for a duration that's reasonable
to drain the DMA buffers before closing the device.
This tries to make SDL robust against device drivers that have hung up,
apps don't freeze in catastrophic (but not necessarily uncommon) conditions.
Now we detach the audio thread and let it clean up and don't care if it
never actually runs to completion.
James Zipperer
The problem I was seeing was that the the ALSA hotplug thread would call SDL_RemoveAudioDevice, but my application code was not seeing an SDL_AUDIODEVICEREMOVED event to go along with it. To fix it, I added some code into SDL_RemoveAudioDevice to call SDL_OpenedAudioDeviceDisconnected on the corresponding open audio device. There didn't appear to be a way to cross reference the handle that SDL_RemoveAudioDevice gets and the SDL_AudioDevice pointer that SDL_OpenedAudioDeviceDisconnected needs, so I ended up adding a void *handle field to struct SDL_AudioDevice so that I could do the cross reference.
Is there some other way beside adding a void *handle field to the struct to get the proper information for SDL_OpenedAudioDeviceDisconnected?
James Zipperer
Close the audio device before waiting for the audio thread to complete, which fixes a situation where the audio thread never completes
Add an additional check in the audio thread to see if the device is enabled and bail out if the device is no longer enabled
Joe Thompson
With Direct Input device (MOMO Steering Wheel w/FF)
with SDL 2.0.3,
SDL_HapticOpenFromJoystick() would fail. (Can't set exclusive mode)
Now with 2.0.4 rc1,
SDL_HapticOpenFromJoystick() succeeds but the the returned SDL_Haptic* cannot be used. Calls to SDL_HapticNewEffect() fail with "Haptic error Unable to create effect"
If SDL_HapticOpen() is used instead of HapticOpenFromJoystick(), the device is usable. Calls to HapticNewEffect() succeed with the exact same parameters as the previous failing call.
I have attached a proposed patch for this issue.
When using SDL_HapticOpenFromJoystick(), the original code did not (re)enumerate the axes. This returned a new haptic device with 0 axes. Later, when a new effect is created, SDL_SYS_SetDirection() would set the flags to include DIEFF_SPHERICAL, regardless of what the caller actually set. (see Line 566 in SDL_dinputhaptic.c). This would cause the SDL_HapticNewEffect() to fail (or interpret the coordinates incorreclty.)
The patch moves the call to IDirectInputDevice8_EnumObjects() outside of the if() block so that the axes are (re)enumerated for the new haptic device.
Note: For steering wheels it is common for the joystick to have multiple axes (ie steering, throttle, brake), but the haptic portion of the joystick usually only applies to steering.
Fixes Bugzilla #3441.
"When using internal SDL_vsnprintf(), and source string length is greater
than destination, the final NULL char will be written beyond destination size.
Primary issue that is SDL_strlcpy returns length of source string
(SDL_PrintString()), not how much is written to destination. The destination
ptr is then incremented by this length before the sanity check is done.
Destination string is properly terminated, but an extra NULL char will be
written beyond destination buffer length.
Patch used internally is attached which fixes primary issue with SDL_strlcpy()
in SDL_PrintString() and adjusts sanity checks to increment destination ptr
safely."
Tim McDaniel
Using checkkeys test app:
* Press and hold Caps Lock key.
* checkkeys reports a CapsLock key pressed event and a CapsLock key released event.
* Release Caps Lock key.
* checkkeys reports no further events.
This patch fixes OSX Caps Lock up/down event detection by installing a HID callback.
John Wordsworth
While attempting to integrate CEF (Browser) into an SDL application, we noticed that there were problems on OS X where approximately 50% of the input events were essentially being lost - even when we were using off-screen rendering in CEF and passing through input events manually.
It appears that this problem has been around for a while (see: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=11141).
Please consider the following patch that fixes this issue. Instead of processing events directly after calling [NSApp nextEventMatchingMask:...] we now pass these events down to NSApp, for processing by an overloaded sendEvent: method. Chromium also forwards events to NSApp in the same way, which means we don't miss events, even if they were originally dequeued by CEF.
Daniel
Seems like check of the visibility of renderer (renderer->hidden) is missing in SDL_RenderCopyEx.
In SDL_RenderCopy it should be done much earlier (after checking support for RenderCopyEx, line 1750).
Michael
In SDL_x11modes.c the CalculateXRandRRefreshRate() function performs integer math on values that may return fractional results. This causes a value that would be calculated as 59.99972... to be returned as 59. In Linux the xrandr command returns 60Hz for this particular display mode yet SDL returns 59Hz.
I suggest this function be updated to correctly round the result of the calculation instead of truncating the result.
Machiel van Hooren
In SDL_dxjoystick.c line 349 there is a constant c_dfDIJoystick2.
However, this constant is aparently also defined in dinput8.lib.
I encountered a linking error when statically linking to SDL:
SDL2_static.lib(SDL_dxjoystick.obj) : error LNK2005: _c_dfDIJoystick2 already defined in dinput8.lib
My application is also linking to dinput8.lib because we rolled our own joystick input and are not using the joystick functionality from SDL.
Patrick Gutlich
The mouse cursor gets corrupted when the mouse moves over the screen edges (right and bottom) a weird type of scaling seems to occur and you end up with a blank square.
tvc
I've spent the last few days implementing touchscreen support in core/linux/SDL_evdev.c. It's fairly rudimentary at the moment, as can be seen from the multiple TODO's and FIXME's littered throughout, but I'm mainly submitting this patch for review. I've tested this patch on my Raspberry Pi 2 with the official touchscreen and it works fantastically, reporting all 10 multitouch points. I'm happy to work on this further, the evdev logic also needs a bit of a cleanup I think (I may have included a few changes). But if it's good enough in its current state to be committed then I'm sure there'd be plenty of people pleased, as currently the only other framework/library that supports touchscreens on the Raspberry Pi is Kivy.
Fritzor
Source Suface is ABGR and Destination Surface is ABGR. We use software blending. In the Switch-Case statement for SDL_COPY_BLEND (Line 126) the alpha-channel is not calculated like in every SDL_blit_auto - function. So if the destination Surface has alpha - channel of zero the resulting surface has zero as well.
Add: ?dstA = srcA + ((255 - srcA) * dstA) / 255;? to code and everything is okay.
Marcel Bakker
Observed when resizing or moving a window in Windows 7.
Depending on how you resize/move your window
, you may receive none or a lot of SDL_WINDOWEVENT_EXPOSED events
, at the moment you release the mouse button.
Maybe add this event to an already existing list of overflow candidates ?
Yann Dirson
When attempting to force use of opengles2 renderer with:
int wanted_renderer = -1;
for (int i = 0; i < numrenderers; i++) {
SDL_RendererInfo renderer_info;
if (SDL_GetRenderDriverInfo(i, &renderer_info) != 0) {
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't get renderer driver info: %s\n",
SDL_GetError());
quit(2);
}
std::cerr << "Renderer " << i << " '" << renderer_info.name << "': flags=0x"
<< std::hex << renderer_info.flags << std::dec
<< ", " << renderer_info.num_texture_formats << " texture formats, max="
<< renderer_info.max_texture_width << "x"
<< renderer_info.max_texture_height << "\n";
if (!strcmp(renderer_info.name, "opengles2")) {
std::cerr << " selecting!\n";
wanted_renderer = i;
}
}
renderer = SDL_CreateRenderer(window, wanted_renderer, 0);
... on banana pi or raspberry pi I get an error like the following (the actual
context profile value varies, being used uninitialized)
ERROR: Couldn't create renderer: Unknown OpenGL context profile 900
With this patch I get the following, which should help more pointing to a real problem:
ERROR: Couldn't create renderer: Failed getting OpenGL glGetString entry point
I pushed a patch (based on master branch of unofficial git mirror):
550389c89f
I'll be opening a different bug for the underlying issue.
Evgeny Vrublevsky
Original code in the video/windows/SDL_windowsevents.c registers obsolete WNDCLASS (not WNDCLASSEX). As the result only one icon size is used as the small and normal icons. Also original code doesn't specify required size of an icon. As the result when 256x256 icon is available, the program uses it as a default icon, and it looks ugly.
We have to use WNDCLASSEX and load icons with proper sizes which we can get using GetSystemMetrics.
Better idea. We could use the first icon from resources, like the Explorer does. Patch is included. It also correctly loads large and small icons, so it will look nice everywhere.
ny00
Using the OpenGL ES 1.1 renderer, after updating a texture with SDL_UpdateTexture (or SDL_UnlockTexture), a following call to SDL_RenderFillRect draws a rectangle with the wrong color (which appears to be the same as the texture's top-left pixel).
Comparing SDL_render_gles.c:GLES_UpdateTexture to SDL_render_gl.c:GL_UpdateTexture, a missing call to glDisable appears to be the cause. After adding it back, the bug is resolved.
ny00
On Android, the keycodes KEYCODE_BUTTON_1..16 (actual values 188-203) are translated to SDL_Joystick buttons no. 20-35. These are currently ignored in SDL_gamecontroller.c.
The attached patch fixes this, by increasing k_nMaxReverseEntries from 20 to another arbitrary bound of 48.
Side-note: Maybe some log should be emitted in case of going over any such bound?
Diego
The keyboard on iPads has a dismiss button that hides the keyboard. When the keyboard was hidden using that button, instead of the return key, SDL was still reporting IsTextInputActive as true. This patch adds an extra SDL_StopTextInput when iOS reports the keyboard will hide.
Simon Hug
The SDLmain file src/main/windows/SDL_windows_main.c defines both entry points for console applications, main and wmain. This seems to confuse MSVC. It outputs a LNK4067 warning and then chooses main, which is a shame because only wmain has the unicode handling. Using SDLmain.lib provided on libsdl.org, the linker also goes for main.
I'm proposing to not define the main entry point at all. wmain should be supported well enough with MSVC.
Eric Wasylishen
The bug here is that a dead keys pressed before calling SDL_StartTextInput() carries over into future text input, so the next key pressed will have the deadkey applied to it.
This in undesirable, imho, and doesn't occur on OS X (haven't check Linux or elsewhere). It's causing a problem for Quakespasm on German keyboard layouts, where we use the ^ deadkey to toggle the console (which enables/disables text input), and ^ characters are showing up in the TEXTINPUT events.
Simon Hug
The function console_wmain in src/main/windows/SDL_windows_main.c does not null terminate the argument list it is creating. As specified by the C standard, "argv[argc] shall be a null pointer."
The SDLTest framework makes use of that null pointer and some test programs can cause an access violation because it's missing.
Simon Hug
The description of the SDL_RenderClear function in the SDL_render.h header says the following:
"This function clears the entire rendering target, ignoring the viewport."
The word "entire" implies that the clipping rectangle set with SDL_RenderSetClipRect also gets ignored. This is left somewhat ambiguous if only the viewport is mentioned. Minor thing, but let's see what the implementations actually do.
The software renderer ignores the clipping rectangle when clearing. It even has a comment on this: /* By definition the clear ignores the clip rect */
Most other render drivers (opengl, opengles, opengles2, direct3d, and psp [I assume. Can't test it.]) use the scissor test for the ClipRect and don't disable it when clearing. Clearing will only happen within the clipping rectangle for these drivers.
An exception is direct3d11 which uses a clear function that ignores the scissor test.
Simon Hug
When updating the viewport in GLES_UpdateViewport, the OpenGL ES renderer doesn't flip the projection matrix for target textures. The lines, rectangles and textures (if drawn with glDrawArrays) are upside down when drawing to target textures.
Simon Hug
The OpenGL ES 2 renderer does not check the target texture format when using SDL_RenderReadPixels and just always uses ABGR8888. This can result in swapped or wrong colors.
The attached patch adds a check and selects the target texture format, if a texture is set as the target.
Simon Hug
All OpenGL renderers always flip the rows of the pixels that come from glReadPixels. This is unnecessary for target textures since these are already top down.
Also, the rect->y value can be used directly for target textures for the same reason. I don't see any code that would handle the logical render size for target textures. Or am I missing something?
The attached patch makes the renderers only the flip rows if the data comes from the default framebuffer.
Simon Hug
The current SDL_SaveBMP_RW function that saves surfaces to a BMP uses an old bitmap header which doesn't officially support alpha channels. Applications just ignore the byte where the alpha is stored. This can easily be extended by using a newer header version and setting the alpha mask.
The attached patch has these changes:
- Extending the description of the function in the SDL_surface.h header with the supported formats.
- Refining when surfaces get stored to a 32-bit BMP. (Must have bit depth of 8 or higher and must have an alpha mask or colorkey.)
- Fixing a small bug that saves 24-bit BGR surfaces with a colorkey in a 24-bit BMP.
- Adding code that switches to the bitmap header version 4 if the surface has an alpha mask or colorkey. (I chose version 4 because Microsoft didn't lose its documentation behind a file cabinet like they did with version 3.)
- Adding a hint that can disable the use of the version 4 header. This is for people that need the legacy header or like the old behavior better. (I'm not sure about the hint name, though. May need changing if there are any rules to that.)
Simon Hug
The GL_SetBlendMode and GLES_SetBlendMode functions of the opengl and opengles renderers call the glTexEnvf to set the texture env mode to either GL_MODULATE (the default) or GL_REPLACE for the NONE blend mode. Using GL_REPLACE disables color and alpha modulation for textures.
These glTexEnv calls were put in the SetBlendMode function back in 2006 [1], but there the NONE code still used the GL_DECAL mode. The GL_REPLACE mode came in 2008 [2]. I'm a bit confused why that wasn't always GL_MODULATE and a bit surprised nobody reported that yet (unless I missed it). I guess only a few use the gles renderer and the newish shaders mask the issue.
Simon Hug
The GL_CreateTexture function doesn't have any checks for the case where the driver doesn't support the framebuffer object extension. It will call into GL_GetFBO which will call the non-existent glGenFramebuffersEXT.
Also, for some reason GL_CreateContext always sets the SDL_RENDERER_TARGETTEXTURE info flag, even if it is not supported. Changeset cc226dce7536 [1] makes this change, but doesn't explain why. It seems to me like the code would already have taken care of this [2].
The attached patch adds some checks and stops SDL from reporting render target support if there is none. The application can then properly inform the user instead of just crashing.
Simon Hug
When the SDL_Blit_Slow function compares the pixel to the color key it does so without removing the alpha component from the pixel value and the key. This is different from the optimized 32-bit blitters which create a rgb mask and apply it to both to filter the alpha out. SDL_Blit_Slow will only skip the pixels with the exact alpha value of the key instead of all pixels with the same color.
The attached test case blits a surface with a color key and prints the pixel values to the console. The third row is expected to be skipped.
Simon Hug
It seems not everyone implemented glDrawTexfOES the same. Intel and Mesa ignore the viewport entirely, whereas the Raspberry Pi implementation offsets the coordinates and does viewport clipping.
The glDrawTexfOES extension text [1] for the function says "Xs and Ys are given directly in window (viewport) coordinates." I guess this wasn't clear enough.
Alex Szpakowski
Honestly I'd probably remove that codepath from SDL_Render entirely. It's an OpenGL ES 1-specific extension that isn't likely to give huge performance gains and adds additional maintenance overhead to SDL_Render while also having bugs in some drivers (as seen here).
SFC30 controller: http://www.8bitdo.com/sfc30/
The SFC30 controller can present itself in a variety of modes and it offers up
different names in each. This patch captures data for three modes (one USB and
two Bluetooth) on three platforms (Mac OS X, Windows, Linux).
However, USB mode on Linux and Windows is missing as the button events did not
make it through to SDL's controllermap tool on Fedora 24/Linux 4.5.5 nor Steam
Big Picture mode on Windows. The two Bluetooth modes were indistinguishable on
Windows. Two modes on OS X were indistinguishable.
There exists a similar controller called the SNES30 (And some others) that are
very likely identical except for the name, but I have not verified this yet so
haven't synthesized lines for those controllers until I can.
Kai Sterker
There are already patches available from mingw64 that fix the issue
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-SDL2
With those applied, I could compile SDL2 without problems. But of course, it would be preferable if SDL built cleanly from source.
Vitaly Novichkov
Line 124
====================================================================
const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION : 0;
====================================================================
Error of compiler:
====================================================================
CC build/SDL_systhread.lo
src/thread/windows/SDL_systhread.c: In function 'SDL_SYS_CreateThread':
src/thread/windows/SDL_systhread.c:124:45: error: 'STACK_SIZE_PARAM_IS_A_RESERVA
TION' undeclared (first use in this function)
const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION :
0;
^
src/thread/windows/SDL_systhread.c:124:45: note: each undeclared identifier is r
eported only once for each function it appears in
make: *** [build/SDL_systhread.lo] Error 1
====================================================================
Fixing when I adding into begin of the file:
====================================================================
#ifndef STACK_SIZE_PARAM_IS_A_RESERVATION
#define STACK_SIZE_PARAM_IS_A_RESERVATION 0x00010000
#endif
====================================================================
The Apple TV remote is currently exposed as a joystick with its touch surface treated as two axes. Key presses are also generated when its buttons and touch surface are used.
A new hint has been added to help deal with deciding whether to background the app when the remote's menu button is pressed: SDL_HINT_APPLE_TV_CONTROLLER_UI_EVENTS.
Previously when the canvas was scaled up and the pointer was locked,
motion corresponding to less than one pixel was lost. Therefore,
slow mouse motion resulted in no motion. This fixes that.
Browsers don't have the functionality to fully support the generic
SDL_ShowMessageBox(), but this handles the likely most-common case.
Without this, you'd return immediately with a proper error result and no UI,
but probably no one checks that for SDL_ShowSimpleMessageBox. And if they
did: what would they do to handle this anyhow?
We'd need to lobby for an HTML spec of some sort that allows customizable
message boxes--that block!--to properly support SDL message boxes on
Emscripten, but this is probably Good Enough for now.
AudioQueues are available in Mac OS X 10.5 and later (and iOS 2.0 and later).
Their API is much more clear (and if you don't mind the threading tapdance
to get its own CFRunLoop) much easier to use in general for our purposes.
As an added benefit: they seemlessly deal with format conversion in ways
AudioUnits don't: for example, my MacBook Pro's built-in microphone won't
capture at 8000Hz and the AudioUnit version wouldn't resample to hide this
fact; the AudioQueue version, however, can handle this.
Generate the C protocol files from the protocol XML files installed by
wayland-protocols, and use them to implement support for relative pointer
motions and pointer locking.
Note that at the time, the protocol is unstable and may change in the future.
Any future breaking changes will, however, fail gracefully and result in no
regressions compared to before this patch.
Since we are loading shared objects dynamically, build our own version of the
core protocol symbols, so that we in the future can include protocol
extensions.
This will be used by Wayland compositors to match the application ID and
.desktop file to the SDL window(s).
Applications can set the SDL_VIDEO_WAYLAND_WMCLASS environemnt variable
early in the process to override using the binary name as a fallback.
Note that we also support the SDL_VIDEO_X11_WMCLASS in the Wayland
backend so that if a program correctly associated the desktop file with
the window under X11, only a newer SDL would be needed for it to work
under Wayland.
https://bugzilla.libsdl.org/show_bug.cgi?id=3376
Author: James Zipperer <james.zipperer@synapse.com>
Date: Sun Aug 21 01:19:19 2016 -0700
bugfix for controller / joystick add / remove being in the event queue at the same time
The repro steps were this:
1. run an sdl2 winrt/uwp app, on Win10, v10.0.10586.0 or higher
2. hide the cursor, via a call to SDL_ShowCursor(0)
3. make the Win10 game bar appear, by pressing the Windows + G hotkey
4. observe that the mouse cursor appears, in order to interact with the
game bar (this is expected behavior)
5. make the Win10 game bar disappear, either by pressing the Windows + G hotkey
again, or clicking somewhere in the app
EXPECTED RESULT: cursor disappears, as game bar disappears
ACTUAL RESULT: cursor didn't always disappear
Moved this code from winmm into core so both can use it.
DirectSound (at least on Win10) also returns truncated device names, even
though it's handed in as a string pointer and not a static-sized buffer. :/
The Windows 10 Anniversary Update (1607) breaks the method uses that SDL uses to
detect XInput devices. That is, on Windows 10 Anniversary Update, it is no longer
possible to query RAWINPUT for HID devices, and check for "IG_" in the device name.
Presumably, this will be fixed in the future.
This patch works around the issue by adding the Xbox One controller series to the
well-known device list.
This skips the more expensive RAWINPUT check for those devices, and causes them to
be detected as XInput devices once again.
Otherwise, if you had a massive, one-time queue buildup, the memory from that
remains allocated until you close the device. Also, if you are just using a
reasonable amount of space, this would previously cause you to reallocate it
over and over instead of keeping a little bit of memory around.
I think this was important for SDL 1.2 because some targets needed
special device memory for DMA buffers or locked memory buffers for use in
hardware interrupts or something, but since it just defines to SDL_malloc
and SDL_free now, I took it out for clarity's sake.
- It's now always called if device->hidden isn't NULL, even if OpenDevice()
failed halfway through. This lets implementation code not have to clean up
itself on every possible failure point; just return an error and SDL will
handle it for you.
- Implementations can assume this->hidden != NULL and not check for it.
- implementations don't have to set this->hidden = NULL when done, because
the caller is always about to free(this).
- Don't reset other fields that are in a block of memory about to be free()'d.
- Implementations all now free things like internal mix buffers last, after
closing devices and such, to guarantee they definitely aren't in use anymore
at the point of deallocation.
Turns out that libartsc isn't thread-safe, so if we run a capture and playback
device at the same time, it often crashes in arts's internal event loop.
We could throw mutexes around the read/write calls, but these are meant to
block, so one device could cause serious latency and stutter in the other.
Since this audio target isn't in high-demand (Ubuntu hasn't offered a libartsc
package for years), I'm just backing out the capture support. If someone needs
it, they can pull it out of the revision history.
(We probably never noticed because this is meant to block until it fully
writes a buffer, and would only trigger an issue if we had a short write
that wasn't otherwise an error condition.)
This workaround, unfortunately, requires that apps directly link to a set of
Win32-style cursor resource files (that contain a transparent cursor image).
Copies of suitable resource files are in src/core/winrt/, and should be
included directly in an app's MSVC project.
A rough explanation of this workaround/hack, and why it's needed (and
seemingly can't be done through programmatic means), is in this change's code.
This allows us to set an explicit stack size (overriding the system default
and the global hint an app might have set), and remove all the macro salsa
for dealing with _beginthreadex and such, as internal threads always set those
to NULL anyhow.
I've taken some guesses on reasonable (and tiny!) stack sizes for our
internal threads, but some of these might turn out to be too small in
practice and need an increase. Most of them are simple functions, though.
Win10's 'GamepadAdded' event seems to need to have something registered with it
in order for Xinput-based gamepad detection to work. This 'fix' simply causes
a dummy event-handler to be added for this event, in case an app wants to use
gamepads on Xbox One (most likely).
This is kind of nasty, because ALSA reports dozens of "devices" that aren't
really things you'd ever want, or things that should be listed this way, but
the default path still works as before, and it at least allows these devices
to be available to apps.
This does not handle hotplugging yet. You get a device list at init time
and that's it.
- Cache the _NET_FRAME_EXTENTS data locally, so we don't have to query
the X server for them (instead, we update our cached data when PropertyNotify
events alert us to a change).
- Use our cached extents for X11_GetWindowBordersSize(), so it's a fast call.
- Window position was meant to refer to the client area, not the window
decorations, so adjust appropriately when getting/setting the position.
We now only raise the magic exception that names the thread when
IsDebuggerPresent() returns true. In such a case, Visual Studio will
catch the exception, set the thread name, and let the debugged process
continue normally. If the debugger isn't running, we don't raise an exception
at all.
Setting the name is a debugger trick; if the debugger isn't running, the name
won't be set if attached later in any case, so this doesn't lose functionality.
This lets this code work without assembly code, on win32 and win64, and
across various compilers.
The only "gotcha" is that if you have something attached that looks like a
debugger but doesn't respect this magic exception trick, the process will
likely crash, but that's probably a deficiency of the attached program.
Fixes Bugzilla #2089.
The returned value is currently not used by the caller. The instance id would
also not be needed on Java side and providing it just complicated the function.
Partially fixes Bugzilla #3234.
This assert triggers when run under XMonad. It's safe to pass a zero here
anyhow, as this will still work "well enough" and the original
problem--GNOME printing a warning message--is still fixed because GNOME's
window manager gives us a chance to grab a non-zero user-time value before
this code is run.
(and thanks to Cengiz for many of the previous Unreal-related
patches! They were generically credited to Epic Games, but a large
amount of that work was his contribution.)
Fixes Bugzilla #3067.
This is for corner cases where a multi-window app is activated and wants to
make a decision about where focus should go.
This patch came from Unreal Engine 4's fork of SDL, compliments of Epic Games.
Adam M.
When setting a texture alpha mod other than 255 and also specifying a flip mode in the software renderer, the rendering fails. When the texture has an alpha channel, it becomes invisible when flipped. When the texture does not have an alpha channel, it is flipped but the colors are wrong: the alpha mod makes the texture darker rather than more translucent.
0) Initialize a software renderer.
1) Load 16-bit 565 or 32-bit texture.
2) Set texture blend mode to BLEND.
3) Set texture alpha mod to 150.
4) Draw the texture flipped horizontally and/or vertically.
Adam M.
There are three problems in the code that I see.
1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key.
2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled.
3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled).
I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and simplifies the rotation code slightly.
Adam M.
Okay, here is the problem, I think.
During the first blit, RLEAlphaSurface is called to do RLE conversion of the RGBA source into a format allowing it "to be quickly alpha-blittable onto dest". Since the destination is the screen, it has no alpha channel. RLEAlphaSurface calls copy_opaque(dst, src + runstart, len, sf, df) (where copy_opaque is copy_32), which has this code:
SDL_RLEaccel.c:984:
RGBA_FROM_8888(*src, sfmt, r, g, b, a);
PIXEL_FROM_RGBA(*d, dfmt, r, g, b, a);
On the first line, it reads the source pixel 0xFFFFFFFF. The second line drops the alpha value (because dfmt for the screen has no alpha channel) and writes 0x00FFFFFF. Later, when the RLE conversion is being undone, uncopy_32 is called, which has the following code:
SDL_RLEaccel.c:1001:
Uint32 pixel = *s++;
RGB_FROM_PIXEL(pixel, sfmt, r, g, b);
a = pixel >> 24;
PIXEL_FROM_RGBA(*dst, dfmt, r, g, b, a);
However, the the alpha channel has already been dropped by copy_opaque (= copy_32), so pixel = 0x00FFFFFF and 'a' becomes 0. Thus, all opaque pixels lose their alpha channel when being unRLE'd. (I don't know what happens to pixels with alpha from 1-254, but they should be checked too.)
So, that seems to be the problem, but I'm not sure what the solution should be. Since opaque pixels have alpha == 255, I'm thinking to create another uncopy function for opaque pixels that simply uses 255 for alpha.
However, there may be other problems here. For translucent pixels, uncopy_32 assumes the alpha channel is stored in the upper 8 bits, but copy_32 doesn't store it there. Instead, it stores it in whatever location is appropriate for the destination surface. Isn't one of their behaviors incorrect, given the other? I'm not sure which to change, however.
For translucent pixels, it seems that the blit function uses do_blend, which is the BLIT_TRANSL_888 macro, which also assumes alpha is in top 8 bits. It has the comment "we have made sure the alpha is stored in the top 8 bits...", but it seems that's not true (copy_32 doesn't make sure the alpha goes there).
Perhaps the correct fix is to make copy_32 put the alpha there, but then that seems to require that RLE conversion be limited to destination surfaces that don't use the upper 8 bits. However, looking further, it seems that has already been done: if (masksum != 0x00ffffff) return -1; /* requires unused high byte */
Sylvain
When using API 21 and running on an old device (android < 5.0 ?) some function are missing.
functions are (at least) : signal, sigemptyset, atof, stpcpy (strcat and strcpy), srand, rand.
Very few modifications on SDL to get this working :
on SDL
======
Undefine android configuration :
HAVE_SIGNAL
HAVE_SIGACTION
HAVE_ATOF
In "SDL_systrhead.c", comment out the few block of lines with "sigemptyset".
Android.mk:
remove the compilation of "test" directory because it contains a few rand/srand calls
Also, there are more discussions about this in internet :
https://groups.google.com/forum/#!topic/android-ndk/RjO9WmG9pfEhttp://stackoverflow.com/questions/25475055/android-ndk-load-library-cannot-locate-srand
Sylvain
http://developer.android.com/reference/android/view/InputDevice.html
int SOURCE_CLASS_JOYSTICK Constant Value: 16 (0x00000010)
int SOURCE_JOYSTICK Constant Value: 16777232 (0x01000010)
int SOURCE_KEYBOARD Constant Value: 257 (0x00000101)
int SOURCE_GAMEPAD Constant Value: 1025 (0x00000401)
int SOURCE_DPAD Constant Value: 513 (0x00000201)
I have an a PC keyboard that I connect to an android device.
The issue is that "arrow" keys gets lost.
More explanation:
This device gets detected twice by the java "pollInputDevices()" both as SOURCE_KEYBOARD and as a composite (0x1000311 == SOURCE_JOYSTICK | SOURCE_KEYBOARD | SOURCE_DPAD).
Because of being a SOURCE_CLASS_JOYSTICK, only the second entry is registered, and I opened it.
When I press one arrow key, the java method "onKey(...)" is called.
The Source "event.getSource()" is "SOURCE_KEYBOARD", so it enters this conditions :
if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {
And then, it enters :
SDLActivity.onNativePadDown() (native code in "SDL_sysjoystick.c")
Since the "arrows" are viewed as "D-PAD", it gets translated :
int button = keycode_to_SDL(keycode);
But the android-java "event.getDeviceId()" is wrong: this is the one from the Keyboard, and not the one from the Joystick that I have opened.
So I don't get them through the Joystick interface.
And since, the keycode has been translated, it returns 0 and assume it was consumed.
So I lost the key in the function "Android_OnPadDown()"
Notice, It won't happen with other normal "letters" keys because they does not get translated by "keycode_to_SDL", so "Android_OnPadDown()" returns -1.
And then java code send the keys to "SDLActivity.onNativeKeyDown()".
Possible patch on "Android_OnPadDown" and also "Android_OnPadUp" (and maybe other functons):
85 int
186 Android_OnPadDown(int device_id, int keycode)
187 {
188 SDL_joylist_item *item;
189 int button = keycode_to_SDL(keycode);
190 if (button >= 0) {
191 item = JoystickByDeviceId(device_id);
192 if (item && item->joystick) {
193 SDL_PrivateJoystickButton(item->joystick, button , SDL_PRESSED);
194 }
+ else return -1;
195 return 0;
196 }
197
198 return -1;
199 }
It would allow the java caller function to send the key to "SDLActivity.onNativeKeyDown();"
Another solution, would be to replace:
if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {
by
if ( (event.getSource() & InputDevice.SOURCE_CLASS_JOYSTICK) != 0)
Because only "SOURCE_CLASS_JOYSTICK" devices are registered/opened.
Martin Gerhardy
Not sure - but I think there might be a logic flaw in SDL_SetWindowGrab.
The problem here is that this modifies the window flags and e.g. sets
SDL_WINDOW_INPUT_GRABBED - but the _this->grabbed_window pointer is not
yet set.
Then in SDL_UpdateWindowGrab the _this->grabbed_window pointer is only
set if the function pointer _this->SetWindowGrab is not NULL. But if
this is NULL, the _this->grabbed_window pointer is never set, but every
future call to any of the grab functions include an assert for:
SDL_assert(!_this->grabbed_window || ((_this->grabbed_window->flags &
SDL_WINDOW_INPUT_GRABBED) != 0));
That means the first call works, the second always fails and triggers
the assert.
Magnus Bjerke Vik
This causes issues when for instance using the joystick API to make an Android phone rotate an object by rotating the phone. When the absolute value of an axis reported by android is larger than earth gravity, SDL will overflow the Sint16 value used for joystick axes, causing sporadic movements when close to the gravity. Just holding the phone so that e.g. Y points directly upwards will make it unstable, and even more if you just tap the phone gently from below (increasing the acceleration).
More detailed: SDLActivity gets the accelerometer values in onSensorChanged and divides each axis by earth gravity. SDL_SYS_JoystickUpdate takes each of the axis values, multiplies them by 32767.0 (largest Sint16), and the casts them to Sint16. From this you can see that any value from Android that exceeds earth gravity will overflow the joystick axis.
A fix is to clamp the values so that they won't overflow the Sint16.
Simon Deschenes
My build system still shows warning as errors.
The first warning says that the member named instances can never be false (or NULL) as it is a static array, and we should check for instances[index] which we do anyway.
Ozkan Sezer
pthread/SDL_syssem.c requires _GNU_SOURCE predefined (like SDL_sysmutex.c),
otherwise sem_timedwait() prototype might not be available to it. Problem
seen with glibc-2.3.4.
If the allocation of an SDL_Touch failed, the number of touch devices was still
increased. Later access of the SDL_Touch would then have dereferenced the NULL.
Joe Thompson
This is a regression. The changes to fix#2460 cause the EnumJoysticksCallback() function to return without adding devices (Line 345 in SDL-0a2b6bc7005f\src\joystick\windows\SDL_dinputjoystick.c).
Looking at dinput.h on my system, at least DI8DEVTYPE_DRIVING and DI8DEVTYPE_FLIGHT need to be added to the test.
It might be better to check if (devtype == DI8DEVTYPE_SUPPLEMENTAL) rather than checking if it is NOT EQUAL to a long list of types. Or check if the device is already in the list.
This happens when the pointer is grabbed, but it's not clear if this is a
bug in x.org or my misunderstanding of the XGrabPointer() documentation.
At any rate, we'll want to revisit this later for a better solution.
Fixes Bugzilla #2963.
Make note to send it, and send next time we SDL_PumpEvents().
Otherwise, we might be trying to use malloc() to push a new event on the
queue while a signal is interrupting malloc() elsewhere, usually causing a
crash.
Fixes Bugzilla #2870.
This was the only thing that made SDL_config.h generate differently between
32 and 64-bit versions of Linux, so instead we force a function cast in our
X11 code to match our dynamic loader version, which removes the compile error
on some machines that prompted this test in the first place.
Xlib never wrote to this data, so if you're on an older Xlib where this param
wasn't const, your data should still be intact when we force the caller to
think it was actually const after all.
Fixes Bugzilla #1893.
Fixes Bugzilla #2895.
His notes:
The following trivial changes make SDL2 tree (mostly) compatible with Visual
Studio 2005:
* SDL_stdlib.c: Similar to VS2010 and newer, VS2005 also generates memcpy(),
(it also generates memset(), see below), so propagate the #if condition to
cover VS2005.
* SDL_pixels.c (SDL_CalculateGammaRamp): VS2005 generates a memset() call for
gamma==0 case, so replace the if loop with SDL_memset().
* SDL_windowsvideo.h: Include msctf.h only with VS2008 and newer, otherwise
include SDL_msctf.h
* SDL_windowskeyboard.c: Adjust the #ifdefs so that SDL_msctf.h inclusion is
always recognized correctly.
Fixes Google Chrome, etc, freezing up when SDL owns the clipboard selection
and actually sends thems the correct text for pasting. Confirmed working with
Unicode strings in UTF-8 format.
There were a few tweaks in this patch, but the specific fix is that
event.xselection.target in the SelectionNotify event we send back in reply
must be set to the same atom as the request ("TARGETS" in this case), and
we failed to do that in this special case. Things that don't ask for a target,
like the Gnome Terminal app, worked fine because they don't ask for TARGETS
and just go right to asking for a UTF8_STRING, and Mozilla apparently just
was more liberal in what they accepted in reply.
Chrome would reject our wrong reply and freeze up waiting for a valid one.
Someone should fix that in Chrome, too. :)
Fixes Bugzilla #2926.
Roberto
I have debugged the code checking the function calls when Direct3D is the renderer, remember that with software and OpenGL renderers, this issue is not happening.
- Create the texture:
SDL_Texture *pTex = SDL_CreateTexture(pRenderer, iFormat, SDL_TEXTUREACCESS_TARGET, pSurf->w, pSurf->h);
- Update the texture:
SDL_UpdateTexture(pTex, NULL, pSurf->pixels, pSurf->pitch);
SDL_render.c, SDL_UpdateTexture(): return renderer->UpdateTexture(renderer, texture, rect, pixels, pitch);
SDL_render_d3d.c, D3D_UpdateTexture(): if (D3D_UpdateTextureRep(data->device, &texturedata->texture, texture->format, rect->x, rect->y, rect->w, rect->h, pixels, pitch) < 0) {
SDL_render_d3d.c, D3D_UpdateTextureRep(): if (D3D_CreateStagingTexture(device, texture) < 0) {
SDL_render_d3d.c, D3D_CreateStagingTexture(): result = IDirect3DDevice9_CreateTexture(..., D3DPOOL_SYSTEMMEM, ...) --> FAIL! with INVALIDCALL code
After checking a bit the Microsoft documentation, I found this:
D3DUSAGE_RENDERTARGET can only be used with D3DPOOL_DEFAULT. (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172625%28v=vs.85%29.aspx)
The call that fails, is using D3DUSAGE_RENDERTARGET with D3DPOOL_SYSTEMMEM which is unsupported, hence the INVALIDCALL return code.
The window needs to catch ClientMessage events for one specific window, but
XNextEvent() catches everything, and XWindowEvent doesn't catch ClientMessage,
so we need predicate procedure and XIfEvent() here.
Fixes Bugzilla #2980.
These events accidentally slipping in sometimes appears to be a bug (or
maybe new behavior) in 10.10, as previous versions of Mac OS X don't appear
to ever trigger this.
Thanks to Paulo Marques for pointing out the fix on the SDL mailing list!
Fixes Bugzilla #2842 (again).
Zack Middleton
The change to the keymap to use SDL_SCANCODE_TO_KEYCODE in SDL_x11keyboard.c causes all SDL scancodes without a Usc4 character to be XOR'd with SDLK_SCANCODE_MASK, but not all key code are suppose to be (as seen in include/SDL_keycodes.h). SDLK_BACKSPACE is not 0x4000002A.
I think the full list of keys affected are return, escape, backspace, tab, and delete.
Volumetric
The "Unknown touch device" message appears because the initial touch device setup loop uses SDL_GetTouch() as a guard for calling SDL_AddTouch(). SDL_GetTouch() will always report "Unknown touch device" since the device hasn't been added yet. The SDL_GetTouch() call is unnecessary since SDL_AddTouch() calls SDL_GetTouchIndex() to verify that the device hasn't been added yet, and SDL_GetTouchIndex() has the benefit of not reporting an error for a device it can't find.
Jacob Lee
If a user has a non-standard keyboard mapping -- say, their caps lock key has been mapped to Ctrl -- then SDL_GetModState() is no longer accurate: it only considers the unmapped keys. This is a regression from SDL 1.2.
I think there are two parts to this bug: first, GetModState should use keycodes, rather than scancodes, which is easy enough.
Unfortunately, on my system, SDL considers Caps Lock, even when mapped as Control, to be both SDL_SCANCODE_CAPSLOCK and SDLK_CAPSLOCK. The output from checkkeys for it is:
INFO: Key pressed : scancode 57 = CapsLock, keycode 0x40000039 = CapsLock modifiers: CAPS
Whereas the output for xev is:
KeyPress event, serial 41, synthetic NO, window 0x4a00001,
root 0x9a, subw 0x0, time 40218333, (144,177), root:(1458,222),
state 0x10, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
XKeysymToKeycode returns keycode: 37
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
I think the problem is that X11_UpdateKeymap in SDL_x11keyboard.c only builds a mapping for keycodes associated with a Unicode character (anything where X11_KeyCodeToUcs returns a value). In the case of caps lock, SDL scancode 57 becomes x11 keycode 66, which becomes x11 keysym 65507(Control_L), which does not have a unicode value.
To fix this, I suspect that SDL needs a mapping of the rest of the x11 keysyms to their corresponding SDL key codes.
hiduei
Overview:
Initializing the Video Subsystem causes many errors though everything works as it should.
Steps to Reproduce:
1) Set Loglevel to SDL_LOG_PRIORITY_ERROR
2) Initialize the Video Subsystem (SDL_Init(SDL_INIT_VIDEO))
Actual Results:
Many errors (see attachment) are printed on stderr, then the application continues as expected.
Expected Results:
The errors should have been warnings at most.
Andreas Ragnerstam
I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected.
Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in.
I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events.
I get the same error on both X11 and Windows.
The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.
Apparently you might get strange paths from GetModuleFileName(), such as
short path names or UNC filenames, so this avoids that problem. Since you have
to tapdance with linking different libraries and defining macros depending on
what Windows you plan to target, we dynamically load the API we need, which
works on all versions of Windows (on Win7, it'll load a compatibility wrapper
for the newer API location).
What a mess.
This also now does the right thing if there isn't enough space to store the
path, looping with a larger allocated buffer each try.
Fixes Bugzilla #2435.
Jason Wyatt
Currently the keymapnotify event handling is commented out as FIXME in SDL_x11events.c (It looks like this may have functioned SDL1.2).
Not handling this event means that if a window manager shortcut such as ALT+SPACE is used, SDL will send an ALT key down signal, but not an up signal. Also querying SDL about the key state, it believes the ALT key remains pressed.
X passes the events keypress (alt), ?focusout?, ?focusin?, keymapnotify.
This lets windows know when they are dropping a mouse event because their
hit test reported something other than SDL_HITTEST_NORMAL. It lets them know
exactly where in the event queue this happened.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
This is currently implemented for X11, Cocoa, Windows, and DirectFB.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
This allows an app to know when a set of drops are coming in a grouping of
some sort (for example, a user selected multiple files and dropped them all
on the window with a single drag), and when that set is complete.
This also adds a window ID to the drop events, so the app can determine to
which window a given drop was delivered. For application-level drops (for
example, you launched an app by dropping a file on its icon), the window ID
will be zero.
Specifically: always on top, skip taskbar, tooltip, utility, and popup menu.
This is currently only implemented for X11.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
Notably: it sets the error string to inform you that your custom SDL is built
without xrandr support, which apparently has been a support issue for
Unreal Engine 4 developers.
This is often useful for SDL apps that aren't meant to be games: the
integrated GPU starts up faster, uses less power, and is often more than
fast enough.
Note that even with this change, the app will still default to the more
powerful, discrete GPU if one is available; an app that prefers the integrated
GPU will still need the NSSupportsAutomaticGraphicsSwitching key properly
set in its Info.plist and Mac OS X 10.7 or later.
https://developer.apple.com/library/mac/qa/qa1734/_index.html
Martin Gerhardy
According to https://msdn.microsoft.com/de-de/library/2kzt1wy3%28v=vs.120%29.aspx when one is using /MT for msvc compilations the libcmt.lib is already linked to the binary. This lib includes the symbol that is now guarded (see attached patch) by the #ifndef _MT.
I don't know if any joysticks report those usages for any buttons in practice, but other prominent Mac gaming software exposes them, so we might as well too.
xaudio2 is not linked against sdl but the sdk already handles dynamically loading (XAudio2Create is inlined and just loads a com object). Updated SDL_xaudio2.c
DXGI fails to report any displays in at least one of the
"Windows App Certification Kit 10.0"'s tests for Store Apps. This was
causing SDL's video initialization code to fail, when the suspect test
("Direct3D Feature Test") was run, as DXGI was unable to report a
display-output at adapter-index 0, output-index 0.
The workaround that is applied here attempts to detect this case, then
use a hopefully-reasonable alternative means to calculate at least one
display output.
"UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs.
This set of changes updates SDL's WinRT backends to support the Win10 flavor
of WinRT. It has been tested on Win10 on a desktop. In theory, it should
also support Win10 on other devices (phone, Xbox One, etc.), however further
patches may be necessary.
This adds:
- a set of MSVC 2015 project files, for use in creating UWP apps
- modifications to various pieces of SDL, in order to compile via MSVC 2015 +
the Win10 API set
- enables SDL_Window resizing and programmatic-fullscreen toggling, when using
the WinRT backend
- WinRT README updates
WinRT 8.0 (Phone and non-Phone) didn't offer an API to set an already-created
thread's priority. WinRT 8.1 offered this API, along with several other
Win32 thread functions that were previously unavailable (in WinRT).
This change makes WinRT 8.1+ platforms use SDL's Win32 backend.
This change-set fixes a lot of windowing related bugs, especially with
regards to Windows 8.x apps running on Windows 10 (which was the driver for
this work). The primary fixes include:
* listed display modes were wrong, especially when launching apps into a
non-fullscreen space
* reported window flags were often wrong, especially on Windows 10
* fullscreen/windowed mode switches weren't failing (they are not
programmatically possible in Win 8.x apps).
This change has also been tested as buildable + runnable on Win32 + MSVC 2015,
2013, 2012, and 2010. It may fix similar build errors (in XInput code) that
are appearing in MingW builds (on buildbot).
They were not needed internally since the switch to the common EGL backend.
Thanks to the SDL mailing list for pointing out that the functions seem unused.
The Y coordinate is flipped in Cocoa, so if you change the height, the window
will move and maybe clip against the screen edge if you don't adjust its Y
coordinate to match.
Possibly fixes Bugzilla #3066.
Unity's window manager is (legitimately, since it moves the client window's
position) sending one, and SDL was incorrectly trying to mask it out. Other
window managers (KWin, apparently) don't move the window and would hang here
indefinitely.
Fixes Bugzilla #3052.
Martin Gerhardy
Just a minor thing, but a huge outcome. All the other jni related functions already have those flags, but the nativeInit function lacks them - so it might be stripped away.
In extremely rare cases, probably due to misconfigured drivers, one might
see this happen, and rather than terminate the process, we try to recover
by reporting an error to the app.
Fixes Bugzilla #3068.
Note that extra steps must be taken when using glReadPixels to read the contents of the main OpenGL ES framebuffer on iOS, if multisampling is used. See the OpenGL ES section of README-ios.md for details.
There are platforms it isn't implemented on (and currently can't be
implemented on!), and there's currently no way for an app to know this.
This shouldn't break ABI on apps that moved to a revision between 2.0.3 and
2.0.4.
This relies on a successful SDL_Init(SDL_INIT_VIDEO) to work, since it's
silly to reproduce all the Xinerama/XRandR code in the message box parts. If
X11 is available but SDL hasn't been initialized, the message box will center
in the primary screen, which will be positioned weirdly on multi-head setups,
but this should fix the most significant common case.
Sam Lantinga
Ryan C. Gordon
Mark Callow
Alex Szpakowski
Patrice Mandin
David Ludwig
Ethan Lee
Brandon Schaefer
Ozkan Sezer
ouned
Philipp Wiesemann
Olli Kallioinen
Bastien Bouclet
Charlie Birks
Patrick Monaghan
Joshua Granick
Juha Kuikka
Drew Bliss
James Legg
R?mi Verschelde
Jessica Stokes
Misty De Meo
Thomas Perl
Alex Baines
Csongor Szabo
Steffen Pankratz
Eric Wing
Bill Lash
Magnus Bjerke Vik
Bastien Nocera
Jonathan Dowland
Alon Zakai
Boris Gjenero
Jukka Jyl?nki
TelpeNight
Jonas ?dahl
Mikkel Krautz
bschaefer
Colby Klein
Jason Wyatt
Edward Rudd
andrewb
Alfred Reynolds