v4l1 compat wrapper version 0.3

v4l1 compat wrapper version 0.3

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

Hi All,

Ok, this one _really_ works with ekiga (and still works fine with spcaview) and 
also works with camorama with selected cams (not working on some cams due to a 
camorama bug).

Changes:
* Don't allow multiple opens, in theory our code can handle it, but not all
   v4l2 devices like it (ekiga does it and uvc doesn't like it).

New version attached.

Regards,

Hans



[-- Attachment #2: v4l1-compat-0.3.tar.gz --]
[-- Type: application/x-gzip, Size: 30612 bytes --]

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l1 compat wrapper version 0.3

[Laurent Pinchart]

Hi Hans,

On Friday 06 June 2008 15:00, Hans de Goede wrote:
> Hi All,
> 
> Ok, this one _really_ works with ekiga (and still works fine with spcaview)
> and also works with camorama with selected cams (not working on some cams
> due to a camorama bug).
> 
> Changes:
> * Don't allow multiple opens, in theory our code can handle it, but not all
>    v4l2 devices like it (ekiga does it and uvc doesn't like it).

Could you please elaborate ? Have you noticed a bug in the UVC driver ? It 
should support multiple opens.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

uvc open/close race (Was Re: v4l1 compat wrapper version 0.3)

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

Laurent Pinchart wrote:
> Hi Hans,
> 
> On Friday 06 June 2008 15:00, Hans de Goede wrote:
>> Hi All,
>>
>> Ok, this one _really_ works with ekiga (and still works fine with spcaview)
>> and also works with camorama with selected cams (not working on some cams
>> due to a camorama bug).
>>
>> Changes:
>> * Don't allow multiple opens, in theory our code can handle it, but not all
>>    v4l2 devices like it (ekiga does it and uvc doesn't like it).
> 
> Could you please elaborate ? Have you noticed a bug in the UVC driver ? It 
> should support multiple opens.

A good question, which I kinda knew I had coming. So now it has been asked I've 
spend some time tracking this down. There seems to be an open/close race 
somewhere in the UVC driver, ekiga does many open/close cycles in quick 
succession during probing.

It seems my no multiple opens code slows it down just enough to stop the race, 
but indeed multiple opens does not seem to be the real problem.

I've attached a program which reproduces it. I've commented out the fork as 
that does not seem necessary to reproduce this, just very quickly doing
open/some-io/close, open/some-io/close seems to be enough to trigger this, here 
is the output on my machine:

[hans@localhost v4l1-compat-0.4]$ ./test
[hans@localhost v4l1-compat-0.4]$ ./test
[hans@localhost v4l1-compat-0.4]$ ./test
[hans@localhost v4l1-compat-0.4]$ ./test
TRY_FMT 2: Input/output error
[hans@localhost v4l1-compat-0.4]$ ./test
TRY_FMT 1: Input/output error
[hans@localhost v4l1-compat-0.4]$ ./test
TRY_FMT 1: Input/output error
[hans@localhost v4l1-compat-0.4]$ ./test
TRY_FMT 1: Input/output error
[hans@localhost v4l1-compat-0.4]$

Notice how after the first time it gets the I/O error, it never recovers and 
from now on every first TRY_FMT fails.

Some notes:
1) TRY_FMT should really never do I/O (but then I guess the
    problem would still persists with S_FMT)
2) I've also seen it fail at TRY_FMT 1 without first failing
    a TRY_FMT 2, I guess that was just me doing arrow-up -> enter to quickly :)

Regards,

Hans

[-- Attachment #2: test.c --]
[-- Type: text/plain, Size: 1256 bytes --]

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <syscall.h>
#include <sys/ioctl.h>
#include <linux/videodev2.h>

int main(void)
{
  int fd;
  pid_t pid;
  struct v4l2_format fmt2 = { .type = V4L2_BUF_TYPE_VIDEO_CAPTURE };
  
  fd = open("/dev/video0", O_RDONLY);
  if (fd == -1) {
    perror("open 1");
    return 1;
  }

  if (syscall(SYS_ioctl, fd, VIDIOC_G_FMT, &fmt2)) {
    perror("G_FMT 1");
    return 1;
  }
      
  if (syscall(SYS_ioctl, fd, VIDIOC_TRY_FMT, &fmt2)) {
    perror("TRY_FMT 1");
    return 1;
  }

  if (syscall(SYS_ioctl, fd, VIDIOC_S_FMT, &fmt2)) {
    perror("S_FMT 1");
    return 1;
  }

/*  pid = fork();
  if (pid == -1) {
    perror("fork");
    return 1;
  }
  
  if (!pid) {
    close(fd);
  } else */ {
    close(fd);
    fd = open("/dev/video0", O_RDONLY);
    if (fd == -1) {
      perror("open 2");
      return 1;
    }

    if (syscall(SYS_ioctl, fd, VIDIOC_G_FMT, &fmt2)) {
      perror("G_FMT 2");
      return 1;
    }
        
    if (syscall(SYS_ioctl, fd, VIDIOC_TRY_FMT, &fmt2)) {
      perror("TRY_FMT 2");
      return 1;
    }

    if (syscall(SYS_ioctl, fd, VIDIOC_S_FMT, &fmt2)) {
      perror("S_FMT 2");
      return 1;
    }
  }
  return 0;
}

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: uvc open/close race (Was Re: v4l1 compat wrapper version 0.3)

[Laurent Pinchart]

Hi Hans,

On Friday 06 June 2008, Hans de Goede wrote:
> Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Friday 06 June 2008 15:00, Hans de Goede wrote:
> >> Hi All,
> >>
> >> Ok, this one _really_ works with ekiga (and still works fine with
> >> spcaview) and also works with camorama with selected cams (not working
> >> on some cams due to a camorama bug).
> >>
> >> Changes:
> >> * Don't allow multiple opens, in theory our code can handle it, but not
> >> all v4l2 devices like it (ekiga does it and uvc doesn't like it).
> >
> > Could you please elaborate ? Have you noticed a bug in the UVC driver ?
> > It should support multiple opens.
>
> A good question, which I kinda knew I had coming. So now it has been asked
> I've spend some time tracking this down. There seems to be an open/close
> race somewhere in the UVC driver, ekiga does many open/close cycles in
> quick succession during probing.
>
> It seems my no multiple opens code slows it down just enough to stop the
> race, but indeed multiple opens does not seem to be the real problem.
>
> I've attached a program which reproduces it.

Thanks for the test software.

> I've commented out the fork as 
> that does not seem necessary to reproduce this, just very quickly doing
> open/some-io/close, open/some-io/close seems to be enough to trigger this,
> here is the output on my machine:
>
> [hans@localhost v4l1-compat-0.4]$ ./test
> [hans@localhost v4l1-compat-0.4]$ ./test
> [hans@localhost v4l1-compat-0.4]$ ./test
> [hans@localhost v4l1-compat-0.4]$ ./test
> TRY_FMT 2: Input/output error
> [hans@localhost v4l1-compat-0.4]$ ./test
> TRY_FMT 1: Input/output error
> [hans@localhost v4l1-compat-0.4]$ ./test
> TRY_FMT 1: Input/output error
> [hans@localhost v4l1-compat-0.4]$ ./test
> TRY_FMT 1: Input/output error
> [hans@localhost v4l1-compat-0.4]$
>
> Notice how after the first time it gets the I/O error, it never recovers
> and from now on every first TRY_FMT fails.
>
> Some notes:
> 1) TRY_FMT should really never do I/O (but then I guess the
>     problem would still persists with S_FMT)

Why not ? The UVC specification defines probe requests to negotiate the 
streaming format. Unlike for most other devices, the UVC model requires I/O 
in TRY_FMT.

> 2) I've also seen it fail at TRY_FMT 1 without first failing
>     a TRY_FMT 2, I guess that was just me doing arrow-up -> enter to
> quickly :)

