em28xx: enable DVB for HVR-900
http://linuxtv.org/hg/v4l-dvb/rev/ca65777314d2
em28xx: Properly register extensions for already attached devices
http://linuxtv.org/hg/v4l-dvb/rev/64e24dfade80
em28xx: Split HVR900 into two separate entries
http://linuxtv.org/hg/v4l-dvb/rev/648a6da8dc3a
Submitted a couple more tonight with some cleanup...
Also continued work on the ATSC scanning support for Kaffeine. This is going to be harder than I thought. The code that parses out the PMT/PAT/PSIP info is really convoluted the way it is written. It is riddled with magic numbers with no explanation such as:
Do you know what those offsets are? The author appears to have never heard of anything resembling constants, whether they be done with #define or enum. It's especially annoying since I have to keep looking up all the raw values in the various EIA standards or compare it against a run of the dvb-app scan in verbose mode.
type = getBits(buf,0,8);
pid = getBits(buf,11,13);
Also, the formatting style wears on the eyes. Like this:
Yeah, there are no spaces between any of the comparsions in if() statements. IMHO, the following is MUCH easier to follow:
if ( audio && desc->napid<desc->maxapid ) {
... do something
}
It's not a typo. The entire project is like that. It's clearly the author's intended coding style. I would love to pass the whole thing through indent but he/she clearly likes it this way.
if ( audio && desc->napid < desc->maxapid ) {
... do something
}
The experience thus far makes me want to scrap the whole scanning subsystem and merge the detection functionality from dvb-app's scan tool. At this point I just wanted to do the minimum work to get the ATSC scanning working (as to ensure it will be taken upstream). Really the whole thing should be refactored but that's a can of worms I'm loathed to open.
I'll get the fucker working but it won't be pretty.
At least all of both the EIA and ATSC standards are publicly available, so none of this is an exercise in reverse engineering...
