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

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

> >> 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