From: Matt L. <mat...@gm...> - 2008-09-09 14:35:29
|
<addressing v4l2 design> On Tue, Sep 9, 2008 at 4:16 AM, Antonio Garrido Carrillo <aga...@de...> wrote: > I was thinking about a new design for controls because, as indicated in v4l2 > specification, > different devices have different controls available, and furthermore, the > range of possible values > vary from device to device. Then, if I write a parameters class, which is te > range of values? > default value? or even, which are the controls associated with current > input? This is all very similar to the vidl2_dc1394_istream class I wrote. That stream uses libdc1394 to control live capture from IEEE 1394 cameras. One key difference is that this library is based on a published standard describing the set of parameters to be used by compliant cameras. I'm not sure how standard or constrained the parameters are for v4l2. However, I think a similar design will work. The vidl2_dc1394_istream class does all the work interfacing with libdc1394. To open a stream you pass it a vidl2_iidc1394_params object. In this case the parameters struct follows the IIDC standard and is not specific to libdc1394 (the same params might be used in the future with a Windows 1394 camera driver). There is another struct named valid_options contained within vidl2_iidc1394_params. The vidl2_dc1394_istream has a static method to probe the bus for available cameras and stores the camera properties (like which options the camera supports) in the valid_options class. The user can then generate a valid set of parameters from this information. It's still a work in progress, but what I have seems to work. The key idea is a parameters class that holds all the values but does no work, and an istream that configures itself from the parameters and does all the work. We should probably standardize this a bit more for all vidl2 streams. For now I think you can check in the code as it is (I've already checked in your additions to vidl2_convert.cxx). You can adjust the design over time, when you have time. Hopefully we will work out a standard way of handling parameters at some point Thanks, Matt |