He's reporting that he believes the device runs hotter under Linux than under Windows. Now, I already know that we're not powering down the device at idle, so essentially it's always running at full power. And at least the HVR-950 I have runs pretty hot to begin with.
So, the question is: is this guy right? I'm certainly not suggesting he's lying, but is his assertion correct? I really need to find some way to quantitatively tell if the device's thermal profile differs, because if I'm driving components improperly it could shorten their life or burn them out. I guess I can rig up some sort of thermal probe that I can tape to the F-connector with some thermal paste.
But this again got me thinking about Markus and his em28xx driver.
The reality is that I don't know if the device is being properly configured. All of the power management is from reverse engineering via analysis of USB traces. The entire V4L driver is a product of guessing the functionality of various registers through trial and error.
In other words, if I had the damn datasheet I could just look up how to properly program the device registers.
Markus has the datasheet because he works for Empiatech. He maintains his own driver separate from the V4L mainline tree.
http://mcentral.de/hg/~mrec/em28xx-new/shortlog
It's licensed under the GPL, but for a number of reasons (some technical and some political), I can't see how it will ever get into the mainline Linux kernel.
So here we have me, Mauro, Douglas, Aidan and a few others hacking away at the "community" driver through reverse engineering, when the vendor of the chipset is paying someone to write and maintain a GPL'd driver based off of the datasheets. This is just stupid.
Can't we all just get along?
The reality is that I don't see this as a competition. It's not about whose driver is "better". It's about getting support into the mainline kernel so it "just works" for users. When I started this, I started working on the V4L driver because of some controversial licensing on the mrec driver and I wanted the support in the mainline kernel. Now that the mrec driver is under the GPL as well, why would we not want a vendor supported driver in the mainline kernel? It's likely to be of higher quality in a number of ways since they have a developer working full time on it and because the driver's based off of the datasheets instead of being reverse engineered.
I took a close look at the mrec driver tonight, and it's pretty good. So I asked myself, why wouldn't this be accepted in the V4L project (and the Linux kernel)?
So this doesn't sound like I'm bashing the driver, here is both a list of the good and the bad thing I see about the driver:
=== Good ===
- Significantly better device support - Markus has access to the actual hardware for many of these devices, spends time adding support for new devices, and since he works for the chipset vendor can in many cases just call the manufacturer of the product and ask them questions.
- Proper tuner locking - tuner locking was one of the big issues that caused infighting before Markus forked off his code. Let's face it - it's been over a year and most of the other devices don't do any locking at all. His scheme, while not unified across drivers, is better than nothing.
- Based on the chipset datasheets - He had the benefit of just being able to look up what the registers mean
- VBI support for analog - a recent addition in the mrec driver, but none at all in the V4L driver
- Support for other demods not currently in V4L - I don't think we have any devices yet that use the LGDT3304, but Markus's driver has support for devices that do.
- More thoroughly debugged - He's working on this full time. He's working bugs, dealing with issues, and putting in proper fixes based on reliable information instead of reverse engineering.
=== Bad ===
- Doesn't leverage common infrastructure such as videobuf (resulting in duplicate functionality and more difficult for those who have to maintain multiple drivers)
- Firmware blobs embedded in source - While it's easier for the user, many distributions do not allow firmware blobs in the kernel due to the belief that this is not GPL compatible. We would need to get permission from the vendor to redistribute the firmware as a file (in the V4L driver, we extract it from the Windows driver binary)
- Ambigious licensing - some of the files have headers from companies other than Empiatech which are very clearly not GPL compatible (like the Micronas drx3973d driver). Also, it's not clear that even the firmware blobs mentioned above are authorized to be redistributed by their rightful owners (Xceive and Micronas). While Empiatech may be ok with making a GPL driver, these parties have not consented to having their intellectual property in the kernel (they may have consented but the header files say just the opposite).
- It has its own xc3028 and xc5000 tuner driver. I don't know whether his driver is better than the one in V4L. Presumably he has the datasheets for those parts, but on the other hand the V4L driver allows loading of the firmware externally. The V4L drivers are also used by devices beyond the em28xx and may have functionality required by other companies products.
- What I'll call "Black magic" - lots of arbitrary code without any explanation as to what it is doing or why. Why does the DVB init routine write 0x77 to register 0x12? What does that do? A combination of poor use of constants and commented code combined with a lack of access to the datasheets leaves this a mystery. You just have to "trust that it's doing the right thing because it works"
- He's the only one who has access to the datasheets, so there is limited opportunity for peer review. The community driver is based on reverse engineering, and we can pass around USB traces we collect to justify/explain design decisions. How do you question a design when the basis of answers is essentially "because the secret document that I can't show you says so"?
I keep thinking about how I could be working on other things, rather than duplicating the efforts of someone else.
Grrr....
I guess I'll get back to my ATSC support for Kaffeine now. At least there I have both the source code AND the specifications.
