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 [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
