Tom Zoerner <tomzo@xxxxxxxxxx> writes:
> Gerd Knorr replied:
> >> VBI device readable in select() and returns EIO for ioctl DQBUF
> >> (...) does de-queue a buffer although it returns an error code.
>
> > Its done intentionally.
>
> If I understand you correctly you want to provide the buffer because
> the data might be useful to the app - but how?
No. I just don't want to block forever in the driver in case of
trouble. If a IRQ doesn't arrive within half a second it is unlikely
that it will arrive anytime soon. Capturing a frame usually takes
*much* less time that 500ms, if that doesn't work out something is
seriously wrong. No signal is one possible reason. Might also be a
hardware issue (broken chipset) or BIOS issue (trying to do IRQ
routing via ACPI causes intresting effects sometimes ...).
> I mean, we don't know
> what data is actually in the buffer, i.e. there might be no new data
> in the buffer at all, or a partial frame and the rest data from 10
> frames ago, or something else entirely.
Yes, and because of that I want to pass that info ("sorry, didn't
worked this time") to the application somehow.
> > Maybe better use something like V4L2_BUF_FLAG_IOERROR instead?
>
> Most intuitive to me would be to not set the DONE flag and set an
> IOERROR flag instead.
I'd set both flags. "DONE" says the driver is done with the buffer
and will not touch it until requeued, and that's true for these
buffers too.
Gerd
--
sigfault
