On Sunday 11 June 2006 15:45, Aristedes Maniatis wrote:
> On 11/06/2006, at 6:55 PM, Hans Verkuil wrote:
> > Unrelated to linux. It's just what happens when a driver is
> > developed outside the kernel and then you want to integrate it.
> > Same thing would have happened with BSD or any other OS. I don't
> > like it either but I see no other option. It's a big driver, it
> > required many changes in the
> > kernel, some really low-level, and it requires developing a whole
> > new API for MPEG devices. This is the consequence of that. The end
> > result will be great, but the intermediate steps are no fun.
>
> And I admire the work you've been able to do. This is not intended in
> any way as a jibe or troll, but I don't quite understand the purpose
> of integrating ivtv with the kernel. Does it mean that in the long
> term:
>
> * patches cannot be made to ivtv except as part of the regular kernel
> releases
> * every update of ivtv is tied to a specific version of the kernel,
> so it becomes impossible to upgrade ivtv without upgrading every
> other kernel module and the kernel itself. This is what bit me
> because I updated the kernel for another reason, was then forced to
> upgrade ivtv and things were never the same again.
It means that if you upgrade to a new kernel ivtv is also upgraded as it
is now part of the kernel itself.
Also, any changes in the kernel internals are also automatically done
for ivtv (as it is part of the kernel).
The encoding/decoding API becomes standardized, so it will work with any
application that supports it (now apps must support an ivtv-specific
API).
> This is probably a discussion for another place, so don't answer if
> it is off topic. I just don't quite understand the movable feast that
> is the Linux kernel API. There appears to be little to no effort put
> into backward compatibility. The suggestion given to many problems in
> the Linux world is "are you running the latest kernel?"
In linux drivers are part of the kernel. New features will therefor
appear in the next kernel. That's the way it works. If you are outside
the kernel, then you have to keep track of all the internal changes
yourself and you get no support or help from other kernel developers.
You also will have to provide packages for all the various distros
since they only look at what is in the kernel (for the most part).
> There is an assumption in Linux world that updating the kernel is
> easy to do, and always results in improvements. I maintain a bunch of
> 5 year old FreeBSD 4.x installations in a data centre. Sure I'll
> upgrade them to new versions when I can schedule the appropriate down
> time and testing, but otherwise the OS is still supported and I can
> still keep updating server software running on it without rebuilding
> the kernel except for security patches. Anyhow, this isn't meant to
> be a competition, just a comparison against what I'm more used to.
> And I guess ivtv is a little different to many other hardware drivers
> such as network or disk drivers.
Again, as part of the move to the kernel the driver needs to track the
internal kernel changes I had to make to prepare for kernel inclusion.
I could have kept one driver that is able to detect all the different
kernel versions, but that was more effort than I wanted to spend on it.
>
> > Anyway, I've taken a quick look at your earlier posts and it looks
> > like
> > the cx25840 module is missing. Is it loaded? (check with lsmod)
>
> tv ~ # lsmod | grep cx
> cx25840 21904 0
> firmware_class 7552 2 ivtv,cx25840
> i2c_core 15888 12
> it87,i2c_isa,nvidia,ivtv,wm8775,saa7127,saa7115,msp3400,tveeprom,tune
>r,t da9887,cx25840
>
> It does appear to be loaded, but I can't see how to switch on any
> more debugging for that module. I tried "options cx25840 debug=1" but
> that didn't work. I am pretty sure I am loading the correct version:
>
> tv modules.d # modprobe -v cx25840
> insmod /lib/modules/2.6.16-gentoo-r2/kernel/drivers/media/video/
> cx25840/cx25840.ko
'didn't work' as in: it refused to load, or as in: nothing appeared in
the log? The modprobe.conf options line is correct.
Try two things:
First load ivtv with the newi2c=0 option. If that still gives the same
problems, then use 'i2cdetect -a 0' to see if the cx25840 is even
detected on the i2c bus. If not (you get 'XX' for address 0x44) then it
is likely to be a hardware problem.
Thanks,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
