Tonight I finally finished the HVR-1600 ALSA cleanup and submitted what I hope is the final PULL request to get it into the mainline.
While I was there, I took a quick look at how well tvtime works with the HVR-1600 – in short: it doesn’t work, and it fails in a way that I suspect would leave most users scratching their heads (in fact, I was only able to understand why it didn’t work by examining the source code). I started to look at the issues in terms of what will be required to support the HVR-1600, and what would be required to make tvtime better report the reason for failure in cases where someone attempts to use an unsupported tuner.
The reason I’m mentioning this is because I am strongly considering dropping support for V4L1 in tvtime – only supporting V4L2. Why, you might ask? Because the code is littered with conditional logic depending on which version is being used, and any changes I make require twice as much testing to ensure that I am not causing a regression in V4L1 support. Plus, with a grand total of three obscure webcams that haven’t been converted to V4L2 (out of over a hundred products), it’s just not worth it to maintain the code.
By removing the V4L1 code, I can make things much cleaner, be more confident that the functionality that we *do* provide works, and I can modernize the interface to better identify things like device capabilities (which are currently absent because they weren’t available in V4L1). This means you will get sane error messages if you do things like try to use your PVR-150’s MPEG device in tvtime, or use a tuner that has a colorspace that isn’t supported in tvtime.
My goal at this point is to get tvtime working with as many modern tuners as possible, and if dropping support for a few really obscure tuners that people cared so little about that they were never even converted to V4L2 makes that goal easier, then I think that is an reasonable compromise.