On Sunday 12 March 2006 18:53, Nicolas Mailhot wrote:
> Le vendredi 10 mars 2006 à 10:18 +0100, Hans Verkuil a écrit :
> > So the situation is that 0.6 might work with 2.6.16, but I'm not
> > sure. I'm not going to spend time on it until 2.6.16 is released.
>
> The situation would not even arise if ivtv was available as a kernel
> patch (meaning - building with normal kernel tools on vanilla kernel
> *not* custom tools on v4l cvs). That's the canonical kernel way and
> it is supported by Fedora (just drop the patch in the srpm as for
> example the wireless guys have been doing - the wireless tree didn't
> even exist when ivtv declared merging time!)
>
> If upstream merging continues to stall would it be possible to
> consider releases-as-kernel-patches? I hate to pull it on the table
> again, but I've been waiting for months for it to happen, and all the
> energy seems to be focused on supporting ancient kernel releases via
> all sorts of unholy workarounds. For the record, we're not all
> running a frozen RHL 7.0 kernel which can not be upgraded without
> replacing its whole v4l system.
I'm definitely not working on old kernels. Heck, I can't even compile
most of them with gcc 4. The time goes into fixing design flaws in
v4l2. You don't see that work on this mailinglist, only in Linus'
changelogs. There's only one piece of work that I need to finish before
starting on the work to get the ivtv module into v4l. Unfortunately, I
also have other interests and things to do.
If you want to help by making kernel patches, feel free. But the bottom
line is that I don't have the time for that.
> ivtv 0.5 seemed aimed square at kernel inclusion
> (in november 2005, 5 months ago, will we hit the half-year mark?)
No doubt. Did you really think I could just drop 600 kilobyte of source
in the video4linux repository? It takes more than just adding sources
you know, and since ivtv brings new functionality with it the API needs
to be modified and designed to also work with future similar cards. One
example is the new v4l2 API for sliced VBI that has now been adopted.
Other issues will be the API to play/rewind/ffw/stop the mpeg decoder.
Or setting codecs.
As long as you are outside the kernel nobody cares, but moving into the
kernel takes time. And if you don't put in that effort your driver
isn't accepted.
> It quickly degenerated in some sort of 0.4 testing ground.
> (you'll note no 0.5.x version was ever released after the 12 november
> 2005)
No, nor will it. I made a mistake with the 0.5 branch, I intended it to
work with 2.6.15 but before I realized it the code would only work with
2.6.16. 0.6 will be the next release once 2.6.16 is out. 0.4.x will
remain supported for older kernels.
> Maybe it's time to declare 0.4 is as good as it will get and focus on
> inclusion? There's a vicious circle where you focus on not breaking
> old releases, and as result new releases suck, people use old
> releases, which justifies your first point, and you end up in
> stagnation.
0.4 has been for quite a while in maintenance mode only. New features go
to the trunk. There are no new releases right now until the release of
the new kernel as ivtv-0.6 already requires 2.6.16 functionality. So a
lot of work has already been done. You just don't see it unless you are
willing to use the ivtv version from the svn trunk, since that is the
latest and greatest and requires the v4l repository to work.
> Here.
> I'm done.
> Hope I won't resend something like this in a few months.
> I'm probably dead wrong about some things but that's how ivtv looks
> like from a bystander point of view.
Why not offer to help instead of complaining? I'm doing most of the work
in my own time for my own enjoyment. So you'll have to forgive me if
the last 1-2 months have been a bit slow. I have a life outside ivtv
you know. And, as I've said above, most of the effort is simply not
visible on the ivtv mailinglists. Just check the changelogs in the
2.6.15 and 2.6.16 kernels to see what I've contributed there.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
