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. :/
--HG--
extra : amend_source : 1ee0edcba3b9e8ca6426e07ff45b53f4541d2ff2
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).
"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
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).
