Hi Oleksij,
On Monday 09 July 2012 07:35:54 Oleksij Rempel wrote:
Am 08.07.2012 23:35, schrieb Laurent Pinchart:
On Sunday 08 July 2012 10:45:45 Oleksij Rempel wrote:
On 08.07.2012 09:22, Eric Ding wrote:
On 07/08/2012 02:52 PM, Oleksij Rempel (fishor) wrote:
Hi, can you please do one
Hi Eric,
On Thursday 12 July 2012 16:05:47 Eric Ding wrote:
On 07/09/2012 10:17 PM, Alan Stern wrote:
On Sun, 8 Jul 2012, Jonathan Nieder wrote:
Eric Ding wrote:
So it looks like you'd have to both look for USB_CLASS_VIDEO and check
uvc_ids[] too... which becomes somewhat hairy, since I
On 07/15/2012 08:21 PM, Laurent Pinchart wrote:
On Thursday 12 July 2012 16:05:47 Eric Ding wrote:
So... now what, then? Who decides which is the better of two evils:
obvious code duplication vs. layering violation? FWIW, it does seem
like the number of Logitech webcams which aren't
On 07/09/2012 10:17 PM, Alan Stern wrote:
On Sun, 8 Jul 2012, Jonathan Nieder wrote:
Eric Ding wrote:
So it looks like you'd have to both look for USB_CLASS_VIDEO and check
uvc_ids[] too... which becomes somewhat hairy, since I assume you don't
realy want usb_detect_quirks() to reference
Am 12.07.2012 10:05, schrieb Eric Ding:
On 07/09/2012 10:17 PM, Alan Stern wrote:
On Sun, 8 Jul 2012, Jonathan Nieder wrote:
Eric Ding wrote:
So it looks like you'd have to both look for USB_CLASS_VIDEO and check
uvc_ids[] too... which becomes somewhat hairy, since I assume you don't
realy
On 08.07.2012 07:37, Eric Ding wrote:
On 07/08/2012 09:52 AM, Alan Stern wrote:
On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:
Well, the quirk does make sense. What doesn't make sense is why moving
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change
On 07/08/2012 02:52 PM, Oleksij Rempel (fishor) wrote:
Hi, can you please do one more test.
Try to reproduce it with MJPEG stream. Use this command:
luvcview -f jpg -C
it will force jpeg (i think your cam support it) and store each frame
separately. If you can reproduce it, please send me
On Sunday, July 08, 2012, Alan Stern wrote:
On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:
Well, the quirk does make sense. What doesn't make sense is why moving
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change in the autosuspend behavior.
On Sun, 8 Jul 2012, Eric Ding wrote:
I think the reason was the way rpm_suspend() worked at the time of that
commit (it works a bit differently now, but not as much as to avoid the
problem).
Namely, before commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2 the device
had a device type
On 08.07.2012 17:18, Alan Stern wrote:
On Sun, 8 Jul 2012, Eric Ding wrote:
I think the reason was the way rpm_suspend() worked at the time of that
commit (it works a bit differently now, but not as much as to avoid the
problem).
Namely, before commit
On Sunday 08 July 2012 17:34:08 Oleksij Rempel wrote:
On 08.07.2012 17:18, Alan Stern wrote:
On Sun, 8 Jul 2012, Eric Ding wrote:
I think the reason was the way rpm_suspend() worked at the time of that
commit (it works a bit differently now, but not as much as to avoid the
problem).
Hi Alan,
On Friday 06 July 2012 11:47:01 Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes, but we still need to know the reason why. Neither Rafael nor I
has been able to figure out why that commit messed things up.
Was the driver doing any dynamic autosuspend at all until
On 07/09/2012 08:38 AM, Alan Stern wrote:
On Sun, 8 Jul 2012, Laurent Pinchart wrote:
this quirks also affect snd_usb_audio module. If for some reasons
uvcvideo is not loaded, snd_usb_audio will fail - i mean haw mysterious
sound problems.
Good point. If we load the uvcvideo driver while
On 07.07.2012 11:20, Eric Ding wrote:
On 07/06/2012 11:47 PM, Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes, but we still need to know the reason why. Neither Rafael nor I
has been able to figure out why that commit messed things up.
Was the driver doing any dynamic
On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
On 07.07.2012 11:20, Eric Ding wrote:
On 07/06/2012 11:47 PM, Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes, but we still need to know the reason why. Neither Rafael nor I
has been able to figure out why that commit messed things
On 07.07.2012 13:38, Eric Ding wrote:
On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
On 07.07.2012 11:20, Eric Ding wrote:
On 07/06/2012 11:47 PM, Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes, but we still need to know the reason why. Neither Rafael nor I
has been able to
On 07.07.2012 15:55, Eric Ding wrote:
On 07/07/2012 09:11 PM, Oleksij Rempel wrote:
On 07.07.2012 13:38, Eric Ding wrote:
On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
On 07.07.2012 11:20, Eric Ding wrote:
On 07/06/2012 11:47 PM, Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes,
On Saturday, July 07, 2012, Alan Stern wrote:
On Sat, 7 Jul 2012, Oleksij Rempel wrote:
Ok, i guess i know your problem but i doubt it will be completely fixed
by changing powermanagement behavior. Two logitech cams i tested is
really easy to confuse/brake/freeze. Just turn off the
On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:
Well, the quirk does make sense. What doesn't make sense is why moving
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change in the autosuspend behavior. That's what we
would like to know.
I think
On 07/08/2012 09:52 AM, Alan Stern wrote:
On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:
Well, the quirk does make sense. What doesn't make sense is why moving
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change in the autosuspend behavior. That's
On 07/08/2012 03:18 AM, Alan Stern wrote:
Apparently the behavior before commit e1620d5 was that the webcam
didn't get suspended, and after the commit it did. Unfortunately
the usbmon traces do not explain this difference; all they show is
when/whether a suspend took place.
For example,
On Fri, 6 Jul 2012 10:37:30 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 6 Jul 2012, Laurent Pinchart wrote:
Hi Alan,
On Friday 06 July 2012 09:50:30 Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
From: Eric Ding ericd...@alum.mit.edu
working if
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes, but we still need to know the reason why. Neither Rafael nor I
has been able to figure out why that commit messed things up.
Was the driver doing any dynamic autosuspend at all until that point ?
I don't know... but whatever it was doing before
23 matches
Mail list logo
