Fri, 11 Aug 2017 19:36:12 -0700Fixed bug 3341 - SDL_sscanf() problem
Sam Lantinga [Fri, 11 Aug 2017 19:36:12 -0700] rev 11227
Fixed bug 3341 - SDL_sscanf() problem

e_pluschauskas

Why does SDL_sscanf() always returns the number of format specifiers and doesn't implements standard C library behavior?

Fri, 11 Aug 2017 18:56:41 -0700Fixed crash in bug 3367 - RGBA_FROM_PIXEL macro can't handle SDL_PIXELFORMAT_ARGB2101010
Sam Lantinga [Fri, 11 Aug 2017 18:56:41 -0700] rev 11226
Fixed crash in bug 3367 - RGBA_FROM_PIXEL macro can't handle SDL_PIXELFORMAT_ARGB2101010

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/b82c0f22d22a/src/video/SDL_blit.h#l303
[2] https://hg.libsdl.org/SDL/file/b82c0f22d22a/src/video/SDL_pixels.c#l540

Fri, 11 Aug 2017 13:37:40 -0700Fixed bug 3464 - Fix for Android hint SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH
Sam Lantinga [Fri, 11 Aug 2017 13:37:40 -0700] rev 11225
Fixed bug 3464 - Fix for Android hint SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH

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.

Fri, 11 Aug 2017 13:24:18 -0700Fixed bug 3492 - SDL_RenderCopyEx angle direction not documented
Sam Lantinga [Fri, 11 Aug 2017 13:24:18 -0700] rev 11224
Fixed bug 3492 - SDL_RenderCopyEx angle direction not documented

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.

Fri, 11 Aug 2017 11:54:24 -0700Fixed bug 3324 - SDL_RenderReadPixels: Wrong rect coordinates with software renderer
Sam Lantinga [Fri, 11 Aug 2017 11:54:24 -0700] rev 11223
Fixed bug 3324 - SDL_RenderReadPixels: Wrong rect coordinates with software renderer

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.

Fri, 11 Aug 2017 11:32:00 -0700Fixed bug 3639 - SDL_GetPrefPath returns a path with two consecutive slashes on Unix if org is omitted
Sam Lantinga [Fri, 11 Aug 2017 11:32:00 -0700] rev 11222
Fixed bug 3639 - SDL_GetPrefPath returns a path with two consecutive slashes on Unix if org is omitted

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.

Fri, 11 Aug 2017 10:42:26 -0700Fixed bug 3646 - SDL_test_common.c: Add key bindings for testing SDL_SetWindowPosition
Sam Lantinga [Fri, 11 Aug 2017 10:42:26 -0700] rev 11221
Fixed bug 3646 - SDL_test_common.c: Add key bindings for testing SDL_SetWindowPosition

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

Fri, 11 Aug 2017 10:32:47 -0700Fixed bug 3682 - Toggle text input in checkkeys when the mouse is clicked
Sam Lantinga [Fri, 11 Aug 2017 10:32:47 -0700] rev 11220
Fixed bug 3682 - Toggle text input in checkkeys when the mouse is clicked

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:

Fri, 11 Aug 2017 10:21:19 -0700Fixed bug 3702 - Clear error messages of SDL_LoadObject for optional libraries
Sam Lantinga [Fri, 11 Aug 2017 10:21:19 -0700] rev 11219
Fixed bug 3702 - Clear error messages of SDL_LoadObject for optional libraries

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.

Fri, 11 Aug 2017 10:18:45 -0700Fixed bug 3714 - Windows: SDL_WINDOW_FULLSCREEN_DESKTOP broken on 3 monitor setup w/ DPI scaling
Sam Lantinga [Fri, 11 Aug 2017 10:18:45 -0700] rev 11218
Fixed bug 3714 - Windows: SDL_WINDOW_FULLSCREEN_DESKTOP broken on 3 monitor setup w/ DPI scaling

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:43c7baa53681)
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.