Bug: Noticable (& annoying) physical mouse input lag when the HDMI is connected (slave PC)
Hello there. Just received my new TinyPilot 2 today. However I am disappointed because I am noticing a significant mouse performance decrease on the slave PC (with physical mouse and keyboard usage plugged into the slave, which TinyPilot may think is headless but isn’t) once the HDMI is connected to the slave PC.
- I have tested with lowering the System > Video Settings ENTIRELY down to 1 each.
- Tested on multiple computers.
- Utilizing an HDMI splitter which worked fine with Startech's USB Crashcart over VGA (with a VGD to HDMI adapter, thus still the same splitter testing here).
Is this is the uStreamer possibly causing this performance drop?
My use case is to utilize the host machine at all times, and then periodically "remote in" from my LAN via TinyPilot, but right now its not possible as it would requiring constantly unplugging the HDMI for daily use, and plugging it back in when I think I will be finished for a while. This would be fine for headless, but in my case mine ALWAYS "has a head" until I need the KVM over IP function to operate.
Have you noticed this? It's easily testable by comapring the choppy / low FPS-like mouse cursor movement when the HDMI is plugged in, and then unplugging it, how smooth it is, like some super high DPI.
Is there something that I can do to tweak uStreamer more to bypass this issue? Otherwise I will have to go back to utilizing the Startech USB Crash Cart NOTECONS02 which doesn't bog down the host's mouse like this. :-(
- 10 replies
- FDon Eitner @FreihEitner
I'm not sure which version of the TinyPilot software shipped with the Voyager 2, but if it is not 2.3.1 you should upgrade. I got my Voyager 1 just over a month ago and noticed bad lag on the "remote" (or "slave") machine. The 2.3.1 software update made a significant improvement. Yes there is still some lag, but it no longer affects my use of my remote/slave machine which I use a handful of times throughout the day.
You can check for (and download) updates directly in the TinyPilot web app.
- AIn reply toAlt0⬆:@Alt0
UPDATE: Possibly my HDMI Splitter is the issue.
I tried messing around with settings in /user/lib/systemd/system/ustreamer.service like --encoder cpu or --encoder hw as per 10 sec+ Latency w/ Full Raspbian OS and then rebooting, but didn't have any luck
However I noticed something I didn't catch before. The lag only appears on the monitor connected to the HDMI splitter, not on the laptop device itself.
Taking the splitter out of the equation and having the display extended, it appears to then have no mouse lag. So perhaps the HDMI Splitter gets under stress from uStreamer and lags out my display which is noticable when moving the mouse due to it being very rapid.
Currently using which was working fine for the StarTech USB Crash Cart NOTECONS02 -- https://www.amazon.com/gp/product/B0732MD43P
I wonder if I should get this one which appears a bit more robust and see what happens -- https://www.amazon.com/HDMI-Splitter-1x2-60Hz-l-b-y/dp/B08D9BCX1R
- In reply toAlt0⬆:
Sorry for the delay, @Alt0. I was travelling for the holidays.
Are you still seeing this delay with a different splitter?
- In reply tomichael⬆:
I just tried this one which was a bit more pricey at $30 (https://www.amazon.com/gp/product/B08D9BCX1R/ ) and had some onboard buttons for EDID, unfortunately the exact same thing is experienced as soon as the TinyPilot HDMI cable is plugged into either splitter port.
Had to set to the simple "copy" switch not 4K, so to ensure it has enough power.
Again the effect is like a noticable "lag" on the actual display monitor itself. That isn't noticable on TinyPilot's GUI itself since there is inherently a delay.
It must be something that uStreamer is doing to the HDMI stream which is bottlenecking splitters. You'd think it is some sort of DPC spike from the slow down in mouse refreshing (as if the fps gets lowered), but I believe this is purely what is being rendered and output. Something with uStreamer + an HDMI splitter / duplicator doesn't seem to play nice.
I wonder if I should go back to testing other uStreamer settings, or if this is even doable.
While a splitter isn't necessary, it allows things to be routed say thru a dock and have less cables needed to plug into a laptop (yes, when testing I've taking the dock out of the equation)
Thanks for following up!
Unfortunately, I'm not sure what's causing the delay in this case. It seems like splitters try to do some magic to combine EDIDs of the two connected devices, so it's hard to debug the root cause or fix it.
Oh man! I wonder if we could tweak some command line parameters from uStreamer or if that would matter. I tried just hw and cpu as the —encoder but without luck
One longshot is to try applying an alternate EDID.
Darn! Was hopeful on this one! But no luck with fixing the slave display lag issue. Question: Should I leave this new EDID, or revert it back?
In any case, I guess I can live without an HDMI splitter/ duplicator, but was just hopeful that TinyPilot would be compatible with it like Startech Crash Cart NOTECONS02 ( https://www.startech.com/en-us/server-management/notecons02 ), tho that does use VGA, for which I had a converter that took the VGA --> HDMI --> Splitter, without problems. On a whim, I tried to convert the TinyPilot video string from HDMI --> VGA --> HDMI --> Splitter, but didn't get any signal (probably too many conversions to convert to-and-fro)
It's best to just take the splitter out of the mix (the display lag is a deal breaker for daily use on the connected slave machine).
TinyPilot's uStreamer just must not play nicely with these splitters. If you have future suggestions, feel free to drop some other knowledge :-). Thank you!