On Monday 22 February 2010 22:43:58 Devin Heitmueller wrote: > On Mon, Feb 22, 2010 at 4:41 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > I am still planning to continue my work for a general control handling > > framework. I know how to do it and it's just time that I lack. > > > > Converting all drivers to support the extended control API is quite complicated > > since the API is fairly complex (esp. with regard to atomicity). In this case > > my advice would be to support extended controls only where needed and wait for > > this framework before converting all the other drivers. > > Hans, > > I have no objection to holding off if that's what you recommend. The > only reason we got onto this thread was because the v4l2-dbg > application seems to implicitly assume that *all* private controls > using V4L2_CID_PRIVATE_BASE can only be accessed via the extended > control interface, meaning you cannot use the utility in conjunction > with a driver that has a private control defined in the the > VIDIOC_G_CTRL function. Ah, that's another matter. The original approach for handling private controls is seriously flawed. Drivers that want to use private controls are strongly encouraged to use the extended control mechanism for them, and to document those controls in the spec. Actually, it is not so much the extended control API that is relevant here, but the use of V4L2_CTRL_FLAG_NEXT_CTRL in VIDIOC_QUERYCTRL to enumerate the controls. Unfortunately, the current support functions in v4l2-common.c to help with this are pretty crappy, for which I apologize. Regards, Hans > > Devin > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
