Hi all,
For the si4713 FM transmitter driver from Eduardo we need to add support for
string controls so that the user can set things like the RDS Program Name.
The v4l2_ext_control struct has been designed with the possibility of things
like this in mind, so adding this isn't very difficult. There are a few
details that need to be sorted out first, though.
The struct looks like this right now:
struct v4l2_ext_control {
__u32 id;
__u32 reserved2[2];
union {
__s32 value;
__s64 value64;
void *reserved;
};
} __attribute__ ((packed));
For string controls we need to change it to this:
struct v4l2_ext_control {
__u32 id;
__u32 length;
__u32 reserved2;
union {
__s32 value;
__s64 value64;
char *string;
};
} __attribute__ ((packed));
The new length field is setup by the caller and contains the size in bytes
of the memory that the string field points to. This length will be used as
well by any future pointer control type, so it is not string specific. Note
that for string controls the length has to be strlen(string) + 1 to make
room for the terminating zero.
An added bonus is that we can use the length field in v4l2-compat-ioctl32.c
in order to do the right pointer transformation from 32 to 64 bits since
length is only non-zero for pointer types.
While it is possible to do a copy_from_user in v4l2-ioctl.c for the string
in a string control I have decided not to do this. For any pointer control
it is the driver that will have to do this step. The reason is that there
is no limit on these lengths, so rather than copying it to a temporary
piece of kernel memory and then again copying it in the driver to whatever
the final destination is, I think it is much more efficient to just let the
driver handle it.
We also need a new string type, of course: V4L2_CTRL_TYPE_STRING.
There is one remaining problem: how to determine how big the string memory
has to be? When retrieving a string control the application has to know how
much memory to allocate for the result. Or at the minimum it has to know
when it didn't allocate enough memory.
The first part of the solution is to utilize the minimum and maximum fields
in v4l2_queryctrl: these can be set to the minimum and maximum length of
the string control. This can be useful when creating a GUI control element
in that the GUI knows how to present the string control and to implement
simple input validation. The maximum value can also be used to allocate
sufficient memory when retrieving a string control. In case there is no
maximum (other than the amount of available memory) the maximum field can
be left at 0. I am not sure whether the min and max fields should refer to
the string length or the memory size. The latter is one higher due to the
terminating zero. I think I prefer the string length as that makes more
sense from a GUI perspective (which is really what v4l2_queryctrl is all
about).
I see no use for the default_value and step fields, so these should be left
at 0.
The second part of the solution is that when retrieving a string control the
length field is set by the driver to the minimum required length if the
original length was too short. In that case the g_ext_ctrls ioctl returns
ENOSPC as error and it is up to the application to re-allocate enough
memory and retry the ioctl. Setting length to 0 initially will always force
an ENOSPC error and can be used to discover the length up front.
I think that this is a reasonable solution.
An initial implementation is in my v4l-dvb-str tree (1). This does not
contain the v4l2_queryctrl and ENOSPC changes. I'm waiting for feedback to
this RFC before I implement that.
If there are no comments, then I'll finalize this next weekend or the
weekend after that.
Regards,
Hans
1) http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-str
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
