Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: [linux-dvb] Re: Problems switching to dvb-kernel under 2.6
Kenneth Aafl°y wrote:
> On Sunday 22 August 2004 18:13, Klaus Schmidinger wrote:
> > Klaus Schmidinger wrote:
> > > ...
> > > Well, since the DVB driver is only one thing I need to have running,
> > > and the 'kfir' driver apparently isn't working under kernel 2.6 yet
> > > (no idea if it ever will be), I've decided to waste no more time trying
> > > to switch to kernel 2.6. For now official VDR development will therefore
> > > be done under SuSE 8.2 with kernel 2.4.20 and the 'linux_2_4' branch of
> > > the dvb-kernel driver.
> > I guess I was a little premature with this statement.
> > Actually I'm back to the "old" DVB driver (as of CVS dated 2004-08-08),
> > because the 'linux_2_4' branch of the dvb-kernel driver still has the
> > problem that audio and video drops out every now and then here on my
> > system - that's why I was trying to go to the kernel 2.6 version of the
> > driver in the first place...
> Klaus, I would like to see you, or someone else actually following through
> with the problems that exists with compiling the current CVS dvb-kernel
> against a suse kernel, but as you know you cut off your attempt way to
> prematurly. Please, could you setup a secondary testing partiotiong alongside
> your primary setup, and whenever You and I have time, We could work through
> this, instead of just dropping everything on the floor?
I do have a separate partition for this, and I will try again.
However, unfortunately my home PC (a silent and fast machine ;-)
was broken a while ago and I'll only get it back tomorrow.
So chances are I'll be able to try again next weekend.
However, since the 'kfir' driver doesn't compile under kernel 2.6,
yet, I won'r be able to actually use linux-dvb under kernel 2.6
in every day use, because that driver is an absolute _must_ for
And: I find it rather annoying that the driver developers use functions
that are only available in "bleeding edge" kernels, without providing
backwards compatibility to the kernels currently used in production
dirtributions. IMHO that 'msleep' thing could have been avoided easily.
There was no need to totally drop the old solution, was there?
It's things like this that keep people from using the latest driver.
Main Index |