http://kernellabs.com/hg/~dheitmueller/polaris4/

It’s not completely cleaned up yet, but both devices are working.

Thanks go out to Conexant for making available a base Linux driver, and to Hauppauge for sample hardware and sponsoring device support and a bunch of the cleanup work required to get the changes into the mainline kernel.

Tester feedback welcome, as always.

http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

We found various issues related to the comb filter, the power management, and a particularly nasty problem with the frame alignment that was causing very jerky video when there was motion. In all, I think users will be very happy with the improvements.

And of course, a big thank you goes out to GetWellNetwork Inc., who was kind enough to sponsor the work.

As always, feedback from users willing to try out the changes is always welcome in the comments below…

Ok, apologies to anyone from the U.K. for my quirky American sense of humor.

Seriously though, Trident Microsystems finally agreed to allow the DRX-J code to be released under a BSD license. This means that we can finally release a driver for the PCTV 80e.

http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-80e

The ATSC support has been tested. Haven’t had a chance to burn in the ClearQAM support. And there’s a bunch of cleanup work required before it can be submitted upstream. But it does work, and should satisfy those who have this board and want to see it working under Linux.

Thanks go out to Trident Microsystems for finally allowing this release, as well as to Hauppauge and PCTV Systems for pushing them on it for so long.

Testing/feedback welcome of course in the comments below.

If anyone is interested in closed captioning support for the HVR-950q, you can get it from the following tree:

http://kernellabs.com/hg/~dheitmueller/v4l-dvb-950qvbi

Unfortunately, the work exposed a bug in tvtime which prevented it from working, which I fixed here:

http://kernellabs.com/hg/~dheitmueller/tvtime

But it *is* working with zvbi-ntsc-cc out of the box.

Comments welcome, as always. Next stop: HVR-950q quality improvements!

For the last six weeks we have been diligently working away at analog support for the Ngene chipset. In particular, we’re working on Linux support for the Viewcast 240e and 450e, which are commercial grade PCIe capture cards (the 240e has one port and the 450e has four ports). The hardware is loaded with features and we’re working to bring those features to Linux (including VBI support, ALSA audio, secondary hardware preamp volume controls). And the hardware itself has a host of input types, including composite, s-video, component video, and both stereo RCA and XLR audio inputs. It even has a 19″ rackmount panel for hooking up all the different inputs to (the 450e can have 12 video feeds connected).

We’ve ended up with new drivers for the Micronas avf4910a video decoder, the Cirrus cs3308 8-channel volume control, and a huge refactoring of the ngene driver (we’re at well over 100 patches in the tree). The goal is to provide a rock-solid solution for high density 24×7 video capture.

And of course we’ve got a bunch of stuff in the pipeline – including more improvements to the HVR-950Q, fixes for cx23885 boards such as the HVR-1800, and support for some new hardware (which we will be talking about when the time is right).

In other words, don’t interpret the fact that we’ve gone quiet as a sign that we’re not doing anything – we’re just *really* busy….

http://kernellabs.com/hg/~dheitmueller/ngene2/

As an added bonus, in order to familiarize ourselves with the ngene chip, we picked up a couple of Avermedia Aver m780 boards and got them working in digital mode (that’s a PCIe ATSC/ClearQAM card with an onboard MPEG encoder). Getting the analog support working will require a significant amount of work on the ngene driver.

So if you happen to be an owner of an m780, feel free to give it a try and provide feedback in the comments!

I know many people have been waiting a long time for this, and I am happy to announce that we’ve got a tree setup which can be merged into the upstream kernel, as well as firmware which can be legally redistributed.

Testers are welcome to try the following hg tree:

http://kernellabs.com/hg/~dheitmueller/v4l-dvb-drxd

To build:

hg clone http://kernellabs.com/hg/~dheitmueller/v4l-dvb-drxd
cd v4l-dvb-drxd
make
make install
reboot


Note, under Ubuntu if you receive errors about not being able to compile the firedtv driver, open “v4l/.config” and change the firedtv=m to be firedtv=n.

