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.
Otherwise, SDL_PIXELFORMAT_BGR24 is reported as having alpha, because
its SDL_ARRAYORDER_BGR pixel order uses the same integer value as
SDL_PACKEDORDER_RGBA, since we weren't checking the pixel type to
differentiate.
Fixes Bugzilla #2977.
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.
