Don't use a separate thread when polling for gamepad events on DRM platforms #3641
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi, I recently got a Powkiddy RGB30 and I'm porting a Raylib game of mine on it. I was able to build it (using PLATFORM_DRM) and run it out-of-the-box, that is totally awesome.
The only issue it that raylib wasn't registering gamepad presses - that is,
IsGamepadButtonDown
was working, butIsGamepadButtonPressed
was not. I started debugging it and realized that, on DRM platforms, a separate thread is created to read gamepad inputs; this approach can lead to race conditions, because both the main thread and the worker thread are writing to global variables (CORE.Input.Gamepad.currentButtonState
) concurrently without locks, and by the way I wonder if that was necessary at all sincePollInputEvents()
is reading mouse events synchronously usingread()
anyway.This fix removed the separate thread and introduces a
PollGamepadEvents()
function that reads the gamepad events. Written against 5.0 release