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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
