Re:RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

[Olivier Lorin <o.lorin@laposte.net>]

Hi!

> We came to the conclusion that having a table in the kernel only for the
> purpose of userspace being able to query it, is not very efficient, and in
> general is not a good idea.
>
> So for the table of upside down webcam's we came to the following conclusion:
> -if the driver can do the rotation itself (in hw) then the table should be in
> the driver and it should invert the meaning of its hflip and vflip controls,
> (iow off is flip, on is do not flip) so that usserspace won't notice the cam
> being upside down in anyway
> -if the driver can not do the rotation libv4l will do it, and the table of cams
> which need this (such as certain uvc models) will be part of libv4l
>
> So I started thinking about my proposal to add read-only controls (CID's) to
> drivers which libv4l can query to find out if it would be a good idea to do
> things like software white balance for a cam.
>
> On second thought this is a bad idea for all the same reasons, having a table
> in the kernel, just so that userspace can query it makes little sense. Better
> to just put the table in userspace.
>
> So this mail mainly is a retraction of my earlier proposal (instead I will
> completely handle this in libv4l). But there are 2 special cases libv4l will
> still need some userspace <-> kernel API for:
>
> 1) With some bridges it is common to not have a usbid per bridge / sensor
> combi, but cams with the same usb-id can have different sensors (the driver
> finds out which one by probing the i2c bus between the bridge and sensor).
> Since things like whitebalance and autogain are often done in the sensor,
> in these cases libv4l will need a way to find out the sensor (the bridge it
> can deduct from the usb-id). So we need a userspace API to query which
> sensor a bridge is connected too.
>
> I would like to suggest to use one of the 4 reserved __u32's in the
> v4l2_capability struct for this. We could then make a very large enum with
> all known sensors and store that there, but instead I would suggest to make
> this a driver specific field, so v4l2_capability would then look like this:

I hope that "driver specific field" does not mean that the same bit may have
different meanings depending on the webcam!


> 2) With some cams the upside down ness may actually be stored in an eeprom, or
> in some cases even determined by a switch (so the cam can be rotated
> manually by the user and the the switch indicates the position)
>
> In these cases we need a userspace API to find this out too. Since this is a
> per frame thing for some cams (one frame could be upright, the next upside
> down). I would like to suggest to define some V4L2_BUF_FLAG_ 's for this
> which can be used by drivers to indicate that the picture in the buffer is
> vflipped or hflipped (with upside down being both together).

In the case of the Genesys webcams using the gl860 bridge,
the upside down state is not really relevant per frame as
there is some instabilities when it is as upside down as right up
so that it is not usefull to check every image state
(by the way it's not a switch but a kind gravity sensor).
The V4L2_BUF_FLAG is a good idea as it matches better the image state purpose
than the V4L2_CID, however it is not to be confused with the upside down sensor
as in these cases, it is not usefull to check regularly the orientation of the image
so that V4L2_BUF_FLAG seems not to be as suitable as some v4L2 capability.
For the read-only properties, to avoid to use the V4L2_CID seems to be quite logical as
they may appear in the allowed settings on a webcam viewer GUI although they
are not to be changed by the user.

 Créez votre adresse électronique prenom.nom@laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list