Video capture I started experimenting with HDMI-over-IP extenders. Some turned out to use a rather standard video format (blog.danman.eu/new-ver…-lkv373a) for streaming. It worked fine… with one little inconvenience: handling the network stream put a significant load on the Raspberry Pi that handled it. I could use a different system for video processing than the RPi responsible for USB emulation, but that would make the whole setup even more complex. Anyway, that’s just a minor inconvenience that requires some more cooling on the RPi, not a deal breaker. About the time I got all of this working, I came across PiKVM (https://pikvm.org/), which looked almost exactly like what I needed. It uses a TC358743 chip connected directly to an RPi (via camera interface) instead of a separate HDMI-to-IP encoder. Setting it up presented some challenges, but the PiKVM project (or, I should say, Maxim Davaev, the guy behind the project) had all of this figured out already. The first issue I encountered was getting a TC358743 device initialized and detected at all. There were several parts to this: The default kernel from OpenSUSE does not include all the necessary drivers (in particular, bcm2835-unicam). They’re currently available only in a kernel from the Raspberry Pi Foundation (www.raspberrypi.com/documen…era.html). I chose to compile it myself with a config based on the one from the PiKVM project. There could be something I’m missing here, but this approach got me a working setup, and I didn’t want to spend too much time on debugging video drivers. Several modifications to config.txt were required: dtoverlay=tc358743 — let the kernel know where the device is start_x=1 — load GPU firmware with video input processing included gpu_mem=128 — required by start_x=1 The latter two must be in config.txt specifically, not a file included (www.raspberrypi.com/documen…txt.html) from there, which is a bit problematic on OpenSUSE, because config.txt is forcefully overridden on each update and only the included extraconfig.txt is meant for user modification. I worked around the issue by mounting the bootloader partition under an alternative mountpoint to disarm the config.txt override. This issue is in OpenSUSE’s bug tracker (bugzilla.opensuse.org/show_bu…_bug.cgi). I have yet to test the upstream fix for the issue. After fixing the above, I had a /dev/video0 device. Then, it was just a matter of configuring it (https://forums.raspberrypi.com/viewtopic.php?f=38&t=281972). Specifically: Loading an appropriate EDID: v4l2-ctl --set-edid=.... The EDID describes the capabilities of this “monitor”. There is a catch if you want to use Full HD resolution: the interface bandwidth is a bit too low for 1920x1080 with a 60Hz refresh rate, but it is enough for 50Hz (yes, unfortunately). This had to be described in the EDID. The author of the tutorial linked above provided some examples (https://github.com/6by9/CSI2_device_config). Setting digital video timings: v4l2-ctl --set-dv-bt-timings query. This can be done only when the system connected to the HDMI port starts and chooses a resolution, and it needs to be repeated each time the resolution changes. I’ve integrated (github.com/os-auto…ull/1741) both of the above into the openQA driver. For the openQA integration, using 1920x1080 resolution was not perfect. OpenQA operates on images at 1024x768. If it receives anything else, it scales it. The result of a 1920x1080 screen capture downscaled to 1024x768 was not nice, to put it mildly. It not only made some text unreadable, but the difference in aspect ratios heavily distorted the image. For example, this made it impossible to reuse reference images made in other tests. I am considering enhancing