[SDL] Fix various issues with keyboard events #1708
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* ALLEGRO_EVENT_KEY_CHAR no longer has the wrong value for keycode when not using a US standard keyboard * ALLEGRO_EVENT_KEY_CHAR no longer has a potentially bad value for the modifiers state * ALLEGRO_EVENT_KEY_DOWN and ALLEGRO_EVENT_KEY_UP no longer set unichar, as that field isn't meant for these events
connorjclark
commented
Dec 18, 2025
| if (keyboard->last_down_keycode != 0) { | ||
| event.keyboard.keycode = keyboard->last_down_keycode; | ||
| } else { | ||
| event.keyboard.keycode = c < 1024 ? keyboard->inverse_unicode[c] : 0; |
Contributor
Author
There was a problem hiding this comment.
The inverse_unicode array could probably be removed now, but honestly I didn't think about it too hard.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
1: This resolves an issue reported by one of my users regarding poor keyboard support for non-US keyboards in the SDL driver (ref ZQuestClassic/ZQuestClassic#1006).
Repro: Build with SDL; pressing the first key on the third row (US "Z", German "Y") should always set
event.keyboard.keycodeto 26. That's true for US standard keyboard, but if you use/emulate a QWERTZ keyboard (which swaps Y and Z on a standard US keyboard), then 25 is incorrectly set instead. That's because the driver makes the incorrect assumption that the unicode value can be used to map to the scancode.2: I also noticed that the code was reading from two different parts of the SDL event union at the same time: namely for the modifiers key state, which it was incorrectly getting for the CHAR event. I actually considered removing modifiers from being set for the KEY_UP/KEY_DOWN events because they are not documented, but I saw the windows driver was setting them and found this commit so I guess the docs are just stale.
3: Lastly, I removed the code that was setting
unicharon the KEY_UP/KEY_DOWN events. I similarly saw it is not documented as being on those event, but this time I also saw that the windows driver always sets them to 0 so I felt confident in removing them.1 and 2 are clear bugs that I doubt anyone would have worked around. 3 could arguably be something people are relying on, so if you want that change behind a version check I can do that.