xaudio2 is not linked against sdl but the sdk already handles dynamically loading (XAudio2Create is inlined and just loads a com object). Updated SDL_xaudio2.c
DXGI fails to report any displays in at least one of the
"Windows App Certification Kit 10.0"'s tests for Store Apps. This was
causing SDL's video initialization code to fail, when the suspect test
("Direct3D Feature Test") was run, as DXGI was unable to report a
display-output at adapter-index 0, output-index 0.
The workaround that is applied here attempts to detect this case, then
use a hopefully-reasonable alternative means to calculate at least one
display output.
"UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs.
This set of changes updates SDL's WinRT backends to support the Win10 flavor
of WinRT. It has been tested on Win10 on a desktop. In theory, it should
also support Win10 on other devices (phone, Xbox One, etc.), however further
patches may be necessary.
This adds:
- a set of MSVC 2015 project files, for use in creating UWP apps
- modifications to various pieces of SDL, in order to compile via MSVC 2015 +
the Win10 API set
- enables SDL_Window resizing and programmatic-fullscreen toggling, when using
the WinRT backend
- WinRT README updates
WinRT 8.0 (Phone and non-Phone) didn't offer an API to set an already-created
thread's priority. WinRT 8.1 offered this API, along with several other
Win32 thread functions that were previously unavailable (in WinRT).
This change makes WinRT 8.1+ platforms use SDL's Win32 backend.
This change-set fixes a lot of windowing related bugs, especially with
regards to Windows 8.x apps running on Windows 10 (which was the driver for
this work). The primary fixes include:
* listed display modes were wrong, especially when launching apps into a
non-fullscreen space
* reported window flags were often wrong, especially on Windows 10
* fullscreen/windowed mode switches weren't failing (they are not
programmatically possible in Win 8.x apps).
This change has also been tested as buildable + runnable on Win32 + MSVC 2015,
2013, 2012, and 2010. It may fix similar build errors (in XInput code) that
are appearing in MingW builds (on buildbot).
They were not needed internally since the switch to the common EGL backend.
Thanks to the SDL mailing list for pointing out that the functions seem unused.
The Y coordinate is flipped in Cocoa, so if you change the height, the window
will move and maybe clip against the screen edge if you don't adjust its Y
coordinate to match.
Possibly fixes Bugzilla #3066.
Unity's window manager is (legitimately, since it moves the client window's
position) sending one, and SDL was incorrectly trying to mask it out. Other
window managers (KWin, apparently) don't move the window and would hang here
indefinitely.
Fixes Bugzilla #3052.
Martin Gerhardy
Just a minor thing, but a huge outcome. All the other jni related functions already have those flags, but the nativeInit function lacks them - so it might be stripped away.
In extremely rare cases, probably due to misconfigured drivers, one might
see this happen, and rather than terminate the process, we try to recover
by reporting an error to the app.
Fixes Bugzilla #3068.
Note that extra steps must be taken when using glReadPixels to read the contents of the main OpenGL ES framebuffer on iOS, if multisampling is used. See the OpenGL ES section of README-ios.md for details.
There are platforms it isn't implemented on (and currently can't be
implemented on!), and there's currently no way for an app to know this.
This shouldn't break ABI on apps that moved to a revision between 2.0.3 and
2.0.4.
This relies on a successful SDL_Init(SDL_INIT_VIDEO) to work, since it's
silly to reproduce all the Xinerama/XRandR code in the message box parts. If
X11 is available but SDL hasn't been initialized, the message box will center
in the primary screen, which will be positioned weirdly on multi-head setups,
but this should fix the most significant common case.
Author: Benoit Pierre <benoit.pierre@gmail.com>
Date: Fri Jul 3 02:17:10 2015 +0200
fix 14dd48ae5bc43b61b2a0dd0b3177d22edec707ef regression
The window manager detection code in X11_HasWindowManager does not work
with Awesome (http://awesome.naquadah.org/). Remove it, and reuse the
result of the more correct checks in X11_CheckWindowManager.
Elise Maurer
When inputting text, dead-keys are currently not handled correctly on Windows with the latest SDL2 tip as well as the 2.0.3 release.
Using a French AZERTY keyboard, when I type the `^` key followed by `e` key to compose the `` character, I erroneously get two SDL_TEXTINPUT events, one with the `^` character and one with the `e` character.
I've looked at the history for SDL_windowsevents.c and there's been some back-and-forth with several methods for handling text input:
* r8142 removed any handling of WM_CHAR because keyboard input was being handled through WM_KEYDOWN along with ToUnicode since r7645.
* But using ToUnicode actually breaks dead-keys (googling for "ToUnicode dead keys" reports many horror stories of people trying to work around that and failing).
* It seems like r7645 introduced a double-fix: it fixed WM_CHAR to properly handle Unicode, and also (unnecessarily?) added text input handling to WM_KEYDOWN. Later, r8142 removed the WM_CHAR stuff instead of the WM_KEYDOWN stuff.
The attached patch restores handling of text input through WM_CHAR and removes it from WM_KEYDOWN. I've tested it with French, English and Russian layouts and it seems to do its job. Obviously, with such matters, it's still a risky change.
Sometimes, on removal SDL_EVDEV_udev_callback() gets called with zero udev_class. This in turn seems to be caused the SDL_udev.c:guess_device_class() failing to find the attributes of the parent device.
Apparently this is normal, attributes are not guaranteed to be in place during removal, depending on timing. This lack of attributes causes guess_device_class() to return zero.
This fix mimics the code in linux/SDL_sysjoystick.c:joystick_udev_callback() which effectively has the same fix already in place.
- disable compiling in XAudio2 support. We both need the DX SDK to make this code plus we need to work out the runtime dependency problem this code bring in on windows (needing the DX runtime installed).
CR: SamL
- do the scancode to keyboard code lookup for the grave key, so that we can show users the correct keyface for the key, rather than forcing it to "`". Note that if a game is using SDLK_* for its KB mapping then after this change on some keyboards the top left key will no longer be mapped correctly with the old data.
CR: SamL
Adam M.
It loses the title and icon when window recreation fails. For instance, this may happen when trying to create an OpenGL ES window on a system that doesn't support it. But at that point, the title and icon have already been lost.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
Adam M.
When setting a texture alpha mod other than 255 and also specifying a flip mode in the software renderer, the rendering fails. When the texture has an alpha channel, it becomes invisible when flipped. When the texture does not have an alpha channel, it is flipped but the colors are wrong: the alpha mod makes the texture darker rather than more translucent.
0) Initialize a software renderer.
1) Load 16-bit 565 or 32-bit texture.
2) Set texture blend mode to BLEND.
3) Set texture alpha mod to 150.
4) Draw the texture flipped horizontally and/or vertically.
Adam M.
There are three problems in the code that I see.
1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key.
2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled.
3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled).
I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and simplifies the rotation code slightly.
Adam M.
Okay, here is the problem, I think.
During the first blit, RLEAlphaSurface is called to do RLE conversion of the RGBA source into a format allowing it "to be quickly alpha-blittable onto dest". Since the destination is the screen, it has no alpha channel. RLEAlphaSurface calls copy_opaque(dst, src + runstart, len, sf, df) (where copy_opaque is copy_32), which has this code:
SDL_RLEaccel.c:984:
RGBA_FROM_8888(*src, sfmt, r, g, b, a);
PIXEL_FROM_RGBA(*d, dfmt, r, g, b, a);
On the first line, it reads the source pixel 0xFFFFFFFF. The second line drops the alpha value (because dfmt for the screen has no alpha channel) and writes 0x00FFFFFF. Later, when the RLE conversion is being undone, uncopy_32 is called, which has the following code:
SDL_RLEaccel.c:1001:
Uint32 pixel = *s++;
RGB_FROM_PIXEL(pixel, sfmt, r, g, b);
a = pixel >> 24;
PIXEL_FROM_RGBA(*dst, dfmt, r, g, b, a);
However, the the alpha channel has already been dropped by copy_opaque (= copy_32), so pixel = 0x00FFFFFF and 'a' becomes 0. Thus, all opaque pixels lose their alpha channel when being unRLE'd. (I don't know what happens to pixels with alpha from 1-254, but they should be checked too.)
So, that seems to be the problem, but I'm not sure what the solution should be. Since opaque pixels have alpha == 255, I'm thinking to create another uncopy function for opaque pixels that simply uses 255 for alpha.
However, there may be other problems here. For translucent pixels, uncopy_32 assumes the alpha channel is stored in the upper 8 bits, but copy_32 doesn't store it there. Instead, it stores it in whatever location is appropriate for the destination surface. Isn't one of their behaviors incorrect, given the other? I'm not sure which to change, however.
For translucent pixels, it seems that the blit function uses do_blend, which is the BLIT_TRANSL_888 macro, which also assumes alpha is in top 8 bits. It has the comment "we have made sure the alpha is stored in the top 8 bits...", but it seems that's not true (copy_32 doesn't make sure the alpha goes there).
Perhaps the correct fix is to make copy_32 put the alpha there, but then that seems to require that RLE conversion be limited to destination surfaces that don't use the upper 8 bits. However, looking further, it seems that has already been done: if (masksum != 0x00ffffff) return -1; /* requires unused high byte */
Sylvain
When using API 21 and running on an old device (android < 5.0 ?) some function are missing.
functions are (at least) : signal, sigemptyset, atof, stpcpy (strcat and strcpy), srand, rand.
Very few modifications on SDL to get this working :
on SDL
======
Undefine android configuration :
HAVE_SIGNAL
HAVE_SIGACTION
HAVE_ATOF
In "SDL_systrhead.c", comment out the few block of lines with "sigemptyset".
Android.mk:
remove the compilation of "test" directory because it contains a few rand/srand calls
Also, there are more discussions about this in internet :
https://groups.google.com/forum/#!topic/android-ndk/RjO9WmG9pfEhttp://stackoverflow.com/questions/25475055/android-ndk-load-library-cannot-locate-srand
Sylvain
http://developer.android.com/reference/android/view/InputDevice.html
int SOURCE_CLASS_JOYSTICK Constant Value: 16 (0x00000010)
int SOURCE_JOYSTICK Constant Value: 16777232 (0x01000010)
int SOURCE_KEYBOARD Constant Value: 257 (0x00000101)
int SOURCE_GAMEPAD Constant Value: 1025 (0x00000401)
int SOURCE_DPAD Constant Value: 513 (0x00000201)
I have an a PC keyboard that I connect to an android device.
The issue is that "arrow" keys gets lost.
More explanation:
This device gets detected twice by the java "pollInputDevices()" both as SOURCE_KEYBOARD and as a composite (0x1000311 == SOURCE_JOYSTICK | SOURCE_KEYBOARD | SOURCE_DPAD).
Because of being a SOURCE_CLASS_JOYSTICK, only the second entry is registered, and I opened it.
When I press one arrow key, the java method "onKey(...)" is called.
The Source "event.getSource()" is "SOURCE_KEYBOARD", so it enters this conditions :
if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {
And then, it enters :
SDLActivity.onNativePadDown() (native code in "SDL_sysjoystick.c")
Since the "arrows" are viewed as "D-PAD", it gets translated :
int button = keycode_to_SDL(keycode);
But the android-java "event.getDeviceId()" is wrong: this is the one from the Keyboard, and not the one from the Joystick that I have opened.
So I don't get them through the Joystick interface.
And since, the keycode has been translated, it returns 0 and assume it was consumed.
So I lost the key in the function "Android_OnPadDown()"
Notice, It won't happen with other normal "letters" keys because they does not get translated by "keycode_to_SDL", so "Android_OnPadDown()" returns -1.
And then java code send the keys to "SDLActivity.onNativeKeyDown()".
Possible patch on "Android_OnPadDown" and also "Android_OnPadUp" (and maybe other functons):
85 int
186 Android_OnPadDown(int device_id, int keycode)
187 {
188 SDL_joylist_item *item;
189 int button = keycode_to_SDL(keycode);
190 if (button >= 0) {
191 item = JoystickByDeviceId(device_id);
192 if (item && item->joystick) {
193 SDL_PrivateJoystickButton(item->joystick, button , SDL_PRESSED);
194 }
+ else return -1;
195 return 0;
196 }
197
198 return -1;
199 }
It would allow the java caller function to send the key to "SDLActivity.onNativeKeyDown();"
Another solution, would be to replace:
if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {
by
if ( (event.getSource() & InputDevice.SOURCE_CLASS_JOYSTICK) != 0)
Because only "SOURCE_CLASS_JOYSTICK" devices are registered/opened.
Martin Gerhardy
Not sure - but I think there might be a logic flaw in SDL_SetWindowGrab.
The problem here is that this modifies the window flags and e.g. sets
SDL_WINDOW_INPUT_GRABBED - but the _this->grabbed_window pointer is not
yet set.
Then in SDL_UpdateWindowGrab the _this->grabbed_window pointer is only
set if the function pointer _this->SetWindowGrab is not NULL. But if
this is NULL, the _this->grabbed_window pointer is never set, but every
future call to any of the grab functions include an assert for:
SDL_assert(!_this->grabbed_window || ((_this->grabbed_window->flags &
SDL_WINDOW_INPUT_GRABBED) != 0));
That means the first call works, the second always fails and triggers
the assert.
Magnus Bjerke Vik
This causes issues when for instance using the joystick API to make an Android phone rotate an object by rotating the phone. When the absolute value of an axis reported by android is larger than earth gravity, SDL will overflow the Sint16 value used for joystick axes, causing sporadic movements when close to the gravity. Just holding the phone so that e.g. Y points directly upwards will make it unstable, and even more if you just tap the phone gently from below (increasing the acceleration).
More detailed: SDLActivity gets the accelerometer values in onSensorChanged and divides each axis by earth gravity. SDL_SYS_JoystickUpdate takes each of the axis values, multiplies them by 32767.0 (largest Sint16), and the casts them to Sint16. From this you can see that any value from Android that exceeds earth gravity will overflow the joystick axis.
A fix is to clamp the values so that they won't overflow the Sint16.
Simon Deschenes
My build system still shows warning as errors.
The first warning says that the member named instances can never be false (or NULL) as it is a static array, and we should check for instances[index] which we do anyway.
Ozkan Sezer
pthread/SDL_syssem.c requires _GNU_SOURCE predefined (like SDL_sysmutex.c),
otherwise sem_timedwait() prototype might not be available to it. Problem
seen with glibc-2.3.4.
If the allocation of an SDL_Touch failed, the number of touch devices was still
increased. Later access of the SDL_Touch would then have dereferenced the NULL.
Joe Thompson
This is a regression. The changes to fix#2460 cause the EnumJoysticksCallback() function to return without adding devices (Line 345 in SDL-45a632fd9d83\src\joystick\windows\SDL_dinputjoystick.c).
Looking at dinput.h on my system, at least DI8DEVTYPE_DRIVING and DI8DEVTYPE_FLIGHT need to be added to the test.
It might be better to check if (devtype == DI8DEVTYPE_SUPPLEMENTAL) rather than checking if it is NOT EQUAL to a long list of types. Or check if the device is already in the list.
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.
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.
