Fix quick shift key presses getting ignored on dinput driver #17185
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.
Description
The main issue with shift keys in the dinput driver on Windows is that when both shift keys are pressed simultaneously, the OS will not issue a WM_KEYUP for the one first pressed down. 4 years ago the PR #11543 fixed this by moving shift key event handling out of the windows message handler into the dinput polling function.
But because shift keys were now ignored in the event message handler and only issued during polling, a quick key press and release between two polls would get missed. This PR fixes this by having the event message handler still issue these key presses and only do the very special issuing of the missing shift key up event in the dinput polling upon simultaneous pressing of both shift keys. This way all key presses are caught no matter how quick they are.
This PR also fixes left alt up key events getting sent to the core twice.
One remaining issue is that the ALT-TAB handling is not yet perfect. If a user holds down any other key before pressing ALT-TAB, no up event will get issued for the keys already pressed before ALT until pressed and then released again while the window has focus again. A core can still work around this by manually querying any pressed keys during
retro_run
withinput_state_cb
to see if they are actually still down. DOSBox Pure does this. This should be rather rare though so fixing it doesn't have high priority.Related Issues
Related Pull Requests
#11543
Reviewers
@sonninnos