You will need to get the firmware from the following location and copy it to /lib/firmware

http://kernellabs.com/firmware/drxd

I’ll be looking to get the firmware bundled into the distros, so that the products will work “out of the box”.

The usual disclaimers apply as of this point I’ve only done minimal testing at this point with a DVB generator and tzap/mplayer (if you want to consider the last 12-14 hours of testing and debugging/fixing problems and edge cases as I found them as “minimal”).

Feedback welcome (both positive or negative) by commenting below. And as this was another unfunded project that KernelLabs did solely for the benefit of the community, if you find this work useful then feel free to throw a couple of bucks into Devin’s LinuxTV support fund

UPDATE 2010-02-28 11:04: I forgot to mention that in addition to the drx firmware, you also need the firmware for the xc3028 tuner, which can be installed via the following directions. Sorry for the confusion (and thanks to users wishmerhill and fabio for pointing out my oversight)!

http://linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#Firmware_Information

Progress continued on improving em28xx analog quality. I isolated a problem with chroma AGC in the saa7115, and am working on a fix now.

I nailed down most of the analog problems being reported against the HVR-950q under MythTV. Posted a tree with fixes and solicited testers to try it out before submitting it upstream.

I finally plugged in my HVR-1800 and took a quick look at the analog support situation under MythTV. It falls down pretty hard with the current v4l-dvb tip, but the situation is somewhat improved with some patches Michael did a few months back which haven’t yet made it into the mainline. Nonetheless, it still would need quite a bit more work before I would consider counting on using it in a MythTV box (looks like a couple of race conditions which will be annoying and time consuming to isolate). Also, a number of the controls are still not implemented, which cause some “red herring” error messages in the MythTV backend log file. I’ll probably also have to plug in a PVR-150 card so I can better understand how the driver capabilities should be announced (comparing the ivtv driver against the cx23885 analog support).

So, things are moving along….

http://kernellabs.com/hg/~dheitmueller/hvr-950q-pmfixes/

There was also a neat bug where the first tuning request after switching from analog mode back to digital would *always* get dropped on the floor. This would cause users to see the first tuning request fail, or there would be cases where if you had been watching analog TV and then later the backend went to record a digital program, that recording would fail.

These changes are not heavily tested yet (they do appear to fix the issues found in my environment), so I am looking for people who have seen problems to try them out and report their results in the comments.

Once I’ve gotten some feedback, I will issue a PULL request to get these fixes merged upstream.

After adding some debugging to the driver, I found basically three classes of problems:

1. The power management on the au8522 was setup such that the chip would get completely powered down when switching modes. Essentially what would happen is when switching from analog to digital mode, the v4l stack would tell the au8522 to completely power down while in the middle of bringing up the digital half of the chip. The power management for both the analog and the digital side of the chip need to be changed such that they only power down their respective parts, rather than the entire chip. It’s basically a race condition, which is why it works sometimes but not others.

2. The digital side of the board won’t actually perform the first tuning request when switching from analog mode, because the driver’s internal state thinks it’s already tuned to the target frequency (so the set_frontend call just does a “return 0″ without actually doing the tune). We will need to explicitly clear out the driver state associated with the digital side of the chip when powering down or switching over to analog mode. That’s why you don’t get a digital lock when switching from analog to digital mode, but then if you change the channel the next tuning request works.

3. MythTV’s “input group functionality” appears to be generally broken. Input groups are designed to handle cases where there are multiple inputs sharing a tuner, so that they don’t get used at the same time. However I can pretty clearly see that even after switching to analog mode, some thread in the mythtv backend continues to run the digital side of the board, performing tuning requests and polling the digital demodulator’s status.

So in other words, this is going to be more annoying than originally thought. Fixing the couple of driver issues is pretty straightforward, but digging into the MythTV code and figuring out why it’s screwed up is going to take some real effort (and users wouldn’t get the benefit of those changes unless they either build mythtv from source or wait until 0.23 comes out).

At least now I have a better idea as to exactly what is going on.