SDL_WaitEvent() doesn't block when a joystick is used

[rofl0r]

it's #3976 all over again... commit 1bc6dc3 effectively broke SDL_WaitEvent() if a joystick is used.
the commit message states:

Joystick and sensor subsystems require periodic polling to detect new device
s.

but that's false, at least in linux joysticks are regular devices that can use poll()/select() syscalls to block until input is received.

[rofl0r]

cc @cgutman @franko

[cgutman]

Joystick and sensor subsystems require periodic polling to detect new devices. (emphasis mine)

It's not a matter of reading joystick input (which already used polling in SDL_WaitEvent() and has done since the original waiting rework was done) - it's detecting new devices which is the problem.

but that's false, at least in linux joysticks are regular devices that can use poll()/select() syscalls to block until input is received.

As I mentioned in #4881, this is possible to do via poll() (or similar methods) for device detection on some platforms, but we agreed the complexity didn't really seem worth it.

it's #3976 all over again... commit 1bc6dc3 effectively broke SDL_WaitEvent() if a joystick is used.

Unlike actually having a joystick connected, which triggers the legacy 1ms polling logic, all 1bc6dc3 does is cap the length of time we will spend blocking in the blocking WaitEventTimeout() callback to 3 seconds.

We still block for 3000x longer when using SDL_WaitEvent() with joystick subsystems active compared to the the old polling method, so it's not even close to the same level of CPU consumption as #3976 (which was waking every 1 ms all the time).

[rofl0r]

we will spend blocking in the blocking WaitEventTimeout() callback to 3 seconds.

this is not what i'm experiencing though. i've been single-stepping through SDL code (and discovering this) because my app was using constant 6% cpu (on machine throttled to 800mhz via powersave governor) while in a loop doing nothing else than SDL_WaitEvent(&evt).

As I mentioned in #4881, this is possible to do via poll() (or similar methods) for device detection on some platforms, but we agreed the complexity didn't really seem worth it.

if this is only about hotplugging, maybe we can make need_poll() return false if hotplug support isnt requested ?

edit:

Unlike actually having a joystick connected, which triggers the legacy 1ms polling logic, all 1bc6dc3 does is cap the length of time...

ouch, so this is exactly what i'm experiencing. i deliberately use SDL_WaitEvent() to NOT poll every one millisecond, while the menu system of my game is open.

[cgutman]

ouch, so this is exactly what i'm experiencing. i deliberately use SDL_WaitEvent() to NOT poll every one millisecond, while the menu system of my game is open.

Yeah, the current situation is not ideal for games. The wait rework was done with SDL-based non-game applications in mind, which were really the most negatively impacted by the 1ms polling behavior.

Avoiding polling on joysticks and sensors can definitely be done, but it will require some serious engineering effort to make it happen. It is fraught with corner cases and platform-specific dependencies.

Maybe a hint to adjust that internal polling interval would be enough to make it tolerable for your use case?

[rofl0r]

Maybe a hint to adjust that internal polling interval would be enough to make it tolerable for your use case?

that doesn't really help, i could then just as well write an SDL_PollEvent() based loop with a custom SDL_Delay, which produces a battery-draining cpu use even at barely tolerable delay levels. i'd really like to see WaitEvent() becoming the API it's supposed to be, rather than producing worse results than even custom PollEvents loop depending on which subsystems have been activated.

[franko]

I see your problem with the joystick @rofl0r. For my purpose I was more interested in the desktop application use case where joystick and sensor support can be disabled altogether.

Unfortunately I cannot participate to any development to help your request due to lack of spare time from my side.

[slouken]

SDL 2.0 is now in maintenance mode, and all inactive issues are being closed. If this issue is impacting you, please feel free to reopen it with additional information.