feat: Normalize IMU data and refactor IMU paths

[pastaq]

This PR does a major overhaul of how IMU data is managed across every aspect of InputPlumber.

• Adds generic de/normalize_gyro/accel_data_i16 functions.
• All source device implementations and t argets now de/normalize IMU data to/from radians per second for gyroscope data and meters per second squared for accelerometer data. Conversion constants per source are derived from SDL or kernel drivers.
• All target devices now denormalize Accelerometer and Gyroscope events into their native format (typically LSB).
• The iio_imu source device driver now configures a buffer and follows an asynchronous drain/refill pattern to create events. This reduces CPU and RAM overhead by reducing the number of reads per event from 3-6 to 1. This also has the benefit of reducing jitter when using iio_imu based devices as the entire event is now based on a single timestamp, when the old method had significant drift during each poll.
• Fixes issues displaying IMU data in the TUI test tool. TUI can now cleanly show up to 6 sources (left/center/right for accel/gyro) and doesn't limit them to what is filtered to userspace.

Considerations:
This change breaks DSU/cemuhook for target devices that don't report their own gyro. The DualSense and Deck type targets will still work, but xbox style and 3rd party controllers will not get gyro data.

Closes #102
Closes #218
Closes #240
Closes #262
Closes #427
Closes #447
Closes #475
Closes #715
Closes #728

AI Disclosure:
I used an LLM to research some of the concepts used here, and to break the code up into individual commits once the concept was flushed out. I also used it to do an initial review.

[ilyasturki]

I hit the DS5 accelerometer saturation this PR fixes: the hidraw source forwards raw counts, denormalize_accel_value scales them a second time, the i16 saturates, and the emulated pad has no usable gravity vector left.

Reading the new constants, the forward direction looks right but the inverses look wrong. Each pair should round-trip to 1 and neither does:

DS5_ACCEL_TO_SI  × DS5_SI_TO_ACCEL  = 0.00119710083 × 0.101971621 = 1/8192
DS5_GYRO_TO_RADS × DS5_RADS_TO_GYRO = 0.00001706026 × 57.29577951 ≈ 1/1024

Raw to SI to raw loses the resolution factor each time.

constant	value	equals	verdict
DS5_ACCEL_TO_SI	0.00119710083	9.80665 / 8192, raw to m/s²	correct
DS5_SI_TO_ACCEL	0.101971621	1 / 9.80665, m/s² to G	should be 835.352 = 8192 / 9.80665
DS5_GYRO_TO_RADS	0.00001706026	(π/180) / 1024, raw to rad/s	correct
DS5_RADS_TO_GYRO	57.29577951	180 / π, rad/s to deg/s	should be 58670.9 = 1024 · 180/π

The driver applies the forward constants as raw to SI (state.accel_x.to_primitive() as f64 * DS5_ACCEL_TO_SI), so nothing compensates further down. As written denormalize_accel_value(9.80665) returns 1 where the target's own calibration report advertises 8192, and the gyro path is off by the same 1024.

denormalize_gyro_value also still takes value_degrees_sec while its doc comment now says radians per second.

I have DualSense Edge hardware on Bluetooth and USB. I can test the branch and send the constant fix as a PR against it.

[pastaq]

Awesome, thanks. This PR is kinda stuck at the moment but I plan to break it up into a few separate PR's. I haven't gone through to validate all the value changes, I think I made quite a few mistakes. I'll be sure to review your input here when I'm working on the SI standardization piece.

[SimpleMatt7]

Tested motion through SDL on a ROG Ally X (BMI323) and wrote up the details in #715. Some notes that may help
when this gets split up:

• DECK_SI_TO_ACCEL = 1632.65 gives 16011 LSB/g; SDL's Deck driver uses 16384 LSB/g (1670.7 per m/s²).
  DECK_RADS_TO_GYRO = 916.73 gives 16.0 LSB per °/s; SDL uses 32768/2000 = 16.384 (938.7 per rad/s).

• The Deck targets also need an axis remap: SDL reads the Deck report as (X, Z, -Y), so the target should
  write (X, -Z, Y). I verified this with static poses on a patched v0.79.0 build (flat: acc Y = −16545,
  upright: acc Z = +16350, right edge up: acc X = +16230).

• On the DualSense target, sensor_timestamp advances by 3 per write_event instead of real time, and the
  calibration feature report (0x05) has a 5-byte bias block, so SDL reads roll bias = −31745 and discards the
  calibration. Neither is touched by this PR.

  Disclosure: written with the help of Claude (Anthropic); measurements and tests done on my device

[pastaq]

@SimpleMatt7 @ilyasturki please retest, issues should be resolved now

[SimpleMatt7]

@pastaq Thanks! Retested on ROG Ally X (Bazzite 44), commit a425117, DualSense Edge target, reading the kernel hid-playstation "Motion Sensors" evdev node.

Fixed

• Sensor timestamp: MSC_TIMESTAMP now advances with real time (sensor/wall-clock ratio 1.00–1.03).
• Accelerometer scale: ~1 g on a single axis per pose (flat: Y −1.03, upright: Z +0.97, right edge up: X +0.99).

