Re: [snapscan] Core testing group

From: Sebastien Sable (sebastien.sable@gmx.net)
Date: Thu Nov 02 2000 - 19:59:14 PST

  • Next message: Dunphy Richard-rdunph01: "RE: Problems with Microtek E3 on Adaptec 1502 SCSI on SuSE Linux."

    cbagwell@sprynet.com writes:

    > This information is very useful. Do you think we should include it
    > in the snapscan.desc file somehow?

    I will put it on the web page when it will be ~complete. Some people
    reported other scanners (by mail to me not to the mailing-list). I
    don't have a report for all the models, but at least those that have
    been reported seem to work.

    > Acer 640BU (Not labeled as a Prisa for some reason!)
    > FlatbedScanner20
    > Works under 1.0.1, stops halfway through with 1.0.3. Probably fixed
    > by Sebastien's patches.

    Probably not ;)

    It's a FlatbedScanner20 so from snapscan.h it uses a PRISA620S. I have
    not made changes for this model, you have to look for ACER300F in:
    * snapscan-source.c (if it blocks (stop halfway?)) <--
    * and/or snapscan-scsi.c (if the picture is full of noise)
    * and/or snapscan.c (if the picture has a puzzle problem : many blocks
      of pixels (mélangés?) badly sorted)

    The change is quite obvious (there is a big test for many models -
    ugly but it works (I'd like to change it though) - just add your
    model).

    > Its described as 48-bits on the box but I downloaded the specs for
    > the scanner chip it uses and it says something about 14 bits only.
    > I'll get back to you on this stuff. It may be more useful to
    > describe the scanners dpi not by model names but the actual optical
    > chip used.

    I though there were only 300dpi and 600dpi. Are there really
    resolutions higher than 600dpi or is it just some kind of
    interpolation?

    I was pretty sure that I could group all scanners in 3 categories to
    simplify the code, and then I realized, that on top of resolution, bus
    and protocol differences, there was a difference between bits per
    color.

    USB/SCSI difference can be easily detected (I looked in epson backend
    to see how they did and we can adapt it - they just put usb in front
    of /dev/usbscanner in their conf file and detect that).

    It would be great if the bits_per_color could be obtained by an
    inquiry, that would not break my pseudo-classification (ok, that's not
    really a good scientific way of proceeding, I'm modifying facts so
    that they fit in my theory, but that would be so much pratical).

    -- 
    Sébastien Sablé
    sebastien.sable@gmx.net
    

    -- 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 : Thu Nov 02 2000 - 19:59:25 PST