You can capture VGA using all the same tools by adding in a VGA to HDMI adaptor. I haven't measured the impact on latency, but a few users have confirmed that it works.[0]
VGA capture has been solved for a long time by readily available products. You can get multi-port or single port units like the Lantronix Spyder. For the most part, HDMI has not had much of a solution. I suspect it’s because of the copy protection enforced by media companies combined with most sever companies moving to fully built-in management interfaces (e.g. IPMI, DRAC, etc.)
A few things to note about the video capture device:
- it hardware encodes to MJPEG at some ok but not great quality. Text becomes somewhat fuzzy but readable.
- a version with HDMI passthrough is available. It also has an extra optional power supply (micro usb) which is useful if you chain a dozen to one pi zero.
- the usb only ones can be as low as £5 on ebay ($6.55) and £10 for passthrough.
- it featured in an artcile by Micael Lynch which featured here on HN, where he explored the latency involved with such video caprure devices (https://mtlynch.io/tinypilot/)
If you are already using and arduino, couldn't you the use it as a HID device and send the keyboard (not sure if it does mouse as well) directly without going through a PS/2 emulation?
You can do it on the Uno, if it's real (or close enough) Uno that uses an atmega16u2 for the USB connection. Using HoodLoader2 like that post mentions: https://github.com/NicoHood/HoodLoader2 .
Most Uno clones skip the atmega16u2 and use a cheap USB to serial adapter instead, which will not let you reprogram it as a USB HID
> IBM was using the PS/2 standard (not to be confused with the PS2) to connect mice and keyboards to PCs
Oh my. I would never expect someone taking PS/2 for PS2. It made me wonder that many communication problems that I have with some of my team is caused because I'm a bit dated...
Notably, you don't need a relay for the RESET pin. Since the Pi and the mobo already share a ground courtesy of the PS/2 connection, you can just tie the RESET line to a GPIO pin and leave it floating (configured as an input, high-impedance state) when you don't need to reset the motherboard. When you do, configure it as an output and set it low, which pulls the signal to ground and places the mobo into reset. A moment later, turn it back to an input and the mobo's pullup raises the line and the chips come out of reset.
If you're feeling extra cautious, use a small FET and raise the gate to pull the pin low. More details in my other comment here.
If you give up the video capture part, a smart plug and a Raspberry Pi that can send Wake on Lan packets and can act as an SSH gateway should work, without extra parts. My beige Linux boxes currently use a $20 8-port switch and a Pi that's reachable via port forwarding.
So the original problem was the disk decryption password, but now instead you have a internet accessible serial console?
Seems to me like it would be better to keep the sensitive info on a separate encrypted partition/disk and let the server boot unencrypted so you can ssh in and unlock the sensitive data.
This solution would probably be harder to maintain and secure than a more straightforward solution to the original problem.
When the last story came out I picked up one of those cheap HDMI capture devices on ebay to play around with and could not get it to work on Linux. I think there are different firmware versions of this device floating around and only some of them can be made to work reliably.
Very impressive project, and I'm especially grateful for a detailed example of ps2dev. I was looking at ps2dev last year, wondering what it would take to create a PS/2 input device.
