Hi Sakari,
On Friday 19 December 2008 09:22:13 Sakari Ailus wrote:
> Hello,
>
> I'm wondering how to use extended driver private controls. Controls
> starting from V4L2_CID_PRIVATE_BASE do not work (check_ext_ctrls() in
> v4l2-ioctl.c:
>
> ---
> /* V4L2_CID_PRIVATE_BASE cannot be used as control class
> when using extended controls.
> Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
> is it allowed for backwards compatibility.
> */
> if (!allow_priv && c->ctrl_class == V4L2_CID_PRIVATE_BASE)
> return 0;
> ---
>
> check_ext_ctrls() is called from __video_do_ioctl() with allow_priv set
> to zero for extended controls.
>
> I know I could create another control class and define that in
> videodev2.h but that feels like a bit of overkill for two integer
> controls... :-) Are there any alternatives if I would like my private
> controls to be available through extended controls as well?
Good question. The situation is as follows: the whole PRIVATE_BASE stuff is
a really bad design. Controls are part of the public API of V4L2 and as
such should be documented in the v4l2 spec and clearly defined. Using
PRIVATE_BASE, however, means that different drivers will have controls with
the same ID but that do different things. Furthermore, there is no way to
classify controls like that (e.g. is it a general user control, an mpeg
control, a camera control?).
So when I designed the extended controls API I wanted to force developers to
use a different approach. If you look at videodev2.h you will see that a
control ID is divided up in bitranges:
Bits 28-31 are for flags (currently on V4L2_CTRL_FLAG_NEXT_CTRL is used).
Bits 16-27 denote the class (USER, MPEG and CAMERA are currently defined).
Bits 0-15 are the control ID within the class.
In addition there is the guarantee that bits 0-15 can never be all 0 for any
valid control.
The current PRIVATE_BASE stuff doesn't really fit in any of this.
What I did to support private controls is to allow drivers to add their own
controls to the various classes, as long as the low 16 bits are >= 0x1000.
You add them to videodev2.h (see the CX2341X private controls), and you just
pick a starting base such as 'V4L2_CTRL_CLASS_MPEG | 0x1100'.
This way the controls are together in one header, they have unique IDs, and
you can assign them to a specific class.
Unfortunately, there are three obstacles:
1) Many apps and drivers still don't use V4L2_CTRL_FLAG_NEXT_CTRL and only
know about PRIVATE_BASE.
2) It's a bit tricky to implement correct control handling in v4l drivers.
3) Documenting is a bit hard at the moment since the V4L2 spec is maintained
elsewhere.
Since drivers that implement VIDIOC_S_EXT_CTRLS are generally new drivers
I've blocked the use of PRIVATE_BASE with that ioctl, hopefully encouraging
driver writers to properly define their controls in videodev2.h, document
them in the v4l2 spec and to implement V4L2_CTRL_FLAG_NEXT_CTRL handling.
That doesn't address the fact that many applications still don't know about
it. It depends on what sort of environment the driver will be used in
whether you need to add duplicate PRIVATE_BASE controls for the time being.
When I created the MPEG controls I didn't make duplicates since any
application that needed to support MPEG had to make changes anyway. In the
case of embedded platforms you probably have a similar situation. But if
you make a simple TV grabber driver, then many apps like xawtv or tvtime
only know about PRIVATE_BASE controls. In that case the only solution is to
provide a duplicate set of PRIVATE_BASE controls.
The other disadvantage is that it is more work at the moment. I hope to
address that in the coming months by adding proper control support to the
v4l2 framework. I have several ideas for this and now that v4l2_device and
v4l2_subdev are both in it should be quite feasible. If it all works as I
hope then the driver control support will become much, much simpler.
The final problem relates to the fact that the documentation is currently
maintained out-of-tree. We want to move it all to the repository in 1-2
months from now and that should make it much easier to update the docs when
you add new private controls.
So, to summarize: for new drivers I recommend using V4L2_CTRL_FLAG_NEXT_CTRL
and adding the private controls to videodev2.h and to prepare documentation
for inclusion with the v4l2 spec. If you really must support old apps, then
you might have to make duplicate PRIVATE_BASE controls (yuck!), but I hope
that won't be necessary.
It's not an ideal situation, but I hope that it will improve considerably in
the next 3-6 months.
Regards,
Hans
PS: please note that there are several control utility functions in
v4l2-common.c! These might prove useful.
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
