BTW: now that the patch has been submitted, will appropriate updates
also be made to the corresponding issue in bugzilla?
https://bugzilla.kernel.org/show_bug.cgi?id=44191
There's also an Ubuntu launchpad bug tied to this kernel bug report.
The original patch already fell by the wayside,
On 07/18/2012 09:13 AM, Laurent Pinchart wrote:
> On Wednesday 18 July 2012 08:09:27 Eric Ding wrote:
>> On 07/17/2012 10:47 PM, Alan Stern wrote:
>>> On Tue, 17 Jul 2012, Laurent Pinchart wrote:
>>>> Alan, what do you think about this approach ? I'm not sure
On 07/17/2012 10:47 PM, Alan Stern wrote:
> On Tue, 17 Jul 2012, Laurent Pinchart wrote:
>> Alan, what do you think about this approach ? I'm not sure whether we need to
>> include the early UVC models that advertise a vendor-specific class in the
>> list.
> The general approach is okay. The deta
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
On 07/12/2012 04:21 PM, Oleksij Rempel 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
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 y
On 07/09/2012 09:10 AM, 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 referenc
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
Hi Alan,
On 07/09/2012 05:23 AM, Laurent Pinchart wrote:
> On Sunday 08 July 2012 11:18:35 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
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 sen
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 examp
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
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, Al
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
14 matches
Mail list logo
