linux-kernel - Re: [Linux-uvc-devel] [PATCH] Re: uvcvideo: Finally fix Logitech Quickcam for Notebooks Pro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200910090832.09254.linux@rainbow-software.org>
Date:	Fri, 9 Oct 2009 08:32:06 +0200
From:	Ondrej Zary <linux@...nbow-software.org>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	linux-uvc-devel@...ts.berlios.de, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org
Subject: Re: [Linux-uvc-devel] [PATCH] Re: uvcvideo: Finally fix Logitech Quickcam for Notebooks Pro

On Friday 09 October 2009, Laurent Pinchart wrote:
> Hi Ondrej,
>
> On Wednesday 07 October 2009 14:59:40 Ondrej Zary wrote:
> > On Tuesday 06 October 2009, Ondrej Zary wrote:
> > > Hello,
> > > I have a Logitech Quickcam for Notebooks Pro camera (046d:08c3) which
> > > just does not work even with kernel 2.6.31 and has never worked well
> > > before.
> > >
> > > On http://linux-uvc.berlios.de/, there are two problems listed. I want
> > > to really fix these two problems so the camera will just work after
> > > plugging in (and not disconnect). I started with problem no. 2 as this
> > > causes the camera not to work at all when plugged in:
> > >
> > > usb 5-2.4: new high speed USB device using ehci_hcd and address 7
> > > usb 5-2.4: configuration #1 chosen from 1 choice
> > > uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c3)
> > > uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling
> > > workaround.
> > > uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 26).
> > > uvcvideo: Failed to initialize the device (-5).
> > >
> > > When I do "modprobe snd_usb_audio", then "rmmod snd_usb_audio" and
> > > finally "modprobe uvcvideo", it works. So it looks like snd_usb_audio
> > > does some initialization that allows uvcvideo to work. It didn't work
> > > at all I didn't have snd_usb_audio module compiled.
> > >
> > > What was the change that supposedly broke this in 2.6.22?
> >
> > I discovered that it's not related to usb audio at all. Doing "rmmod
> >  uvcvideo" and "modprobe uvcvideo" repeatedly succeeded after a couple of
> >  tries. Increasing UVC_CTRL_STREAMING_TIMEOUT to 3000 helped (2000 was
> > not enough).
> >
> >
> > Increase UVC_CTRL_STREAMING_TIMEOUT to fix initialization of
> > Logitech Quickcam for Notebooks Pro.
> > This fixes following error messages:
> > uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling
> >  workaround. uvcvideo: Failed to query (129) UVC probe control : -110
> > (exp. 26). uvcvideo: Failed to initialize the device (-5).
> >
> > Signed-off-by: Ondrej Zary <linux@...nbow-software.org>
> >
> > --- linux-2.6.31-orig/drivers/media/video/uvc/uvcvideo.h	2009-09-10
> >  00:13:59.000000000 +0200 +++
> >  linux-2.6.31/drivers/media/video/uvc/uvcvideo.h	2009-10-07
> >  13:47:27.000000000 +0200 @@ -304,7 +304,7 @@
> >  #define UVC_MAX_STATUS_SIZE	16
> >
> >  #define UVC_CTRL_CONTROL_TIMEOUT	300
> > -#define UVC_CTRL_STREAMING_TIMEOUT	1000
> > +#define UVC_CTRL_STREAMING_TIMEOUT	3000
> >
> >  /* Devices quirks */
> >  #define UVC_QUIRK_STATUS_INTERVAL	0x00000001
>
> Thanks for the patch. I wonder if it will help other Logitech users.
>
> The UVC specification unfortunately doesn't give a time boundary for
> answering streaming requests, so that's up to the developers. I'm pretty
> sure we will find at least one webcam model that will require 3001ms at
> some point :-)
>
> I was thinking about adding a module parameter to set the streaming control
> timeout. I'm not sure what the default value should be though. What's your
> opinion on this ? If we decide to increase the default value, where should
> we stop ?

I really don't know. Maybe only the first request is slow as the hardware 
needs some time to initialize?

If someone knows what value is used by Windows or Mac OS X, that's probably 
the "right" choice as most devices are tested with them.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/