Pen button 1 is typically used as right click. Pen button 2 (Wacom eraser) doesn't have a specific mapping, but we'll use middle click for now.
(cherry picked from commit e3df61b070)
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
(cherry picked from commit e04064350f)
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.
(cherry picked from commit 8caeaaacdd)
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.
(cherry picked from commit aad1e35162)
* 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!).
We'll switch to the global mouse ID just once we are ready to deliver events.
This makes sure that any button events that come in for a specific mouse ID maintain that state if we switch to relative mode and start using that mouse ID for events.
Fixes https://github.com/libsdl-org/sdl2-compat/issues/263
Add SDL keycodes for keys found commonly found in the default Xkb layout, such as left tab and compose, and keys frequently used for custom modifiers such as Meta, Hyper, and Level5 Shift.
As these keys aren't Unicode code points and don't have associated scancodes (at least on modern keyboards), they are placed in the new extended key code space, with bit 30 set as a flag.
