Open benjaminaigner opened 4 years ago
Implemented both, behaviour can be changed via make menuconfig
or idf.py menuconfig
.
See: https://github.com/asterics/esp32_mouse_keyboard/tree/rateLimiter
Should we discard received UART HID data if sent too fast OR should the ESP32 sum up mouse movement values & send them accumulated in one report?
Absolute data (mouse clicks & keyboard keys):
I think these should be sent ASAP (when the rate limiting timeout is finished), without further modification.
wow - you were so fast implementing this i could not even add my comment ;-) great that both options are available now!
i agree that keyboard reports and mouse clicks should not be discarded - but sending them ASAP could also lead to problems (e.g. a mouse clicks at a wrong position). accumulations of relative data is IMO the best method and should be the default.
i added a PR with some comments: https://github.com/asterics/esp32_mouse_keyboard/pull/39
maybe we can now remove the rate limiting which exists in the FlipMouse code: https://github.com/asterics/FLipMouse/blob/56b854f2b889f4f2fac8f5503f65db2b070b8f90/FLipWare/bluetooth.cpp#L66
For this, we should integrate the rate limit settings of the ESP32 into the UART command protocol (to make it accessible from the host system / GUI).
On some phones (currently observed on one older Android device), the received GATT HID reports are processed slower, which leads to noticeable delayed movements.
A possible solution would be a rate limitation for sending GATT data.
Open for discussion:
Relative data (mouse movements):
Should we discard received UART HID data if sent too fast OR should the ESP32 sum up mouse movement values & send them accumulated in one report?
Absolute data (mouse clicks & keyboard keys):
I think these should be sent ASAP (when the rate limiting timeout is finished), without further modification.
@ChrisVeigl what's your opinion?