This should remain binary compatible with Windows XP, as we dynamically
load anything we need and fall back to DirectSound/WinMM/XAudio2 if not
available.
K_NORMTAB, K_SHIFTTAB, K_ALTTAB, K_ALTSHIFTTAB
In the normal case we'll load all the keymaps from the kernel, but this reduces the size of the SDL library for the fallback case when we can't get to the tty.
Rob
I've ran into an issue where I successfully receive SDL_KEY[UP,DOWN] events but not SDL_TEXTINPUT or SDL_TEXTEDITING. In my case the code in SDL_EVDEV_do_text_input() is returning early (on error) prior to calling SDL_SendKeyboardText(). I'm running on the RaspberryPi 3, without X11.
In SDL_EVDEV_do_text_input() there is a condition to check keysyms with a type value below 0xf0, then subtract 0xf0 from type. Without understanding the purpose of this code, I disabled it, recompiled, and I'm getting correct SDL_TEXTINPUT events. I'm going to guess that my hack/fix is going to be problematic in some other environment, but after some initial testing it looks like everything is running fine in my setup.
tvc
I believe this patch should fix it, instead of looping through all the tty's and seemingly selecting the wrong one and corrupting the console I've just made SDL open /dev/tty which is the console attached to the current process anyway.
Rob
When calling ioctl(fd, KDGKBTYPE, &type) in SDL_EVDEV_is_console(), we declare type as an 'int'. This should be a 'char'. The subsequent syscall, and kernel code, only writes the lower byte of the word.
See: http://lxr.free-electrons.com/source/drivers/tty/vt/vt_ioctl.c?v=4.4#L399
ucval = KB_101;
ret = put_user(ucval, (char __user *)arg);
I've observed intermittent behavior related to this, and I can force an error condition by using an int initialized to 0xFFFFFFFF. The resulting ioctl will set type to 0XFFFFFF02, and the conditional return in SDL_EVDEV_is_console() will fail.
Recommend changing to char, or masking off unused bits.
felix
Compiling even a simple SDL2 'hello world' program with gcc -Wstrict-prototypes (GCC 6.2.1) results in warnings like:
/usr/include/SDL2/SDL_gamecontroller.h:143:1: attention : function declaration isn't a prototype [-Wstrict-prototypes]
extern DECLSPEC int SDLCALL SDL_GameControllerNumMappings();
^~~~~~
It seems there is a missing 'void' between the parentheses.
Weitian Leung
Just moved ibus direct call to SDL_IME_* related functions, and adds fcitx IME support (uses DBus, too),
enable with env: SDL_IM_MODULE=fcitx (ibus still the default one)
tvc
I've spent the last few days implementing touchscreen support in core/linux/SDL_evdev.c. It's fairly rudimentary at the moment, as can be seen from the multiple TODO's and FIXME's littered throughout, but I'm mainly submitting this patch for review. I've tested this patch on my Raspberry Pi 2 with the official touchscreen and it works fantastically, reporting all 10 multitouch points. I'm happy to work on this further, the evdev logic also needs a bit of a cleanup I think (I may have included a few changes). But if it's good enough in its current state to be committed then I'm sure there'd be plenty of people pleased, as currently the only other framework/library that supports touchscreens on the Raspberry Pi is Kivy.
Moved this code from winmm into core so both can use it.
DirectSound (at least on Win10) also returns truncated device names, even
though it's handed in as a string pointer and not a static-sized buffer. :/
Win10's 'GamepadAdded' event seems to need to have something registered with it
in order for Xinput-based gamepad detection to work. This 'fix' simply causes
a dummy event-handler to be added for this event, in case an app wants to use
gamepads on Xbox One (most likely).
