Hi Bruce,
On Wednesday 20 May 2009 05:29:27 bruce m beach wrote:
> Hello Laurent
>
> > > ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument
> > > why is the ioctl call failing?
> >
> > Because VIDIOC_S_STD isn't supported by webcam drivers (that ioctl only
> > makes sense for analog video). xawtv should be able to cope with that.
> > You might want to upgrade it.
>
> I have xawtv-3.95 which is the latest stable release.
The latest stable release is buggy :-)
> > > and why does it keep telling me
> > > no way to get: 384x288 16 bit TrueColor (LE)
> > > no way to get: 2048x1572 32 bit TrueColor (BE: rgb)
> >
> > Is that related to the webcam or to the display ?
>
> This I don't know. Xorg.0.log gives me
>
> (==) RADEON(0): Depth 24, (==) framebuffer bpp 32
> (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
> (==) RADEON(0): Default visual is TrueColor
> (**) RADEON(0): Option "DRI"
>
> so the message may be a side effect of something else especially if
> it doesn't ring a bell for you. I think xawtv may not be working at all
> since the webcam green light doesn't come on whereas with luvcview it
> does. At this point I'm not going to bother with it.
Ok.
> > > Anyway any ideas as to how to proceed are appreciated.
> >
> > Use luvcview for testing. If luvcview doesn't work xawtv will not work
> > either.
>
> Okay. Here's what I have done to the code in luvcview, (luvcview-20070512)
> since it looks like it might take a long time to get this going.
>
> 1) added -g to the CFLAGS to add debugging support for gdb if it ever
> gets to that level.
> 2) set static int debug = 1; in v4l2uvc.c to get whatever error
> messages it has.
> 3) For starts added a perror message at the beginning of every function
> call like below:
>
> int check_videoIn(struct vdIn *vd, char *device)
> {
> int ret;
> perror("START init_v4l2");
>
> Later on if needed I could add some kind of switch to turn them on
> and off. This has tracked down the a problem with terminating the
> program. Currently only kill -9 will work. Have a look at the following
> output notice the last entry:
>
> ... ... ...
> ... ... ...
> START dec_rec2: Success
> START idct: Success
> START idct: Success
> START idct: Success
> START idct: Success
> START idct: Success
> START idct: Success
> START yuv420pto422: Success
> START dec_readmarker: Success
> START eventThread: Success
> START uvcGrab: Success
> START video_enable: Success
> uvcGrab: memset(&vd->buf, 0, sizeof(struct v4l2_buffer));: Success
> uvcGrab: vd->buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;));: Success
> uvcGrab: vd->buf.memory = V4L2_MEMORY_MMAP;: Success
> uvcGrab: ret=ioctl(vd->fd, VIDIOC_DQBUF, &vd->buf); (BEFORE THE CALL):
> Success uvcGrab: ret = ioctl(vd->fd, VIDIOC_DQBUF, &vd->buf (AFTER THE
> CALL);: Success uvcGrab just before Capture a single raw frame: Success
> V4L2_PIX_FMT_MJPEG: Success
> START jpeg_decode: Success
> bytes in used 77389
> END uvcGrab normal: Success
> START uvcGrab: Success
> uvcGrab: memset(&vd->buf, 0, sizeof(struct v4l2_buffer));: Success
> uvcGrab: vd->buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;));: Success
> uvcGrab: vd->buf.memory = V4L2_MEMORY_MMAP;: Success
> uvcGrab: ret=ioctl(vd->fd, VIDIOC_DQBUF, &vd->buf); (BEFORE THE CALL):
> Success
> ^^^^^^ ^^^ ^^^^
> The program does all its initializations printing
> out lots of stuff (which I don't show here) and eventually arrives at
> uvcGrab (Which I assume is the routine entered at the frame rate to get the
> camera data by whatever method). The call is completed once, some other
> stuff is executed, it is entered again, calls
>
> ret=ioctl(vd->fd, VIDIOC_DQBUF, &vd->buf)
>
> and never returns. (notice the message (BEFORE THE CALL). It stays
> in the call until kill -9 luvcview(PID) is executed.
>
> "ps x" gives:
>
> 2592 pts/3 Sl+ 0:00 luvcview
>
> indicating interruptible sleep (waiting for an event to complete) and
> multi threaded. On question is why doesn't it time out?
The V4L2 specification doesn't specify if and when VIDIOC_DQBUF should
timeout. Why would you like it to timeout ?
> I have another webcam (0c45:6009 Microdia VideoCAM ExpressII) that uses
> "modprobe sn9c102" to work. If I run it with luvcview it is only gives
> a green screen but the uvcGrab looping works and it terminates normally.
> I have another program (sn-webcam) where the ExpressII works okay.
That's a completely different driver, and I'm not familiar with it, sorry.
> By the way doing "make" on luvcview gives a lot of redefinitions like:
>
> uvcvideo.h:31:1: warning: "V4L2_CID_WHITE_BALANCE_TEMPERATURE" redefined
>
> I assume this is intentional. Anyway looking forward to you comments.
I assume you get those warnings with the deprecated SVN version. Don't use it,
it's really deprecated.
The reason why VIDIOC_DQBUF fails to return is probably that the driver
doesn't get enough data from the camera to fill a frame (or that it believes
it doesn't). Could you set the trace level to 255, run luvcview for a few
seconds, kill it (ctrl-\ should do the job) and send me the messages printed
by the uvcvideo driver to the kernel log ?
Best regards,
Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
