[MythDora] Trouble-video4linux-kmdl-2.6.19-1.2895.fc6-20061107-77.fc6.at.i386.rpm

[Dennis Hand]

Ouch, this hurts. As Chris has now informed me, after a few stubborn
emails later, he is in fact using the lastest video4linux kmdls and
ivtv in MythDora-4.0 beta and seems to be having issues with this.
What I don't understand is why would V4L be messing with ivtv? If this
is in fact the problem that Chris has been experiencing, which it does
look like,  then it looks like I won't be able to use video4linux in
the newest MythDora version.

Dennis

On 3/15/07, Axel Thimm <Axel.Thimm at atrpms.net> wrote:
> On Thu, Mar 15, 2007 at 08:14:44AM -0400, gchris wrote:
> > Axel Thimm wrote:
> > >On Thu, Mar 15, 2007 at 03:38:38AM -0400, gchris wrote:
> > >>Alex, I'm in the process of debugging MythDora 4.0 for Dennis and I've
> > >>run into a problem with the Fedora kernel not configuring pcHDTV HD3000
> > >>cards properly.  I traced the problem back to three specific modules in
> > >> video4linux-kmdl-2.6.19-1.2895.fc6-20061107-77.fc6.at.i386.rpm whose
> > >>aliases look decidedly different than stock Fedora modules which are
> > >>known to work. The three modules are cx8802.ko, c88-dvb.ko and
> > >>cx88-blackbird.ko.  There could be others as well, but these three are
> > >>the focus of my attention right now.
> > >>
> > >>I'm attaching modinfo dumps of the MythDora modules along with stock
> > >>Fedora modules so you can see the differences and would appreciate a
> > >>note back confirming that the RPM is (or is not) in error.
> > >
> > >Thanks for the report.
> > >
> > >For one I see that you compare 2.6.19-1.2911.6.5.fc6 vs
> > >2.6.19-1.2895.fc6 which contain already a lot of differences. You
> > >would have to pick the same kernel for both.
> > >
> > I realize that there are level differences, but the nature of the
> > problem is functional at the level of basic card initialization, and I'm
> > simply comparing a current Fedora kernel that works with one modified by
> > this RPM, which doesn't work.  The key element is the alias field as
> > described below.
> >
> > >Furthermore, what is the real error you see? A difference in
> > >srcversion does not hint to an error. Check out the logs/dmesgs for
> > >differences during initialization of these kernel modules.
> > >
> > I have seen no error messages in logs/dmesg but there are functional
> > difference which I'll explain.
> >
> > The stock 2.6.19 kernel initializes the ATSC side of the HD3000 at boot
> > by loading cx88-dvb.  cx88-dvb is loaded because its alias matches the
> > digital signature of the HD3000, is assigned as its driver, and it in
> > turn, loads cx8802 and some other modules.  The result of this is that
> > the HD3000 gets a /dev/dvb/adapter port assigned to it at boot.
> >
> > The RPM module's cx88-dvb contains no alias, but the cx8802 does contain
> > an alias matching the HD3000 so it loads at boot and is assigned as the
> > HD3000s driver.  The cx8802 is not capable of opening a /dev/dvb/adapter
> > port when loaded by itself so the HD3000 ATSC section has no port and is
> > basically deaf and mute to the outside world.
> >
> > After I wrote to you I checked further and found an ominous note at
> > http://linuxtv.org/v4lwiki/index.php/Cx88_devices_%28cx2388x%29#Supported_cards
> > which reads:
> > >Note: The current kernel, 2.6.20, does not automatically load the cx88-dvb
> > >driver when a program like mplayer requests to use it. This problem will
> > >most likely be fixed in kernel 2.6.21, but in the mean time, you will
> > >either need to load it using:
> > >
> > >modprobe cx88-dvb
> > >
> > >or you can specify it in your modprobe.conf file which in gentoo would be
> > >/etc/modules.autoload.d/kernel-2.6 so that it will load when the computer
> > >boots:
> > >
> > >cx88-dvb
> > This implies to me that the functional change that I am seeing may have
> > been intentional, but the solution offered does not work with the HD3000
> > card.  Forcing cx88-dvb to load after the cx8802 has been assigned as
> > the card's driver does cause the card's /etc/dvb/adapter port to open,
> > but it also causes the card's analog port /dev/video0 to close,
> > rendering the NTSC side of the card useless.
> >
> > This problem could be kernel specific because I have now confirmed that
> > the alias anamoly also existed in the 2.6.18 version of this RPM used in
> > MythDora 3.2 but I have not experienced the problem with the /dev/video
> > ports disappearing using that kernel.  The ports problems are 100%
> > reproducible with the 2.6.19-1.2895 kernel.
> >
> > I'm beginning to suspect that the developers of this code have placed
> > themselves in conflict with kernel architecture and to my mind, that is
> > comparable to fooling with mother nature.
>
> :)
>
> Do you need ivtv support? If not, then try the latest video4linux
> kmdls, if there was works in progress it should be in there.
>
> But if you are using ivtv, then be careful as the latest video4linux
> kmdls contain ivtv as submitted for kernel inclusion and that is not
> compatible to the usual ivtv, e.g. it requires changes to mplayer,
> mythtv etc., which haven't been submitted yet.
>
> Even if you do have a secondary card with ivtv it would be interesting
> to know whether the new video4linux kmdls fix your issue. If so, then
> it will be easier to do something with the new ivtv subpart of it then
> fix the old viedo4linux kmdls.
>
> P.S. I think this discussion is generic and interesting enough to
> continue on either the mythdora list or atrpms-devel.
> --
> Axel.Thimm at ATrpms.net
>
>