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

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

[Olivier Lorin]

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

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

[Olivier Lorin]

> >> 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).
>
>
> Please be aware of the fact that, when the gspca-sq905 module is
> considered complete, there will need to be some kind of scheme which will
> take its needs into consideration. Here is what happens with these
> cameras:
>
> 1. All of them have the same Vendor:Product number, 0x2770:0x9120.
>
> 2. Some of them emit output which needs vertical inversion, but for some
> others a horizontal mirroring is required, instead.
>
> 3. The way that you can tell which is needed is that a four-byte model
> number is requested, and that can be parsed to decide which of (1) or
> (2) to do. The way the camera works, the first step in initializing it is
> to read this number; the streaming takes place after that.
>
> Clearly, it is possible either to perform the appropriate action on the
> frames either in the module, or in userspace, in libv4l. Equally obvious,
> if the action has to take place in userspace then there has to be some way
> to pass the appropriate information on.
>
> From my point of view, it does not matter whether the appropriate
> manipulations take place in the module or in userspace. I merely want to
> point out that the information does not come from the Vendor:Product
> number, but from a specific query which takes place after the module is in
> control and is sending commands to the camera. And, if the manipulation is
> done in userspace then the information has to be passed on, too.
>
> Theodore Kilgore

The use of the buffer flags makes the life easier as this flag 
is read for every image. So we can solve for the flip/rotation 
issues with the help of two new buffer flags: V4L2_BUF_FLAG_NEEDS_HFLIP 
and V4L2_BUF_FLAG_NEEDS_VFLIP.

A driver has to set them properly. Does the rotation or flip(s) 
apply to every image (e.g. sensor upside down) or change with frames
(e.g. Genesys webcams), that no more matters .
I can do the patch these days.
I do not remember if there is h/v flip functions in the libv4l, 
maybe they have to be added.

Regards,
Nol

 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