pvrusb2 and hvr1950 sat in a tree...

K-I-S-S-I-N-G...

The new machine I built was meant to be a VPN server, Vmware server, media centre, myth-ical backend and gaming rig. I hand picked each of the components to be compatible with Linux and blow the socks of the Windows based alternatives.

The one thing I didnt quite anticipate was the Hauppauge HVR 1950. I knew quite well the misery of PCI based TV tuners that worked ONLY in Windows. The HVR 1950 is an external USB 2.0 device - because of which I thought it would be a breeze to use in Linux - after all, USB is a reasonably stable standard, and Linux does have V4L et all to manage so many AV (audio/video) devices.

I underestimated the hackery that companies are capable of.
It seems that Mike Isely found, while providing support for Hauppauge devices in Linux, that firmware needs to be present on the host OS to use the device.

Now dont get me wrong - I'm sure Hauppauge intentions were admirable: Seen from their point of view, this method presents a clean way for the host to send across the correct firmware for the device without needing to implement the USB firmware upgrade class.
And what better way to ensure the best possible firmware than to upgrade it at every power cycle?

Dear Haupauge software geniuses: FAIL!!!
Most people associate USB devices with plug and play - just plug it in, it will work just fine.
What happens when one of your customers plugs your USB device into an operating system that follows the USB standards to the book but doesnt know about your backdoor entry firmware uploader?

Why? Why would you do that?
Were you attempting to have an interesting version of DRM??

Anyway: For those of you who have already purchased a Hauppauge HVR 1950 device: Do not despair.
Hauppauge doesnt seem to be as malevolent as some other companies. They have permitted ivtv to actually distribute their firmware binaries.

However, ivtv doesn't have all the firmware binaries yet (as of Dec 2008), specifically not the ones needed for HVR 1950.

So if you did purchase the HVR 1950, you have only one option: You will need to use your install CD and pull out the firmware from there.

But first, lets do some reading and find out how this all works: Go to Mike Isely's fantastic explanation of pvrusb2 to see why it matters to us right now.

So first we need to extract the firmware. It works and works VERY well.

You should now have the three files
v4l-cx2341x-enc.fw
v4l-cx25840.fw
v4l-pvrusb2-73xxx-01.fw

In ubuntu, you will need to copy these three files into /lib/firmware/

Now take a look at the usage page. Note the "initusbreset" setting. Note what he says about it.

Now read this. It describes the problem: deadlock due to re-acquisition of instance mutex as a result of doing a USB reset to the device, the workaround: Keeping a file with "options pvrusb2 initusbreset=0" under /etc/modprobe.d/

Remember that creating that file will need su privileges. Now read this to see why a simple sudo will not work. More explanation here.
The trick is to do a straight su or an "sudo -s".

This workaround should fix the bug I faced - described here and here.
Please note that my current "uname -r" is "2.6.27-9-generic".
The reason I give my uname is because in one of the postings on Mike's listserver, this workaround is unnecessary starting from 2.6.27-10.
Also, in a later conversation with Mike over IRC, he explained to me that the "fixed" pvrusb2 driver in 2.6.27-10 does not have initusbreset as one of its known parameters. Therefore, modprobe will calmly refuse to load pvrusb2 if you keep that parameter in modprobe.d

Thats something I will need to keep in mind when I get the next generic kernel from Canonical.

Edit 1:
You need another firmware: go here and follow the extract.sh

Edit 2:
Just for a fraction of a second, I saw the 1950's red LED glow... Then it disappeared.
dmesg confirms that the various firmware files are used, but then I get: "cx25840' 6-0044: 0x0000 is not a valid video input!"

Attempted to contact Mike Isely on freenode#pvrusb2. No response yet.
Dammit I'm hungry - time to feed.

Edit 3:
It works! It works!!!
Thanks Mike!

Edit 4: Short explanation about the "magic" between edit 2 and 3:
The output of "cat /sys/class/pvrusb2/*/ctl_input/enum_val" should show the list of values that can be sent to cur_val in that directory.
Depending on whatever input you have attached to the HVR 1950, you need to echo that value to cur_val.
Since in my case, I have a composite cable connected to the 1950, all I needed to do was "echo composite > cur_val".

This made pvrusb2 switch modes into picking up the composite input.

Now at this point, /dev/video[0-9] should have an mpeg stream from the 1950.
However, to actually see if it works on the media player of your choice, you need to tell the media player to treat /dev/video[0-9] as a standard file, and not use the v4l / dvb interface on it.
In my case, the node is called /dev/video1 and my favorite player is vlc. Therefore to test it, all I did was:
"vlc /dev/video1 &"

... wait for a few seconds, and I am able to see the composite input in VLC!

Up next: actually configuring the 1950 to be a real tuner and make it work in MythTV.