Fwd: uvcvideo extension controls
-- Forwarded message --
From: Paulo Assis <pj.as...@gmail.com>
Date: 2017-04-20 12:04 GMT+01:00
Subject: uvcvideo extension controls
To: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>, aUDIo
<djaudio...@gmail.com>
Laurent Hi,
I've just noticed that uvcvideo extension controls no longer work
properly, for instance for a logitech c930e I have the
'UVC_GUID_LOGITECH_PERIPHERAL':
VideoControl Interface Descriptor:
bLength28
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID11
guidExtensionCode {212de5ff-3080-2c4e-82d9-f587d00540bd}
bNumControl 3
bNrPins 1
baSourceID( 0) 10
bControlSize3
bmControls( 0) 0x00
bmControls( 1) 0x41
bmControls( 2) 0x01
iExtension 0
when I try to map or query the controls associated with this GUID
(like the LED control) I get a ENOENT error, the same applies for
other GUID, although some, like the h264 extension, will work just
fine:
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID12
guidExtensionCode {41769ea2-04de-e347-8b2b-f4341aff003b}
bNumControl11
bNrPins 1
baSourceID( 0) 3
bControlSize2
bmControls( 0) 0x07
bmControls( 1) 0x7f
iExtension 0
'uvcdynctrl --device=/dev/video1 --get_raw=12:1' returns without error:
query control size of : 46
query control flags of: 0x3
These mappings were working just fine in previous kernels, did
something changed in the uvc extension control API, or do you think
this is just a bug in the driver?
Regards,
Paulo
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi, 2014-11-04 23:32 GMT+00:00 Sakari Ailus sakari.ai...@iki.fi: Sakari Ailus wrote: yavta does, for example, print both the monotonic timestamp from the buffer and the time when the buffer has been dequeued: URL:http://git.ideasonboard.org/yavta.git $ yavta -c /dev/video0 should do it. The first timestamp is the buffer timestamp, and the latter is the one is taken when the buffer is dequeued (by yavta). I've done exaclty this with guvcview, and uvcvideo timestamps are completly unreliable, in some devices they may have just a bit of jitter, but in others, values go back and forth in time, making them totally unusable. Honestly I wouldn't trust device firmware to provide correct timestamps, or at least I would have the driver perform a couple of tests to make sure these are at least reasonable: within an expected interval (maybe comparing it to a reference monotonic clock) or at the very least making sure the current frame timestamp is not lower than the previous one. Regards, Paulo Removing the uvcvideo module and loading it again with trace=4096 before capturing, and then kernel log would provide more useful information. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Paulo Assis wrote: 2014-11-04 23:32 GMT+00:00 Sakari Ailus sakari.ai...@iki.fi: Sakari Ailus wrote: yavta does, for example, print both the monotonic timestamp from the buffer and the time when the buffer has been dequeued: URL:http://git.ideasonboard.org/yavta.git $ yavta -c /dev/video0 should do it. The first timestamp is the buffer timestamp, and the latter is the one is taken when the buffer is dequeued (by yavta). I've done exaclty this with guvcview, and uvcvideo timestamps are completly unreliable, in some devices they may have just a bit of jitter, but in others, values go back and forth in time, making them totally unusable. Honestly I wouldn't trust device firmware to provide correct timestamps, or at least I would have the driver perform a couple of tests to make sure these are at least reasonable: within an expected interval (maybe comparing it to a reference monotonic clock) or at the very least making sure the current frame timestamp is not lower than the previous one. I can add that to the uvcvideo driver, but I'd first like to find out whether the device timestamps are really unreliable, or if the problem comes from a bug in the driver's timestamp conversion code. Could you capture images using yavta with an unreliable device, with the uvcvideo trace parameter set to 4096, and send me both the yavta log and the kernel log ? Let's start with a capture sequence of 50 to 100 images. Removing the uvcvideo module and loading it again with trace=4096 before capturing, and then kernel log would provide more useful information. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
I've add to change guvcview so that it now generates it's own monotonic timestamps, kernel timestamps (uvcvideo at least), caused a similar problem, e.g: I would get a couple of frames with correct timestamps, then I would get at least one with a value lower than the rest, this caused playback to stutter. I didn't had time to check the cause, but it has been like this for quite some time now. Regards, Paulo 2014-11-04 12:42 GMT+00:00 Rémi Denis-Courmont r...@remlab.net: Le 2014-11-04 14:58, Sakari Ailus a écrit : Have you tried with a different application to see if the problem persists? Tried mplayer and cheese now, and it seems they are not affected, so it's an issue with vlc. I wonder why it doesn't like newer flags.. Ohwell, sorry for the noise. I guess the newer VLC could indeed pay attention to the monotonic timestamp flag. Remi, any idea? VLC takes the kernel timestamp, if monotonic, since version 2.1. Otherwise, it generates its own inaccurate timestamp. So either that code is wrong, or the kernel timestamps are. -- Rémi Denis-Courmont -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo fails on 3.16 and 3.17 kernels
Laurent hi, 2014-09-30 23:31 GMT+01:00 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Paulo, Thank you for investigation this. On Tuesday 30 September 2014 13:56:15 Paulo Assis wrote: Ok, so I've set a workaround in guvcview, it now uses the length filed if bytesused is set to zero. Anyway I think this violates the v4l2 api: http://linuxtv.org/downloads/v4l-dvb-apis/buffer.html bytesused - ..., Drivers must set this field when type refers to an input stream, ... without this value we have no way of knowing the exact frame size for compressed formats. And this was working in uvcvideo up until 3.16, I don't know how many userspace apps rely on this value, but at least guvcview does, and it's currently broken for uvcvideo devices in the latest kernels. It took me some time to debug the problem, and I think the problem is actually on guvcview's side. When dequeuing a video buffer, the application requeues it immediately before processing the buffer's contents. The VIDIOC_QBUF ioctl will reset the bytesused field to 0. While you could work around the problem by using a different struct v4l2_buffer instance for the VIDIOC_QBUF call, the V4L2 doesn't allow userspace application to access a queued buffer. You must process the buffer before requeuing it. I though this was why we requested multiple buffers. If this is true then using just one buffer is enough, also using multiple threads to process frame data seems useless in this case, since we need to process the buffer before queueing the next one. I thought one could request 4 buffers for mmap and do: VIDIOC_DQBUF data-buf[0] VIDIOC_QBUF driver queues-buf[1] process buf[0] VIDIOC_DQBUF data-buf[1] VIDIOC_QBUF driver queues-buf[2] process buf[1] VIDIOC_DQBUF data-buf[2] VIDIOC_QBUF driver queues-buf[3] process buf[2] VIDIOC_DQBUF data-buf[3] VIDIOC_QBUF driver queues-buf[0] process buf[3] Now if we need to process the buffer between VIDIOC_DQBUF and VIDIOC_QBUF, whats the point in using more than one buffer ? Regards, Paulo 2014-09-30 9:50 GMT+01:00 Paulo Assis pj.as...@gmail.com: I referring to the following bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362358 I've run some tests and after increasing verbosity for uvcvideo, I get: EOF on empty payload this seems consistent with the zero size frames returned by the driver. After VIDIOC_DQBUF | VIDIOC_QBUF, I get buf.bytesused=0 Testing with an eye toy 2 (gspca), everything works fine, so this is definitly related to uvcvideo. This happens on all available formats (YUYV and MJPEG) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo fails on 3.16 and 3.17 kernels
Laurent,
OK, I undersdant what I'm doing wrong now.
I don't see any other solution in order to follow the v4l2 api, than
to copy the mmap data into another buffer that will be used in frame
processing, and then requeue.
Guvcview processes frame data in several different threads and I don't
want to wait for processing to finish before requeing, I just want to
call the get_frame function from whathever thread and be done with it.
This solution however forces a mem copy that the mmap operation
intends to avoid.
Best regards,
Paulo
2014-10-01 12:05 GMT+01:00 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Paulo,
On Wednesday 01 October 2014 11:48:26 Paulo Assis wrote:
Laurent hi,
2014-09-30 23:31 GMT+01:00 Laurent Pinchart:
Hi Paulo,
Thank you for investigation this.
On Tuesday 30 September 2014 13:56:15 Paulo Assis wrote:
Ok,
so I've set a workaround in guvcview, it now uses the length filed if
bytesused is set to zero.
Anyway I think this violates the v4l2 api:
http://linuxtv.org/downloads/v4l-dvb-apis/buffer.html
bytesused - ..., Drivers must set this field when type refers to an
input stream, ...
without this value we have no way of knowing the exact frame size for
compressed formats.
And this was working in uvcvideo up until 3.16, I don't know how many
userspace apps rely on this value, but at least guvcview does, and
it's currently broken for uvcvideo devices in the latest kernels.
It took me some time to debug the problem, and I think the problem is
actually on guvcview's side. When dequeuing a video buffer, the
application requeues it immediately before processing the buffer's
contents. The VIDIOC_QBUF ioctl will reset the bytesused field to 0.
While you could work around the problem by using a different struct
v4l2_buffer instance for the VIDIOC_QBUF call, the V4L2 doesn't allow
userspace application to access a queued buffer. You must process the
buffer before requeuing it.
I though this was why we requested multiple buffers. If this is true
then using just one buffer is enough, also using multiple threads to
process frame data seems useless in this case, since we need to
process the buffer before queueing the next one.
I thought one could request 4 buffers for mmap and do:
VIDIOC_DQBUF data-buf[0]
VIDIOC_QBUF driver queues-buf[1]
process buf[0]
VIDIOC_DQBUF data-buf[1]
VIDIOC_QBUF driver queues-buf[2]
process buf[1]
VIDIOC_DQBUF data-buf[2]
VIDIOC_QBUF driver queues-buf[3]
process buf[2]
VIDIOC_DQBUF data-buf[3]
VIDIOC_QBUF driver queues-buf[0]
process buf[3]
That's certainly valid. However, if I'm not mistaken, after dequeuing buffer i
you immediately requeue the same buffer, not buffer i+1.
What you should do is queueing all buffers right before starting the stream (I
think you're doing fine there, but I haven't double-checked), and then, when a
buffer is available, perform the following sequence.
VIDIOC_DQBUF() - returns buffer i
process buffer i
VIDIOC_QBUF(buffer i)
You can perform processing in a different thread if needed, the important part
being not to requeue the buffer before userspace is done with it.
The bug that caused guvcview to stop functioning is in v4l2_core.c.
memset(vd-buf, 0, sizeof(struct v4l2_buffer));
vd-buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
vd-buf.memory = V4L2_MEMORY_MMAP;
ret = xioctl(vd-fd, VIDIOC_DQBUF, vd-buf);
if(!ret)
{
/*
* driver timestamp is unreliable
* use monotonic system time
*/
vd-timestamp = ns_time_monotonic();
/* queue the buffers */
ret = xioctl(vd-fd, VIDIOC_QBUF, vd-buf);
...
}
The VIDIOC_DQBUF call will return the correct bytesused value in vd-
buf.bytesused, but the VIDIOC_QBUF call then resets that value to 0.
As a quick workaround while you fix the buffer processing sequence, you can
copy vd-buf into a new local v4l2_buffer variable after calling VIDIOC_DQBUF,
and use that local variable in the VIDIOC_QBUF call. Note that you will still
violate the V4L2 API as you're not allowed to touch a buffer after requeuing
it, but it should hide the problem and get guvcview to display images again.
Now if we need to process the buffer between VIDIOC_DQBUF and
VIDIOC_QBUF, whats the point in using more than one buffer ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
uvcvideo fails on 3.16 and 3.17 kernels
I referring to the following bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362358 I've run some tests and after increasing verbosity for uvcvideo, I get: EOF on empty payload this seems consistent with the zero size frames returned by the driver. After VIDIOC_DQBUF | VIDIOC_QBUF, I get buf.bytesused=0 Testing with an eye toy 2 (gspca), everything works fine, so this is definitly related to uvcvideo. This happens on all available formats (YUYV and MJPEG) Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo fails on 3.16 and 3.17 kernels
Ok, so I've set a workaround in guvcview, it now uses the length filed if bytesused is set to zero. Anyway I think this violates the v4l2 api: http://linuxtv.org/downloads/v4l-dvb-apis/buffer.html bytesused - ..., Drivers must set this field when type refers to an input stream, ... without this value we have no way of knowing the exact frame size for compressed formats. And this was working in uvcvideo up until 3.16, I don't know how many userspace apps rely on this value, but at least guvcview does, and it's currently broken for uvcvideo devices in the latest kernels. Regards, Paulo 2014-09-30 9:50 GMT+01:00 Paulo Assis pj.as...@gmail.com: I referring to the following bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362358 I've run some tests and after increasing verbosity for uvcvideo, I get: EOF on empty payload this seems consistent with the zero size frames returned by the driver. After VIDIOC_DQBUF | VIDIOC_QBUF, I get buf.bytesused=0 Testing with an eye toy 2 (gspca), everything works fine, so this is definitly related to uvcvideo. This happens on all available formats (YUYV and MJPEG) Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo fails on 3.16 and 3.17 kernels
Yes, but disabling libv4l2 and accessing the driver directly, has the same effect. Also like I said, gspca works fine, even through libv4l2. So I'm pretty sure this is related to uvcvideo. My libv4l2 version is 1.2.0 and the reported problems with libv4l2 I've received relate to version 1.4.0 (debian), virtual formats (rgb3, bgr3, yu12, yv12) are not working with that version. Regards, Paulo 2014-09-30 14:12 GMT+01:00 Nicolas Dufresne nicolas.dufre...@collabora.com: Le 2014-09-30 04:50, Paulo Assis a écrit : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362358 I've run some tests and after increasing verbosity for uvcvideo, I get: EOF on empty payload this seems consistent with the zero size frames returned by the driver. After VIDIOC_DQBUF | VIDIOC_QBUF, I get buf.bytesused=0 Testing with an eye toy 2 (gspca), everything works fine, so this is definitly related to uvcvideo. This happens on all available formats (YUYV and MJPEG) Might be related to the libv4l2 bug I reported yesterday, are you using libv4l2 in these tests ? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo: logitech C920 resets controls during VIDIOC_STREAMON
Hi,
2014-03-05 23:01 GMT+00:00 William Manley w...@williammanley.net:
Hi All
I've been attempting to use the Logitech C920 with the uvcvideo driver.
I set the controls with v4l2-ctl but some of them change during
VIDIOC_STREAMON. My understanding is that the values of controls should
be preserved.
Minimal test case:
#include linux/videodev2.h
#include stdio.h
#include stdlib.h
#include fcntl.h
#include errno.h
#include string.h
#include unistd.h
#include sys/ioctl.h
#define DEVICE /dev/video2
int main()
{
int fd, type;
fd = open(DEVICE, O_RDWR | O_CLOEXEC);
if (fd 0) {
perror(Failed to open DEVICE \n);
return 1;
}
struct v4l2_requestbuffers reqbuf = {
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
.memory = V4L2_MEMORY_MMAP,
.count = 1,
};
if (-1 == ioctl (fd, VIDIOC_REQBUFS, reqbuf)) {
perror(VIDIOC_REQBUFS);
return 1;
}
system(v4l2-ctl -d DEVICE -l | grep exposure_absolute);
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
if (ioctl (fd, VIDIOC_STREAMON, type) != 0) {
perror(VIDIOC_STREAMON);
return 1;
}
printf(VIDIOC_STREAMON\n);
usleep(10);
system(v4l2-ctl -d DEVICE -l | grep exposure_absolute);
return 0;
}
None of the other controls seem to be affected. Note: to get the C920
to report exposure_absolute correctly I also had to make this change to
the uvcvideo kernel driver:
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
b/drivers/media/usb/uvc/uvc_ctrl.c
index a2f4501..e7c805b 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -227,7 +227,8 @@ static struct uvc_control_info uvc_ctrls[] = {
.size = 4,
.flags = UVC_CTRL_FLAG_SET_CUR
| UVC_CTRL_FLAG_GET_RANGE
- | UVC_CTRL_FLAG_RESTORE,
+ | UVC_CTRL_FLAG_RESTORE
+ | UVC_CTRL_FLAG_AUTO_UPDATE,
},
{
.entity = UVC_GUID_UVC_CAMERA,
The variables seem to be changed when the URBs are Submitted. To
investigate I made the following change to the uvc driver:
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index 3394c34..f2f66f6 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1649,17 +1649,23 @@ static int uvc_init_video(struct uvc_streaming
*stream, gfp_t gfp_flags)
if (ret 0)
return ret;
+ /* No effect: */
+ uvc_ctrl_resume_device(stream-dev);
+
/* Submit the URBs. */
for (i = 0; i UVC_URBS; ++i) {
ret = usb_submit_urb(stream-urb[i], gfp_flags);
if (ret 0) {
uvc_printk(KERN_ERR, Failed to submit URB %u
(%d).\n, i, ret);
uvc_uninit_video(stream, 1);
return ret;
}
}
+ /* Fixes the issue: */
+ uvc_ctrl_resume_device(stream-dev);
+
return 0;
}
At this point the backtrace looks something like:
uvc_init_video
uvc_video_enable
uvc_v4l2_do_ioctl (in the case VIDIOC_STREAMON:)
The call to uvc_ctrl_resume_device() has the effect that the v4l2 ctrls
which are cached in the kernel get resubmitted to the camera as if it
were coming out of suspend/resume.
I've looked at the wireshark capture of USB traffic and I can't find
anywhere where the host causes exposure_auto to change. The camera does
have a mode where it would change by itself but that is disabled
(exposure_auto=1).
This alone doesn't guarantee that exposure absolute is untouched.
To do so you need to set V4L2_CID_EXPOSURE_AUTO_PRIORITY to 0 and
V4L2_CID_EXPOSURE_AUTO to V4L2_EXPOSURE_MANUAL
I've uploaded the wireshark trace to:
http://williammanley.net/usb-wireshark-streamon.pcapng
I'm guessing that this is a hardware bug. One fix would be modify the
driver to save all values at the beginning of STREAMON and then restore
them at the end. What do you think?
Thanks
Will
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Paulo
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-uvc-devel] Closing Bulk Stream in V4L2 UVC Linux driver
Hi, guvcview just handles this like any other V4L2 device. You should look at the driver in this case, and check what it does when a VIDIOC_STREAMOFF is received. Regards, Paulo PS: adding linux media to CC 2014/1/1 Ayoub, Hani hani.ay...@intel.com: Hi, I’m trying to bring up a device which sends data using BULK transfer using V4L2 UVC Linux driver (Ubuntu 12.04). Using guvcview, I can see that the device transfer data successfully and I can see a stream. However, that works fine ONLY the first time I run guvcview after I plug-in the device, closing the app and re-launching it does not show any pictures… to get a good stream I have to re-plug-in the device to the USB 3.0 port. Via USB analyzer, I can see that when closing the application (closing the device) an “AltSet 1” (alternateSetting set 1) is sent although it’s prohibited by spec (UVC 1.1 section 2.4.3) – so the device ignores it, this (I think) is the reason why the stream doesn’t work when re-launching the application. My question is: how should I properly close the stream in BULK? Is there any way to “patch” V4L or the application to make closing the device works fine? There are some similar discussions in the web, but I think there’s no real answer (some references below) References: · Thread1 · Thread2 · Thread3 · Thread4 Thanks, Hani; - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Linux-uvc-devel mailing list linux-uvc-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 00/19] UVC 1.5 VP8 support for uvcvideo
Hi,
2013/11/11 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Paulo,
On Thursday 10 October 2013 11:27:37 Paulo Assis wrote:
Hi,
just want t know the current state on this series.
I'm currently adding h264 stream preview support to guvcview.
It's already working fine on uvc 1.1 cameras like the BCC950
Great ! Is the code already available ?
Yes, the latest git version is working very well, even for the c930,
although for this one, h264, can only be muxed in the MJPG container.
From what I understand Logitech had to remove direct H264 stream
support (no H264 descriptor) due to some issues with a very well known
OS vendor.
but for uvc 1.5 devices like the c930e it could really use some driver
support.
I'm nearly done reviewing the patches (although 19/19 is a huge beast that
will take a bit of time to tame :-)). Getting the code to mainline will still
need some time, but it seems to be going in the right direction. We'll get
hardware compression support for UVC 1.5 in the driver one way or another, it
won't be left to userspace to implement (you will of course have to adapt
existing applications to use the new features, but it should hopefully not be
too complex).
I've test the patches in it's current form and for the c930, at least,
there is a regression that prevents the camera from functioning (it
doesn't create the video node).
The problem happens with patch 3 : uvcvideo: Add support for multiple
chains with common roots, in function uvc_scan_device there is the
following check:
if (UVC_ENTITY_TYPE(entity) != UVC_VC_EXTENSION_UNIT
|| entity-bNrInPins != 1
|| uvc_entity_by_reference(dev, entity-id, NULL)) {
uvc_printk(KERN_INFO, Found an invalid branch
starting at entity id %d.\n, entity-id);
return -1;
}
for unit 12 (the h264 extension control), 'uvc_entity_by_reference'
check fails and this causes the camera initialization to also fail, so
no video node is created.
My very simple fix was to comment the 'uvc_entity_by_reference' check,
this allows the init process to carry on and the video node is
created. The camera will work fine in that case.
I could propose a more appropriate patch, but since this is still
under review I'm not sure if that's OK or if it's better to wait on
other comments.
Regards,
Paulo
2013/8/30 Pawel Osciak posc...@chromium.org:
Hello everyone,
This series adds support for UVC 1.5 and VP8 encoding cameras to the
uvcvideo driver. The official specification for the new standard can be
found here: http://www.usb.org/developers/devclass_docs.
The main change in 1.5 is support for encoding cameras. Those cameras
contain additional UVC entities, called Encoding Units, with their own
set of controls governing encode parameters. Typical encoding cameras
(see examples in class spec) expose two USB Video Streaming Interfaces
(VSIs): one for raw stream formats and one for encoded streams.
Typically, both get their source stream from a single sensor, producing
raw and encoded versions of the video feed simultaneously.
Encoding Units may also support the so-called simulcast formats, which
allow additional sub-streams, or layers, used to achieve temporal
scalability. The spec allows up to 4 simulcast layers. Those layers are
encoded in the same format, but encoding parameters, such as resolution,
bitrate, etc., may, depending on the camera capabilities, be changed
independently for each layer, and their streaming state may also be
controlled independently as well. The layers are streamed from the same
USB VSI, and the information which layer a frame belongs to is contained
in its payload header.
In V4L2 API, a separate video node is created for each VSI: one for raw
formats VSI and another for the encoded formats VSI. Both can operate
completely independently from each other. In addition, if the Encoding
Unit supports simulcast, one V4L2 node is created for each stream layer
instead, and each can be controlled independently, including
streamon/streamoff state, setting resolution and controls. Once a
simulcast format is successfully set for one of the simulcast video nodes
however, it cannot be changed, unless all connected nodes are idle, i.e.
they are not streaming and their buffers are freed.
The userspace can discover if a set of nodes belongs to one encoding unit
by traversing media controller topology of the camera.
I will be gradually posting documentation changes for new features after
initial rounds of reviews. This is a relatively major change to the UVC
driver and although I tried to keep the existing logic for UVC 1.5
cameras intact as much as possible, I would very much appreciate it if
these patches could get some testing from you as well, on your own
devices/systems.
Thanks,
Pawel Osciak
Pawel Osciak (19):
uvcvideo: Add UVC query tracing.
uvcvideo: Return 0 when setting probe
Re: [PATCH v1 03/19] uvcvideo: Add support for multiple chains with common roots.
Hi,
I'm repeating myself, but this seems the proper place to post this.
This patch causes a regression with the logitech c930e.
Please see comments below:
2013/11/10 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Pawel,
Thank you for the patch.
On Friday 30 August 2013 11:17:02 Pawel Osciak wrote:
This adds support for pipelines that fork into branches consisting of more
than one entity, creating a chain for each fork and putting common entities
on all chains that share them.
This requires us to share the ctrl_mutex across forked chains. Whenever we
discover a shared part of a chain, we assign the pointer to an existing
mutex to the sharing chain instead of creating a new one.
The forward scan is not needed anymore, as after scanning back from OTs,
we go over all entities which are not on a path from an OT and accept
single-XU branches, adding them to the existing chains.
Also extract control locking into __uvc_ctrl_{lock,unlock} functions.
This is one core piece of the UVC 1.5 rework, and I have mixed feelings about
it.
Adding entities to multiple overlapping chains somehow doesn't feel right.
What would you think about using a pipeline object instead, which would store
all entities in the pipeline ?
The driver currently iterates over all entities in a chain for several
purposes:
- registering streaming terminals as video nodes (uvc_driver.c)
- registering MC entities (uvc_entity.c)
- enumerating inputs (uvc_v4l2.c)
- finding controls and extension units (uvc_ctrl.c)
The first two uses could easily be replaced by iterations over the whole
pipeline. Input enumeration would probably require a bit of custom code
anyway, so we would be left with controls.
At first sight it would make sense to expose on a video node only the controls
that can be reached from that video node moving up the pipeline (relatively to
the video flow). However, this might break existing applications, as the
driver currently also includes controls reacheable by forward scans of side
branches. We thus need to carefully think about what controls to include, and
we need to take into account output video nodes corresponding to input
streaming terminals.
Signed-off-by: Pawel Osciak posc...@chromium.org
---
drivers/media/usb/uvc/uvc_ctrl.c | 70 -
drivers/media/usb/uvc/uvc_driver.c | 210 +++--
drivers/media/usb/uvc/uvc_entity.c | 15 ++-
drivers/media/usb/uvc/uvc_v4l2.c | 9 +-
drivers/media/usb/uvc/uvcvideo.h | 20 +++-
5 files changed, 199 insertions(+), 125 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
b/drivers/media/usb/uvc/uvc_ctrl.c index a2f4501..ba159a4 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -841,6 +841,7 @@ static struct uvc_control *uvc_find_control(struct
uvc_video_chain *chain, {
struct uvc_control *ctrl = NULL;
struct uvc_entity *entity;
+ struct uvc_chain_entry *entry;
int next = v4l2_id V4L2_CTRL_FLAG_NEXT_CTRL;
*mapping = NULL;
@@ -849,7 +850,8 @@ static struct uvc_control *uvc_find_control(struct
uvc_video_chain *chain, v4l2_id = V4L2_CTRL_ID_MASK;
/* Find the control. */
- list_for_each_entry(entity, chain-entities, chain) {
+ list_for_each_entry(entry, chain-entities, chain_entry) {
+ entity = entry-entity;
__uvc_find_control(entity, v4l2_id, mapping, ctrl, next);
if (ctrl !next)
return ctrl;
@@ -1048,6 +1050,16 @@ static int __uvc_query_v4l2_ctrl(struct
uvc_video_chain *chain, return 0;
}
+int __uvc_ctrl_lock(struct uvc_video_chain *chain)
+{
+ return mutex_lock_interruptible(chain-pipeline-ctrl_mutex) ?
+ -ERESTARTSYS : 0;
+}
+void __uvc_ctrl_unlock(struct uvc_video_chain *chain)
+{
+ mutex_unlock(chain-pipeline-ctrl_mutex);
+}
+
int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
struct v4l2_queryctrl *v4l2_ctrl)
{
@@ -1055,9 +1067,9 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
struct uvc_control_mapping *mapping;
int ret;
- ret = mutex_lock_interruptible(chain-ctrl_mutex);
+ ret = __uvc_ctrl_lock(chain);
if (ret 0)
- return -ERESTARTSYS;
+ return ret;
ctrl = uvc_find_control(chain, v4l2_ctrl-id, mapping);
if (ctrl == NULL) {
@@ -1067,7 +1079,7 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
ret = __uvc_query_v4l2_ctrl(chain, ctrl, mapping, v4l2_ctrl);
done:
- mutex_unlock(chain-ctrl_mutex);
+ __uvc_ctrl_unlock(chain);
return ret;
}
@@ -1094,9 +1106,9 @@ int uvc_query_v4l2_menu(struct uvc_video_chain *chain,
query_menu-id = id;
query_menu-index = index;
- ret = mutex_lock_interruptible(chain-ctrl_mutex);
+ ret = __uvc_ctrl_lock(chain);
if (ret 0)
- return -ERESTARTSYS;
+
Re: Corrupt Raw webcam data
Hi, You must add the nodrop option to the uvc driver (nodrop=1), otherwise bayer frames (smaller than yuyv frames) will get droped, since the driver mistakens these with incomplete yuyv frames. If you are using guvcview make sure you use the latest version (1.7.0), then I would try different resolutions and frame rates, I woul first try the sensor full resolution at the lowest fps. If the image has a blue or yellow tone try chaging the bayer order. Regards, Paulo 2013/6/11 phil rosenberg philip_rosenb...@yahoo.com: Hi Paulo Unfortunately I tried setting things up in the order you suggested, but as soon as I select 'Disable video processing I get only a single frame of something that looks a bit like a bayer grid, coloured deep blue. I think the image might be in this data but shifted horizontally and then an error Could not grab image (select timeout): Resource temporariliy unavailable which is repeated until I unselect 'Disable video processing' and change to any other input type. I've tested this on Ubuntu 12.04 and Raspian Wheezy with the same results. If you have any other ideas I'd be happy to hear them All the best Phil - Original Message - From: Paulo Assis pj.as...@gmail.com To: phil rosenberg philip_rosenb...@yahoo.com Cc: linux-media@vger.kernel.org linux-media@vger.kernel.org Sent: Tuesday, 11 June 2013, 11:13 Subject: Re: Corrupt Raw webcam data Hi, You should select YUYV before disabling the video processing. So with video processing still enabled: set YUYV format set the desired fps and resolution set exposure now disable video processing and set the bayer order every time you need to change exposure or resolution you need to enable video processing first. Regards, Paulo 2013/6/11 phil rosenberg philip_rosenb...@yahoo.com: Hello Paulo Thank you for your quick response. Unfortunately if I select YUYV or any other format that is not MJPG data flow stops and I see timeouts appear in the console. Does this represent a bug in either the webcam's UVC support or the UVC driver? If so I presume there is no likely quick workaround. Phil From: Paulo Assis pj.as...@gmail.com To: phil rosenberg philip_rosenb...@yahoo.com Cc: linux-media@vger.kernel.org linux-media@vger.kernel.org Sent: Tuesday, 11 June 2013, 10:11 Subject: Re: Hi, make sure you are streaming in YUYV format and not in MJPG or any of the libv4l formats since these are decoded from MJPG. If you are using guvcview for the stream preview you should also set the bayer pattern accordindly since it will depend on whathever resolution you are using. Regards, Paulo 2013/6/11 phil rosenberg philip_rosenb...@yahoo.com Hi this is my first email to the list, I'm hoping someone can help I have a logitech C300 webcam with the option of raw/bayer output. This works fine on windows where the RGB output consists of zeros in the r and b bytes and pixel intensitey in the g byte. However on linux when I activate the webcam using uvcdynctrl and/or the options in guvcview the out put seems to be corrupted. I get something that looks like multiple images interlaces and displaced horizontally, generally pink. I've put an example of an extracted avi frame at http://homepages.see.leeds.ac.uk/~earpros/test0.png,which is a close up of one of my daughters hair clips and shows an (upside down) picture of a disney character. I'm wondering if the UVC/V4L2 driver is interpretting the data as mjpeg and incorrectly decoding it giving the corruption. When I use guvcview I can choose the input format, but the only one that works in mjpeg, all others cause timeouts and no data. The image also has the tell-tale 8x8 jpeg block effect. Is there any way I can stop this decoding happening and get to the raw data? Presumably if my theory is correct then the decompression is lossy so cannot be undone. Any help or suggestions welcome. Phil -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd:
For the list (again) -- Forwarded message -- From: Paulo Assis pj.as...@gmail.com Date: 2013/6/11 Subject: Re: To: phil rosenberg philip_rosenb...@yahoo.com Cc: linux-media@vger.kernel.org linux-media@vger.kernel.org Hi, make sure you are streaming in YUYV format and not in MJPG or any of the libv4l formats since these are decoded from MJPG. If you are using guvcview for the stream preview you should also set the bayer pattern accordindly since it will depend on whathever resolution you are using. Regards, Paulo 2013/6/11 phil rosenberg philip_rosenb...@yahoo.com Hi this is my first email to the list, I'm hoping someone can help I have a logitech C300 webcam with the option of raw/bayer output. This works fine on windows where the RGB output consists of zeros in the r and b bytes and pixel intensitey in the g byte. However on linux when I activate the webcam using uvcdynctrl and/or the options in guvcview the out put seems to be corrupted. I get something that looks like multiple images interlaces and displaced horizontally, generally pink. I've put an example of an extracted avi frame at http://homepages.see.leeds.ac.uk/~earpros/test0.png, which is a close up of one of my daughters hair clips and shows an (upside down) picture of a disney character. I'm wondering if the UVC/V4L2 driver is interpretting the data as mjpeg and incorrectly decoding it giving the corruption. When I use guvcview I can choose the input format, but the only one that works in mjpeg, all others cause timeouts and no data. The image also has the tell-tale 8x8 jpeg block effect. Is there any way I can stop this decoding happening and get to the raw data? Presumably if my theory is correct then the decompression is lossy so cannot be undone. Any help or suggestions welcome. Phil -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Corrupt Raw webcam data
Hi, You should select YUYV before disabling the video processing. So with video processing still enabled: set YUYV format set the desired fps and resolution set exposure now disable video processing and set the bayer order every time you need to change exposure or resolution you need to enable video processing first. Regards, Paulo 2013/6/11 phil rosenberg philip_rosenb...@yahoo.com: Hello Paulo Thank you for your quick response. Unfortunately if I select YUYV or any other format that is not MJPG data flow stops and I see timeouts appear in the console. Does this represent a bug in either the webcam's UVC support or the UVC driver? If so I presume there is no likely quick workaround. Phil From: Paulo Assis pj.as...@gmail.com To: phil rosenberg philip_rosenb...@yahoo.com Cc: linux-media@vger.kernel.org linux-media@vger.kernel.org Sent: Tuesday, 11 June 2013, 10:11 Subject: Re: Hi, make sure you are streaming in YUYV format and not in MJPG or any of the libv4l formats since these are decoded from MJPG. If you are using guvcview for the stream preview you should also set the bayer pattern accordindly since it will depend on whathever resolution you are using. Regards, Paulo 2013/6/11 phil rosenberg philip_rosenb...@yahoo.com Hi this is my first email to the list, I'm hoping someone can help I have a logitech C300 webcam with the option of raw/bayer output. This works fine on windows where the RGB output consists of zeros in the r and b bytes and pixel intensitey in the g byte. However on linux when I activate the webcam using uvcdynctrl and/or the options in guvcview the out put seems to be corrupted. I get something that looks like multiple images interlaces and displaced horizontally, generally pink. I've put an example of an extracted avi frame at http://homepages.see.leeds.ac.uk/~earpros/test0.png, which is a close up of one of my daughters hair clips and shows an (upside down) picture of a disney character. I'm wondering if the UVC/V4L2 driver is interpretting the data as mjpeg and incorrectly decoding it giving the corruption. When I use guvcview I can choose the input format, but the only one that works in mjpeg, all others cause timeouts and no data. The image also has the tell-tale 8x8 jpeg block effect. Is there any way I can stop this decoding happening and get to the raw data? Presumably if my theory is correct then the decompression is lossy so cannot be undone. Any help or suggestions welcome. Phil -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the gspca_ov519 driver
Hi, This bug also causes the camera to crash when changing fps in guvcview, uvc devices (at least all the ones I tested) require the stream to be restarted for fps to change, so in the case of this driver after STREAMOFF the camera just becomes unresponsive. Regards, Paulo 2012/5/22 Lluís Batlle i Rossell vi...@viric.name: Hello, I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5). As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to vb2. I don't know what it means. Can someone take care of the bug, or should I consider the camera 'non working' in linux? Thank you, Lluís. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Hans, I've add you has a developer to the project, so you should be able to commit these patches yourself, I would suggest that you pushed a new branch with your changes and after testing we merge them into the master. I'm doing the same for some fixes I have planned and also for the code for version 0.3 that Martin kindly send me (it has a lot of new apps, including a qt interface, and video capture support). This is the project page: https://sourceforge.net/p/libwebcam/code currently master is not building against the new uvcvideo.h, I'll try to fix that today, also the check for this header during configuration is unnecessary since it's now in linux headers (just need to include it with linux/uvcvideo.h) Regards, Paulo 2012/5/4 Hans de Goede hdego...@redhat.com: Hi Paulo, I've also done some work on libwebcam a while ago, but have not yet had the time to send this to Martin Rubli. Attached are git format-patch patches against the 0.2.1 branch of svn. Note these are against what was in that branch when I did this work some months ago, so not sure if it will still apply cleanly. I would really like to work together with you on getting an updated version of libwebcam out there for use in distros (I maintain libwebcam in Fedora, and AFAIK you maintain it in Debian, right?) My sourceforge.net account is jwrdegoede, I hope you're willing to give me commit access to the git repo there. I guess if there is going to be more then 1 of us working on the git repo we should have some review procedure. If others don't object we could post patches to linux-media, prefixing the subject with a [PATCH libwebcam] and then do reviews on linux-media and push only after an ack? I guess we could start with that right away with my proposed patches, if you can make an initial git repo available I can rebase on top of that and then send the patches with git send-email (so 1 patch / mail) for review? Either way thanks for working on this! Regards, Hans On 05/03/2012 04:17 PM, Paulo Assis wrote: Karl Hi, I'm setting up a libwebcam git repo in sourceforge, Martin Rubli from logitech (the libwebcam developer), was kind enough to post me all it's code and the old svn repo backup. He had already done some fixes regarding the new ioctls for version 0.3, so I just need to go through that and add add them to 0.2. I still need to check with him how he wants to handle the 0.3 version, since it has a lot of new code ( and some extra apps ). Regards, Paulo 2012/5/3 Karl Kinigerkarl.kini...@med.ge.com: Hi Paulo, On Wed 120502, Paulo Assis wrote: OK, so UVCIOC_CTRL_ADD is no longer available, now we have: UVCIOC_CTRL_MAP and UVCIOC_CTRL_QUERY, so I guess some changes are needed, I'll try to fix this ASAP. compiled libwebcam-0.2.1 from Ubuntu (had to fight against CMake - I am almost CMake agnostic so far...) and I got the manual focus control in guvcview so things are definitely looking better now. So far I have got a focus slider and a LED1 frequency slider, but not a LED mode... forgot what exactly was available in the past. --- LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml [libwebcam] Unsupported V4L2_CID_EXPOSURE_AUTO control with a non-contiguous range of choice IDs found [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x009A0901, name = 'Exposure, Auto' Importing dynamic controls from file /usr/share/uvcdynctrl/data/046d/logitech.xml. /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to map 'Pan (relative)' control. ioctl(UVCIOC_CTRL_MAP) failed with return value -1 (error 2: No such file or directory) /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to map 'Tilt (relative)' control. ioctl(UVCIOC_CTRL_MAP) failed with return value -1 (error 2: No such file or directory) /usr/share/uvcdynctrl/data/046d/logitech.xml:354: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_BUTTON' /usr/share/uvcdynctrl/data/046d/logitech.xml:368: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_BUTTON' /usr/share/uvcdynctrl/data/046d/logitech.xml:396: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_MENU' Thanks again, Karl Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Karl Hi, I'm setting up a libwebcam git repo in sourceforge, Martin Rubli from logitech (the libwebcam developer), was kind enough to post me all it's code and the old svn repo backup. He had already done some fixes regarding the new ioctls for version 0.3, so I just need to go through that and add add them to 0.2. I still need to check with him how he wants to handle the 0.3 version, since it has a lot of new code ( and some extra apps ). Regards, Paulo 2012/5/3 Karl Kiniger karl.kini...@med.ge.com: Hi Paulo, On Wed 120502, Paulo Assis wrote: OK, so UVCIOC_CTRL_ADD is no longer available, now we have: UVCIOC_CTRL_MAP and UVCIOC_CTRL_QUERY, so I guess some changes are needed, I'll try to fix this ASAP. compiled libwebcam-0.2.1 from Ubuntu (had to fight against CMake - I am almost CMake agnostic so far...) and I got the manual focus control in guvcview so things are definitely looking better now. So far I have got a focus slider and a LED1 frequency slider, but not a LED mode... forgot what exactly was available in the past. --- LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml [libwebcam] Unsupported V4L2_CID_EXPOSURE_AUTO control with a non-contiguous range of choice IDs found [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x009A0901, name = 'Exposure, Auto' Importing dynamic controls from file /usr/share/uvcdynctrl/data/046d/logitech.xml. /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to map 'Pan (relative)' control. ioctl(UVCIOC_CTRL_MAP) failed with return value -1 (error 2: No such file or directory) /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to map 'Tilt (relative)' control. ioctl(UVCIOC_CTRL_MAP) failed with return value -1 (error 2: No such file or directory) /usr/share/uvcdynctrl/data/046d/logitech.xml:354: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_BUTTON' /usr/share/uvcdynctrl/data/046d/logitech.xml:368: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_BUTTON' /usr/share/uvcdynctrl/data/046d/logitech.xml:396: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_MENU' Thanks again, Karl Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Karl Hi, I'm using a 3.2 kernel and I haven't notice this problem, can you check the exact version that causes it. Regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: Please can someone shed a little light on this? Greatly appreciated, Karl On Tue 120424, Karl Kiniger wrote: Dear all, guvcview does not display the extra controls (focus, led etc) any more since kernel 3.2 an higher (Fedora 16, x86_64). after the various video modes it says: vid:046d pid:0990 driver:uvcvideo Adding control for Pan (relative) UVCIOC_CTRL_ADD - Error: Inappropriate ioctl for device checking format: 1196444237 VIDIOC_G_COMP:: Inappropriate ioctl for device fps is set to 1/25 drawing controls Checking video mode 640x480@32bpp : OK -- /usr/bin/uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml [libwebcam] Unsupported V4L2_CID_EXPOSURE_AUTO control with a non-contiguous range of choice IDs found [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x009A0901, name = 'Exposure, Auto' Importing dynamic controls from file /usr/share/uvcdynctrl/data/046d/logitech.xml. ERROR: Unable to import dynamic controls: Invalid device or device cannot be opened. (Code: 5) /usr/share/uvcdynctrl/data/046d/logitech.xml: error: device 'video0' \ skipped because the driver 'uvcvideo' behind it does not seem to support \ dynamic controls. -- Is there work in progess to get the missing functionality back? Can I help somehow? Greetings, Karl -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
karl, I've run some tests under ubuntu 12.04 with kernel 3.2.0 and everything seems to be working fine. I know some changes were made to the uvcvideo module regarding XU controls, but I was under the impression that they wouldn't break userspace. Logitech shutdown the quickcamteam site, so you won't be able to download libwebcam from there. I'm currently the debian mantainer of that package, so I'll try to test it on a newer kernel and patch it as necessary. I'll also fix guvcview if needed. Regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: Hi Paulo, I am running plain Fedora 16 on x86_64. The last kernel where UVC dyncontrols worked was 3.1.10-2. (If I remember correctly...) The first kernel with failing dyncontrols was 3.2.1-1 and all later kernels up to 3.3.2-6 fail as well. libwebcam version is libwebcam-0.2.0-4.20100322svn and guvcview is guvcview-1.5.1-1. http://www.quickcamteam.net/software/libwebcam seems to be offline/ discontinued since a few months. what software versions are you running? Is there a later libwebcam available from somewhere else? pls look also at: http://permalink.gmane.org/gmane.linux.kernel/1257500 Greetings, Karl On Wed 120502, Paulo Assis wrote: Karl Hi, I'm using a 3.2 kernel and I haven't notice this problem, can you check the exact version that causes it. Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Hi, yes, libwebcam depends on uvcvideo.h, I've only added this as a patch since it was missing from debian kernel headers at the time. I think you should be able to get it from there now, not sure if the new header breaks anything, I'll have to run some tests. The other patches are not needed, but they do increase functionality to some extent. Anyway if this was just a libwebcam issue, guvcview should still be able to add the controls, and apparently that's failing also. Best regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: On Wed 120502, Paulo Assis wrote: karl, I've run some tests under ubuntu 12.04 with kernel 3.2.0 and everything seems to be working fine. I know some changes were made to the uvcvideo module regarding XU controls, but I was under the impression that they wouldn't break userspace. Logitech shutdown the quickcamteam site, so you won't be able to download libwebcam from there. I'm currently the debian mantainer of that package, so I'll try to test it on a newer kernel and patch it as necessary. I'll also fix guvcview if needed. Very much appreciated, Paulo! In the meantime I poked around at Ubuntu and found libwebcam_0.2.1.orig.tar.gz - will try to compiled it but they have a couple of kernel patches to 3.2.x as well and perhaps there is a depency. Karl Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
OK, so UVCIOC_CTRL_ADD is no longer available, now we have: UVCIOC_CTRL_MAP and UVCIOC_CTRL_QUERY, so I guess some changes are needed, I'll try to fix this ASAP. Regards, Paulo 2012/5/2 Paulo Assis pj.as...@gmail.com: Hi, yes, libwebcam depends on uvcvideo.h, I've only added this as a patch since it was missing from debian kernel headers at the time. I think you should be able to get it from there now, not sure if the new header breaks anything, I'll have to run some tests. The other patches are not needed, but they do increase functionality to some extent. Anyway if this was just a libwebcam issue, guvcview should still be able to add the controls, and apparently that's failing also. Best regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: On Wed 120502, Paulo Assis wrote: karl, I've run some tests under ubuntu 12.04 with kernel 3.2.0 and everything seems to be working fine. I know some changes were made to the uvcvideo module regarding XU controls, but I was under the impression that they wouldn't break userspace. Logitech shutdown the quickcamteam site, so you won't be able to download libwebcam from there. I'm currently the debian mantainer of that package, so I'll try to test it on a newer kernel and patch it as necessary. I'll also fix guvcview if needed. Very much appreciated, Paulo! In the meantime I poked around at Ubuntu and found libwebcam_0.2.1.orig.tar.gz - will try to compiled it but they have a couple of kernel patches to 3.2.x as well and perhaps there is a depency. Karl Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC video output problem with 3.3.1 kernel
Hi, BGR3, RGB3, YU12 and YV12 are provided through libv4l, the original unconverted stream format provided through uvcvideo driver is YUYV, if this is fine then this is probably an issue with libv4l. Regards, Paulo 2012/4/5 Chris Rankin ranki...@googlemail.com: Hi, I have a UVC video device, which lsusb describes as: 046d:0992 Logitech, Inc. QuickCam Communicate Deluxe With the 3.3.1 kernel, the bottom 3rd of the video window displayed by guvcview is completely black. This happens whenever I select either BGR3 or RGB3 as the video output format. However, YUYV, YU12 and YV12 all display fine. Does anyone else see this, please? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC video output problem with 3.3.1 kernel
Hi, From what you describe I would say that during conversion a YUYV (2 bytes per pixel) size (be it a buffer or loop iterations) is being used for RGB3 (3 bytes per pixel), so you only get 2/3 of the picture. Does this happen in any resolution ? Regards, Paulo 2012/4/5 Paulo Assis pj.as...@gmail.com: Hi, BGR3, RGB3, YU12 and YV12 are provided through libv4l, the original unconverted stream format provided through uvcvideo driver is YUYV, if this is fine then this is probably an issue with libv4l. Regards, Paulo 2012/4/5 Chris Rankin ranki...@googlemail.com: Hi, I have a UVC video device, which lsusb describes as: 046d:0992 Logitech, Inc. QuickCam Communicate Deluxe With the 3.3.1 kernel, the bottom 3rd of the video window displayed by guvcview is completely black. This happens whenever I select either BGR3 or RGB3 as the video output format. However, YUYV, YU12 and YV12 all display fine. Does anyone else see this, please? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: size of raw bayer data
Hi, 2011/8/13 Veda N ved...@gmail.com: what should be the size of a raw bayer data from the driver. for 640x480 = i get 640x480x2. Is this in bytes? Shouldnt i get more? It shoule be more than yuv422/rgb565 No, that depends on the pixel size, so for 8 bit pixel you should get 640x480 bytes, for 12 bit you should get 640x480x3/2 and so on. 640x480x2 is equivalent to a 16 bit pixel, this is a bit unusual I think, the most common is 8 bit pixel, what device/driver are you using ? Regards, Paulo -- Regards, S. N. Veda -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux-uvc-devel] Logitech C910 driver problem
Radek, Please attach the full dmesg output when starting video capture with the second camera. Also increase log verbosity first: something like this: rmmod uvcvideo modprobe uvcvideo trace=65535 You should also refer your capture settings (if I remember MJPG 640x480@24 fps) and that if you use one c910 and one c600 everything works fine. Note: Cc linux-media since you also posted this thread there. Regards, Paulo 2011/1/14 Radek Mašín ra...@masin.eu: Hello, I'm trying to get working two Logitech C910 cameras in one computer and I'm unable to do it. I connect both cameras to one USB controller and first camera is starting capture without problem, but when I try to start second camera during first camera is running, I get message in log uvcvideo: Failed to submit URB 0 and capturing fails. I have discussed this problem on quickcamteam forum and it seems, that there is problem with uvcvideo driver for this camera. Cameras have been tested in two different systems (SuSe 11.2 and Ubuntu 10.10) and on both systems I get same behavior. Thank you Radek Masin ___ Linux-uvc-devel mailing list linux-uvc-de...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power frequency detection.
Hi, 2010/12/18 Theodore Kilgore kilg...@banach.math.auburn.edu: Does anyone know whether, somewhere in the kernel, there exists a scheme for detecting whether the external power supply of the computer is using 50hz or 60hz? The reason I ask: A certain camera is marketed with Windows software which requests the user to set up the option of 50hz or 60hz power during the setup. Judging by what exists in videodev2.h, for example, it is evidently possible to set up this as a control setting in a Linux driver. I am not aware of any streaming app which knows how to access such an option. Most uvc cameras present this as a control, so any v4l2 control app should let you access it. If your camera driver also supports this control then this shouldn't be a problem for any generci v4l2 app. here are a couple of ones: v4l2ucp (control panel) guvcview (guvcview --control_only will work along side other apps just like v4l2ucp) uvcdynctrl from libwebcam for command line control utility . Regards, Paulo Information about which streaming app ought to be used which could take advantage of a setting for line frequency would be welcome, too, of course. As I said, I do not know of a single one and would therefore have trouble with testing any such control setting unless I could find the software which can actually present the choice to the user. But my main question is whether the kernel already does detect the line frequency anywhere else, for whatever reason. For, it occurs to me that a far more elegant solution -- if the camera really does need to have the line frequency detected -- would be do do the job automatically and not to bother the user about such a thing. In other news, in case anyone has any children who are in love with Lego, the Lego Bionicle camera which is currently on sale has an SQ905C type chip in it. I just added its Product number to the Gphoto driver last night. And it works perfectly in webcam mode if one adds its product number in gspca/sq905c.c. I will get around to doing that formally, of course, when I get time. But if anyone wants just to add the number and re-compile the Vendor:Product number for the new camera is 0x2770:0x9051. Merry Christmas. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.37] V4L documentation fixes
Hi, Since we are talking about V4L documentation, I would like to remind of the timestamps subject since this is a recurrent issue. The current spec refers to gettimeofday return value for the buffer timestamps and as already discussed in previous posts, gettimeofday, introduces a lot of issues, using ktime (monotonic) instead seems a much better approach. Uvcvideo and gspca already use it, but since the documentation has not been changed yet, it can cause some confusion between developers. NOTE: I see this topic is intended for discussion in the LPC: http://www.linuxtv.org/news.php?entry=2010-06-22.mchehab So I'm not sure if this should be put on hold until then. As a side note: if you need a similar timestamp to the one returned by ktime in user space, you can get it with: static struct timespec ts; clock_gettime(CLOCK_MONOTONIC, ts); A conversion between timespec and timeval is needed but that is easy enough, for both drivers and user space. Best Regards Paulo 2010/9/23 Hans Verkuil hverk...@xs4all.nl: On Wednesday, September 22, 2010 23:17:08 Mauro Carvalho Chehab wrote: Em 22-09-2010 17:06, Hans Verkuil escreveu: On Wednesday, September 22, 2010 21:42:03 Mauro Carvalho Chehab wrote: Em 15-09-2010 04:23, Hans Verkuil escreveu: The following changes since commit 57fef3eb74a04716a8dd18af0ac510ec4f71bc05: Richard Zidlicky (1): V4L/DVB: dvb: fix smscore_getbuffer() logic are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc2 Hans Verkuil (6): V4L Doc: removed duplicate link This doesn't seem right. the entry for V4L2-PIX-FMT-BGR666 seems to be duplicated. We should remove the duplication, instead of just dropping the ID. No, this patch is correct. This section really duplicates the formats due to confusion about the byte order in memory. But only one of these format tables should have a valid ID. See table 2.4 and 2.5 here: http://www.xs4all.nl/~hverkuil/spec/media.html#packed-rgb As you can see here there is no BGR666 entry in either table since the docbook generation has been failing on this docbook error for some time now. V4L Doc: fix DocBook syntax errors. V4L Doc: document V4L2_CAP_RDS_OUTPUT capability. V4L Doc: correct the documentation for VIDIOC_QUERYMENU. Applied, thanks. V4L Doc: rewrite the Device Naming section The new text is incomplete, as it assumes only the old non-dynamic device node creation. Also, some distros actually create /dev/v4l, as recommended. IMHO, we need to improve this section, proposing a better way to name devices. This may be an interesting theme for this year's LPC. No, the major is still 81 and the minors are still between 0 and 255. But the minor ranges are gone (unless you turn that on explicitly). So this text is really correct and way more understandable than the old text. Hmm... are the V4L core artificially limiting minor range to be between 0 and 255? Well, we do need to keep a mapping between minor and video_device (the video_device array in v4l2-dev.c) so we do need a maximum number of devices. Increasing this number is a matter of just increasing the VIDEO_NUM_DEVICES macro. Since we no longer split up the 256 minors into ranges for each video type (video, vbi, radio) we make full use of all minors. Nothing I've seen comes even close to filling up all those minors. That said, when we add support for the subdev device nodes we should probably at the same time double the number of reserved minors. Just in case. Regards, Hans V4L Doc: clarify the V4L spec. This is a mix of several changes on the same patch. I want to do comments about it, but no time right now to write an email about that. It is a way harder to comment Docbook changes than patches, as the diff output is not user-friendly. I'll postpone this patch for a better analysis. No problem. Regards, Hans I don't want to postpone the DocBook correction patches due to that, so I'm applying the patches I'm ok. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L Camera frame timestamp question
2010/6/10 Jean-Francois Moine moin...@free.fr: On Thu, 10 Jun 2010 03:24:05 + (UTC) jiajun zhujia...@gmail.com wrote: I'm currently using the V4L-DVB driver to control a few logitech webcams and playstation eye cameras on a Gubuntu system. Everything works just fine except one thing: the buffer timestamp value seems wrong. [snip] this should be the timestamp of when the image is taken (similar to gettimeofday() function) but the value I got is something way smaller (e.g. 75000) than what it should be (e.g. 1275931384) Is this a known problem? Hi, No, I did not know it! Thank you. I will try to fix it for the kernel 2.6.35. You can't use gettimeofday for timestamps or you will have big problems if your clock changes when you are grabbing video. You must use a monotonic clock, this is what gspca and uvc are doing, they now use ktime, a monotonic highres clock. This prevents time shifts that can break the video stream playback, also gettimeofday as problems in multicore cpus since for most processors the internal cpus are not exactly in sync. So PLEASE leave it like it is now, also other drivers should really move into using ktime nad not gettimeofday. You are converting the timestamp to seconds this will produce a smaller value, you should really convert it to ms, then you would get a value closer to what you want. Best Regards, Paulo Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.35] gspca for_2.6.35
PLEASE NO, The current use of ktime is much better, timestamps are perfectly in sync and will not suffer from time shifts if the clock value changes. PLEASE just leave it like it is now. Best Regards, Paulo 2010/6/10 Jean-Francois Moine moin...@free.fr: Hi Mauro, The following changes since commit e411f2dda48c81c556c802d4430717950cf088fd: Merge branch 'for-linus' of git://git.monstr.eu/linux-2.6-microblaze (2010-06-09 08:52:03 -0700) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.35 Jean-François Moine (1): gspca - main: Set the wall time as buffer timestamp. drivers/media/video/gspca/gspca.c | 15 --- 1 files changed, 12 insertions(+), 3 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L Camera frame timestamp question
Hi,
2010/6/10 Jiajun Zhu zhujia...@gmail.com:
Thanks for the discussion.
Based on my testing, the image timestamps or ktime is the system uptime in
nanosecond, is this correct?
For my application, I need to synchronize the camera image with other data
which are all timestamped by gettimeofday().
Like I explained gettimeofday is not the proper way to set timestamps,
you should use a monotonic clock:
e.g.:
//timestamps in nanosec
uint64_t ns_time_monotonic()
{
static struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, ts);
return ((uint64_t) ts.tv_sec * G_NSEC_PER_SEC + (uint64_t) ts.tv_nsec);
}
This will give you a similar timestamp to ktime.
How would you suggest me to do this?
I can think of two options:
1. Get the system uptime and compute the offset between gettimeofday() at
the start of my program, and then use this offset
to correct all the image timestamps.
The only linux userspace function I can find to get system uptime is to
read /proc/uptime file, which resolution is 0.01 seconds.
2. Hack the camera driver to use do_getimeofday() instead of ktime, and
ignore all the problems you guys mentioned earlier.
Any comments?
In my case to sync audio and video timestamps I just take the first
video ts and check it against the
initial audio ts (taken with the above function) , remember that for
timestamps the important thing is the delta between them,
so you can store the first one and just use the difference for the
next ones. e.g.:
//timestamps in nanosec
if (first_frame)
ts_ref = (uint64_t) buf.timestamp.tv_sec * 10 +
buf.timestamp.tv_usec *1000;
frame_ts = ((uint64_t) buf.timestamp.tv_sec * 10 +
buf.timestamp.tv_usec *1000) - ts_ref;
now you can also use ts_ref for audio timestamps.
If you really need to use getttimeofday (very bad idea), you just need
the timeofday for the first (ref_ts) timestamp
for the others just use the delta.
so when you grab the first frame also get the value of getimeofday()
(in the same time base), that's that simple, from then on just do:
initial_frame_timeofday + frame_ts
Best Regards,
Paulo
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] V4L2 Controls State Store/Restore File Format v.0.0.2 and test app
Ok so here is a new version for the controls state store/restore
functionality and a test app implementing the functionality.
I've removed the need for control order inside the file since this can
be done inside the application.
Simply ordering by id is enough for most auto/absolute control pairs
to work since auto controls will almost in all cases have a lower id
than the absolute counterpart, the exception being
V4L2_CID_FOCUS_AUTO, in the included test app I don't take any special
attention for this case since it would increase complexity.
I also could not test string and 64 bit integer controls since i don't
have any hardware that supports them.
Best Regards,
Paulo
[RFC] V4L2 Controls State Store/Restore File Format
AUTHORS: Paulo Assis pj.as...@gmail.com
VERSION: 0.0.2
ABSTRACT
This document proposes a standard for the file format used by v4l2 applications
to store/restore the controls state.
This unified file format allows sharing control profiles between applications,
making it much easier on both developers and users.
INTRODUCTION
V4l2 controls can be divided by classes and types.
Controls in different classes are not dependent between themselves, on the
other end if two controls belong to the same class they may or may not be
dependent.
A good example are automatic controls and their absolute counterparts, e.g.:
V4L2_CID_AUTOGAIN and V4L2_CID_GAIN.
Controls must be set following the dependency order, automatic controls must be
set first or else setting the absolute value may fail, when that was not the
intended behavior (auto disabled).
After a quick analyses of the v4l2 controls, we are left to conclude that auto
controls have in almost all cases a lower ID order than the corresponding
absolute counterparts, the exception being V4L2_CID_FOCUS_AUTO.
So by ordering controls by id, with the above exception, should be enough for
things to work without problems.
Ordering by id will also automatically order the controls by class allowing the
usage of the extension control API.
Button controls are stateless so they can't be stored.
Relative controls are also in effect stateless, since they will always depend
on their current state.
In fact only controls with Read/Write permissions can be stored and restored so
only these belong in the scope of this document.
The proposed file format takes all of this into account and tries to make
implementation of both store and restore functionality as easy as possible.
FILE FORMAT
The proposed file format is a regular text file with lines terminating with the
newline character '\n'.
Comments can be inserted by adding '#' at the beginning of the line, and can
safely be ignored when parsing the file.
FILE EXTENSION
Although not much relevant, the file extension makes it easy to visually
identify the file type and also for applications to list relevant files, so we
propose that v4l2 control state files be terminated by the suffix: .v4l
FILE HEADER
The file must always start with a commented line containing the file type
identification and the version of this document on which it is based:
#V4L2/CTRL/0.0.2
Additionally it may contain extra information like the application name that
generated the file and for usb devices the vid and pid of the device to whom
the controls relate in hexadecimal notation:
APP_NAME{application name}
VID{0x00}
PID{0x00}
CONTROLS DATA
The controls do not require any special ordering in the file since this can be
achieved in the application implementing the functionality.
In any case ordering by ID is natural as this is the usual way VIDIOC_QUERYCTRL
is done.
Each control must have is data set in a single line nad it will depend on the
control type:
1- V4L2_CTRL_TYPE_STRING:
ID{0x};CHK{min:max:step:0}=STR{string_value}
2- V4L2_CTRL_TYPE_INTEGER64:
ID{0x};CHK{0:0:0:0}=VAL64{value64}
3- V4L2_CTRL_TYPE_INTEGER; V4L2_CTRL_TYPE_BOOLEAN; V4L2_CTRL_TYPE_MENU:
ID{0x};CHK{min:max:step:def};EXT{[0|0}=VAL{value}
The ID key is the control v4l2 id in hex notation.
The CHK key is used to match the control stored in file to the one we are
trying to set on the device.
Controls on different devices may have identical ID's but is unlikely that the
correspondent values remain the same. All values are in decimal notation and
correspond to the controls reported values.
min- minimum
max- maximum
step: step
def: default
These are specially important for integer types but are not relevant for 64 bit
controls.
For string controls max can be used for the string allocation (max+1).
The STR key contains the string control value.
The VAL64 key contains a 64 bit signed integer value.
The VAL key contains a 32 bit signed integer value.
This format should cover all current control types, and is still flexible
enough to allow new types in the future.
/* Store/Restore V4L2 Controls File Format example
*
* Paulo Assis pj.as...@gmail.com
*
* This program is free software; you can
Re: [RFC] V4L2 Controls State Store/Restore File Format
Hans, 2010/5/23 Hans Verkuil hverk...@xs4all.nl: On Thursday 20 May 2010 16:42:01 Paulo Assis wrote: Hi all, Below is a proposal for the file format to use when storing/restoring v4l2 controls state. I've some doubts concerning atomically set controls and string controls (see below) that may be inducing me on error. The format is intended to be generic enough to support any control class so I hope to receive comments for any special cases that I might have missed or overlooked. Don't worry about bashing on the proposal to hard I have a hard skin :-D Regards, Paulo -- Forwarded message -- From: Hans de Goede hdego...@redhat.com Date: 2010/5/20 Subject: Re: [RFC] V4L2 Controls State Store/Restore File Format To: Paulo Assis pj.as...@gmail.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com, martin_ru...@logitech.com Hi Paulo, Clearly you've though quite a bit about this I had not realized this would be this complex (with ordering issues etc.). This looks like a good proposal to start with to me, I think it would be good to further discuss this on the linux-media list, where other v4l devs can read it and chime in. Regards, Hans On 05/20/2010 03:11 PM, Paulo Assis wrote: Hans, Below is the RFC with my proposed control state file format for store/restore functionality. I have several doubts, mostly regarding controls that must be set atomically with the extended control API. The main question is: How does an application know that a group of controls must be set atomically ? Is this reported by the driver or is it something that the application must know. Also for string controls, I've only seen two implementations on RDS controls, so I've set these with low precedence/priority order compared with other control types. Awaiting comments, bash it all you want :-) Regards, Paulo __ [RFC] V4L2 Controls State Store/Restore File Format VERSION 0.0.1 ABSTRACT This document proposes a standard for the file format used by v4l2 applications to store/restore the controls state. This unified file format allows sharing control profiles between applications, making it much easier on both developers and users. INTRODUCTION V4l2 controls can be divided by classes and types. Controls in different classes are not dependent between themselves, on the other end if two controls belong to the same class they may or may not be dependent. A good example are automatic controls and their absolute counterparts, e.g.: V4L2_CID_AUTOGAIN and V4L2_CID_GAIN. Controls must be set following the dependency order, automatic controls must be set first or else setting the absolute value may fail, when that was not the intended behavior (auto disabled). After a quick analyses of the v4l2 controls, we are left to conclude that auto controls are in most cases of the boolean type, with some exceptions like V4L2_CID_EXPOSURE_AUTO, that is of the menu type. So ordering control priority by control type seems logical and it can be done in the following order: 1-V4L2_CTRL_TYPE_BOOLEAN 2-V4L2_CTRL_TYPE_MENU 3-V4L2_CTRL_TYPE_INTEGER 4-V4L2_CTRL_TYPE_INTEGER64 5-V4L2_CTRL_TYPE_STRING I'm not sure whether the ordering is needed, it sounds more like a driver bug that you are trying to work around. When you retrieve the state of controls, then the value of the controls must be valid. So you should be able to set it later. There are some dependencies, for example selecting a particular MPEG video encoding might deactivate some controls and activate others. But the INACTIVE flag should be used to mark that, never the DISABLED flag. And you can still set inactive controls. How would this work for controls like Exposure, Auto ? In the cameras I've tested if we don't set it to manual first, changing Exposure (Absolute) fails. Maybe it's a uvcvideo a bug, I'm not sure. The same for White Balance Temperature, Auto and White Balance Temperature. They all return a EIO error. For controls not belonging to the user class I would store and restore them all using G/S_EXT_CTRLS. So for each class just get all controls that are both readable and writable and not disabled, then get or set them in one call. I'll have to test at least camera class controls and see if this works. For the user class controls you can do the same, but if that fails, then you have to fallback to G/S_CTRL on a per-control basis. I'll test this to! The main problem at the moment is that control handling stinks. Which is why I am working on a new control framework that will handle everything in the v4l core greatly simplifying drivers and providing a unified and consistent interface towards applications. Will this bring any changes to the API, or is just at the core level ? Best Regards, Paulo Regards, Hans Button controls are stateless so they can't
Re: [RFC] V4L2 Controls State Store/Restore File Format
Hi, 2010/5/23 Hans Verkuil hverk...@xs4all.nl: On Sunday 23 May 2010 15:40:26 Paulo Assis wrote: Hans, 2010/5/23 Hans Verkuil hverk...@xs4all.nl: On Thursday 20 May 2010 16:42:01 Paulo Assis wrote: Hi all, Below is a proposal for the file format to use when storing/restoring v4l2 controls state. I've some doubts concerning atomically set controls and string controls (see below) that may be inducing me on error. The format is intended to be generic enough to support any control class so I hope to receive comments for any special cases that I might have missed or overlooked. Don't worry about bashing on the proposal to hard I have a hard skin :-D Regards, Paulo -- Forwarded message -- From: Hans de Goede hdego...@redhat.com Date: 2010/5/20 Subject: Re: [RFC] V4L2 Controls State Store/Restore File Format To: Paulo Assis pj.as...@gmail.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com, martin_ru...@logitech.com Hi Paulo, Clearly you've though quite a bit about this I had not realized this would be this complex (with ordering issues etc.). This looks like a good proposal to start with to me, I think it would be good to further discuss this on the linux-media list, where other v4l devs can read it and chime in. Regards, Hans On 05/20/2010 03:11 PM, Paulo Assis wrote: Hans, Below is the RFC with my proposed control state file format for store/restore functionality. I have several doubts, mostly regarding controls that must be set atomically with the extended control API. The main question is: How does an application know that a group of controls must be set atomically ? Is this reported by the driver or is it something that the application must know. Also for string controls, I've only seen two implementations on RDS controls, so I've set these with low precedence/priority order compared with other control types. Awaiting comments, bash it all you want :-) Regards, Paulo __ [RFC] V4L2 Controls State Store/Restore File Format VERSION 0.0.1 ABSTRACT This document proposes a standard for the file format used by v4l2 applications to store/restore the controls state. This unified file format allows sharing control profiles between applications, making it much easier on both developers and users. INTRODUCTION V4l2 controls can be divided by classes and types. Controls in different classes are not dependent between themselves, on the other end if two controls belong to the same class they may or may not be dependent. A good example are automatic controls and their absolute counterparts, e.g.: V4L2_CID_AUTOGAIN and V4L2_CID_GAIN. Controls must be set following the dependency order, automatic controls must be set first or else setting the absolute value may fail, when that was not the intended behavior (auto disabled). After a quick analyses of the v4l2 controls, we are left to conclude that auto controls are in most cases of the boolean type, with some exceptions like V4L2_CID_EXPOSURE_AUTO, that is of the menu type. So ordering control priority by control type seems logical and it can be done in the following order: 1-V4L2_CTRL_TYPE_BOOLEAN 2-V4L2_CTRL_TYPE_MENU 3-V4L2_CTRL_TYPE_INTEGER 4-V4L2_CTRL_TYPE_INTEGER64 5-V4L2_CTRL_TYPE_STRING I'm not sure whether the ordering is needed, it sounds more like a driver bug that you are trying to work around. When you retrieve the state of controls, then the value of the controls must be valid. So you should be able to set it later. There are some dependencies, for example selecting a particular MPEG video encoding might deactivate some controls and activate others. But the INACTIVE flag should be used to mark that, never the DISABLED flag. And you can still set inactive controls. How would this work for controls like Exposure, Auto ? In the cameras I've tested if we don't set it to manual first, changing Exposure (Absolute) fails. Maybe it's a uvcvideo a bug, I'm not sure. The same for White Balance Temperature, Auto and White Balance Temperature. They all return a EIO error. That's definitely wrong. Either they should set the INACTIVE flag and just accept the new value (possibly storing it internally), or they should set the READONLY flag and return -EACCES or -EINVAL. The spec says -EINVAL but we want to change that to -EACCES. -EIO should only be used for failing hardware. I.e. i2c errors or something like that. But as I said there is a wild variety of ways in which drivers handle controls. It's why I'm working on the control framework and why I want to get that in asap. Still I'm guessing this won't be fully available in drivers before 2.6.36/37. And applications would still need to support older kernel versions, so
Re: [RFC] V4L2 Controls State Store/Restore File Format
Martin Hi,
2010/5/21 martin_ru...@logitech.com:
Hi Paulo,
I haven't looked into the details, but why not use an XML format? It's less
concise, yes, but it's standard, more extensible, and you don't have to
worry about parsing it too much - after all, we already use libxml in
libwebcam.
I've thought about this initially, xml would provide a standard format
without the strict rules of the one I'm proposing and yes it would be
very extensible and would also make it very simple to group controls,
however it as some drawbacks.
Mainly it is very hard to parse with standard c code and it would
almost certainly require an external lib (libxml).
This would be ok for libwebcam and probably some other apps, but the
idea was to create a format that requires only very simple code to
use.
When we finally decide on a format I'll right a small example that can
easily be integrated into any application, so I would rather not use
any external libs.
IMHO xml would be an overkill in this case, but if the general opinion
is that such format should be used instead I can easily change the
proposal to a xml format.
Regards,
Paulo
Cheers,
Martin
Paulo Assis pj.as...@gmail.com wrote on 2010-05-20 21:11:36:
From: Paulo Assis pj.as...@gmail.com
To: Hans de Goede hdego...@redhat.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com,
martin_ru...@logitech.com
Date: 2010-05-20 21:11
Subject: [RFC] V4L2 Controls State Store/Restore File Format
Hans,
Below is the RFC with my proposed control state file format for
store/restore functionality.
I have several doubts, mostly regarding controls that must be set
atomically with the extended control API.
The main question is:
How does an application know that a group of controls must be set
atomically ?
Is this reported by the driver or is it something that the application
must know.
Also for string controls, I've only seen two implementations on RDS
controls, so I've set these with low precedence/priority order
compared with other control types.
Awaiting comments, bash it all you want :-)
Regards,
Paulo
__
[RFC] V4L2 Controls State Store/Restore File Format
VERSION
0.0.1
ABSTRACT
This document proposes a standard for the file format used by v4l2
applications to store/restore the controls state.
This unified file format allows sharing control profiles between
applications, making it much easier on both developers and users.
INTRODUCTION
V4l2 controls can be divided by classes and types.
Controls in different classes are not dependent between themselves, on
the other end if two controls belong to the same class they may or may
not be dependent.
A good example are automatic controls and their absolute counterparts,
e.g.: V4L2_CID_AUTOGAIN and V4L2_CID_GAIN.
Controls must be set following the dependency order, automatic
controls must be set first or else setting the absolute value may
fail, when that was not the intended behavior (auto disabled).
After a quick analyses of the v4l2 controls, we are left to conclude
that auto controls are in most cases of the
boolean type, with some exceptions like V4L2_CID_EXPOSURE_AUTO, that
is of the menu type.
So ordering control priority by control type seems logical and it can
be done in the following order:
1-V4L2_CTRL_TYPE_BOOLEAN
2-V4L2_CTRL_TYPE_MENU
3-V4L2_CTRL_TYPE_INTEGER
4-V4L2_CTRL_TYPE_INTEGER64
5-V4L2_CTRL_TYPE_STRING
Button controls are stateless so they can't be stored and thus are out
of the scope of this document.
Relative controls are also in effect stateless, since they will always
depend on their current state and thus can't be stored.
There are also groups of controls that must be set atomically, so
these need to be grouped together and properly identified when loading
the controls state from a file.
The proposed file format takes all of this into account and tries to
make implementation of both store and restore functionality as easy as
possible.
FILE FORMAT
The proposed file format is a regular text file with lines terminating
with the newline character '\n'.
Comments can be inserted by adding '#' at the beginning of the line,
and can safely be ignored when parsing the file.
FILE EXTENSION
Although not much relevant, the file extension makes it easy to
visually identify the file type and also for applications to list
relevant files, so we propose that v4l2 control state files be
terminated by the suffix: .v4l
FILE HEADER
The file must always start with a commented line containing the file
type identification and the version of this document on which it is
based:
#V4L2/CTRL/0.0.1
Additionally it may contain extra information like the application
name that generated the file and for usb devices the vid and pid of
the device to whom the controls relate in hexadecimal notation:
APP_NAME{application name}
VID{0x00}
PID{0x00}
CONTROLS DATA
The controls related data must be ordered by control
[RFC] V4L2 Controls State Store/Restore File Format
Hi all,
Below is a proposal for the file format to use when storing/restoring
v4l2 controls state.
I've some doubts concerning atomically set controls and string
controls (see below)
that may be inducing me on error.
The format is intended to be generic enough to support any control
class so I hope
to receive comments for any special cases that I might have missed or
overlooked.
Don't worry about bashing on the proposal to hard I have a hard skin :-D
Regards,
Paulo
-- Forwarded message --
From: Hans de Goede hdego...@redhat.com
Date: 2010/5/20
Subject: Re: [RFC] V4L2 Controls State Store/Restore File Format
To: Paulo Assis pj.as...@gmail.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com,
martin_ru...@logitech.com
Hi Paulo,
Clearly you've though quite a bit about this I had not realized
this would be this complex (with ordering issues etc.).
This looks like a good proposal to start with to me, I think it
would be good to further discuss this on the linux-media list,
where other v4l devs can read it and chime in.
Regards,
Hans
On 05/20/2010 03:11 PM, Paulo Assis wrote:
Hans,
Below is the RFC with my proposed control state file format for
store/restore functionality.
I have several doubts, mostly regarding controls that must be set
atomically with the extended control API.
The main question is:
How does an application know that a group of controls must be set atomically ?
Is this reported by the driver or is it something that the application
must know.
Also for string controls, I've only seen two implementations on RDS
controls, so I've set these with low precedence/priority order
compared with other control types.
Awaiting comments, bash it all you want :-)
Regards,
Paulo
__
[RFC] V4L2 Controls State Store/Restore File Format
VERSION
0.0.1
ABSTRACT
This document proposes a standard for the file format used by v4l2
applications to store/restore the controls state.
This unified file format allows sharing control profiles between
applications, making it much easier on both developers and users.
INTRODUCTION
V4l2 controls can be divided by classes and types.
Controls in different classes are not dependent between themselves, on
the other end if two controls belong to the same class they may or may
not be dependent.
A good example are automatic controls and their absolute counterparts,
e.g.: V4L2_CID_AUTOGAIN and V4L2_CID_GAIN.
Controls must be set following the dependency order, automatic
controls must be set first or else setting the absolute value may
fail, when that was not the intended behavior (auto disabled).
After a quick analyses of the v4l2 controls, we are left to conclude
that auto controls are in most cases of the
boolean type, with some exceptions like V4L2_CID_EXPOSURE_AUTO, that
is of the menu type.
So ordering control priority by control type seems logical and it can
be done in the following order:
1-V4L2_CTRL_TYPE_BOOLEAN
2-V4L2_CTRL_TYPE_MENU
3-V4L2_CTRL_TYPE_INTEGER
4-V4L2_CTRL_TYPE_INTEGER64
5-V4L2_CTRL_TYPE_STRING
Button controls are stateless so they can't be stored and thus are out
of the scope of this document.
Relative controls are also in effect stateless, since they will always
depend on their current state and thus can't be stored.
There are also groups of controls that must be set atomically, so
these need to be grouped together and properly identified when loading
the controls state from a file.
The proposed file format takes all of this into account and tries to
make implementation of both store and restore functionality as easy as
possible.
FILE FORMAT
The proposed file format is a regular text file with lines terminating
with the newline character '\n'.
Comments can be inserted by adding '#' at the beginning of the line,
and can safely be ignored when parsing the file.
FILE EXTENSION
Although not much relevant, the file extension makes it easy to
visually identify the file type and also for applications to list
relevant files, so we propose that v4l2 control state files be
terminated by the suffix: .v4l
FILE HEADER
The file must always start with a commented line containing the file
type identification and the version of this document on which it is
based:
#V4L2/CTRL/0.0.1
Additionally it may contain extra information like the application
name that generated the file and for usb devices the vid and pid of
the device to whom the controls relate in hexadecimal notation:
APP_NAME{application name}
VID{0x00}
PID{0x00}
CONTROLS DATA
The controls related data must be ordered by control type and for each
type the ordering must be done by control ID. Ordering by control ID
will also group the controls by class.
The exception to the above rule are controls that need to be set
atomically, these must be grouped together independent of their type.
Each control must have is data set in a single line:
ID{0x};CHK
Re: where I can get UVC svn repository
Hi, linuxtv uses mercurial (or git) not svn, please check the how-to: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers regards, Paulo 2010/2/8 loody milo...@gmail.com: Dear all: I hear UVC is change its repository to linxutv. But I tried several possible repositories like svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/tags svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/rev/75c97b2d1a2a But svn says the repository is incorrect. Would anyone tell me where is the correct location? appreciate your help, miloody -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, The uvcdynctrl utility is part of the libwebcam project: http://www.quickcamteam.net/software/libwebcam But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that is needed to be able to control the focus on some uvc autofocus cameras. Actually libwebcam is still maintained in svn: http://www.quickcamteam.net/documentation/how-to/how-to-install-the-webcam-tools but you are right just a few applications use it, and since it's not yet included in any distribution most end users will miss some advance features on their webcams. I'm just a bit worried that having two different packages providing the same set of tools may cause some compatibility problems in the future. Binary packages of libwebcam are being prepared and will be available soon, so I guess some compat tests may be in order, maybe splitting uvcdynctrl from libwebcam into a different package and making it incompatible with libv4l would be a good idea. Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Adaptec VideOh! DVD Media Center
Hi, I'm currently porting the GPL linux-avc2210k driver ( http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2. The current version has it's own API that makes it incompatible with any software except for specific user space apps (avcctrl, avctune) bundled with the driver. Since development seems to have halted for some time now, I had no other choice than get my hands dirty :( For the most part this task seems quite straight forward it's mostly a matter of changing ioctls to V4L2 and add some missing support, there are however a few points that I need some advice on: For the box to function it needs a firmware upload. Currently this is managed by a udev script that in turn calls an application (multiload) that provides for the upload. What I would like to know is, if this the best way to handle it? The problem with this process is that it will always require installing and configuring additional software (multiload and udev script), besides the firmware. Is there any simpler/standard way of handling these firmware uploads ? Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems compiling webcam driver
Hi, You have to unload the all the old modules before loading the new ones: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers#First_Use:_Out_with_the_Old.2C_In_with_the_New otherwise you will get that type of errors. Regards, Paulo 2009/12/14 Nicolau Werneck nwern...@gmail.com: Hello. I have modified the t613 driver to support a new sensor (code 0x0802), and I am now trying to prepare a patch to submit. The problem is that now that I started to work with the driver again, I started to get this error message... Does anybody know what is this about? I already tried to switch from the 2.6.31 kernel to the 2.6.32, but the same happened. [ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3 [ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128 [ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, SerialNumber=0 [ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam [ 1525.026054] usb 6-2: Manufacturer: TASCORP [ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice [ 1525.072916] gspca_main: disagrees about version of symbol video_devdata [ 1525.072918] gspca_main: Unknown symbol video_devdata [ 1525.073060] gspca_main: disagrees about version of symbol video_unregister_device [ 1525.073062] gspca_main: Unknown symbol video_unregister_device [ 1525.073118] gspca_main: disagrees about version of symbol video_register_device [ 1525.073119] gspca_main: Unknown symbol video_register_device [ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add [ 1525.073731] gspca_t613: Unknown symbol gspca_debug [ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect [ 1525.073931] gspca_t613: Unknown symbol gspca_resume [ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe [ 1525.074038] gspca_t613: Unknown symbol gspca_suspend see you, ++nicolau -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MSI StarCam working in vlc only (with poor colors)
Josef,
white balance temperature and hue controls are being blacklisted in
uvcvideo for all cameras due to a bug in the driver.
A patch fixing the issue was committed recently
(https://lists.berlios.de/pipermail/linux-uvc-devel/2009-December/005396.html)
but I'm not sure when it will be available.
These controls if supported by your camera could help improve the image color.
Best regards,
Paulo
2009/12/10 Jozef Riha jose1...@gmail.com:
thank you again, paulo, for your off-list help. cam is now working
nicely with xawtv, guvcview and skype. the colors slightly improved
during day-light, when artificial light is used they still look bad
though. i fiddled around with just about all v4l controls but couldn't
really fix it. i'll run a comparison with windows driver when i have a
chance.
for others interested: the fix was indeed the quirks mode. i had to
set it like this:
$ cat /etc/modprobe.d/uvcvideo.conf
options uvcvideo trace=15 quirks=2
regards all,
joe
On Wed, Dec 9, 2009 at 11:53 PM, Paulo Assis pj.as...@gmail.com wrote:
You must reload the driver,
rmmod uvcvideo
modprobe uvcvideo
otherwise the quirks want have any effect.
uvcvideo is now mantained in the mercurial repo at linuxtv,
installing v4l-dvb will also install uvcvideo, but if you want, just
follow the instructions on the wiki to compile, but use:
hg clone http://linuxtv.org/hg/~pinchartl/uvcvideo/
so that you get the very latest (testing) uvc code.
In any case the quirks should be enough:
http://lists.berlios.de/pipermail/linux-uvc-devel/2009-October/005235.html
Best regards,
Paulo
2009/12/9 Jozef Riha jose1...@gmail.com:
setting quirks to 2 unfortunately did not help. gucview's 1.2.1 output below
[j...@darkstar ~]$ LC_ALL=C guvcview --verbose
guvcview 1.2.1
unexpected integer value (1) for snd_numsec
Strings must be quoted
video_device: /dev/video0
vid_sleep: 0
cap_meth: 1
resolution: 640 x 480
windowsize: 480 x 700
vert pane: 0
spin behavior: 0
mode: mjpg
fps: 1/25
Display Fps: 0
bpp: 0
hwaccel: 1
avi_format: 0
sound: 1
sound Device: 0
sound samp rate: 0
sound Channels: 0
Sound delay: 0 nanosec
Sound Format: 80
Sound bit Rate: 160 Kbps
Pan Step: 2 degrees
Tilt Step: 2 degrees
Video Filter Flags: 0
image inc: 0
profile(default):/home/jose/default.gpfl
starting portaudio...
language catalog= dir:/usr/share/locale type:C lang:C cat:guvcview.mo
mjpg: setting format to 1196444237
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951) (location: usb-:00:1d.1-1)
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
vid:1b3b
pid:2951
driver:uvcvideo
checking format: 1196444237
VIDIOC_S_FORMAT - Unable to set format: Input/output error
Init v4L2 failed !!
Init video returned -2
trying minimum setup ...
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951) (location: usb-:00:1d.1-1)
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
vid:1b3b
pid:2951
driver:uvcvideo
checking format: 1196444237
VIDIOC_S_FORMAT - Unable to set format: Input/output error
Init v4L2 failed !!
ERROR: Minimum Setup Failed.
Exiting...
free audio mutex
VIDIOC_REQBUFS - Failed to delete buffers: Invalid argument (errno 22)
closed v4l2 strutures
free controls - vidState
cleaned allocations - 100%
Closing portaudio ...OK
Terminated.
are you sure with the web-page? i cannot see a relationship between
dvb and uvcvideo. shouldn't i download the most recent driver from
http://linux-uvc.berlios.de/#download ?
thank you,
joe
On Wed, Dec 9, 2009 at 11:20 PM, Paulo Assis pj.as...@gmail.com wrote:
Hi, could you try the following:
echo 2 /sys/module/uvcvideo/parameters/quirks
this will set uvcvideo quirks to 2
or you can also try the latest uvcvideo:
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
please if you can, use the latest version for guvcview (1.2.1) :D
Regards,
Paulo
2009/12/9 Jozef Riha jose1...@gmail.com:
[j...@darkstar ~]$ LC_ALL=C guvcview --verbose
guvcview 1.1.4
video_device: /dev/video0
vid_sleep: 0
cap_meth: 1
resolution: 640 x 480
windowsize: 480 x 700
vert pane: 0
spin behavior: 0
mode: mjpg
fps: 1/25
Display Fps: 0
bpp: 0
hwaccel: 1
avi_format: 0
sound: 1
sound Device: 0
sound samp rate: 0
sound Channels: 0
Sound Block Size: 1 seconds
Sound Format: 80
Sound bit Rate: 160 Kbps
Pan Step: 2
Re: v4l-dvb from source on 2.6.31.5 opensuse kernel - not working
2009/12/9 Valerio Bontempi valerio.bonte...@gmail.com: 2009/12/9 Paulo Assis pj.as...@gmail.com: Hi, I've just responded to a similar issue in the linux-uvc list: https://lists.berlios.de/pipermail/linux-uvc-devel/2009-December/005391.html Do you also have insertion errors when modprobing the driver under opensuse? If so just follow the instructions :D, they worked in the above case. Best regards, Paulo 2009/12/9 Valerio Bontempi valerio.bonte...@gmail.com: Hi all, I am trying to install v4l-dvb drivers from source because my device (Terratec Cinergy T XS, usb device DVB only) isn't supported by official v4l-dvb released in last kernel version yet: it is simply detected with the wrong firmware, but modifing the source code of the driver is works fine, tested successfully on ubuntu 9.10 (I have already submitted the patch to v4l team). I compiled v4l-dvb drivers and installed them through make install, but then v4l-dvb driver is not working anymore: the video device is not created, and I don't find any information about my device in dmesg (neither the message about the wrong firmware). So I am supposing that v4l-dvb is not working at all. Does someone know how I can understand where is the problem? Best regards Valerio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I checked I have no .gz file in whole /lib/modules dir and in its subdirectories but the ouput of 'modprobe em28xx' is #modprobe em28xx WARNING: Error inserting ir_common (/lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/common/ir-common.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting v4l2_compat_ioctl32 (/lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/v4l2-compat-ioctl32.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting v4l1_compat (/lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/v4l1-compat.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting videodev (/lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/videodev.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting v4l2_common (/lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/v4l2-common.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting em28xx (/lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/em28xx/em28xx.ko): Unknown symbol in module, or unknown parameter (see dmesg) and from dmesg [ 2080.998842] videobuf_vmalloc: disagrees about version of symbol videobuf_queue_core_init [ 2080.998864] videobuf_vmalloc: Unknown symbol videobuf_queue_core_init [ 2080.999053] videobuf_vmalloc: disagrees about version of symbol videobuf_queue_cancel [ 2080.999064] videobuf_vmalloc: Unknown symbol videobuf_queue_cancel [ 2476.403046] videobuf_vmalloc: disagrees about version of symbol videobuf_queue_core_init [ 2476.403066] videobuf_vmalloc: Unknown symbol videobuf_queue_core_init [ 2476.403277] videobuf_vmalloc: disagrees about version of symbol videobuf_queue_cancel [ 2476.403290] videobuf_vmalloc: Unknown symbol videobuf_queue_cancel Valerio, This is clearly caused by old modules still laying around. In the case of Chris he just uninstalled then reinstalled everything related to v4l then build v4l-dvb by following the instructions on the v4l-dvb wiki (http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers): # make distclean # make menuconfig[this is optional] # make # make install # make unload # modprobe em28xx That solved is problem. Best regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MSI StarCam working in vlc only (with poor colors)
Hi, could you try the following:
echo 2 /sys/module/uvcvideo/parameters/quirks
this will set uvcvideo quirks to 2
or you can also try the latest uvcvideo:
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
please if you can, use the latest version for guvcview (1.2.1) :D
Regards,
Paulo
2009/12/9 Jozef Riha jose1...@gmail.com:
[j...@darkstar ~]$ LC_ALL=C guvcview --verbose
guvcview 1.1.4
video_device: /dev/video0
vid_sleep: 0
cap_meth: 1
resolution: 640 x 480
windowsize: 480 x 700
vert pane: 0
spin behavior: 0
mode: mjpg
fps: 1/25
Display Fps: 0
bpp: 0
hwaccel: 1
avi_format: 0
sound: 1
sound Device: 0
sound samp rate: 0
sound Channels: 0
Sound Block Size: 1 seconds
Sound Format: 80
Sound bit Rate: 160 Kbps
Pan Step: 2 degrees
Tilt Step: 2 degrees
Video Filter Flags: 0
image inc: 0
profile(default):/home/jose/default.gpfl
starting portaudio...
language catalog= dir:/usr/share/locale type:C lang:C cat:guvcview.mo
(guvcview:31380): GLib-GObject-WARNING **: IA__g_object_set_valist:
object class `GtkSettings' has no property named `gtk-button-images'
mjpg: setting format to 1196444237
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951) (location: usb-:00:1d.1-1)
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
checking format: 1196444237
VIDIOC_S_FORMAT - Unable to set format: Input/output error
Init v4L2 failed !!
Init video returned -2
trying minimum setup ...
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951) (location: usb-:00:1d.1-1)
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
checking format: 1196444237
VIDIOC_S_FORMAT - Unable to set format: Input/output error
Init v4L2 failed !!
ERROR: Minimum Setup Failed.
Exiting...
Terminated.
On Wed, Dec 9, 2009 at 10:53 PM, Paulo Assis pj.as...@gmail.com wrote:
Hi,
Could you please try guvcview ( http://guvcview.berlios.de )
Please post me the output of guvcview --verbose
Best regards,
Paulo
2009/12/9 Jozef Riha jose1...@gmail.com:
Jozef Riha jose1711 at gmail.com writes:
Hello dear ML members,
I wonder whether you can help me with the following issue. My webcam
MSI StarCam (http://www.aaronpc.cz/produkty/msi-starcam-370i)
identified as
...
Sorry I forgot to add kernel version. It is 2.6.32, config at
http://repos.archlinux.org/wsvn/packages/kernel26/repos/core-i686/config
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MSI StarCam working in vlc only (with poor colors)
You must reload the driver,
rmmod uvcvideo
modprobe uvcvideo
otherwise the quirks want have any effect.
uvcvideo is now mantained in the mercurial repo at linuxtv,
installing v4l-dvb will also install uvcvideo, but if you want, just
follow the instructions on the wiki to compile, but use:
hg clone http://linuxtv.org/hg/~pinchartl/uvcvideo/
so that you get the very latest (testing) uvc code.
In any case the quirks should be enough:
http://lists.berlios.de/pipermail/linux-uvc-devel/2009-October/005235.html
Best regards,
Paulo
2009/12/9 Jozef Riha jose1...@gmail.com:
setting quirks to 2 unfortunately did not help. gucview's 1.2.1 output below
[j...@darkstar ~]$ LC_ALL=C guvcview --verbose
guvcview 1.2.1
unexpected integer value (1) for snd_numsec
Strings must be quoted
video_device: /dev/video0
vid_sleep: 0
cap_meth: 1
resolution: 640 x 480
windowsize: 480 x 700
vert pane: 0
spin behavior: 0
mode: mjpg
fps: 1/25
Display Fps: 0
bpp: 0
hwaccel: 1
avi_format: 0
sound: 1
sound Device: 0
sound samp rate: 0
sound Channels: 0
Sound delay: 0 nanosec
Sound Format: 80
Sound bit Rate: 160 Kbps
Pan Step: 2 degrees
Tilt Step: 2 degrees
Video Filter Flags: 0
image inc: 0
profile(default):/home/jose/default.gpfl
starting portaudio...
language catalog= dir:/usr/share/locale type:C lang:C cat:guvcview.mo
mjpg: setting format to 1196444237
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951) (location: usb-:00:1d.1-1)
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
vid:1b3b
pid:2951
driver:uvcvideo
checking format: 1196444237
VIDIOC_S_FORMAT - Unable to set format: Input/output error
Init v4L2 failed !!
Init video returned -2
trying minimum setup ...
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951) (location: usb-:00:1d.1-1)
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
vid:1b3b
pid:2951
driver:uvcvideo
checking format: 1196444237
VIDIOC_S_FORMAT - Unable to set format: Input/output error
Init v4L2 failed !!
ERROR: Minimum Setup Failed.
Exiting...
free audio mutex
VIDIOC_REQBUFS - Failed to delete buffers: Invalid argument (errno 22)
closed v4l2 strutures
free controls - vidState
cleaned allocations - 100%
Closing portaudio ...OK
Terminated.
are you sure with the web-page? i cannot see a relationship between
dvb and uvcvideo. shouldn't i download the most recent driver from
http://linux-uvc.berlios.de/#download ?
thank you,
joe
On Wed, Dec 9, 2009 at 11:20 PM, Paulo Assis pj.as...@gmail.com wrote:
Hi, could you try the following:
echo 2 /sys/module/uvcvideo/parameters/quirks
this will set uvcvideo quirks to 2
or you can also try the latest uvcvideo:
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
please if you can, use the latest version for guvcview (1.2.1) :D
Regards,
Paulo
2009/12/9 Jozef Riha jose1...@gmail.com:
[j...@darkstar ~]$ LC_ALL=C guvcview --verbose
guvcview 1.1.4
video_device: /dev/video0
vid_sleep: 0
cap_meth: 1
resolution: 640 x 480
windowsize: 480 x 700
vert pane: 0
spin behavior: 0
mode: mjpg
fps: 1/25
Display Fps: 0
bpp: 0
hwaccel: 1
avi_format: 0
sound: 1
sound Device: 0
sound samp rate: 0
sound Channels: 0
Sound Block Size: 1 seconds
Sound Format: 80
Sound bit Rate: 160 Kbps
Pan Step: 2 degrees
Tilt Step: 2 degrees
Video Filter Flags: 0
image inc: 0
profile(default):/home/jose/default.gpfl
starting portaudio...
language catalog= dir:/usr/share/locale type:C lang:C cat:guvcview.mo
(guvcview:31380): GLib-GObject-WARNING **: IA__g_object_set_valist:
object class `GtkSettings' has no property named `gtk-button-images'
mjpg: setting format to 1196444237
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951) (location: usb-:00:1d.1-1)
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
checking format: 1196444237
VIDIOC_S_FORMAT - Unable to set format: Input/output error
Init v4L2 failed !!
Init video returned -2
trying minimum setup ...
capture method = 1
video device: /dev/video0
/dev/video0 - device 1
Init. UVC Camera (1b3b:2951
Re: [Linux-uvc-devel] [PATCH] uvc: kmalloc failure ignored in uvc_ctrl_add_ctrl()
Laurent, That's not enough to prevent a kernel crash. The driver can try to dereference ctrl-data if ctrl-info isn't NULL. You should only set ctrl-info if allocationg succeeds. Something like ctrl-data = kmalloc(ctrl-info-size * UVC_CTRL_NDATA, GFP_KERNEL); if (ctrl-data == NULL) return -ENOMEM; ctrl-info = info; Without reading any code this doesn't seem correct, how can you use ctrl-info-size if you haven't set ctrl-info yet? Did you mean something like this: ctrl-data = kmalloc(info-size * UVC_CTRL_NDATA, GFP_KERNEL); if (ctrl-data == NULL) return -ENOMEM; ctrl-info = info; Like I said I haven't read the code but this looks better. Best regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
