[Linux-uvc-devel] Accessing Extension Units

[Laurent Pinchart]

Hi Nathanael,

On Friday 17 August 2007, Nathanael Galpin wrote:
> Hi
>
> I'm testing some cameras right now, and I'd like to be able to access
> the controls in the camera's extension unit. I've spent some time this
> last week looking at the driver and attempting to add the controls in,
> but I haven't been successful. What steps do I need to take to get the
> driver to recognize these controls?

You will have to modify the uvc_ctrls and uvc_ctrl_mappings arrays in 
uvc_video.c

Add an entry to uvc_ctrls with the following fields:

- entity	entity GUID
- selector	UVC control selector (the identifier to be used in requests)
- index		UVC control index in extension unit descriptor bmControls bitfield
- size		UVC control size in bytes
- flags		UVC control flags (see existing controls for examples)

Then add one or more entries to uvc_ctrl_mappings to map the UVC control to 
V4L2 control(s). A single UVC control can be mapped to several V4L2 controls. 
The fields are:

- id		V4L2 control ID
- name		V4L2 control name
- entity	associated UVC control entity GUID
- selector	associated UVC control selector
- size		V4L2 control size in bits
- offset	V4L2 control offset in bits from the UVC control base (*)
- v4l2_type	V4L2 control type
- data_type	V4L2 control field type in the UVC control (**)

(*) A single UVC control can be mapped to several V4L2 controls. For instance, 
a pan/tilt 32-bit (4 bytes) UVC control made of a 16-bit pan value followed 
by a 16-bit tilt value could be mapped to a 16-bit V4L2 pan control and a 
16-bit V4L2 tilt control. The first V4L2 control's offset would be equal to 0 
and the second V4L2 control's offset would be equal to 16.

(**) The currently supported values are UVC_CTRL_DATA_TYPE_SIGNED and 
UVC_CTRL_DATA_TYPE_UNSIGNED. They are used to perform sign extension when 
mapping from signed UVC controls to signed V4L2 controls if the control size 
are not identical.

Finally, modify uvcvideo.h and set V4L2_CID_PRIVATE_LAST equal to your last 
private V4L2 control identifier.

> So far I've added a GUID for the camera's extension unit, as well I've
> added entries to the uvc_ctrl and uvc_ctrl_mappings lists. I've written
> a test application using the V4L2 API to enumerate the controls on the
> camera, and it does see a new control,

Sounds good so far.

> but I'm not able to use that control. It seems like I'm missing something to
> associate the control with the camera it belongs to.

What are the symptoms ? Do you get an error when you try to access the 
control ? If so, what error (errno) do you get ?

If you can enumerate the control on your device instance, there should be 
no "association" problem. Try to raise the trace level to 255 (modprobe 
uvcvideo trace=255 or echo 255 > /sys/modules/uvcvideo/parameters/trace) and 
check the kernel log (dmesg) for error messages after you try to access the 
control from your userspace application.

> Hopefully that makes sense, at this point I'm not looking for a really
> elegant solution, I'd just like to hard code it into the driver to do
> some testing.

The elegant solution is in the dynctrls branch. The idea is to let a userspace 
application configure the driver to add new control mappings at runtime. I 
have to bring the branch up to date, as I haven't worked on it for some time.

Best regards,

Laurent Pinchart