v4l1 compat wrapper version 0.3

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

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hi Hans,

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

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

#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;
}

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hi Hans,

Thanks for the test software.

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.

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

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."

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

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

No messages I'm afraid.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hi Hans,

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.

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.

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

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

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

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

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hi Hans,

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

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

That's right.

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list