SDL_InitSubSystem, SDL_INIT_GAMECONTROLLER, takes five seconds to complete


I’m upgrading from 2.0.8 to 2.0.12 and I’ve noticed that SDL_InitSubSystem(SDL_INIT_GAMECONTROLLER) has gone from being unremarkable to approximately 5 seconds to return. I’m on a windows 10 machine with VS 2017 and I’m using the downloaded VS build of SDL. I have a a PS4 controller connected via USB but it’s the same delay if it’s plugged/unplugged.

I separated the init calls to this:

if (SDL_Init(0) != 0) {
spdlog::error("SDL_Init Error: {}", SDL_GetError());
    return false;



Is this a known issue or by design?


This isn’t expected. Can you build SDL and debug it to find out what’s going on?

Please report a bug on


Thanks for the info. I’ve had a look, here are my steps:

  • downloaded SDL2 2.0.12 zip file
  • opened the SLN in the VisualC folder.
  • accepted conversion to 141 toolchain
  • selected testgamecontroller as the ‘default project’
  • built in debug

here is the function that seems to take a long time to complete (complete stack)

SDL2.dll!hid_enumerate(unsigned short vendor_id, unsigned short product_id) Line 334
	at d:\sdl2-2.0.12\src\hidapi\windows\hid.c(334)
SDL2.dll!HIDAPI_UpdateDeviceList() Line 811
	at d:\sdl2-2.0.12\src\joystick\hidapi\sdl_hidapijoystick.c(811)
SDL2.dll!HIDAPI_JoystickDetect() Line 904
	at d:\sdl2-2.0.12\src\joystick\hidapi\sdl_hidapijoystick.c(904)
SDL2.dll!HIDAPI_JoystickInit() Line 586
	at d:\sdl2-2.0.12\src\joystick\hidapi\sdl_hidapijoystick.c(586)
SDL2.dll!HIDAPI_IsDevicePresent(unsigned short vendor_id, unsigned short product_id, unsigned short version, const char * name) Line 847
	at d:\sdl2-2.0.12\src\joystick\hidapi\sdl_hidapijoystick.c(847)
SDL2.dll!EnumJoysticksCallback(const DIDEVICEINSTANCEW * pdidInstance, void * pContext) Line 659
	at d:\sdl2-2.0.12\src\joystick\windows\sdl_dinputjoystick.c(659)
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for dinput8.dll]
SDL2.dll!SDL_DINPUT_JoystickDetect(JoyStick_DeviceData * * pContext) Line 677
	at d:\sdl2-2.0.12\src\joystick\windows\sdl_dinputjoystick.c(677)
SDL2.dll!WINDOWS_JoystickDetect() Line 351
	at d:\sdl2-2.0.12\src\joystick\windows\sdl_windowsjoystick.c(351)
SDL2.dll!WINDOWS_JoystickInit() Line 309
	at d:\sdl2-2.0.12\src\joystick\windows\sdl_windowsjoystick.c(309)
SDL2.dll!SDL_JoystickInit() Line 224
	at d:\sdl2-2.0.12\src\joystick\sdl_joystick.c(224)
SDL2.dll!SDL_InitSubSystem_REAL(unsigned int flags) Line 234
	at d:\sdl2-2.0.12\src\sdl.c(234)
SDL2.dll!SDL_Init_REAL(unsigned int flags) Line 291
	at d:\sdl2-2.0.12\src\sdl.c(291)
SDL2.dll!SDL_Init(unsigned int a) Line 85
	at d:\sdl2-2.0.12\src\dynapi\sdl_dynapi_procs.h(85)
testgamecontroller.exe!SDL_main(int argc, char * * argv) Line 265
	at d:\sdl2-2.0.12\test\testgamecontroller.c(265)
testgamecontroller.exe!main_getcmdline() Line 71
	at d:\sdl2-2.0.12\src\main\windows\sdl_windows_main.c(71)
testgamecontroller.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * hPrev, char * szCmdLine, int sw) Line 104
	at d:\sdl2-2.0.12\src\main\windows\sdl_windows_main.c(104)
[External Code]

Since it is enumerating all the HID devices I ran the code with different USB devices connected.
This lead me to discover that if I remove my monitors USB cable (the cable from the motherboard to the monitor disconnecting the monitors USB HUB) the function completes within a reasonable time (effectively instantly). My monitor is an Apple Cinema HD display 30".

The slow down occurs even if there is nothing plugged in to the monitors USB ports.

Digging further in to the code:

Once device_interface_detail_data->DevicePath is known in hid.c:496 I checked to see if it’s equal to \\\\?\\hid#vid_05ac&pid_9220#7&1f9b818e&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} (which I assume if the UUID for the HUB? Not sure about that) and I observed that HidD_GetProductString return zero but takes a few seconds to return. HidD_GetSerialNumberString and HidD_GetManufacturerString both return zero but do so instantly.

I also think the enumeration of the HID is being done twice? doubling the delay I am seeing in startup.

Does that help? happy to do more digging or testing.


1 Like

If you think this is still a bug I can report it. The monitor USB HUB does behave normally, I have no reason to suspect it’s broken in anyway.

I think this may fix it:

If not, please submit a bug for tracking.


Can confirm this fixes it, great news. Thanks.