Pimoroni Trackball improvement

[Tonasz]

Creating this issue, to not loose a track of proposed in #321 pimoroni_trackball.py improvement. Not all of them must be implemented - these are just subjects to investigate.

• [ ] Fine-tuning of acceleration logic. Both in usability and optimization (MCU heavy trigonometry and pow are used)
• [ ] Investigating right frequency of I2C and polling
• [ ] Interrupt pin logic
• [ ] Vertical mouse scroll
• [ ] Movement amount is capped because of bytes limit and acceleration can generate high value

[xs5871]

I thought about the speed limit and acceleration in general. Most mouse HIDs don't do acceleration on the hardware / client device, but on the host driver side. The reason the virtual mouse keys of custom keyboard firmwares have acceleration or on-the-fly changeable speed is that, by nature being digital, switches can't represent speed, rate of change, etc... -- and without some kind of dynamic behavior they are irritating to use. That's not quite the case with the trackball and the case could be made for dropping the acceleration feature from the trackball and leaving that to the OS.

[Tonasz]

I tried a bit playing with enabling and disabling mouse acceleration in windows and I must say, it needs data to work on. And because of a way of how this little trackball delivers data (short spikes) I'm not sure if it can do much in current implementation. You take look at: https://github.com/Tonasz/kmk_firmware/commit/eadbc5705132f5feacd734e4799719d2f437ba66 I've added sending the data, which exceeded hid_limit in consecutive hid reports and I think it feel better. And maybe even better if you apply changes + enable mouse acceleration in OS (I'm using Windows). Ofc numbers needs tweaking. I now don't think if that exponential calculation should be called acceleration, but I think it improves the feel and usability of this tiny trackball.

[xs5871]

The movement resolution is a problem. It looks like the trackball resolves around 5-10 degrees on the major axes. Diagonal movement is very jittery, even without scaling. It helped a little to reduce the polling interval to 10ms, that also capped raw_x/y to a size where an accumulator for "unsent" movement wouldn't make a noticable difference. Anything that's higher than quadratic scaling also feels to jumpy to me. My next idea would be some kind of dynamic/integrating scaling, where the scaling factor takes a series/sum of the last couple movement values into account. In light of the general data and haptic quality of the trackball, it's not going to be a daily driver for me anytime soon, and I'm in no rush to make it actually usable.