[sane-devel] Pixma problems: 1200dpi Grayscale and batch mode
john.cotter at phonecoop.coop
Tue Apr 28 08:04:34 UTC 2009
Can you please take me off your distribution list manually? I get about 30
of these per day. The unsubscribe option below does not seem to be working
fully. Regards John
From: sane-devel-bounces+john.cotter=phonecoop.coop at lists.alioth.debian.org
[mailto:sane-devel-bounces+john.cotter=phonecoop.coop at lists.alioth.debian.or
g] On Behalf Of Nicolas Martin
Sent: 26 April 2009 17:42
To: Wade Fitzpatrick
Subject: Re: [sane-devel] Pixma problems: 1200dpi Grayscale and batch mode
Le dimanche 26 avril 2009 à 17:19 +1000, Wade Fitzpatrick a écrit :
> Things wrong in pixma_mp730.c:
> 1. Protocol error. The scanner did not like having start_session
> and select_source commands sent to it when it already had a
> session open and was reading from the ADF.
Does this happen in multipage ADF scan ?
Do you get the "Busy" answer from scanner (what did the scanner not like
In fact, the current implementation by Wittawat did not include ADF code at
the beginning of mp730_scan(), as it is done in mp150_scan().
ADF multipage is simply performed by scanning separately 1 by 1 all pages. I
changed this a while back for generation 3 devices (in file mp150) to
enhance multipage speed and act exactly as the windows driver does.
One thing surprises me in the code you added: could you double check that
the counter increments with a PDBG output ?
I see it constantly at 0 if I try, due to thread start/stop, the
session_open counter is reset at each page scan, and in this case,
start_session/select_source will still always be sent.
Would be good to double check in a Windows snoop, using the Windows driver,
how MP730 behaves for multipage scan, as I guess Wittawat probably imitated
this behavior. This is the neatest way to be sure implementation will be ok.
So a suggestion here: would prefer to use the same as for a generation 3
device (file mp150), there's a slightly different flag
(s->param->adf_pageid), which can be used for that, the change from your
code would be:
+ if (error >= 0 && ! mp->session_open)
place, as in pixma_mp150.c:
+ if (error >= 0 && s->param->adf_pageid == 0)
I don't know however what would be the side effect for other MPs managed by
file pixma_mp730.c but will limit this to ADF scan only.
> 1. The maximum resolution for the ADF is only 600dpi.
Yes, if not supported, the scanner rejects the 1200 dpi in ADF, with an IO
error returned by the backend.
Another suggestion here:
Rather than returning an error, would be to force a scan at 600 dpi instead
of 1200 dpi (very easy to implement in mp730_check_param()), and to issue a
PDBG warning. This way, a non expert user under a graphic frontend would not
get an error that he may not understand, he would get a 600 dpi scan from
ADF instead of a 1200 dpi (maximum the scanner can do).
> 1. The maximum bounds should not apply for the ADF. This is still
> an issue. I changed the bounds in the pixma_config_t structure
> to be able to accept A4 pages, but the ADF can read up to 39
> inches according to Canon's sales flyer.
> The patch containing fixes 1 and 2 is ready to be applied to CVS now.
> Fix 3 is not ready yet.
> I have solved the ECANCELED problem using a different method. Please
> review the patch on my website.
> The change to pixma.c is still curious even to me. I found that
> sometimes when I was stepping through the code in gdb, it would end
> successfully without the ECANCELED return code, but every time I just
> let it run by itself, it always returned ECANCELED. By experimenting
> with different sleeps, from 10000 to 100000, I found that 30000 gives
> a successful scan consistently. I don't understand why it works, it
> just works.
The driver is not working correctly, as it should not loop there, but should
call read_image() at line 1313 in pixma.c
As explained before, this is because the scanner is requested a different
scan width than the frontend wants, leading to padding or trunking the scan
line in other loops in pixma.c
The modification proposed before (sp->w = calc_raw_width (sp) *
sp->channels;) works fine, as seen in the log trace, there's only
another bug which is trigged :-( as at the end of this log, the end
sequence is incorrect.
The "abort_session" ef20 message is sent before the 2 query_status
(f320) and activate (cf60), and gets an error return (1515) from the scanner
(and thus trigs the ECANCELED). This bug is easy to fix (a mess up with the
state_finish status in read_image_block, corrected in file
mp150) and should make the whole scan sequence right:
- scan width corrected
- end condition corrected
I'll send you a modified pixma_mp730.c file to try with those changes.
> So now I can scan many A4 pages successfully in batch mode through the
> ADF at resolutions 75dpi to 600dpi.
> When I add your suggestion to change the way the width is calculated,
> it goes back to returning ECANCELED. See the log.
> The log of a 1200dpi grayscale scan is also attached to my site.
I don't see in this 1200 dpi gray log any issue concerning the backend
except scan width set at 1890 by the frontend, but requested at 1896 to the
scanner, due to rounding at 12. I don't understand why the scanner stops
sending data at some point, it did not send any end of scan condition :-(
Does 1200 dpi grayscale work under Windows ?
> 2009/4/26 Nicolas Martin <nicolas.martin at freesurf.fr>
> Le samedi 25 avril 2009 à 23:43 +1000, Wade Fitzpatrick a
> écrit :
> > I tried moving the MP730_PID and DEV macro from
> pixma_mp730.c into
> > pixma_imageclass.c but the scanner would not operate at all.
> > attached to the endpoints correctly and could read and write
> URBs but
> > when it came to sending the read_image command (0xd420) it
> > with a cancel command (0x1515).
> > The other imageCLASS devices are all limited to 600dpi which
> > their specifications but the MP730 is capable of
> 1200x2400dpi optical.
> > Maybe the imageclass driver is not the best reference for
> That's normal, there are some differences, so MP730 cannot
> work out of
> the box with the imageclass driver. The idea here was to
> compare both
> mp730 and imageclass files to check differences, if you do
> this, you'll
> see they are very similar.
> 1/ grayscale issue
> Could you now just activate only the pixma trace log:
> $ export SANE_DEBUG_PIXMA=11
> and put the full error trace in a file, zip it and send it
> back, I would
> like to check if the scanner sent the end scan condition, or
> something special happens at the moment it hangs. Also, how
> much data it
> expected to send versus how much is requested.
> 2/ End condition canceled by software
> I have a clue (but it's only a guess) on what happens here, as
> looks same to what happened for devices in the mp150 file.
> The "Canceled by software" end condition was raised because
> the frontend
> expected less data than the scanner was requested to send, so
> backend sends an abort command to the scanner when all its
> expected data
> is received.
> In fact, all Pixma devices need a rounded up scan width, older
> had a 4 or 12 pixels alignment, while recent generations
> currently all
> use 32.
> For mp150 devices, the fix was simply to modify the scan width
> requested by the frontend, to take this into account (the
> round up was
> only done for scanner parameters).
> Could you try the same in the mp730 file:
> in function mp730_check_param(), change the current content:
> sp->depth = 8; /* FIXME: Does MP730 supports other
> depth? */
> sp->line_size = calc_raw_width (sp) * sp->channels;
> with that:
> sp->depth = 8; /* FIXME: Does MP730 supports other depth? */
> sp->w = calc_raw_width (sp);
> sp->line_size = calc_raw_width (sp) * sp->channels;
> and give a try ?
> Also, could you take a complete [pixma] only log trace and
> send it
> back ?
sane-devel mailing list: sane-devel at lists.alioth.debian.org
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-request at lists.alioth.debian.org
More information about the sane-devel