Re: Adding a control for Sensor Orientation

["Hans Verkuil" <hverkuil@xs4all.nl>]

> On Mon, 16 Feb 2009 12:01:14 +0100 (CET)
> "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
>
>> Anyone can add an API in 5 seconds. It's modifying or removing a bad
>> API that worries me as that can take years. If you want to add two
>> bits with mount information, feel free. But don't abuse them for
>> pivot information. If you want that, then add another two bits for
>> the rotation:
>>
>> #define V4L2_BUF_FLAG_VFLIP     0x0400
>> #define V4L2_BUF_FLAG_HFLIP     0x0800
>>
>> #define V4L2_BUF_FLAG_PIVOT_0   0x0000
>> #define V4L2_BUF_FLAG_PIVOT_90  0x1000
>> #define V4L2_BUF_FLAG_PIVOT_180 0x2000
>> #define V4L2_BUF_FLAG_PIVOT_270 0x3000
>> #define V4L2_BUF_FLAG_PIVOT_MSK 0x3000
>
> Hi,
>
> HFLIP + VFLIP = PIVOT_180
>
> then
>
> #define V4L2_BUF_FLAG_PIVOT_180 0x0c00

This makes it impossible for an application to see the difference between
an upside-down mounted sensor and a 180-degrees pivoted camera. In
addition, there may be sensors that are not upside-down, but only
V-flipped (or only H-flipped).

All this seems so simple, but it really isn't. This is something for an
RFC, posted and discussed both here and at least the linux-omap list, as
the input from the people who are working on those embedded systems will
be very valuable.

And what about output devices? E.g. LCDs? These too can be mounted
upside-down or rotated. You won't encounter this situation on a PC, but it
is another matter in the embedded space. Any API should by preference be
usable both for capture and output.

Regards,

        Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG