mirror of
https://github.com/libretro/RetroArch.git
synced 2026-11-07 08:36:02 -10:00
LibretroAdmin
bc0cf2adef
keyboard_led() runs on the main thread: led_driver_init from retroarch.c and led_driver_set_led wired into the core LED interface in runloop.c. Under video_threaded the main window and its message pump belong to the video thread, so the main thread's synchronous key table is never advanced and GetKeyState reports every lock as clear. That made keyboard_init() record all three locks as off, and every subsequent set saw status 0 and fired keybd_event to toggle a lock that was already lit. keyboard_free() then "restored" all of them to off. Take the lock state from the mask win32_update_keyboard_mods() publishes from the owning thread, which is correct in both video threading configurations. The mask advances when the window procedure sees a key event, so a lock changed while RetroArch is not focused is still not observed until the next key reaches the window. That is a smaller window than before and matches what the rest of the Win32 input path already assumes.