script: Poll gamepad events in a seperate thread#44792
Conversation
| }; | ||
|
|
||
| loop { | ||
| while let Some(event) = handle.next_event() { |
There was a problem hiding this comment.
next_event_blocking will make this loop much more efficient.
| event_loop_proxy | ||
| .clone() | ||
| .send_event(AppEvent::Gamepad(event, name.to_owned(), index)) | ||
| .expect("Coulnt access to event loop proxy!"); |
There was a problem hiding this comment.
Breaking out of the loop when we can no longer communicate with the event loop will avoid errors during shutdown.
| let index = request.gamepad_index(); | ||
| let GamepadHapticEffectType::DualRumble(params) = effect_type; | ||
|
|
||
| let mut handle = self.handle.borrow_mut(); |
There was a problem hiding this comment.
My instinct here is to use an Arc<Mutex<Gilrs>> that's shared between the gilrs thread and the main thread.
There was a problem hiding this comment.
Mmm, that probably interacts poorly with next_event_blocking. Perhaps next_event plus the sleep when there's no event, like you mentioned?
There was a problem hiding this comment.
Another option: use next_event_blocking with a timeout, and add a channel to the gilrs thread which is used to listen for haptic requests. The main thread code that receives a haptic request sends the relevant data through the sender; the gilrs thread uses try_recv on the receiver after each next_event_blocking.
2 participants
In order to reliably listen for gamepad events this PR is polling gamepad events in seperate thread and sending them as AppEvents via event loop proxy. The PR is working but not complete yet, I'd like to ask for a feedback first on some issues before moving further:
handle.next_eventreturns None?Testing: TBD
Fixes: #44575 #41448