VirtualHere Client windows (USB list or KVM window) for Modular KVMIP on macOS (x86_64) doesn't display in Cmd+Tab overview or dock and doesn't retain Keep Host Awake setting

So part of the reason I was testing on Windows is there is an intermittent flicker of the video stream when the target machine's resolution is set to 1080p rather than the 4096/3860 options, but I encountered an issue where after a while the VHClient lost connectivity to the VHServer on a remote host, even though the macOS machine looking at the same VHServer never lost communication.

All devices are connected to the network via wired ethernet connection, and the crazy thing is the hiccups only seem happen on the Windows node, I don't think I've seen the macOS node disconnect once other than very early in my testing when I was running another application on the VHServer device that was heavy on network traffic and used a decent bit of CPU/memory as well.

Monitoring the System Message as well as the latency from both Windows and macOS clients it is 1ms on the macOS client and 2-3 ms on the Windows client, I can try moving them all to the same switch to see if there is a weird hiccup, but I'd be really surprised since I otherwise have really solid connectivity.

The errors I'm seeing in the System Messages on Windows are below:
#Yesterday
Connection 1 receiving msg size didn't complete due to error 10053
Server ping timeout, shutting down connection 1

Connection 2 receiving msg data size didn't complete due to error 10054
Server ping timeout, shutting down connection 2

#Today
Connection 3 receiving msg size didn't complete due to error 10053
Server ping timeout, shutting down connection 3

I have a feeling something is being too aggressive about shutting down the connections for a single ping failure, because the internet on the Windows machine is fine and not really doing much of anything else, and the macOS machine never even blips.


Now the really weird thing is when I attempted accessing the two different KVM HDMI resources from two different computers through the same VHServer I'm able to see the video on both, but the macOS host is saying it lost contact with the VirtualHere Emulator, and it won't let me type into either host, but the Windows machine when I disconnect the macOS one and connect from Windows was briefly able to interact with the hosts, but now it too is saying "Sleeping (move the mouse to wake up...)" but it is ignoring the mouse.

From the error logs on macOS it is saying "error clearing halt on ep0x83 for device 8112, -1" or "error clearing halt on ep0x81 for device 7113, -1" or "error clearing halt on ep0x81 for device 7111, -1" or "error clearing halt on ep0x83 for device 8114, -1" .

On the Windows node I turned on the "View USB Hubs" and it threw some errors about TreeView_SortChildrenCB() (Cannot create a file when that file already exists.)

The Windows node also tries to open COM5 and COM4 but gets access denied, I'm not sure why it wants to use a serial device when it isn't running the server, is that one of the ways it sends the HID data, because it was working without that for a while.

So another interesting thing is I was monitoring the traffic on the VHServer using jnettop and noticed that the Windows host where I was running VHClient (but had quit it) apparently had a rogue network connection staying open even after I had ended all the connections until I totally quit the client and started it again. The rogue connection was using 4Mbps of bandwith, which is about half of what it is using with a freshly launched VHClient, but that bandwidth usage was happening with no active KVM sessions.

I think I narrowed down the root cause of the issues though, if a macOS client accesses a host and then you close the window it very frequently has the failure "error clearing halt on ep 0x81 for device 7113, -1" (or one of the others listed above) which appears to be the VirtualHere Emulator, so I'm guessing it has the port "disabled" or THINKS it is on the VHServer side, and then neither macOS or Windows can access it until something triggers the port to wake up again. Now the very weird thing is the last few times I've attempted it seems to auto recover, but there were a couple times I had to completely quit the VHClient (on both machines) and start it back up again for things to be happy.

So it appears that if Windows runs into permissions issues with the COM devices it is pretty much the same as macOS's ep 0x81 fault, but while macOS will sometimes recover, once Windows has hit the permissions error it is a dead dodo.

I'm using a formerly Android device running Armbian Linux on an RK3399 chipset, so I'm using that "optimized" build to take advantage of all the big and little cores (I hope?).

The kernel seems to be fine, but the server maybe isn't requesting/releasing the resources in the order that the kernel would like?

https://gist.github.com/dragon788/593cc3a457f2eb6c501160a882c71636

The first file is huge, but is basically the dmesg/journalctl output while the second file is much shorter but it showed me opening both video sessions from the Windows node, it couldn't access the inputs on the second host, so I closed that connection on Windows and opened it on macOS and it was able to communicate and let me unlock the remote host. Then closing the session and going back to the Windows host I was able to open it and click and type again.