Re: [Linux-uvc-devel] again "Logitech QuickCam Pro for Notebooks 046d:0991"

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 10/26/2009 12:52 PM, Alexey Fisher wrote:
> Am Sonntag, den 25.10.2009, 14:21 +0100 schrieb Hans de Goede:
>> Hi,
>>
>> On 10/25/2009 02:02 PM, Alexey Fisher wrote:
>>> Am Sonntag, den 25.10.2009, 13:17 +0100 schrieb Hans de Goede:
>>>> Hi,
>>>>
>>>> On 10/22/2009 09:40 AM, Alexey Fisher wrote:
>>>>> Hi Laurent,
>>>>> thank you for the answer, i thought - no body care. :)
>>>>>
>>>>> Am Donnerstag, den 22.10.2009, 01:55 +0200 schrieb Laurent Pinchart:
>>>>>> Hi Alexey,
>>>>>>
>>>>>> On Thursday 15 October 2009 21:00:59 Alexey Fisher wrote:
>>>>>>> I did some simple dirty hack, it prevent webcam from being killed by cheese.
>>>>>>> On other site it make cheese work too.
>>>>>>> Like Paulo said,  the camera is slow and it need more time to make thirst
>>>>>>> start, some time it need 8 seconds on second start it need about 2 seconds.
>>>>>>> If we call STREAMOFF before we get EOF, the camera will die.
>>>>>>
>>>>>> Which EOF are you talking about here ? The UVC bit in the video packets header
>>>>>> ? How have you tested that ?
>>>>>
>>>>> I used "uvcvideo trace=255" and cheese.
>>>>> I talking about "uvc_v4l2_ioctl(VIDIOC_STREAMON)", "Frame complete (EOF
>>>>> found)" and "uvc_v4l2_ioctl(VIDIOC_STREAMOFF)".
>>>>>
>>>>>>> IMHO, the driver should decide if camera ready or not. The easiest way
>>>>>>> is, to add SLOWSTART quirk. Correct way probobly will be to check if camera
>>>>>>> ready or not.
>>>>>>> Any ideas how to make it? Or any other ideas?
>>>>>>>
>>>>>>> I know, cheese use some bruteforce way to get settings, but the bug in
>>>>>>> cheese make the bug in uvcvideo easy to reproduce.
>>>>>>
>>>>>> It's not a bug in uvcvideo but a bug in the camera. Have you been to isolate
>>>>>> exactly which sequence of ioctls issued by Cheese make the camera crash ? I'd
>>>>>> like more information about that.
>>>>>
>>>>> I made dmesg of two situations, webcam work and don't work.
>>>>> cheese celling two times "uvc_v4l2_ioctl(VIDIOC_STREAMON)", thirst one
>>>>> to get the settings and second time to start the record. Between thirst
>>>>> and second pass the time out seems to be too short (even it is 10
>>>>> seconds).
>>>>>
>>>>
>>>> This is not an issue with the camera, nor with the driver, but an issue with
>>>> cheese. In order to not wait for ever when probing devices which for some
>>>> reason won't stream, cheese wait a maximum of 3 seconds before the stream to
>>>> start, so if the camera is this slow to start, then cheese will most likely
>>>> have given up before the cam has started.
>>>
>>> <sarcastic>   Really good and helpful response</sarcastic>
>>>
>>> so what, let say you have a network adapter driver for it and firefox...
>>> firefox asked for dns three time and these accidently erased eeprom of
>>> network adapter. So the developer of driver for this network adapter
>>> will claim the firefox is bad and not driver which enabled write access
>>> to eeprom.
>>> This example is a bit surrealistic (except e1000e), but this is exact
>>> point to your answer.
>>> I ready seid, this is not about cheese, empathy has same issue. So what?
>>> let us make in every application timeout for 20 seconds? How will you
>>> fix in on user space?
>>> If it will be like - cheese do not work but camera will work after it, i
>>> didn't had any problem, but in this case cheese kill the webcam and
>>> driver made it possible.
>>>
>>> This bug is more then one year old, and users who reported it are kicked
>>> all the time between developers with words: "my app is clean" or "this
>>> is not about the driver". If you can't communicate with each other, what
>>> is about us, users? Who can solve this problem?
>>>
>>
>> Sorry,
>>
>> I was trying to be helpful here, and your input as user is appreciated.
>>
>> fwiw I'm a v4l kernel developer, but I'm not involved in the UVC driver,
>> I'm however a contributor to cheese, I thought that my input that cheese
>> would give up even if the driver has a long enough timeout would be helpful.
>>
>> To try and see if this (the cheese timeout is the issue), you will need
>> to re-compile cheese from source, after unpacking cheese, edit
>> src/cheese-webcam.c and goto line 716 (in 2.28.0)
>>
>> And change the "10 * GST_SECOND" there in something bigger. I also see that
>> I'm mistaken and the timeout in cheese is not 3 but 10 seconds, it might
>> have changed recently, or my memory has been playing tricks on me.
>>
>> I still believe this might be the cause, the trace you have posted seems
>> consistent with cheese's behaviour. Also noticed that there never is a
>> successfull DQBUF the first time cheese opens the device. If cheese
>> (or rather gstreamer) does not manage to DQBUF the first time, then cheese
>> will not work with the device. There is a limitation in gstreamer
>> (or maybe in the way cheese uses it) where gstreamer needs to be streaming
>> before cheese can tell the properties of the cam. If the stream does not
>> start within the first 10 seconds, then cheese will fail to get the properties.
>>
>> If you go to cheese's edit ->  preferences menu, and your cam has no resolutions
>> listed there (the resolution drop down is grayed out). This is what is happening.
>>
>> As for empathy, I'm not familiar with that. But if we can get cheese to work
>> first I'm sure that that would be a good step in the right direction.
>>
>> Regards,
>
> Hallo Hans,
> thank you for your constructive response,
> I increased timeout to 15 seconds i now i can't reproduce camera freeze,
> i'll play with it more to be sure. There is still one issue with it - on
> cold start the image is zoomed in.
> I need to close cheese and open it again to get normal zoom. The
> resolution seems to be the same.
>

That definitely sounds like a camera bug, but maybe we can do something
on the driver side (like forcing a resolution change even if not necessary)
to work around this. Laurent ?

Note re-adding the mailing list and Laurent to the CC, they somehow got
dropped.

Regards,

Hans