-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High polling rate makes mouse(HID) movement sluggish #3088
Comments
Any relevant logs in the console output? |
Sorry. I'm not a programmer so that I might not understand you well. Where can I find the console output? |
Double-click on |
And here is the log.
|
When the polling rate is set to 125hz, I don't see the
|
OK, that's what I suspected. Scrcpy enqueues at most a fixed number of events (currently 64), because if there are too many events not consumed, we want to discard them (to avoid forwarding them with a high delay). With a high polling rate, this limit might be too low, let's try to increase to 512: diff --git a/app/src/usb/aoa_hid.h b/app/src/usb/aoa_hid.h
index d785a0e9..d1a95643 100644
--- a/app/src/usb/aoa_hid.h
+++ b/app/src/usb/aoa_hid.h
@@ -27,7 +27,7 @@ sc_hid_event_init(struct sc_hid_event *hid_event, uint16_t accessory_id,
void
sc_hid_event_destroy(struct sc_hid_event *hid_event);
-struct sc_hid_event_queue CBUF(struct sc_hid_event, 64);
+struct sc_hid_event_queue CBUF(struct sc_hid_event, 512);
struct sc_aoa {
struct sc_usb *usb; Here is a binary to replace in your v1.23 release:
Please check if there are still warnings in the console (if you mouse the mouse for a while). If not, please check that there is no noticeable delay between your mouse motion and the cursor motion. If there are still warnings, then the events could not be consumed/forwarded at the same rate as they are received. That would require event resampling/merging to accommodate the issue. |
I replaced the file. |
OK, thank you. So an event resampling/merging mechanism will be necessary. It's not trivial and requires some work. Unfortunately, I could not reproduce on my machine with my mouse (AFAIK I could not configure the polling rate). |
This is quite important as the polling rate of a gaming mouse is normally set to at least 500hz by default. I'm now ok with 125hz though. I will wait patiently. |
Does it work with another Android device? |
I tested it on my phone. Still the same.
|
OK. And does it work correctly if you connect your mouse directly to the Android device? |
Also, do you reproduce the problem if you use the default mouse injection method instead of HID? (Since mouse motion events are not forwarded when nl mouse buttons are pressed, press the left button and move the mouse.) |
I connect my mouse directly to my Android devices via OTG cable. It works correctly.
Sorry. I don't quite understand this. What is "default mouse injecton method"? |
Without |
Do you mean mirroring screen of Android device and controling it on pc screen? In this case, I don't see delay. |
Yes. In that case, when you move the mouse with left button pressed, are there any warnings in the console? |
No, there is no any warnings in the console. |
I have the same issue on v1.24 (latest right now) using a Razer DeathAdder Essential which only can be set to 500 or 1000 Hz polling rate. I tested both I cut the end of the Terminal output because its repeating:
I know its asking a bit lot but the DeathAdder Essential is a very cheap gaming mouse by now. I bought it for 28€ 2 years ago not on discount. Cheapest price new I found 22€ just now. Maybe you could consider it for supporting mice that dont go under 500 Hz. I would even use 125 Hz as a workaround if it was available for me. |
Everything described above applies to my 1000Hz mouse on Linux if that is any help |
When I tried using AOAv2 to forward HID events in my own program, I noticed that each usb.Control command took longer than 1ms, sometimes up to 2ms. I think that's why the high polling rate mouse lags, because it reports faster than AOAv2 can consume. |
For sending HID events, it is possible to combine multiple HID event data into one send. after AOAv2 receives the data and reports it to the kernel, the system splits and processes the received HID events one by one. this approach keeps the 1000Hz polling data intact and reduces the data interaction frequency to 125Hz. but it introduces a latency of about 8ms. But I think this is enough to solve the problem. |
Environment
Describe the bug
The polling rate of my mouse can be set to 125hz, 500hz, 1000hz in driver. When it is set to 500hz or 1000hz, mouse(HID) movement is sluggish.
The text was updated successfully, but these errors were encountered: