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
[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] [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
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] Webcam with H264 encoder not in Devicelist
Hi Ajay, On Thursday 03 November 2011 13:43:17 Ajay Bhargav wrote: > > Thank you taking charge on the MPEG2-TS support. I was thinking that > MPEG2-TS container format may contain video stream encoded differently > other than H.264. So is it good to take out the container part and > exposing the raw stream? I'm not sure about that. Demuxing should really be done in userspace, not inside the kernel. If we need something uvcvideo-specific, it should probably live in libv4l. > I faced problem when I was storing H.264 stream only using gstreamer. Video > was running too fast with no timing information and VLC was unable to play > that stream. > > how did you deal with the FID problem? coz MPEG2-TS does not provide such > information. What I did was to count certain number of packets and toggle > FID forcefully so that buffer is ready for reading. It looks like you are > missing some packets coz of which video is bad. I faced the same problem > untill i added that FID hack. Please see the patches I've just pushed to the uvcvideo-wip-mpeg branch git://linuxtv.org/pinchartl/uvcvideo.git, and especially patch "uvcvideo: Fix FID and EOF handling for stream-based formats" which deals with this problem. > I hope this will help you. Please let me know if I can help you in this. Could you please test the patches ? -- 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 Monday 21 November 2011 16:49:46 Robert Krakora wrote: > On Thu, Nov 10, 2011 at 3:34 PM, Robert Krakora wrote: > > On Thu, Nov 3, 2011 at 7:55 AM, Laurent Pinchart wrote: > >> 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. > > > > Let me know when you have some patches available for FaceVsion. In my > > hacking, I was able to get MPEG2 TS H.264, but the video looked very > > washed out although motion was fluid (not jerky). > > Have you had time to work on the FaceVsion support lately? ;-) Not as much as I would have liked, but yes, I have :-) I've pushed patches to the uvcvideo-wip-mpeg branch in git://linuxtv.org/pinchartl/uvcvideo.git. The last patch is still work in progress, and I'm not totally happy with the "psize * 500" heuristic. I've also updated yavta to support writing all frames to a single file. Capturing 100 frames with yavta to a single file produces something I can play with mplayer, but not without issues. The video doesn't look very good, and mplayer prints lots of error messages: $ mplayer mpeg.bin MPlayer SVN-r33094-4.4.5 (C) 2000-2011 MPlayer Team Playing mpeg.bin. TS file format detected. VIDEO H264(pid=68) NO AUDIO! NO SUBS (yet)! PROGRAM N. 1 FPS seems to be: 29.970030 Load subtitles in ./ == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == Audio: no sound Starting playback... Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 1280x720 => 1280x720 Planar YV12 V: 0.1 1/ 1 ??% ??% ??,?% 0 0 [h264 @ 0xae68a0]out of range intra chroma pred mode at 28 19 [h264 @ 0xae68a0]error while decoding MB 28 19 [h264 @ 0xae68a0]concealing 2101 DC, 2101 AC, 2101 MV errors V: 0.1 3/ 3 ??% ??% ??,?% 0 0 [h264 @ 0xae68a0]mb_type 109 in P slice too large at 19 16 [h264 @ 0xae68a0]error while decoding MB 19 16 [h264 @ 0xae68a0]concealing 2350 DC, 2350 AC, 2350 MV errors V: 0.2 5/ 5 ??% ??% ??,?% 0 0 [h264 @ 0xae68a0]P sub_mb_type 22 out of range at 47 7 [h264 @ 0xae68a0]error while decoding MB 47 7 [h264 @ 0xae68a0]concealing 3042 DC, 3042 AC, 3042 MV errors V: 0.3 7/ 7 ??% ??% ??,?% 0 0 [h264 @ 0xae68a0]out of range intra chroma pred mode at 60 3 [h264 @ 0xae68a0]error while decoding MB 60 3 [h264 @ 0xae68a0]concealing 3349 DC, 3349 AC, 3349 MV errors V: 0.3 9/ 9 ??% ??% ??,?% 0 0 [h264 @ 0xae68a0]P sub_mb_type 28 out of range at 50 20 [h264 @ 0xae68a0]error while decoding MB 50 20 [h264 @ 0xae68a0]concealing 1999 DC, 1999 AC, 1999 MV 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] 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] 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] [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
> ---
> 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 > > > > t
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] [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 Pinchart > > 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 -- 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 Ajay, On Friday 04 November 2011 06:38:20 Ajay Bhargav wrote: > - "Laurent Pinchart" 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
[Linux-uvc-devel] [PATCH 2/2] uvcvideo: Extract video stream statistics
Export the statistics through debugfs.
Signed-off-by: Laurent Pinchart
---
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 = &
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 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
---
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
+#include
+#include
+
+#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/drive
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
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] 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] 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] 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] 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] 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] 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] 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] 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] MS LifeCam Cinema and Studio have no usb bandwidth issue under Windows
p the > camera from asking for all the available usb bandwidth. I was only > thinking that if it would be possible to find out how the camera is > "convinced" to not asked for full bandwidth under Windows - maybe that > can be replicated in the uvc driver under Linux. I don't think Windows tells the camera to use less bandwidth. I obviously can't tell for sure what the Windows driver does, but I expected it to either - use heuristics to compute the amount of bandwidth a webcam really requires - have device-specific quirks (quite unlikely though, unless the webcam comes with its specific driver) - allow allocation of more than 80% of the USB bandwidth to periodic USB transfers If I'm not mistaken Linux recently got support for the third option, maybe this could help you. Details can be found on the linux-usb mailing list AFAIR. Another option would be to snoop USB transfers in Windows to find out how much bandwidth the webcam requests and how much bandwidth Windows allocates. > However, I know almost nothing about the intricacies of the uvc standard and > the corresponding Linux (or Windows) implementation - that is why I was > asking if there is anyway to probe the uvc driver in Windows and find out > more that way. -- 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] Accessing XU controls in an UVC webcam
Hi Peter,
On Friday 07 October 2011 06:54:48 Peter Zotov wrote:
> Hello.
>
> I have an h.264 encoding webcam, and I am trying to make it
> work. Currently, it outputs a valid h.264 stream, but each frame
> is compressed to ~12K of data, resulting in a very distorted, but
> still barely recognizable image. I suppose that some of the XU controls
> are responsible for the encoding quality, and they're in some extreme
> position by default.
>
> The webcam is "046d:0828 Logitech, Inc. HD Webcam B990".
>
> Here are the XU descriptors (whole `lsusb -v' is 52K long, and I'm not
> sure if I really should post it to the list):
Messages are currently limited to 75kB. You can also post the descriptors
compressed, or send them privately to me.
[snip]
> I've googled all the GUIDs, and it turned out that first four of them
> also appear in lsusb listings for non-encoding webcams as well. So, I
> decided that some of the other three contain the quality control. (It
> may not be true, of course, but that's what I will start with.) They
> have 19 different controls, apparently.
>
> Now, I am trying to tune some of these with UVC, with no success. Here
> is the relevant code:
>
> %<%<%<%<%<%<
> void init_controls()
> {
> struct uvc_xu_control_mapping mapping = {
> .id = XU_START,
> .name = "XU control",
> .selector = 1,
> .size = 1,
> .offset = 0,
> .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
> .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> };
>
> guid_to_byte_array("{a032c549-154f-fc4c-908a-5bce154b1cea}",
> mapping.entity);
>
> if(ioctl(fd, UVCIOC_CTRL_MAP, &mapping) < 0) {
> fprintf(stderr, "Cannot add control: %d, %s\n",
> errno, strerror(errno));
> exit(EXIT_FAILURE);
> }
> }
> %<%<%<%<%<%<
>
> (The `guid_to_byte_array' function was taken from libwebcam
> sources. Handcrafting the GUID with proper endianness gives
> the same result).
>
> It outputs: Cannot add control: 2, No such file or directory
>
> I've examined USB bus transactions. They include a control `request'
> and an interrupt `reply'.
>
> The control frame is here:
>bmRequestType: 0x21
>bRequest: 1
>wValue: 0x0200
>wIndex: 1
>wLength: 26
>
> This is somewhat strange. Per sect. 4.2.2.4 of UVC1.1 spec,
> bmRequestType=0x21 and bRequest=1 indicate a SET_CUR transfer.
> wValue of 0x0200 addresses selects control 2 instead of 1 (through
> this is still in range), and wIndex selects XU 1 (while my one
> has bUnitID of 8).
wIndex selects the interface, and wValue the control. This request is a
SET_CUR request on the UVC video commit control. It got sent by a
uvc_commit_video() call, either from uvc_video_resume() if the camera got
resumed or from uvc_video_enable() if the driver received a VIDIOC_STREAMON
call.
> Also, I do not understand at all what does the
> data transmitted means:
>
> 00:00:01:01:00:00:00:00
> 00:00:00:00:00:00:00:00
> 32:00:00:60:09:00:00:0c
> 00:00
>
> The reply contains a -ENOENT (-2) code, as shown by Wireshark.
>
> Using different GUID's or different selectors does not change
> anything.
>
> What am I doing wrong here?
I'm not sure exactly what you're doing wrong. Setting the uvcvideo trace
parameter to 0x might give you more information.
On a side note, if you're using a recent kernel, you should use
UVCIOC_CTRL_QUERY. This will let you query a UVC control directly without
going through mappings. That's much easier when experimenting with XU
controls.
--
Regards,
Laurent Pinchart
___
Linux-uvc-devel mailing list
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] 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] 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] 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] 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 (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] 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
#include
+#include
+#include
#include
#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
Re: [Linux-uvc-devel] (no subject)
Hi Josef, Thanks for the report. On Monday 31 October 2011 12:22:35 Josef Burg wrote: > Hi Alexey, > > I tested all the modes you reported and came up with te following table: >| Dell| Logilink > > ---+-- > without quirks | working | not working > UVC_QUIRK_STATUS_INTERVAL | working | not working > UVC_QUIRK_PROBE_MINMAX | working *1 | working > UVC_QUIRK_PROBE_EXTRAFIELDS| not working | not working > UVC_QUIRK_BUILTIN_ISIGHT | not working | not working > UVC_QUIRK_STREAM_NO_FID| not working | not working > UVC_QUIRK_IGNORE_SELECTOR_UNIT | working | not working > UVC_QUIRK_FIX_BANDWIDTH| working | not working > UVC_QUIRK_PROBE_DEF| working | not working > UVC_QUIRK_RESTRICT_FRAME_RATE | working | not working > > *1 the image looks very pixelated > > > So sorry for the report for the Dell webcam. I had quirks enabled by > default for my Logilink-Webcam and didn't test it without quirks :-/ > > But the Logilink USB-Webcam is only working with quirks set to 0x2 > (UVC_QUIRK_PROBE_MINMAX). Otherwise I get 'Unable to set format: > Input/output error\n Init v4L2 failed !! exit fatal' when starting > luvcview. I've added the quirk to the driver and updated the supported devices list. I will push the changes to v3.3. -- 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
11f..0c21a56 100644
> --- a/drivers/media/video/uvc/uvc_v4l2.c
> +++ b/drivers/media/video/uvc/uvc_v4l2.c
> @@ -500,6 +500,8 @@ static int uvc_v4l2_open(struct file *file)
> handle->state = UVC_HANDLE_PASSIVE;
> file->private_data = handle;
>
> +kref_get(&stream->dev->kref);
> +
> return 0;
> }
>
> @@ -528,6 +530,7 @@ static int uvc_v4l2_release(struct file *file)
> uvc_status_stop(stream->dev);
>
> usb_autopm_put_interface(stream->dev->intf);
> +kref_put(&stream->dev->kref, uvc_delete);
> return 0;
> }
>
> diff --git 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 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] [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 > Signed-off-by: Alexey Fisher > --- > 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] 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 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] [PATCH RFC] uvcvideo: Add a mapping for H.264 payloads
Hi Stephan,
On Friday 28 January 2011 20:38:58 Stephan Lachowsky wrote:
> Associate the H.264 GUID with an H.264 pixel format so that frame
> and stream based format descriptors with this GUID are recognized
> by the UVC video driver.
Can I get your Signed-off-by line for this patch ?
> ---
> drivers/media/video/uvc/uvc_driver.c |5 +
> drivers/media/video/uvc/uvcvideo.h |3 +++
> include/linux/videodev2.h|1 +
> 3 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 6bcb9e1..a5a86ce 100644
> --- a/drivers/media/video/uvc/uvc_driver.c
> +++ b/drivers/media/video/uvc/uvc_driver.c
> @@ -108,6 +108,11 @@ static struct uvc_format_desc uvc_fmts[] = {
> .guid = UVC_GUID_FORMAT_MPEG,
> .fcc= V4L2_PIX_FMT_MPEG,
> },
> + {
> + .name = "H.264",
> + .guid = UVC_GUID_FORMAT_H264,
> + .fcc= V4L2_PIX_FMT_H264,
> + },
> };
>
> /*
>
> diff --git a/drivers/media/video/uvc/uvcvideo.h
> b/drivers/media/video/uvc/uvcvideo.h index e522f99..4f65ac6 100644
> --- a/drivers/media/video/uvc/uvcvideo.h
> +++ b/drivers/media/video/uvc/uvcvideo.h
> @@ -155,6 +155,9 @@ struct uvc_xu_control {
> #define UVC_GUID_FORMAT_MPEG \
> { 'M', 'P', 'E', 'G', 0x00, 0x00, 0x10, 0x00, \
>0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> +#define UVC_GUID_FORMAT_H264 \
> + { 'H', '2', '6', '4', 0x00, 0x00, 0x10, 0x00, \
> + 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
>
> /*
> *
> Driver specific constants.
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 5f6f470..d3b5877 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -341,6 +341,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG
> */ #define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /*
> 1394 */ #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E',
> 'G') /* MPEG-1/2/4*/ +#define V4L2_PIX_FMT_H264 v4l2_fourcc('H',
> '2', '6', '4') /* H.264 Annex-B NAL Units */
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV
> */
--
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 Wednesday 31 August 2011 10:11:41 Max Lapshin wrote: > On Wed, Aug 31, 2011 at 12:04 PM, Alexey Fisher wrote: > > But - there are some cam now, what use uvc and notuvc stuff. It will be > > interesting to use uvcvideo like a library and have some extension part. > > B990 is one of this. > > On other side, if logitech will make next month new cam with other H264 > > specification, it will be work for one cam only. Then automatically will > > come the question, who will maintain this code. > > > > One more question: do h264 part work out of the box with uvc driver on > > windows? > > Currently I see other problem: I can't find patchset in mailing list. > So it is hard to discuss if B990 is UVC or not UVC. Could someone please post the lsusb -v output for thr 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] 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 Alexey, On Wednesday 31 August 2011 10:04:25 Alexey Fisher wrote: > Am 31.08.2011 08:36, schrieb Pierre Gronlier: > > On Wed, Aug 31, 2011 at 1: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. > >>> zip ? > >>> There are some encoder setup options. > >> > >> That's the totally broken spec I don't want to support. > > > > Even if it allows Linux users to use Skype with hardware encoding camera > > ? > > I think the question like to do or not to do is not quiet correct here. > If make this webcam work, will do help in some situations... then why > not. But it looks like Laurent is only responsible for UVC module and he > is right - it is not belong to uvc. > > But - there are some cam now, what use uvc and notuvc stuff. It will be > interesting to use uvcvideo like a library and have some extension part. > B990 is one of this. > On other side, if logitech will make next month new cam with other H264 > specification, it will be work for one cam only. Then automatically will > come the question, who will maintain this code. > > One more question: do h264 part work out of the box with uvc driver on > windows? UVC devices that comply to the new UVC H.264 spec should work out of the box (provided the Windows UVC driver is new enough), but *only* with applications that implement support for UVC H.264. Applications that use the generic DirectShow API and try to get H.264 video from the device will fail. The only application that I know to work is Skype, as they co-designed the spec. UVC devices that implement another H.264 interface will require a custom driver and/or custom applications. -- 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 Pierre, On Wednesday 31 August 2011 08:36:19 Pierre Gronlier wrote: > On Wed, Aug 31, 2011 at 1: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. > > Even if it allows Linux users to use Skype with hardware encoding camera ? Yes. I've notified Logitech multiple times that their spec was totally broken before they got it standardized. I pointed out the obvious design mistakes, proposed clean solutions and offered free help. They denied all problems and stop answering. That spec has been designed solely to support Skype with Logitech webcams on Windows. Those three companies (well, two now) decided to game the system and get a completely broken specification standardized. This somehow reminds me of the OOXML fiasco. -- 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 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] 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] 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: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] 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 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 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] 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] 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] 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 : > >> 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] [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
Date: Thu, 18 Mar 2010 08:56:35 +0100
Subject: [PATCH] uvcvideo: Add user pointer streaming mode
Signed-off-by: Laurent Pinchart
---
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
#include
#include
+#include
+#include
#include
#include
#include
@@ -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(¤t->mm->mmap_sem);
+ ret = get_user_pages(current, current->mm, data & PAGE_MASK,
+ buf->npages, 1, 0, buf->pages, NULL);
+ up_read(¤t->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 succe
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] 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 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 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 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] 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] 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] 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] 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 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 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] 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] 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] 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] 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] 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] 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] 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] 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: > < 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] 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] 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] 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] 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] 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] 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] [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] [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
> 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
Acked-by: Laurent Pinchart
> ---
> 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
> +
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] 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] 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 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 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 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 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] 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] error code list
Hi Jorge, On Friday 24 June 2011 16:39:21 Jorge Yesid Rios Ortiz wrote: > Hi Laurent: > > Thanks very much for your answer. > I don't know what I must to be for to resolve this error. > > Can you give me some information about how to solve this error? Try to upgrade to a recent kernel. 2.6.14 is more than 5 years old. > El mié, 22-06-2011 a las 02:41 +0200, Laurent Pinchart escribió: > > On Tuesday 14 June 2011 18:28:02 Jorge Yesid Rios Ortiz wrote: > > > Hi: > > > > > > I have a problem when I tried to use this web-cam in my embedded > > > system: > > > > > > Camera: > > > ID 041e:4058 > > > model: Live! Cam Optia AF > > > manufacturer: Creative Technology, Ltd > > > > > > > > > Embedded system ARTILA M-501: > > > CPU: ATMEL AT91RM9200, 180MHz > > > OS: Linux 2.6.14-M5 > > > SDRAM: 64MB > > > USB Host interface: 2x, USB 2.0 compliant > > > UART: 4x, 921.6kbps > > > > > > This cams works very fine when I used it on my PC with Linux, but when > > > I plugged to my embedded system I get this message: > > > > > > usb 1-2: new full speed USB device using at91rm9200-ohci and address 5 > > > usb 1-2: Manufacturer: Creative Labs > > > uvcvideo: Found UVC 1.00 device (041e:4058) > > > uvcvideo: Non-zero status (-110) in status completion handler. > > > > > > I'm looking for about what means this code error, but I can't find > > > anything!!! > > > > > > is Anybody help me? > > > > According to /usr/include/asm-generic/errno.h, -110 is -ETIMEDOUT. > > According to Documentation/usb/error-codes.txt, -ETIMEDOUT means > > > > "Synchronous USB message functions use this code to indicate timeout > > expired before the transfer completed, and no other error was reported > > by HC." > > > > I'm surprised to see this error code reported in a URB completion > > handler. -- 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] 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 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
