Hans,
2010/5/23 Hans Verkuil <hverkuil@xxxxxxxxx>:
> On Thursday 20 May 2010 16:42:01 Paulo Assis wrote:
>> Hi all,
>>
>> Below is a proposal for the file format to use when storing/restoring
>> v4l2 controls state.
>>
>> I've some doubts concerning atomically set controls and string
>> controls (see below)
>> that may be inducing me on error.
>> The format is intended to be generic enough to support any control
>> class so I hope
>> to receive comments for any special cases that I might have missed or
>> overlooked.
>> Don't worry about bashing on the proposal to hard I have a hard skin :-D
>>
>> Regards,
>> Paulo
>>
>> ---------- Forwarded message ----------
>> From: Hans de Goede <hdegoede@xxxxxxxxxx>
>> Date: 2010/5/20
>> Subject: Re: [RFC] V4L2 Controls State Store/Restore File Format
>> To: Paulo Assis <pj.assis@xxxxxxxxx>
>> Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>,
>> Martin_Rubli@xxxxxxxxxxxx
>>
>>
>> Hi Paulo,
>>
>> Clearly you've though quite a bit about this I had not realized
>> this would be this complex (with ordering issues etc.).
>>
>> This looks like a good proposal to start with to me, I think it
>> would be good to further discuss this on the linux-media list,
>> where other v4l devs can read it and chime in.
>>
>> Regards,
>>
>> Hans
>>
>>
>> On 05/20/2010 03:11 PM, Paulo Assis wrote:
>> >
>> > Hans,
>> > Below is the RFC with my proposed control state file format for
>> > store/restore functionality.
>> > I have several doubts, mostly regarding controls that must be set
>> > atomically with the extended control API.
>> > The main question is:
>> > How does an application know that a group of controls must be set atomically ?
>> > Is this reported by the driver or is it something that the application
>> > must know.
>> >
>> > Also for string controls, I've only seen two implementations on RDS
>> > controls, so I've set these with low precedence/priority order
>> > compared with other control types.
>> >
>> > Awaiting comments, bash it all you want :-)
>> >
>> > Regards,
>> > Paulo
>> > ______________________
>> >
>> > [RFC] V4L2 Controls State Store/Restore File Format
>> >
>> > VERSION
>> >
>> > 0.0.1
>> >
>> > ABSTRACT
>> >
>> > This document proposes a standard for the file format used by v4l2
>> > applications to store/restore the controls state.
>> > This unified file format allows sharing control profiles between
>> > applications, making it much easier on both developers and users.
>> >
>> > INTRODUCTION
>> >
>> > V4l2 controls can be divided by classes and types.
>> > Controls in different classes are not dependent between themselves, on
>> > the other end if two controls belong to the same class they may or may
>> > not be dependent.
>> > A good example are automatic controls and their absolute counterparts,
>> > e.g.: V4L2_CID_AUTOGAIN and V4L2_CID_GAIN.
>> > Controls must be set following the dependency order, automatic
>> > controls must be set first or else setting the absolute value may
>> > fail, when that was not the intended behavior (auto disabled).
>> > After a quick analyses of the v4l2 controls, we are left to conclude
>> > that auto controls are in most cases of the
>> > boolean type, with some exceptions like V4L2_CID_EXPOSURE_AUTO, that
>> > is of the menu type.
>> > So ordering control priority by control type seems logical and it can
>> > be done in the following order:
>> >
>> > 1-V4L2_CTRL_TYPE_BOOLEAN
>> > 2-V4L2_CTRL_TYPE_MENU
>> > 3-V4L2_CTRL_TYPE_INTEGER
>> > 4-V4L2_CTRL_TYPE_INTEGER64
>> > 5-V4L2_CTRL_TYPE_STRING
>
> I'm not sure whether the ordering is needed, it sounds more like a driver bug
> that you are trying to work around.
>
> When you retrieve the state of controls, then the value of the controls must be
> valid. So you should be able to set it later. There are some dependencies,
> for example selecting a particular MPEG video encoding might deactivate some
> controls and activate others. But the INACTIVE flag should be used to mark that,
> never the DISABLED flag. And you can still set inactive controls.
>
How would this work for controls like "Exposure, Auto" ?
In the cameras I've tested if we don't set it to manual first, changing
"Exposure (Absolute)" fails. Maybe it's a uvcvideo a bug, I'm not sure.
The same for "White Balance Temperature, Auto" and
"White Balance Temperature". They all return a EIO error.
> For controls not belonging to the user class I would store and restore them
> all using G/S_EXT_CTRLS. So for each class just get all controls that are both
> readable and writable and not disabled, then get or set them in one call.
>
I'll have to test at least camera class controls and see if this works.
> For the user class controls you can do the same, but if that fails, then you
> have to fallback to G/S_CTRL on a per-control basis.
>
I'll test this to!
> The main problem at the moment is that control handling stinks. Which is why
> I am working on a new control framework that will handle everything in the
> v4l core greatly simplifying drivers and providing a unified and consistent
> interface towards applications.
>
Will this bring any changes to the API, or is just at the core level ?
Best Regards,
Paulo
> Regards,
>
> Hans
>
>> >
>> > Button controls are stateless so they can't be stored and thus are out
>> > of the scope of this document.
>> > Relative controls are also in effect stateless, since they will always
>> > depend on their current state and thus can't be stored.
>> >
>> > There are also groups of controls that must be set atomically, so
>> > these need to be grouped together and properly identified when loading
>> > the controls state from a file.
>> >
>> > The proposed file format takes all of this into account and tries to
>> > make implementation of both store and restore functionality as easy as
>> > possible.
>> >
>> > FILE FORMAT
>> >
>> > The proposed file format is a regular text file with lines terminating
>> > with the newline character '\n'.
>> > Comments can be inserted by adding '#' at the beginning of the line,
>> > and can safely be ignored when parsing the file.
>> >
>> > FILE EXTENSION
>> >
>> > Although not much relevant, the file extension makes it easy to
>> > visually identify the file type and also for applications to list
>> > relevant files, so we propose that v4l2 control state files be
>> > terminated by the suffix: ".v4l"
>> >
>> > FILE HEADER
>> >
>> > The file must always start with a commented line containing the file
>> > type identification and the version of this document on which it is
>> > based:
>> >
>> > #V4L2/CTRL/0.0.1
>> >
>> > Additionally it may contain extra information like the application
>> > name that generated the file and for usb devices the vid and pid of
>> > the device to whom the controls relate in hexadecimal notation:
>> >
>> > APP_NAME{"application name"}
>> > VID{0x00}
>> > PID{0x00}
>> >
>> > CONTROLS DATA
>> >
>> > The controls related data must be ordered by control type and for each
>> > type the ordering must be done by control ID. Ordering by control ID
>> > will also group the controls by class.
>> > The exception to the above rule are controls that need to be set
>> > atomically, these must be grouped together independent of their type.
>> >
>> > Each control must have is data set in a single line:
>> > ID{0x0000};CHK{min:max:step:def};EXT{[0|>0}=VAL{value}
>> >
>> > The ID key is the control v4l2 id in hex notation.
>> > The CHK key is used to match the control stored in file to the one we
>> > are trying to set on the device.
>> > Controls on different devices may have identical ID's but is unlikely
>> > that the correspondent values remain the same. All values are in
>> > decimal notation and correspond to the controls reported values.
>> > EXT indicates if the control must be set atomically, if it is set to a
>> > value higher than zero, then the next controls must be searched for
>> > identical EXT values, all of them shall then be grouped and set using
>> > the extension control mechanism, VIDIOC_S_EXT_CTRLS.
>> > Controls with a EXT value of 0 can be set individually with a regular
>> > VIDIOC_S_CTRL.
>> > The VAL key contains the control state in decimal form.
>> --
>> 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
>>
>>
>
> --
> Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
>
--
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
