On Tue, Feb 23, 2010 at 2:53 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> Control enumeration is actually working fine. The queryctrl does >> properly return all of the controls, including my new private control. > > OK. So the problem is that v4l2-ctl uses G/S_EXT_CTRLS for non-user controls, > right? Why not change v4l2-ctl: let it first try the EXT version but if that > fails with EINVAL then try the old control API. For what it's worth, I actually bisected the v4l2-ctl.cpp, and found out the breakage got introduced in rev 12546: == v4l2-ctl: add support for string controls From: Hans Verkuil <hverkuil@xxxxxxxxx> Add support for string controls to v4l2-ctl. Also refactor the code to generalize the handling of control classes. Priority: normal == And this change breaks the v4l2-ctl application not just with my driver but with *any* of the drivers which have private controls implemented in g_ctrl or s_ctrl (including bttv, saa7134, and pwc) The root of the issue is that private controls are not considered "user controls". Hence when getting or setting the control, the v4l2-ctl app will always insist on attempting to use the g_ext_ctrls/s_ext_ctrls ioctl calls, even though the underlying driver doesn't have them implemented as extended controls. The enumeration of all of control values (using the "-l" argument) does include the private controls properly because the logic is written such that it always uses g_ctrl for all cases where the control ID >= V4L2_CID_PRIVATE_BASE. I guess I'll see whether I can rework the logic a bit such that the set/get routines work in a comparable manner to the routine to enumerate all the controls. I would prefer to avoid making the g_ext_ctrls ioctl() call and then retrying it as g_ctrl if it fails, since that will cause errors to be printed to the screen (due to the abstraction of doioctl() function) and is generally a bad practice. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
