[PULL] http://linuxtv.org/hg/~hverkuil/v4l-dvb

[mrechberger at gmail.com (Markus Rechberger)]

On 8/6/07, Hans Verkuil <hverkuil at xs4all.nl> wrote:
> On Monday 06 August 2007 20:50:06 Mauro Carvalho Chehab wrote:
> > Hans,
> >
> > > It's *not* on by default, you have to set a define in ivtv-driver.h
> > > to enable it. Furthermore, *all* code relating to the xceive
> > > userspace tuner is stripped from ivtv by gentree.pl (something that
> > > didn't happen with the current ivtv code).
> > >
> > > If you look at the current code you'll see that there is also some
> > > code relating to an older xceive driver that is no longer available
> > > without heavy kernel patching. So it just replaces hard-to-use code
> > > with code that is much easier to use by the end-user.
> > >
> > > In other words: this patch makes it fairly easy for people with an
> > > xceive-based tuner to use v4l-dvb and ivtv. It's better than
> > > nothing.
> > >
> > > The impact on ivtv is minimal, should a kernel xc2028 driver appear
> > > in the future, then it is very easy to change ivtv to use that one.
> >
> > The gentree.pl script is meant to handle with compat code only. What
> > it does is just removing all compat code from the patches. It can be
> > used with some care to avoid incomplete patches from just *one*
> > author to arrive kernel. However, handling changes with different
> > authors would be a real mess, since later, there's no easy way to
> > split the changes.
> >
> > The usage for xc3028 code happened only as a way to solve a big
> > conflict that arrived when the code were committed on an HG tree. Due
> > to a lack of proper branch implementation on HG (not documented on
> > that time), an experimental patch arrived the mainstream. This caused
> > a large noise between all developers.
> >
> > On that time, we've expected that xc3028 fixes would be happen soon,
> > and that we should have a proper fix. Unfortunately, this doesn't
> > happen.
> >
> > Maybe the better would be just to undo xc3028 changes from v4l-dvb,
> > while the other solutions are being maturated.
> >
> > For now, please keep the xc3028 patches you have on a separate
> > development tree.
>
> I will if I really have to, but I feel highly uncomfortable doing this:
> first of all 90% of the changes are not specific to the userspace tuner
> stuff (e.g. the structs in ivtv-cards.c or the tuner reset code in
> ivtv-gpio.c). No matter what code will eventually implement the xceive
> tuner, these changes are needed. That leaves only a small portion that
> is specific to the userspace tuner.
>
> It looks like the userspace tuner will be in kernel 2.6.24 at the latest
> (probably too late for 2.6.23), and these changes are for that kernel
> as well. If you prefer that I use another #define for this, then that's
> no problem. If you really don't want to have this code in, then I would
> still prefer to keep the ivtv-cards.c and ivtv-gpio.c changes
> under '#if 0' or '#if NOTYET' as they'll be needed regardless. I can
> make a separate tree for the remaining changes.
>
> Markus, what's your current schedule for kernel inclusion? If you are
> certain that it's in 2.6.24 (pending disasters of course), then I see
> no reason to keep my changes out.

the merge window for 2.6.23 is already closed; so 2.6.24 is the only
release where it can go into. I'm also testing cx88/xc2028 radio
functionality now.

Markus