InputShareUSB VS barrier

Have you tried using a different cable? A few months ago I wrote a similar program and someone experienced the same issue and it turned out to be the cable.

I wrote something similar (windows --network--> raspi zero w --usb--> target device). My first attempt used a simple tcp stream without nagle's algorithm and it was completely useable because I was sending way to many packets this way. After turning nagle's algorithm back on it generally usable but it also introduced something like a 0.5s delay (it's easily noticable, trust me). However the whole thing was pretty unstable, because even a small hick-up in network quality would result in a death spiral that took around 2-3s to resolve itself and make the program usable again. I'm sure I could've optimized my naive tcp protocol further to make it more stable but I chose to fix the problem on the source and wrote my own simple, reliable, ordered network protocol on top of UDP. While it currently has some limitations (no encryption, no congestion control, connection loss is somewhat ungraceful) it runs amazingly stable even under bad network conditions and with unnoticeable latency.

Both the Windows and Raspberry Pi parts of this project are written in Rust and can be found here.

Yes. When you use the Linux gadget driver it creates a device like /dev/hid0 for you in that you can write your usb-hid packets. This means that you can write a simple script that listens to a TCP connection and simply forwards everything it receives into /dev/hid0. On the PC side of things you then simply connect to this TCP server and you're good to go. Here is an example of what I'm talking about.

For software KVM you can use https://github.com/debauchee/barrier

I use it between a Windows PC & a Macbookpro (Linux version available but I don't have Linux)

libei looks useful. But IDK why libei is necessary to run Barrier with Wayland?

For client systems, couldn't there just be a virtual /dev/inputXYZ that Barrier forwards events through

And for host systems, it looks like xev only logs input events when the window is focused.

Is xeyes still broken on Wayland, and how to fix it so that it would work with Barrier?

With Barrier, when the mouse cursor reaches a screen boundary, the keyboard and mouse input are then passed to a different X session on another box until the cursor again crosses a screen boundary rule.

Barrier is a fork of Synergy's open core: https://github.com/debauchee/barrier

libei:

I have a similar gaming/WFH setup (2 monitors at 1440p 144hz) and I’ve been using Barrier instead of a physical kvm, and it works really well. Not sure if you’re open to a software kvm but if you are, I’m happy to answer any questions about it if you have any.

Have you tried Barrier? I casually used it to swap between my main rig and my MBP. Took a minute to get it setup but once I sorted it all out it worked pretty well. It has some settings and tweaks built in to address some of the layout issues you mentioned...

Barrier appears to handle PC switching only for the keyboard and mouse.

Sorry, probably not entirely on topic and can't answer anything reliable about the multimonitor stuff, but a tip regarding the 2 mice and 2 keyboards for the 2 different computers: use this: https://github.com/debauchee/barrier It's oss multi-os software that lets you use one mouse and keyboard (server) on several PCs (clients) easily over your LAN.

Barrier is a free and open source alternative.