Could you please tell me what webcam you used, as well as what kernel version 
you are running ? I would also appreciate if you could check the kernel log 
for error messages after triggering the problem.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: uvc open/close race (Was Re: v4l1 compat wrapper version 0.3)

[Hans de Goede]

Laurent Pinchart wrote:
> Hi Hans,
> 
>> Some notes:
>> 1) TRY_FMT should really never do I/O (but then I guess the
>>     problem would still persists with S_FMT)
> 
> Why not ? The UVC specification defines probe requests to negotiate the 
> streaming format. Unlike for most other devices, the UVC model requires I/O 
> in TRY_FMT.
> 

I would expect the driver to ask the camera what format it supports once, at 
probe and then cache that info, many applications do a lot of TRY_FMT calls in 
quick succession, so doing the querying then and each time seems like a bad 
idea to me. Esp as, as seen in my example try_fmt can now throw IO/errors 
whichs is somewhat strange IMHO.

Quoting from:
http://lwn.net/Articles/227533/

"The VIDIOC_TRY_FMT handlers are optional for drivers, but omitting this 
functionality is not recommended. If provided, this function is callable at any 
time, even if the device is currently operating. It should not make any changes 
to the actual hardware operating parameters; it is just a way for the 
application to find out what is possible."

>> 2) I've also seen it fail at TRY_FMT 1 without first failing
>>     a TRY_FMT 2, I guess that was just me doing arrow-up -> enter to
>> quickly :)
> 
> Could you please tell me what webcam you used, as well as what kernel version 
> you are running ?

I'm using a Logitech sphere usb id: 046d:08cc

Fedora kernel: kernel-2.6.25-8.fc9, which includes UVC (added by Fedora).

> I would also appreciate if you could check the kernel log 
> for error messages after triggering the problem.

No messages I'm afraid.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: uvc open/close race (Was Re: v4l1 compat wrapper version 0.3)

[Laurent Pinchart]

Hi Hans,

On Saturday 07 June 2008, Hans de Goede wrote:
> Laurent Pinchart wrote:
> > Hi Hans,
> >
> >> Some notes:
> >> 1) TRY_FMT should really never do I/O (but then I guess the
> >>     problem would still persists with S_FMT)
> >
> > Why not ? The UVC specification defines probe requests to negotiate the
> > streaming format. Unlike for most other devices, the UVC model requires
> > I/O in TRY_FMT.
>
> I would expect the driver to ask the camera what format it supports once,
> at probe and then cache that info,

