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

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

> > 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.

Laurent Pinchart

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