Implemented rate limiter for HID reports.

[ChrisVeigl]

Added new config variables for KConfig: -) enabling rate limiter -) set interval in microseconds -) Either accumulate mouse movements or discard reports when sent too fast

[benjaminaigner]

I've moved all the rate limiter stuff to the esp_hidd_prf_api.c file, because it is more reasonable to it there. The rate limiter is using an esp_timer in accumulate mode, discard mode is working just with a timestamp.

Every packet is sent via the timer, because the default value is set to 500us, which is half the time of the USB request (1ms). With up to 50ms there is no noticeable delay (this setting should be sufficient for all devices, even for older ones).

[ChrisVeigl]

Every packet is sent via the timer, because the default value is set to 500us, which is half the time of the USB request (1ms). With up to 50ms there is no noticeable delay (this setting should be sufficient for all devices, even for older ones).

OK! i think we should test the response with different rate limits and devices. if we want to apply it in the FlipMouse, we need to remove the current rate limiter (which currently just drops everything < 20ms) in bluetooth.cpp: https://github.com/asterics/FLipMouse/blob/56b854f2b889f4f2fac8f5503f65db2b070b8f90/FLipWare/bluetooth.cpp#L19

And it we could make the rate limit adjustable via uart / a new FlipMouse AT-command (eg. AT BC to transfer bluetooth commands to the esp32 - for example "AT BC $RA 80" for setting the rate limiter to 80 ms) ?

[benjaminaigner]

OK! i think we should test the response with different rate limits and devices. if we want to apply it in the FlipMouse, we need to remove the current rate limiter (which currently just drops everything < 20ms) in bluetooth.cpp: https://github.com/asterics/FLipMouse/blob/56b854f2b889f4f2fac8f5503f65db2b070b8f90/FLipWare/bluetooth.cpp#L19

I don't know if we should remove it completely. If we do that, we might run into the issue, that the serial buffer is full and packets are dropped within the FM?

[ChrisVeigl]

I don't know if we should remove it completely. If we do that, we might run into the issue, that the serial buffer is full and packets are dropped within the FM?

if we do not remove it, it will compromise the function of the rate limiter inside the esp32 add-on (becuaes it just drops commands), IMO the best implementation for the FlipMouse would be to limit the rate of commands as soon as possible (before USB or BT actions are created).

[benjaminaigner]

This PR is also ~2years old and we don't have any problems with rate limiting.