Hi Alex,
On Monday 01 September 2008, Alex Hixon wrote:
> 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.
Does the device expose different descriptors after a firmware upgrade ? Does
it simulate a disconnection/reconnection when you upload the firmware ?
Could you please provide me with a full USB descriptors dump ('lsusb -v' with
usbutils 0.72 or newer) ? If descriptors before and after firmware loading
differ please send me both. I would also be interested in having a look at
the firmware file.
> >> 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.
Best regards,
Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
