Thu, 28 May 2015 18:57:57 -0700Fixed building test programs on the iOS simulator
Sam Lantinga [Thu, 28 May 2015 18:57:57 -0700] rev 9681
Fixed building test programs on the iOS simulator

Thu, 28 May 2015 18:57:10 -0700Fixed clip rectangle calculation when there is a viewport offset
Sam Lantinga [Thu, 28 May 2015 18:57:10 -0700] rev 9680
Fixed clip rectangle calculation when there is a viewport offset

Thu, 28 May 2015 12:55:01 -0700Fixed bug 2054 - SDL_GetError: "Unknown touch device"
Sam Lantinga [Thu, 28 May 2015 12:55:01 -0700] rev 9679
Fixed bug 2054 - SDL_GetError: "Unknown touch device"

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.

Thu, 28 May 2015 12:48:20 -0700Fixed bug 2096 - Mapping from scancode to keycode doesn't work for remapped modifier keys
Sam Lantinga [Thu, 28 May 2015 12:48:20 -0700] rev 9678
Fixed bug 2096 - Mapping from scancode to keycode doesn't work for remapped modifier keys

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.

Thu, 28 May 2015 15:36:27 -0400Windows SDL_GetBasePath: free string on failure.
Ryan C. Gordon [Thu, 28 May 2015 15:36:27 -0400] rev 9677
Windows SDL_GetBasePath: free string on failure.

Thu, 28 May 2015 15:32:45 -0400Windows GetBasePath: fixed reallocation code.
Ryan C. Gordon [Thu, 28 May 2015 15:32:45 -0400] rev 9676
Windows GetBasePath: fixed reallocation code.

Thu, 28 May 2015 15:29:43 -0400Windows SDL_GetBasePath: Fixed wrong variable when growing the buffer size.
Ryan C. Gordon [Thu, 28 May 2015 15:29:43 -0400] rev 9675
Windows SDL_GetBasePath: Fixed wrong variable when growing the buffer size.

Thu, 28 May 2015 12:31:25 -0700Fixed bug 2210 - Initializing Video produces unnecessary errors
Sam Lantinga [Thu, 28 May 2015 12:31:25 -0700] rev 9674
Fixed bug 2210 - Initializing Video produces unnecessary errors

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.

Thu, 28 May 2015 12:18:05 -0700Fixed bug 2367 - Bad mouse motion coordinates with two windows where one has changed logical size
Sam Lantinga [Thu, 28 May 2015 12:18:05 -0700] rev 9673
Fixed bug 2367 - Bad mouse motion coordinates with two windows where one has changed logical size

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.

Thu, 28 May 2015 12:06:48 -0700Fixed compiling and tested on Windows
Sam Lantinga [Thu, 28 May 2015 12:06:48 -0700] rev 9672
Fixed compiling and tested on Windows