The driver reads the list of supported frame formats, frames sizes and frame 
rates at initialisation time and caches the information. Calls to 
VIDIOC_ENUM_FRAMEFORMATS and VIDIOC_ENUM_FRAMESIZES do not result in any 
request to the device.

The UVC specification defines a protocol to negotiate the format with the 
camera. This is really a collaborative process. The drivers requests a set of 
streaming parameters, and the camera responds with possibly modified values 
depending on its capabilities.

> many applications do a lot of TRY_FMT calls in quick succession, so doing
> the querying then and each time seems like a bad idea to me.

Applications shouldn't. If they want to list the supported formats and sizes 
they should use VIDIOC_ENUM_FRAMEFORMATS and VIDIOC_ENUM_FRAMESIZES instead 
of VIDIOC_TRY_FMT.

> Esp as, as seen in my example try_fmt can now throw IO/errors whichs is
> somewhat strange IMHO. 
>
> Quoting from:
> http://lwn.net/Articles/227533/
>
> "The VIDIOC_TRY_FMT handlers are optional for drivers, but omitting this
> functionality is not recommended. If provided, this function is callable at
> any time, even if the device is currently operating. It should not make any
> changes to the actual hardware operating parameters; it is just a way for
> the application to find out what is possible."

The negotiation process doesn't change any hardware parameter. It just probes 
the device without committing any change.

> >> 2) I've also seen it fail at TRY_FMT 1 without first failing
> >>     a TRY_FMT 2, I guess that was just me doing arrow-up -> enter to
> >> quickly :)
> >
> > Could you please tell me what webcam you used, as well as what kernel
> > version you are running ?
>
> I'm using a Logitech sphere usb id: 046d:08cc
>
> Fedora kernel: kernel-2.6.25-8.fc9, which includes UVC (added by Fedora).

That's a very buggy webcam. It has nasty firmware issues. See 
http://www.quickcamteam.net/documentation/faq/logitech-webcam-linux-usb-incompatibilities

> > I would also appreciate if you could check the kernel log
> > for error messages after triggering the problem.
>
> No messages I'm afraid.

Now that's weird. The only error path that can return -EIO print a message to 
the kernel log. Could you please double check ?

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: uvc open/close race (Was Re: v4l1 compat wrapper version 0.3)

[Hans de Goede]

Laurent Pinchart wrote:
>> I'm using a Logitech sphere usb id: 046d:08cc
>>
>> Fedora kernel: kernel-2.6.25-8.fc9, which includes UVC (added by Fedora).
> 
> That's a very buggy webcam. It has nasty firmware issues. See 
> http://www.quickcamteam.net/documentation/faq/logitech-webcam-linux-usb-incompatibilities
> 

Ah, I already feared that much, so its not MS's fault it doesn't work out of 
the box with vista then :)

>>> I would also appreciate if you could check the kernel log
>>> for error messages after triggering the problem.
>> No messages I'm afraid.
> 
> Now that's weird. The only error path that can return -EIO print a message to 
> the kernel log. Could you please double check ?
> 

Done,

There are some messages like this one:
uvcvideo: Failed to query (135) UVC control 7 (unit 2) : -75 (exp. 2).

(Also with different numbers) but those seemed harmless to me, as I interpreted 
them as could not get brightness / contrast / hue / etc. But maybe I 
misinterpreted them, sorry I should have reported them the first time.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: uvc open/close race (Was Re: v4l1 compat wrapper version 0.3)

[Laurent Pinchart]

Hi Hans,

sorry for the late reply. I got somehow side-tracked.

On Monday 09 June 2008, Hans de Goede wrote:
> Laurent Pinchart wrote:
> >> I'm using a Logitech sphere usb id: 046d:08cc
> >>
> >> Fedora kernel: kernel-2.6.25-8.fc9, which includes UVC (added by
> >> Fedora).
> >
> > That's a very buggy webcam. It has nasty firmware issues. See
> > http://www.quickcamteam.net/documentation/faq/logitech-webcam-linux-usb-i
> >ncompatibilities
>
> Ah, I already feared that much, so its not MS's fault it doesn't work out
> of the box with vista then :)
>
> >>> I would also appreciate if you could check the kernel log
> >>> for error messages after triggering the problem.
> >>
> >> No messages I'm afraid.
> >
> > Now that's weird. The only error path that can return -EIO print a
> > message to the kernel log. Could you please double check ?
>
> Done,
>
> There are some messages like this one:
> uvcvideo: Failed to query (135) UVC control 7 (unit 2) : -75 (exp. 2).

I'm afraid this is most probably caused by firmware bugs in the webcam. The 
driver can't do much about it.

> (Also with different numbers) but those seemed harmless to me, as I
> interpreted them as could not get brightness / contrast / hue / etc.

That's right.

> But maybe I misinterpreted them, sorry I should have reported them the first
> time.

No worries.

While I don't completely the possibility of having race conditions in the UVC 
driver (no piece of software is ever perfect), the problems you have 
encountered are caused by webcam firmware issues.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list