[cpia] a new CVS branch for a .v4l2 driver for 2.5.x kernel

Duncan Haldane f.duncan.m.haldane@worldnet.att.net
Sun, 20 Oct 2002 00:21:03 -0400 (EDT)


Hi I have added a new subtree cpia/module-v4l2 at
http://webcam.sourceforge.net.

It starts with the linux-2.5.44 kernels sources 
(which includes the first set of updates I sent to 
Alan Cox), and I have progerssively patched them
to include (ithink) all the improvemenst in the sourceforce
cvs.

i.    2.5.44 sources  (has reactivated cpia_write-proc() and QX3 support)
ii.   fix for the (De)register bug reported by Nick Hollaway
iii.  patch to about the v1.1 driver.  (yuv420 and decimation)
iv.   patch to some of v1.2 driver  (flicker control)
v.    patch to rest of 1.2 drivers (VID_TYPE_SUBCAPTURE support) 
vi.   cosmetic fixes (end "preprocessor abuse" in cpia_write_proc())

This is the sequence I intend to push the updtates into the kernel in.
The upadtes compile OK on 2.5.44, but are not tested, as I havent
managed to get 2.5.x usb working yet...


If anyone can test on 2.5.44 or later, please do.  

I will try to keep the CVS synced with the latest 2.5.x kernels.   Nick (or
anyone else), feel free to add any more working
v4l2 improvements to these sources.  I can add you as a
sourceforge developer if you have a sourceforge account.


Duncan

On 18-Oct-2002 Nick Holloway wrote:
> f.duncan.m.haldane@worldnet.att.net (Duncan Haldane) writes:
>> I also found some time last weekend to get patches for the
>> Kernel maintainers ready and tested, so the work in the sourceforge
>> CVS source won't just get lost.
> 
> I'm really glad that this stuff is getting pushed to the mainstream kernel
> -- as you say, it prevents the CVS source from mouldering in a corner.
> 
> Is anyone looking at getting cpia updated for 2.5.x?
> 
> I had a go at getting cpia to compile under 2.5 with the various API
> changes.  I reckon that I've battled about 80% of the way, basing my
> changes on the way that other drivers have been updated.  I'd like to
> try and complete this, maybe waiting to see if v4l2 does land before
> Halloween.
> 
> My main feeling from the work so far, is that the extent of the changes
> mean that it is not feasible to augment the current source with more of
> '#if (LINUX_VERSION_CODE...'.  For example, my current code has this
> for cpia_mmap:
> 
>     #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0))
>     static int cpia_mmap(struct file *file, struct vm_area_struct* vma )
>     {
>           unsigned long start = vma->vm_start;
>           unsigned long size  = vma->vm_end - vma->vm_start;
>           struct video_device *dev = video_devdata(file);
>     #else
>     static int cpia_mmap(struct video_device *dev, const char *adr,
>                        unsigned long size)
>     {
>           unsigned long start = (unsigned long)adr;
>     #endif
> 
> The area around the memory handling is worse, and I think this is just
> too difficult to maintain.
> 
> What do people[1] think of the idea of producing a set of cpia*.[ch] for
> the 2.5 kernel, free from the baggage of earlier kernel support?
> 
> -
> [1] If there is anybody out there :-)
> 
> -- 
>  `O O'  | Nick.Holloway@pyrites.org.uk
> // ^ \\ | http://www.pyrites.org.uk/
> 
> _______________________________________________
> cpia mailing list  -  cpia@risc.uni-linz.ac.at
> http://mailman.risc.uni-linz.ac.at/mailman/cgi-bin/listinfo/cpia

----------------------------------
E-Mail: Duncan Haldane <f.duncan.m.haldane@worldnet.att.net>
Date: 20-Oct-2002
Time: 00:05:53

This message was sent by XFMail
----------------------------------