--- On Sat, 9/13/08, Paul Chubb <paulc@xxxxxxxxxxxxxxxxxx> wrote:
> around 2.6.22. At some stage the functionality in videobuf_core.c was
> replaced by video-buf-dvb.c. This meant that when you compile against
> the 2.6.22 headers it works fine but still loads the videobuf_core
> module from the previous module set. Once you get to 2.6.24 it still
> loads videobuf_core, however now you get a lot of symbol issues when it
> loads and ultimately the driver for the card didn't work. This was
Ah, thanks. I've seen this (in the list) often and ignored it
as a newbie error. (I ignore most things anyway)
Now I'm trying to hack* around something comparable in a diff
which has strangely disappeared from my screen, but may be
videodev.c --> v4l2-dev.c which probably will/has cause(d)
issues.
* `hack' should be translated as, looking at the diffs, wishing
I had had more sleep, even if it had meant missing all the doku on
Chairman Humph (for those in the know) that I should have instead
recorded for later viewing, and wondering if a `make-it-compile'
hack is enough... Am I making sense? Should I sleep?
> 2) The v4l-dvb tree has complex firmware loading logic in tuner-xc2028.c
>
> So either could be fixed, and I fixed the first. I could have fixed the
> second by investing more time.
Just to be clear -- did you fix the firmware issue, or the issue
with migration of, and changes to, source files, which in my
hum^Wignorant opinion, would be the more difficult one in general?
> But I don't think that is why people talk
> about incompatibility between the two.
It's helpful to me, nonetheless. I am sympathetic to the fork,
as my `production' (were I to produce anything; in reality, I
mean that it's been several years operating with only power
failures requiring attention, otherwise generally running with
full CPU load) machine is 2.6.14 and has loads of hacks which
I need to apply to a more recent kernel, should I find a stable
one (perhaps the hardware of my development machine is suspect
here, as I now have nearly a week uptime on the same kernel
which would typically freeze/panic within a few hours -- watch
it wedge solid before I can send this, again), and much of the
code which I've hacked (UFS large fragment size filesystem,
ISA ethernet and others) has or may have suffered substantial
rewriting since I got it working... That second sentence was long...
thanks for your feedback!
barry bouwsma
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
