Kai Sterker
SDL2 on Haiku so far uses Haiku-specific APIs for loading dynamic objects as add-ons, instead of using dlopen to load them as libraries. This, for example, leads to SDL_mixer not being able to load its audio backends, when compiled with standard settings.
As discussed at https://www.freelists.org/post/haikuports/SDL2-mixer-ogg-music-not-playing-and-other-stuff,2 , the best way to deal with this would be using dlopen instead of load_add_on. The following patch implements this change by dropping the Haiku-specific bits and using dlopen instead.
/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c: In function 'calc_swizzle32':
/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c:127:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
const vector unsigned char plus = VECUINT8_LITERAL(0x00, 0x00, 0x00, 0x00,
^
Kai Sterker
Apparently, SDL2 on Haiku does not generate SDL_TEXTINPUT events.
Attached is a patch that adds this functionality.
Tested with SDLs own checkkeys program and different keymaps as well as my own SDL application and German keyboard layout to verify it generates the expected input.
Albert Casals
On a RaspberryPI, it might become convenient to specify the Dispmanx layer SDL uses.
Currently, it is hardcoded to be 10000 to sit above most applications.
This can be specially useful when integrating other graphical apps and frameworks like OMXplayer, QT5 etc.. in order to have more flexibility on their Z-order.
ny00
Unfortunately, simply checking the return codes of "onNativePadDown/Up" as previously done has its own issue:
If an SDL joystick is connected *and* opened, then a proper KeyEvent, say with keycode KEYCODE_BUTTON_1, should lead to an SDL joystick button event as expected.
If, however, the joystick was *not* opened, then "onNativePadDown/Up" will return a negative value, so before the commit from bug 3426, you could unexpectedly get a keyboard event. (In practice, you'll just get a log message, since KEYCODE_BUTTON_1 has no mapping to a proper SDL_ScanCode value, but it's still an problem).
What should still be done, though, is checking the key code itself. We do have the KeyEvent.isGamepadButton method, but according my test, it returns "true" exactly (and only) for the KEYCODE_BUTTON* values, and not for KEYCODE_DPAD* or any other key code.
Here is a possible solution:
- Do check the return codes of "onNativePadDown/Up" as previously done.
- In addition, in "Android_OnPadDown/Up" from src/joystick/android/SDL_sysjoystick.c, 0 should *always* be returned in case the key code can be translated to an SDL_joystick button; Even if no matching joystick can be found.
Philipp Wiesemann
Maybe the fault is in the SDL_VIDEO_DRIVER_WINDOWS section in SDL_InitSubSystem() of "src/SDL.c". Because there only SDL_INIT_JOYSTICK is checked. The flags are adapted for SDL_INIT_GAMECONTROLLER afterwards.
Eric Wasylishen
The patch makes StartTextInput/StopTextInput call Xutf8ResetIC ( https://www.x.org/releases/X11R7.5/doc/man/man3/XmbResetIC.3.html ) on the XIC of all SDL windows.
This fixes my use case in Quakespasm (Ubuntu 16.04, system keyboard layout set to German. Type the '^' dead key, which opens Quakespasm's developer console and calls SDL_StartTextInput, then press 'e'. I expect the dead key to be ignored.)
Also, here is a patch for sdl2's "checkkeys" for testing this: https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2451
Olav Sorensen
After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a *second* time generates an event like it should.
Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.
Simon Hug
There are currently three entry points in the SDL2_main code for windows: main, wmain and WinMain. Only the latter two properly convert the arguments to UTF-8.
Console applications linked with MSVC will always link with the main entry point (wmain has to be selected by manually setting the entry point). This makes it likely that such programs will not have proper unicode arguments.
Sylvain
After a long time, I found out more clearly what was going wrong.
The native libraries should be built with a "APP_PLATFORM" as low as possible.
Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml
So that the application never runs on a lower APP_PLATFORM than it has been built for.
An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10
(If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10.
And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".)
to precise what happened in the initial reported test-case:
Let say the "c" code contains a call to "srand()".
with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()".
with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()".
but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()).
So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10.
That was the issue. The path tried to fix this by in fact always calling srand48().
SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform.
It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions.
Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.
Robert Folland
When running this little test program with SDL2 on Wayland it often crashes in SDL_Init.
From a backtrace it is apparent that there is a race condition in creating a xkb_context_ref. Sometimes it is 0x0.
By moving the relevant lines higher up in Wayland_VideoInit (in SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302) this seems to get fixed.
I moved the call to WAYLAND_xkb_context_new() up to before the call to WAYLAND_wl_display_connect().
Here is the test program (just a loop of init and quit), and a backtrace from gdb:
#include <cstdio>
#include <stdlib.h>
#include <SDL2/SDL.h>
#include <unistd.h>
#include <iostream>
int main(int argc, char **argv)
{
int count = atoi(argv[1]);
for (int i = 0; i < count; i++) {
std::cout << "Init " << i << std::endl;
if (SDL_Init(SDL_INIT_VIDEO) < 0) {
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION,
"Couldn't initialize SDL: %s\n",
SDL_GetError());
return 1;
}
std::cout << "Quit" << std::endl;
SDL_Quit();
}
return 0;
}
Init 12
Quit
Init 13
Program received signal SIGSEGV, Segmentation fault.
xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156
156 ctx->refcnt++;
(gdb) bt
#0 xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156
#1 0x00007ffff5e1cd4c in xkb_keymap_new (ctx=0x0, format=XKB_KEYMAP_FORMAT_TEXT_V1, flags=flags@entry=XKB_KEYMAP_COMPILE_NO_FLAGS) at src/keymap-priv.c:65
#2 0x00007ffff5e1c6cc in xkb_keymap_new_from_buffer (ctx=<optimized out>,
buffer=0x7ffff7fd5000 "xkb_keymap {\nxkb_keycodes \"(unnamed)\" {\n\tminimum = 8;\n\tmaximum = 255;\n\t<ESC>", ' ' <repeats 16 times>, "= 9;\n\t<AE01>", ' ' <re
peats 15 times>, "= 10;\n\t<AE02>", ' ' <repeats 15 times>, "= 11;\n\t<AE03>", ' ' <repeats 15 times>, "= 12;\n\t<AE04>", ' ' <repeats 12 times>..., length=48090,
format=<optimized out>, flags=<optimized out>) at src/keymap.c:191
#3 0x00007ffff7b8ea4e in keyboard_handle_keymap (data=0x6169b0, keyboard=<optimized out>, format=<optimized out>, fd=5, size=48091)
at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandevents.c:269
#4 0x00007ffff64501f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#5 0x00007ffff644fc58 in ffi_call () from /usr/lib/libffi.so.6
#6 0x00007ffff665be3e in wl_closure_invoke (closure=closure@entry=0x61f000, flags=flags@entry=1, target=<optimized out>, target@entry=0x616d20,
opcode=opcode@entry=0, data=<optimized out>) at src/connection.c:949
#7 0x00007ffff6658be0 in dispatch_event (display=<optimized out>, queue=<optimized out>) at src/wayland-client.c:1274
#8 0x00007ffff6659db4 in dispatch_queue (queue=0x617398, display=0x6172d0) at src/wayland-client.c:1420
#9 wl_display_dispatch_queue_pending (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1662
#10 0x00007ffff665a0cf in wl_display_roundtrip_queue (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1085
#11 0x00007ffff7b8faa0 in Wayland_VideoInit (_this=<optimized out>) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302
#12 0x00007ffff7b7aed6 in SDL_VideoInit_REAL (driver_name=<optimized out>, driver_name@entry=0x0) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/SDL_video.c:513
#13 0x00007ffff7ae0ee7 in SDL_InitSubSystem_REAL (flags=16416) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/SDL.c:173
#14 0x0000000000400b24 in main (argc=2, argv=0x7fffffffebb8) at vplay-init.cpp:13
(gdb)
Eric wing
Sometimes an SDL_assert triggers at RPI_WarpMouseGlobal
src/video/raspberry/SDL_rpimouse.c:232 'update'.
It doesn't always reproduce, but it seems to happen when you really bog down the system and the event loop can't update for awhile.
The first time I hit this, I wasn't even using the mouse. I don't call any warp mouse functions either.
I can usually reproduce with a simple program that runs an expensive blocking CPU series of functions which blocks the main loop until complete (can be up to 10 seconds).
Sometimes this assertion gets triggered after that. I'm not sure if
they are related or coincidental.
Disabling the SDL_asserts when compiling SDL will avoid this problem. I actually haven't seen any problems with the mouse when I do this.
On a Raspberry Pi 2 running Raspbian Jessie.
Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.
Daniel Gibson
Ok, I followed the simple approach of just making SDL_PIXELFORMAT_RGBA32 an alias of SDL_PIXELFORMAT_RGBA8888/SDL_PIXELFORMAT_ABGR8888, depending on endianess. And I did the same for SDL_PIXELFORMAT_ARGB32, .._BGRA, .._ABGR.
SDL_GetPixelFormatName() will of course return SDL_PIXELFORMAT_RGBA8888 (or SDL_PIXELFORMAT_ABGR8888) instead of SDL_PIXELFORMAT_RGBA32, but as long as that's mentioned in the docs it shouldn't be a problem.
Apparently some systems see "hw:", some see "default:" and some see
"sysdefault:" (and maybe others!). My workstation sees both "hw:" and
"sysdefault:" ...
Try to find a prefix we like and prioritize the prefixes we (think) we want
most. If everything else fails, if there's a "default" (not a prefix) device
name, list that by itself so the user gets _something_ here.
If we can't find a prefix we like _and_ there's no "default" device, report
no hardware found at all.
