Hi Ralph,
I just committed your patch to git. I also edited some doc files and set
the scanner to "status :good" due to buggy ADF.
Maybe you'll have access to the scanner again in future. Then we can fix
buggy ADF.
Many thanks for your help.
Cheers,
Rolf
Am 21.09.2013 17:24, schrieb littlesincanada:
> Hi,
> Final patch included.
>
> The ADF "dirty fix" did the job for me: after the first scan subsequent
> pages are ejected from the ADF.
> I have not included it in the patch file though.
>
> I wish I had the time to have a go at this, but I only have the scanner
> today and lots of other stuff to do :(
>
> Anyway, apart from all that, it's great! Fully functional scanning and
> no errors.
> Contributing is cool.
>
> BTW: udev rule (I don't know if this is supplied by sane or the distro,
> but here it is anyway):
>
> # Canon imageCLASS MF4770N
> ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="2774",
> ENV{libsane_matched}="yes"
>
> Until next time!
>
> Cheers,
> Ralph
>
>
> On 21/09/13 00:50, Rolf Bensch wrote:
>> Hi Ralph,
>>
>> Am 21.09.2013 07:39, schrieb littlesincanada:
>>> Hi Rolf,
>>> Enclosed is the output file for the ADF multi page issue.
>>> As before, I load up 2 pages into the ADF.
>>> On first scan with xsane, the first page is pulled through and scanned
>>> normally.
>>> As the first page is finishing, the ADF starts to draw through the
>>> second page (like a fax machine typically does), then waits with it
>>> after the first page is finished.
>>> The trace in the enclosed file acknowledges that the ADF still has some
>>> pages in it.
>>> The scanner Processing/Data light is flashing so the scanner thinks that
>>> a job is still in progress.
>>>
>>> When I try to scan the next sheet, the trace shows that xsane thinks the
>>> scanner is busy and cannot proceed.
>>>
>> Maybe attached dirty patch will help for this issue.
>>
>> The problem is that the backend doesn't recognize that a 2nd page starts
>> scanning. Therefore it starts with the start session command. Normally a
>> scan is closed with the abort session command, but not a multi page scan
>> session. It is waiting for the next page and sends the abort session
>> command after the last page has been scanned.
>>
>> But maybe it is too complicated and we should follow KISS: A complete
>> scan session for each single page. We can do this here because we don't
>> use gama tables and other calibration for the scanner. But maybe this
>> will cause other problems with the frontend (batch scan).
>>
>> The main control variables are in pixma.c in pixma_sane_t: idle and
>> page_cout.
>>
>>> =========
>>>
>>> BTW, the flatbed will actually do the full 11.7" so please put the
>>> flatbed scan height back to 877:
>>>
>>> In iclass_check_param():
>>> sp->h = MIN (sp->h, 877 * sp->xdpi / 75);
>>>
>>> The ADF will indeed scan legal up to 14" in length.
>>> Apart from that everything looks cool.
>>>
>> OK
>>
>>> It is a shame that we have dimension information hidden in the
>>> iclass_check_param() function.
>>> We could do with adding an extra entry in pixma_config_t for separate
>>> ADF/flatbed geometry.
>>>
>> Indeed. This was a quick paste and copy patch. I'll patch this later. I
>> did this before for e.g. adftpu_min_dpi.
>>
>>> On Sunday, I have to say bye-bye to the printer, so from then on, I
>>> cannot do anything further :(
>>> There might be some time for me to look at the ADF issue tomorrow
>>> (Saturday) and test any further patches.
>>>
>> Sorry, I have no time to create any further patches today.
>>
>> Maybe you can solve this by yorself. Please send your final patch, so
>> that I can add this to git.
>>
>> Many thanks for your help.
>>
>> Cheers,
>> Rolf
>
