When querying the keycode produced by a scancode with a certain set of modifiers, it would fall back to defaults if a key hash value with the exact set of modifiers wasn't found, which resulted in certain modifier combination returning incorrect keycodes on non-ANSI keyboard layouts. For example, querying SDL_SCANCODE_Y with the alt modifier on a QWERTZ layout returns SDLK_Y instead of SDLK_Z on most platforms, as the backends don't generate a specific entry for this key + modifier combo, so the lookup would fall back to the default ANSI layout.
Adding additional key+modifier combinations when building the keymap is one solution, but it makes an already expensive operation even more so, pushing the time needed to build the keymap into double-digit milliseconds in some cases due to the large amount of key combos that need to be queried, most of which are redundant.
Instead, falling back to searching through the shift levels for the given modifier state when querying the keymap will ensure that the most appropriate keycode is returned. This does add some overhead to lookups if the key doesn't have an entry with the exact set of modifiers, but it is minimal as hash table lookups are an inexpensive operation, and unnecessary lookups are avoided. In my own testing of an optimized build, the difference between best-case and worst-case performance (the latter of which is highly unlikely in real-world usage) is only a few hundred nanoseconds. Additionally, the unmodified keys are queried when pumping events, so there is no additional overhead in that case.
The function SDL_GetCurrentKeymap() would return null instead of the actual bound keymap for non-latin layouts if certain mapping options were set. Add a parameter to ignore the keymap options and always return the actual bound keymap, which is needed in the Wayland backend to avoid spamming keymap changed events on every keystroke with certain layouts.
This can be toggled per-window, so use the individual window flags instead of the global toggle to selectively enable it only for the relevant window in a multi-seat scenario, as is already done with keyboard and pointer grabs.
The problems are two-fold. When this happens a WM_POINTERDOWN event is sent with IS_POINTER_INCONTACT_WPARAM() evaluating as true. So when SDL_SendPenButton() is sent for the barrel button, there is no pen in contact yet, so the right mouse button is sent. Then SDL_SendPenTouch() is sent, which generates a left button press event.
Fixes https://github.com/libsdl-org/SDL/issues/12926
Wayland compositors may send recursive clipboard offers to the client, which need to be filtered out to avoid clearing local data. Previously this was worked around with a hack, but this caused the ownership flag to be set incorrectly, which broke some clients.
This introduces a metadata MIME type of application/x-sdl3-source-id to be sent with SDL3 selection offers, which contains a string that is a unique identifier for the instance, and can be used to detect if a received selection offer is originating from the same instance that generated it.
If DBus is available, the unique identifier string is the unique name of the connection, otherwise, the process ID is used.
Wayland environments can expose more than one seat for multiple collections of input devices, which can include multiple, simultaneously active, desktop pointers and keyboards with independent layouts. The Wayland input backend previously presumed that only one seat could exist, which caused broken behavior if the compositor exposed more than one, which is possible on wlroots based compositors such as Sway. This introduces support for handling multiple seats, including proper handling of dynamically added and removed seats and capabilities at run time.
The SDL Wayland input system was accreted over time, and the assumption that only one seat will ever exist resulted in state and related objects not always being tied to their most appropriate owner in a multi-seat scenario, so refactoring was required to manage several bits of state per-seat, instead of per-window or globally.
As Wayland keyboards can have per-seat layouts, fast keymap switching is required when multiplexing input from multiple seats to the global SDL keyboard device. A parameter was added to the keymap creation function to specify if the keymap lifetime should be externally managed to facilitate keymap reuse, and some layout info was moved from the global keyboard state to the keymap state to avoid unnecessarily redetermining it whenever a reused keymap is bound. This reduces the overhead of switching keymaps to setting a single pointer.
Multiple seats also means that multiple windows can have keyboard and/or mouse focus at the same time on some compositors, but this is not currently a well-handled case in SDL, and will require more work to support, if necessary.
We can't use keyboard input as a signal about whether a keyboard is attached. There might be keyboard input from any number of generated inputs or non-keyboard devices.
SDL 2.0.18 added preciseX/Y to mouse wheel events, which we cannot
emulate in sdl2-compat without a mechanism to control integer position
and scroll deltas separately.
The existing behavior helps clients that don't expect exclusive fullscreen windows to move by maintaining a consistent size and mode, however, some are aware that this can occur and want to handle mode selection themselves.
Add a hint to disable auto mode switching when an exclusive fullscreen window moves to accommodate this use case, and don't override fullscreen changes that may occur in an event watcher between the display changed event being posted and SDL running the display changed handler, as the mode switch may have already been handled there by the client.
* Update SDL_mouse.c
Stop a mouseID of SDL_PEN_MOUSEID being discarded when dispatching mouse events. I'm not sure if this enough to fix the lack of SDL_PEN_MOUSEID being emitted.
* Update SDL_mouse.c
Since we test for touch input here we also test for pen input in the same way.
* Stop duplicate synthetic touch events
If SDL_HINT_PEN_MOUSE_EVENTS and SDL_HINT_MOUSE_TOUCH_EVENTS are both enabled, the pen generated synthetic mouse event will then produce a touch event without this additional check.
This requires the previous commits in order to do anything since it needs to be able to identify those pen generated mouse events.
This was intended to make the API public, so SDL_hashtable.h got an extreme
documentation makeover, but for now this remains a private header.
This makes several significant interface changes to SDL_HashTable, and
improves code that makes use of it in various ways.
- The ability to make "stackable" tables is removed. Apparently this still
worked with the current implementation, but I could see a future
implementation struggle mightily to support this. It'll be better for
something external to build on top of the table if it needs it, inserting a
linked list of stacked items as the hash values and managing them separately.
There was only one place in SDL using this, unnecessarily, and that has also
been cleaned up to not need it.
- You no longer specify "buckets" when creating a table, but rather an
estimated number of items the table is meant to hold. The bucket count was
crucial to our classic hashtable implementation, but meant less once we
moved to an Open Addressing implementation anyhow, since the bucket count
isn't static (and they aren't really "buckets" anymore either). Now you
can just report how many items you think the hash will hold and SDL will
allocate a reasonable default for you...or 0 to not guess, and SDL will
start small and grow as necessary, which is often the correct thing to do.
- There's no more SDL_IterateHashTableKey because there's no more "stackable"
hash tables.
- SDL_IterateHashTable() now uses a callback, which matches other parts of SDL,
and also lets us hold the read-lock for the entire iteration and get rid of
the goofy iterator state variable.
- SDL_InsertIntoHashTable() now lets you specify whether to replace existing
keys or fail if the key already exists.
- Callbacks now use SDL conventions (userdata as the first param).
- Other naming convention fixes.
I discovered we use a lot of hash tables in SDL3 internally. :) So the bulk
of this work is fixing up that code to use the new interfaces, and simplifying
things (like checking for an item to remove it if it already exists before
inserting a replacement...just do the insert atomically, it'll do all that
for you!).
