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

[Roger J. Allen]

On Thu, 10 Nov 2005, Mike Isely wrote:

> On Thu, 10 Nov 2005, Roger J. Allen wrote:
>
>> 
>> I was getting errors about "tveeprom_hauppauge_analog" with some
>> combinations of Fedora Core 4 2.6.13 kernels and recent pvrusb2
>> snapshots.  It had been working well upto kernel-2.6.12-1.1447_FC4 and
>> pvrusb2-mci-20050804.tar.bz2.  I guessed it was the v4l changes filtering
>> thru the different developers.
>
> Hmm, I had no idea this was happening.  FYI, I always work with vanilla 
> kernel source trees from www.kernel.org - I never use patched kernels from 
> any distribution (not even from Debian).  That may be a source of trouble 
> here, but frankly it would be an unending nightmare if I tried to account for 
> every different distribution's idea of patched kernels.  The V4L folks are 
> dealing with a variation of this same problem.
>

That's why I didn't bring it up before.  This was a Fedora kernel package
problem.

>
>> 
>> Now, with pvrusb2-mci-20051109.tar.bz2, everything is working great with
>> the latest FC4 kernel (kernel-2.6.13-1.1532_FC4).  I did have to add
>> a link to msp3400.h for it to compile.  Something like this:
>> 
>> make --directory ivtv
>> ln -s ../ivtv/msp3400.h driver/msp3400.h
>> make --directory driver
>
> You should not have to do that.  The msp3400.h that the build will grab is 
> hiding in the kernel source tree under drivers/media/video.  Do you see an 
> msp3400.h there in your sources?  There is a directive in the driver

I did a "find / -name msp3400.h", and nothing was found besides
the copies in the pvrusb2 sources.

> directory's Kbuild file that is supposed to ensure that area is searched:
>
>  EXTRA_CFLAGS += -I$(srctree)/drivers/media/video
>
> I'm curious to understand why that isn't apparently working in this case. I 
> wonder if the kernel tree you are using is incomplete; I wonder if that is 
> going to be a common problem...
>
> Previous snapshots used the msp3400.h from ivtv, a header which used to be 
> right there in the pvrusb2 driver source.  But as you figured out, I moved 
> that header over to the ivtv partition of the snapshot and arranged for the 
> build to instead point at what is in the kernel tree.  Your experience here 
> suggests that might be causing trouble for some people.  I did this change 
> because in the end, that's the header that the driver is going to be using 
> once it's in V4L officially.  Also, I understand that all those support 
> modules (tuner.ko, msp3400.ko, tveeprom.ko, saa7115.ko) are now finally 
> merged into V4L and that the next ivtv release 0.5.0 (to be released this 
> weekend) won't have them anymore.  So I need to stop relying on it all. 
> Switching headers for msp3400 is part of that.
>

That msp3400.h file doesn't seem to be part of the kernel-devel rpm package
for Fedora Core 4.  I currently have these installed:

kernel-2.6.13-1.1532_FC4
kernel-devel-2.6.13-1.1532_FC4

There are some headers like:

/usr/src/kernels/2.6.13-1.1532_FC4-i686/include/media/audiochip.h
/usr/src/kernels/2.6.13-1.1532_FC4-i686/include/media/tuner.h
/usr/src/kernels/2.6.13-1.1532_FC4-i686/include/media/tveeprom.h

but no msp3400.h.

It was kind of surprising because there is a:

/lib/modules/2.6.13-1.1532_FC4/kernel/drivers/media/video/msp3400.ko

I don't know if I have something misconfigured, or if this is
something specific to Fedora.

>
>> 
>> The FC4 kernel has tveeprom.ko, tuner.ko, and msp3400.ko, so I only
>> installed saa7115.ko and pvrusb2.ko before running "depmod -a".
>> 
>> My setup uses the composite video source, so I havn't tested the tuner.
>> 
>> The remote control works with the atrpms lirc packages.
>
> That all sounds great.
>
>  -Mike

Mythtv just recorded a half an hour of news thru the pvrusb2, so it's
getting the job done.

Thanks for your hard work.

-- 
Roger J. Allen