Lots of snipping below so I hope I get the attributions correct.
On Monday 16 February 2009, Hans Verkuil wrote:
>
> We are talking about a core change, so some careful thought should go into
> this.
Agreed, a few days or even weeks spent getting the right solution is far
better than having to update lots of drivers and apps if we get it wrong.
>
> > So Adam, kilgota, please ignore the rest of this thread and move forward
> > with the driver, just add the necessary buffer flags to videodev2.h as
> > part of your patch (It is usually to submit new API stuff with the same
> > patch which introduces the first users of this API.
>
> Don't ignore it yet :-)
>
I've tried twice to write some code when I thought the discussion had died
down - I'll wait a while before attempting version 3.
> Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> > I welcome libv4l patches to use these flags.
Olivier Lorin submitted a patch to use the flags to support the 180 degree
rotation - it was pretty trivial but
a) didn't allow v4lconvert_flags to over-ride it to support kernels that don't
specify behaviour for those cameras
b) only coped with HFLIP and VFLIP both being set
Given an agreed solution I intend to fix both of those problems.
> Hans Verkuil wrote:
> > I think we have to distinguish between two separate types of data: fixed
> > ('the sensor is mounted upside-down', or 'the sensor always requires a
> > hflip/vflip') and dynamic ('the user pivoted the camera 270 degrees').
> >
Agreed they are different cases that potentially need different handling
> > The first is static data and I think we can just reuse the existing
> > HFLIP/VFLIP controls: just make them READONLY to tell libv4l that libv4l
> > needs to do the flipping.
> >
> > The second is dynamic data and should be passed through v4l2_buffer since
> > this can change on a per-frame basis. In this case add two bits to the
> > v4l2_buffer's flags field:
I'm not sure how Olivier Lorin's Genesys gl860 case should be handled in this
scenario - It feels to me that this should be treated as the sensor being
mounted upside down when it is turned away from the user as it is due to a
hardware limitation that the picture is upside down in that case and the user
would want libv4l to fix it - pivoting I see as being more a case of a user
creative activity and automatically correcting it isn't necessarily good. The
gl860 case is clearly dynamic data though.
On Monday 16 February 2009, Trent Piepho wrote:
> HFLIP and VFLIP are only good for 0 and 180 degrees. 90 and 270 isn't the
> same as flipping.
Agreed - but I think 90 and 270 will only apply to the user pivot case and
HFLIP / VFLIP only to the sensor mounting. The fact that HFLIP + VFLIP ==
pivot 180 should probably be ignored. Some of the sq905 camera variants
provide examples of the sensor data being VFLIPed but not HFLIPed.
On Monday 16 February 2009, Hans de Goede wrote:
>
> I agree that we have static and dynamic camera properties, and that we may
> want to have 2 API's for them. I disagree the control API is the proper API
> to expose static properties, many existing applications will not handle
> this well.
I certainly agree that re-using the existing controls doesn't seem like a good
idea - it seems to combine the case of "the user made a creative decision to
produce flipped video" with "this hardware always creates flipped video so
please fix it" If the sensor mounting is going to go in a control then it
ought to be a new one and I rather see just 1 control with 2 bits as I
wouldn't want to see a camera be able to tell us only part of the info, that
just complicates the code unnecessarily. Also having the info possibly
available via 2 different routes is bound to cause problems.
Where does all of that leave us?
We need to decide if sensor mounting should be considered static info - if it
should then putting it in a new control seems reasonable. The presence of
that control then definitively indicates if the driver is providing this
info. If we say that the gl860 case means this is dynamic info (which is the
way I'm leaning at the moment) then using 2 bits of buffer flags seems the
best option as dynamic info shouldn't be in controls.
Unless anyone has evidence to the contrary we don't yet know of any cameras
that provide pivot info. If any do it is likely that they are in embedded
devices which may well make the info available via the input mechanism rather
than as part of the camera. If we do ever get pivot info it might even be
from some fancy camera mount that provides pitch, yaw and roll so it would be
premature to attempt to design for it now. Currently we know neither what
data might be available or how it might be used and the supply of suitable
crystal balls is limited.
--
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