New issue: gyro reads 8–35 °/s at rest on the DualSense target

Device lying still on a table:

report/s  204.3 | accel g  X   0.00  Y  -1.03  Z  -0.02 | gyro deg/s    8.12  34.70   9.20
report/s  197.1 | accel g  X   0.00  Y  -1.04  Z  -0.02 | gyro deg/s    7.97  34.51   9.29
report/s  197.2 | accel g  X   0.00  Y  -1.03  Z  -0.02 | gyro deg/s    8.33  34.28   9.36

At the same time, inputplumber device 0 test shows the gyro at 0 when the device is still, so the offset seems to appear in the DualSense target output.

If I read the code right, it could be a scale mismatch: the target writes the gyro at 1024 LSB per °/s (DS5_RAD_S_TO_GYRO_RAW), while both hid-playstation (dualsense_get_calibration_data) and SDL (HIDAPI_DriverPS5_LoadCalibrationData) derive the gyro scale from the calibration report: speed_2x * 1024 / (|plus - bias| + |minus - bias|) = 1080 * 1024 / (8835 + 8840), i.e. ~16.37 LSB per °/s. That would make the reported rate ~62× the real one, and would turn the sensor's normal ~0.1–0.5 °/s zero-rate offset into 8–35 °/s. I skipped the in-game test because of this.

Side effect of the IIO buffer

With this build, sysfs in_*_raw reads on the bmi323 fail while InputPlumber holds the buffer (in the mainline driver bmi323_read_raw() requires iio_device_claim_direct()), so tools that poll sysfs, like iio-dsu-bridge (cemuhook/DSU for emulators), stop receiving data: I measured 0 packets/s while testing this build. Just flagging it, since some users rely on DSU for emulators.

[QQCry]

│ Hey, while testing PR #612 I noticed a small typo in the udev rules that prevents the controller IMU bypass from being set:
│
│ In rootfs/usr/lib/udev/rules.d/99-inputplumber-device-setup.rules:
│
│ ATTR{left_handle/imu_bypass_enable}="true", ATTR{right_handle/imu_bypass_enable}="true"
│
│ The sysfs attribute exposed by the hid-lenovo-go kernel driver actually ends with a d:
│
│ /sys/.../left_handle/imu_bypass_enabled
│ /sys/.../right_handle/imu_bypass_enabled
│
│ Because of the missing d (enable instead of enabled), udev fails to find the sysfs attribute and cannot set it to true.
│
│ It should be:
│
│ ATTR{left_handle/imu_bypass_enabled}="true", ATTR{right_handle/imu_bypass_enabled}="true"
│
│ (Note: The driver also exposes imu_enabled if you ever need that as well).

[QQCry]

Hey @pastaq,

I tested PR #612 using inputplumber device 0 test. Here are my findings:

1. Tablet Sensor (Center): Works great!
   The IIO refactor with the direct filesystem buffer reads cleanly. Both accel_3d and gyro_3d report smoothly, and jitter is visibly reduced compared to the older industrial-io crate implementation.

2. Controller Sensors (Left / Right): No data incoming
   Only the tablet sensor (Center) produces output; the left and right controller gyros remain at 0.

Why the controller gyros aren't streaming yet:
The Legion Go Joy-Con MCU does not stream IMU data by default, even with imu_bypass_enabled active in hid-lenovo-go. The controller firmware requires explicit, unpadded 7-byte vendor commands sent to the gamepad interface (GP_IID = 0x02) to initialize the sensor and start high-rate 16-bit streaming:

• 05 06 6a 02 04 01 01 (Enable IMU sensor)
• 05 06 6a 07 04 02 01 (Enable 16-bit HQ stream)

Note: The firmware ignores these 0x6a packets if they are zero-padded to 64 bytes—they must be sent as exactly 7 bytes.

Additionally, the firmware stops the 16-bit stream if it doesn't receive a periodic keep-alive/heartbeat. In my custom build, sending these exact 7-byte commands along with a 3-second heartbeat loop kept the Joy-Con IMUs streaming reliably at ~350 Hz.

[pastaq]

Thanks. I'll compare those commands to the hid-lenovo-go driver. The documentation doesn't mention anything about HQ 16 but stream enabling, that appears to be an interpretation by the HHD dev and not necessarily accurate.

There is a bug currently in the hid-lenovo-go driver that incorrectly routes the IMU enable for the right controller to the bypass feature. TBS, the controller remembers its state so it should only need enablement once to work correctly.

[QQCry]

Regarding the controller remembering its state: I've already tested that extensively.
│
│ Unfortunately, in practice the controller terminates the stream and goes back to sleep whenever it gets disconnected/detached, or after sitting idle
│ for a short period without input.
│
│ That's why having a periodic keep-alive heartbeat (or a silence-detection re-arm) is necessary in real-world use — otherwise the gyro stream
│ unexpectedly dies and doesn't recover on its own.

[pastaq]

Reminder: user tested Apex and found the matrix from F1 series matched. Update config.