On Tuesday 10 February 2009 19:18:03 Jean-Francois Moine wrote: > On Mon, 9 Feb 2009 18:50:15 -0200 > > Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > > On Thu, 5 Feb 2009 10:32:31 +0100 > > Jean-Francois Moine <moinejf@xxxxxxx> wrote: > > [snip] > > > > Please pull from http://linuxtv.org/hg/~jfrancois/gspca/ > > > for: > > [snip] > > > Hmm... it seems that your tree has more changesets than what you've > > pointed on your pull request... I got here 15 patches. > > Right! And there are some more to come! I was waiting for you to do the > pull before requesting a new pull... > > > On the last changesets, I've seen that you're adding a lot of private > > controls, like those: > > > > +#define V4L2_CID_IMAGE_QUALITY (V4L2_CID_PRIVATE_BASE + 0) > > +#define V4L2_CID_CAM_QUALITY (V4L2_CID_PRIVATE_BASE + 1) > > > > and, on other driver: > > > > +#define V4L2_CID_INFRARED (V4L2_CID_PRIVATE_BASE + 0) > > +#define V4L2_CID_IMAGE_QUALITY (V4L2_CID_PRIVATE_BASE + 1) > > +#define V4L2_CID_JPEG_QUALITY (V4L2_CID_PRIVATE_BASE + 2) > > > > We should really standardize those controls and prepare some patches > > for V4L2 API also, documenting what does that mean. Btw, it as not > > clear what's the difference between those "quality" controls... Argh! Don't use PRIVATE_BASE except as a duplicate for older apps! Add class-private controls as was done with the MPEG controls. I wrote a good overview of how to add private controls and the current status of that here: http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg07999.html I suggest that you add proper camera controls to videodev2.h from base V4L2_CTRL_CLASS_CAMERA | 0x1000, document them in the spec and use PRIVATE_BASE IDs internally as a backup for old apps. Currently I am working to convert all drivers to use the new v4l2 framework. Once that it finished I can start to do all sorts of fancy stuff including improving handling of controls. You might want to consider converting gspca to use v4l2_device as well to be prepared for that. It doesn't do much right know (unless the driver needs i2c modules), but it will become much more important in the future. > Well, each webcam has a lot of parameters. Some of them enter in the > standard controls, some other ones are very specific. > > This is the case here for the zc3xx subdriver: there is a quality > parameter in the bridge which accepts values from 0 to 3. This > parameter is automatically set by the ms-win driver according (surely) > to the luminosity, and its initial value depends on the sensor. As we > have no documentation about this quality, the best for me was to have a > specific control (CAM_QUALITY). > > What difference with the JPEG quality? This last control is used to > load the quantization tables into the webcam. The quality is the > standard JPEG compression quality (value 0..100 in percent). > > And the last control? It is not a control of the webcam. It defines > the quantization tables which are added to the webcam raw images to > create JPEG images readable by any JPEG/MJPEG viewer. So, while their > units are the same (compression in percent), the difference between > JPEG_QUALITY and IMAGE_QUALITY is that the first one is used for > encoding (in the webcam) while the second one is used for decoding (by > the v4l library). JPEG_QUALITY looks to me to be perfect as a general camera or user control. IMAGE_QUALITY I don't get. Do you mean that the v4l library will use this control? For what? > Indeed, I should have written some documentation, but I think most users > will play with these controls before reading anything. They *must* be documented in the spec. There are other private controls in existing drivers that are completely undocumented and nobody knows what they do. Let's prevent that for new private controls. > About the two last controls (quantization tables in the webcam or added > in the raw JPEG images), there is already a jpegcomp ioctl, but I could > not understand how it should work. AFAIK, only one driver implements it. I'm working on the zoran driver anyway. I'll see if I can find out some decent documentation and add it to the spec (another case of people adding to the API without documenting it!). To be honest, I am afraid that they basically added a zoran-private ioctl to the public V4L2 API and it probably is useless outside that single driver. Regards, Hans > Otherwise, one interesting feature of the V4L2 API is the possibility > for any application to handle all standard and private device controls > via VIDIOC_G/S_CTRL. Usually, control changes are not done > automatically by applications, but by the users. Once a user has set > the controls to get correct images, he may start any viewer application > (but not mplayer which resets some controls to their default!). > > BTW, it should be useful to have a program which saves the control > values on disk at change time, device disconnection or reboot) and > reload them at system start or on device connection... > > Cheers. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
