Hello Laurent, On Mon, Mar 1, 2010 at 3:57 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > I don't think it should matter which API (the base one or the extended one) > you use for controls, be they private, standard or whatever. I don't see a > reason for disallowing some controls to be used through one or the other API. I would generally agree. My original belief was that the extended control API was designed to be a superset of the older API and that it could be used for both types of controls. Imagine my surprise to find that private controls were specifically excluded from the extended control interface. >> I can change v4l2-ctl to use g_ctrl for private controls if we think >> that is the correct approach. But I didn't want to do that until I >> knew for sure that it is correct that you can never have a private >> extended control. > > Do we have extended *controls* ? All I see today is two APIs to access > controls, a base *control API* and an extended *control API*. G_CTRL/S_CTRL > should always be available to userspace. If you want to set a single control, > the extended API isn't required. The MPEG controls count as "extended" controls, since they provide the ability for grouping controls and modifying the values for multiple controls in an atomic manner. It's worth noting that I actually did track down the regression in v4l2-ctl, and the fix ended up being pretty simple (although it took a couple of hours to understand the code and nail down the proper fix): http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/142ae5aa9e8e It's kind of annoying that I have to tell my client that the ability to query/update private controls using v4l2-ctl has been completely broken for six months, but it seems like that is where we are at. 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
