-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't use a separate thread when polling for gamepad events on DRM platforms #3641
Conversation
@cinghycreations Oh! Nice review! Actually there was undergoing work on that direction by @michaelfiber! There also seems to be some branch conflicts, could you review them? Also, I'm curious about the |
Hi, thanks for your quick feedback. I've resolved the conflict, bear with me if I made some mistakes... it's my first pull request ever, on any project 😄 As for the By the way, I was able to use WSL (Windows Subsystem for Linux) to build the game for Windows, Linux and Raspberry Pi on Windows 11. Also, I didn't have to change anything in my code or CMake files - everything just built and worked on all three platforms. |
Nice! That is how it is supposed to work! 😄 |
@michaelfiber Please, could you take a look to this PR before merging? |
I reviewed the code and I'm merging it. Feel free to comment if some issue is detected. |
Awesome, thank you! |
@cinghycreations I know your PR is already merged, but I've been working through a very similar issue on a similar device (the R36S), and I believe I know the reason: the DRM platform directly uses the index of the button based as reported by |
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