Hi Peter,
On Friday 07 October 2011 06:54:48 Peter Zotov wrote:
> Hello.
>
> I have an h.264 encoding webcam, and I am trying to make it
> work. Currently, it outputs a valid h.264 stream, but each frame
> is compressed to ~12K of data, resulting in a very distorted, but
> still barely recognizable image. I suppose that some of the XU controls
> are responsible for the encoding quality, and they're in some extreme
> position by default.
>
> The webcam is "046d:0828 Logitech, Inc. HD Webcam B990".
>
> Here are the XU descriptors (whole `lsusb -v' is 52K long, and I'm not
> sure if I really should post it to the list):
Messages are currently limited to 75kB. You can also post the descriptors
compressed, or send them privately to me.
[snip]
> I've googled all the GUIDs, and it turned out that first four of them
> also appear in lsusb listings for non-encoding webcams as well. So, I
> decided that some of the other three contain the quality control. (It
> may not be true, of course, but that's what I will start with.) They
> have 19 different controls, apparently.
>
> Now, I am trying to tune some of these with UVC, with no success. Here
> is the relevant code:
>
> ----%<----%<----%<----%<----%<----%<----
> void init_controls()
> {
> struct uvc_xu_control_mapping mapping = {
> .id = XU_START,
> .name = "XU control",
> .selector = 1,
> .size = 1,
> .offset = 0,
> .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
> .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> };
>
> guid_to_byte_array("{a032c549-154f-fc4c-908a-5bce154b1cea}",
> mapping.entity);
>
> if(ioctl(fd, UVCIOC_CTRL_MAP, &mapping) < 0) {
> fprintf(stderr, "Cannot add control: %d, %s\n",
> errno, strerror(errno));
> exit(EXIT_FAILURE);
> }
> }
> ----%<----%<----%<----%<----%<----%<----
>
> (The `guid_to_byte_array' function was taken from libwebcam
> sources. Handcrafting the GUID with proper endianness gives
> the same result).
>
> It outputs: Cannot add control: 2, No such file or directory
>
> I've examined USB bus transactions. They include a control `request'
> and an interrupt `reply'.
>
> The control frame is here:
> bmRequestType: 0x21
> bRequest: 1
> wValue: 0x0200
> wIndex: 1
> wLength: 26
>
> This is somewhat strange. Per sect. 4.2.2.4 of UVC1.1 spec,
> bmRequestType=0x21 and bRequest=1 indicate a SET_CUR transfer.
> wValue of 0x0200 addresses selects control 2 instead of 1 (through
> this is still in range), and wIndex selects XU 1 (while my one
> has bUnitID of 8).
wIndex selects the interface, and wValue the control. This request is a
SET_CUR request on the UVC video commit control. It got sent by a
uvc_commit_video() call, either from uvc_video_resume() if the camera got
resumed or from uvc_video_enable() if the driver received a VIDIOC_STREAMON
call.
> Also, I do not understand at all what does the
> data transmitted means:
>
> 00:00:01:01:00:00:00:00
> 00:00:00:00:00:00:00:00
> 32:00:00:60:09:00:00:0c
> 00:00
>
> The reply contains a -ENOENT (-2) code, as shown by Wireshark.
>
> Using different GUID's or different selectors does not change
> anything.
>
> What am I doing wrong here?
I'm not sure exactly what you're doing wrong. Setting the uvcvideo trace
parameter to 0xffff might give you more information.
On a side note, if you're using a recent kernel, you should use
UVCIOC_CTRL_QUERY. This will let you query a UVC control directly without
going through mappings. That's much easier when experimenting with XU
controls.
--
Regards,
Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
