Live strace on yarn during gameplay revealed the daemon was correctly
calling effect.vibration(freq=35) on slip events, but the OUT report
on the wire showed mode=0x26 (VIBRATION) with byte 31 (param9 =
frequency) = 0. The controller firmware treats freq=0 as "no
oscillation" — trigger sits silent in vibration mode. That's why the
user reported "doesn't react to slipping or anything" even after the
pedal-off early-return fix.
Root cause is in dualsense-controller 0.3.1 itself:
- WriteStates.__init__ registers individual write-states for trigger
effect params 1-7 only. params 8/9/10 are not registered.
- update_out_report copies from per-state values to the OutReport,
again only params 1-7.
- The OutReport dataclass DEFINES params 1-10 (with defaults of 0)
and Usb01OutReport.to_bytes writes all 10 to the wire.
- effect.vibration() puts frequency in param9 — silently dropped.
- Same hits effect.machine() (params 8,9,10) and effect.galloping()
(param10). effect.feedback/weapon/bow only use params 1-7 so
they happen to work.
Fix is a small upstream-style patch added under patches/dualsense-
controller/ and wired into the dualsense-controller derivation in
hosts/yarn/forza-trigger/python-packages.nix via the patches attr:
in update_out_report, after the param7 assignments, read param8/9/10
directly from the parent TriggerEffect state value (which already
carries them correctly from the call site through _set_value).
Verified post-patch by source-reading the installed library:
out_report.left_trigger_effect_param9 = self.left_trigger_effect.value.param9
out_report.right_trigger_effect_param9 = self.right_trigger_effect.value.param9
(and 4 more for left/right param8/10)
Build-sandbox tests (54/54) pass via the forza-trigger-tests build
gate; full yarn NixOS closure builds clean.
Filing upstream against yesbotics/dualsense-controller-python is the
follow-up; until then this is a local patch.
