Hi Sebastian,
On Mar 9, 2007, at 8:43 AM, Sebastian Hartman wrote:
> I'm getting "no queues buffered" constantly when
> trying to select() from the file descriptor with the
> zoran drivers in Linux 2.6.18.
So let's start with the obvious: did you queue a buffer? Please offer
some source code.
(It's perfectly possible that select() isn't fully compliant, there
was no app using this when I wrote the code, so I had to write my own
testing code, which may not be what other apps do. It worked for my
test code.)
> I looked into the
> source code and found that fh->v4l_buffers doesn't
> match fh->zr->v4l_buffers when the zoran_poll() call
> is being made. Another thing is that zoran_irq()
> increases the pend_tail index, so when zoran_poll()
> checks whether fh->v4l_buffers[pend_tail &
> ...].state == BUZ_STATE_DONE it's false (but when
> checking against fh->zr->v4l_bu.... and subtracting
> the index with one it's true.
>
> Is this a known bug? Additionally I saw you're
> referencing structures to each other (I assume that
> fh->zr->v4l_buffers should be exactly the same as
> fh->v4l_buffers). Example:
>
> struct monkey { char area[256]; };
> struct monkey baboon;
> struct monkey chimpansee = baboon;
> strcpy(baboon.area, "Rainforest");
>
> Now, baboon.area != chimpansee.area.
>
> You should use a pointer for this occation.
Yes, but no. V4l2 requires us to have a per-filehandle buffer
management, so it needs to be in the fh-> struct. The IRQ handler
has no access to this, so we need a pointer/copy in zr->. The danger
here is that an IRQ handler cannot keep mutexes, which means that I
may be unsetting it in another thread at the very time when I try to
write to it in my IRQ handler -> system down. The most practical
solution to this is to keep a copy and have sync threads copy it when
it matches, which is what zoran_driver.c does in line 942 of v4l_sync
(). That is all 100% intentional, and I hope this makes it clear why
we don't use a pointer. you will notice that prior to line 942,
v4l_sync() only looks at zr-> before making sure that it is our
capture session and not that of another file handle. So capturing
obviously works as expected.
Now, let's look at select(), or rather zoran_poll(). The raw capture
mode case first checks that our file handle queued buffers and if so,
it looks at the zr-> structures. This all looks fine to me, so it
looks like a bug in your code if you trigger that. What makes me
wonder is line 4319-20, where we re-reference fh->v4l_buffers without
copying it like in 942 of v4l_sync(), which looks kind of odd to me.
It looks like we _should_ copy it and then check state and return the
proper return value. You may want to check that and I'd take such a
patch. However, first and foremost, it looks like you're not actually
queueing buffers properly, as Laurent suggested. (The same is true
for JPG capture as well, so he same patch there makes sense also.)
Ronald
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
