Nemosoft Unv. wrote:
<snip>
Comment #2 (the negative one)
What an utter waste of time.
I'm sorry to say this, and I've thought for a while if I even should
mention this, but this is how I feel about it.
Hey, it wasn't my patch. :-) I must admit that I liked the changes
though. V4L drivers are notoriously complex and bloated, and anything to
alleviate that is welcome IMHO.
In stead of fixing the
problems that are there for V4L1, or making a commitment of getting V4L2
into the kernel and drivers, you introduce changes for an API that I
consider out-of-date (though in widespread use) and work for us who write
the drivers.
Since I don't know the status or plans for V4L2 in 2.5, I won't try to
justify the timing of these changes. This does deploy V4L2 in a more
incremental manner, which is probably a good thing.
My main complaint is that now I have to keep track of 3 development
threads: the 2.4 kernel, the 2.5 kernel which literally changes memory
subsystem every release, and this V4L1.1 interface.
I'm sure there are many good reasons to do this, but the timing sucks
(more about that below).
There are probably good technical reasons for having direct access to
fops (potentially fewer races, and easier handling of multiple opens).
Oh yes, for the Question: when do you think this will make it into 2.5 (if
it hasn't already)?
It's already in 2.5.7-pre1.
As for abandoning 2.4 because of V4L2, you probably won't have to do
that completely. The V4L2 "videodevX" driver works with 2.2 and 2.4, and
supports both V4L1 and V4L2 drivers and apps. Your in-kernel 2.4 driver
will have to be abandoned, of course, but 2.4 users will still be able
to use the latest driver from your website.
Yes, but I'd have to make my driver ready for V4L2 (which is only backward
compatible). And since that isn't in the main kernel yet, we have a
chicken-and-egg problem...
Agreed. This is why my ov511 is still a V4L1 driver. With all the talk
of a V4L3 a few months ago, I didn't want to risk writing for any API
that wan't available from kernel.org.
However, as long as V4L2 retains its compatibility layer when it is
merged into 2.5, we can stick with our current V4L1 drivers until either
the compatibility layer is ripped out, or users begin demanding
V4L2-only features.
And by 'abandon' I mean that new features that make it into the 2.5.* tree
will not be incorported into 2.4.*. Of course I'm not going to pull the
source code from 2.4...
Right. I was simply saying that even if new features can't be
incorporated into 2.4, videodevX will allow 2.4 users to play with your
latest driver even after you make the switch to V4L2.
Follow-ups to V4L list.
--
Mark McClelland
mmcclell@xxxxxxxxxxx
