Description
I noticed a couple issues that seem to be related to the new raw input work as of 4d00706
cc: @slouken
Busy Looping
First, the MsgWaitForMultipleObjects() call doesn't appear to actually be blocking to wait on new raw input messages (or more likely, we're somehow not reading them all off the queue to clear QS_RAWINPUT).
SDL/src/video/windows/SDL_windowsrawinput.c
Lines 81 to 87 in e055a9f
When I stepped through WIN_PollRawInput(), I saw it accumulate events on the first wakeup, then subsequent wakeups seemed to always receive 0 events from GetRawInputBuffer() without resetting QS_RAWINPUT. As a result, MsgWaitForMultipleObjects() instantly returns and we end up in a busy loop. I didn't see anything obviously wrong with any of the code there, so it probably needs more detailed investigation.
I used testgl2.exe from the sdl2-compat repo to reproduce this, but I think it impacts basically any SDL3 program using raw input.
Keyboard Grab
It looks like raw input also interferes with our keyboard hook. The hook is installed successfully, but it doesn't get called while we're registered for raw input. I tried using RIDEV_NOHOTKEYS which worked for blocking the Windows key, but doesn't properly intercept Alt+Tab (and [triggers use of the legacy Alt+Tab UI too).
We could try to carve out a specific exception for raw keyboard input in the case that keyboard grab is enabled and SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED=1 (with the caveat of Windows's RIDEV_NOHOTKEYS Alt+Tab handling not quite behaving as we document that hint should), but I think it's probably easier to just disable raw keyboard input as long as a keyboard grab is active.
To repro, I used testgl2.exe --keyboard-grab and pressed Alt+Tab and Windows key to ensure the grab was working.