You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
The text was updated successfully, but these errors were encountered: