Gamepad: Implement GamepadHapticActuator #32046
Conversation
|
Also wondering if maybe @gterzian or someone has some insight, currently the subtests that test |
There was a problem hiding this comment.
Thanks for the start!
Bunch of small comments, plus a big one for the doing reset. I've also filed w3c/gamepad#200
| @@ -205,16 +210,32 @@ where | |||
| } | |||
| }, | |||
| EventType::Connected => { | |||
| let len = self.haptic_effects.len(); | |||
| self.haptic_effects.resize_with(len + 1, Default::default); | |||
There was a problem hiding this comment.
The intention was to add a new slot in the haptic effects vec for any effects that will play on that gamepad, not sure why I did it like this instead of just appending None though. Have adjusted this
| self.global().as_window().send_to_embedder(event); | ||
| } else { | ||
| let message = DOMString::from("complete"); | ||
| reset_result_promise.resolve_native(&message); |
There was a problem hiding this comment.
This step reads like it should be done only after the effect has been stopped. But the spec is unclear, because it resolves the promise directly from the parallel steps without queuing a task for it. See other comment about restructuring this...
| self.reset_result_promise.borrow().is_some() | ||
| } | ||
|
|
||
| pub fn resolve_reset_result_promise(&self) { |
There was a problem hiding this comment.
So to do this as per the spec we will have to restructure this via a listener on the IPC router thread and using trusted refs to the promises and also the actuator:
- Look at to setup a route over IPC, see for example
BroadcastListener, and do this insideReset. - Put the IPC sender in the
EmbedderMsg::StopGamepadHapticEffect - Put both the
playing_effect_promiseand thereset_result_promise, and also the actuator itself, as trusted on the "listener" in the route. - Add something in the reply about whether the effect was "successfully stopped"
- From the route, when you receive the reply, queue a task that runs all steps 4.3 and 4.4 of https://www.w3.org/TR/gamepad/#dom-gamepadhapticactuator-reset (the spec is wrong because it does 4.4. outside of a task).
- To do 4.3.1, I think you need to add a "playing effect generation counter", so that you can compare the one you stored on the IPC listener with the current one on the actuator by the time the task runs. Note this is necassary because it plays with the step 4 of
playEffect.
| let _ = self.global().gamepad_task_source().queue( | ||
| task!(preempt_promise: move || { | ||
| let promise = trusted_promise.root(); | ||
| let message = DOMString::from("preempted"); |
There was a problem hiding this comment.
This should only fire if the promise hasn't already been preempted by a playEffect call after the reset call that ended-up queuing this task(see comment above).
| return; | ||
| }; | ||
|
|
||
| effect.stop().expect("Failed to stop haptic effect."); |
There was a problem hiding this comment.
can we handle this in some way?
There was a problem hiding this comment.
Maybe for the "was succesffuly stopped" thing the in the reply(see above comment).
|
|
||
| /// <https://www.w3.org/TR/gamepad/#handling-visibility-change> | ||
| #[allow(dead_code)] | ||
| pub fn handle_visibility_change(&self) { |
This addresses another item on #31362 by implementing GamepadHapticActuator, allow haptic effects to play on connected gamepads. Note that this currently implements the main spec version of GamepadHapticActuator and not what's present in the Gamepad Extensions.
./mach build -ddoes not report any errors./mach test-tidydoes not report any errors