Disabling RAWINPUT on Windows 10 causes these issues:
* All Xbox controllers are named "XInput Controller".
* Trigger rumble no longer works.
* "XInput Controllers" are now also listed as separate haptic devices
It's only needed to support more than 4 Xbox controllers, and adds significant complexity to the joystick processing, and we regularly get bugs from people who aren't using an SDL window who need to turn on SDL_HINT_JOYSTICK_THREAD.
Replace instances of fprintf(stderr, ...) with SDL_SetError(), replace C++ comments with C style, use a uniform format for multi-line comments, and remove unused headers as poll and select aren't used in this file (the SDL function which calls them is used instead).
libdecor_dispatch() needs to be called, as libdecor plugins might do some required internal processing within, however care must be taken to avoid double-blocking in the case of a timeout, which can occur if libdecor_dispatch() and the SDL event processing both work on the main Wayland queue. Additionally, assumptions that libdecor will always dispatch the main queue or not process zero-length queues (can occur if a wait is interrupted by the application queueing an event) should not be made, as this behavior is outside the control of SDL and can change.
SDL handles polling for Wayland events and then calls libdecor to do its internal processing and dispatch. If libdecor operates on the main queue, it will dispatch the queued events and the additional wl_display_dispatch_pending() call will be a NOP. If a libdecor plugin uses its own, separate queue, then the wl_display_dispatch_pending() call will ensure that the main queue is always dispatched.
Fixes battery level dropping to empty with the Qanba Drone Arcade Stick.
It looks like we might also be able to skip the check for all third party controllers, but I think this is the right thing to do for Sony controllers as well.
In all cases they were using SDL_SCANCODE_TABLE_XFREE86_2 with some keycodes remapped or fewer than expected keycodes. This adds a sanity check that catches all of them and gives them the right scancode table.
If we can't find the X11 keysym, it's likely that either the keysym is NoSymbol, in which case we won't hit it anyway, or it's been mapped to a character, in which case the existing mapping is correct for the scancode and the character will be reflected in the keycode mapping.
* Consolidated scancode mapping tables into a single location for all backends
* Verified that the xfree86_scancode_table2 is largely identical to the Linux scancode table
* Updated the Linux scancode table with the latest kernel keycodes (still unmapped)
* Route X11 keysym -> scancode mapping through the linux scancode table (which a few hand-written exceptions), which will allow mappings to automatically get picked up as they are added in the Linux scancode table
* Disabled verbose reporting of missing keysym mappings, we have enough data for now
The original code mapped incorrectly from [min, max] to [-32768, 32512], the upper bound being SDL_JOYSTICK_AXIS_MAX - 255 instead of SDL_JOYSTICK_AXIS_MAX.
If this assertion fails on some platform (unlikely), we will need a
third implementation for SwapLongLE().
Signed-off-by: Simon McVittie <smcv@collabora.com>
The check for whether to use a 32- or 64-bit swap for an array of long
values always took the 64-bit path, because <limits.h> wasn't included
and therefore ULONG_MAX wasn't defined. Turn this into a runtime check,
which a reasonable compiler will optimize into a constant.
This fixes testevdev failures on 32-bit big-endian platforms such as hppa
and older powerpc. Little-endian and/or 64-bit platforms are unaffected.
[smcv: Added commit message]
Bug-Debian: https://bugs.debian.org/1021310
Co-authored-by: Simon McVittie <smcv@collabora.com>
Sylvain
Sam Lantinga
Deve
David Jacewicz
Wouter Wijsman
Brad Smith
Frank Praznik
Daniel Bomar
happyharryh
Cameron Gutman
Pierre Wendling
Simon McVittie
Ryan C. Gordon
Desour
Helge Deller
Ethan Lee
zhailiangliang