fix(DualSense): only emit changed input reports for IMU#601
fix(DualSense): only emit changed input reports for IMU#601sunshineinabox wants to merge 2 commits into
Conversation
pastaq
left a comment
pastaq
left a comment
There was a problem hiding this comment.
Seems fine from a code perspective. Does this match the behavior of the real hardware?
| // send UHID_INPUT events to the kernel. | ||
| uhid_virt::OutputEvent::Open => { | ||
| log::debug!("Open event received"); | ||
| self.last_written = None; |
There was a problem hiding this comment.
This will be none by default, so it's a no-op at initial opening. Then we carry that stale data in memory until the next time it is opened. Rather than do this here, does it make more sense to do it after close?
There was a problem hiding this comment.
Went with doing it around close. Only issue is resetting on close alone doesn't really work since write_state still runs every poll even with nothing attached, so it just repopulates last_written before the next open and the reconnecting consumer can get its first report skipped as unchanged. So I also skip write_state while closed and reset last_written on close.
|
I don't have a real controller to actually test this on, if there is proper motion control this will likely be no behavior change as without fuzz it would constantly report anyway. This is effectively only useful for devices that are emulating the controller without motion sensors. If someone with real DS5 could look into real hardware behavior I would appreciate it. |
2 participants
DS5 emits at its standard poll rate of 250Hz, however for devices that don't have any IMU it continues to report the same data (zero). This should be a no-op for devices with actual IMU reported. Issue discovered on Rocknix Mangmi Air X build where the polling was causing high CPU usage in box86/64.