Remove FHIDPollingRunnable

[slonopotamus]

It does not do anything useful.
Controller disconnects are properly handled even without it.

[rafaelvaloto]

Thanks for your feedback on this. I understand why FHIDPollingRunnable might seem redundant at first, but its primary purpose is actually crucial for performance, going beyond just preventing disconnects.

This task actively polls the controller to enforce a high and consistent polling rate. Without it, we would rely on the OS's default (and often slower) schedule, which leads to noticeable performance issues.

By forcing a high polling rate, this runnable achieves three key things:

Drastically Reduces Input Lag: It lowers the latency between physical input and the computer's response, making the controller feel much more responsive.

Guarantees Consistent Performance: It eliminates communication jitter (variance in packet delay), ensuring the controller's performance is stable and reliable, without random spikes of lag.

In short, while it does act as a keep-alive, its main function is to optimize the data pipeline for a low-latency, high-performance experience.

[slonopotamus]

Interesting... I'll try to run some benchmarks with and without it.

[rafaelvaloto]

Yes, you can use a much lower value to make your test run as fast as 4ms. I left the status polling interval at 150ms, which is a high value, but there's a technical explanation.

The problem is that the status polling task (which checks the battery, etc.) was, in some cases, running at the same time as the main input reading, which creates a race condition and causes instability in the Hid API. The definitive solution is to implement a mutex to ensure that only one operation accesses the device at a time.

Since this implementation isn't yet finalized, I increased the interval to 150ms as a temporary measure. This drastically reduces the likelihood of conflicts and allows us to continue development without crashes.

[slonopotamus]

Didn't have time for testing yet, marking PR as draft for now.