[pvrusb2] Thanks for the driver :)

[Mike Isely]

On Mon, 31 Aug 2009, Chris Cox wrote:

> On Mon, 2009-08-31 at 23:08 +0200, Xavier Gnata wrote:
> > Hi Mike,
> > 
> > Well I was here since the beginning of the project and I want to thank 
> > you for the excellent support you provide me with.
> > I'm living in Germany and I have switched to dvb-t. I'm not using the 
> > pvrusb2 device anymore.
> > 
> > The driver for my new device is not fully buggy free yet 
> > (http://bugs.launchpad.net/ubuntu/+source/linux/+bug/403156 for 
> > instance) but it does work.
> > Mike, I wish you all the best for your current and next projects and do 
> > thank you for all these hours I spend doing nothing watching TV :)
> 
> I want to say thanks as well.  I've used this driver on the PVR USB2
> as well as the newer smaller combo ATSC devices.  Very nicely done.  Is
> there a mechanism to reward you?
> 

All:

Sorry if it seemed like I was ignoring this.  It's just taken me a while 
to think of what to say.  The appreciation is heard, and, well, 
appreciated of course!

I just don't know how to best respond to compliments.  I've been lousy 
at it in the past.  Plus I don't feel like it's really that much 
deserved anyway - because there's still so much more I can do here and I 
just haven't had the time to get it done.  I've been under a lot of 
pressure between my day job ("work overtime or else...") and my bank 
account, and that's been a source of distraction.  But with that said, I 
_really_ don't want any sort of "reward".  What I've said in the past is 
that like everyone here I've been a beneficiary of the free Linux 
community for over 15 years now and as far as I consider it, this effort 
is just my very tiny little attempt to give something back.  So please 
gladly take advantage of this and I will continue to do what I can do 
support the driver going forward.

As for going forward, some thoughts I'd like to share:

1. My ability to debug analog RF reception now has been limited by the 
fact that the digital TV transition has taken place in the USA.  
Suddenly I don't have any more over-the-air analog signals I can test 
with.  In addition, I don't subscribe to cable (and I despise the local 
cable provider) so that potential signal source is out.  However a while 
back I purchased a channel 3/4 RF modulator and I've been using that as 
an RF signal generator - that's the extent of my "specialized test 
equipment" :-)  So I still have some limited ability to ensure that RF 
analog tuning still works ok.  However I also have to wonder as people 
transition to digital TV just how important the older 29xxx and 24xxx 
devices will continue to be.  But rest assured that so long as I have 
working hardware, the ability to debug problems, and as long as I 
perceive the need, I will continue to support it all as best I can.

2. I know people would like to see VBI support in the pvrusb2 driver, 
but I seriously doubt it will ever happen.  First, let's consider the 
sobering thought that Hauppauge's own Windows driver never supported VBI 
for this device.  There's probably a good reason for that.  Second, I 
don't at the moment see a way to get that data out in a form that is 
still possible while concurrently streaming video.  And (most important) 
third, with the transition to digital TV here I simply do NOT have any 
means to test such an implementation.  Unfortunately, without VBI we 
also don't have access to the WSS flag (a piece of VBI data) else that 
could have been a source to help detect the actual aspect ratio of the 
incoming signal (see recent thread).

3. I haven't forgotten about uncompressed (raw frame) video capture.  
The solution to that puzzle came to light last winter and it's still on 
my list.  Sorry that nothing has come of it yet.  To do this one right 
will require a number of pieces of new development - it will probably be 
the largest set of changes to the driver in several years.

4. I think I finally understand how to get proper device attributes made 
visible to udev.  This issue was raised a few months ago, and last week 
(as part of my day job, curiously enough) I did some more reading on how 
udev does its magic.  This evening it finally hit me, and of course now 
it's blindingly obvious.  I still need to try some experiments in order 
to work out the finer points, but I hope to see all the appropriate 
device attributes become available to udev by the next snapshot.  And 
with that, the door becomes open to nailing down specific tuner 
instances to specific /dev names, e.g. ensure that your HVR-1950 gets 
one specified name while your older nearby 24xxx device gets another 
specified name.  I am right now building a factory-fresh 2.6.31 kernel 
with which I intend on finally nailing down this very issue.

5. The driver in its current form AFAIK still does not support the FM 
radio on the HVR-1950.  This is a bit of a glaring hole.  But the reason 
why I qualified that with "AFAIK" is because the problem with this 
ability is not strictly due to the pvrusb2 driver.  There are hardware 
differences with the tuner in this device that require proper support in 
the V4L/DVB tuner module.  Plus I have been told that there is a 
firmware change needed as well (the cx25840 firmware IIRC).  Those are 
both out of my hands.  Actually it's been a while - I last tried to test 
for this last May.

6. Some day I'd like to see the ability to FULLY operate a hybrid device 
like the HVR-1950 from EITHER the V4L or DVB APIs.  Said another way, 
gee it'd be nice to run DVB-only app and have it operate the analog side 
of the device.  Or similarly, it would be really cool to run an 
mpeg-aware V4L application in such a way that it can stream from the 
digital side of the hybrid device.  And selecting "digital" or "analog" 
would just be another input choice, nothing any more complex from the 
app point of view.  (Right now you can only stream digital via DVB and 
all else must use V4L.)  To me, there is a certain "order in the 
universe" if both APIs became equally capable.  For one thing it'd be 
great if I could tell everyone, "sure use any DVB or V4L app and you 
have full run of the hardware" - as opposed to right now where there's a 
bunch of asterisks and caveats that depend on the app, the API, and 
whether it's digital or analog.  I'd also like to think that this would 
be a huge step to a final actual for-real integration of the V4L and DVB 
subsystems.  Devices driven by the pvrusb2-driver are candidates for 
this because the analog side is a sort of "hybrid" already - the signal 
might be analog coming in, but the mpeg encoder makes the output look 
like something closer (though not identical) to what DVB natively 
manipulates anyway.  Unfortunately a huge roadblock to this is that the 
DVB side essentially "takes ownership" of the hardware when streaming 
digital, and since the knowledge for how to do that is buried in the DVB 
front end framework then there's no way to make that visible for V4L.  
Similarly, the DVB framework wants to "see" the tuner directly so I 
can't fool it into thinking that the mpeg encoder output is some kind of 
special tuner.  There really needs to be a sort of shim between the DVB 
core and the hardware, where the pvrusb2 driver can insert itself, 
before this goal becomes achievable.  Maybe it's just a pipe dream.  
Some day....

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8