crrcsim/X11: very fast autorepeat

[smcv]

Prerequisites:

• Debian testing (Debian 12 alpha)
• Video: GNOME 43 in Wayland mode (with Mesa 22.2.0 on AMD Vega, if it matters)
• Audio: Pipewire 0.3.59, with pipewire-pulse emulating PulseAudio
• apt install crrcsim (Debian package version 0.9.13-3.2)
• Some relevant libraries:
  • libsdl1.2-compat either 1.2.58-1 (packaged in Debian experimental) or commit 63e4393 (locally built)
  • libsdl2-2.0-0 version 2.24.1+dfsg-1
  • libsdl1.2debian (real SDL 1.2) version 1.2.15+dfsg2-8

To reproduce:

• crrcsim
• LD_LIBRARY_PATH=.../sdl12-compat/_build crrcsim

Press Escape to open a menu. Hold down Escape for a second or so.

Expected result: pressing Esc briefly opens menu. Holding Esc cycles between menu and no menu a few times per second.

Actual result: pressing Esc very briefly opens menu, but a typical keypress (at least for me) will be long enough to open it and then close it again - I have to try quite hard to press it briefly enough to get the menu. Holding Esc cycles between menu and no menu rather quickly.

[icculus]

So this happens for a few reasons:

• crrcsim sets the initial key repeat delay to be very low (50 milliseconds, SDL 1.2's recommended default is 500).
• (as I just discovered) SDL 1.2 sees that this delay has passed for the first time, and sets a flag that says to actually deal with it on the next iteration of SDL_PumpEvents, so with vsync or whatnot, it might be significantly higher than the app-requested value.
• sdl12-compat "flushes" key presses in several cases, and this is currently where we decide about key repeat, but it might be better to move this to something directly under PumpEvents so it doesn't run sooner or more often than desired.

[icculus]

sets a flag that says to actually deal with it on the next iteration of SDL_PumpEvents

(Actually, it just sets the timestamp to "now" at this point, which is treated as a starting point, not the event timeout, so what 1.2 is actually doing is waiting the delay time plus one interval, not waiting the delay and then handling it in the next PumpEvents.)

[smcv]

Confirmed fixed by 67f8b3a, 1.2.58 + 29 commits