By Date: <-- -->
By Thread: <-- -->

RFC: V4L2 MPEG Encoding API: Part 1 (second version)

On Monday 22 May 2006 23:24, Laurent Pinchart wrote:
> > > How would you then group a pan and a tilt control into a single
> > > request ?
> >
> > It's not that it may not be a good idea to allow these controls
> > with the ext_control mechanism, it's just that a) I don't have the
> > time to implement that, b) I'm no expert on camera controls so I
> > really can't tell if that is the best way to go and c) I have the
> > suspiscion based on what little I've seen of webcam drivers that it
> > might be a good idea to take a wider view and see if making more
> > extensive use of this new mechanism for implementing atomic
> > controls and combining generic and device-specific controls
> > regarding camera devices might not be a good idea.
> >
> > In other words, my suggestion would be that you research this
> > further and then write an RFC. Given the need for atomic pan/tilt
> > it may turn out that having them as user controls was not such a
> > good idea and that having a bunch of extended camera controls is
> > much better. But that's not for me to decide. Being able to use the
> > same controls with both the user and extended ioctls just strikes
> > me as very confusing.
>
> That's interesting, because I thought we wanted controls to be
> accessible both through the 'user' (S_CTRL) and 'extended'
> (S_EXT_CTRLS) ioctls.
>
> Devices expose hardware controls. Drivers expose V4L2 controls. Some
> controls are mapped 1:1 (contrast, saturation, ...), others are
> mapped 1:N (single hardware control, multiple V4L2 controls - i.e.
> pan/tilt, red/blue gains for white balance, MPEG compression
> parameters, ...). The type of mapping depends on the hardware: some
> webcams might have two separate control registers to hold to red and
> blue gains, while some others might have a single control register.
>
> My idea was to expose all controls through both APIs. If an
> application sets both red and blue gains with a single call to
> S_EXT_CTRLS, a device that implements separate control registers will
> receive two hardware requests from the driver, while a device that
> implements a single control register will receive a single request.
> If an application sets the red gain only, a device that implements
> separate control registers will receive a single hardware request to
> modify the red gain, while a device that implements a single control
> register will receive a single hardware request with the new red gain
> and old blue gain values.
>
> The V4L2 layer could even convert all calls to G_CTRL/S_CTRL to
> G_EXT_CTRLS/S_EXT_CTRLS for drivers that support those calls. For
> drivers that don't support the atomic ioctls, the V4L2 layer could
> split them in multiple G_CTRL/S_CTRL calls. That way applications
> using the new ioctls would work with old drivers, and applications
> using the old ioctls would work with new drivers. There might be some
> problems with that approach, I'm open to comments.

The definition of a user control that I use (and that I was told by 
others) is that user controls are completely independent from one 
another, that they can be set at any time and that applications don't 
set them for you, but that the user sets them (well, the app may store 
the last set value and restore them the next time, but that's about 
it).

These restrictions are lifted for extended controls: these controls 
basically replace the old ioctl that receives a struct because it is 
pretty much impossible to define a struct that is able to cater for all 
variations. That it is also an easy way to expose these settings in an 
application as a GUI element is a nice bonus.

I think it is good to keep these two use cases separate. For a user 
control that conforms to the above definition there is no point to use 
them with the extended control API since there is no need for atomicity 
or anything else. If there is such a need, then that control is perhaps 
at the wrong place and should be turned into an extended control for 
webcams. Keeping support for the old user control as legacy, probably.

To illustrate another difference between the two: some programs like 
xawtv make user controls available to the user. It makes no sense to do 
the same for the extended controls: for those you would need a 
dedicated dialog that can take care of the various dependencies between 
the ext. controls.

Regards,

	Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list