Sat, 06 Jun 2015 22:45:22 -0400RPi: Patched to compile without OpenGL (thanks, Simon!), other cleanups.
Ryan C. Gordon <icculus@icculus.org> [Sat, 06 Jun 2015 22:45:22 -0400] rev 9711
RPi: Patched to compile without OpenGL (thanks, Simon!), other cleanups.

Fixes Bugzilla #3003.

Fri, 05 Jun 2015 19:41:34 +0200Fixed comments at conditional compilation macro in header file.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Fri, 05 Jun 2015 19:41:34 +0200] rev 9710
Fixed comments at conditional compilation macro in header file.

Fri, 05 Jun 2015 19:41:18 +0200Fixed comments at conditional compilation macros.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Fri, 05 Jun 2015 19:41:18 +0200] rev 9709
Fixed comments at conditional compilation macros.

Fri, 05 Jun 2015 19:40:50 +0200Android: Added deactivated intent filter for testing drop file support.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Fri, 05 Jun 2015 19:40:50 +0200] rev 9708
Android: Added deactivated intent filter for testing drop file support.

Thu, 04 Jun 2015 19:05:01 -0400Fixed docs path in RPM .spec file.
Ryan C. Gordon <icculus@icculus.org> [Thu, 04 Jun 2015 19:05:01 -0400] rev 9707
Fixed docs path in RPM .spec file.

Thu, 04 Jun 2015 15:41:39 -0400X11: Fixed SelectionRequest replies for target TARGETS.
Ryan C. Gordon <icculus@icculus.org> [Thu, 04 Jun 2015 15:41:39 -0400] rev 9706
X11: Fixed SelectionRequest replies for target TARGETS.

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.

Thu, 04 Jun 2015 10:59:02 -0400X11: Fixed compiler warnings in DEBUG_XEVENTS sections.
Ryan C. Gordon <icculus@icculus.org> [Thu, 04 Jun 2015 10:59:02 -0400] rev 9705
X11: Fixed compiler warnings in DEBUG_XEVENTS sections.

Thu, 04 Jun 2015 17:52:51 +0200AIX: Fixed nearly impossible file descriptor leak.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Thu, 04 Jun 2015 17:52:51 +0200] rev 9704
AIX: Fixed nearly impossible file descriptor leak.

Thu, 04 Jun 2015 17:52:27 +0200Fixed not needed calculation in test program.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Thu, 04 Jun 2015 17:52:27 +0200] rev 9703
Fixed not needed calculation in test program.

Thu, 04 Jun 2015 00:56:11 -0700Fixed bug 2625 - Direct3D9 with SDL_TEXTUREACCESS_TARGET textures causes an application crash
Sam Lantinga <slouken@libsdl.org> [Thu, 04 Jun 2015 00:56:11 -0700] rev 9702
Fixed bug 2625 - Direct3D9 with SDL_TEXTUREACCESS_TARGET textures causes an application crash

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.