Hi Sam, > > Is there any known reason for that ? That sounds a bit against the UVC > > spec. > > Thanks for your reply. > > Good question. I'd guess that Ricoh webcams have non-UVC controls > because the manufacturer couldn't fit the required functionality into > the limited code space. Some of these controls (but no UVC controls) > support auto-adjustment -- Exposure/AEC, Component WB/AWB, Gain/AGC. > There is no reason for these devices to support control change events, > but there would be if the auto controls were UVC.
:-/ > Realistically, for full support, the driver needs a hard-coded list of > non-UVC controls for each device, and of course needs to be able to > issue private non-UVC set commands for these controls. It's unclear > how to fit this into uvcvideo's clean, orderly control model, and > seems like a relatively large device-specific concession for an > otherwise generic driver. I've got to agree with you there... > > Agreed. I'd rather go for the first solution. > > > > Can we discuss the issues you mentioned, as well as all other issues you > > can foresee ? > > If uvcvideo had more complete frame buffer access methods, including > read and VIDIOCGMBUF, apps like camstream, motion, and wengophone > might work. VIDIOCGMBUF is part of the deprecated V4L1 API. Applications should be ported to V4L2. Adding V4L1 support is not planned. > One way to do this would be to link uvcvideo against video-buf, and > implement a short VIDIOCGMBUF handler. uvcvideo already implements full buffer management. The streaming I/O V4L2 method is fully supported. I might consider using video-buf later, although there are a few things I don't like in the API (especially the way video-buf insists on handling streamon/streamoff itself). VIDIOCGMBUF support isn't planned. > xawtv working would be another plus. xawtv should support V4L2. I'll have to debug it sometimes to find out if the issue lies in the application or in the driver. > I also have a module used by r5u870 that takes care of common webcam > problems, called usbcam. It handles device registration, file > operations, and V4L frame buffer access calls via video-buf. It's > also the foundation for another driver under development for a more > exotic sq930b device. I've been through many cycles tuning this > layer, listening to user complaints, tracing apps and figuring out how > to work around bugs, and refining its minidriver interface. To try to > integrate it with uvcvideo would be interesting, and I'm willing to > adapt it to your liking. This would be another way to fix the frame > buffer problems, and perhaps in a more reusable way. Once again, there are no frame buffer problems, only application problems :-) An approach to using V4L1 applications with the driver would be to write a LD_PRELOAD'able shared object that would intercept V4L1 calls and translate them into V4L2 calls. usbcam sounds interesting. Porting uvcvideo to usbcam would be lots of work, and I'm not willing to do that for now. Feel free to give it a go though :-) Don't forget that the uvcvideo driver is quite complex, and that it will eventually support video output as well, which falls out of the scope of usbcam. You might have issues with control handling which is being rewritten to allow for runtime controls definitions through specific ioctls. The extended control API will also have to be implemented by usbcam, and the mini drivers API will have to support control transactions. usbcam also seems to be missing proper multiple open support. Two applications opening the same device shouldn't be able to call VIDIOC_DQBUF for instance, or to mess with each other's streaming parameters. On a side note, you should split usbcam into several files. It will be easier to read the code. Do you plan to submit usbcam to the kernel ? Do you think current USB drivers could be ported ? One of the main issues is that developers might not be willing to throw away most of the code they wrote. Are you aware that Mauro (the V4L2 maintainer) is trying to move ioctl handling to the V4L2 layer, which is the first step to a mini driver approach ? It seems to me that V4L2 is undergoing some major changes, and I'm not sure to be happy with them. If we indeed decide that some operations (such as buffer management) should be handled by generic code, this should be discussed first on the video4linux mailing list. > > I'm still not sure if the firmware download operation should be handled > > by the driver or by a userspace utility. The fxload software from the > > usbutils package is meant to be called by the hotplug system. This would > > obviously be easier for the driver :-) > > > > Do all Ricoh devices advertise a different class and/or USB pid before > > and after loading the firmware ? > > Indeed, so you started a big thread about this a few months ago. > > Regarding the descriptor tables, the microcode and other volatile > state does not seem to have an effect on what is reported by Ricoh > webcam devices, so they don't behave like isight or ezusb devices. > This doesn't make it more difficult to do the microcode upload at user > level though -- the kernel driver must fail gracefully anyway when > probing a device without microcode, and a microcode uploader in this > case would have the additional problem of forcing the kernel driver to > re-probe the device, which isn't difficult. Is it possible to simulate device unplugging/replugging from userspace to force the USB stack to reenumerate the device ? > I wrote up a prototype upload utility, including a solution for the > device re-probe problem, and tested it with my non-UVC camera. This > utility should be enough to allow an unmodified uvcvideo to at least > grab frames from a Ricoh UVC camera. I assume the firmware loading requests are not compatible with ezusb chips, so fxload can't do the job. Is that right ? > There is little question that it is easier for the driver to outsource > microcode upload functions to a user level program. Overall it sounds > much more complicated, because one must also create, maintain, > evangelize, and support a separate package. If there is some other > reason that this sort of package must exist, fine, and if so, it might > be best to integrate the microcode upload functionality for as many > devices as possible into this package. It could be included in the kernel instead, but it would then have to be a generic microcode loader usable by several drivers. > As for the other problems, the Ricoh cameras do appear to be evolving. > Future models will probably follow the standard more completely and > do away with the non-UVC controls, and less device specific code might > be required of uvcvideo. Where do you feel comfortable drawing the > line? I don't mind adding a few quirks to the uvcvideo driver. Support for non-UVC controls is a bit more intrusive though. Other ways to support those hybrid devices would be to add hooks to uvcvideo or implement a minidriver interface like the one you wrote for usbcam. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
