Re: [Linux-uvc-devel] [ANNOUNCE] Mailing list move to SourceForge
Hello everybody, It looks like the Sourceforge administration team needs more than two weeks to handle a mass-subscription request :-S As Berlios will close today, I have no choice but to ask you to manually subscribe to the new mailing list at https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel. I'm sorry for the inconvenience. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [patch] add report file to debugfs
Hi Alexey, Thanks for the patch, and sorry for the late reply. On Monday 21 November 2011 15:51:47 Alexey Fisher wrote: Hi Laurent, here is my version of bug_report file for debugfs. It include usb.id, dmi.system.product (for upsidedown report). And stream specific information. I think it is good size for initial patch. I near future i would like to add control call count and control error rate to stats. And probably firs urb error number to report file. I think it will be enough to provide needed info for troubleshooting. I got a couple of comments regarding both the purpose of the patch and its implementation. I'd like to discuss the purpose first. My understanding is that this new debugfs entry is meant to help diagnosing and debugging issues. This is a nice thing, but most of the debugging information (such as the USB VID:PID and the DMI information) can already be obtained using lsusb and dmidecode. Duplicating in debugfs information that is already available through other means isn't something I'm very fond of. Sure, dmidecode needs to be run as root, but if the user can't figure that out I don't think getting him to moutn debugfs will be a great success either :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [faq] test cases
Hi Alexey, On Wednesday 30 November 2011 16:16:13 Alexey Fisher wrote: Hi Laurent, here are new ideas for FAQ: Thanks (sorry for the late reply again) - I got a new webcam or laptop with build in cam, but it's not working, what should i do? UVC (usb video class) is same kind standard class like UMS (usb mass storage). One of good UMS examples is usb stick. If you will need to install driver to use usb stick it will make no sense and if it is not working on linux it is most probably broken. The purpose of the UVC class is already explained on the home page. Same situation is with UVC webcams. *If it is not working with modern linux distribution or any modern linux kernel, then this device is most probably broken!* And if you still can, then give or send it back! - With app XYZ my webcam is not working, is my cam or app is broken? there are different apps to test webcam: luvcview, guvcview, cheese, mplayer, vlc, skype. We prefer to test it with luvcview or guvcview. The cams can also support different formats, yuv, jpeg, ... in this case try different. PS: Please add reminder on first page: read FAQ before send email. There's already a FAQ entry about troubleshooting devices that don't work. Instead of adding a second one, I've updated the existing one. Thanks for the ideas. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [ANNOUNCE] Mailing list move to SourceForge
Hi everybody, Berlios will unfortunately close on December the 31st. I have thus decided to move the linux-uvc-devel to SourceForge. I've filed a support request with SourceForge to mass-subscribe the existing mailing list members to the new list, while retaining the digest option (other option may be lost, sorry for the inconvenience). You will likely receive an e-mail to inform you of your subscription to the new list in the near future. You can already visit https://lists.sourceforge.net/lists/listinfo/linux-uvc- devel for information about the new list. Please keep using the Berlios list for now. I will disable it after receiving the mass subscription confirmation, and ask SourceForge to import the list archives. -- Best regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Sweex WC061 HD Webcam Sliver
Hi Alexey, On Thursday 17 November 2011 08:39:30 Alexey Fisher wrote: Am 14.11.2011 20:20, schrieb Michael Tandy: I did some more experiments with this webcam, and with a nasty hack got it working. Basically the problem seems to be the frame interval requested. If I replace line 175 of uvc_v4l2.c [1] with probe-dwFrameInterval = 250; the camera works fine in mjpeg mode. The frame interval behaves oddly in this camera, in that if you set the frame interval above a certain threshold the camera seems to ignore it and send frames at whatever rate it feels like, but if you set it below a certain threshold the camera exhibits the bug I've described above, sending back corrupted frames and error codes. Most likely a firmware bug, as I can't imagine anyone would design a camera to function that way. I assume we wouldn't be inclined to patch the kernel to deal with this one camera's weird behaviour? [1] http://lxr.free-electrons.com/source/drivers/media/video/uvc/uvc_v4l2.c? v=2.6.28#L175 Hi Laurent, i still think that checking the reason of error bit, make sense. In this case we check the reason of error bit. If we get permanent buffer underrun or overrun, we should switch to different framerate. Or notify user to do that. I could make sense, but I think there are more pressing issues than that :-) Automatically lowering the frame rate when we detect that the device is buggy is really icing on the cake (and I'm not even sure whether devices will correctly report the error causes...). And probably add the error bit handler to the uvc status list on your page :) The goal is to shorten the list, not make it longer ;-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Sweex WC061 HD Webcam Sliver
Hi Michael,
On Monday 14 November 2011 20:20:12 Michael Tandy wrote:
I did some more experiments with this webcam, and with a nasty hack
got it working.
Basically the problem seems to be the frame interval requested. If I
replace line 175 of uvc_v4l2.c [1] with
probe-dwFrameInterval = 250;
the camera works fine in mjpeg mode.
The frame interval behaves oddly in this camera, in that if you set
the frame interval above a certain threshold the camera seems to
ignore it and send frames at whatever rate it feels like, but if you
set it below a certain threshold the camera exhibits the bug I've
described above, sending back corrupted frames and error codes. Most
likely a firmware bug, as I can't imagine anyone would design a camera
to function that way.
I assume we wouldn't be inclined to patch the kernel to deal with this
one camera's weird behaviour?
That could be done, but it would likely require something different than the
current quirks system.
What is the frame interval threshold value for the device ?
[1]
http://lxr.free-electrons.com/source/drivers/media/video/uvc/uvc_v4l2.c?v=
2.6.28#L175
On 3 November 2011 10:20, Laurent Pinchart wrote:
On Wednesday 07 September 2011 08:11:48 Alexey Fisher wrote:
Am 06.09.2011 12:53, schrieb Michael Tandy:
[99317.553237] uvcvideo: uvc_v4l2_ioctl(VIDIOC_STREAMON)
[99317.554747] uvcvideo: uvc_v4l2_poll
[99333.472385] uvcvideo: Dropping payload (error bit set).
[99333.472389] uvcvideo: Frame complete (EOF found).
[99333.472391] uvcvideo: EOF in empty payload.
[99333.472429] uvcvideo: uvc_v4l2_poll
[99333.472438] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
[99333.472447] uvcvideo: Dequeuing buffer 0 (3, 2676 bytes).
hmm... the camera notify us about with error bit set, but current driver
will just drop it and mark the buffer as faulty.
As the data can't be trusted, the uvcvideo driver decides to drop the
packet. Alternatively the packet could be processed normally and the
buffer market as bad. It would then be up to the application to decide
what to do with such buffers (you will have to set the no_drop module
parameter to 1, as the driver drops faulty buffers by default).
The following patch should implement that behaviour, in case you want to
test it.
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c index ffd1158..baa5850 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -419,13 +419,6 @@ static int uvc_video_decode_start(struct
uvc_streaming *stream, if (len 2 || data[0] 2 || data[0] len)
return -EINVAL;
- /* Skip payloads marked with the error bit (error frames). */
- if (data[1] UVC_STREAM_ERR) {
- uvc_trace(UVC_TRACE_FRAME, Dropping payload (error bit
- set).\n);
- return -ENODATA;
- }
-
fid = data[1] UVC_STREAM_FID;
/* Increase the sequence number regardless of any buffer states,
so @@ -442,6 +435,13 @@ static int uvc_video_decode_start(struct
uvc_streaming *stream, return -ENODATA;
}
+ /* Mark the buffer as bad if the error bit is set. */
+ if (data[1] UVC_STREAM_ERR) {
+ uvc_trace(UVC_TRACE_FRAME, Marking buffer as bad (error
bit + set).\n);
+ buf-error = 1;
+ }
+
/* Synchronize to the input stream by waiting for the FID bit to
be * toggled when the the buffer state is not UVC_BUF_STATE_ACTIVE. *
stream-last_fid is initialized to -1, so the first isochronous
--
Regards,
Laurent Pinchart
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH] uvcvideo: correct error message for debugfs stats file
Hi Alexey,
Thanks for the patch.
As your original patch hasn't been pushed to upstream yet, I've combined it
with this patch.
On Thursday 17 November 2011 09:16:11 Alexey Fisher wrote:
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_debugfs.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_debugfs.c
b/drivers/media/video/uvc/uvc_debugfs.c index bdba016..1b0087b 100644
--- a/drivers/media/video/uvc/uvc_debugfs.c
+++ b/drivers/media/video/uvc/uvc_debugfs.c
@@ -97,8 +97,7 @@ int uvc_debugfs_init_stream(struct uvc_streaming *stream)
dent = debugfs_create_file(stats, 0600, stream-debugfs_dir,
stream, uvc_debugfs_stats_fops);
if (IS_ERR_OR_NULL(dent)) {
- uvc_printk(KERN_INFO, Unable to create debugfs %s
directory.\n,
-dir_name);
+ uvc_printk(KERN_INFO, Unable to create debugfs stats file.\n);
uvc_debugfs_cleanup_stream(stream);
return -ENODEV;
}
--
Regards,
Laurent Pinchart
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Suggestion for FAQ update
Hi Alexey, On Thursday 10 November 2011 13:16:41 Alexey Fisher wrote: Hi Laurent, i think it is good time to update FAQ. And add notice about reading the FAQ before ask some thing on maeling list. My suggestion entry to FAQ: I have an UVC webcam but it is not working. What do you need to troubleshoot it? 1. Read How do I find out whether my camera is a UVC device or not? 2. Create usb dump file and attach it to email: lsusb -vd 046d:08cb lsusb_dump 3. Enable debug for uvcvideo module: sudo echo 0xfff /sys/module/uvcvideo/parameters/trace 4. reproduce the problem 5. attach dmesg to email dmesg dmesg PS: Please do not use HTML formatet mails. == Your suggestions? Thanks for the suggestion. I've updated the FAQ (after modifying the text slightly). -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Dual sensor, single controller, one USB Device
Hi, On Friday 04 November 2011 20:05:23 cheshirekow wrote: On Fri, 2011-11-04 at 14:44 +0100, Laurent Pinchart wrote: On Friday 04 November 2011 13:46:36 cheshirekow wrote: On Wed, 2011-11-02 at 17:38 +0100, Laurent Pinchart wrote: On Saturday 29 October 2011 09:30:04 Alexey Fisher wrote: Am 28.10.2011 18:01, schrieb cheshirekow: On Sun, 2011-10-23 at 13:50 -0400, cheshirekow wrote: On 10/22/2011 03:16 AM, Alexey Fisher wrote: Can you please attach the output of this command: lsusb -vd 10f1:1a26 lsusb_dump Sure. The dump file is attached. Thanks! Has anyone by chance managed to take a look at this lsusb dump? To recap: the HP Slate has two integrated we cams: One forward facing for video calls, and one higher-resolution rear-facing for snapping photos. There appears to be a single controller for both cameras. In linux, lsusb only shows one webcam device. In windows, the device manager also shows only one device for the webcam. However, in windows applications that use the webcam (i.e. HP's webcam application, and in skype) I'm able to select which one to use as an option. In linux, there is only one video device, /dev/video0. There does not appear to be any control available from uvcdynctrl or within vlc to select which physical camera to use. I've tried setting the resolution in vlc when I use the open capture device menu item. I know that the forward facing camera is VGA so I tried specifying 640x480, but the result is that it shows the rear-camera stream at a low resolution, rather then showing the forward-camera stream. I'd appreciate any suggestions on how to get the forward-facing camera to work in linux (for skype/google video calls). Also, if it is clear that this facility is not available in UVC and that there is no way this is possilble, that would also be useful information. Thanks again Hi, suddenly i do not see any control to switch the sensor. I assume there can be two variants how it may work: 1. vendor specific extension unit for uvc 2. or usb mode switcher if both sensors have same capabilities, the 1. make sense. If not then second. Because this usb dump report settings only for one sensor. For 1. it will be probably possible to control it with libwebcam. For 2. it should be possible to control it with some kind of usb_modeswitch (i'm not up to date). To find what it is actually, there can be fallowing options: 1. sniff usb traffic 2. see if the windows driver has some advise for us 3. unscrew your laptop and find what control use your webcam. My guess is that the camera uses either an extension unit (XU) control or a vendor-specific request to select between the two sensors (which is very unfortunate, given that the UVC specification has explicit support for dual- sensor cameras, and I would have liked to test that code :-)). Thanks for the information. It is unfortunate that the camera doesn't take advantage of what is already in the spec. Let's start with the XU control. I've attached a patch for the yavta test application (http://git.ideasonboard.org/?p=yavta.git;a=summary) to this e- mail. Could you please apply it, compile the application with Ok sure. I downloaded the test, applied the patch, and ran it with the following output: Device /dev/video0 opened. Device `HP Webcam' on `usb-:00:1d.7-8' is a video capture device. XU control 0: info GET SET (0x03) 2 bytes XU control 1: info GET SET (0x03) 64 bytes XU control 2: info GET SET (0x03) 64 bytes XU control 3: info GET SET (0x03) 2 bytes XU control 4: info GET SET (0x03) 2 bytes XU control 5: info GET SET (0x03) 2 bytes XU control 6: info GET SET (0x03) 2 bytes XU control 7: info GET SET (0x03) 2 bytes Video format: YUYV (56595559) 640x480 buffer size 614400 Those XU controls seem to be quite generic, and are found in other webcams that use the same chipset. They probably allow direct access to the sensor and bridge registers. More information will be needed to find out how to select the sensor. I'm afraid USB sniffing in windows seems to be unavoidable. I will need a trace of all USB control requests (if your USB sniffer allows filtering out the isochronous transfers, please do so) sent to the device when you switch from one sensor to the other one. Ok, so I've started trying to sniff some data from windows. I've done this before but it was so long ago I think I forgot everything I knew about USB hardware stuff. Anyway, I'm trying to use usbsnoopy (sourceforge.net/projects/usbsnoop). I'm not sure this is working. There are two devices listed which
Re: [Linux-uvc-devel] Annoying HTTPS in link to list archive.
Hi Ajay, On Friday 04 November 2011 06:38:20 Ajay Bhargav wrote: - Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Friday 30 September 2011 22:41:29 Kaz Kylheku wrote: Hi all, If you view this list's page (note the HTTP here) http://lists.berlios.de/mailman/listinfo/linux-uvc-devel the link which it gives to the list archives is HTTPS! Because of this stupidity, Google has indexed this list using HTTPS URLs. You have to accept the self-signed security certificate when you navigate to the archive pages from a Google search result. Can someone fix that? I have no control over the link to the archives in http://lists.berlios.de/mailman/listinfo/linux-uvc-devel. I could ask Google to remove the https:// URLs from its cache, but they will come back anyway, so it's a bit pointless. Berlios will close at the end of the year and the mailing list will move elsewhere, hopefully fixing the problem. You can put a redirect in your .htaccess file if someone tries to access https links then he/she will be redirected to http://... Put a permanent redirect so that google will automatically remove all the https links from its cache. Hope this is helpful :) The problem is that I have no control over lists.berlios.de. I can't modify the .htaccess file. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH 1/2] uvcvideo: Add debugfs support
Hi Alexey, On Friday 04 November 2011 09:19:45 Alexey Fisher wrote: Am 03.11.2011 17:27, schrieb Laurent Pinchart: Create a debugfs entry per UVC stream. This will be used to export stream statistics. Signed-off-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com Ok, i see you made it in mind more fore online statistic. I wonted to make it more for postmortum trouble shooting. For example i added start time and time of first frame because some apps make problems if cam starting too slow. I also added time of first error_bit and so. (probably not in the patch i send you before) It's indeed not in the latest patch I've got. The question is, do you wont to make separate files for verbose report and for statistic? My idea is, if some body has some problem with the cam, instead of telling reload module with ...blabla... i can just tell: reproduce the error and send me content of /sys/debug...bla ... You know what i mean? For example we can add firs usb error we got and time stamp of it, to make it more computer forensic friendly :) That sounds like a good idea to me. The real question will then be to pick what information to report. Things like the selected alternate setting and the bandwidth requested by the camera are very important for instance. I'd like that to be exposed through a separate file, as that information isn't really statistics. Are you OK with such an approach ? So if you prefer to make separate files i give my SoB :) Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Dual sensor, single controller, one USB Device
Hi, On Friday 04 November 2011 13:46:36 cheshirekow wrote: On Wed, 2011-11-02 at 17:38 +0100, Laurent Pinchart wrote: On Saturday 29 October 2011 09:30:04 Alexey Fisher wrote: Am 28.10.2011 18:01, schrieb cheshirekow: On Sun, 2011-10-23 at 13:50 -0400, cheshirekow wrote: On 10/22/2011 03:16 AM, Alexey Fisher wrote: Can you please attach the output of this command: lsusb -vd 10f1:1a26 lsusb_dump Sure. The dump file is attached. Thanks! Has anyone by chance managed to take a look at this lsusb dump? To recap: the HP Slate has two integrated we cams: One forward facing for video calls, and one higher-resolution rear-facing for snapping photos. There appears to be a single controller for both cameras. In linux, lsusb only shows one webcam device. In windows, the device manager also shows only one device for the webcam. However, in windows applications that use the webcam (i.e. HP's webcam application, and in skype) I'm able to select which one to use as an option. In linux, there is only one video device, /dev/video0. There does not appear to be any control available from uvcdynctrl or within vlc to select which physical camera to use. I've tried setting the resolution in vlc when I use the open capture device menu item. I know that the forward facing camera is VGA so I tried specifying 640x480, but the result is that it shows the rear-camera stream at a low resolution, rather then showing the forward-camera stream. I'd appreciate any suggestions on how to get the forward-facing camera to work in linux (for skype/google video calls). Also, if it is clear that this facility is not available in UVC and that there is no way this is possilble, that would also be useful information. Thanks again Hi, suddenly i do not see any control to switch the sensor. I assume there can be two variants how it may work: 1. vendor specific extension unit for uvc 2. or usb mode switcher if both sensors have same capabilities, the 1. make sense. If not then second. Because this usb dump report settings only for one sensor. For 1. it will be probably possible to control it with libwebcam. For 2. it should be possible to control it with some kind of usb_modeswitch (i'm not up to date). To find what it is actually, there can be fallowing options: 1. sniff usb traffic 2. see if the windows driver has some advise for us 3. unscrew your laptop and find what control use your webcam. My guess is that the camera uses either an extension unit (XU) control or a vendor-specific request to select between the two sensors (which is very unfortunate, given that the UVC specification has explicit support for dual- sensor cameras, and I would have liked to test that code :-)). Thanks for the information. It is unfortunate that the camera doesn't take advantage of what is already in the spec. Let's start with the XU control. I've attached a patch for the yavta test application (http://git.ideasonboard.org/?p=yavta.git;a=summary) to this e- mail. Could you please apply it, compile the application with Ok sure. I downloaded the test, applied the patch, and ran it with the following output: Device /dev/video0 opened. Device `HP Webcam' on `usb-:00:1d.7-8' is a video capture device. XU control 0: info GET SET (0x03) 2 bytes XU control 1: info GET SET (0x03) 64 bytes XU control 2: info GET SET (0x03) 64 bytes XU control 3: info GET SET (0x03) 2 bytes XU control 4: info GET SET (0x03) 2 bytes XU control 5: info GET SET (0x03) 2 bytes XU control 6: info GET SET (0x03) 2 bytes XU control 7: info GET SET (0x03) 2 bytes Video format: YUYV (56595559) 640x480 buffer size 614400 Those XU controls seem to be quite generic, and are found in other webcams that use the same chipset. They probably allow direct access to the sensor and bridge registers. More information will be needed to find out how to select the sensor. I'm afraid USB sniffing in windows seems to be unavoidable. I will need a trace of all USB control requests (if your USB sniffer allows filtering out the isochronous transfers, please do so) sent to the device when you switch from one sensor to the other one. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Annoying HTTPS in link to list archive.
Hi, On Friday 30 September 2011 22:41:29 Kaz Kylheku wrote: Hi all, If you view this list's page (note the HTTP here) http://lists.berlios.de/mailman/listinfo/linux-uvc-devel the link which it gives to the list archives is HTTPS! Because of this stupidity, Google has indexed this list using HTTPS URLs. You have to accept the self-signed security certificate when you navigate to the archive pages from a Google search result. Can someone fix that? I have no control over the link to the archives in http://lists.berlios.de/mailman/listinfo/linux-uvc-devel. I could ask Google to remove the https:// URLs from its cache, but they will come back anyway, so it's a bit pointless. Berlios will close at the end of the year and the mailing list will move elsewhere, hopefully fixing the problem. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] H.264 camera options.
Hi Kaz, On Friday 30 September 2011 04:24:02 Kaz Kylheku wrote: Hi All, I'm searching for a suitable H.264 camera to use as a reference hardware for a a Linux-based embedded platform. I've seen references to the B990 from Logitech, so that looks like a good candidate. Is there anything out there which goes above 720p, maybe as high as 1080p? This is not a hard requirement, but a nice to have. It would be nice to have as capable a H.264 camera as possible for the reference. An important requirement is that the un-encoded video stream is available from the camera, not only the coded stream. It should be possible to loop back the picture without decoding anything, since decoding resources are limited on the platform, especially when we get into higher resolutions. I expect most H.264 webcams to support streaming a compressed and an uncompressed stream concurrently. However, most of them do so in a completely proprietary way, and are not supported by the uvcvideo driver at the moment. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Ajay, On Friday 09 September 2011 08:44:22 Ajay Bhargav wrote: Hi Srinivas, Patches are attached here... There are more modifications I did to uvc_video to set size of buffer + fid bit toggle after 44 MPEG2-TS packets. Why 44 ? What kind of camera are you using? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Paulo, On Friday 09 September 2011 16:05:24 Paulo Assis wrote: Well one important thing to notice is the pixel format returned by the driver, will it differentiate between avc and svc streams, or even mpeg2 ? That very much depends on the camera. Facevsion cameras seem to report MPEG2- TS but stream H.264. It then becomes difficult for the driver to know what to expose to userspace. If not maybe then it becomes harder for generic apps to decode it, unless we use a bunch of switch cases for the different cameras (something like this would be best implemented in the driver though) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] New unsupported UVC WebCam
Hi, On Sunday 11 September 2011 15:46:55 gudv...@gmail.com wrote: Hi, I bought a laptop ASUS U31SD with USB2.0 UVC VGA WebCam webcam, that doesn't work with uvcvideo driver. See info from lsusb: Bus 001 Device 004: ID 13d3:5710 IMC Networks Could you please send me the output of lsusb -v -d 13d3:5710 ? And dmesg log: [snip] [10013.494171] kernel BUG at drivers/media/media-entity.c:346! [snip] This is a known bug that was introduced in v3.0 and got fixed in both the 3.0 stable branch and in v3.1. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Sweex WC061 HD Webcam Sliver
Hi,
On Wednesday 07 September 2011 08:11:48 Alexey Fisher wrote:
Am 06.09.2011 12:53, schrieb Michael Tandy:
[99317.553237] uvcvideo: uvc_v4l2_ioctl(VIDIOC_STREAMON)
[99317.554747] uvcvideo: uvc_v4l2_poll
[99333.472385] uvcvideo: Dropping payload (error bit set).
[99333.472389] uvcvideo: Frame complete (EOF found).
[99333.472391] uvcvideo: EOF in empty payload.
[99333.472429] uvcvideo: uvc_v4l2_poll
[99333.472438] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
[99333.472447] uvcvideo: Dequeuing buffer 0 (3, 2676 bytes).
hmm... the camera notify us about with error bit set, but current driver
will just drop it and mark the buffer as faulty.
As the data can't be trusted, the uvcvideo driver decides to drop the packet.
Alternatively the packet could be processed normally and the buffer market as
bad. It would then be up to the application to decide what to do with such
buffers (you will have to set the no_drop module parameter to 1, as the driver
drops faulty buffers by default).
The following patch should implement that behaviour, in case you want to test
it.
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index ffd1158..baa5850 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -419,13 +419,6 @@ static int uvc_video_decode_start(struct uvc_streaming
*stream,
if (len 2 || data[0] 2 || data[0] len)
return -EINVAL;
- /* Skip payloads marked with the error bit (error frames). */
- if (data[1] UVC_STREAM_ERR) {
- uvc_trace(UVC_TRACE_FRAME, Dropping payload (error bit
- set).\n);
- return -ENODATA;
- }
-
fid = data[1] UVC_STREAM_FID;
/* Increase the sequence number regardless of any buffer states, so
@@ -442,6 +435,13 @@ static int uvc_video_decode_start(struct uvc_streaming
*stream,
return -ENODATA;
}
+ /* Mark the buffer as bad if the error bit is set. */
+ if (data[1] UVC_STREAM_ERR) {
+ uvc_trace(UVC_TRACE_FRAME, Marking buffer as bad (error bit
+ set).\n);
+ buf-error = 1;
+ }
+
/* Synchronize to the input stream by waiting for the FID bit to be
* toggled when the the buffer state is not UVC_BUF_STATE_ACTIVE.
* stream-last_fid is initialized to -1, so the first isochronous
According to uvc specification v1.1 in 4.3.1.7 Stream Error Code
Control we can/should check the error reason:
---
The host software should send a GET_CUR request to this control to
determine the error when one of the following events occurs:
- The Error bit in the video or still image payload header is set by the
device
For scenarios where the host is transmitting video data to the device,
the host can not use the Error bit in the payload header to detect a
device error. Therefore, in order to determine when a streaming error
occurs, the host must rely on either a Control Change interrupt from the
device or a bulk endpoint stall.
I'm suddenly not so good to implement ne things without testing and
probing. May be Laurent can do this? Or i need access to the webcam.
Retrieving the cause of the error requires sending a control request, which
can't be done in interrupt context. This could be implemented, but won't be
trivial, and I'm not sure it will give any useful information anyway. Knowing
whether the error comes from a buffer underrun, a buffer overrun or something
else won't let the driver fix the error.
--
Regards,
Laurent Pinchart
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] UVC H264 Support
Hi Max, On Tuesday 25 October 2011 08:53:15 Max Lapshin wrote: Looks like this camera is not supported for no serious reasons. One of the reasons is that nobody has submitted a proper patch yet. I'll let you decide whether it's a serious reason or not :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Working with Logitech B990: Issues.
Hi Kaz, On Thursday 03 November 2011 02:20:30 Kaz Kylheku wrote: Hey all, I'm working with the B990 on an ARM-based embedded system based on linux-2.6.27.47. H.264 is coming out of the cam, but I don't see an SPS/PPS, and all the frames are P slices, e.g. like this and similar: 00 00 00 01 61 9a 00 38 37 e0 20 30 ... I can't really help you with that, I haven't tried H.264 on a B990 yet (one of the reasons is that I don't own any B990 :-)). Secondly, after some period of running, the USB controller throws up an over-current error, and then the device is not usable without a reboot. Maybe this big sucker really draws too much current? That's not impossible. At least one Logitech webcam actually runs Linux embedded in the device (see https://opensource.logitech.com/logitech/), the B990 might as well. This could explain why the current consumption is higher than with microcontroller-based cameras. Usually I am not able to two consecutive successful opens of the device. By the way, I patched the driver to make the trace and quirks sysctl parameters, since I have it compiled into the kernel. Aren't uvcvideo module parameters available through /sys/modules/uvcvideo/parameters/ even when uvcvideo is compiled in ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Robert, On Thursday 03 November 2011 12:34:55 Robert Krakora wrote: Hi Guys, I did not see audio in the MPEG2 TS stream that I was able to get out of the FaceVsion camera. I purchased one for Laurent for development purposes. It sounds like he has been working with it some. Yes I've finally started working on it. Thanks for the hardware. I'll post prototype patches to the list. I've been able to get a video stream out of the device, but it looks pretty bad when played in mplayer. I'm not sure who is at fault that. I wish these vendors would come to some kind of consensus on how to expose H.264 via USB interface. The latest version of the UVC 1.1 specification includes an H.264 payload format. Unfortunately Microsoft, Logitech and Skype designed something really horrible, without much input from anyone else. It seems like it would make life easier for the UVC developers such as Laurent. I should come up with my own H.264 UVC payload specification :-) If Laurent needs any more makes/models of H.264 cameras for development, I will accommodate. Thank you. I will first try to finish the Facevsion support. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [PATCH 1/2] uvcvideo: Add debugfs support
Create a debugfs entry per UVC stream. This will be used to export
stream statistics.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/Makefile |2 +-
drivers/media/video/uvc/uvc_debugfs.c | 76 +
drivers/media/video/uvc/uvc_driver.c | 21 +++--
drivers/media/video/uvc/uvcvideo.h|9
4 files changed, 102 insertions(+), 6 deletions(-)
create mode 100644 drivers/media/video/uvc/uvc_debugfs.c
diff --git a/drivers/media/video/uvc/Makefile b/drivers/media/video/uvc/Makefile
index 2071ca8..c26d12f 100644
--- a/drivers/media/video/uvc/Makefile
+++ b/drivers/media/video/uvc/Makefile
@@ -1,5 +1,5 @@
uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o \
- uvc_status.o uvc_isight.o
+ uvc_status.o uvc_isight.o uvc_debugfs.o
ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
uvcvideo-objs += uvc_entity.o
endif
diff --git a/drivers/media/video/uvc/uvc_debugfs.c
b/drivers/media/video/uvc/uvc_debugfs.c
new file mode 100644
index 000..f58969a
--- /dev/null
+++ b/drivers/media/video/uvc/uvc_debugfs.c
@@ -0,0 +1,76 @@
+/*
+ * uvc_debugfs.c -- USB Video Class driver - Debugging support
+ *
+ * Copyright (C) 2011
+ * Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/debugfs.h
+#include linux/slab.h
+#include linux/usb.h
+
+#include uvcvideo.h
+
+/*
-
+ * Global and stream initialization/cleanup
+ */
+
+static struct dentry *uvc_debugfs_root_dir;
+
+int uvc_debugfs_init_stream(struct uvc_streaming *stream)
+{
+ struct usb_device *udev = stream-dev-udev;
+ struct dentry *dent;
+ char dir_name[32];
+
+ if (uvc_debugfs_root_dir == NULL)
+ return -ENODEV;
+
+ sprintf(dir_name, %u-%u, udev-bus-busnum, udev-devnum);
+
+ dent = debugfs_create_dir(dir_name, uvc_debugfs_root_dir);
+ if (IS_ERR_OR_NULL(dent)) {
+ uvc_printk(KERN_INFO, Unable to create debugfs %s
directory.\n,
+ dir_name);
+ return -ENODEV;
+ }
+
+ stream-debugfs_dir = dent;
+
+ return 0;
+}
+
+void uvc_debugfs_cleanup_stream(struct uvc_streaming *stream)
+{
+ if (stream-debugfs_dir == NULL)
+ return;
+
+ debugfs_remove_recursive(stream-debugfs_dir);
+ stream-debugfs_dir = NULL;
+}
+
+int uvc_debugfs_init(void)
+{
+ struct dentry *dir;
+
+ dir = debugfs_create_dir(uvcvideo, usb_debug_root);
+ if (IS_ERR_OR_NULL(dir)) {
+ uvc_printk(KERN_INFO, Unable to create debugfs directory\n);
+ return -ENODATA;
+ }
+
+ uvc_debugfs_root_dir = dir;
+ return 0;
+}
+
+void uvc_debugfs_cleanup(void)
+{
+ if (uvc_debugfs_root_dir != NULL)
+ debugfs_remove_recursive(uvc_debugfs_root_dir);
+}
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index 750ab68..a240d43 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -1675,6 +1675,8 @@ static void uvc_unregister_video(struct uvc_device *dev)
video_unregister_device(stream-vdev);
stream-vdev = NULL;
+
+ uvc_debugfs_cleanup_stream(stream);
}
/* Decrement the stream count and call uvc_delete explicitly if there
@@ -1700,6 +1702,8 @@ static int uvc_register_video(struct uvc_device *dev,
return ret;
}
+ uvc_debugfs_init_stream(stream);
+
/* Register the device with V4L. */
vdev = video_device_alloc();
if (vdev == NULL) {
@@ -2405,17 +2409,24 @@ struct uvc_driver uvc_driver = {
static int __init uvc_init(void)
{
- int result;
+ int ret;
- result = usb_register(uvc_driver.driver);
- if (result == 0)
- printk(KERN_INFO DRIVER_DESC ( DRIVER_VERSION )\n);
- return result;
+ uvc_debugfs_init();
+
+ ret = usb_register(uvc_driver.driver);
+ if (ret 0) {
+ uvc_debugfs_cleanup();
+ return ret;
+ }
+
+ printk(KERN_INFO DRIVER_DESC ( DRIVER_VERSION )\n);
+ return 0;
}
static void __exit uvc_cleanup(void)
{
usb_deregister(uvc_driver.driver);
+ uvc_debugfs_cleanup();
}
module_init(uvc_init);
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 882159a..2d45e58 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -403,6 +403,9 @@ struct
Re: [Linux-uvc-devel] [RFC PATCH] uvc debugfs interface, initial patch
Hi Alexey, On Wednesday 21 September 2011 08:27:06 Alexey Fisher wrote: this is initial patch for debugfs interface. I didn't implemented all requests, i think the size of this patch is any way too big now. I've finally found time to go through your patch :-) I'm sorry for the way too long delay. Here is how it's working. After driver is loaded it create debugfs/usb/uvcvideo directory. If some device is attached it create device dir like this: 001.007_046d.0991 (first part is usb bus, second is usb id). In this directory it create file called stats. Here is the content of this file: usb id: 046d:0991, usb bus: 001:007 packet size: 944(6) state: idle -- show the state of device. capture or idle start time: 1316585466 - unix epoch time in seconds. capture time: 106 - capture time in seconds. format: YUV 4:2:2 (YUYV) resolution: 320x240 @ 30 decode_start: 846880 - this show how many payloads we started to decoding. bad_header: 0 -- haw many payloads was dropped, because of bad header uvc_empty: 604160 -- correct uvc payloads without video data uvc_stream_err: 0 -- count of payloads with err bit set sequence: 955 -- count of fid switches out_of_sync: 0 -- out of sync calls I like the patch but have lots of small comments. Instead of playing ping-pong with you to get everything fixed, I've reworked your patch. The result can be found as replies to this e-mail. First of all I've split the patch in two. The first patch adds debugfs support to the driver, and the second patch exports video stream statistics. This makes review easier. Then, I've modified statistics gathering to store per-stream stats instead of per-device as a UVC device can expose several streams. Finally I've removed the state information from the statistics, as they're not really statistics. It should be easi to add them back in a state or info debugfs file once we agree on these patches. Both patches are currently authored by me. I'll will use your name and e-mail address if you send me your SoB line. Laurent Pinchart (2): uvcvideo: Add debugfs support uvcvideo: Extract video stream statistics drivers/media/video/uvc/Makefile |2 +- drivers/media/video/uvc/uvc_debugfs.c | 136 + drivers/media/video/uvc/uvc_driver.c | 21 - drivers/media/video/uvc/uvc_video.c | 111 ++- drivers/media/video/uvc/uvcvideo.h| 39 ++ 5 files changed, 302 insertions(+), 7 deletions(-) create mode 100644 drivers/media/video/uvc/uvc_debugfs.c -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [PATCH 2/2] uvcvideo: Extract video stream statistics
Export the statistics through debugfs.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_debugfs.c | 60 ++
drivers/media/video/uvc/uvc_video.c | 111 -
drivers/media/video/uvc/uvcvideo.h| 32 +-
3 files changed, 201 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_debugfs.c
b/drivers/media/video/uvc/uvc_debugfs.c
index f58969a..bdba016 100644
--- a/drivers/media/video/uvc/uvc_debugfs.c
+++ b/drivers/media/video/uvc/uvc_debugfs.c
@@ -18,6 +18,57 @@
#include uvcvideo.h
/*
-
+ * Statistics
+ */
+
+#define UVC_DEBUGFS_BUF_SIZE 1024
+
+struct uvc_debugfs_buffer {
+ size_t count;
+ char data[UVC_DEBUGFS_BUF_SIZE];
+};
+
+static int uvc_debugfs_stats_open(struct inode *inode, struct file *file)
+{
+ struct uvc_streaming *stream = inode-i_private;
+ struct uvc_debugfs_buffer *buf;
+
+ buf = kmalloc(sizeof(*buf), GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
+ buf-count = uvc_video_stats_dump(stream, buf-data, sizeof(buf-data));
+
+ file-private_data = buf;
+ return 0;
+}
+
+static ssize_t uvc_debugfs_stats_read(struct file *file, char __user *user_buf,
+ size_t nbytes, loff_t *ppos)
+{
+ struct uvc_debugfs_buffer *buf = file-private_data;
+
+ return simple_read_from_buffer(user_buf, nbytes, ppos, buf-data,
+ buf-count);
+}
+
+static int uvc_debugfs_stats_release(struct inode *inode, struct file *file)
+{
+ kfree(file-private_data);
+ file-private_data = NULL;
+
+ return 0;
+}
+
+static const struct file_operations uvc_debugfs_stats_fops = {
+ .owner = THIS_MODULE,
+ .open = uvc_debugfs_stats_open,
+ .llseek = no_llseek,
+ .read = uvc_debugfs_stats_read,
+ .release = uvc_debugfs_stats_release,
+};
+
+/*
-
* Global and stream initialization/cleanup
*/
@@ -43,6 +94,15 @@ int uvc_debugfs_init_stream(struct uvc_streaming *stream)
stream-debugfs_dir = dent;
+ dent = debugfs_create_file(stats, 0600, stream-debugfs_dir,
+ stream, uvc_debugfs_stats_fops);
+ if (IS_ERR_OR_NULL(dent)) {
+ uvc_printk(KERN_INFO, Unable to create debugfs %s
directory.\n,
+ dir_name);
+ uvc_debugfs_cleanup_stream(stream);
+ return -ENODEV;
+ }
+
return 0;
}
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index a57f813..2ab92a7 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -358,6 +358,106 @@ static int uvc_commit_video(struct uvc_streaming *stream,
}
/*
+ * Timestamp statistics
+ */
+
+static void uvc_video_stats_decode(struct uvc_streaming *stream,
+ const __u8 *data, int len)
+{
+ unsigned int header_size;
+
+ if (stream-stats.stream.nb_frames == 0
+ stream-stats.frame.nb_packets == 0)
+ ktime_get_ts(stream-stats.stream.start_ts);
+
+ /* Make sure we have at least 2 bytes of header. */
+ if (len 2) {
+ stream-stats.frame.nb_invalid++;
+ return;
+ }
+
+ switch (data[1] (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
+ case UVC_STREAM_PTS | UVC_STREAM_SCR:
+ header_size = 12;
+ break;
+ case UVC_STREAM_PTS:
+ header_size = 6;
+ break;
+ case UVC_STREAM_SCR:
+ header_size = 8;
+ break;
+ default:
+ header_size = 2;
+ break;
+ }
+
+ /* Check for invalid headers. */
+ if (len header_size || data[0] header_size) {
+ stream-stats.frame.nb_invalid++;
+ return;
+ }
+
+ /* Record the first non-empty packet number. */
+ if (stream-stats.frame.size == 0 len header_size)
+ stream-stats.frame.first_data = stream-stats.frame.nb_packets;
+
+ /* Update the frame size. */
+ stream-stats.frame.size += len - header_size;
+
+ /* Update the packets counters. */
+ stream-stats.frame.nb_packets++;
+ if (len header_size)
+ stream-stats.frame.nb_empty++;
+
+ if (data[1] UVC_STREAM_ERR)
+ stream-stats.frame.nb_errors++;
+}
+
+static void uvc_video_stats_update(struct uvc_streaming *stream)
+{
+ struct uvc_stats_frame *frame = stream-stats.frame;
+
+ uvc_trace(UVC_TRACE_STATS, frame %u stats: %u/%u/%u packets\n,
+ stream-sequence, frame-first_data
Re: [Linux-uvc-devel] Dual sensor, single controller, one USB Device
Hi,
On Saturday 29 October 2011 09:30:04 Alexey Fisher wrote:
Am 28.10.2011 18:01, schrieb cheshirekow:
On Sun, 2011-10-23 at 13:50 -0400, cheshirekow wrote:
On 10/22/2011 03:16 AM, Alexey Fisher wrote:
Can you please attach the output of this command:
lsusb -vd 10f1:1a26 lsusb_dump
Sure. The dump file is attached.
Thanks!
Has anyone by chance managed to take a look at this lsusb dump?
To recap:
the HP Slate has two integrated we cams: One forward facing for video
calls, and one higher-resolution rear-facing for snapping photos. There
appears to be a single controller for both cameras. In linux, lsusb only
shows one webcam device. In windows, the device manager also shows only
one device for the webcam. However, in windows applications that use the
webcam (i.e. HP's webcam application, and in skype) I'm able to select
which one to use as an option. In linux, there is only one video
device, /dev/video0.
There does not appear to be any control available from uvcdynctrl or
within vlc to select which physical camera to use. I've tried setting
the resolution in vlc when I use the open capture device menu item. I
know that the forward facing camera is VGA so I tried specifying
640x480, but the result is that it shows the rear-camera stream at a low
resolution, rather then showing the forward-camera stream.
I'd appreciate any suggestions on how to get the forward-facing camera
to work in linux (for skype/google video calls). Also, if it is clear
that this facility is not available in UVC and that there is no way this
is possilble, that would also be useful information.
Thanks again
Hi,
suddenly i do not see any control to switch the sensor. I assume there
can be two variants how it may work:
1. vendor specific extension unit for uvc
2. or usb mode switcher
if both sensors have same capabilities, the 1. make sense. If not then
second. Because this usb dump report settings only for one sensor.
For 1. it will be probably possible to control it with libwebcam. For 2.
it should be possible to control it with some kind of usb_modeswitch
(i'm not up to date).
To find what it is actually, there can be fallowing options:
1. sniff usb traffic
2. see if the windows driver has some advise for us
3. unscrew your laptop and find what control use your webcam.
My guess is that the camera uses either an extension unit (XU) control or a
vendor-specific request to select between the two sensors (which is very
unfortunate, given that the UVC specification has explicit support for dual-
sensor cameras, and I would have liked to test that code :-)).
Let's start with the XU control. I've attached a patch for the yavta test
application (http://git.ideasonboard.org/?p=yavta.git;a=summary) to this e-
mail. Could you please apply it, compile the application with
make
run
yavta /dev/video0
and report the results ?
If your kernel headers are not recent enough (which I expect), compilation
will fail. In that case you will need to download a recent kernel source tree,
run
make headers_install
in the kernel tree (this will install the headers in the local directory, it
won't mess up with your system) and then compile yavta with
make KDIR=/path/to/kernel/tree
--
Regards,
Laurent Pinchart
diff --git a/Makefile b/Makefile
index 4a9f055..9987d56 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,8 @@
CROSS_COMPILE ?=
+KDIR ?=
CC := $(CROSS_COMPILE)gcc
-CFLAGS ?= -O2 -W -Wall
+CFLAGS ?= -O2 -W -Wall -I$(KDIR)/usr/include
LDFLAGS ?=
LIBS := -lrt
diff --git a/yavta.c b/yavta.c
index be2f40c..7a3e35f 100644
--- a/yavta.c
+++ b/yavta.c
@@ -32,6 +32,8 @@
#include sys/select.h
#include sys/time.h
+#include linux/usb/video.h
+#include linux/uvcvideo.h
#include linux/videodev2.h
#ifndef V4L2_BUF_FLAG_ERROR
@@ -233,6 +235,75 @@ static void video_close(struct device *dev)
close(dev-fd);
}
+/* -
+ * UVC XU controls
+ */
+
+static void query_xu_controls(struct device *dev, unsigned int unit,
+ unsigned int count)
+{
+ struct uvc_xu_control_query query;
+ unsigned int i;
+ uint8_t data[2];
+ uint16_t size;
+ uint8_t info;
+ int ret;
+
+ for (i = 0; i count; ++i)
+ {
+ memset(query, 0, sizeof query);
+ query.unit = unit;
+ query.selector = i + 1;
+ query.query = UVC_GET_INFO;
+ query.size = 1;
+ query.data = data;
+
+ ret = ioctl(dev-fd, UVCIOC_CTRL_QUERY, query);
+ if (ret 0)
+ {
+ printf(failed to query XU control %u info: %s (%d)\n, i,
+ strerror(errno), errno);
+ continue;
+ }
+
+ info = data[0];
+
+ memset(query, 0, sizeof query);
+ query.unit = unit;
+ query.selector = i + 1;
+ query.query = UVC_GET_LEN;
+ query.size = 2;
+ query.data = data;
+
+ ret = ioctl(dev-fd, UVCIOC_CTRL_QUERY, query);
+ if (ret 0)
+ {
+ printf(failed to query XU control %u size: %s (%d)\n, i,
+ strerror(errno), errno
Re: [Linux-uvc-devel] Microsoft Lifecam Studio catch button
Hi Max, On Friday 14 October 2011 17:57:02 Max Lapshin wrote: Hi. Is it possible to capture button press on microsoft lifecam studio? There is small button on top of camera and it would be nice to be able to catch pressing on it. It there any way? The first thing to check is whether the button is detected by the uvcvideo driver and registered as an input device. Here's what dmesg reports when I plug a Logitech webcam with a button: [27583.858330] uvcvideo: Found UVC 1.00 device unnamed (046d:080a) [27583.898843] input: UVC Camera (046d:080a) as /devices/pci:00/:00:1d.7/usb2/2-3/2-3:1.0/input/input10 Does the uvcvideo driver print a line starting with 'input' when you plug your camera in ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Mark Microsoft LifeCam Studio as having the usb bandwidth bug
Hi Sebastian, On Thursday 27 October 2011 22:49:07 Sebastian Arcus wrote: Hello all, Would it be possible to add the corresponding note next to the Microsoft LifeCam Studio in the supported devices list on the Linux uvc website (http://www.ideasonboard.org/uvc/), so that people will know that it has the same usb bandwidth bug as the Microsoft LifeCam Cinema, please. Done. Thank you. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] libv4l2 error with 045e:00f8 cameras
Hi Edwin, On Saturday 22 October 2011 00:36:14 Edwin Aponte wrote: libv4l2 is giving having problems with a Microsoft LifeCam NX-6000 webcam (045e:00f8). I have to run skype as below to get the webcam working well for a moment, though an error is generated, until the system freezes completely after some minutes and even SysRq doesn't work. Those two problems are likely unrelated, and the second one is pretty bad. Is your machine connected to a network ? Can you still ping it after it freezes ? What about ssh ? env LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? Your camera seems to produce bad MJPEG frames. From the log you've attached it seems that the first frame is bigger than the next ones. This might be related. Could you try luvcview, which doesn't use libv4l ? Sometimes, I get the same error with the program webcam: -- ~ webcam reading config file: /home/edwinh/.webcamrc video4linux webcam v1.5 - (c) 1998-2002 Gerd Knorr grabber config: size 320x240 [none] input (null), norm (null), jpeg quality 75 rotate=0, top=0, left=0, bottom=240, right=320 libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? v4l2: read: Input/output error capturing image failed - and some times this other error: - ~ webcam reading config file: /home/edwinh/.webcamrc video4linux webcam v1.5 - (c) 1998-2002 Gerd Knorr grabber config: size 320x240 [none] input (null), norm (null), jpeg quality 75 rotate=0, top=0, left=0, bottom=240, right=320 libv4lconvert: Error decompressing JPEG: fill_nbits error: need 1 more bits - I have attached some information based on this thread http://lists.berlios.de/pipermail/linux-uvc-devel/2008-November/004265.html that seems to be a similar case of my problem. I set the trace level to 255: # echo 255 /sys/module/uvcvideo/parameters/trace and I record a frame using: ~ luvcview -f mjpg -c and after that I saved the output of dmesg. Thanks. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Is 064E:E285 supported?
Hi Art, On Saturday 22 October 2011 09:19:28 Alexey Fisher wrote: Can you please attach the output of this command: lsusb -vd 064e:e285 lsusb_dump I second that request :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Flipped video on (13d3:5126)
Hi Nicholas, On Thursday 20 October 2011 19:38:39 Nicholas Hall wrote: uvcvideo: Found UVC 1.00 device USB 2.0 PC Cam (13d3:5126) I applied one of the flip video patches floating around to correct the issue. This is an Asus Eee PC T101MT. Unfortunately, I don't have dmidecode on this system. Please let me know if there is any other information I can get you. To automatically activate image rotation in libv4l for your webcam we need both the USB VID:PID (which you provided) and the dmidecode output. The same webcam module can be mounted correctly or upside-down depending on the machine, so we can't activate image rotation blindly based on the USB VID:PID only. Could you install dmidecode on your machine ? It shouldn't be difficult to compile it directly from sources if needed. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Chicony web cam not working
Hi Bogdan, On Sunday 02 October 2011 10:05:56 Bogdan Milanovic wrote: I have a weird issue. Relevant lsusb: Bus 001 Device 002: ID 04f2:b23b Chicony Electronics Co., Ltd Could you please send the output of lsusb -v -d 04f2:b23b It's a built-in cam in a laptop. The problem is it doesn't work. Not with Skype, not with luvcview. However, if I do chmod 666 /dev/video0 It then works fine. So this is simply a permission issue. Another thing, here's my errors.log: Oct 2 03:01:38 localhost udevd[318]: timeout: killing 'usb_id --export /devices/pci:00/:00:12.2/usb1/1-3' [514] Oct 2 03:01:39 localhost udevd[318]: timeout: killing 'usb_id --export /devices/pci:00/:00:12.2/usb1/1-3' [514] Oct 2 03:01:40 localhost udevd[318]: timeout: killing 'usb_id --export /devices/pci:00/:00:12.2/usb1/1-3' [514] For some reason usb_id times out, which makes udev fail to set the correct permissions on the device node. Do you get any error message in the kernel log (dmesg) ? As you can see, this updates every second with the same message. Because of this problem, I've discovered also that I cannot suspend my system, and it often fails to properly turn off as well. Luckily I have an option in BIOS to disable the webcam. If I do so, the system functions perfectly fine. Googling the VID:PID codes yielded no real results. Apparently uvcvideo module still doesn't support this camera. Any help? As Jason suggested, linux-usb might turn out to be more helpful, as this looks like a core USB issue. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH] fix uvcvideo crash on device hotplug
a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 4c1392e..0925642 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -423,6 +423,7 @@ struct uvc_device {
char name[32];
enum uvc_device_state state;
+struct kref kref;
atomic_t users;
atomic_t nmappings;
@@ -439,7 +440,6 @@ struct uvc_device {
/* Video Streaming interfaces */
struct list_head streams;
-atomic_t nstreams;
/* Status Interrupt Endpoint */
struct usb_host_endpoint *int_ep;
@@ -509,6 +509,7 @@ extern unsigned int uvc_timeout_param;
/* Core driver */
extern struct uvc_driver uvc_driver;
+extern void uvc_delete(struct kref *kref);
extern struct uvc_entity *uvc_entity_by_id(struct uvc_device *dev, int
id);
--
Regards,
Laurent Pinchart
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] compat_ioctl32 errors while poking
Hi Riccardo,
On Sunday 25 September 2011 16:06:53 Riccardo Magliocchetti wrote:
Hello,
i've started playing with opencv but the inlined python script does not
work and these messages are shown in dmesg:
[32452.730023] compat_ioctl32: unknown ioctl 'v', dir=1, #10 (0x4020760a)
[32452.730043] ioctl32(python:10359): Unknown cmd fd(3)
cmd(4020760a){t:'v';sz:32} arg(09f57f48) on /dev/video0
This is a V4L1 ioctl and the uvcvideo driver supports V4L2 only. V4L1 is
deprecated and has been removed from the kernel.
This may well be an opencv issue.
$ cat cvtest.py
import cv
capture = cv.CreateCameraCapture(0)
cv.SetCaptureProperty(capture,cv.CV_CAP_PROP_FRAME_WIDTH, 640.0)
cv.SetCaptureProperty(capture,cv.CV_CAP_PROP_FRAME_HEIGHT, 480.0)
while True:
img = cv.QueryFrame(capture)
cv.ShowImage(camera, img)
cv.WaitKey(10)
kernel is 3.0 64 bit on 32 bit userspace, camera is 174f:5931, the
camera works fine with luvcview.
--
Regards,
Laurent Pinchart
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH] uvcvideo: fix UVC_ENTITY_TYPE check.
Hi Alexey, On Friday 23 September 2011 07:51:24 Alexey Fisher wrote: This patch fix small regression cousing crashe after device was detected. In case of buildin webcam it prevented laptop to boot. This regression was introduced by patch a96aa5342: uvcvideo: Ignore entities for terminals with no supported format Thanks for the patch. I've already fixed the bug in my stable branch (http://git.linuxtv.org/pinchartl/uvcvideo.git/shortlog/refs/heads/uvcvideo- stable) and Mauro said he would pull that for v3.1. Bug-reported-by: Remco Rijnders re...@webconquest.com Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net --- drivers/media/video/uvc/uvc_entity.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/uvc/uvc_entity.c b/drivers/media/video/uvc/uvc_entity.c index 48fea37..29e2399 100644 --- a/drivers/media/video/uvc/uvc_entity.c +++ b/drivers/media/video/uvc/uvc_entity.c @@ -49,7 +49,7 @@ static int uvc_mc_register_entity(struct uvc_video_chain *chain, if (remote == NULL) return -EINVAL; - source = (UVC_ENTITY_TYPE(remote) != UVC_TT_STREAMING) + source = (UVC_ENTITY_TYPE(remote) == UVC_TT_STREAMING) ? (remote-vdev ? remote-vdev-entity : NULL) : remote-subdev.entity; if (source == NULL) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH] uvcvideo: fix UVC_ENTITY_TYPE check.
Hi Alexey, On Friday 23 September 2011 12:49:01 Alexey Fisher wrote: Am 23.09.2011 10:19, schrieb Laurent Pinchart: Hi Alexey, On Friday 23 September 2011 07:51:24 Alexey Fisher wrote: This patch fix small regression cousing crashe after device was detected. In case of buildin webcam it prevented laptop to boot. This regression was introduced by patch a96aa5342: uvcvideo: Ignore entities for terminals with no supported format Thanks for the patch. I've already fixed the bug in my stable branch (http://git.linuxtv.org/pinchartl/uvcvideo.git/shortlog/refs/heads/uvcvid eo- stable) and Mauro said he would pull that for v3.1. ouch :) Sorry for the duplicate work. can you please take a look on my debugfs patch. Sure. Thanks for spending time on it. I've already had a quick look, the approach looks good. I'll try to review it in depth during the weekend, but I'm very busy at the moment. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvc header question
Hi Alexey, On Wednesday 07 September 2011 10:46:41 Alexey Fisher wrote: On 07.09.2011 10:05, Laurent Pinchart wrote: On Wednesday 07 September 2011 08:14:45 Alexey Fisher wrote: Am 06.09.2011 17:24, schrieb Laurent Pinchart: On Monday 05 September 2011 17:48:42 Alexey Fisher wrote: Am 31.08.2011 00:32, schrieb Laurent Pinchart: On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. You are right, the idea is not to show definitely broken frames. If there is some thing what we can't filter, is ok. we did our best. I understand. I'm not sure if this should be included in the mainline uvcvideo driver though. It makes the code more complex to support a couple of completely broken devices, and doesn't guarantee that those devices will work correctly. ok, i give up. I'm sorry about that. I definitely appreciate the work you've done on this, but as I said I don't think we should cripple the driver with complex code just to try to support a bit better a webcam that is completely broken anyway. I just thinking about build in uvc compliance tester insight of the module. Some thing what users can use right in shop or at home before 14 day return guarantee. You enables compliance test and it print results in in dmesg. One of test should be header check, error/drop rate, and so on. That's an interesting idea. It should probably come with a userspace stress test software as well. you mean luvcview or some thing other? I'm thinking about a new command line software that would get/set controls at high speed for instance, verify that all controls reported by the device are actually supported, start/stop streaming multiple times, ... Something that would stress the device and try to crash it (which is unfortunately often quite easy :-)). That's nice :) and on kernel should provide file with statistics. Some thing like: /sys/kernel/debug/uvcvideo/stats It should have - packet count - frame count - payloads with error bit - empthy payloads - overruns, and underruns (for row) - jpeg completation (SOI - EOI) I don't think the driver should parse MJPEG data to extract markers. This can be done by the userspace application. Any thing else? The number of failed and total control requests would also be interesting. Statistics about the status endpoint would also be interesting, to verify that the device correctly sends control change events for instance (although those are not properly supported in the driver yet). -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvc header question
Hi Alexey, On Wednesday 07 September 2011 08:14:45 Alexey Fisher wrote: Am 06.09.2011 17:24, schrieb Laurent Pinchart: On Monday 05 September 2011 17:48:42 Alexey Fisher wrote: Am 31.08.2011 00:32, schrieb Laurent Pinchart: On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. You are right, the idea is not to show definitely broken frames. If there is some thing what we can't filter, is ok. we did our best. I understand. I'm not sure if this should be included in the mainline uvcvideo driver though. It makes the code more complex to support a couple of completely broken devices, and doesn't guarantee that those devices will work correctly. ok, i give up. I'm sorry about that. I definitely appreciate the work you've done on this, but as I said I don't think we should cripple the driver with complex code just to try to support a bit better a webcam that is completely broken anyway. I just thinking about build in uvc compliance tester insight of the module. Some thing what users can use right in shop or at home before 14 day return guarantee. You enables compliance test and it print results in in dmesg. One of test should be header check, error/drop rate, and so on. That's an interesting idea. It should probably come with a userspace stress test software as well. you mean luvcview or some thing other? I'm thinking about a new command line software that would get/set controls at high speed for instance, verify that all controls reported by the device are actually supported, start/stop streaming multiple times, ... Something that would stress the device and try to crash it (which is unfortunately often quite easy :-)). -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvc header question
Hi Alexey, On Monday 05 September 2011 17:48:42 Alexey Fisher wrote: Am 31.08.2011 00:32, schrieb Laurent Pinchart: On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. You are right, the idea is not to show definitely broken frames. If there is some thing what we can't filter, is ok. we did our best. I understand. I'm not sure if this should be included in the mainline uvcvideo driver though. It makes the code more complex to support a couple of completely broken devices, and doesn't guarantee that those devices will work correctly. I just thinking about build in uvc compliance tester insight of the module. Some thing what users can use right in shop or at home before 14 day return guarantee. You enables compliance test and it print results in in dmesg. One of test should be header check, error/drop rate, and so on. That's an interesting idea. It should probably come with a userspace stress test software as well. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Robert, On Wednesday 31 August 2011 03:59:18 Robert Krakora wrote: Hi Laurent, The Logitech B990 does not adhere to the USB-IF spec to which you have referred. Multiplexing H.264 in a Motion JPEG container is a bit odd. Stephan's patches from earlier this year and some slight modifications to the GStreamer v4l2src element were sufficient. I can see why you would reject patches for any cameras that adhere to the USB-IF spec, but I don't know why you would not consider accepting Stephan's patches. They seem pretty benign. The FaceVsion E1 exposes H.264 as a MPEG2 transport stream (another one of Stephan's patches), I have this working as well although there seems to be a audio/video synchronization problem. That's something I plan to (at least try to) support. FaceVsion unfortunately ignored all my e-mails when I asked them for a camera sample. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Max, On Wednesday 31 August 2011 13:44:29 Max Lapshin wrote: On Wed, Aug 31, 2011 at 3:29 PM, Robert Krakora wrote: Here are the patches I used for v4l2. I have an additional patch for the v4l2src element for GStreamer that I am going to create and e-mail as well. Many thanks to Stephan for his work on these patches. H264 (Logitech): https://patchwork.kernel.org/patch/515631/ MPEG2 TS (FaceVsion): https://patchwork.kernel.org/patch/515621/ I can hardly understand, what is the problem in 4-lines patch, that looks like other code. The first patch was rejected back then because H.264 support in the V4L2 API had to be implemented differently. Recent discussions about H.264 and V4L2 resulted in a different position, so I can now apply the patch. I've asked Stephan for his Signed-off-by line and I will push it to v3.2. I still need to review the second patch properly, that's on my TODO list. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Microdia Sonix id 0c45:6310
Hi Rafael, On Friday 12 August 2011 09:28:55 Alexey Fisher wrote: On 10.08.2011 16:06, Rafael Piazenski wrote: Thanks again, for your help! The file is attached! I receiver this output (sorry this is in portuguese, but I'll try to translate): gst-launch-0.10 v4l2src num-buffers=3 ! autovideosink Definindo a fila de processamento para PAUSADO... ERRO: A fila do processamento não quer pausar. ERRO: do elemento /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: O dispositivo /dev/video0 não pôde ser identificado. Informação adicional de depuração: v4l2_calls.c(493): gst_v4l2_open (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: system error: Arquivo ou diretório não encontrado Definindo a fila de processamento para NULO... Liberando a fila de processamento... Setting the queue processing to PAUSED ... ERROR: The queue does not want to pause processing. ERROR: from element / GstPipeline: pipeline0/GstV4l2Src: v4l2src0: Device / dev/video0 could not be identified. Additional information for debugging: v4l2_calls.c (493): gst_v4l2_open (): / GstPipeline: pipeline0/GstV4l2Src: v4l2src0: system error: File or directory not found Setting the processing queue to NULL ... Releasing the queue processing ... Hope this can help! Rafael 2011/8/10 Alexey Fisher bug-tr...@fisher-privat.net: On 10.08.2011 15:11, Rafael Piazenski wrote: Hello people! First of all, thanks for your help! I have this webcam on my ubuntu 11.04 in a HP TX2500 (2540br). My webcam is recognized, but there is no /dev/video0 for it. Can you help me solve this issue? Thanks a lot! Rafael Piazenski Bus 002 Device 004: ID 0c45:6310 Microdia Sonix USB 2.0 Camera lsusb -d 0c45:6310 -v | grep 14 Video can't get device qualifier: Operation not permitted can't get debug descriptor: Operation not permitted cannot read device status, Operation not permitted (1) bFunctionClass 14 Video Please attach complete lsusb output. Use: sudo lsusb -vd 0c45:6310 lsusb Then reload uvc module with debug options: sudo rmmod uvcvideo sudo modpprobe uvcvideo trace=0xfff play some thing, for example: gst-launch-0.10 v4l2src num-buffers=3 ! autovideosink this will capture only 3 frames. And after this attach dmesg output as well. Regards, Alexey In dmesg you can see this part: [11459.512425] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. [11459.512829] uvcvideo: Failed to query (129) UVC probe control : -32 (exp. 26). [11459.512837] uvcvideo: Failed to initialize the device (-5). May be your can is really not uvc compliant. I currently can't help you, if you able to compile kernel and wont to try some hacks then you are wellkome, but most of the time you should think and hack by your self. Could you try to load the uvcvideo module with quirks=0x100 ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Interface between webcam driver and UVC
Hi Shekhar, On Friday 12 August 2011 13:59:33 Chandrashekhar Lavania wrote: Hi, This might be a naive question, but I was wondering which uvc driver file interacts with the actual webcam driver. I'm not sure to understand your question. If you're looking for how the driver interacts with applications, that's implemented in uvc_v4l2.c. Also is there an architecture of the UVC driver for linux available which highlights the mentioned interaction and interaction between various layers of uvc driver. Not that I know of :-) The V4L2 API specification (http://linuxtv.org/downloads/v4l-dvb-apis/) describes the kernel - userspace API. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Erlang capture for UVC
Hi Max, On Friday 12 August 2011 18:37:31 Max Lapshin wrote: Hi. I've added erlang driver for UVC: http://github.com/erlyvideo/uvc This driver captures video from v4l and transforms it to erlang messages. Mention adding huffman table to output jpeg. Without it jpeg decoders can't take mjpeg from camera. Thanks again for great linux driver! You're welcome. Thank you for contributing to Linux UVC support. This tool http://github.com/erlyvideo/jpeg uses turbojpeg library to decode mjpeg stream to yuv stream. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam Compatibility Report
Hi, On Tuesday 23 August 2011 21:20:29 Téssio Fechine wrote: Hello, My webcam Lenovo EasyCamera (090c:3717) is compatible with UVC and works very well. Just reporting new hardware to your known UVC devices. Thanks you for the report. Could you please send me the output of lsusb -v -d 090c:3717 running as root if possible ? Does the webcam come integrated in a laptop ? If so, what's its model name ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Max, On Saturday 27 August 2011 11:09:13 Max Lapshin wrote: Robert, would You kindly tell more: how can I get H264 with UVC api? I'm not using gstreamer, because I capture video directly into my program. I just brought B990 home (how huge is it!) and trying to get compressed stream. should I select something like V4L2_PIX_FMT_H264 ? You can't, at least for now. The uvcvideo driver doesn't support H.264. Stephan's patches might be enough to get very basic H.264 support for some webcams, but I'm not even sure about that. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Max, On Saturday 27 August 2011 11:50:55 Max Lapshin wrote: By the way, have you seen document http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1_052811.zip ? There are some encoder setup options. That's the totally broken spec I don't want to support. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Max, On Wednesday 31 August 2011 00:06:20 Max Lapshin wrote: On Wed, Aug 31, 2011 at 2:03 AM, Laurent Pinchart wrote: You can't, at least for now. The uvcvideo driver doesn't support H.264. Stephan's patches might be enough to get very basic H.264 support for some webcams, but I'm not even sure about that. Robert showed that there is some result from B990. However, I have a kernel programmer nearby, whom I can hire to add proper support, according to docs on usb.org Should I tell him to point at your repository? As explained before, I will very likely refuse patches that implement support for that broken spec, unless you somehow manage to make them clean enough (which might be an impossible task). Supporting H.264 cameras that don't conform to the spec will probably be easier. These cameras are really cool for my task, so I need them. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Erlang capture for UVC
On Tuesday 30 August 2011 23:36:58 Max Lapshin wrote: I would like to add H264 capture support and I have B990 camera, but I can't find any exact information where should I take patches and what should I change to capture h264. There's no UVC H.264 support at the moment. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Max, On Wednesday 31 August 2011 00:12:50 Max Lapshin wrote: On Wed, Aug 31, 2011 at 2:07 AM, Laurent Pinchart wrote: On Saturday 27 August 2011 11:50:55 Max Lapshin wrote: By the way, have you seen document http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1_052811.z ip ? There are some encoder setup options. That's the totally broken spec I don't want to support. So, this document has nothing to do with the way, that Logitech B990 exchanges H264 via USB? I don't know how H.264 support is implemented in the B990. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvc header question
Hi Alexey, On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Microdia Sonix id 0c45:6310
Hi Rafael, On Wednesday 31 August 2011 00:30:33 Rafael Piazenski wrote: Ok! I did this: sudo modprobe -r uvcvideo sudo modprobe uvcvideo quirks=0x100 and I got this: [ 4062.230154] usbcore: deregistering interface driver uvcvideo [ 4068.823775] Linux media interface: v0.10 [ 4068.838320] Linux video capture interface: v2.00 [ 4068.838327] WARNING: You are using an experimental version of the media stack. [ 4068.838328]As the driver is backported to an older kernel, it doesn't offer [ 4068.838330] enough quality for its usage in production. [ 4068.838331]Use it with care. [ 4068.838332] Latest git patches (needed if you report a bug to linux-me...@vger.kernel.org): [ 4068.838333]9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e [media] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028 [ 4068.838335]ffd638e0e613578fbe82d5f2d9c1e5ec503a3a2b [media] v4l: Move event documentation from SUBSCRIBE_EVENT to DQEVENT [ 4068.838337]31ee95ec2d3dd3b6f68d7fa0f410045652895af2 [media] adp1653: check error code of adp1653_init_controls [ 4068.844524] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:6310) [ 4068.844529] uvcvideo: Forcing device quirks to 0x100 by module parameter for testing purpose. [ 4068.844531] uvcvideo: Please report required quirks to the linux-uvc-devel mailing list. [ 4068.846762] uvcvideo: Failed to query (129) UVC probe control : -32 (exp. 26). [ 4068.846769] uvcvideo: Failed to initialize the device (-5). [ 4068.847508] usbcore: registered new interface driver uvcvideo [ 4068.847512] USB Video Class driver (1.1.1) Your webcam looks badly broken. Can you test it under windows ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [uvc] Can I have your UserPointer streaming patch
Hi Alexander,
On Friday 05 August 2011 18:54:19 Alexander Lam wrote:
Hi,
If you could, can you please send me the patch mentioned in this
linux-uvc-devel discssion:
http://lists.berlios.de/pipermail/linux-uvc-devel/2010-May/005756.html
You don't need to update it to the latest kernel, I can handle that.
(I am attempting to fix a uvc-on-arm corruption issue)
Here's the latest version, already rebased on top of v3.0. I haven't tested it
for that kernel though.
I've CCed the linux-uvc-devel list as this can be of interest to other people.
--
Regards,
Laurent Pinchart
From 56a921d24412d6df71f6ac973c4634e7d56c1307 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Thu, 18 Mar 2010 08:56:35 +0100
Subject: [PATCH] uvcvideo: Add user pointer streaming mode
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_isight.c | 11 +--
drivers/media/video/uvc/uvc_queue.c | 196 +++---
drivers/media/video/uvc/uvc_v4l2.c |5 +-
drivers/media/video/uvc/uvc_video.c | 35 ++-
drivers/media/video/uvc/uvcvideo.h | 13 ++-
5 files changed, 209 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_isight.c b/drivers/media/video/uvc/uvc_isight.c
index 74bbe8f..08b198d 100644
--- a/drivers/media/video/uvc/uvc_isight.c
+++ b/drivers/media/video/uvc/uvc_isight.c
@@ -45,8 +45,7 @@ static int isight_decode(struct uvc_video_queue *queue, struct uvc_buffer *buf,
0xde, 0xad, 0xfa, 0xce
};
- unsigned int maxlen, nbytes;
- __u8 *mem;
+ unsigned int written;
int is_header = 0;
if (buf == NULL)
@@ -83,13 +82,9 @@ static int isight_decode(struct uvc_video_queue *queue, struct uvc_buffer *buf,
* contain no data.
*/
if (!is_header) {
- maxlen = buf-buf.length - buf-buf.bytesused;
- mem = queue-mem + buf-buf.m.offset + buf-buf.bytesused;
- nbytes = min(len, maxlen);
- memcpy(mem, data, nbytes);
- buf-buf.bytesused += nbytes;
+ written = uvc_buffer_write(queue, buf, data, len);
- if (len maxlen || buf-buf.bytesused == buf-buf.length) {
+ if (written len || buf-buf.bytesused == buf-buf.length) {
uvc_trace(UVC_TRACE_FRAME, Frame complete
(overflow).\n);
buf-state = UVC_BUF_STATE_DONE;
diff --git a/drivers/media/video/uvc/uvc_queue.c b/drivers/media/video/uvc/uvc_queue.c
index f90ce9f..e27876e 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -15,6 +15,8 @@
#include linux/mm.h
#include linux/list.h
#include linux/module.h
+#include linux/pagemap.h
+#include linux/slab.h
#include linux/usb.h
#include linux/videodev2.h
#include linux/vmalloc.h
@@ -89,6 +91,47 @@ void uvc_queue_init(struct uvc_video_queue *queue, enum v4l2_buf_type type,
queue-type = type;
}
+static void uvc_unlock_buffer(struct uvc_buffer *buf)
+{
+ unsigned int i;
+
+ for (i = 0; i buf-npages; ++i)
+ page_cache_release(buf-pages[i]);
+
+ kfree(buf-pages);
+ buf-npages = 0;
+ buf-pages = NULL;
+}
+
+static int uvc_lock_buffer(struct uvc_buffer *buf)
+{
+ unsigned long data;
+ unsigned int first, last;
+ int ret;
+
+ data = buf-buf.m.userptr;
+ first = (data PAGE_MASK) PAGE_SHIFT;
+ last = ((data + buf-buf.length - 1) PAGE_MASK) PAGE_SHIFT;
+
+ buf-offset = data ~PAGE_MASK;
+ buf-npages = last - first + 1;
+ buf-pages = kmalloc(buf-npages * sizeof(buf-pages[0]), GFP_KERNEL);
+ if (buf-pages == NULL)
+ return -ENOMEM;
+
+ down_read(current-mm-mmap_sem);
+ ret = get_user_pages(current, current-mm, data PAGE_MASK,
+ buf-npages, 1, 0, buf-pages, NULL);
+ up_read(current-mm-mmap_sem);
+
+ if (ret != buf-npages) {
+ buf-npages = ret 0 ? ret : 0;
+ return ret 0 ? ret : -EINVAL;
+ }
+
+ return 0;
+}
+
/*
* Free the video buffers.
*
@@ -103,6 +146,9 @@ static int __uvc_free_buffers(struct uvc_video_queue *queue)
return -EBUSY;
}
+ for (i = 0; i queue-count; ++i)
+ uvc_unlock_buffer(queue-buffer[i]);
+
if (queue-count) {
uvc_queue_cancel(queue, 0);
INIT_LIST_HEAD(queue-mainqueue);
@@ -133,7 +179,7 @@ int uvc_free_buffers(struct uvc_video_queue *queue)
* Buffers will be individually mapped, so they must all be page aligned.
*/
int uvc_alloc_buffers(struct uvc_video_queue *queue, unsigned int nbuffers,
- unsigned int buflength)
+ enum v4l2_memory memory, unsigned int buflength)
{
unsigned int bufsize = PAGE_ALIGN(buflength);
unsigned int i;
@@ -152,31 +198,37 @@ int uvc_alloc_buffers(struct uvc_video_queue *queue, unsigned int nbuffers,
if (nbuffers == 0)
goto done;
- /* Decrement the number of buffers until allocation succeeds. */
- for (; nbuffers 0; --nbuffers) {
- mem = vmalloc_32(nbuffers * bufsize);
- if (mem != NULL)
- break;
- }
+ /* Allocate video buffers for mmap mode. Decrement the number of
+ * buffers until allocation succeeds.
+ */
+ if (memory == V4L2_MEMORY_MMAP) {
+ for (; nbuffers 0; --nbuffers) {
+ mem = vmalloc_32(nbuffers * bufsize
Re: [Linux-uvc-devel] luvcview and Cheese on SLC6
Hi Dusan, On Thursday 04 August 2011 12:54:42 Dusan Bruncko wrote: Dear Laurent, no, unfortnately no I did try e.g. following command: bash -c 'LD_PRELOAD=/usr/lib64/libv4lconvert.so.0 /usr/bin/cheese' or bash -c 'LD_PRELOAD=/usr/lib64/libv4lconvert.so.0 luvcview -f yuv' but any effect Could you please send me the lsusb -v output for your camera, as well as the dmidecode output ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] luvcview and Cheese on SLC6
Hi Dusan, On Thursday 04 August 2011 13:14:57 Dusan Bruncko wrote: Dear Laurent, my camera: USB2.0 UVC 2M WebCam and please look attachment. Thanks, but I've asked for lsusb -v (run as root if possible), not lspci :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] luvcview and Cheese on SLC6
Hi Dunsan, On Thursday 04 August 2011 13:23:34 Dusan Bruncko wrote: Sorry, lsusb output is in attachment. Thanks. I've forwarded the information to the libv4l author. The next version should support your webcam. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] 3.0 - exposure settings.
Hi Carl, On Wednesday 03 August 2011 08:29:56 Carl Michal wrote: On Tue, 2 Aug 2011, Laurent Pinchart wrote: On Tuesday 02 August 2011 07:29:47 Carl Michal wrote: Hi Laurent, I understand there were changes made in the exposure settings in 3.0. I just installed 3.0 and have some new/different issues here. I have two cameras available: a quanta integrated webcam in a dell XPS 15 and a logitech C910. For either camera, guvcview used to give me a drop-down menu with 4 exposure options in addition to an auto priority checkbox and a slider to manually set the exposure. Two of the drop-down settings didn't seem to work, but two of them did. With a 3.0 kernel, there is only an auto exposure check-box and manual exposure slider - but the exposure slider no longer works and guvcview says: control id: 0x009a0902 failed to set (error -1) (for the quanta) or control id: 0x009a0902 failed to set (error -1) (for the logitech) So pretty much the same error for both :-) err - somehow they looked a little less identical when I went to paste the second one in. Blame that on the new baby... Could you try listing the controls with v4l2-ctl or yavta ? The auto-exposure control should still be a menu (I expect guvcview to convert it to a boolean control automatically for some reason, maybe because it has two values only), and if the values reported by the driver match the two values that worked before ? yavta -l for either camera lists three exposure controls (with different values for the min, max and default): control 0x009a0901 `Exposure, Auto' min 0 max 3 step 1 default 3 current 3. 1: Manual Mode 3: Aperture Priority Mode control 0x009a0902 `Exposure (Absolute)' min 3 max 2047 step 1 default 166 current 166. control 0x009a0903 `Exposure, Auto Priority' min 0 max 1 step 1 default 0 current 0. The two values reported for the 'Exposure, Auto' control are the two values in the drop down that worked before. But that control isn't drawn by guvcview at all now (tried guvcview: 1.4.2, 1.4.4 or 1.4.5). Interesting though, luvcview (0.2.6) draws the first two of those controls (but not the third). So - I turned off the auto exposure in luvcview and now the manual exposure setting works. But - now I can't turn auto exposure back on. luvcview says either: Auto Exposure set to 1 or Set Auto Exposure off error It looks like luvcview wants to set values of either 0 or 1, when the legal values are 1 or 3. with v4l2-ctl, I can set the Auto Exposure control to 1 or 3 and it seems to work correctly. So looks like the driver does the right thing but maybe both guvcview and luvcview are confused by the available values? That's quite likely. Do you want to have a try at fixing them ? :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] luvcview and Cheese on SLC6
Hi Dusan, On Tuesday 02 August 2011 16:58:25 bruncko wrote: Hello, I have SLC6, uname -ra Linux acer-ntbk 2.6.32-131.6.1.el6.x86_64 #1 SMP Tue Jul 12 17:14:50 CDT 2011 x86_64 x86_64 x86_64 GNU/Linux My problem is following: I can run luvciew or Cheese, all going well, but I see the picture flip over 180 degree. Can you help me? Flipping the image is handled by libv4l in userspace. Is the image correct if you use a libv4l-aware application (or LD_PRELOAD libv4lconvert into luvcview or Cheese) ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] 3.0 - exposure settings.
Hi Carl, On Tuesday 02 August 2011 07:29:47 Carl Michal wrote: Hi Laurent, I understand there were changes made in the exposure settings in 3.0. I just installed 3.0 and have some new/different issues here. I have two cameras available: a quanta integrated webcam in a dell XPS 15 and a logitech C910. For either camera, guvcview used to give me a drop-down menu with 4 exposure options in addition to an auto priority checkbox and a slider to manually set the exposure. Two of the drop-down settings didn't seem to work, but two of them did. With a 3.0 kernel, there is only an auto exposure check-box and manual exposure slider - but the exposure slider no longer works and guvcview says: control id: 0x009a0902 failed to set (error -1) (for the quanta) or control id: 0x009a0902 failed to set (error -1) (for the logitech) So pretty much the same error for both :-) Could you try listing the controls with v4l2-ctl or yavta ? The auto-exposure control should still be a menu (I expect guvcview to convert it to a boolean control automatically for some reason, maybe because it has two values only), and if the values reported by the driver match the two values that worked before ? yavta -l /dev/video0 reports control 0x009a0901 `Exposure, Auto' min 0 max 3 step 1 default 3 current 3. 1: Manual Mode 3: Aperture Priority Mode on my C905. Writing to the Exposure (Absolute) control when Exposure, Auto is set to 3 fails with EIO, and succeeds if Exposure, Auto is set to 1. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Logitech 910 working excelently
Hi Max, On Tuesday 02 August 2011 12:12:44 Max Lapshin wrote: I want to thank those who have created uvc project. It is working excelently. I've took Logitech 910 camera and it made my day, because it give picture better than IP H264 surveillance cameras, that costs 10 times more. Video is capturing excelently (1280x720@24) and audio also (via alsa). Thank you again. You're welcome. I'm always happy to hear that the driver works fine for at least a couple of users :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Exposure setting problems with Creative Live! Cam Socialize HD
Hi Alexey, On Monday 01 August 2011 08:12:07 Alexey Rempel wrote: Am 31.07.2011 18:28, schrieb Laurent Pinchart: On Saturday 30 July 2011 15:08:14 Michael Stapelberg wrote: Hi, I recently bought a Creative Live! Cam Socialize HD (ID 041e:4080) after verifying that it is a device supported by the uvcvideo driver. The device basically works, but to get 30 fps (at 640x480, but also with higher resolutions), I need to set the 'Exposure, Auto' setting to 1 (Manual Mode). Afterwards, I can set the 'Exposure (Absolute)' setting to one of the values 39, 78, 156, 312, 625, 1250, 2500, …. All other values lead to a heavily over-exposed picture. This effect was already mentioned on this list for a different cam [1]. I wonder what we can do about it, as the step size for this setting is reported as '1' while in reality it seems logarithmic – with the exception of the step 312 to 625. Those values are 2500 / 64, 32, 16, 8, 4, 2 and 1. There's unfortunately no way for the driver to know that other values will lead to bad results. I've seen bad firmware bugs, but this one is high on the list. So, I can live with changing the configuration after plugging in the cam, which I would automate with udev. However, I have noticed that I need to have an active video capture running, otherwise setting these values with uvcdynctrl has no effect. I tested it like this: 1) Plug in the camera, wait until the white LED (which indicates capturing) goes off. This takes about 5 seconds. 2) Use uvcdynctrl -s 'Exposure, Auto' 1 3) Verify the result with uvcdynctrl -g 'Exposure, Auto', which also returns 1 4) Use uvcdynctrl -s 'Exposure (Absolute)' 312, verify it 5) Use gst-launch v4l2src ! xvimagesink → The video is at 5 fps instead of 30 fps If I do it like this, it works: 1) Plug in the camera, wait until the white LED (which indicates capturing) goes off. This takes about 5 seconds. 2) Use gst-launch v4l2src ! xvimagesink, leave it open 3) Use uvcdynctrl -s 'Exposure, Auto' 1, verify it 4) Use uvcdynctrl -s 'Exposure (Absolute)' 312, verify it → The video works correctly That's weird. I'm wondering if the camera doesn't just reset all controls when the video stream is started. What happens in the second case if you stop the video stream and restart it ? Are exposure settings correct, or do they go back to bad values ? How about usb autosuspend? well be settings stored if usbautosupend is disabled, at least for the cam? The uvcvideo restores controls at resume time, so this shouldn't be an issue. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Exposure setting problems with Creative Live! Cam Socialize HD
Hi Michael, On Tuesday 02 August 2011 00:05:47 Michael Stapelberg wrote: Hi Alexey, Excerpts from Alexey Fisher's message of 2011-08-01 08:16:42 +0200: How about usbautosuspend? Will it store the settings if you disables usbautosuspend? Good hint, but no. Disabling autosuspend does not help for this issue. However, I found out that I do not have to let the video output running while setting the parameters. So, the following works, too: 1) Plug in the webcam 2) Start video using gst-launch v4l2src ! xvimagesink 3) Stop video 4) uvcdynctrl -s 'Exposure, Auto' 1 5) uvcdynctrl -s 'Exposure (Absolute)' 625 6) All video from now on is correct Maybe the webcam just ignores all set control requests before the first stream-on ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Exposure setting problems with Creative Live! Cam Socialize HD
Hi Michael, On Monday 01 August 2011 23:53:41 Michael Stapelberg wrote: Excerpts from Laurent Pinchart's message of 2011-07-31 18:28:27 +0200: Those values are 2500 / 64, 32, 16, 8, 4, 2 and 1. There's unfortunately no way for the driver to know that other values will lead to bad results. I've seen bad firmware bugs, but this one is high on the list. Hm, ok. Maybe we could add a quirk for the specific models? But that won’t help us with the 'step' value, because it’s not flexible enough for 2500/x, right? You could still set step to 1, and fixup the value in the driver. That's weird. I'm wondering if the camera doesn't just reset all controls when the video stream is started. What happens in the second case if you stop the video stream and restart it ? Are exposure settings correct, or do they go back to bad values ? When I stop the video stream and restart it, I can see about half a second of the 'Exposure, Auto' == 3 capture, then it switches to my settings (without auto exposure). If you want me too, I can make a video of this. Some firmware developers should be banned from using a computer forever... Probably in the camera firmware. The device queries the camera for default and current values, and I wouldn't be surprised if the camera reported a default value that it doesn't use as a default. So, I guess a quirk would be the way to go in this case? Are you interested in patches for this issue? A quirk could fix the manual exposure control values issue, but it won't fix the other problem(s) you got with that device. How do you mean ? On non-broken cameras you can just set the control to any legal value and things will work :-) Yes, but I expect to just plug in my camera and start a video chat in Pidgin. Where do you usually configure your exposure settings? I mean, you don’t do it by hand every time you plug in your camera, right? To be honest I don't use webcams for video conferencing much :-) When I do I just leave the default control values, that works pretty well on the webcams I use. Maybe libv4l could help there. There has been some discussions about adding control save/restore features to the library. I don't know if that has been implemented. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Is there any sample for uvc gadget?
Hi, On Thursday 28 July 2011 02:58:05 chao xie wrote: hi My develop board have usb and camera sensor supported. I want to simulate my board to be a usb camera for the Linux host. I find that the f_uvc is supported in current kernel, but i am confused about how to make use of the video device exported by webcam. How can i do to simulate the board as a usb camera device? Is there any sample i can reference to? Thanks. The only sample userspace application I know of is called uvc-gadget and available at http://git.ideasonboard.org/. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Microsoft LifeCam HD-5000 Confirmed working
Hi Vincent, On Wednesday 27 July 2011 01:24:53 Vincent wrote: I would like to confirm that Microsoft LifeCam HD-5000 with a device ID of 045e:076d is tested and working! Thank you for the report. I've updated the supported devices list. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Ajay, On Thursday 23 June 2011 06:39:28 Ajay Bhargav wrote: Hi Laurent, Thanks for your reply. Well I know that H.264 payload is specified in newer UVC 1.1 documentation, but my webcam is not sending H.264 as payload. Its sending MPEG2-TS according to UVC1.0 secifications, i found out during debugging, format descriptor gives 0x0A as Descriptor subtype. As per old archives from mailing list i added MPEG2-TS handling similar to DV format. I am now able to create a /dev/video device on my machine but i have no idea how to add stream support to UVC-v4l2 interface or where to add that support. As there is no frame descriptor V4L2 driver is not able to detect the frame rate etc... Maybe i am getting little confused here? Implementing MPEG2-TS support is onmy TODO list, but I unfortunately don't own any UVC device that implements MPEG2-TS :-S -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvc webcam does not support 640*480 on arm9 board
Hi, On Wednesday 08 June 2011 14:31:59 JITENDRA SINGH wrote: Hi all, I am able to uvccapture 320*240 jpgs using this webcam on arm9 board, but it fails when I try to capture 640*480 stills, it hangs while trying to exit: [snip] dmesg error when uvccapture didnt work: [ 2650.79] uvcvideo: Failed to resubmit video URB (-45). [ 2650.79] uvcvideo: Failed to resubmit video URB (-45). [ 2650.79] uvcvideo: Failed to resubmit video URB (-45). [ 2650.79] uvcvideo: Failed to resubmit video URB (-45). 45 is EL2NSYNC. A quick grep in drivers/usb shows only one driver returning that error code, and that's for a gadget device, not a host controller. I suspect an issue in your board's USB host controller driver. What ARM9 SoC are you using ? Can you try upgrading it to a more recent kernel ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Exposure setting problems with Creative Live! Cam Socialize HD
Hi Michael, On Saturday 30 July 2011 15:08:14 Michael Stapelberg wrote: Hi, I recently bought a Creative Live! Cam Socialize HD (ID 041e:4080) after verifying that it is a device supported by the uvcvideo driver. The device basically works, but to get 30 fps (at 640x480, but also with higher resolutions), I need to set the 'Exposure, Auto' setting to 1 (Manual Mode). Afterwards, I can set the 'Exposure (Absolute)' setting to one of the values 39, 78, 156, 312, 625, 1250, 2500, …. All other values lead to a heavily over-exposed picture. This effect was already mentioned on this list for a different cam [1]. I wonder what we can do about it, as the step size for this setting is reported as '1' while in reality it seems logarithmic – with the exception of the step 312 to 625. Those values are 2500 / 64, 32, 16, 8, 4, 2 and 1. There's unfortunately no way for the driver to know that other values will lead to bad results. I've seen bad firmware bugs, but this one is high on the list. So, I can live with changing the configuration after plugging in the cam, which I would automate with udev. However, I have noticed that I need to have an active video capture running, otherwise setting these values with uvcdynctrl has no effect. I tested it like this: 1) Plug in the camera, wait until the white LED (which indicates capturing) goes off. This takes about 5 seconds. 2) Use uvcdynctrl -s 'Exposure, Auto' 1 3) Verify the result with uvcdynctrl -g 'Exposure, Auto', which also returns 1 4) Use uvcdynctrl -s 'Exposure (Absolute)' 312, verify it 5) Use gst-launch v4l2src ! xvimagesink → The video is at 5 fps instead of 30 fps If I do it like this, it works: 1) Plug in the camera, wait until the white LED (which indicates capturing) goes off. This takes about 5 seconds. 2) Use gst-launch v4l2src ! xvimagesink, leave it open 3) Use uvcdynctrl -s 'Exposure, Auto' 1, verify it 4) Use uvcdynctrl -s 'Exposure (Absolute)' 312, verify it → The video works correctly That's weird. I'm wondering if the camera doesn't just reset all controls when the video stream is started. What happens in the second case if you stop the video stream and restart it ? Are exposure settings correct, or do they go back to bad values ? What I also do not understand is why the control has a reported default value of 1 while uvcdynctrl -g 'Exposure, Auto' returns 3. Is this a bug in the uvcvideo driver? Or in the camera firmware? Probably in the camera firmware. The device queries the camera for default and current values, and I wouldn't be surprised if the camera reported a default value that it doesn't use as a default. What is the recommended way to deal with the Exposure setting? How do you mean ? On non-broken cameras you can just set the control to any legal value and things will work :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Multiple Lifecam Cinema HD's
Hi Chris, On Tuesday 26 July 2011 11:40:56 Chris Jones wrote: On 26/07/11 00:44, Laurent Pinchart wrote: On Monday 25 July 2011 11:52:07 Chris Jones wrote: On 24/07/11 00:39, Laurent Pinchart wrote: Try loading the driver with modprobe uvcvideo quirks=0x80 That doesn't seem to help, i still get a 'Device or resource busy' message when trying to open the second device. This slipped through when I replied to your e-mail. That error doesn't seem to be related to USB bandwidth. What do you mean by opening the device ? Are you talking about the open() call, or opening it in an application ? The uvcvideo driver will only return -EBUSY if an application has already opened the device. Have you made sure the driver isn't already loaded before loading it with the above command ? modprobe exits silently if the driver is already loaded, without doing anything. Yes, I ran `rmmod uvcvideo` first. It seems if I turn the resolution right down I can get both to work simultaneously... With or without the quirk ? What resolution(s) have you tried ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Multiple Lifecam Cinema HD's
Hi Chris, On Monday 25 July 2011 11:52:07 Chris Jones wrote: On 24/07/11 00:39, Laurent Pinchart wrote: On Thursday 30 June 2011 17:24:59 Chris Jones wrote: How do I go about setting the FIX_BANDWIDTH quirk? Try loading the driver with modprobe uvcvideo quirks=0x80 That doesn't seem to help, i still get a 'Device or resource busy' message when trying to open the second device. Have you made sure the driver isn't already loaded before loading it with the above command ? modprobe exits silently if the driver is already loaded, without doing anything. Could you please send me the output of lsusb -v (running as root if possible) for your webcam ? Sure, attached. Thank you. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] New UVC device
Hi Todor, On Sunday 24 July 2011 23:30:58 Todor Nickolov wrote: Hello Laurent, I attach the output. Thank you. I've updated the supported devices list. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] New UVC device
Hi Todor, On Saturday 09 July 2011 08:32:38 Todor Nickolov wrote: Hello, I have got a device working with the UVC driver and not listed in the table of known devices. Device ID: 041e:4071 Name: Creative Live! Cam Video IM Ultra (according to usb driver - Product: VF0415 Live! Cam Vid. IM Ultra) Manufacturer: Creative Technology Ltd. (Creative Labs?) Kernel version: 2.6.37.6 If any other information is needed, please let me know. Could you please send me the output of lsusb -v -d 041e:4071 running as root if possible ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] ID 1871:0101 Aveo Technology Corp.
Hi, On Monday 04 July 2011 23:11:30 piewie wrote: Hello, I have a Bresser USB Microscope Digital. It is flawlessly working here on gentoo with 2.6.39-gentoo-r1, uvcvideo and guvcvideo - even the snapshot button on the microscope is useable. Thank you. I've updated the suppported devices list. Thank You very much for your work. You're welcome. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Green Image
Hi, On Tuesday 05 July 2011 12:01:33 Mac Smith wrote: Hi, I am getting a green image when i capture it using vgrabbj. vgrabbj supports the deprecated V4L1 API only. uvcvideo only supports V4L2. # vgrabbj -d /dev/video0 -f /var/www/webcam2.jpeg -D 7 -i vga Set option ImageSize to value 640 (value: vga) Set option ImageSize to value 480 (value: vga) Updated pointers to new allocated memory. Done parsing commandline Setting tmpout file to /var/www/webcam2.jpeg.tmp Device /dev/video0 successfully opened Checking settings of device /dev/video0 Set palette successfully to YUYV Initializing memory Memory initialized, size: 614400 (in), 921600 (out) Reading image from /dev/video0 Palette to be used: YUYV (8), size: 614400 Could not get mmap-buffer - Falling back to read() Using normal read for image grabbing Image successfully read Got YUYV, converting... converted to RGB24 Temporary outputfile /var/www/webcam2.jpeg.tmp closed Temporary output /var/www/webcam2.jpeg.tmp moved to final destination /var/www/webcam2.jpeg Updated pointers to new allocated memory. There was no map allocated to be freed... Device /dev/video0 closed Buffers freed vars freed Image: http://flic.kr/p/9ZLRNb -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Horizontal mirror uvc cams
Hi Matthieu, On Friday 01 July 2011 09:37:23 Grignon Matthieu wrote: Hi, First, thank you for your job! You're welcome. I write you this mail because my webcam have a trouble, the image is al reverse at the horizontal (should have a horizontal mirror in the configuration to fix it). I send you the lusb.log and dmi.log in attach. I'm running with a packardbell easynote NM98-JU, the cam is integrate, and ubuntu natty (it was also the same with ubuntu 10.10). Could you please send me the output of lsusb -v -d 0402:9665 running as root if possible ? Thanks for everything. Sorry for my very approximate english. /(The normal salutation here with a friendly formulation, i have no idea how to write that)/ ;-) Don't worry :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Multiple Lifecam Cinema HD's
Hi Chris, On Thursday 30 June 2011 17:24:59 Chris Jones wrote: Hi All, Google tells me this camera has a bug where it requests all available bus bandwidth, and that I should 'set the FIX_BANDWIDTH quirk'. How do I go about setting the FIX_BANDWIDTH quirk? Try loading the driver with modprobe uvcvideo quirks=0x80 Could you please send me the output of lsusb -v (running as root if possible) for your webcam ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] UVC Compilant USB Cam
Hi, On Thursday 30 June 2011 08:41:28 Mac Smith wrote: Hi, We have usb cameras from Beyond which uses aveo chip. I am not able to run it under ubuntu linux. I understand that ubuntu linux has uvcvideo driver inbuild kernel. I tried using different application like cheese, vgrabbj, streamer to capture still images. every application says its unable to set or get properties from the camera. Kindly help us to sort this out. Out of some of the commands are # lsusb Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 160a:3184 VIA Technologies, Inc. VIA VNT-6656 [WiFi 802.11b/g USB Dongle] Bus 001 Device 002: ID 1871:0501 Aveo Technology Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Could you please send me the output of lsusb -v -d 1871:0501 running as root if possible ? [snip] [ 11.421088] uvcvideo: Found UVC 1.00 device USB2.0 Camera (1871:0501) [ 11.422756] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. [ 11.423917] usbcore: registered new interface driver uvcvideo [snip] [ 89.435099] uvcvideo: Failed to query (130) UVC probe control : -32 (exp. 26). [ 89.435472] uvcvideo: Failed to query (130) UVC probe control : -32 (exp. 26). Please try to load the uvcvideo module with modprobe uvcvideo quirks=2 If the module is already loaded, unload it with modprobe -r uvcvideo before loading it with quirks=2. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] error code list
Hi Jorge, On Friday 24 June 2011 19:45:06 Jorge Yesid Rios Ortiz wrote: Hello laurent: You propose to me: Try to upgrade to a recent kernel. 2.6.14 is more than 5 years old. It isn't possible to use a newer/newest kernel. I tried to compile different versions of kernels (2.6.18, 2.6.20, 2.6.22, 2.6.242.6.38 ) and basically is impossible for some reasons: 1) the toolchains is very old (3.3.2 version). I wrote to ARTILA's support tech asking about a new toolchain because I need to compile a newer kernel and your answers was: this is the last toolchains for your board, you must to use this. I download different versions of ARM's toolchains (like code sourcery lite version http://www.codesourcery.com/sgpp/lite/arm and others more), if I well I can to compile a c or c++ file, when I try to compile or I upload to my target the the executable, isn't working. I've successfully used 2009q1-203 for kernel compilation. 2) Russell King ( he supports the ARM Linux kernel community http://www.arm.linux.org.uk ) on your site wrote this: Downloading an ARM patch: You only need this step if you are using a kernel prior to 2.6.0-test2. There are no -rmk or -vrs patches for later kernels. I suppose that recent versions of kernel has support for ARM architecture, but, when I tried to compile different versions of kernels, always I obtain different errors. 3) On ARTILA ftp site, the last kernel version is 2.6.14-M5 kernel version update to september 15 / 2010, I think. (for me it's a bad joke to say last kernel version to a 2.6.14 version). I read something about URB and I don't know what I must to be for to solve this error. If you have some idea about how to proceeded I will appreciate very much. That's always the problem with vendor-provided kernels, and that's why I always try to use a mainline kernel and get support for my boards upstreamed. It's not an easy task and often requires kernel development. You would basically need to port support for your board from 2.6.14 to a mainline kernel. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH, RESEND] uvcvideo: Add FIX_BANDWIDTH quirk to HP Webcam found on HP Mini 5103 netbook
Hi Kirill,
On Friday 22 July 2011 16:47:22 Kirill Smelkov wrote:
[ Cc'ing Andrew Morton -- Andrew, could you please pick this patch, in
case there is no response from maintainers again? Thanks beforehand. ]
Hello up there,
My first posting was 1 month ago, and a reminder ~ 2 weeks ago. All
without a reply. v3.0 is out and they say the merge window will be
shorter this time, so in oder not to miss it, I've decided to resend my
patch on lowering USB periodic bandwidth allocation topic.
I'm very very sorry for missing the patch (and worse, twice :-/).
Could this simple patch be please applied?
Yes it can. I see that Andrew already applied it to his tree. Mauro, should it
go through there, or through your tree ? I've pushed it to my tree at
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable, so you can already
pull.
Thanks,
Kirill
P.S.
Referenced in the description cc62a7eb (USB: EHCI: Allow users to
override 80% max periodic bandwidth) will be entering the mainline via
Greg's usb tree.
8
From: Kirill Smelkov k...@mns.spb.ru
Subject: [PATCH] uvcvideo: Add FIX_BANDWIDTH quirk to HP Webcam found on HP
Mini 5103 netbook
The camera there identifies itself as being manufactured by Cheng Uei
Precision Industry Co., Ltd (Foxlink), and product is titled as HP
Webcam [2 MP Fixed].
The device isn't listed in the supported devices list. Could you please send
me its lsusb -v output ?
I was trying to get 2 USB video capture devices to work simultaneously,
and noticed that the above mentioned webcam always requires packet size
= 3072 bytes per micro frame (~= 23.4 MB/s isoc bandwidth), which is far
more than enough to get standard NTSC 640x480x2x30 = ~17.6 MB/s isoc
bandwidth.
As there are alt interfaces with smaller MxPS
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05c8 ProdID=0403 Rev= 1.06
S: Manufacturer=Foxlink
S: Product=HP Webcam [2 MP Fixed]
S: SerialNumber=200909240102
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=125us
I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS= 512 Ivl=125us
I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us
I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=1536 Ivl=125us
I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=2048 Ivl=125us
I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=2688 Ivl=125us
I: If#= 1 Alt= 7 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=3072 Ivl=125us
UVC_QUIRK_FIX_BANDWIDTH helps here and NTSC video can be served with
MxPS=2688 i.e. 20.5 MB/s isoc bandwidth.
In terms of microframe time allocation, before the quirk NTSC video
required 60 usecs / microframe and 53 usecs / microframe after.
P.S.
Now with tweaked ehci-hcd to allow up to 90% isoc bandwidth (cc62a7eb
USB: EHCI: Allow users to override 80% max periodic bandwidth) I can
capture two video sources -- PAL 720x576 YUV422 @25fps + NTSC 640x480
YUV422 @30fps simultaneously. Hooray!
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_driver.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c index b6eae48..f633700 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -2130,6 +2130,15 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_PROBE_MINMAX
| UVC_QUIRK_BUILTIN_ISIGHT },
+ /* Foxlink (HP Webcam on HP Mini 5103) */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x05c8,
+ .idProduct= 0x0403,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_FIX_BANDWIDTH },
/* Genesys Logic USB 2.0 PC Camera */
{ .match_flags
Re: [Linux-uvc-devel] [PATCH, RESEND] uvcvideo: Add FIX_BANDWIDTH quirk to HP Webcam found on HP Mini 5103 netbook
Hi Kirill, On Saturday 23 July 2011 00:25:20 Kirill Smelkov wrote: On Sat, Jul 23, 2011 at 12:03:57AM +0200, Laurent Pinchart wrote: On Friday 22 July 2011 16:47:22 Kirill Smelkov wrote: [ Cc'ing Andrew Morton -- Andrew, could you please pick this patch, in case there is no response from maintainers again? Thanks beforehand. ] Hello up there, My first posting was 1 month ago, and a reminder ~ 2 weeks ago. All without a reply. v3.0 is out and they say the merge window will be shorter this time, so in oder not to miss it, I've decided to resend my patch on lowering USB periodic bandwidth allocation topic. I'm very very sorry for missing the patch (and worse, twice :-/). Nevermind. I'm curious though, whether I did something wrong or anything else? I mean how to avoid such long delays next time? It was all my fault, mails piled up in my mailbox and for some reason I marked yours as processed while they were not. I certainly hope it won't happen again. Could this simple patch be please applied? Yes it can. I see that Andrew already applied it to his tree. Mauro, should it go through there, or through your tree ? I've pushed it to my tree at git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable, so you can already pull. You've applied the patch from my first posting, but actually in the RESEND one I've added reference to EHCI-tweaking patch -- it is already merged into Greg's USB tree (it was not when I first posted), so could you please reapply? (sorry for confusion). Sure. That should now be fixed. Thanks for replying and for uvcvideo, You're more than welcome. Thank you for the patch, and thank you for keeping on pushing :-) -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Invitation to connect on LinkedIn
LinkedIn Invitations Laurent Pinchart wrote: --- * RE: Invitation to connect on LinkedIn Hi Liu, On 07/19/11 12:51 AM, Liu Jaloo wrote: Laurent, I'd like to add you to my professional network on LinkedIn. My memory might be playing tricks on me, but have we worked together ? Laurent Pinchart --- Reply to Laurent Pinchart: http://www.linkedin.com/e/2d8m4g-gqamvqjk-65/YhLeBtiJ1S_RPnQZ02mJgWFyYP4RYKjG0EhEfiqeMY29FTi7/blk/I134231218_13/3cNnPwNcz4PczgPckALpn9JbOYWrSlI/mre/ If you wish to change how you receive future LinkedIn invitation notifications, please click here: http://www.linkedin.com/e/2d8m4g-gqamvqjk-65/YhLeBtiJ1S_RPnQZ02mJgWFyYP4RYKjG0EhEfiqeMY29FTi7/blk/I134231218_13/sS9xbOYWrSlI/abs/ If you have any questions, please contact customer_serv...@linkedin.com. -- (c) 2011, LinkedIn Corporation___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Looking for upside down uvc cams
Hi Stefano, On Sunday 19 June 2011 15:09:30 stefano.mazzon...@gmail.com wrote: Hi, yes. Using Skype on Fedora Lovelock I have webcam upside-down (only with it, instead if I use Cheese webcam is ok). Then libv4l already supports your webcam. Google for skype + libv4l to find out how to use it in skype. Thanks for you support! :) I attach output of lsusb -v run as su. Thank you. The device is already included in the supported devices list. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Hi Carl, On Tuesday 07 June 2011 02:31:17 Carl Michal wrote: Hello, I'm having some trouble with a Quanta integrated webcam. It identifies itself as: Laptop_Integrated_Webcam_2HDM, usbid: 0408:2fb1. This is built in to a Dell XPS-15 (L501X). Could you please send me the output of lsusb -v -d 0408:2fb1 running as root if possible ? The uvcvideo module works, but the video stutters and has some distortions, even at low resolutions and frame rates. With the Camera Output set to MJPG (in guvcview) Ignoring empty buffer ... messages occur with most glitches. If the output is set to YV12, the errors look like: VIDIOC_DQBUF - Unable to dequeue buffer : Input/output error Error grabbing image libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? With cheese, the video preview looks ok, but video capture is unusable - the video stutters badly at low resolution, and the capture hangs at high resolution (the program doesn't hang, but after a couple of frames no more get captured). This is kernel 2.6.39 on gentoo with libv4l-0.8.3 Any advice would be appreciated. I'll answer in the mail thread. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Hi Carl, On Monday 13 June 2011 18:37:43 Carl Michal wrote: On Mon, 13 Jun 2011, Alexey Fisher wrote: On So, 2011-06-12 at 21:05 -0700, Carl Michal wrote: On Sun, 12 Jun 2011, Alexey Fisher wrote: Am Samstag, den 11.06.2011, 23:33 -0700 schrieb Carl Michal: On Sun, 12 Jun 2011, Alexey Fisher wrote: On Sa, 2011-06-11 at 21:55 -0700, Carl Michal wrote: [snip] Most frames are terminated with EOF, but occasionally an FID and EOF are found in the same packet. So two buffers are marked as completed, but the second one shouldn't be (I don't think). [snip] I just realized: NO_FID quirk, do not disables FID handling if there is some wrong FID bit appear. It assume webcam do not use FID bit at all. Try attached patch and load module with NO_FID quirk - quirks=0x10 I think you nailed it. Every frame looks perfect now. I don't think that's the right solution. If FID toggling is completely ignored, loosing an EOF packet will cause the driver to loose a frame. Quoting one of your logs: uvcvideo: Frame complete (FID bit toggled) buf: 3, bytes: 63504. uvcvideo: Frame complete (EOF found) buf: 0, bytes: 1072. Your device either sets the EOF bit too late or toggles the FID bit too early. Given that the previous buffers are 64684 and 64728 bytes in size, my guess is that FID is toggled too early. We can try to ignore the FID bit being toggled if EOF is set. Could you please try this patch: diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c index fc766b9..748ec99 100644 --- a/drivers/media/video/uvc/uvc_video.c +++ b/drivers/media/video/uvc/uvc_video.c @@ -426,7 +426,8 @@ static int uvc_video_decode_start(struct uvc_streaming *stream, return -ENODATA; } - fid = data[1] UVC_STREAM_FID; + fid = data[1] UVC_STREAM_EOF + ? stream-last_fid : data[1] UVC_STREAM_FID; /* Increase the sequence number regardless of any buffer states, so * that discontinuous sequence numbers always indicate lost frames. The trace shows a few of these: Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480 anyway) - in MJPG all the frames have the right size. If the error bit is set, the payload is dropped as the driver considers it to be corrupted. For uncompressed formats we can try processing the packet is if it were correct. This will produce frame corruption, but should avoid part of the image from being shifted. We can additionally mark the V4L2 buffer as being faulty. For compressed data this will likely not help. There is a some weirdness with frame rates depending on the exposure setting: 1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter priority mode, and aperture priority mode. Auto and shutter don't seem to be settable (errors from guvcview when chosen). This will be fixed in kernel 3.0. There is also an Exposure, auto priority checkbox. Frame rates drop dramatically in manual mode (to 10-15fps from 30). But I can't really complain at this point - the corrupt frames are gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Hi Alexey, On Tuesday 14 June 2011 09:39:47 Alexey Fisher wrote: Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal: Hi, I think you nailed it. Every frame looks perfect now. The trace shows a few of these: Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480 anyway) - in MJPG all the frames have the right size. There is a some weirdness with frame rates depending on the exposure setting: 1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter priority mode, and aperture priority mode. Auto and shutter don't seem to be settable (errors from guvcview when chosen). There is also an Exposure, auto priority checkbox. Frame rates drop dramatically in manual mode (to 10-15fps from 30). But I can't really complain at this point - the corrupt frames are gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? Thanks, Hi, it seems like I am much better off by fully disabling FID (with your patch) than before. With the patch, YUYV frames are _always_ the right size. There are still some problems: 1) corrupt frames - with part of the image missing or the image displaced. Sometimes (but definitely not always) these occur at the same time as a trace message saying the error bit is set. 2) sometimes the camera just won't start. when guvcview (or luvcview) is started, no frames come back from the camera. There is a light next to the camera that comes on to indicate it should be active, but no frames arrive. There seems to be a fairly strong correlation with using luvcview (which from the traces seems to use some different mechanism to get frames from the driver from guvcview. guvcview polls, luvcview doesn't). Sometimes just restarting guvcview several times will work and the camera eventually starts. Sometimes just changing resolution or frame rates succeeds in starting the camera. I haven't found anything reproducible. I do not think this is related to your patch, as it did happen once before your patch was applied. Unloading and reloading the uvcvideo and ehci_hcd modules does not consistently solve it. guvcview just lists: Could not grab image (select timeout): Resource temporarily unavailable and the trace shows guvcview polling, but nothing else going on. I have tried adding the other quirks to the FID quirk, but haven't seen any improvement with any others. Thanks for you help - Carl Webcam returns error in the middle of some frame, theoretically we should drop complete frame. But current uvcvideo just gather data and assume the cam will resend previous parts to complete the frame. Try attached patch additionally to my previous one. What about not ignoring the data in addition to setting buf-error to 1 ? This won't solve corruptiong, but would avoid the image effect for uncompressed formats. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Hi Carl, On Wednesday 15 June 2011 08:31:32 Carl Michal wrote: On Tue, 14 Jun 2011, Alexey Fisher wrote: Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal: Hi, I think you nailed it. Every frame looks perfect now. The trace shows a few of these: Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480 anyway) - in MJPG all the frames have the right size. There is a some weirdness with frame rates depending on the exposure setting: 1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter priority mode, and aperture priority mode. Auto and shutter don't seem to be settable (errors from guvcview when chosen). There is also an Exposure, auto priority checkbox. Frame rates drop dramatically in manual mode (to 10-15fps from 30). But I can't really complain at this point - the corrupt frames are gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? Thanks, Hi, it seems like I am much better off by fully disabling FID (with your patch) than before. With the patch, YUYV frames are _always_ the right size. There are still some problems: 1) corrupt frames - with part of the image missing or the image displaced. Sometimes (but definitely not always) these occur at the same time as a trace message saying the error bit is set. 2) sometimes the camera just won't start. when guvcview (or luvcview) is started, no frames come back from the camera. There is a light next to the camera that comes on to indicate it should be active, but no frames arrive. There seems to be a fairly strong correlation with using luvcview (which from the traces seems to use some different mechanism to get frames from the driver from guvcview. guvcview polls, luvcview doesn't). Sometimes just restarting guvcview several times will work and the camera eventually starts. Sometimes just changing resolution or frame rates succeeds in starting the camera. I haven't found anything reproducible. I do not think this is related to your patch, as it did happen once before your patch was applied. Unloading and reloading the uvcvideo and ehci_hcd modules does not consistently solve it. guvcview just lists: Could not grab image (select timeout): Resource temporarily unavailable and the trace shows guvcview polling, but nothing else going on. I have tried adding the other quirks to the FID quirk, but haven't seen any improvement with any others. Thanks for you help - Carl Webcam returns error in the middle of some frame, theoretically we should drop complete frame. But current uvcvideo just gather data and assume the cam will resend previous parts to complete the frame. Try attached patch additionally to my previous one. Hi, its very hard to say if this helps or not. There are still corrupt frames, and some seem to occur at about the same time as the error bit trace messages, but some don't show anything unusual in the traces that I've noticed yet. Since all the uncompressed frames were the right size (even ones where the error bit was set somewhere) those frames are at least complete. Could you please add the packet size to the Dropping payload (error bit set) message ? I'm curious to see whether the error bit is set in empty packets only (len == data[0]) or in non-empty payloads as well. Is there some convenient way to capture just those frames with the error bit set? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Hi Carl, On Friday 17 June 2011 23:33:25 Carl Michal wrote: [snip] I've been looking at lengths of packets and headers in packets where these unexpected STI, RES, EOH and ERROR bits are set. There are many things that seem inconsistent, but there are some patterns that come up repeatedly. For example getting a packet with an ERROR bit set that has a length of 2048 and a header length (from data[0]) of 127 or 125 or 110 or some other big number. That packet gets discarded because of the error bit, but then when the frame ends, it is 2048 bytes shorter than it should be. I've also seen that with a packet length of 1024 and the frame ending 1024 bytes short. It looks like the header has somehow disappeared and the image data is being interpreted as header. Good catch. To test this, I put in checks in uvc_video_decode_isoc for any EOH, STI, RES or ERROR - if any are set (or unset for EOH) then to return a header length of 0, so that the entire packet gets used as image data. This by no means solves all my problems, but with that - I do find at least some frames assembled this way are complete and uncorrupted. So somehow some headers are disappearing? That's totally against the UVC specs. We could work around it in the driver if there was a reliable way to detect that a frame doesn't start with a header, but that's not possible. I would consider the camera as completely broken. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Hi Alexey, On Friday 24 June 2011 20:25:03 Alexey Fisher wrote: Am Freitag, den 24.06.2011, 20:08 +0200 schrieb Laurent Pinchart: On Tuesday 14 June 2011 09:39:47 Alexey Fisher wrote: Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal: Hi, I think you nailed it. Every frame looks perfect now. The trace shows a few of these: Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480 anyway) - in MJPG all the frames have the right size. There is a some weirdness with frame rates depending on the exposure setting: 1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter priority mode, and aperture priority mode. Auto and shutter don't seem to be settable (errors from guvcview when chosen). There is also an Exposure, auto priority checkbox. Frame rates drop dramatically in manual mode (to 10-15fps from 30). But I can't really complain at this point - the corrupt frames are gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? Thanks, Hi, it seems like I am much better off by fully disabling FID (with your patch) than before. With the patch, YUYV frames are _always_ the right size. There are still some problems: 1) corrupt frames - with part of the image missing or the image displaced. Sometimes (but definitely not always) these occur at the same time as a trace message saying the error bit is set. 2) sometimes the camera just won't start. when guvcview (or luvcview) is started, no frames come back from the camera. There is a light next to the camera that comes on to indicate it should be active, but no frames arrive. There seems to be a fairly strong correlation with using luvcview (which from the traces seems to use some different mechanism to get frames from the driver from guvcview. guvcview polls, luvcview doesn't). Sometimes just restarting guvcview several times will work and the camera eventually starts. Sometimes just changing resolution or frame rates succeeds in starting the camera. I haven't found anything reproducible. I do not think this is related to your patch, as it did happen once before your patch was applied. Unloading and reloading the uvcvideo and ehci_hcd modules does not consistently solve it. guvcview just lists: Could not grab image (select timeout): Resource temporarily unavailable and the trace shows guvcview polling, but nothing else going on. I have tried adding the other quirks to the FID quirk, but haven't seen any improvement with any others. Thanks for you help - Carl Webcam returns error in the middle of some frame, theoretically we should drop complete frame. But current uvcvideo just gather data and assume the cam will resend previous parts to complete the frame. Try attached patch additionally to my previous one. What about not ignoring the data in addition to setting buf-error to 1 ? This won't solve corruptiong, but would avoid the image effect for uncompressed formats. My english (and c) are not my bet qualities. But currently i'm really not sure if i understand. Was it sarcasm? Not at all :-) If the error bit is set, the packet will be dropped. For uncompressed formats, dropping the data will shift part of the frame up/left and possibly mess the color ups. Instead of doing that, we could handle packets with the error bit set normally. The data will likely be corrupted, but that will just corrupt a small part of the frame, and won't shift the rest of the frame up/left. We should then also set buf-error to 1 as done in your patch, to tell applications that the V4L2 buffer contains errors. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Fix potential oops rollback after camera fails to start
Hi Sjoerd, On Saturday 18 June 2011 18:19:45 Sjoerd Simons wrote: On Sat, 2011-06-18 at 17:28 +0200, Laurent Pinchart wrote: Thank you for the patches, and sorry for my late reply. The patches look good to me. Could you please give me your Signed-off-by line for both of them ? Sorry about that, patches with signed-off-by attached. Thank you. I'll try to push the patches to 3.0. If not possible, they will go to 3.1. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] VAIO Webcam - 04f2:b26d Chicony Electronics Co.
Hi Giacomo, On Thursday 02 June 2011 10:20:12 Giacomo wrote: Dear Linux UVC development team, I've just bought a SONY VAIO VPCSB laptop, which includes the following built-in webcam 04f2:b26d Chicony Electronics Co., Ltd Unfortunately, if I try to switch on the webcam, the laptop freezes Ouch. (btw, I'm using Debian Squeeze, kernel 2.6.38-2-686). Is such a webcam already supported? Or may I ask to enlist it for the development? First of all, could you please send me the output of lsusb -v -d 04f2:b26d running as root if possible ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Microsoft Lifecam HD 3000 (exposure + led issues)
Hi Marco,
On Sunday 05 June 2011 12:42:43 Marco Gulino wrote:
Could you please send me the output of lsusb -v (running as root if
possible) for your webcam ?
Sure... you can find it in the attachment.
Thank you. I've updated the supported devices list.
I also found out (reading another thread in this list:
https://lists.berlios.de/pipermail/linux-uvc-devel/2011-February/006321.htm
l ) that the camera does accept some discrete values for exposure control,
i guess the sensor is exactly the same as Lifecam HD 5000 then.
I patched v4l2ucp to display a combo in place of a slider to easly setup
these values, so at least this problem is partially fixed (still annoying,
but it's usable at least).
OK, problem solved :-)
UVC doesn't provide a standard control for this. Some cameras support
controlling the LED manually, and implements that using UVC extension
units.
Without manufacturer documentation it might be difficult to find out how
to control the LED, but trial/error is possible (be warned that this
could in theory brick the camera).
I see... it seems kinda hard then...
Anyway worth trying, it would really help cooling down the camera... Any
hints on what to try?
According to the USB descriptors, your camera has one extension unit with 8
controls.
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 5
guidExtensionCode {29a787c9-d359-6945-8467-ff0849fc19e8}
bNumControl16
bNrPins 1
baSourceID( 0) 4
bControlSize2
bmControls( 0) 0xff
bmControls( 1) 0xff
iExtension 0
Using the UVC extension unit API (made public in the 3.0 kernel and documented
in Documentation/video4linux/uvcvideo.txt) you can query those controls and
modify them. Have a look at the UVCIOC_CTRL_QUERY ioctl documentation. I still
need to publish a tool to automate the process.
Be warned that poking XU controls directly might in theory break your device,
even though chances are low. Chances are also unfortunately low that randomly
poking controls will turn the LED on or off (but you never know). Can you
control it manually in Windows ?
--
Regards,
Laurent Pinchart
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Request to help me in bringing up UVC driver for linux-2.6.18 version
Hi, On Tuesday 07 June 2011 07:12:29 purushotham reddy wrote: Hello Sir/madam, I would like to build UVC driver in old linux kernel-2.6.18 in which there is no UVC driver in it. I would like to know is there any patch which can be applied to my kernel. Also, please let me know the procedure to build this driver to my kernel. You can try to compile the whole V4L subsystem using the media_build git tree from git.linuxtv.org. Instructions are available at http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L- DVB_Device_Drivers. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvcvideo: Failed to submit URB 0 (-28) error for VGA-YUV capture
Hi, On Wednesday 08 June 2011 10:07:20 Chandrashekhar Lavania wrote: Hi, I am trying to capture VGA frames in YUYV format from Logitech QuickCam E3500. But When I try to do this , I get the following error: uvcvideo: Failed to submit URB 0 (-28). Also, I put printk in the uvc_init_video_isoc() function of uvc_video.c to get psize and size values in the following manner: psize = le16_to_cpu(ep-desc.wMaxPacketSize); psize = (psize 0x07ff) * (1 + ((psize 11) 3)); size = stream-ctrl.dwMaxVideoFrameSize; printk(KERN_ALERT SIZE = %d\n,size); printk(KERN_ALERT PSIZE = %d\n,psize); When I try to capture VGA - YUV I get the following alerts: SIZE = 614400 PSIZE = 1984 This is for single frame capture. I tried to do the same thing for QVGA -YUV, and then I was able to capture the image. I got the following alerts: SIZE = 153600 PSIZE = 512 What could be causing this... Do you have other connected USB devices that could use the USB bandwidth ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Z-Star USB Digital Microscope
On Monday 13 June 2011 09:34:35 Alexey Fisher wrote: On Mo, 2011-06-13 at 14:18 +0800, hagar wrote: On 06/12/2011 02:11 PM, Alexey Fisher wrote: On So, 2011-06-12 at 13:51 +0800, hagar wrote: [snip] Bad news. uvcvideo thins your cam has only 640x480, because your cam tells it has only 640x480. See this part of lsusb info: Bus 001 Device 013: ID 0ac8:3610 Z-Star Microelectronics Corp. Device Descriptor: 8- VideoStreaming Interface Descriptor: bLength26 bDescriptorType36 bDescriptorSubtype 3 (STILL_IMAGE_FRAME) bEndpointAddress0 bNumImageSizePatterns 5 wWidth( 0)640 wHeight( 0) 480 wWidth( 1)352 wHeight( 1) 288 wWidth( 2)320 wHeight( 2) 240 wWidth( 3)176 wHeight( 3) 144 wWidth( 4)160 wHeight( 4) 120 bNumCompressionPatterns 5 According to The WinXP driver ini file the camera is capable of - ( Would all the hex numbers be of use ? ) UVC FUNC_MODE HIGH SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288, 800x600, 1024x768, 1280x960, 1280x1024, (?? 1600x1280, 2000x1600, 2560x2048 ?? ) UVC FUNC_MODE FULL SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288 UVC FUNC_MODE YUY2 HIGH SPEED VIDEO 640x480, 160x120, 176x144, 320x240, 352x288, 800x600, 1024x768, 1280x960, 1280x1024, (?? 1600x1280, 2000x1600, 2560x2048 ?? ) UVC FUNC_MODE STILL PIN HIGH SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288, 800x600, 1024x768, 1280x960, 1280x1024, (?? 1600x1280, 2000x1600, 2560x2048 ?? ) UVC FUNC_MODE STILL PIN FULL SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288 Can you please check the driver (some.sys file) it use under win xp. The idea of UVC (usb video class) is zero config functionality. You plug some device and it just work. It is only possible if manufacture write all needed settings in the eeprom of the device (webcam,...). If you plug your device in MacOSX or Windows Vista/7, in any UVC ready OS, you will get same result - max resolution 640x480. If you need to install some thing to get more, then it is not UVC device, at least not 100%. Only good thing you can do for you and all others is to send this device back. Manufactures should learn to read and use uvc specification. This isn't the first time I hear about such a problem. I wonder how the Windows UVC driver handles that. usbsnoop might shed some light on this. Hagar, the device isn't listed in the supported devices list. I will add it. Do you have a link to a website describing the product ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam works intermittently - [18e3:9512] built-in in Hannspree SN12E2 netbook
as /devices/pci:00/:00:1d.1/usb7/7-2/7-2:1.0/input/input12 [10462.300114] usb 7-2: USB disconnect, address 3 [10462.304073] cannot submit datapipe for urb 0, error -19: no device peed USB device using ehci_hcd and address 13 [10456.984412] hub 2-0:1.0: unable to enumerate USB device on port 4 [10457.228083] usb 2-4: new high speed USB device using ehci_hcd and address 14 [10457.296381] hub 2-0:1.0: unable to enumerate USB device on port 4 [10457.484269] hub 2-0:1.0: unable to enumerate USB device on port 4 [10457.728073] usb 2-4: new high speed USB device using ehci_hcd and address 16 [10457.796365] hub 2-0:1.0: unable to enumerate USB device on port 4 [10458.064094] usb 7-2: new full speed USB device using uhci_hcd and address 3 [10458.292116] usb 7-2: not running at top speed; connect to a high speed hub [10458.422485] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:9512) [10458.436312] input: USB 2.0 Camera as /devices/pci:00/:00:1d.1/usb7/7-2/7-2:1.0/input/input12 [10462.300114] usb 7-2: USB disconnect, address 3 [10462.304073] cannot submit datapipe for urb 0, error -19: no device Also, sometimes I get endless unable to enumerate USB device messages -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Frame Rate/Corruption C910, plus 4 others
, 480M |__ Port 3: Dev 13, If 0, Class=audio, Driver=snd-usb-audio, 480M |__ Port 3: Dev 13, If 1, Class=audio, Driver=snd-usb-audio, 480M |__ Port 3: Dev 13, If 2, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M |__ Port 3: Dev 13, If 3, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/5p, 480M Windows users have reported getting 30fps. http://forums.quickcamteam.net/showthread.php?tid=1345page=2 Sometimes I get a little more than 15fps, for no apparent reason. For example, now guvcview reports 18.00fps at 640x480/30P-MJPG and when I tell guvcview to capture video, it gives 24.18fps: Duration: 00:00:05.54, start: 0.00, bitrate: 16494 kb/s Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 24.18 tbr, 24.18 tbn, 24.18 tbc http://ffmpeg-users.933282.n4.nabble.com/What-does-the-output-of-ffmpeg-mea n-tbr-tbn-tbc-etc-td941538.html The video is corrupted. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi, On Thursday 16 June 2011 11:09:51 Ajay Bhargav wrote: Hi Paulo, I have the pdf document of the same. But the thing is my camera is UVC V1.0 and actual format coming from camera is H.264 encoded stream in MPEG2-TS format. So i will have to look for only MPEG2-TS support. I hope i am going in right direction. As per my UVC traces, the video streaming format is 10 which is MPEG2-TS. @Laurent, Please provide me some information so i can move ahead. H.264 UVC payloads have been implemented in various webcams before the official H.264 UVC payload spec got released. Those implementations are not documented, and not supported by the driver. Without documentation from the manufacturer, H.264 encoder parameters won't be supported. The official H.264 UVC specification isn't better. Its only purpose is to support Logitech webcams in Skype under Windows. Its quality is way below what I would expect from a USB-IF specification. I don't plan to implement support for that spec in the uvcvideo driver in the near future. I'll review patches, but I will NAK anything that isn't clean enough. And from reading the spec producing a clean implementation will be pretty difficult. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] 5986:0343 support
Hi Julian, On Saturday 18 June 2011 16:49:18 Julian Sikorski wrote: W dniu 2011-06-18 16:44, Laurent Pinchart pisze: On Monday 16 May 2011 02:13:35 Julian Sikorski wrote: Hi, I would like to report that the said device seems to work on Fedora 15. I am attaching lsusb -v output. lsusb reports it as Acer for some reason. Thanks for the report. I'll update the supported devices list. Could you please tell me whether the device is a standalone webcam or integrated into a laptop, and give me the webcam/laptop commercial brand and model ? This device is integrated into the laptop. The laptop is a Clevo P150HM. Thank you. Supported devices list updated. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] New cam: Celestron Model #44421 is supported
Hi Mike, On Saturday 18 June 2011 21:20:10 Mike Spencer wrote: You wrote: Hi Michael, On Friday 13 May 2011 06:29:00 Mike Spencer wrote: The list of supported devices at http://www.ideasonboard.org/uvc/ invites reporting to linux-uvc-devel of uvc devices not listed there. This one isn't there: Celestron Digital Microscope Imager Model #44421 Could you please send me the output of lsusb -v for your device (running as root if possible) ? I'll then update the supported devices list. Appended below. It appears to include data for internal hubs that you probably don't need or want but I'm pretty clueless on USB hacking so I've done exactly as you asked rather than edit out what I think, perhaps wrongly, is unwanted. Thank you for the information. The camera device (19b4:0104) descriptors would have been enough, but too much information is (usually) better than too little. I've updated the supported devices list. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] 5986:0343 support
Hi Julian, On Monday 16 May 2011 02:13:35 Julian Sikorski wrote: Hi, I would like to report that the said device seems to work on Fedora 15. I am attaching lsusb -v output. lsusb reports it as Acer for some reason. Thanks for the report. I'll update the supported devices list. Could you please tell me whether the device is a standalone webcam or integrated into a laptop, and give me the webcam/laptop commercial brand and model ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Obtaining driver from git
Hi Brent, Sorry for the late reply. On Wednesday 18 May 2011 22:36:25 Brent Weatherall wrote: I cloned the repository and added the uvcvideo.git per the instructions on 'http://git.linuxtv.org/pinchartl/uvcvideo.git'. I am new to git and having a horrible time obtaining the revision I want. Using a qtgit I see a branch of uvcvideo.h which has the 'struct uvc_xu_control_query' defined. Even though the GUI client can show this to me, there does not seem to be a straightforward way to load this version of the repository so I can build it and use use the updated version of the uvcvideo.ko module on my development machine. If I am reading the GUI client information correctly, I want to get SHA1 - cdd0bc822e118946c1ce2b78ea7332dbd967ebcf, with short log entry 'uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*' and ID '52'. After reading the man pages for git it seems to me I should simply do either: 1. git pull git://linuxtv.org/pinchartl/uvcvideo.git cdd0bc822e118946c1ce2b78ea7332dbd967ebcf or 2. git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git cdd0bc822e118946c1ce2b78ea7332dbd967ebcf However, these fail with 'fatal: Couldn't find remote ref cdd0bc822e118946c1ce2b78ea7332dbd967ebcf' and I am at a loss as to how I am supposed to retrieve the revision I would like to try out. Can anyone offer some insights into what I am missing? The revision I am interested in is a branch from the main line. I also tried pulling in the main line where the branch occurred with the intent of patching in the changes, but I receive the same error message. git checkout cdd0bc822e118946c1ce2b78ea7332dbd967ebcf should do the job. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
