[pvrusb2] New driver snapshot: pvrusb2-mci-20091011

[Mike Isely]

On Sat, 17 Oct 2009, Martin Dauskardt wrote:

> >   http://linuxtv.org/hg/~mcisely/pvrusb2-20091011/
> Hi Mike,
> 
> I tried it and there are now much more informations available via udev :-)
> 
> But is this right:
> 
>     ATTRS{serial}=="0000:00:10.4".
> 
> Instead of the serial number it seems to include the bus info.
> v4l2-ct --all says
> 
>         Bus info      : usb-0000:00:10.4-2
> 

The change that enabled all of this was simply to generate an 
association between the V4L device entity in the kernel and the 
underlying USB device.  I can't control how udev gets information from 
those devices - all I can do is tell both sides that they are related.  
So I'm not sure why this would be happening.  But remember udev is 
looking at a heirarchy - "serial" at a different level may be what you 
want.  I did see a serial number attribute visible through udev at one 
point that was in fact a hex version of the decimal serial number that 
the pvrusb2 driver already knows about.


> 
> While doing a lot of testing with both boxes (old 29xxx model PVRUSB2 and HVR 
> 1900) I realized two other things (not new, seem to persist in the driver for 
> a long time):
> 
> root at ubuntuvdr:~# v4l2-ctl --all -d 2
> Driver Info:
>         Driver name   : pvrusb2
>         Card type     : WinTV PVR USB2 Model Category 2
> 
> I always wondered what "Category 2" means, so I looked into the driver. 
> The card type should come from struct v4l2_capability.
> 
> First I found this in pvrusb2-v4l2.c:
> 
> static struct v4l2_capability pvr_capability ={
> 	.driver         = "pvrusb2",
> 	.card           = "Hauppauge WinTV pvr-usb2",
> 	.bus_info       = "usb",
> 	.version        = KERNEL_VERSION(0, 9, 0),
> 	.capabilities   = (V4L2_CAP_VIDEO_CAPTURE |
> 			   V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_RADIO |
> 			   V4L2_CAP_READWRITE),
> 	.reserved       = {0,0,0,0}
> };
> 
> but obviously it is not used. Instead the driver returns the descriptions from 
> pvrusb2-devattr.c:
> 
> 		.description = "WinTV PVR USB2 Model Category 29xxx",
> 		.description = "WinTV PVR USB2 Model Category 24xxx", 
> 
> but they seem to be  too long for the card[32] field, so it cuts after 
> the "2".
> 
> I guess this should be easy to fix, just remove the word "Category".

Ouch.  The "category" word was meant to refer to the two major 
categories of that device series.  The 29xxx models were the original 
design, using an msp3400 for audio and an saa7115 for video.  When the 
24xxx series came out, the internals were redone quite a bit (and I 
spent a month figuring it all out again and another month stabilizing 
the driver against the new device).  The string can certainly be 
shortened.


> 
> Another issue is streaming after clossing/opening the device (which I do to 
> clear the encoder).
> It is no problem with the HVR 1900. This box seems to be a bit slower when 
> doing "close- open- tune- read", but is reliable. 
> 
> The 29xxxx frequently hangs when starting the read access. This is basically 
> the code I use:
> 
>     log(pvrDEBUG2, "now start reading");
>     r = read(parent->v4l2_fd, buffer, BUFFSIZE_INPUT);
>     log(pvrDEBUG2, "r=%d", r);
>     if (r < 0) {
>        log(pvrERROR, "error=%d:%s",  errno, strerror(errno));
>       }
>     if (r > 0)  {
>       ParseProgramStream(buffer, r);
>       }
> 
> I made a lot debugging and found out that the read call randomly returns 
> nothing. I see my debug message  "now start reading", but then it hangs. No 
> value for "r" is returned, no error message. The red LED is on.
> 
> When I do a "v4l2-ctl --set-ctrl=video_bitrate_mode=0" in a terminal, the box 
> seems to "awake" and the picture appears.

Hmm, that's new behavior as far as I know.  The streaming code in the 
pvrusb2 driver (i.e. the part that handles read(), select(), etc) has 
been largely unchanged for YEARS.  I will have to investigate this.


> 
> I tried increasing TIME_MSEC_ENCODER_WAIT and using a sleep between 
> pvr2_encoder_adjust and the CX2341X_ENC_INITIALIZE_INPUT call. Both doesn't 
> help. Do you have an idea where else I could look?

We need to figure out what part of the video pipeline is getting stuck.  
It sounds like some kind of race, but at what point...


> 
> Do you think that using select() in my application could help? But I have no 
> idea how to use this. I am only a hobbyist :-)

You should not need to use select().  The purpose of that call is to 
implement concurrent scheduling of I/O in the kernel.  The driver has 
support for this (which works fine) but read() by itself should be 
enough.

Can you send me (off the list) a sample program which demonstrate this 
or can you reproduce the problem just by using cat?

  -Mike