On Tue, Apr 6, 2010 at 9:44 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > 1) We don't have that information. > 2) It would make a simple scheme suddenly a lot more complicated (see > Andy's comments) > 3) The main interface is always the application's GUI through ioctls, not > sysfs. > 4) Remember that ivtv has an unusually large number of controls. Most > drivers will just have the usual audio and video controls, perhaps 10 at > most. > > Strife for simplicity. I'm not sure whether we want to have this in sysfs > at all. While nice there is a danger that people suddenly see it as the > main API. And Markus' comment regarding permissions was a good one, I > thought. > > I think we should just ditch this for the first implementation of the > control framework. It can always be added later, but once added it is > *much* harder to remove again. It's a nice proof-of-concept, though :-) I tend to agree with Hans. We've already got *too many* interfaces that do the same thing. The testing matrix is already a nightmare - V4L1 versus V4L2, mmap() versus read(), legacy controls versus extended controls, and don't get even me started on VBI. We should be working to make drivers and interfaces simpler, with *fewer* ways of doing the same thing. The flexibility of providing yet another interface via sysfs compared to just calling v4l2-ctl just isn't worth the extra testing overhead. We've already got too much stuff that needs to be fixed and not enough good developers to warrant making the code more complicated with little tangible benefit. And nobody I've talked to who writes applications that work with V4L has been screaming "OMG, if only V4L had a sysfs interface to manage controls!" 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
