On 01/09/2008, at 7:15 AM, Laurent Pinchart <[EMAIL PROTECTED]> wrote:
> Hi Alex, > > On Sunday 31 August 2008, Alex Hixon wrote: >> Hi Laurent, >> >> Way back in April last year, Sam Revitch sent an email to >> linux-uvc-devel[1] announcing the work he had been doing on r5u870, >> which >> provided a working webcam to those users with cameras using the Ricoh >> chipset. In January this year, I took up the task of maintaining >> the driver >> (since Sam had seemingly gone MIA). Maintaining an out-of-kernel >> driver and >> having very little time to tend to it (we now support 15 different >> camera >> models, up from 3 ;) has become very difficult as of late, and bug >> reports >> regarding conflicts between the r5u870 and uvcvideo modules seem to >> becoming more and more frequent. uvcvideo also seems to do a better >> job at >> the UVC stuff than the other driver on most devices, anyway. >> >> I've done a bit of hacking in an effort to retrofit uvcvideo with the >> firmware-loading functionality of the original r5u870 driver. It >> appears to >> work reasonably well. However, before I go and work on something >> worth >> committing, I was just curious as to whether I should be attempting >> to >> implement it in the kernel module (less work for me :) or as a >> userspace >> application. > > I've discussed firmware loading issues previously with iSight > developers, and > I wasn't very keen on adding firmware loading support to the UVC > driver, > especially with a userspace utility already available (the iSight is > based on > a Cypress chip). How do Ricoh webcams enumerate when the firmware is > not > loaded ? Is the firmware loading protocol specific to Ricoh devices ? As far as I'm aware, all Ricoh devices use the same firmware loading protocol. Looking at the source for the iSight cameras the other day, and found that they also interestingly use the same command while uploading firmware data (although a different format from what I gather). Before the firmware is uploaded to the devices, they still report via the USB descriptor that they are webcam devices, hence why uvcvideo picks it up. > >> One thing that might be an issue that I'm not sure was ever >> resolved in the >> communication between yourself and Chris was that regarding the UVC >> controls. As you might remember, the microcode that gets uploaded >> to the >> camera doesn't report all the controls it supports. Would it be >> possible to >> use some of the quirk modes provided by uvcvideo to get around that? > > Could you list the Ricoh "features" that are not UVC-compliant ? Are > the > non-reported controls addressed with standard UVC requests or with a > proprietary protocol ? For the most part, the controls that aren't reported but supported are all accessible through the standard controls, you just have to know which camera supports which. Once the firmware is uploaded, everything is handled by the UVC specification. Cheers, Alex Hixon _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
