From Nick.Holloway@pyrites.org.uk Fri, 18 Oct 2002 20:32:42 +0100 Date: Fri, 18 Oct 2002 20:32:42 +0100 From: Nick Holloway Nick.Holloway@pyrites.org.uk Subject: [cpia] [PATCH] Devices do not get de-registered on module removal On Fri, Oct 18, 2002 at 03:01:00AM -0400, Duncan Haldane wrote: > Are there any advantages to Nick's > fix that I havent appreciated? (see his patch posted in August). I could see that one way to fix it was to add the extra level of indirection as you've done in your patch. However, rather than than having yet another implementation of doubly-linked lists in the kernel source, I thought it would be better to use the existing implementation provided by . I would say the only advantage is that there is a little bit less code to be maintained by cpia. On the other hand, I don't see any advantage in cpia keeping its own private list implementation. -- `O O' | Nick.Holloway@pyrites.org.uk // ^ \\ | http://www.pyrites.org.uk/ From f.duncan.m.haldane@worldnet.att.net Fri, 18 Oct 2002 03:01:00 -0400 (EDT) Date: Fri, 18 Oct 2002 03:01:00 -0400 (EDT) From: Duncan Haldane f.duncan.m.haldane@worldnet.att.net Subject: [cpia] [PATCH] Devices do not get de-registered on module removal Hi I've been maintaining the old cpia driver at sourceforge.. I finally got round to fixing (in CVS) this problem reported by Nick Holloway. (but more conservatively than his patch...) It seems to have crept in by an earlier "code cleanup"..... Are there any advantages to Nick's fix that I havent appreciated? (see his patch posted in August). I've been feeding updates from CVS to the official kernel via Alan Cox. Some will be in 2.4.20. P.S. Is the cpia list still working? (Peter, can you check ,if this email doesnt get resent to the list). diff -uNr module/cpia.h module-fixed/cpia.h --- module/cpia.h Sat May 11 14:51:02 2002 +++ module-fixed/cpia.h Fri Oct 18 02:41:48 2002 @@ -419,16 +419,20 @@ (p)&0x80?1:0, (p)&0x40?1:0, (p)&0x20?1:0, (p)&0x10?1:0,\ (p)&0x08?1:0, (p)&0x04?1:0, (p)&0x02?1:0, (p)&0x01?1:0); -static inline void cpia_add_to_list(struct cam_data* l, struct cam_data* drv) +static inline void cpia_add_to_list(struct cam_data** l, struct cam_data** drv_p) { - drv->next = l; - drv->previous = &l; - l = drv; + struct cam_data* drv; + drv = *drv_p; + drv->next = *l; + drv->previous = l; + *l = drv; } -static inline void cpia_remove_from_list(struct cam_data* drv) +static inline void cpia_remove_from_list(struct cam_data** drv_p) { + struct cam_data* drv; + drv = *drv_p; if (drv->previous != NULL) { if (drv->next != NULL) drv->next->previous = drv->previous; diff -uNr module/cpia_pp.c module-fixed/cpia_pp.c --- module/cpia_pp.c Thu May 9 20:36:11 2002 +++ module-fixed/cpia_pp.c Fri Oct 18 02:42:00 2002 @@ -1507,7 +1507,7 @@ return -ENXIO; } spin_lock( &cam_list_lock_pp ); - cpia_add_to_list(cam_list, cpia); + cpia_add_to_list(&cam_list, &cpia); spin_unlock( &cam_list_lock_pp ); return 0; @@ -1521,7 +1521,7 @@ for(cpia = cam_list; cpia != NULL; cpia = cpia->next) { struct pp_cam_entry *cam = cpia->lowlevel_data; if (cam && cam->port->number == port->number) { - cpia_remove_from_list(cpia); + cpia_remove_from_list(&cpia); spin_unlock( &cam_list_lock_pp ); #ifdef CONFIG_VIDEO_CPIA_PP_DMA diff -uNr module/cpia_usb.c module-fixed/cpia_usb.c --- module/cpia_usb.c Thu May 9 20:00:50 2002 +++ module-fixed/cpia_usb.c Fri Oct 18 02:41:56 2002 @@ -565,7 +565,7 @@ } spin_lock( &cam_list_lock_usb ); - cpia_add_to_list(cam_list, cam); + cpia_add_to_list(&cam_list, &cam); spin_unlock( &cam_list_lock_usb ); return cam; @@ -617,7 +617,7 @@ struct usb_cpia *ucpia = (struct usb_cpia *) cam->lowlevel_data; spin_lock( &cam_list_lock_usb ); - cpia_remove_from_list(cam); + cpia_remove_from_list(&cam); spin_unlock( &cam_list_lock_usb ); /* Don't even try to reset the altsetting if we're disconnected */ On 07-Aug-2002 Nick Holloway wrote: > I've been using a parport cpia camera, with the driver compiled as > modules. I found that if the camera had been used, and the modules > unloaded, the next attempt to load caused an oops. > > I discovered that this was due to the camera not getting deregistered > when the module was unloaded. > > Several DBGs and recompiles later, I tracked this down to "cam_list" > never containing any entries, because "cpia_add_to_list" doesn't manage > to add the camera to the list (code looks OK at first glance, but doesn't > actually modify "cam_list", but just its local copy). > > Here is a patch to use the double-linked list implementation from > "linux/list.h". This patch is against the current CVS tree. > > I've tested cpia_pp with a single camera with kernel 2.4.18. I've updated > the 2.2.x style deregistration, but I can't test it, as my parport needs > 2.4 to be used with the camera. I've updated cpia_usb, but I also can't > test this. > > -- > `O O' | Nick.Holloway@pyrites.org.uk > // ^ \\ | http://www.pyrites.org.uk/ ---------------------------------- E-Mail: Duncan Haldane Date: 18-Oct-2002 Time: 02:48:39 This message was sent by XFMail ---------------------------------- From f.duncan.m.haldane@worldnet.att.net Mon, 14 Oct 2002 22:57:28 -0400 (EDT) Date: Mon, 14 Oct 2002 22:57:28 -0400 (EDT) From: Duncan Haldane f.duncan.m.haldane@worldnet.att.net Subject: [cpia] CPiA driver news: cpia-control-0.4 released Hi, to any CPiA-based Webcam users (if any are left...) I just released a 0.4 version of Peter Preglers cpia-control utility with a few cleanups and the capability to set a few more features (YUV order (YUYV/UVYV) and subsampling (4202/420), decimation on/off and fast/slow ECP port speed). It also no longer complains when unsupported keys in /proc/cpia/video change.. 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. The /proc/cpia/video control interface is again writable to in linux-2.4.20-pre10 from Marcelo Tosati, and the QX3 microscope is now supported there. Alan Cox has put these changes in linux-2.5.41-ac1, so they will find their way into future 2.6 kernels. I have just sent Alan and Marcello a patch to about cpia-1.1 (YUV420, decimation etc), and this should also show up in 2.4.20 or 2.4.21. Next will be a patch to update the kernel drivers to cpia-1.2 (better flicker control)(prepared), and finally a patch with VIDIOSCAPTURE support (not yet prepared), This will finish moving the driver work that is here in the sourceforge CVS for a long time into the kernel. (It needed to be done in smaller chunks.) I'll also try to find time sometime to check out the patch posted by Nick Holloway in August (a bug in deregistering the camera, it seems). Duncan ---------------------------------- E-Mail: Duncan Haldane Date: 14-Oct-2002 Time: 22:33:45 This message was sent by XFMail ---------------------------------- From Nick.Holloway@pyrites.org.uk 18 Oct 2002 23:58:26 +0100 Date: 18 Oct 2002 23:58:26 +0100 From: Nick Holloway Nick.Holloway@pyrites.org.uk Subject: [cpia] CPiA driver news: cpia-control-0.4 released 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/ From f.duncan.m.haldane@worldnet.att.net Sun, 20 Oct 2002 00:21:03 -0400 (EDT) Date: Sun, 20 Oct 2002 00:21:03 -0400 (EDT) From: Duncan Haldane f.duncan.m.haldane@worldnet.att.net Subject: [cpia] a new CVS branch for a .v4l2 driver for 2.5.x kernel 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 Date: 20-Oct-2002 Time: 00:05:53 This message was sent by XFMail ---------------------------------- From f.duncan.m.haldane@att.net Sat, 19 Oct 2002 00:46:40 +0000 Date: Sat, 19 Oct 2002 00:46:40 +0000 From: f.duncan.m.haldane@att.net f.duncan.m.haldane@att.net Subject: [cpia] CPiA driver news: cpia-control-0.4 released > f.duncan.m.haldane@worldnet.att.net (Duncan Haldane) writes: >> > Is anyone looking at getting cpia updated for 2.5.x? > Alan Cox accepted the first set of updates from CVS (QX3 support, reactivate camera control by writing to /proc/cpia ) into 2.5.42-ac1. I got things to compile without error, but I havent got usb working if I boot into 2.5.4x, so I havent been able to test the cpia driver. The updates I am planning to send (yuv420 flicker control etc) are not sensitive to v4l2 updates, so they should be OK, but obviously the driver needs to get tested. > 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? > Probably a good idea... Shall I put the source from 2.5.42-ac1 as a new tree at sourcefource, and update it from the old source? That way I make the patches, and then it is a basis for v4l2 improvements? Duncan > - > [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 From f.duncan.m.haldane@worldnet.att.net Sun, 20 Oct 2002 18:17:37 -0400 (EDT) Date: Sun, 20 Oct 2002 18:17:37 -0400 (EDT) From: Duncan Haldane f.duncan.m.haldane@worldnet.att.net Subject: [cpia] kernel patches done, new 2.5.x. branch open at sourceforge Hi, I've finally completed the cpia driver patchsets for 2.4.20 and 2.5.44, and sent them to Alan Cox. The first batch of updates made their way into Marcelo's 2.4.20pre8 and Linus' 2.5.43 kernels, so this route seems to be working. The new branch cpia/module-v4l2 at sourceforge has the full driver for kernels 2.5.43 and later, and cpia/module works with 2.4.20 or earlier. (sorry for all the typos in the cvs log messages whne I committed this..) The 2.5.43 code compiles, but hasnt been tested on my cameras, as I havent yet managed to get USB working under 2.5.x. (I guess I should try to test my parport camera, but I havent yet, because of parport issues...) If anyone can test the CVS module-v4l2 code on linux >=2.5.43 please do. Any Video4linux2 improvements should get added to that codebase. (Nick?) Duncan. ---------------------------------- E-Mail: Duncan Haldane Date: 20-Oct-2002 Time: 18:03:31 This message was sent by XFMail ---------------------------------- From Nick.Holloway@pyrites.org.uk 21 Oct 2002 20:57:39 +0100 Date: 21 Oct 2002 20:57:39 +0100 From: Nick Holloway Nick.Holloway@pyrites.org.uk Subject: [cpia] a new CVS branch for a .v4l2 driver for 2.5.x kernel f.duncan.m.haldane@worldnet.att.net (Duncan Haldane) writes: > If anyone can test on 2.5.44 or later, please do. After applying the PnP patch against 2.5.44 [1], I've got the current cpia CVS compiled in. I can now give the parport camera a test on my state of the art hardware [2]. > I can add you as a sourceforge developer if you have a sourceforge account. That might be useful. I've created "nwh" as an account. I've already spotted that the module counts are not getting incremented when the cpia device is open, so I'll look into that. - [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=103505548907204&q=raw [2] 486 DX2/50 12MB/540MB lp0: PCSPP/TRISTATE -- `O O' | Nick.Holloway@pyrites.org.uk // ^ \\ | http://www.pyrites.org.uk/ From Nick.Holloway@pyrites.org.uk Wed, 23 Oct 2002 21:30:42 +0100 Date: Wed, 23 Oct 2002 21:30:42 +0100 From: Nick Holloway Nick.Holloway@pyrites.org.uk Subject: [cpia] a new CVS branch for a .v4l2 driver for 2.5.x kernel I've committed a couple of changes to the cpia driver in the module-v4l2 directory over the last few days. The first was a fix for some unmatched down/up calls on a couple of the camera semaphores. This caused ioctl to hang. The second was a fix to ensure the module counts for cpia_pp and cpia_usb are maintained when the camera is opened and closed. This prevents them being unloaded when the camera was in use. The parport cpia camera now works for me with the 2.5.44 kernel (Creative WebCam II). If somebody has the USB camera, this version needs to be tested. -- `O O' | Nick.Holloway@pyrites.org.uk // ^ \\ | http://www.pyrites.org.uk/ From f.duncan.m.haldane@worldnet.att.net Wed, 23 Oct 2002 22:29:47 -0400 (EDT) Date: Wed, 23 Oct 2002 22:29:47 -0400 (EDT) From: Duncan Haldane f.duncan.m.haldane@worldnet.att.net Subject: [cpia] a new CVS branch for a .v4l2 driver for 2.5.x kernel Great! I noticed Nick had committed. Its good to know the 2.5 cpia code is now working with parport webcams. I haven't yet managed to get USB working under 2.5.x (the modules load but neither cpia nor other usb devices are getting activated - its nothing specific to the cpia driver ...) This was with 2.5.43 and 2.5.44-ac1. I'll try again with 2.5.44-ac2 which now has the full cpia update I sent to Alan Cox. (I sent it before the fixes Nick committed, so I'll send another update hopefully after I get usb working, but if I can't, I won't delay the patch). I suppose this means that Linus will take the patch from Alan, and we are in before the 2.5.x feature freeze..... So Peter Pregler's and Scott Bertin's work will live on for posterity in future kernels.... One thing that didn't make it from 2.2 into 2.4 was DMA support for the parport. (#ifdef CONFIG_VIDEO_CPIA_PP_DMA code). This was stripped from cpia_pp.c in the official kernel sources, but is there in the sourceforge cpia/module code (but not in the 2.5 code in module-v4l2) This needed some extra support to be patched into the 2.2 kernel, and some people on this list have mentioned working on it for 2.4 in the past. Does the 2.5 kernel contain some generic DMA access feature that cpia_pp.c could use? Does DMA make a noticeable improvement for parport cameras? Duncan On 23-Oct-2002 Nick Holloway wrote: > I've committed a couple of changes to the cpia driver in the module-v4l2 > directory over the last few days. > > The first was a fix for some unmatched down/up calls on a couple of the > camera semaphores. This caused ioctl to hang. > > The second was a fix to ensure the module counts for cpia_pp and cpia_usb > are maintained when the camera is opened and closed. This prevents them > being unloaded when the camera was in use. > The parport cpia camera now works for me with the 2.5.44 kernel (Creative > WebCam II). If somebody has the USB camera, this version needs to > be tested. > > -- > `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 Date: 23-Oct-2002 Time: 21:53:42 This message was sent by XFMail ---------------------------------- From f.duncan.m.haldane@worldnet.att.net Fri, 25 Oct 2002 22:37:43 -0400 (EDT) Date: Fri, 25 Oct 2002 22:37:43 -0400 (EDT) From: Duncan Haldane f.duncan.m.haldane@worldnet.att.net Subject: [cpia] ReEPP (as opposed to ECP) parport support for cpia_pp ? Hi I was tying to test the 2.5.44 cpia code with the Creative WebCam II (paralell port) camera, but the machine I set 2.5.44 up on only supports PCSPP and EPP paralel port modes. The cpia_pp code only seems to support ECP and TRISTATE parport modes. The Webcam Works fine using windows, but not under linux with ether the 2.4.x or 2.5.x cpia drivers, because the "paralel port is nor ECP-capable". Presumably it *could* work with EPP protocol, but none of the original developers had an EPP parport? is TRISTATE a subset of EPP that would work? Would it be easy to add EPP support to cpia_pp.c? (I am not really interested in running an obsolete camera on an EPP parport, but I could test it) Duncan On 23-Oct-2002 Nick Holloway wrote: > I've committed a couple of changes to the cpia driver in the module-v4l2 > directory over the last few days. > > The first was a fix for some unmatched down/up calls on a couple of the > camera semaphores. This caused ioctl to hang. > > The second was a fix to ensure the module counts for cpia_pp and cpia_usb > are maintained when the camera is opened and closed. This prevents them > being unloaded when the camera was in use. > > The parport cpia camera now works for me with the 2.5.44 kernel (Creative > WebCam II). If somebody has the USB camera, this version needs to > be tested. > > -- > `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 Date: 25-Oct-2002 Time: 22:25:09 This message was sent by XFMail ---------------------------------- From Peter_Pregler@email.com Sat, 26 Oct 2002 14:07:58 +0200 Date: Sat, 26 Oct 2002 14:07:58 +0200 From: Peter Pregler Peter_Pregler@email.com Subject: [cpia] EPP (as opposed to ECP) parport support for cpia_pp ? On Fri, 25 Oct 2002 22:37:43 -0400 (EDT) Duncan Haldane wrote: > I was tying to test the 2.5.44 cpia code with the Creative WebCam II > (paralell port) camera, but the machine I set 2.5.44 up on only > supports PCSPP and EPP paralel port modes. > > The cpia_pp code only seems to support ECP and TRISTATE parport modes. Correct. > The Webcam Works fine using windows, but not under linux with ether > the 2.4.x or 2.5.x cpia drivers, because the "paralel port is nor > ECP-capable". > > Presumably it *could* work with EPP protocol, but none of the original > developers had an EPP parport? is TRISTATE a subset of EPP that would > work? It could work. EPP is somewhat close to ECP in capabilities. The TRISTATE is far worse and I would not recommend it for streaming but just for grabbing single pictures. But that you can do also with userspace-tools (at least someone was writing such stuff). > Would it be easy to add EPP support to cpia_pp.c? (I am not really > interested in running an obsolete camera on an EPP parport, but I > could test it) Well, the basic parport code completely changed from 2.2 to 2.4. In 2.2. the cpia_pp has somewhat direct access to the parport. In 2.4. there is an abstract parport-interface and the parport-code itself should implement and automagically use what is actually available. Actually, there should not be a message from cpia_pp that it cannot work in 2.5. If there is such a problem the message should come from the parport-drivers. Check out the cpia_pp_register. The capability-check there seems to be overly strict to me. What the cpia-chip really supports you should be able to find in the chip-documents available at webcam.sourceforge.net. But as I said you could try the generic approach and simply remove that and see what the parport-layer tells you. Unfortunatly, I have neither a parport-camera available anymore. And the parport-people did never implement all the necessary read-stuff since they were focused more or less on writing (the printer symptom). Therefore there is also no DMA-read available in 2.4 which has to be reimplemented at the generic parport-read layer. And finally similar to you I am not really interested to write new code for such old stuff. -Peter -- As an individual my scope is limited. ------------------------------- Email: Peter_Pregler@email.com From mip_fyp@yahoo.com Thu, 31 Oct 2002 02:33:10 -0800 (PST) Date: Thu, 31 Oct 2002 02:33:10 -0800 (PST) From: Affan Ahmed mip_fyp@yahoo.com Subject: [cpia] Webcam 3 pp version not being detected Hello every one, I am unable to get my Webcam 3 to be detected. I have RH 7.2, with kernel 2.4.7-10. This already contained the cpia driver, and i simply did the following: modprobe cpia_pp I also set up the camera in such a way so that it is getting power (via the PS/2 port sharing with keyboard ...arrrgh... a very ungainly method), but there is no /proc/cpia/video0 file even dmesg dosent show any device being detected. dmesg shows the following messges: Linux video capture interface: v1.00 V4L-Driver for Vision CPiA based cameras v0.7.4 Parallel port driver for Vision CPiA based cameras v0.7.4 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] parport0: cpp_daisy: aa5500ff(98) parport0: assign_addrs: aa5500ff(98) parport0: cpp_daisy: aa5500ff(98) parport0: assign_addrs: aa5500ff(98) parport_pc: Via 686A parallel port: io=0x378 usb.c: registered new driver cpia Parallel port driver for Vision CPiA based cameras v1.2.1 PCI: Found IRQ 10 for device 00:07.5 PCI: Sharing IRQ 10 with 00:0a.0 PCI: Setting latency timer of device 00:07.5 to 64 Parallel port driver for Vision CPiA based cameras v1.2.1 Can any body suggest a solution. How can i make this camera get detected. regards affan Ahmed __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ From Nick.Holloway@pyrites.org.uk 31 Oct 2002 12:44:51 -0000 Date: 31 Oct 2002 12:44:51 -0000 From: Nick Holloway Nick.Holloway@pyrites.org.uk Subject: [cpia] Webcam 3 pp version not being detected mip_fyp@yahoo.com (Affan Ahmed) writes: > I am unable to get my Webcam 3 to be detected. I have RH 7.2, with > kernel 2.4.7-10. This already contained the cpia driver [...] This camera is not a CPiA device, so will not work with this driver. The SourceForge page has pointers to some information for the WebCam III. -- `O O' | Nick.Holloway@pyrites.org.uk // ^ \\ | http://www.pyrites.org.uk/ From mip_fyp@yahoo.com Thu, 31 Oct 2002 05:51:43 -0800 (PST) Date: Thu, 31 Oct 2002 05:51:43 -0800 (PST) From: Affan Ahmed mip_fyp@yahoo.com Subject: [cpia] Webcam 3 pp version not being detected Thankyou all for your replies, All of you seem to agree on one thing WebCam3 does not work with CPiA. but the problem is that it says on source forge that ov511 supports it. On ov511 site (http://alpha.dyndns.org/ov511/faq.html) i find out that it only supports Webcam 3 with USB. I quote: "Q: I have a parallel port camera. Does your driver support it? A: The OV511 chip supports the USB bus only. The CPiA chip is used in many parallel cameras, notably some revisions of the Creative Labs WebCam3 Parallel, and in some USB cameras. You can find drivers for the CPiA here . Surprisingly, the USB version of the WebCam3 uses the OV511, not the CPiA, probably since the OV511 supports higher resolutions and is therefore (arguably) a better chip. " The parallel port version works with CPiA. And i am back on this list again!!! ( Actually i had already tried ov511 before coming to you guys) So can any one help now. --- Nick Holloway wrote: > mip_fyp@yahoo.com (Affan Ahmed) writes: > > I am unable to get my Webcam 3 to be detected. I have RH 7.2, with > > kernel 2.4.7-10. This already contained the cpia driver [...] > > This camera is not a CPiA device, so will not work with this driver. > > The SourceForge page has > pointers to some information for the WebCam III. > > -- > `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 __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ From Nick.Holloway@pyrites.org.uk 31 Oct 2002 18:58:35 -0000 Date: 31 Oct 2002 18:58:35 -0000 From: Nick Holloway Nick.Holloway@pyrites.org.uk Subject: [cpia] Webcam 3 pp version not being detected mip_fyp@yahoo.com (Affan Ahmed) writes: > "Q: I have a parallel port camera. Does your driver support it? > A: The OV511 chip supports the USB bus only. The CPiA chip is used in > many parallel cameras, notably some revisions of the Creative Labs > WebCam3 Parallel, and in some USB cameras. You can find drivers for the > CPiA here. I hadn't read closely enough to spot that it says that _some_ revisions of the WebCam3 parallel are cpia. The first step is to determine if your camera is one of them. When I boot a 2.4.18 kernel with the WebCam II plugged in, I get the following (taken from dmesg): parport0: PC-style at 0x3bc [PCSPP,TRISTATE] parport0: Multimedia device, VLSI Vision Ltd PPC2 Camera If I cat /proc/sys/dev/parport/parport0/autoprobe, then I get: CLASS:MEDIA; MODEL:PPC2 Camera; MANUFACTURER:VLSI Vision Ltd; DESCRIPTION:Parallel Port Camera; COMMAND SET:CPIA_1-20; The cpia_pp driver only registers cameras where the device is class media, and the command set starts with "CPIA_1". What do you get from your bootup messages and /proc information when you boot with your camera plugged in? -- `O O' | Nick.Holloway@pyrites.org.uk // ^ \\ | http://www.pyrites.org.uk/