HVR-2250
Feb 19th, 2009 by StevenToth
The HVR-2250 Linux driver – Where is it? This is the official status page for the Linux HVR-2250 / 2200 driver project. Check back here for updates on a regular basis to see my progress. Like most Linux v4l-dvb developers, I do this in my spare time, Hauppauge don’t pay me to do this. If this is your first time here, welcome! 
Update: If you have a couple of bucks to spare and would like to support or sponsor the project then either use the donation button at the bottom of the page or contact me directly. (Contact details on the About page).
May 12th 2009 9.18am
If you haven’t already caught up with yesterdays announcement then the project is slowly migrating to kernellabs.com and the main project page for the SAA7164 driver is here. If you haven’t already visited Kernel Labs then take a few moments of your time, I think you’ll like the content – I post on a regular basis and it will be easier for you to subscribe/track to it.
As more and more of the SAA7164 content is being posted to www.kernellabs.com the postings here at steventoth.net will begin to slow down and finally stop. This is intended. We’re outgrowing the steventoth.net blog and we need a site that can better present the SAA7164 driver and it’s development trees. (FAQ here)
That being said, the real news of the day:
- I’ve posted three new patches to the SAA7164 development tree, details are on the new blog here.
May 11th 2009 9.25am
It’s a big day and I have a few things to say:
- First, I want to thank you all for supporting the HVR-22xx project. Yes, you, Thank you.
- Second, together we’ve finally reached stage1. It’s been a long haul. Now we have a SAA7164 driver that supports ATSC/QAM and DVB-T. We’ve come this far because of your support and donations, but we’re not done yet. Stage2 (Analog support) is just around the corner and that will start soon. I hope you’ll stick around and support the project.
- I think you’re probably looking for this http://www.kernellabs.com/blog/
Have a great day!
May 10th 2009 9pm
After the recent 32/64bit cleanups I spent the day testing the saa7164-stable tree on 32 and 64 bit systems. ATSC is working as expected.
Generally I have two major types of saa7164 tree. 1) saa7164-stable and 2) saa7164-’other’. The stable tree is tested with all 7164 cards in various systems and should be a good choice for your MythTV ATSC/QAM/DVB-T needs. The ‘other’ trees are considered ‘bleeding edge’ and are not recommend for general use. Changes to the ‘other’ trees could occur daily as required but stable will only be updated when absolutely required, after regression testing.
Tomorrow is the big day.
May 9th 2009 1pm
A heads up for anyone who wants to prepare their platforms for the Monday release!
The minimum kernel version for saa7164 support will be 2.6.26 (Ubuntu 8.10). If your environment doesn’t meet this then the SAA7164 tree will not be selected for compilation and you won’t see the SAA7164 tree as a menuconfig compile options.
If you want to remove this requirement then remove the VIDEO_SAA7164 entry from v4l/versions.txt manually in the v4l-dvb tree.
Please upgrade your platforms if you want me to respond to any bugs, or not – if you know what you are doing!
May 9th 2009 11.51am
Cleanup complete. Other than final HVR2250 testing via MythTV to ensure nothing broke, I’m done.
Expect more changes shortly after release as I refactor more code and tighten things, remove debugging etc.
May 8th 2009 9am
Still more cleanup. What the heck does this mean?
Well, partially the linuxtv.org group adheres to certain kernel source code coding styles. Some of the formatting style I adhere to, some I don’t. I’d be the first person to demand that code conforms so, I’m adjusting the formatting to pass the kernel merge rules. This is pretty much done. The rest of the cleanup is removing bogus comments, turning long an tedious code functions into smaller more managable functions, easier to read and understand by you, the tester, cleaning up variable names, adding comments where appropriate. Get the idea? It’s tedious but it’s just as important as writing the code in the first place.
After this, retesting will take a few hours just in case any ugly bugs crept in.
I am happy to announce one thing:
- The first public tree will be available for download on Monday 13th 11th.
Exact details to follow.
May 7th 2009 8.13am
Cleanup in progress.
May 4th 2009 9.50am
Earlier today NXP blessed the GPL saa7164 driver and gave me the green light for a public release. This is something we’ve been planning together over the last few weeks. This is excellent news.
Thank you NXP.
Before I can release a tree I have some coding style fix-ups, whitespace issues and some general tidying. This will take a day or two. After this the first release will be announced via this website.
May the 4th be with you.
May 2nd 2009 8.31am
Regression testing against the cx23885 was fine, 100%. I’m having trouble with the pvrusb2 tree, I can’t get the driver to load (with or without my changes).
It’s been a very long time since I ran up the pvrusb for DVB-T so it could be a generic driver bug.
I’m working on this today.
May 1st 2009 9.18am
More DVB-T testing today.
I need to regression test the TDA10048 patches against the PVRUSB, HVR1200 and HVR1700 products before I can submit them for merge. I also need these patches in the kernel as they’re a dependency for the SAA7164 tree.
Apr 30th 2009 7.23pm
Testing of the 89519, 89619 and 89609 DVB-T models was a success. I’ve modified the TDA10048 driver to handle multiple input frequencies and I now force all bridge drivers (saa7164, cx23885 and pvrusb2) to specifically pass the I/F frequency to the TDA10048 during attach.
Looking good.
Apr 28th 2009 8.55pm
Testing started badly, the HVR-2200 demodulators would not achieve lock. Boo! Speculation surrounded the 7164 internal DIF. The tuner is driven from either the DIF or the TDA10048 demodulators, but not both. The belief was that the DIF (which was unprogrammed) and the demodulator were both trying to drive the tuners AGC, essentially confusing the demod.
In theory, just program the DIF correctly to avoid the issue. This turned out to be bogus, although an important issue that will have to be dealt with when analog support is addressed.
The bug/feature was related to incorrect sample rate programming on the TDA10048. Why? Probably as simple at the exting HVR1200/HVR1700 Linux drivers used a different clock frequency. Patching the TDA10048 registers allows the HVR-2200 demodulators to lock and everything is running fine. Now I’ll need to rework the TDA10048 driver and correctly seed the sampling registers based on board specific information.
So, the HVR-2200 is running correctly and streaming digital TV, that’s good news…. and I’ll need to rework the TDA10048 to make it a little more flexible. Grr!
Apr 27th 2009 8.56am
HVR-2200 DVB-T testing begins today.
Apr 25th 2009 7.54am
A second day of successful MythTV recordings. I think we’re in good shape. I did remove some spurious debug messages that were flooding my logs.
From the ‘Bizarre Factoid of the Day Dept.’:
- Of all of the states in the US this site has never been visited by anyone living in the state of Wyoming. Really? A quick fact check of US Census Bureau shows the estimated 2007 population as 522,830 people.
Apr 24th 2009 8.35am
The results are in:
- All of yesterdays scheduled recordings worked perfectly, no errors.
Six recordings are scheduled for today. Anyone want to predict the outcome?
Also, I’ve added support for model 88061 to the driver.
Apr 23rd 2009 9.01am
OK! I now have a MythTV backend configured and running with the HVR-2250 on US digital cable. Sweet!
Using multi-rec I have 4 virtual encoders covering the two digital tuners. All of my recordings are established and scheduled and the mythweb Upcoming Recordings view certainly looks busy enough to test the driver, with multiple overlapping and back to back shows in the mix.
Some comments on configuration: MythTV-setup configuration/installation was easy, it was no different to any other ATSC/QAM card configuration. Great! No magic required for the SAA7164 tree and DTV. It took 2 minutes.
(Unrelated: SchedulesDirect is a kick-ass service.)
Here’s the test plan for the next 48 hours: I have 13 scheduled recordings for today (thursday) and six for tomorrow.
The backend is recording a couple of test shows as I write, That 70′s show and a Kids TV show, everything looks good so far.
Let’s see how this turns out over the next few days.
Apr 21st 2009 9.58am
A couple of updates for you:
1. I’m waiting to hear back from NXP. They are reviewing an older slice of the SAA7164 tree and determining whether I can release it to the public.
2. I’m going to start some real-life MythTV testing tonight with the HVR-2250.
Specifically, I’m going to setup a new myth box with multi-rec on US digital cable. Using both digital tuners I’m going to mirror my primary MythTV backend. I tend to record 4 or 5 shows per day so thats 80-100 per 50 shows per week. Any duration or stability bugs show start to show themselves pretty quickly.
I’ll keep you posted with any updates.
Apr 18th 2009 9.53am
If you have any of the following model numbers then your product will definitely be supported on the first public tree.
HVR-2200: 89519, 89619 and 89609.
HVR-2250: 88001, 88021 and 88041.
Fixed a bug related to rmmod’ing the driver after it failed to register dvb correctly.
Apr 18th 2009 8.30am
Adding two new models to the tree today. HVR-2200 #89619 and HVR-2250 #88021.
Apr 16th 2009 8.50am
Hauppauge are planning to ship model #88021 soon into the HVR-2250 family. I sourced one of these yesterday so I’ll need to add it to the tree.
I also need to source a 89619 for DVB-T.
Apr 14th 2009 8.45am
Saturday was a great day. Aside from fixing a couple of showstopper bugs I dug out all of my HVR-22xx boards and went through them to ensure the current SAA7164 tree had support for DVB-T/ATSC/QAM.
So, if you have any of the following model numbers then your product will definitely be supported on the first public tree.
HVR-2200: 89519 and 89609
HVR-2250: 88001 and 88041.
That being said, I don’t have every model that Hauppauge have ever produced, so, a call to arms!
Do you want to see your product supported in the first public tree?
If I haven’t tested your model then please go back and find my ‘Thank you for donating’ personal email and hit reply, send a response back to me, telling me:
1. Your model number (89xxx or 88xxx) (see white label)
2. Your card revision (rev NNNN) (see white label)
3. Your country.
Please: Emails from project contributors only please.
I’ll review the data and find hardware samples, I’ll update the driver (and this website) and you’ll be a lot happier when the driver finally ships…. as will I
Thanks for reading, have a great day.
Apr 11th 2009 2.30pm
Testing is going well on both 32bit and 64bit ubuntu systems.
Hopefully this is the last of the timeout and race condition issues.
Both digital tuners on the cards are operating correctly and streaming DTV simultaneously.
Apr 11th 2009 8.46am
The windows driver and linux firmware extraction scripts are up on www.steventoth.net/linux/hvr22xx
I ran an overnight duration test on the first digital tuner last night, streaming transport. Hmm, the whole thing stopped after 3 hrs. Why? No idea. I’m looking into this.
After yesterdays posting and subsequent follow-up inside Hauppauge I now have a definitive list of SAA7164 boards that we’ve shipped so I can start to refine the tree with more detail.
I need to chase down a message timeout error today.
Apr 10th 2009 8.30am
Hauppauge’s US support page for the HVR-2250 shows the current production driver is dated March 27th 2009.
The inf shows the version as 7.6.1.27086 and the internal project names for the DVB-T (Wiltshire) and ATSC (Halesite) projects.
Importantly, the device detection sections looks like this:
[Hauppauge] ;%Wiltshire.DeviceDesc%=Wiltshire,PCI\VEN_1131&DEV_7164 ;; Wiltshire %Wiltshire.DeviceDesc8900%=WiltshireOEM1,PCI\VEN_1131&DEV_7164&SUBSYS_89000070 %Wiltshire.DeviceDesc8901%=Wiltshire,PCI\VEN_1131&DEV_7164&SUBSYS_89010070 %Wiltshire.DeviceDesc8980%=Wiltshire,PCI\VEN_1131&DEV_7164&SUBSYS_89800070 %Wiltshire.DeviceDesc89A0%=Wiltshire,PCI\VEN_1131&DEV_7164&SUBSYS_89A00070 %Wiltshire.DeviceDesc89A1%=WiltshireOctopus,PCI\VEN_1131&DEV_7164&SUBSYS_89A10070 ;; Halesite %Halesite.DeviceDesc8800%=Wiltshire,PCI\VEN_1131&DEV_7164&SUBSYS_88000070 %Halesite.DeviceDesc8880%=Wiltshire,PCI\VEN_1131&DEV_7164&SUBSYS_88800070 %Halesite.DeviceDesc88A0%=Wiltshire,PCI\VEN_1131&DEV_7164&SUBSYS_88A00070 %Halesite.DeviceDesc88A1%=WiltshireOctopus,PCI\VEN_1131&DEV_7164&SUBSYS_88A10070
Hmm. How does this compare to the Linux driver? Let’s check.
The linux tree has support for two variations of the HVR-2200 and three variations of the HVR-2250….
struct saa7164_subid saa7164_subids[] = {
{
.subvendor = 0x0070,
.subdevice = 0x8900,
.card = SAA7164_BOARD_HAUPPAUGE_HVR2200,
},{
.subvendor = 0x0070,
.subdevice = 0x8901,
.card = SAA7164_BOARD_HAUPPAUGE_HVR2200,
},{
.subvendor = 0x0070,
.subdevice = 0x8810,
.card = SAA7164_BOARD_HAUPPAUGE_HVR2250,
},{
.subvendor = 0x0070,
.subdevice = 0x8880,
.card = SAA7164_BOARD_HAUPPAUGE_HVR2250,
},{
.subvendor = 0x0070,
.subdevice = 0x88a1,
.card = SAA7164_BOARD_HAUPPAUGE_HVR2250_2,
},
};
Hmm #2. I’m missing support for the HVR-2200 models 8980 and 89a0, also, I’m missing support for HVR-2200′s models 8800 and 88A0.
Why? Probably for at least two reasons:
- It’s pretty common for hardware vendors to have ‘bootstrap development’ boards that are used for debug purposes only. These boards are usually listed in the windows driver and are indistinguishable (as far as windows PNP device detection goes) from full commercial products. Incidentally, I have at least one of those boards in the linux driver, and will be removed before the driver is released.
- Time waits for no man, we obviously have new DVB-T/ATSC boards that I need to work with. I’ll have to check at Hauppauge internally to see which new boards have shipped in the last few months, and get new samples.
Summary: I need to find out which of these devices went commercial and which are development ‘curiosities’. Support for all commercially shipped boards in the first public release of the SAA7164 tree? This may be possible after all.
Apr 9th 2009 8.27am
AC3 is disabled in silicon although everything else remains enabled (apparently).
Apr 8th 2009 8.51am
Trawling the web I found a product brief for NXP’s SAA7164 reference design.
Based on this I think we can definitively say that the SAA7164 silicon supports the following video codecs H.263, MPEG-1/2/4, DIVX and WMV, as well as the following audio codecs MP3, MPEG-1Layer2, AAC-LC and AC3 Dolby Digital 2.0.
I’ll have to double check whether Hauppauge have licensed AC3 and/or whether we have AC3 enabled in our silicon.
The interesting thing I wanted to mention is that the NXP SAA7164 product brief also claims support for RDS. In FM radio environments RDS can be used to carry meta-data related to the current playing song, artists and other channel information. Neat!
I plan to investigate this at some point.
With a cleverly written app and some driver support I’d be able to tune to my local ClearChannel owned radio station and scrape all of the 1,000′s 25 songs that they inundate us with day after day, month after month, ad nauseam. 
Apr 7th 2009 8.35am
Three massively important things happened for me last night.
- I finally got around to finishing the family’s annual US Tax return, which has been haunting me for weeks. Seriously, I’ve just been busy with too many other things. End result, a Win! We owe the Fed a little but the State owe us a decent chunk – after my wife got laid off from Starbucks last year.
- My wife made a phenomenal meatloaf for dinner, which I’m particulary partial to. In a rapid manor, like any hacker running against the clock or in the style of a starving man, I wolfed down while watching The Big bang Thoery. A double win!
Still reading? I did say massively important things for me….
Oh and…
- I started adding HVR-2200 DVB-T support to the driver, which no-doubt will put a smile on a few peoples faces.
Happy Tuesday!
Apr 6th 2009 8.30am
I sent a slice of the saa7164 tree to NXP for review last week, no response yet.
Apr 3rd 2009 10.45am
Time for some rambling.
- From here on when I refer to the HVR-22xx hardware I mean the HVR-2250 and the HVR-2200. If I mention the 2250 or the 2200 specifically then I’ll be talking specifically about that hardware.
- The driver is generic and will be known by the linux development community as the SAA7164 driver. (linux/drivers/media/video/saa7164)
- Enabling the second digital tuner is fairly trivial, this opens the door for my next statement.
- The first public release will support both the HVR-2250 (US) and the HVR-2200 (Europe / Australia). Yes, I wanted to mention both of these models specifically.
- The SAA7164 driver use standard v4l-dvb interfaces, so the digital tuners will be supported by MythTV in the first public release. The same should also be true for Kaffeine and others.
- The point of these messages is to give you status updates. So here’s a big one…. I don’t have a release date for the first build, so – be patient, wait until it’s ready.
Other than large amounts of polish / whitespace clean up / minor restructuring, one of the remaining issues will be that the command / response mechanism that’s used to communicate with the firmware has a race condition. I’ll need to fix this before any release.
What does this impact? Well, messages from multiple apps to different firmware endpoints can get lost, the driver structures can get out of sequence, this ripples badly down into the hardware. The only fix for this is a PCI reset, in other words a reboot. See, I thought you’d see it was an important fix.
Huh? In english please. Running azap on adapter0/fe0 and adapter1/fe0 occasionally borks.
As I get closer to something approaching a public release no doubt more goo will eek out of the seams and edges, but so far I think we’re in good shape.
You probably aren’t aware but Hauppauge have already released various HVR-22xx hardware SKUs – containing different hardware revisions, for different geographic regions, each with different internal firmwares, sigh. I’ll need to test each and every one of these revs, as well as providing downloads for firmwares etc.
This testing won’t hold up the first release because the first release will only support the current shipping HVR-22xx models. Within 2-3 days after release I’ll be making patches available to add new boards – just like we do for all new bridges being added to v4l-dvb.
Exciting times!
Mar 30th 2009 9.34am
My wife finally found Jaws 2 on the network, I’m calling the day a success even before it’s started.
It’s a 12 mile drive to work, time to go.
Mar 30th 2009 10.37pm
Oops, 34Mbps wasn’t right. It turns out I was dropping a buffer. Fixed. Now the digital cable bitrate is running correctly at 38Mbps. Yeah!
I took a 30 second snapshot and analyzed the stream in some tools that we use in the QA lab. It’s completely clean. Sweet. No corruption, better than I’d expected.
-PID--FREQ-----BANDWIDTH-BANDWIDTH- 0000 3 p/s 0 kb/s 5 kbit 04f0 3 p/s 0 kb/s 5 kbit 0520 4928 p/s 904 kb/s 7411 kbit 0521 130 p/s 23 kb/s 196 kbit 0529 3 p/s 0 kb/s 5 kbit 052f 14 p/s 2 kb/s 22 kbit 0590 2 p/s 0 kb/s 4 kbit 0620 7915 p/s 1453 kb/s 11904 kbit 0621 264 p/s 48 kb/s 397 kbit 0629 3 p/s 0 kb/s 5 kbit 062f 14 p/s 2 kb/s 22 kbit 0660 3 p/s 0 kb/s 5 kbit 0720 5951 p/s 1092 kb/s 8950 kbit 0721 130 p/s 23 kb/s 196 kbit 0729 3 p/s 0 kb/s 5 kbit 072f 14 p/s 2 kb/s 22 kbit 0820 3321 p/s 609 kb/s 4995 kbit 0821 264 p/s 48 kb/s 397 kbit 0829 3 p/s 0 kb/s 5 kbit 082f 14 p/s 2 kb/s 22 kbit 1fff 2807 p/s 515 kb/s 4222 kbit 2000 25804 p/s 4737 kb/s 38809 kbit
Mar 30th 2009 10pm
Digital cable is working. Hmm, I should say — limping along very nicely!
The driver’s now streaming transport packets reliably into the kernel demux. Here’s a quick dump from dvbtraffic showing the DTV packet stats PID by PID. I need to take some transport recordings for analysis.
-PID--FREQ-----BANDWIDTH-BANDWIDTH- 0000 2 p/s 0 kb/s 4 kbit 04f0 2 p/s 0 kb/s 4 kbit 0520 3312 p/s 608 kb/s 4981 kbit 0521 124 p/s 22 kb/s 186 kbit 0529 2 p/s 0 kb/s 4 kbit 052f 12 p/s 2 kb/s 19 kbit 0590 3 p/s 0 kb/s 5 kbit 0620 4617 p/s 847 kb/s 6944 kbit 0621 202 p/s 37 kb/s 304 kbit 0629 2 p/s 0 kb/s 4 kbit 062f 12 p/s 2 kb/s 19 kbit 0660 1 p/s 0 kb/s 2 kbit 0720 9172 p/s 1683 kb/s 13794 kbit 0721 231 p/s 42 kb/s 347 kbit 0729 3 p/s 0 kb/s 5 kbit 072f 12 p/s 2 kb/s 19 kbit 0820 3176 p/s 583 kb/s 4776 kbit 0821 252 p/s 46 kb/s 380 kbit 0829 2 p/s 0 kb/s 4 kbit 082f 12 p/s 2 kb/s 19 kbit 1fff 1260 p/s 231 kb/s 1896 kbit 2000 22425 p/s 4117 kb/s 33727 kbit
Mar 30th 2009 8.51am
Saturday was a fruitful day, a 10 hour stint on the HVR-2250 driver. The DMA port is mostly working and largely understood. What exactly does this mean? Well, the PCI buffers and associated lists have been correctly configured and placed into the DMA’s configuration registers. When I press the ‘big green button’ and start streaming the driver is stable. I see transport packets arriving during the interrupt handler. Soooo, it’s alive.
…. but not quite. Isn’t their always a catch?
I’m not seeing consistently full buffers. For sure over the next couple of days the solution will probably eek from my brain, out of my ear and into my coffee, then sit their, bobbing up and down looking at me. Probably.
I can say probably because that’s how driver development goes, at least for me. Han’s Verkuil (of cx18 and v4l2 fame – another linux dev) said exactly the same thing to me to the other day. “Mad bouts of driver progress followed by hours of debugging small items”. Amen.
Sunday was a massive context switch back into a reality. In other words a write-off in terms of the HVR-2250. As my wife likes to reminds me, we have 8 full-time computers running around the house and yet she still can’t find Sleepless in Seattle or Jaws 2. (She sighed at this point – it’s worth mentioning). So, I trashed my Linux file server and installed Windows Home Server, I need to get all of my movies, music in a single place.
I tried to clean my office a little and largely spent the day doing odd-jobs around the house.
I did manage to go outside…. once.
More work on the HVR-2250 project during the evenings this week.
Mar 28th 2009 6.12pm
It’s alive! More news to follow…
Mar 26th 2009 – During Lunch
I posted a series of questions to the linux-media@vger.kernel.org mailing list, related to advanced codec types and some odd-ball issues we’re likely to have with V4L2 and the HVR-22xx driver.
Why not jump in and give us your feedback!
Mar 25th 2009 8.37pm
Left brain: “Remember last year how you said that switching the args around in your saa7164_writel() macros was a great idea?”
Homer brain: “Yes”
Left brain: “Remember how you’ve been trying to debug weird DMA hangs?”
Homer brain: “Yes”
Left brain: “You’ve been writing the wrong values to the wrong locations! You IDIOT!”
(brief pause)
Homer brain: “Touche!”
Mar 24th 2009 8pm
Amazing factoid: If I had $1 for every time someone downloaded this file from my site: http://steventoth.net/linux/xc5000/HVR-12×0-14×0-17x0_1_25_25271_WHQL.zip I’d have $20k and be able to support and/or sponsor a large number of other LinuxTV.org developer projects.
I’m actually pretty shocked by the numbers, aren’t you?
Mar 24th 2009 9.16am
A few words for everyone interested in the HVR-2250 project, before I head out to work. I spent the evening triple checking that I was programming both encoders correctly, but I’m still experiencing a full system hang on 64 (and now 32bit) systems…. Which probably means my triple check is flawed, doh! I need to go back to a windows debugger and compare values. I’ve been here before during the cx23885 driver project. I spent a week, maybe more, chasing down a less than obvious bug. I know this feeling, it just takes patience and perseverance. More updates for you in a day or two.
Mar 22nd 2009 3.20pm
So the driver’s at the point where you can issue azap -r and the tuner and demod locks, you get the correct status. The DMA engine is primed and set to run, then the hardware locks up. I’m starting to thing the DMA issue is related to fact I’m running 64 bit O/S. Time to install 32bit on a spare disk.
Mar 22nd 2009 11.48am
The hardware now moves from stop, to acquire then into pause (and back to stop without and issue). WHEY! Taking the next step and putting the hardware into RUN causes a full system lockup. Boo! It’s progress, the DMA buffers are probably miss-configured and I’m writing buffers all over the kernel. I guess the hardware wants to speak to me, which is good news.
Mar 22nd 2009 10.15am
I spent yesterday simplifying the DMA buffering and finished most of the work on a generic IRQ handler. The transport hardware is configured, I pulled the trigger (started the DMA engine), it told me it had acquired hardware (YEAH!) but then failed to transition into Run mode. Boo! I’m working on this today. Spring today, WHEY!
Mar 16th 2009
A busy weekend on various projects, mostly HVR-2250. This weekend I worked on two pieces of the HVR2250 driver. Here’s an update on where I am:
- Looking at my stats I can see that over the last 3 weeks the HVR-2250 project page has had 1896 total views (1417 unique) and 27 people (and companies) have donated a total of $955. I’ve thanked each of these contributors individually, and again generally here.
- The descriptor parsing routines. Each device has a ‘blob’ of configuration data that describes (amongst other things) media ‘endpoints’ that describe various attributes related to video and DMA. Each board revision can have completely different configurations so this has to be understood to build a generic vendor driver. More importantly, base addresses and register offsets for certain video features are held here so the key to implementing DMA buffering is born from this. I started to write these functions and define the structures to track / decode these.
- More work on the DMA buffering scheme, and it still needs more work – especially for videobuf_dvb. Right now the device flags an interrupt (for activity) and a deferred worker thread is triggered for later execution.
Mar 7th 2009 – 9.30am
A couple of things to say:
- Looking at my stats I can see that over the last 2 weeks this page has had 837 total views (614 unique) and 18 people have donated a total of $600. I’ve thanked each of these contributors individually, and again generally here.
- Work resumes on the SAA7164 project today. This primary goal is to get the digital demodulators streaming digital TV then run this driver past the NXP guys for official public release. How long before I can release something? I’d estimate 3-4 weeks.
- All status notifications or announcements will be made here.
It feels good to be back!
Feb 27th 2009 – Mid Day
It’s been a week, where am I? Looking at my stats I can see that over the last week this page has had 416 total views (317 unique) and 4 people have donated a total of $80. I’ve thanked each of these contributors individually.
Feb 19th 2009 – 11pm
Here’s the project summary so far… Background: It’s a long (ish) story that began during the early part of 2008. I started work on the Linux driver for the Hauppauge HVR-2250 Dual ATSC/QAM/Analog Encoder board (IIRC) March 2008. Works went well up until July / August 2008 when I put the project on ice and decided to take a stand against the whole Multiproto farce. It’s best not to dwell on that sorry episode of v4l-dvb history. That being said, I started to focus my attention on developing the S2API project, going head to head with a few people and trying to get DVB-S2 into DVB-CORE. Didn’t we all want a flexible API able to deal with S2, ISDB-T and other modulation types? For the main part, Yes. We bickered over lot of the implementation details (Multiproto vs S2API) but importantly – things were moving forward. (Side note: for a group of developers who enjoy spending their spare time writing TV kernel drivers, it’s odd that we fight so much). The S2API work swiftly led on to the Linux Plumbers Conf 2008 where I presented the S2API proposal and met with these excellent fellows! (I’m top left, white shirt, Yep – the odd bod.). What happened after Plumbers? We’ll more S2API and then the code merge. Thanks to the work of many developers worldwide we finally merged support into the master repository for S2. Kudos to everyone who helped. I’ve already thanked you publicly, you know who you are. Then things got crazy, personal and out of hand on the mailing lists so as usual (as I often do) I took some time away from Linux to recharge the batteries. After all, isn’t this supposed to be fun? We’d broken the back of the S2API and the rest was trivial to resolve. To be honest I just needed a break. Something weird happened during October 2008, the average person didn’t expect the economy to tank, but it did. Companies started laying off employees. Big names like Sun, HP, Microsoft, Google. Even companies like Hauppauge. People were losing their jobs, their homes, 401k’s in the tank, stock prices falling to the floor and everything got ugly. It’s still ugly today. I have friends in the Investment Banking industry. What’s their outlook?
“It’s not going to get back to pre-october levels for 5 years.” Doh!
So, since October / November, other than keeping myself busy in the New York Hauppauge offices, I spend my evenings and weekends working on projects that help bring a few extra dollars into the Toth household.
As Jason Calacanis says “In times this that you need to be investing in yourself”
Hey, it’s good to take a break. I’ve been learning all sorts of interesting things about the Mac OSX developer tools and frameworks. This work turned into a couple of Mac projects (HDPVRCapture and AVCNoodle) which I occasionally make a few dollars from. If you interested or curious you should checkout the AVSForum where these are discussed here and here. Anyway, back to the point. A number of individuals have written to me in public and in private (as have a number of companies). They’ve suggesting that I should start accepting donations… really? … to help fund the HVR-2250 and HVR-2200 driver project. Why? HVR-2250 users are frustrated. They want to use their TV tuners under Linux and the only way we can legally make this happen is if I start working on the driver again. This isn’t a project I can outsource to another developer. If you know me and my work then you’ll know that I’ve done a large amount of Linux work in the past, you’ll find my email address stoth at linuxtv [dot] org all over the v4l-dvb tree. Look, I do this for fun, not for profit, so it’s uncomfortable feeling for me to add a donation button to my blog. Still, I do need to earn a crust. So, to all the people who have asked, “Put a donation button on your blog and maybe we can convince you to start working on the HVR2250 driver again”. Your wish is my command.
[...] drivers are still in development for the HVR-2250, however it sounds like we’re approaching a release date sooner rather than later. [...]
[...] Posted by EvilGenius007 Linux drivers are still in development for the HVR-2250, however it sounds like we’re approaching a release date sooner rather than later. [...]