Chris Bagwell wrote:
> Steve,
>
> Here is a more specific question I have for you regarding a code change
> I made to RGBRouter_remaining(). The original functions logic works out
> to the following (this version is closer to what Lawernce posted).
>
> if (ps->cb_start < 0)
> remaining = (TxSource_remaining(pself) - ps->cb_size +
> ps->cb_line_size);
> else
> remaining = (TxSource_remaining(pself) + ps->cb_line_size -
> ps->pos);
>
> return (remaining);
>
> As far as I can tell, cb_start can only be < 0 at two or three times:
> 1) When you start a fake scan to get transfer speed, 2) When you start
> the real scan, 3) when your closing down everything. In case 1 & 2 it
> seems to me that there are a lot of cases where the buffer will not be
> full (because the fake scan doesn't attempt to read a full buffer but
> that might be a bug or in case of the real scan I was thinking that the
> scanner might come back with an EAGAIN error or something and give us a
> partial buffer).
At the start of a scan you need to fill the entire circular buffer before
you can get a single byte out of it. This is the reason for cb_start being
set to -1 at the beginning. It triggers the buffer routines to perform the
first intial complete fill. So, you are right about cases 1) and 2). Case
3) is an oddity. cb_start won't become -1 during closedown. However, if we
try a super small scan (less than the number of lines needed to fill the
circular buffer), or something goes wrong, we might be shutting down before
the circular buffer is completely full, and cb_start will still be -1. I
try to behave correctly in the RGBRouter_remaining routine, using the code
you reproduced above.
Lawrence was hitting this situation. In his case, the behaviour of the USB
pseudo-SCSI interface was causing zero byte reads mid-scan. This was seen
by the code as the end of the scan, and shutown began. The fix there was to
stop the USB code's bad behaviour.
> If I read your original email correctly you said the test for cb_start <
> 0 was for the end of the scan but I don't really see any code that would
> drain the circular buffer after the call to RGBRouter_done().
I think either you misread, or I miswrote.
The ideal thing would be that you ask for x lines of scan, and get x lines.
For this, the scan would need to be expanded by the number of lines
required for the circular buffer to merge the R, G and B lines. I wasn't
sure if this was OK for a full page scan on all models, or if the scan size
limits which the scanner returns are absolute. The RGB offsets which the
scanner reports are in terms of scan lines at the current scanning
resolution. You cannot find the correct offsets until you set the scanner
to the required resolution. This causes some sequence-of -events hassles I
cannot quite remember, and didn't sort out. My dirty, short term, approach
was to just return a few lines less than you ask for. So, the answer to
your question about whether lines are absorbed in the circular buffer is
yes. The number of scan lines over which the R, G and B scanners are spread
are absorbed, as you can only correctly output parts of the image which all
three colours have scanned.
Regards,
Steve
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Tue Nov 21 2000 - 05:54:31 PST