v4l1 doesn't work anymore with bttv on 2.6.26
Hi,
This is a copy of the bugreport i did on debian bugtracker : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510621
I got a v4l1 application that worked for years.
With the current kernel, it hangs in a state where VIDIOCMCAPTURE always return -EBUSY.
After some debug, it seems that VIDIOCMCAPTURE fails the first time because of videobuf_queue_is_busy 'vbuf: busy: buffer #0 mapped'.
Then after that error it does a VIDIOCSYNC on all buffer. Then every call of VIDIOCMCAPTURE failed because of check_btres returning -EBUSY.
I don't know what cause the first videobuf_queue_is_busy error. But for all the other errors I suppose one of the problem is that VIDIOCSYNC does a STREAMON but never does a STREAMOFF...
Regards,
Matthieu
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 9 lines · matthieu castet
This is a copy of the bugreport i did on debian bugtracker :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510621I got a v4l1 application that worked for years.
With the current kernel, it hangs in a state where VIDIOCMCAPTURE always return-EBUSY.After some debug, it seems that VIDIOCMCAPTURE fails the first time because of
videobuf_queue_is_busy'vbuf: busy: buffer #0 mapped'.
Around that time frame the bttv driver was converted from having native v4l1 support to using the v4l1->v4l2 compat module. The bttv driver supported a non-standard v4l1 buffer allocation method were there buffers get allocated or resized in the MCAPTURE ioctl and the v4l1 compat module doesn't support this. I bet this is what your problem is.
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list