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
ny00
According to the current documentation in SDL_hints.h, if SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH is set to "0" (or not set at all) then mouse input should lead to touch events, along with corresponding *fake* mouse events with mouse id SDL_TOUCH_MOUSEID.
However, while moving a mouse around (actually using a trackpad identified as a mouse), I get SDL mouse motion events with differing mouse ids, as follows:
- If the mouse is moved while a mouse button is pressed, the mouse id is SDL_TOUCH_MOUSEID.
- Otherwise, the mouse id for mouse motion events is 0.
I've attached sample code for reference, which includes logs of the various mouse events (the "which" field is covered).
I believe that no actual mouse event should arrive, if the hint is unset. In particular, no mouse motion event should arrive while no mouse button is pressed.
I'm going to attach a patch which resolves this, while also disabling mouse wheel motion events.
xyzdragon
Reading https://wiki.libsdl.org/SDL_RenderCopyEx there is no mention what the angle means. Normally in a mathematically environment positive angles translate to counter-clockwise rotations, but in SDL positive angles means clockwise rotation.
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
Eric Wasylishen
Small change to checkkeys so you can toggle text input mode with a mouse click.
This is needed for testing how dead keys react to toggling mouse input, i.e. these bugs:
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.
Sylvain
On Android, when shared libraries are not correctly loaded (eg SDLActivity.mBrokenLibraries is true), there is a pop-up with an error message.
After user dismisses the pop-up, application crashes:
- because the native function "nativePause()" may no be loaded (if libSDL2.so is not loaded).
- because mSurface is null.
tschwinger@elitemail.org
Most ironically, although autoconf/automake-based builds install (pretty half-assed) CMake package configuration files, they're missing in installations resulting from CMake-based builds entirely.
A proper configuration file typically also loads target exports (implemented in patch 3572, also fixing this issue - see my comment on that issue for details).
I believe it would be best to let the dinosaurs go extinct and redirect all build efforts to the CMake end for two reasons:
1. It potentially provides the best user experience, but you'd have to give it some love and ship with less quirky buildfiles.
2. It would force distros to build SDL via CMake and thus would ensure target exports are actually available everywhere.
Various CMake patches I submitted today in summary (directly converted from the HG commits and `am`d onto a fork of a git mirror that happened to be on `tip`).
https://github.com/tschw/SDL/commits/patched
Fixing #2576#3572, #3613, and this fresh ticket, which is almost entirely advertisement ;).
These already do to make SDL much less of a quirky fella to have in your dependency tree...
Martin Gerhardy
- list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CLFAGS} ${XKB_CLFLAGS})
+ list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CFLAGS} ${XKB_CFLAGS})
CFLAGS is spelled wrong in two different ways for EGL and XKB
And while you are on it...
sdl needs mir >= 0.24 afaik - it fails on travis-ci (ubuntu 14.04 LTS with 0.18 installed and in other environments, too (e.g. https://github.com/urho3d/Urho3D/issues/1685)
To fix this one should add a min version check to pkg_check_modules like this
- pkg_check_modules(MIR_TOOLKIT mirclient mircommon)
+ pkg_check_modules(MIR_TOOLKIT mirclient>=0.24 mircommon)
-Enabling checking for GCC_ATOMICS also on clang by default. This way all Android ABIs build successfully
-Android cmake: Threading was not enabled correctly
-Android cmake: Timers and dynamic lib loading were not included in the sources
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".
