+1000 points for the PiKVM V4 Plus. We (Revise Robotics - a YC company!) refurbish laptops with robots and AI - as part of this, we (or rather, the AI) send(s) keyboard commands in software to the computers we're refurbishing.
How/why? The AI needs to navigate the BIOS among other tasks - so we need a KVM to send arrow down and enter, roughly speaking.
We were a GL.iNet KVM shop until we ran into a nasty issue with a specific ThinkPad - the GL.iNet would send an incorrect USB 0 byte which most laptops ignored, except this ThinkPad which was freaked out by it / beeped / wouldn't accept any key command.
I couldn't let this problem go, so I got a low level USB debugger [0] (which I extremely recommend) and wire-debugged the USB signal, A/B comparing the GL.iNet and the PiKVM. The PiKVM was doing things properly (usb-wise), so we swapped all (~10) of our KVMs for it.
I also remember that the GL.iNet was stranger/more difficult to customize (it's just running pikvm the software but doesn't let you customize it as much). The GL offers a nicer UI, but it doesn't matter that much (we drive it via API) and we're happy to support the actual PiKVM authors/company. It's a fantastic product. Not cheap, but truly truly great.
P.S. If someone from GL wants to reach out, I can offer you a lot of low-level debugging info -- fixing this issue would be great.
I think if you can afford it, the PiKVM is still the gold standard... and also one of the best engineered devices, with the most flexibility. It costs a lot because it's worth it.
They also have a nice (if messy) solution for multiple device management with an external box (TechnoTim had some good coverage on his channel/website[1]).
Most other Pi-based KVMs use PiKVM's software anyway, and I'm not sure if any directly support PiKVM upstream (they should, IMO).
The other class is the JetKVM and its derivatives (many forked JetKVM's snappier Go software), and that's another reason I've stuck with JetKVM itself. It seems to have a nice community around it for mounts in almost any situation, and hacks to get weird things working correctly with it. They're also going to have a PoE + full-size HDMI version soon, I think, with microSD for expanded ISO storage.
I'm not from GL. I write my own USB HID handlers and I'm being nosy about bad protocol that exists in the wild. Was the 0 byte in some input report? In a descriptor? Somewhere else?
TLDR - GLKVM's kernel emits a trailing 0-byte DATA packet (ZLP) (which PiKVM does not)
Supposedly, this is due to the `req->zero = ((count % maxpacket) == 0)` line in the kernel's f_hid.c - which, for 8-byte HID keyboard reports, makes it append a trailer packet. Strict BIOS HID stacks treat this 0-byte packet as malformed and beep.
Interesting. My first thought is wondering whether the keyboard HID is adding report IDs to its input reports, because it isn't in boot mode or something. That would have that effect.
It's one of those things where $400 is WAY too much for a homelabber, but most companies (even small ones) can barely count that low when speccing out hardware, ESPECIALLY these days. $400 is like one hard drive in a machine that will potentially have 8-24 of them.
......Unsettlingly that's also like 16GB of dram in a machine that might be measuring memory in TBs
I kinda wanted to get a KVM recently, but decided to save my money to afford RAM for my planned server build instead. Might even get a 32 GB kit for $400.
There are tons of devices used that have no built-in BMC (like the Thinkpads in the original comment in this thread), yet still need reliable remote control in certain cases (e.g. a remote lab, or multiple-unit headless testing).
It would be a bit odd if a place was deploying new Dell servers and slapping IP KVMs on top of them.
OK, I just don't see the intersection of people/companies that are using thinkpads in their server room and those willing to pay $400 for a KVM being too large
How/why? The AI needs to navigate the BIOS among other tasks - so we need a KVM to send arrow down and enter, roughly speaking.
We were a GL.iNet KVM shop until we ran into a nasty issue with a specific ThinkPad - the GL.iNet would send an incorrect USB 0 byte which most laptops ignored, except this ThinkPad which was freaked out by it / beeped / wouldn't accept any key command.
I couldn't let this problem go, so I got a low level USB debugger [0] (which I extremely recommend) and wire-debugged the USB signal, A/B comparing the GL.iNet and the PiKVM. The PiKVM was doing things properly (usb-wise), so we swapped all (~10) of our KVMs for it.
I also remember that the GL.iNet was stranger/more difficult to customize (it's just running pikvm the software but doesn't let you customize it as much). The GL offers a nicer UI, but it doesn't matter that much (we drive it via API) and we're happy to support the actual PiKVM authors/company. It's a fantastic product. Not cheap, but truly truly great.
P.S. If someone from GL wants to reach out, I can offer you a lot of low-level debugging info -- fixing this issue would be great.
[0] https://greatscottgadgets.com/cynthion/