While Kernel Labs has been shipping a driver for the Hauppauge Colossus for a couple of years now, we have generally been focused entirely on the use cases that commercial parties care about, and these tend to be things like gStreamer, ffmpeg, and VLC. However in the last few days I finally got around to trying out the driver with a stock MythTV system, and the results were pretty interesting.
It didn’t work on the first try. I guess this wasn’t too surprising given the rats nest of V4L2 capture code in the MythTV backend. Note that I’m not making a criticism of the MythTV developers – it’s really hard to support so many devices, and in many cases there are workarounds for driver bugs which are either still outstanding or were fixed years ago. I certainly cannot fault them for doing whatever they could to make devices work within their application despite those bugs (even when those workarounds are ugly).
When running the MythTV setup program for the backend, my first instinct was to choose the HDPVR profile for the Colossus. After all, both devices are architecturally similar (despite one being USB and the other PCIe). They both use the V4L2 API to deliver compressed transport streams with H.264 video and AAC audio, and have basically the same input types (HD component, s-video, etc). Unfortunately when I went to enter LiveTV mode in the MythTV frontend, I received no video, which began an iterative process of digging through backend logs and the MythTV source code to better understand what’s going on.
When I started looking at the source code, I realized that you needed more than to simply select the HDPVR input type in the GUI for the Mythbackend to treat the device as an HDPVR. The backend code is littered with checks of the driver name (looking for “hdpvr”) and using that to change the behavior of the capture code.
So I cheated: I hacked our Colossus driver to report itself with driver type “hdpvr”. I’ve done this in the past with some of our tuner drivers to announce themselves as an HVR-950q, mostly for applications written by commercial customers who hard-coded logic based on the device type. Hence by adding a modprobe option to the Colossus driver called “emulate_hdpvr”, I can make the driver “pretend” to be an HDPVR from an application perspective. All the custom logic for the HDPVR was now being executed by MythTV.
This exposed something else – many of the places in the code which were designated as specific for the HDPVR aren’t really unique to the HDPVR at all. For example, there is code which explicitly doesn’t call G_TUNER if it’s an HDPVR. But in reality you shouldn’t call G_TUNER for *any* device which doesn’t expose V4L2_CAP_TUNER in it’s device capabilities.
I can certainly understand why some of these constraints are hard-coded for the HDPVR – even after five years the original HDPVR continues to be the only HD capture device that has freely available Linux drivers. As soon as a second device gets driver support, presumably some of these hdpvr specific constraints will be made more generic to all HD capture devices.
All that said, in the end I did get it working (see screenshot below). It was a useful exercise as it did expose a couple of bugs in our own driver which are now fixed (for example, we had a bug in the brightness control exposed by testing with MythTV which caused the video to be too dark by default).
