Should the mode be set to blocking by default and can be changed to non-blocking via message?
I'm still not sure what the difference is, pros and cons between both modes.
What do you think Johannes?
.b.
Hans-Christoph Steiner wrote:
Anyway to make this work in a generic way, so it can be included in builds that support a wide array of hardware?
.hc
On Sep 18, 2008, at 11:47 PM, B. Bogart wrote:
Opening the device in blocking mode (removing O_NONBLOCK flag) solves these issues.
I'm sending this so that future cx88xx people can fix it:
- Remove the O_NONBLOCK flag from videoV4L2.cpp
- make sure your using V4L2 (V4L)
- make sure you set pix_video to YUV colour: "colorspace YUV" (RGB does
not seem to work on my card.)
Then it should work as well as the ol bt8x8 cards.
.b.
B. Bogart wrote:
I have made progress.
I've managed to get my card working in Gem with some minor changes to the code. I'm not sure what this code does though, so I'm not sure what the longer term effect will be.
I'm sending this to the v4l list as you all are the best to advice on a proper solution to this issue.
I've attached the original, and the hacked version.
Basically the hacked version ignores all errors when running the following command:
xioctl (m_tvfd, VIDIOC_DQBUF, &buf)
What does this command actually do? Why are there two instances in the capture function?
I can use the card at 640x480.
The result is the frame-rate is horrid compared to mplayer (which I suppose makes sense based on those removed error reports) and also using the V4L1 w/ a bt8x8 card.
Does this change give a hint as to what is causing the problem?
What is the proper way to fix the issue, rather than commenting out error codes?
Thanks all, B. Bogart
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Access to computers should be unlimited and total. - the hacker ethic