back

by gregsadetsky·2mo ago·view on hn ↗
+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.

[0] https://greatscottgadgets.com/cynthion/

5 comments
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.

[1] https://technotim.com/posts/pikvm-at-scale/

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.
Isn't that expected in USB so the receiving side knows it's at the end of the data transfer?
Just wanted to give you kudos for having a hw company in nyc. You don't see to many of those around :p
Surprised no one's built a BIOS MCP yet
Extremely please build one! I'm serious. :-)
$400 for kvm?
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.
don't these boxes already have a BMC? KVM is kind of poor man's BMC.
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
Surprising amount of gear required extra licenses or even parts to have fully functional remote console that does all the stuff PiKVM 4 brings to the table, and not always do you have the benefit of properly operational netboot infrastructure (especially in corporate settings with their usually broken by design networks) - and remote boot media might be gated behind license.

So you end up with ipkvm because there might be windows server that requires remote display, or because for various reasons IPMI SOL or equivalent does not work properly (BIOS mode enabled instead of UEFI, SOL requiring extra license, etc). Or even not being able to setup autoconfiguration for BMC but for various reasons it's easier to setup ipkvm.

TBC I don't necessarily mean they're using them on those servers. Just saying the prices are peanuts to them. I find KVMs are usually used for non-rackmount / weird hardware that nonetheless ends up in a server room.
You're supporting the developers original work at that price. There's plenty of cheaper devices that take that original work and just throw it on some chips