[PATCH] HID: nintendo: Fix imu_timestamp_us double increment per report

[PATCH] HID: nintendo: Fix imu_timestamp_us double increment per report

[Christos Maragkos]

Previously, the imu_timestamp_us variable was incremented twice per
report, causing it to advance by two times the desired amount.

This resulted in incorrect jumps in IMU timestamps reported using
MSC_TIMESTAMP, so userspace applications saw corrupted timing on
functions such as gyroscope-based aim and motion controls.

This is fixed by removing the redundant increment at the start of the
report handling so the remaining can account for the full report
interval.

Fixes: 4ff5b10840a88 ("HID: nintendo: add IMU support")
Signed-off-by: Christos Maragkos <whitetowersoftware@gmail.com>
---
 drivers/hid/hid-nintendo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 29008c2cc530..a701e396ee50 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -1453,7 +1453,6 @@ static void joycon_parse_imu_report(struct joycon_ctlr *ctlr,
 		dropped_threshold = ctlr->imu_avg_delta_ms * 3 / 2;
 		dropped_pkts = (delta - min(delta, dropped_threshold)) /
 				ctlr->imu_avg_delta_ms;
-		ctlr->imu_timestamp_us += 1000 * ctlr->imu_avg_delta_ms;
 		if (dropped_pkts > JC_IMU_DROPPED_PKT_WARNING) {
 			hid_warn_ratelimited(ctlr->hdev,
 				 "compensating for %u dropped IMU reports\n",
-- 
2.54.0

Re: [PATCH] HID: nintendo: Fix imu_timestamp_us double increment per report

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing dropped packet compensation causes cumulative IMU timestamp lag.
--

commit ad128b0e7b6200fd6acd6f6287071433e2058d5a
Author: Christos Maragkos <whitetowersoftware@gmail.com>

HID: nintendo: Fix imu_timestamp_us double increment per report

This commit fixes an issue where the imu_timestamp_us variable was incremented
twice per report. It removes the redundant increment at the start of the
report handling to ensure accurate timing for userspace applications.

> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
> --- a/drivers/hid/hid-nintendo.c
> +++ b/drivers/hid/hid-nintendo.c
> @@ -1453,7 +1453,6 @@ static void joycon_parse_imu_report(struct joycon_ctlr *ctlr,
>  		dropped_threshold = ctlr->imu_avg_delta_ms * 3 / 2;
>  		dropped_pkts = (delta - min(delta, dropped_threshold)) /
>  				ctlr->imu_avg_delta_ms;
> -		ctlr->imu_timestamp_us += 1000 * ctlr->imu_avg_delta_ms;
>  		if (dropped_pkts > JC_IMU_DROPPED_PKT_WARNING) {
>  			hid_warn_ratelimited(ctlr->hdev,
>  				 "compensating for %u dropped IMU reports\n",
>  				 dropped_pkts);
>  			hid_warn_ratelimited(ctlr->hdev,
>  				 "delta=%u avg_delta=%u\n",
>  				 delta, ctlr->imu_avg_delta_ms);
>  		}

[Severity: High]
This is a pre-existing issue, but while the timestamp logic is being
modified here in joycon_parse_imu_report(), the code calculates dropped_pkts
and logs a warning about compensating for dropped IMU reports, but completely
lacks the logic to actually add the dropped time to imu_timestamp_us.

Because the driver only increments the timestamp for the 15ms window of
the received samples later in the function, dropped intervals are silently
omitted. Over a gaming session, will this cause the controller's timestamp
to accumulate permanent lag relative to real time, breaking sensor fusion
or gyro aiming in userspace?

Additionally, does the existing formula for dropped_pkts undercount by 1,
yielding 0 for a single dropped packet? Would it be better to correct this
formula (for example, (delta + avg / 2) / avg - 1) so it can accurately
perform the missing compensation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603152134.94439-1-whitetowersoftware@gmail.com?part=1