# 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."
  - Previous message: Sebastien Sable: "Re: [snapscan] Core testing group"
  - Next in thread: Steve Underwood: "Re: [snapscan] Core testing group"
  - Reply: Steve Underwood: "Re: [snapscan] Core testing group"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  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

  - Next message: Dunphy Richard-rdunph01: "RE: Problems with Microtek E3 on Adaptec 1502 SCSI on SuSE Linux."
  - Previous message: Sebastien Sable: "Re: [snapscan] Core testing group"
  - Next in thread: Steve Underwood: "Re: [snapscan] Core testing group"
  - Reply: Steve Underwood: "Re: [snapscan] Core testing group"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Thu Nov 02 2000 - 19:59:25 PST