Re: [sane-devel] Help Please with Nikon Super Coolscan 4000 ED

[abel deuring]

Am 06.03.2018 um 23:34 schrieb Bob Louden:
> Dear mailing list.  Please excuse me if I am not using this mailing list
> properly.
> 
> I created a request for help a few days ago in the Linux Mint Hardware
> forum but have not had any luck with responses.  
> 
> I have this very nice, albeit old, scanner that I cannot get to work --
> though I feel like I am very close to having it work.  Alas, I am on the
> brink of giving up on it.  I also have this not-as-good Plustek scanner
> that I've started messing with and it was from searching for help with
> it that I found your mailing list.
> 
> Anyway, if there is anyone out there who might be able to help me, here
> is a link to my Linux Mint forum
> post:  https://forums.linuxmint.com/viewtopic.php?f=51=264978
> 
> Please feel free to respond to me via either email or in the forum.

Bob,

after reading the conversation on the Mint forum it seems to me that the
host machine and the scanner have a, let's say, very serious
communication problem: The excerpt from syslog after "UPDATE2" in your
first post there shows the message "scsi host6: scsi scan: INQUIRY
result too short (7), using 36".

The "inquiry" command is the first command sent by a SCSI host to a SCSI
device when the host detects a new SCSI device. (I know, the scanner is
connected via Firewire, not via a physical SCSI interface, but Firewire
uses the SCSI commands for several device types.)

When a SCSI device receives this comamnd, it should send back a
description of itself: What type of device (disk, optical drive, tape
drive, scanner etc) it is, its vendor vendor name, product name and
other stuff. A SCSI device must send at least 36 bytes to the host
computer, and the content of these 36 bytes is well standardized.

You can find a description of the inquiry command for example on pages
90-99 of this file:

https://www.seagate.com/staticfiles/support/disc/manuals/scsi/100293068a.pdf

(it is hard to find a "generic" description of the SCSI commands, so I
just opened the first result of a Google search for "scsi protocol
specification". As already said, the first 36 bytes inquiry command are
well standardized, so it does not matter much that this PDF describes
the wrong device type.)

The type of the device is described in bits 0-4 of byte 0 in the inquiry
data (page 92 of the aforementioned PDF) – and, according to syslog,
they say that the device is a disk which is obviously wrong. Another
oddity in the syslog messages: The scanner has apparently sent only 7
bytes, not the expected 36 bytes. But it seems that the product name
("LS-4000 ED"), stored in bytes 16-31 of the inquiry data, has been sent
to the host anyway.

In other words: The communication between the computer and the scanner
is really messed up. Hence I think that the idea to replace the firewire
controller and driver chips (as you mention in the forum under "NEWS
FLASH") is technically reasonable – but I also understand that doing
this on a "commercial basis" is somewhat unreasonable.

But before you consider this (despite the costs...) you should
double-check that the Firewire interface of your computer works: Try to
connect another Firewire device to the computer and check if it works
better. Similary, you could check if the scanner shows similar symptoms
when it is connected to another computer. Since we suspect a hardware
problem, you could try any other machine that runs under Linux, MacOS or
Windows.

Abel

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] Supported languages?

[abel deuring]

Am 01.10.2017 um 19:04 schrieb Jeff Sadowski:
> I'm not sure I grasp it.
> 
> So if I install ubuntu on a vm for each language I want to support would
> I be able to copy the output for each language?

No: The i18n concept for Sane is this:

- The backends return in every case the Endlish strings as they appear
  in the source code.
- A frontend can/should use the PO files to replace the english strings
  with the desired language.

The problem is that scanimage, the frontend, does not support i18n/l10n.

Perhaps one more reason to follow Jeff's advice not to call scanimage
but to write a Sane library for PHP ;)

> Or would it be better to do a google translate for the languages? I can
> add tables for translating the common options if need be.

Well, the translations are all there, in .po/.mo files -- just use them
;) But again, this is much easier to do if a PHP wrapper for Sane
backends directly passes the English strings to your application than to
search for these strings in the output from scanimage.

I am not at all familiar with PHP, but I'd bet that it supports gettext().

Abel


> 
> On Sun, Oct 1, 2017 at 5:18 AM, Olaf Meeuwissen
> > wrote:
> 
> Hi Yury,
> 
> Yury Tarasievich writes:
> 
> > Does scanimage actually contain the l10n
> > functionality?
> 
> Good question!
> 
> While the backends have their messages translated to some 20 languages,
> it is the SANE frontend's responsibility to activate translation.  I did
> a quick check of the scanimage source code and it doesn't seem to do so.
> 
> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
>  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>  Support Free Software                        https://my.fsf.org/donate
>  Join the Free Software Foundation              https://my.fsf.org/join
> 
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> 
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> 
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>              to sane-devel-requ...@lists.alioth.debian.org
> 
> 
> 
> 
> 


-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] ScanSnap S1100 on Linux Mint

[abel deuring]

Am 23.06.2017 um 13:41 schrieb Crusader:
> Thank you for identifying the problem, Allan.  Your finding brings me
> very close to resolving the issue.
> 
> My distro (Linux Mint 17.3 Cinnamon 64 bit, Cinnamon Version 2.8.8) does
> not have an update to sane-backends version 1.0.27, and as you pointed
> out, compiling is complicated (I tried it).  I am open to suggestions.

Since Mint is based on Ubuntu, Rolf Bensch's PPA can help you:

https://launchpad.net/~rolfbensch/+archive/ubuntu/sane-release

It provides the most recent Sane release. Just follow the instructions
"Adding this PPA to your system" from that page and then run

  sudo apt-get upgrade

Abel

> 
> In the interim, I will take this issue back to the Linux Mint forum and
> see if I can get further help there.
> 
> Your support is greatly appreciated!
> 
> On Thu, Jun 22, 2017 at 8:02 PM, m. allan noah  > wrote:
> 
> On Thu, Jun 22, 2017 at 7:46 PM, Crusader  > wrote:
> >
> > 3. run 'SANE_DEBUG_EPJITSU=5 scanimage -L' and send the output text to
> > this list- I want to see what version of sane you are running.
> > a@a-UL80VT ~ $ SANE_DEBUG_EPJITSU=5 scanimage -L
> > [sanei_debug] Setting debug level of epjitsu to 5.
> > [epjitsu] sane_init: epjitsu backend 1.0.20, from sane-backends 1.0.23
> > [epjitsu] load_fw: firmware already loaded?
> > device `epjitsu:libusb:002:004' is a FUJITSU ScanSnap S1100 scanner
> 
> Well, there is your problem, you are running an ancient version of
> sane-backends, which does not support this scanner fully. You will
> need to upgrade to something more recent. 1.0.25 was the first version
> that supported this scanner, but 1.0.27 would be better, as it
> contains some fixes. You should see if your distro has some kind of
> updated package you could load. If not, you will have to compile from
> source, which is more complicated.
> 
> allan
> --
> "well, I stand up next to a mountain- and I chop it down with the edge
> of my hand"
> 
> 
> 
> 


-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

[sane-devel] HP scanjet 8200: open of device avision:libusb:001:004 failed: Operation not supported

[abel deuring]

Hello,

a friend bought recently an HP Scanjet 8200 and tried to use it under
Ubuntu 14.04 (sane version 1.0.23). The scanner does not have any
accessories like an ADF or a transparency unit.

scanimage -L says:

device `avision:libusb:001:003' is a Hewlett-Packard ScanJet 8200
flatbed scanner

Attempts to run a simple scanimage  /dev/null results in the error:

scanimage: open of device avision:libusb:001:004 failed: Operation not
supported

The stderr output from SANE_DEBUG_AVISION=255 scanimage is in the
attached file.

I see the same error when using self compilied binaries from GIT
revision 29abd19a8f7a0df7614484e887d8d79210687a0e.

But the following patch of the function get_accessories_info() avoids
the problem:

diff --git a/backend/avision.c b/backend/avision.c
index 31b0a58..b1094d4 100644
--- a/backend/avision.c
+++ b/backend/avision.c
@@ -3164,7 +3164,7 @@ static SANE_Status
 get_accessories_info (Avision_Scanner* s)
 {
   Avision_Device* dev = s-hw;
-  int try = 3;
+  int try = 1;

   /* read stuff */
   struct command_read rcmd;
@@ -3238,7 +3238,7 @@ get_accessories_info (Avision_Scanner* s)
 goto RETRY;
   }
   DBG (1, get_accessories_info: Maximum retries attempted, ADF
unresponsive.\n);
-  return SANE_STATUS_UNSUPPORTED;
+  return SANE_STATUS_GOOD;
 }
   }

(The first change isn't important to avoid the problem but makes the
start phase of the scan a bit faster.)

I would not claim that this change is reasonable for inclusion into the
Sane repositories: I did not read the file avision.c very carefully, I
don't have any technical docs for the HP8200 available (neither for any
other of the many scanners supported by the avision backend...) and
can't hence say how this change could affect other scanners supported by
the backend, or even an HP8200 having an ADF installed.

This problem seems to be a bit older. I found these bug reprots for
Ubuntu and Suse:

https://bugs.launchpad.net/ubuntu/+source/sane-frontends/+bug/789745
https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1050011
https://bugzilla.novell.com/show_bug.cgi?id=680767

Myself and the owner of the scanner are able to test other workarounds
or real fixes -- but the response time will be a bit slow: I'll need to
visit the owner in order to try anything...

cheers
Abel


hp8200.log.gz
Description: GNU Zip compressed data
-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject unsubscribe your_password
 to sane-devel-requ...@lists.alioth.debian.org

[sane-devel] Legal-size scanner recommendations?

[abel deuring]

*On 12.02.2010 05:12, emre wrote:
 Thank you for the recommendation. I looked at the fi-6130  it seems/
 quite nice. I originally had in mind a flatbed scanner, but this looks
 like it will be more generally
 useful  convenient... actually the more I think about, I think fi-6130
 will be a better
 choice for my needs.  I looked at and subsequently rejected the
 fi-6230... I prefer
 the smaller footprint of the fi-6130.
 
 I have one more question, it has to do with resolution.  The fi-6130
 reports a 600 dpi
 resolution (which seems to me to be more than sufficient).  I have seen
 some Epson
 scanners that report 6400 dpi.  I am guessing that higher resolution
 might be good
 for slides and photos, but wouldn't be of much use for scanning documents?
 Thanks again,

I have serious doubts that even any affordable slide scanner really has
such a high resolution; for a scanner that can scan an A4 or letter size
document, 6400 dpi sounds ridiculous. You would need very precise and
expensive optical and mechanical components to really achieve such a
high resolution.

Also, consider the size of an A4 size scan with 6400 dpi: That would be
210*297*6400*6400/(25.4*25.4), nearly 4 billion pixels. IOW, you could
fill a terabyte disk with just 250 uncompressed gray scale images...

Typical scan resolutions for A4/letter size are 200 or 300 dpi -- what
you need depends on your use case, the number of scans you want to store
and on the storage capacity you can and want to afford.

Abel

[sane-devel] Stated scanner resolution. Was: Legal-size scanner recommendations?

[abel deuring]

On 12.02.2010 14:16, emre wrote:
 abel deuring wrote:
 *On 12.02.2010 05:12, emre wrote:
  

 I have one more question, it has to do with resolution.  The fi-6130
 reports a 600 dpi
 resolution (which seems to me to be more than sufficient).  I have seen
 some Epson
 scanners that report 6400 dpi.  I am guessing that higher resolution
 might be good
 for slides and photos, but wouldn't be of much use for scanning
 documents?
 Thanks again,
 

 I have serious doubts that even any affordable slide scanner really has
 such a high resolution; for a scanner that can scan an A4 or letter size
 document, 6400 dpi sounds ridiculous. You would need very precise and
 expensive optical and mechanical components to really achieve such a
 high resolution.

 Also, consider the size of an A4 size scan with 6400 dpi: That would be
 210*297*6400*6400/(25.4*25.4), nearly 4 billion pixels. IOW, you could
 fill a terabyte disk with just 250 uncompressed gray scale images...

 Typical scan resolutions for A4/letter size are 200 or 300 dpi -- what
 you need depends on your use case, the number of scans you want to store
 and on the storage capacity you can and want to afford.

 Abel

   
 I just verified at the epson.com website for the Epson Perfection V600
 printer, and they
 do report 6400 dpi for their optical resolution.  Granted, it would take
 a lot of disk space,
 but it would also seem beneficial to have this resolution for archiving
 of slides and negatives.

Sure, it might be nice to scan slides with that resolution. But even
then: IIRC, the resolution of most slides is more like 2000dpi than
6000dpi. So, unless I am completely mistaken about the, how is is
called, grain size?, of slides or negatives, 6400dpi looks a bit
pointless. Also, I'd be really curious how a scan of a high-quality
Siemens star (http://en.wikipedia.org/wiki/Siemens_star) looks like for
these allegedly possible 6400dpi. Frankly, I'd suspect that the image
will look quite blurry, if you look at it closely enough.

 Now, if they really have this resolution, I can not say...  I am

I can't say either, of course ;) Sure, I believe them that the _data_
produced by scanner will have 6400dpi resolution -- I just doubt that
you can really get such an _optical_ resolution with a scanner that
costs less than, let's say, a good second hand car...

Abel

[sane-devel] List of sane_control_option options?

[abel deuring]

On 10.05.2009 15:49, Mark Pemburn wrote:
 Hi again,
 
 Almost immediately after sending my request, I think I figured out what I 
 need to do:  Call sane_get_option_descriptor with the SANE handle and 
 integer 
 0 as the second argument (SANE_Int n) and it'll return a pointer to a 
 structure of type SANE_Option_Descriptor.  One of the members of this 
 structure 
 contains the an integer that tells _how many_ options are available from this 
 particular device (not sure which but I'll test it out and see).  By 
 iterating 
 over calls to sane_get_option_descriptor supplied with values of 1 to n-1, 
 you'll get a full list of available options and what to do with them.  Is 
 this 
 correct?  Anything I missed?

Yes, it is correct.

 
 Mark
 
 Earlier I wrote:
 I'm pretty new to SANE so please forgive my ignorance.  After several 
 weeks of brain busting with new languages and concepts, I've made quite a 
 bit 
 of progress on my Mac OS X scanner interface using Cocoa/Objective-C.  I can 
 get the list of available scanners, get the SANE handle and, in moment of 
 ecstasy this past Thursday, was finally able to activate the scanner and 
 retrieve data.  I still haven't figure out exactly how to display the 
 results 
 but this will come in time.  The next thing I want to tackle is setting 
 options for the scanner, something I gather is done with 
 sane_control_option.  Is there a list of all of the available options and 
 the valid values for each?  I've searched all over but haven't turned 
 anything 

There is a list of well-known options (you found it already, I assume
;), but there is nothing like a complete list of options. There is no
way to predict what fancy features a scanner ?ight have: Some ADF
scanners can detect double feeds or have a small printer attached
allowing you to print serial numbers on scanned documents, other
scanners allow you to select the light colour; a slide scanner might
allow you to select a specific slide from a tray with multiple slides.
For more examples, look into the source code of some backends ;)

If you want to write GUI widgets, I'd strongly recommend to work with
the test backend. Firstly, it scans much faster than any real scanner,
and secondly, you'll get examples for every Sane option, giving you the
best opportunity to ensure that your code can indeed deal with sorts of,
erm, weird Sane options.

Abel

 up yet.  Your help will be greatly appreciated.

 Regards,

 Mark Pemburn
 

 --
 sane-devel mailing list: sane-devel at lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/sane-devel
 Unsubscribe: Send mail with subject unsubscribe your_password
  to sane-devel-request at lists.alioth.debian.org
 
 
 
 
 
 --
 sane-devel mailing list: sane-devel at lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/sane-devel
 Unsubscribe: Send mail with subject unsubscribe your_password
  to sane-devel-request at lists.alioth.debian.org

[sane-devel] automated, multiple scanner use

[abel deuring]

On 14.04.2009 14:24, Rewald, Boris wrote:
 Dear list,
 
  
 
 I new on this list and the ?sane field?. Thus, I have to ask some basic
 questions first.
 
  
 
 I?m looking for an method to use 10-20 usb flatbed scanners with one
 computer (possibly connected via an usb-hub) and by setting automatic
 scan intervals (for example: once scan an hour per scanner).
 
  
 
 Do you think this is possible? What software do I need?

The most straightforward way is probably a simple cronscript which
invokes scanimage.

There might exist though a problem: I am not very familiar with the
internals of libusb (used by most if not all backends for USB scanners),
so I might be wrong, but I suspect that the device string for scanimage
(as in scanimage -d fujitsu:002:003) might change when you
disconnect/reconnect a scanner. In other words: make sure that a given
device string always identifies the same scanner. (I am sure that other
people reading this list can give you better founded advice about the
stability of these device numbers.)

If a cronscript calling scanimage is, erm, too simple, you might
consider to write a Perl or Python script. For both languages exist Sane
bindings. A simple scan script can be as small as 20 or 30 lines (at
least in Python), allowing you for example to easily create meaningful
filenames or to store some interesting metadata in another file for each
scan.

Abel

[sane-devel] Paper size detection for Fujitsu fi-5110eoxm (sane-fujitsu)?

[abel deuring]

On 22.03.2009 12:58, Adam Richter wrote:
 Hello,
 
   At the outset, let me say thank you to the sane-fujitsu
 authors (according to fujitsu.c, Randolph Bentson, Frederik Ramm,
 Oliver Schirrmeister, and M. Allan Noah) for providing a backend that
 has been working so well with my Fujitsu fi5110eoxm double sided
 sheet fed scanner for almost two years.
 
   I am interested in adding automatic page length detection,
 similar to what the avision driver does I would like some pointers to
 the relevant technical specifications of the protocol used by the
 scanners that sane-fujitsu supports.  I do not see that feature in
 the cvs snapshot of 2009.03.22, but I may have missed something.  I
 am not saying that I am committing to implement this, but I would
 like to get the relevant technical specifications and see how hard
 it would be to try.

I can't claim that I know how page length detection works in the avision
backend, but from quickly grepping through the source code it seems that
some Avsion scanners have some sort of firmware support for this
feature. Some Fujitsu scanners, OTOH, support an overscan feature,
meaning that they scan an area larger than the selected papersize.
Additionally, you can select the color of this overscan area to be
either white or black, so that the scan data can include a black margin
around white pages or a white margin for black pages. This allows you to
implement paper size and skew detection in software. Having code that
implements these features would really great -- but the code should IMHO
live outside the Fujitsu backend, just for the case that scanners from
other manufacturers support a similar feature.

Some kind of library would be great, another option would be a
contribution for a program like Jens Gulden's unpaper.

 
 If I get really ambitious, perhaps I might also try to
 implement a bottom margin option to scan a bit past the end to
 accomodate pages scanned at a slight angle, and perhaps some support
 for the scan button also along the line of what avision has.
 
   Just to confirm that I have done some basic sanity checks
 related to this request, I will mention that scanner appears to
 support page length detection, according to these web pages:
 
   Automatically recognizes document type by paper length
   http://scansnap.fujitsu.com/spec-mac.html
 
   Automatic de-skew and paper size detection
   
 http://www.fujitsu.com/us/services/computing/peripherals/scanners/discontinued/fi-5110eoxm.html
  (click on Features tab)
 
   As another sanity check, I should mention that I have done
 some web searches and skimmed the sane-devel mailing list to
 try to see if anyone is already working on this, and have not
 found any hits.
 
   At first, I was hopeful that since the fujitsu backend's help
 text mentioned that it wanted to know the page size in order to do jam
 detection, that perhaps the driver was periodically querying the paper
 detection and scrolling the paper from the host computer, but a quick
 look at the source code seems to indicate that the paper size
 information is simply sent to the scanner, I guess locally controls
 the scrolling of the paper feeder.  So, I think I need more
 documentation about the protocols used by this scanner to figure out
 how to implement support for automatic paper length detection.

AFAICS the Fujitsu scanners use indeed the selected page length to check
if some sensor sees paper after a document has been fed for the
selected page length (plus some error margin).

 
   I assume that there is no automatic paper width detection, but
 would be happy to be corrected if I am wrong, especially because the
 images that I receive for the areas left and right of the paper being
 scanned seem to have some noise (that is, they are not columns of
 exactly one solid color), so I will probably have to do some research
 to determine if I can find software that reliably detects the paper's
 left and right edges.

Again, the overscan feature should give you all data you need (erm,
provided that your  5110eox supports it...)

 
   Finally, on a different subject, but one related to protocol
 documentation, I notice that nineteen .c files in
 sane-backends-2009-03-22/backends contain both the terms USB and
 SCSI, so it looks like there are multiple drivers that claim to
 encapsulate some kind of scsi commands over USB.  This makes me wonder
 if there might be some SCSI standards on t10.org and/or USB device
 class specification on www.usb.org that might describe what most of
 these drivers do and perhaps provide an opportunity to factor out some
 common code.  On the other hand, if the fujitsu scanners are basically
 running a custom protocol, then I probably need some documents from
 Fujitsu, which I am sure would be helpful in any case.
 
   Any pointers would be appreciated.  Thanks in advance.

You'll find indeed drafts of the SCSI2 and SCSI3 standards at t10.org.

[sane-devel] Providing the version of SANE used in VueScan

[abel deuring]

On 27.01.2009 07:30, Ed Hamrick wrote:
 Hi Olaf,
 
 The source you referred to is attached.  I'm happy
 to assist people with getting copies of the source
 code to the trivial parts of SANE that I used in
 VueScan.  And yes, I'm obviously capable of spending
 an hour or two stripping the sanei_scsi module
 out of VueScan - after all, VueScan does support many
 things (like infrared cleaning) on Epson scanners that
 you're incapable of supporting :)

Actually, I'd appreciate if you would remove sanei_scsi from Vuescan. I
remember a bug report from a Vuescan user a few years ago who stumbled
over a sanei_scsi bug. I could fix this bug quickly -- but the poor user
was out of luck: you wrote that you hadn't had enough time to link the
fixed sanei_scsi version into a new Vuescan release...

That was a reason why I always considered to start a discussion if Sane
shouldn't switch to the LGPL: It would allow Vuescan users to link a
fixed Sane library into Vuscan and other proprietary programs for
themselves.

 
 This is also an official request to Ren? Rebe to
 provide the source code to avision.c that he's included
 in ExactScan 2.

Yeah -- the funny thing with this request is that it was Rene who wrote
the avision backend. So your request may be formally valid, but,
frankly, it looks a bit weird.

Abel

[sane-devel] Providing the version of SANE used in VueScan

[abel deuring]

On 27.01.2009 18:28, m. allan noah wrote:
 On Tue, Jan 27, 2009 at 8:01 AM, abel deuring adeuring at gmx.net wrote:
 On 27.01.2009 07:30, Ed Hamrick wrote:
 Hi Olaf,

 The source you referred to is attached.  I'm happy
 to assist people with getting copies of the source
 code to the trivial parts of SANE that I used in
 VueScan.  And yes, I'm obviously capable of spending
 an hour or two stripping the sanei_scsi module
 out of VueScan - after all, VueScan does support many
 things (like infrared cleaning) on Epson scanners that
 you're incapable of supporting :)
 Actually, I'd appreciate if you would remove sanei_scsi from Vuescan. I
 remember a bug report from a Vuescan user a few years ago who stumbled
 over a sanei_scsi bug. I could fix this bug quickly -- but the poor user
 was out of luck: you wrote that you hadn't had enough time to link the
 fixed sanei_scsi version into a new Vuescan release...

 That was a reason why I always considered to start a discussion if Sane
 shouldn't switch to the LGPL: It would allow Vuescan users to link a
 fixed Sane library into Vuscan and other proprietary programs for
 themselves.

 This is also an official request to Ren? Rebe to
 provide the source code to avision.c that he's included
 in ExactScan 2.
 Yeah -- the funny thing with this request is that it was Rene who wrote
 the avision backend. So your request may be formally valid, but,
 frankly, it looks a bit weird.
 
 No, it is not weird at all. The GPL is not to punish Rene, it is to
 give rights to Ed (and everyone else). If he has received a legitimate
 copy of ExactScan, he is entitled to the SANE portions. Since
 ExactScan comes as a free trial, everyone is a legitimate user. There
 seems to be no other way to get this code than asking Rene directly.

As Julien aleady wrote, if Rene is the only author of the backend he can
whatever he wants with the code.

 
 allan
 
 ps- these license issues would be clarified by switching to the LGPL,
 but because the copyright holder of SANE is each individual author,
 you would have to get all of their permission. An impossible task,
 IMHO.

Agreed. That's the main reason why I did not start this discussion.

Abel

[sane-devel] Question on SCSI-scanners

[abel deuring]

On 06.01.2009 21:00, Dieter Jurzitza wrote:
 Dear listmembers,
 dear Abel,
 dear Allan,
 thanks for the pointers. First of all, a grep processor within the 
 desc-files results in nothing. I personally do not see a way how to extract 
 this information from the desc-files, but maybe (hopefully!) I overlooked 
 something.
 
 For better explanation: I started working on the fdi-file to include support 
 for scsi scanners. Everything that announces itself as scanner is readily 
 supported. Howerver, I have a SCSI-Scanner from HP here that announces itself 
 as processor, so as you readily confirmed, this may happen. And, naturally, 
 hal won't grant access to this device as - well, a processor is not a scanner 
 if you do not know that it is a scanner.
 
 What I'd like to avoid is to generally assign every device on the SCSI bus 
 assigning itself the attribute processor the permissions of a scanner. 
 This is why I'd like to realize the list.
 
 The point is now how can I get that list in order to include a set of 
 modifications within the fdi file so everyone having a SCSI scanner would 
 be back into live with the openSUSE distribution (and probably others, 
 too).
 
 I mean, there are other ways of getting there (like making the user a group 
 member of the group that gets assigned to the device by udev) but this is 
 inconsistent and I'd like to prevent end-users from having more work than 
 neccessary.
 
 So, I only have one scanner that behaves like this - if you have an idea what 
 to check for in oder to find the scanner's behaviour would be fantastic. From 
 the sane - sources I only saw that anything like scanner / processor is 
 accepted by sane - but due to additional rules sane will find out whether it 
 is really a scanner or not.
 
 If anyone has a rule of thumb that would (at least) cover the vast majority 
 of 
 such devices that would be of huge help for me. I am currently working on a 
 patch for sane-desc.c to provide the corresponding information and will send 
 it upstream as soon as I know sufficient details.
 
 @Abel: could you kindly provide an example in the sources what you're 
 referring to with the INQUIRY command or / and with the sane_start 
 references? For example, if I look into hp.c, the sane-start will trigger 
 sanei_hp_handle_startScan and things get quite difficult to track.

Right, the hp backend isn't that easy to read ;) It seems from quick
grepping that it issues the INQUIRY command only in one function,
sanei_hp_scsi_new (command data inq_cmd; retunred data in inq_data).

I wrote my mail without actually looking into the relevant source files
and the *desc files... I would have made a moderate bet (say, a few
bottles of wine) that
(1) the *desc files contain the SCSI model and vendor names as returned
by the scanner for the INQUIRY command
(2) each backend would check the vendor and model names returned for the
INQUIRY against a list of known names.

But I am wrong in both cases... You already dicovered that I was wrong
with cklaim (2); for (1), it seems that the HP backend just tries tries
to send an SCL command and to check if the result matches some
expectations in order to decide if the tested device is a supported
scanner... Hence it is not worth the effort to

Anyway, there might be a completely different way to configure HAL. You
can define a rule that a HAL callout script shall be called if a SCSI
device of type processor is detected. In this callout, you call
scanimage -L and parse the result to check if one of the detected
scanners has the right SG device file name. If so, you set up the HAL
properties and you can perhaps even set the device file permissions.
(Though that might be better done elsewhere -- ask the HAL folks...)

Abel

[sane-devel] Slightly off topic: Anyone know anything about SCSI CD commands?

[abel deuring]

On 06.01.2009 00:24, kilgota at banach.math.auburn.edu wrote:
 Wishing everyone a prosperous, happy, and peaceful year 2009.
 
 For a lark, I bought a rather worthless but very cheap gadget for myself 
 for Christmas. It is a very small digital picture frame which one can hang 
 on the key ring. The little book which came with it says that to use it, 
 one merely plugs it in on a computer running XP or Vista, and the app is 
 already installed which will communicate with it. I tried this, and it is 
 so. With the app, one can view JPEG images on the device, also move images 
 to/from, and delete what is on the device. Then, the device has a 
 primitive OS which will allow various things to be done, such as to 
 display the time instead of a picture. It also gets reported as an 
 external drive, with the information that it is full and AFAIK one 
 cannot access it directly.
 
 I made one snoop log, which probably does not yet have the serious 
 information needed to continue with this thing. I spent most of my time 
 fighting Vista to get the log made.
 
 So much for the background. What it is, is a Mass Storage Bulk Transport 
 device which comes up as a /dev/sg, not as a /dev/sd. So in other words it 
 is possible to talk to it with Mass Storage Bulk Transport, but one can 
 not mount it. In other words, similar to some audio CDs, or to some 
 scanners. In the forwarded message below, there is some report of the 
 results of various commands, and also a question at the end, about a 
 certain SCSI command with which I am not acquainted and can not seem to 
 find relevant documentation. I hope that someone can help me with the 
 question.
 
 Theodore Kilgore
 
 
 -- Forwarded message --
 Date: Mon, 5 Jan 2009 12:57:13 -0600 (CST)
 From: kilgota at banach.math.auburn.edu
 To: Pete Zaitcev zaitcev at redhat.com
 Cc: usb-storage at lists.one-eyed-alien.net
 Subject: Re: [usb-storage] A keychain digital picture frame.
 
 
 
 On Thu, 1 Jan 2009, Pete Zaitcev wrote:
 
 On Thu, 1 Jan 2009 21:34:00 -0600 (CST), kilgota at banach.math.auburn.edu 
 wrote:

 I successfully made a snoop log of one photo being moved over to the
 device. Indeed, it appears to be using Mass Storage Bulk Transport
 commands.
 Try to eject the pseudo-CD on Linux, maybe the device will re-enumerate
 itself then.

 -- Pete

 
 Well, as I mentioned earlier, the eject did not work. Therefore, I have done 
 a 
 bit of looking through that log file. I have also gotten a copy of sg3-utils 
 and played with it a little bit.
 
 One thing seems clear, that the device reports itself as a CD. The sectors 
 are 
 2048 bytes, and it uses READ_10 to read a sector, or sectors. Lots of fairly 
 routine stuff. Some selections:
 
  : 55 53 42 43 c8 e6 95 84 08 00 00 00 80 00 0a 25
  0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
 reports
 
  : 00 01 e7 ff 00 00 08 00 (0x1e7ff sectors of size 0x800)
 
 so I wonder if it has the off-by-one error. It would not make any difference 
 unless one were going to mount it, I suppose...
 
 I do not know enough about this to understand the response to REQUEST_SENSE
 
  : 55 53 42 43 88 d5 9f 84 12 00 00 00 80 00 0c 03
  0010: 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
 
 which gets various responses. One of them is
 
  : f0 00 02 00 00 00 00 0b 00 00 00 00 3a 00 00 00
  0010: 00 53
 
 Windows keeps insisting on sending
 
  : 55 53 42 43 28 3e 6e 84 20 00 00 00 80 00 0a 51
  0010: 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
 
 which makes the device to throw a fit, and a reset is required. I think that 
 this has something to do with initializing RAID setup?
 
 Now, scsi.h says the following one is READ_TOC:
 
  : 55 53 42 43 88 2b 82 84 0c 00 00 00 80 00 0a 43
  0010: 00 01 00 00 00 00 00 0c 00 00 00 00 00 00 00
 
 I do not understand what the response might be telling me, which is
 
  : 00 0a 01 01 01 14 00 a0 00 00 00 00
 
 though I do vaguely remember that the device claimed to have room for 45 
 images. The numbers strung out here do add up to that, which might or might 
 not 
 be significant.
 
 
 Here is a sample of READ_10
 
  : 55 53 42 43 c8 e6 95 84 00 08 00 00 80 00 0a 28
  0010: 00 00 00 00 19 00 00 01 00 00 00 00 00 00 00
 
 (read one sector at 0x19)
 to which the reply begins with
 
  : 5b 41 55 54 4f 52 55 4e 5d 0d 0a 49 43 4f 4e 3d
 A  u  t  o  r  u  n i  c  oO  P  E
  0010: 41 75 74 6f 72 75 6e 2e 69 63 6f 0d 0a 4f 50 45
  0020: 4e 3d 49 6d 61 67 65 56 69 65 77 65 72 34 2e 65
 x  e -  C  O  P  Y  F  I  L  E
  0030: 78 65 20 2d 43 4f 50 59 46 49 4c 45 00 00 00 00
  0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0050: 00 00 00 (the rest of the sector is empty)
 
 and then
 
  : 55 53 42 43 08 00 5b 84 38 00 00 00 80 00 

[sane-devel] Question on SCSI-scanners

[abel deuring]

On 06.01.2009 17:30, Dieter Jurzitza wrote:
 Dear listmembers,
 prior to doing a deep down search on my own, here's a question someone 
 might 
 be able to answer  to me:
 
 The move in openSUSE from conventional permission distribution to hal 
 recently started caused issues with SCSI scanners.
 By the help of the hal-developers I found a workaround that might require a 
 certain extension to really work reliably.
 
 Therefore I'd like to know whether there is a chance to find from the sources 
 (i. e. a specific variable there) whether a scanner announces itself 
 as processor, as scanner or as something else. This depends on the 
 scsi.type that can be found in the device's bios.
 
 Any help would be greatly appreciated.

I think there is no other way than to look into the source code of
backends for SCSI scanners... IIRC only some Epson and HP scanners
present themselves as processors, all others say that they are of type
scanner. You can look if a backend checks for the SCSI device type
after having issued the INQUIRY command, or you can look in the
sane_start function. If the backend issues the SCSI commands 0x1b (start
scan) and 0x24 (set window), chances are goog that the device resents
itself as a scanner, not a processor.

But as I understand it, you need a list of SCSI vendor/model name
strings for HAL (or udev?) to configure some rules which devices should
be directly accessible for users. The most simple approach would be to
parse all *.desc files. This way you will not only get processor type
devices but also all those SCSI scanners that have the SCSI type
scanner, but the list is not too long, I think. And I don't think that
SCSI scanners are any longer manufactured, so we have quite stable list
of these devices.

Abel

[sane-devel] help with improving text scans

[abel deuring]

On 20.12.2008 23:15, Jeffrey Ratcliffe wrote:
 2008/12/20 abel deuring adeuring at gmx.net:
 Just open sane's .mo file with gettext :) (OK, I'm more involved with
 the competition -- Python --, so I don't know if a gettext
 implementation for Perl exists, but I would be really suprised if it
 doesn't.)
 
 Locale::gettext is the Perl module, which gscan2pdf uses for its own
 localisation.
 
 #!/usr/bin/perl
 use warnings;
 use strict;
 use Locale::gettext;
 use POSIX; # Needed for setlocale()
 setlocale(LC_MESSAGES, );
 my $d = Locale::gettext-domain(sane-backends);
 print $d-get(Preview), \n;
 
 works.
 
 What I really meant is that scanimage doesn't seem to use SANE's
 translations, which makes it difficult to provide a consistent
 interface for the different frontends scanimage/scanadf/libsane-perl.

Ah, I missed that point.

 
 But you are right - I can get the English strings from scanimage, and
 feed them through gettext. Unfortunately scanimage --help only gives
 the option titles for the groups.
 
 Can the backends be induced to give the option titles in some debug mode?

Well, since you have now libsane-perl -- do you really need to call
scanimage or scanadf from gscan2pdf anymore ;) ?

Abel

[sane-devel] help with improving text scans

[abel deuring]

On 20.12.2008 17:05, Jeffrey Ratcliffe wrote:
 2008/12/20 m. allan noah kitno455 at gmail.com:
 Having written Perl bindings for SANE, I will be able to do a more
 general interface, but please file the bug on Sourceforge or against
 the Debian package in the mean time.
 
 Now I remember the other problem with a general interface -
 internationalisation. scanimage, for instance, doesn't seem to have
 been translated:
 
 LANGUAGE=de scanimage --help
 
 produces English output.
 
 If I look in saneopts.h, the macro SANE_I18N is used for all the
 titles, but how do I get at the translations?

Just open sane's .mo file with gettext :) (OK, I'm more involved with
the competition -- Python --, so I don't know if a gettext
implementation for Perl exists, but I would be really suprised if it
doesn't.)

Abel

[sane-devel] Perl Bindings

[abel deuring]

On 02.09.2008 07:25, Jeffrey Ratcliffe wrote:
 2008/9/1 abel deuring adeuring at gmx.net:
 The test backend is a invaluably useful tool for testing: You get more
 or less any sort of device options; you can see if your bindings
 properly handle things like enabling/disabling of options, if you get
 the type conversion between Sane and Perl data types properly done etc etc.

 You even get perfectly reproducible, noise free, scan data :)
 
 Excellent. I'll use that.
 
 Additional tests with real-world devices are also useful, because the
 
 Sure, but I can only test it with mine :-)

Of course -- nobody expects that you'll be able to test your code with
ten different scanners :)

 
 Is there a good reason why pkg-config files aren't built with SANE?
 The lack of them make dependency checking difficult before build-time.

I think nobody yet bothered about that.

 
 If I work up a patch to add them is it likely to be accepted?

I would not mind seeing Perl bindings included. But other Sane folks
should give their opinion too. I could imagine that CPAN might be a
better place for the bindings, since Perl developers might look for Perl
modules there, I'd guess. (disclaimer: I am not a Perl developer, so I
can't claim to have any real clue where/how to search for Perl modules...)

Abel

[sane-devel] Perl Bindings

[abel deuring]

On 01.09.2008 10:56, Jeffrey Ratcliffe wrote:
 I am in the process of writing some Perl bindings for SANE.
 
 Would you like this to be a part of the SANE project, or should I
 start a new project (probably on Alioth)?
 
 It is tricky testing things, given the necessity for the correct
 hardware. How does SANE handle tests?

Im am not aware of any formal test requirements.

The test backend is a invaluably useful tool for testing: You get more
or less any sort of device options; you can see if your bindings
properly handle things like enabling/disabling of options, if you get
the type conversion between Sane and Perl data types properly done etc etc.

You even get perfectly reproducible, noise free, scan data :)

Additional tests with real-world devices are also useful, because the
test backend can of course not emulate the behaviour of every scanner.
The Python bindings for Sane (part of PIL) for example had for years a
bug in the higher components that prevented the retrieval of the
backside image from duplex scanners, because sane_cancel was
automatically called after an image was completely read.

Abel

[sane-devel] Python bindings segfault

[abel deuring]

On 15.06.2008 14:56, Albert Cervera i Areny wrote:
 While testing sane python bindings I found a segmentation fault while trying 
 to open the device. I attach a couple of logs. 
 
 'sane.log' is the output of running:
 SANE_DEBUG_HP5590=50 SANE_DEBUG_SANEI_USB=255 ./test-sane.py
 
 'valgrind.log' is the output of running my test script 
 with valgrind --trace-children=yes
 
 The script is very simple (the device exists):
 
 import sane
 sane.init()
 sane.open( 'hp5590:libusb:004:005' )

Am I right that this is the complete Pytjon code leading to the segfault?

 
 This is running Debian unstable with the following packages:
 python-imaging-sane 1.1.6
 sane 1.0.14
 libsane 1.0.19
 plus -deb packages, as as you can see in valgrind.log
 
 Do you think this is a Debian specific problem, any other tests I could make?

Unfortunately, the C extension _sane.so does not automatically ensure
the correct sequence of the calls sane_close() and sane_exit().
(sane_close should be called for all opened devices before sane_exit; if
sane_close is called after sane_exit, weird things may happen)

sane_close isn't even called automatically -- you must do that explicitly.

Could you try something like

import sane
sane.init()
device = sane.open( 'hp5590:libusb:004:005' )
device.close()

If this does not help, can you send me gdb's bt output?

Abel

PS: This requirement to explicitly call device.close() bothers me since
years, but I never got of my ass to write a more pythonic
implementation of _sane.c ...

[sane-devel] Question on scanimage -f

[abel deuring]

On 23.05.2008 20:45, Dieter Jurzitza wrote:
 Dear listmembers,
 having two scanners attached to my system I get calling scanimage -L
 SCANNER1
 SCANNER2
 
 choosing the appropriate command sequence with scanimage -f I can get the 
 very 
 same result, except it looks like
 SCANNER1SCANNER2
 
 is there any hidden way to force scanimage -f commandset to put it's 
 entries into separate lines so you can easily grep for a certain scanner? I 
 can do some sed-tweaking, but it is much more cumbersome than if I had all in 
 two separate lines.
 
 Maybe I overlooked something, but adding a \n does not work.

Simply write something like

scanimage -f %i %d


i.e., use quotation marks and put the second quotation mark into a new
line :) That should work at least for bash.

Abel

[sane-devel] HAL and scanners.

[abel deuring]

On 19.03.2008 14:24, Johannes Meixner wrote:

 Though this might also be a bit dangerous: The callout should
 not touch any backends for devices that are for example
 accessible via ethernet.
 
 Could you explain what you mean?

What I mean is that dll.conf entires for backends for network scanners,
for the net backend and for the test backend should not be automatically
removed by such a tool.

Abel

[sane-devel] HAL and scanners.

[abel deuring]

Hi all,

On 18.03.2008 16:03, m. allan noah wrote:
 On Tue, Mar 18, 2008 at 10:24 AM, ?tienne Bersac bersace03 at gmail.com 
 wrote:
 Hi,

  In january 2007, happened a very good discussion this list about SANE
  and HAL wich led to shipping a basic fdi.
  
 http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018343.html.

  Currently, sane-desc generate a very basic fdi which only badge device
  as scanner and add a property scanner.access_method hardcoded to
  proprietary, the latter is pretty useless ;)

  Please keep in mind that supporting HAL does NOT mean depending on HAL
  nor breaking API.


  Abel Deuring did a very nice job on sane-fdi, a parser for .desc file
  that provide much useful information right in the fdi. Sadly, the
  discussion stopped without a lot of success. I updated the sane-fdi
  script from Abel following the advice from Abel and Johannes Meixner.

  A device rule looks like :

   device
 match key=usb.vendor_id int=0x04a9
   match key=usb.product_id int=0x2207
 append key=info.capabilities type=strlistscanner/append
 append key=scanner.api type=strlistsane/append
 append key=scanner.sane.model type=strlistCanon CanoScan 
 N1220U/append
 append key=scanner.sane.backends type=strlistplustek/append
 append key=scanner.sane.backends.plustek.supportstatus 
 type=strlistcomplete/append
 append key=scanner.sane.backends.plustek.comment 
 type=strlistIdentical to UMAX 3400/append
   /match
 /match
   /device

  The updated sane-fdi script is available at
  http://bersace03.free.fr/pub/Development/Scanner/sane-fdi .
 
 i've not looked at this code yet, but the output above seems reasonable.
 
  There is still one thing needed to get full HAL support by SANE, build
  the SANE device name from those infos.

  One goal would be to allow frontend to provide an entry for each backend
  allowing user to select the backend to use. Using e.g. Cannon CanoScan
  N1220U (complete support with plustek driver) along Canon CanoScan
  N1220U (complete support with umax driver) will allow user to easily
  select driver.

  According to discussion about HAL and SANE last year, seems that the
  udi:backend:udi would be the solution for SANE to support HAL
  (without depending on it). See
  
 http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018353.html 
 for details.
 
 ok, so lets assume that we have a new 'hal' meta backend to do some
 'magic'. when the dll backend is asked to open a device like
 'hal:udi:backend'. it will load the hal backend, and ask it to
 open 'udi:backend'. the hal backend will load 'backend', and ask
 it for a list of scanners it can find, and somehow pick the one that
 goes with the 'udi'.
 
 i am worried that the last step means that each backend will have to
 know how to translate udi's.

As I understand it, the main point of the discussion is to find a way
for HAL that allows HAL aware applications to access a specific
scanner; this could be either a scan button daemon or a Sane frontend,
or whatever else. HAL already has quite detailed knowledge about
devices; what is missing is basically either a specialized Sane-UDI or
another way to assign a Sane device string (like
fujitsu:libusb:005:003) to a specific device.

HAL knows already quite many details about devices, like USB bus/devide
numbers, SG device filenames and whatever else; the main problem is that
the Sane device names do not give a reliable indicator, which device (in
the HAL sense) belongs to a specific Sane device.

Instead of making Sane HAL-aware, we can also add a function like
sane_get_device_information to the Sane API that would return data like
USB bus and devices numbers, USB vendor/product IDs, the SCSI device
filename, SCSI vendor/product strings, SCSI host/bus/device/LUN numbers
similar things.

A HAL callout (this is a script called by hald for certain devices
either when the daemon starts or when a device has been hotplugged) can
then call sane_get_devices, call sane_get_device_information for each
Sane device and can this way decide, if a Sane device matches the
current HAL device. And if the HAL and Sane devices match, the callout
can add a property like scanner.sane.device_name to the HAL device,
which would store the Sane device name as returned by sane_get_devices.
This should be enough to allow HAL aware scan software to find and
access devices via Sane.

Abel

PS: sorry, I don't have that much time to spare at present, so consider
this more to be a backseat driver comment...

[sane-devel] HAL and scanners.

[abel deuring]

Hi all,

On 18.03.2008 17:15, ?tienne Bersac wrote:
 Hi,
 
 I answer both allan and abel in this mail.
 
 we can also add a function like sane_get_device_information to the
 Sane API that would return data like USB bus and devices numbers [?]
 
 A HAL callout can then call sane_get_devices, call
 sane_get_device_information for each Sane device and can this way
 decide, if a Sane device matches the current HAL device.
 
 So basically, we have have two solutions :
 
  1. a HAL callout + sane_get_device_informations()?
  2. a SANE meta backend
  3. extends the meaning of sane_open()
 
 I actually prefer the first since it imply less modification in SANE.
 
 Something good would be to avoid reloading all backends since HAL know
 which backends support the device. Something like
 sane_backend_get_devices would be very cool.

That is one step too far -- we should get an agreement about the basic
stuff first ;) But the HAL callout could also mess with dll.conf and
enable those backends that fit to a newly detected scanner. Though
this might also be a bit dangerous: The callout should not touch any
backends for devices that are for example accessible via ethernet.

 
 Which solution is the right ? Other solution are welcome ;) Please
 comment.

Without much thinking, I think one could also write a meta-backend using
a function like sane_get_device_information. But I'd prefer to leave the
legwork to a HAL callout.

Also, I think that it would not be too much work to implement the
function sane_get_device_informations (but remember: I'm talking about
work that I cannot promise to do myself...). If we allow backends to
return sorry, can't provide any device data -- and that is necessary
for example for the test backend --, we can in a first step add a dummy
function to all backends that simply returns SANE_STATUS_UNSUPPORTED.
Most newer scanners have a USB interface and most if not all related
Sane backends use the sanei_usb library to access the devices, hence it
would probably be sufficient to implement a function like
sanei_usb_device_info in sanei_usb, which can be called by the backends
in sane_get_device_informations. A similar common function can be
implemented in sanei_scsi.c.

I believe that the main challenge is to define the data to be returned
by sane_get_device_informations in such a way that it is useful at least
for USB and SCSI scanners, and hopefully also for IEEE1394 and parport
scanners -- on different platforms, with/without libusb usage etc.
[sorry, I'm going back to work without making any specific proposals...]

Abel

[sane-devel] The future of the SANE-Standard

[abel deuring]

On 21.12.2007 15:33, Alessandro Zummo wrote:
 On Fri, 21 Dec 2007 09:12:56 -0500
 m. allan noah kitno455 at gmail.com wrote:
 
 well, i wanted to minimize the changes to front-ends, other than
 dropping unknown frame types. also, this sets up a precedent for
 backends needing to have 'modes' where they support historical
 versions of the sane standard. in this case, that is not a problem,
 but in the future, it might be.

 are you proposing that we update every backend in sane with this
 function- because they are all going to get their minor version number
 bumped to 1, to match their new sonames...
 
  i'm just thinking about it, so it is not a proposal at this time.
 
  i have not yet checked the matter in the sane source but, if we add 
  the api call to dll.c and not in the backend, what will happen?
 
   a) segfault
   b) SANE_STATUS_NOT_SUPPORTED
 
  ?

I'd prefer such an enabler function to an enabler option. The latter
would cause lots of questions from naive users :)

Perhaps I missed something -- but reading the function init() in
backend/dll.c, I think that the dll backend returns
SANE_STATUS_NOT_SUPPORTED for functions which do not exist in the real
backend. The BeOS implementation is the only exception I could see, but
that should be easy to fix.

So, for dynanically linked backends, it should be fine to use a new
enabler function, which does not exist in 1.0.x backends.

Unfortunately, an enabler function, which is optional for backends,
would not work for statically linked backends. But are these used
anywhere? In other words: Couldn't we simply drop static linkage?

Abel

[sane-devel] (no subject)

[abel deuring]

On 06.11.2007 20:07, Mauricio Villamil wrote:
 Hello, 
 
 reading the SANE Docs, I found that it is possible to set up the 
 Environmental variable for a larger buffer size:
 
 SANE_SG_BUFFERSIZE, I have my RICOH_IS420 scanner hooked uo to Fedora core 6 
 and it is working well, I just want to set up the variable to a larger size 
 ,but I don't knoe how??, which files need editing ??


You can set environment variables from a shell, i.e., a command line
window and start a Sane frontend from the _same_ shell, like so:

export SANE_SG_BUFFERSIZE=131072
xsane

But if the scanner works fine, there should not be any need to do this.
This option is useful only in the case that a scanner stops the scan
head very often during a scan. Increasing the buffer size and thus
increasing the amount of data transferred for one read command can help
to reduce the number of such scan head stops. But I assume that a
document scanner like the IS420 does not show such scan head stops.

Abel

[sane-devel] scanimage: sane_start: Scanner cover is open

[abel deuring]

Hi Lars,

On 20.10.2007 20:31, Lars M?llendorf wrote:
 Hallo,
 
 since I updated from Kubuntu 6.06 to 7.10 running an SHARP JX330 SCSI 
 flatbed scanner with scanimage produces this error:
 
 $ scanimage --device-name='sharp:/dev/sg0' --source='Flatbed'out.pnm
 scanimage: sane_start: Scanner cover is open
 
 Indeed the scanner cover is open, because I try to scan a book, but this 
 used to be no problem.

Do you have an ADF or a transparency unit installed? At least the ADF is
probably able to detect if the cover is open. But you are right that an
ADF status information should not affect flatbed scans.

 
 If I scan with xscanimage, it finally works with open cover if I scan 
 with closed cover first. Here the output of
 SANE_DEBUG_XSCANIMAGE=4 xscanimage 2debug.log
 
 [sanei_debug] Setting debug level of xscanimage to 4.
 [xscanimage] main
 [xscanimage] xscanimage (version: 1.0.14, package: sane-frontends) starting
 [xscanimage] interface
 [sanei_debug] Setting debug level of xscanimage to 4.

Could you please make similar tests with SANE_DEBUG_SHARP=255 ?

 Unfortunately this workaround doesn't work with gscan2pdf. I also tried 
 to find a hardware workaround but I don't know
 how the scanner knows it is open. I thought there would be a little 
 stylus or switch that has to be pressed, but the one I found doesn't 
 work. I have no
 manual or technical information about the scanner.

I have the technical docs for this scanner, but I am at present moving
into a new flat and the docs are buried in some transport box :( So
apologies in advance if can't fix your problem very quickly...

Abel

[sane-devel] General question on C programming

[abel deuring]

On 17.10.2007 18:18, jazz_johnson at verizon.net wrote:

 THANKS. I somehow missed this point. I now see ibm.c includes ibm-scsi.c
 which explains how ibm.c sees the static funcctions in ibm-scsi.c
 
 I hope to soon have a driver supporting essential IS450 scanning functions.
 I've written structs and functions for most IS450 commands/data, but have not 
 yet added non-essential options to the SANE_OPTION_DESCRIPTORS array.
 
 Does the SANE API have a means of getting user input. My IS450DE has an 
 Endorser which can print a (19 char max) string on each sheet fed through the 
 ADF. So to implement this feature I need a way to let the User type in their 
 stamp, although I could read the stamp string from the configuration file.

You can use the string option.

 
 Also, I noticed that the API has a BUTTON type, but haven't seen any examples.
 The IS450 has a self-diagnostics, optical-adjustment and scanner maintenance 
 data features which I supposed I could use the BUTTON to implement, e.g. when 
 button is pressed run_self_diagnostics or run_optical_adjustment.

Yes, a button option is intended for such purposes. You can use a
read-only string option to display the test results.

 
 The IS450 also comes with an option IPU (Image Processing Unit) which mine 
 doesn't have. Basically, this is some firmware for image processing. I've 
 written structs for the IPU command/data, but haven't added it yet to 
 OPTIONS. Is there any advantage in having the scanner do image processing 
 instead of just returning raw scan data to the front end for further 
 processing? CPUs are a lot faster now than 10 years ago.
 In the same vein, the IS450 allows user definable dither patterns and gamma 
 tables to be uploaded to the scanner for use with the IPU firmware. So to add 
 such an OPTION would require some means of letting the user browse for their 
 custom dither patterns and gamma tables (which I've also deferred 
 implementing).

A string constraint string list (usually displayed as a drop-down list
by GUIs) allows the selection of such options.

 
 Also the IS450 allow setting its padding type (default: trucate to byte 
 boundary), bitorder, as well as byte order (1st to last  or last - 1st) for 
 its image data and also  packing of 4bits gray data. I suppose there is no 
 reason for the backend to play with these things.

Well, just use the settings which make the transformation into the
output format most convenient :) I am not sure, if it makes sense to
select the byte order for the scanner depending on the byte order of the
 the machine.

 
 
 The IS450 also supports up to 2 window identifiers in its window_data 
 structure, but the IS420 only supports 1:
 /* HS2P_WINDOW_DATA_FORMAT   */
 struct hs2p_window_data {   
SANE_Byte window_id;   
SANE_Byte auto_bit; 
/* {(ulx,uly), (brx,bry)} main scan region */ 
SANE_Byte xres[2];  
SANE_Byte yres[2];
SANE_Byte ulx[4];
SANE_Byte uly[4];
SANE_Byte width[4];
.
.
.
/* sub scan regions {(ulx,uly),(brx,bry)}[i] */
struct window_section sec[8];
 }


Is the IS450 a duplex scanner? In this case the first window would
probably describe the front side scan area, and the second window the
backside scan area. If my guess is right, use the same settings for both
windows.

 I don't understand what this is for. The other backends just  use one w_id.
 Also when the IPU is installed this scanner allows scanning sub sections of a 
 document (up to 4 for the IS450 and 6 for the IS420). So if you had a 
 document with mixed text, photos, etc., you could scan the photo in halftone 
 and the text in lineart, etc. I've not yet implented an OPTION to allow 
 defining more than one { (ulx,uly), (brx,bry) } scanning region. Would xsane 
 work with such a feature? Again, since my IS450 lacks an IPU this feature 
 isn't available and I haven't yet implemented it.

I'm afraid that most frontends will have problems to deal with multiple
windows :)

Abel

[sane-devel] saned does not work with 2.6.23-rc9

[abel deuring]

On 03.10.2007 10:27, Joerg Platte wrote:
 Hi,
 
 today I updated the kernel on my Debian stable box to vanilla 2.6.23-rc9 and 
 now, saned (version 1.0.14-2) is unable to find my scanner. Here is the 
 strace output of sane-find-scanner:
 
 open(/proc/scsi/scsi, O_RDONLY)   = 3
 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
 0xb7f52000
 read(3, Attached devices:\nHost: scsi0 Ch..., 1024) = 976
 read(3, , 1024)   = 0
 close(3)= 0
 munmap(0xb7f52000, 4096)= 0
 open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
 ioctl(3, SG_SET_TIMEOUT, 0xbf84a834)= 0
 ioctl(3, SG_GET_VERSION_NUM, 0x8062524) = 0
 ioctl(3, SG_GET_SCSI_ID, 0xbf84a7f0)= -1 ENOTTY (Inappropriate ioctl for 
 device)
 close(3)= 0
 
 Is there a patch available to fix sane?

It is very weird that the SG_GET_SCSI_ID ioctl does not work: Could you
check, if /dev/scanner -- should be a symlink -- indeed points to a
device file of some SCSI device (ideally, to the scanner's device file)?
And if so, do you see any suspicious output in /var/log/messages?
Finally, can you run sane-find-scaner with SANE_DEBUG_SANEI_SCSI=255 and
send us the output?

And which SCSI adapter and which adapter driver are you using?

Abel

[sane-devel] saned does not work with 2.6.23-rc9

[abel deuring]

On 03.10.2007 14:46, Joerg Platte wrote:
 Am Mittwoch, 3. Oktober 2007 schrieb abel deuring:
 Hi,
 
 It is very weird that the SG_GET_SCSI_ID ioctl does not work: Could you
 check, if /dev/scanner -- should be a symlink -- indeed points to a
 device file of some SCSI device (ideally, to the scanner's device file)?
 
 I wrote this udev rule to create /dev/scanner:
 SUBSYSTEMS==scsi, SYSFS{vendor}==SCANNER , OWNER=saned, 
 GROUP=jplatte, 
 MODE=660, NAME=scanner
 
 root at jako:~ ls -la /dev/scanner
 crw-rw 1 saned jplatte 254, 5 2007-10-03 14:37 /dev/scanner
 
 And if so, do you see any suspicious output in /var/log/messages?
 
 No.
 
 Finally, can you run sane-find-scaner with SANE_DEBUG_SANEI_SCSI=255 and
 send us the output?
 
 Here it is:
 root at jako:~ SANE_DEBUG_SANEI_SCSI=255  sane-find-scanner
 
   # sane-find-scanner will now attempt to detect your scanner. If the
   # result is different from what you expected, first make sure your
   # scanner is powered up and properly connected to your computer.
 
 [sanei_debug] Setting debug level of sanei_scsi to 255.

did not give me any clue, but you already found the cause of the problem
:) And since the host adapter driver did not see any devices, we can't
expect to get useful output.

 [sanei_debug] Setting debug level of sanei_scsi to 255.
 [sanei_scsi] sanei_scsi_find_devices: vendor=(null) model=(null) type=Scanner
 bus=0 chan=0 id=6 lun=0  num=5
[...]

 And which SCSI adapter and which adapter driver are you using?
 
 An old Symbios based card
 02:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26)
 
 with this driver:
 sym53c8xx  66964  0
 scsi_transport_spi 20864  1 sym53c8xx
 scsi_mod  122124  8 
 sg,sr_mod,st,sd_mod,osst,sym53c8xx,scsi_transport_spi,libata

Both driver and adapter are generally very reliable.

 
 After some reboots I discovered, that the scanner is recognized by 
 sane-add-scanner if it is turned on during system boot. It is not detected 
 after executing the following script to rescan all SCSI busses (I'm using 
 ata_piix, hence there is more than one SCSI bus):
 for device in /sys/class/scsi_host/host*/scan ; do
 echo 0 - -  $device
 done

Yes, if the scanner is not known to its host adapter driver, no
application will find it :) But it is nevertheless very weird that
_some_ SCSI related IOCTLs worked, but SG_GET_SCSI_ID failed, probably
for a stale device file.

 With this script the kernel detects the scanner according to /proc/scsi/scsi 
 and the device node is created:
 Host: scsi0 Channel: 00 Id: 06 Lun: 00
   Vendor: SCANNER  Model:  Rev: 2.02
   Type:   Scanner  ANSI  SCSI revision: 01 CCS
 
 but then sane-add-scanner is not able to find it. Looks more like a kernel 
 bug, because this script worked fine with older kernels.

right.

Abel

[sane-devel] saned does not work with 2.6.23-rc9

[abel deuring]

On 03.10.2007 17:26, Joerg Platte wrote:
 Am Mittwoch, 3. Oktober 2007 schrieb abel deuring:
 
   # sane-find-scanner will now attempt to detect your scanner. If the
   # result is different from what you expected, first make sure your
   # scanner is powered up and properly connected to your computer.

 [sanei_debug] Setting debug level of sanei_scsi to 255.
 did not give me any clue, but you already found the cause of the problem

 :) And since the host adapter driver did not see any devices, we can't

 expect to get useful output.
 
 But at tis point Linux found the scanner and created the device node and an 
 entry in /proc/scsi/scsi and the scanner is turned on and connected. With 
 previous kernels this was sufficient to actually use the scanner. 

OK, I misunderstood you.

 
 Yes, if the scanner is not known to its host adapter driver, no
 application will find it :) But it is nevertheless very weird that
 _some_ SCSI related IOCTLs worked, but SG_GET_SCSI_ID failed, probably
 for a stale device file.
 
 I don't think it is stale, looks more like it is not fully initialized. But 
 maybe the SCSI implementation of the scanner is buggy and recent kernels 
 trigger a bug. The scanner is a Mustek ScanExpress 12SP and I don't think 
 it is 100% SCSI compatible...

Well, this scanner might have some compatibility issues, but the
SG_GET_SCSI_ID ioctl asks basically for the same data as you can see in
/proc/scsi/scsi. Hence this ioctl should work, if the scanner is listed
in /proc/scsi/scsi. Looks more like a new bug in the SCSI system of the
Linux kernel.

 
 right.
 
 Hope, this bug will be fixed soon... I usually turn my scanner on when I need 
 it and not during system boot. 

As Allan already wrote, it might help to rmmod and modprobe the
sym53c8xx driver. Only a workaround, but after all, SCSI devices are not
detected automatically, so you need to invoke one or the other helper
program anyway, if your scanner is not powered on at boot time (which is
absolutely reasonable :).

 
 Thank you for your help!

you're welcome!

Abel

[sane-devel] HP ScanJet 4c - no b/w?

[abel deuring]

On 27.09.2007 01:53, m. allan noah wrote:
 yes- when i first started using sane, i wondered, what is this Linear
 T thing, but at this point we are stuck with it :)

I believe the name shows the original purpose of this mode: to scan
pages with Linear T scripts, a relatively unknown successor of Linear B,
http://en.wikipedia.org/wiki/Linear_b ;

Abel

[sane-devel] Astra 1220s freezes system

[abel deuring]

On 02.08.2007 12:47, B Thomas wrote:
 Hi,
 I am using Astra 1220 (scsi) with Debian/GNU Linux 4.0 (etch),
 kernel 2.6.22.1, and sane 1.0.18. After a couple of scans using
 xsane the scanner stops scanning often in the middle of a scan.
 xsane stops responding and eventually goes into uninteruptable
 sleep (state D). Often but not always the entire xserver freezes
 and I have to do a hard boot. The kernel spits out i/o error
 messages.

Thi sounds like a problem within the Linux kernel, most likely, with the
card driver...

 Any subsequent scsi command also goes to sleep 
 immediately. Even if the system is not hung, the xsane process
 can not be killed and starting a new one hangs it too.
 
 My scsi card is Domex 3191D. It uses passive termination and the
 scanner has two scsi ports, one of which is terminated,(the other
 has the cable).

A quote form an old posting to this list from Henning Meier-Geinitz
(http://lists.alioth.debian.org/pipermail/sane-devel/2003-June/007879.html):

 |  Adaptec AHA-1505/AHA-1542/AHA-2940
 |  ASUS SC200
 |  BusLogic BT958
 |  NCR/Symbios 53c400/53c400 ISA card
 |  Domex DTC3181E/L/LE (DTCT436/436P) ISA card
 
 The last two are very low level cards that come with SCSI scanners
 (e.g. Mustek ones). I wouldn't call them work without difficulty.
 While they can be made to work, they are slow and the driver tends to
 crash quite often.

I remember too quite a few problem reports for this Domex card.. You
could ask the maintainer of the kernel driver for this card for help,
but as a quick fix I'd recommend to buy a well-supported SCSI adapter
card. You can get quite useful second-hand cards on Ebay for perhaps
10-20 Dollar/Euro/... For example the Adaptec 2940 works fine, as well
as adapters with the Symbios 53c8xx chips.

Abel

[sane-devel] [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

[abel deuring]

Hi Julien

Julien BLACHE schrieb:
 abel deuring adeur...@gmx.net wrote:
 
 Hi,
 
 are you sure that the 32/64 bit problem is _not_ fixed for the
 read/write interface, but only for the ioctl? If so, we should indeed
 
 Yes; I've read the code in sg.c and in the ioctl compat layer, and
 sg.c doesn't do anything to fixup the 32/64bit issue.
 
 use the ioctl call in sanei_scsi. But if we do so, we should at the same
 time get rid of all the queue management. If you compare the Linux part
 of sanei_scsi with that for other operation systems, you will note that
 the code is much simpler, mostly due to the fact that these OSes all use
 
 Ohhh yes... that would greatly simplify sanei_scsi. It's been fun to
 workaround the async code to get the ioctl in sanei_scsi :]

;)

 a simple ioctl instead of the write/read logic. OK, this would also mean
 to change a bit more in sanei_scsi, especially it would mean that the
 check for the availability of the SG_IO ioctl would be moved from run
 time to compile time.
 
 I think we can even get rid of the old SG interface entirely. SG_IO
 exists in Linux 2.4 too, so it should be safe.

I must admit that I am one of these persons who cannot throw away
anything... But you are right: Doug Gilbert wrote the SG3 interface in
the late 90ies (IIRC, the first versions were available even for 2.2.x
kernels), so keeping the old interface would be useful for very few
people, if any.

 But I am quite surprised that your Microtek scanner is so much faster
 with the ioctl is than the current implementation. When Doug Gilbert had
 
 It can be due to changes in the microtek2 backend too. Honestly, I
 haven't bothered to check :)
 
 implemented command queuing for the SG driver, I noticed a considerable
 performance gain for the Sharp JX250 scanner. The latency between the
 end of a SCSI command and the start of the next command (from the
 viewpoint of the scanner) is lower, if the command has already been
 issued by the application, so the kernel can start the next command
 immediately, without a context switch to the application. On the other
 hand, this was at a time, when processors had clock speeds of 200 or 300
 MHz. With modern processors, the latency is small enough even if kernel
 level queueing is not used.
 
 The latency here seems low enough, and this machine is an SGI Indigo2
 R4400SC 200 MHz w/256 MB RAM and an asthmatic SCSI controller (under
 Linux, at least, because we don't have the specs ...)

The effects of longer latency times seem to depend heavily on the
scanner models. The Sharp JX250, a moderately fast model, probably with
only a tiny internal buffer, seems to suffer more than many other devices...

Abel

[sane-devel] [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

[abel deuring]

Hi Julien,

Julien BLACHE wrote:
 abel deuring adeur...@gmx.net wrote:
 
 Hi,
 
 I think we can even get rid of the old SG interface entirely. SG_IO
 exists in Linux 2.4 too, so it should be safe.
 I must admit that I am one of these persons who cannot throw away
 anything... But you are right: Doug Gilbert wrote the SG3 interface in
 the late 90ies (IIRC, the first versions were available even for 2.2.x
 kernels), so keeping the old interface would be useful for very few
 people, if any.
 
 According to http://sg.torque.net/sg/ SG3 was first released in a
 stable kernel with Linux 2.4.0 in 2001. It's unclear to me whether
 it's been available in Linux 2.2 before that. (are there really people
 here still running SANE on a 2.2 kernel ?)

It seems that my memory it not very well functioning ;) Perhaps there
were some some beta versions available earlier, but never mind.

 
 The latency here seems low enough, and this machine is an SGI Indigo2
 R4400SC 200 MHz w/256 MB RAM and an asthmatic SCSI controller (under
 Linux, at least, because we don't have the specs ...)
 The effects of longer latency times seem to depend heavily on the
 scanner models. The Sharp JX250, a moderately fast model, probably with
 only a tiny internal buffer, seems to suffer more than many other devices...
 
 It'd be nice to gather some feedback on my patch with a couple of
 different scanners, that'd set the record straight as far as latency
 goes :)

It could be that the JX250 is much more sensistive to latency problems
than other scanners... I'll test your patch during the next days (sorry,
I can't make at present a more precise and honest promise...). But I
already made some test scans with sane-backends 1.0.18 and a modified
sharp.conf file that disables queueing on the SG level: No performance
problems with a 1.6 GHZ Athlon mainboard and a SCSI controller for the
sym53c8xx driver. (I don't have a slower system available...)

Abel

[sane-devel] [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

[abel deuring]

Julien BLACHE wrote:
 BERTRAND Jo?l joel.bertr...@systella.fr wrote:
 
 Hi,
 
 I use a Snapscan 1236s with xsane on an i386 (K6-III/400, 256 MB,
 Adaptec 2940U, kernel 2.6.20.1) without any trouble. If I use the same
 scanner on an U2 (2xUltraSPARC-II/296 MHz, 2 GB, Happymeal-ESP, kernel
 2.6.21-rc7), sane-find-scanner does not find any scanner but this
 scanner is shown in /proc/scsi/scsi. Both stations run lenny.
 
 [Summary for sane-devel]
 This is the old Linux SG3 interface does not work in
 32/64bit mixed environments. The most recent reference to this
 problem I could find is the discussion that took place on sane-devel
 (and some other lists at the same time) back in early 2003.
 
 
 This bug made me dig a bit into this issue this afternoon; I don't
 remember reading any of that yet, so here is what I found:
 
  - sanei_scsi doesn't work using the Linux SG3 interface in 32/64bit
mixed environments
  - sg3-utils' sg_inq, which does something equivalent to what
sane-find-scanner does, that is sending SCSI INQUIRY commands, does
work
 
 As it turns out, sanei_scsi uses the asynchronous SG3 interface (using
 read/write calls on /dev/sgX), and sg3-utils now uses the SG_IO ioctl
 interface.
 
 The SG_IO ioctl benefits from the 32/64bit ioctl compatibility layer,
 hence sg3-utils has no problems in a 32/64bit mixed environment.
 
 
 So, in a nutshell, sanei_scsi needs to move to SG_IO instead of the
 current interface if we want to support the more and more common mixed
 environment case.
 
 
 Attached is a proof of concept patch, tested on a Microtek scanner
 (microtek2 backend); the scanner works like a charm with this code, it
 feels like it even goes faster than using the async interface on the
 same machine (with a 32bit kernel, last time I tried it took something
 like 10 minutes to scan an A4 page with the default settings on an idle
 machine, it's under 1 minute now).
 
 
 I am not entirely sure that my patch behaves properly when an error
 occurs; I don't know anything about sanei_scsi (well, didn't know
 anything until today), so if someone familiar with sanei_scsi could
 take a look, maybe we could fix this bug for good :-)
 
 (note: with the SG_IO ioctl, we're loosing command queuing to the
 scanner; doesn't look terribly important to me given how my test
 turned out ...)

Julien,

are you sure that the 32/64 bit problem is _not_ fixed for the
read/write interface, but only for the ioctl? If so, we should indeed
use the ioctl call in sanei_scsi. But if we do so, we should at the same
time get rid of all the queue management. If you compare the Linux part
of sanei_scsi with that for other operation systems, you will note that
the code is much simpler, mostly due to the fact that these OSes all use
a simple ioctl instead of the write/read logic. OK, this would also mean
to change a bit more in sanei_scsi, especially it would mean that the
check for the availability of the SG_IO ioctl would be moved from run
time to compile time.

But I am quite surprised that your Microtek scanner is so much faster
with the ioctl is than the current implementation. When Doug Gilbert had
implemented command queuing for the SG driver, I noticed a considerable
performance gain for the Sharp JX250 scanner. The latency between the
end of a SCSI command and the start of the next command (from the
viewpoint of the scanner) is lower, if the command has already been
issued by the application, so the kernel can start the next command
immediately, without a context switch to the application. On the other
hand, this was at a time, when processors had clock speeds of 200 or 300
MHz. With modern processors, the latency is small enough even if kernel
level queueing is not used.

Abel

[sane-devel] sending scanned image to a remote SANE server

[abel deuring]

Tom Miller wrote:

 I am plan to install the workstation with Linux OS and 
 install SANE on it.  This workstation with have a scanner
 attach to it.
 
 
 I will then scan an image from the workstation and direct it 
 through the network with some SCANIMAGE's network option
 to a remote Server that running SANE and put that scanned 
 image under /tmp/  directory.
 
 Is this possible?

In other words: you wan to run scanimage on the workstation;
scanimage writes the scanned data into a file, and this file shall
be located on the server.

Yes, this is possible: you can create, read, write, modify and
delete files on remote computers, provided that both machines are
properly configured. If the server is also a Linux/Unix machine, use
NFS (Network File System). Install the NFS server software on the
server, configure the NFS server and mount a server volume on the
workstation.

A good start to see how to do this is Olaf Kirch's Linux Network
Administrator Guide: http://tldp.org/LDP/nag/node140.html

Abel

PS: Your question is not strictly a Sane (or scanning in general)
question, but a question about about file system access via a
network; you may get more and better help on networked file system
access in other places

[sane-devel] MFP - Samsung SCX-4521F

[abel deuring]

Heiko Freundel wrote:
 abel deuring schrieb:
 But if you ask google for mfpport.ko, you'll get a lot
 of error reports, often in conjunction with Samsung devices, but no
 hint for useful patches, at least on the first 5 result pages.
 Yes, there are many questions, but no helpful answers.

Actually, I found a page that might help you, if your machine does
not use the parallel port, bu has a USB interface, because this
mfpport.ko module seems to be required only for parport devices:

http://hathawaymix.org/Weblog/2005-07-15


 This
 is an indication that mfpport.ko is a Samsung-specific kernel
 module, for which no source code is available. You could try to find
 this file somewhere in the Samsung driver package, and try to load
 it manually, but if there is any incompatibility with the Ubuntu
 kernel, this will not work.
   
 It is not in, there is just an libMFPPortPlugin.so

So the install package is even not complete -- weird.

   
 Samsung told me, the driver was not testet with Ubuntu.
 
 ...which they should state clearly on their website, in README files
 and in other places where people might check, if a device is
 supported under a specific operating system. Binary-only kernel
 modules are a really bad idea.
   
 You are right. Now I found it in the user manual. Who reads an user
 manual BEFORE buying an product. Even if they right something from linux
 support.  They just support Redhat, Mandrake, SuSe, Caldera, TurboLinux,
 Slackware.

Providing this information in the wrong place is even more weird...

 And we (the Sane project) should tell more clearly in the *desc
 files for external backends, if source code is available (at least
 partially), if the backend works only under Linux, or even only with
 very specific kernel versions...
   
 Maybe it's an stuppid question, but: If the Samsung-drivers work with
 the above mentioned distributions, isn't then the source code
 available?  I just phoned to Samsung, there I can't anticipate any help.**

Well, some persons at Samsung, or at some contractor company,
probably have the source code. But the question is, if they are
willing to release it. The Sane license does not require the free
distribution of the source code of external backends; moreover, a
kernel module is missing in your case, which is license-wise more
a question of legal compatibility with the Linux kernel, and AFAIK
 there is also no requirement to freely release the source code of
external kernel modules.

Abel

[sane-devel] MFP - Samsung SCX-4521F

[abel deuring]

Heiko Freundel wrote:
 Hi,
 
 for the above mentioned MultiFunktionPrinter Samsung provides an Linux
 driver which should work with sane. This was a main reason for deciding
 for that MFP. I tried to use it with Ubuntu 10.0, but without success.
 
 Samsung just wrote me, that the driver was not testet with Ubuntu :-(
 
  At http://www.sane-project.org I just found the information, that there
 is an untested version of the driver.

Where did you find this information? I just checked the page with
the list of scanners supported by the sane-backends package, and
could not find the word Samsung. Only on the list of external
backends mentions Samsung. Additionally, I searched the current
source code from the CVS -- and found the SCX-4521F only in the
files describing external backends.

 
 1. How can Samsung have an driver and the sane-project has not?

well, anybody, individuals as well as companies and other
organizations, are free to write Sane backends as they want to do
so. And nobody is forced to contribute a Sane backend to the
backend collection from the Sane project. Moreover, a manufacturer
like Samsung has the advantage to have easy access to relevant
programming information for the scanners (I don't know, if Samsung
provides this kind of information to independent developers).

The Sane project will have direct support for Samsung devices only
if somebody starts the work on a special backend, or if some
scanner/MFP device turns out to be easily supportable by an existing
backend.

 2. How can I get the untestet driver from the sane-project?

As written above: I'm afraid that there is no such driver/backend...

Abel

[sane-devel] MFP - Samsung SCX-4521F

[abel deuring]

Heiko Freundel wrote:

 The Sane project will have direct support for Samsung devices only
 if somebody starts the work on a special backend, or if some
 scanner/MFP device turns out to be easily supportable by an existing
 backend.
   
 I know, that Samsung can do that. But the driver doesn't work with
 Ubuntu 10.0. Samsung told me, that it wasn't tested with Ubuntu. Two
 days ago I asked with which distributions it was test. I'm still waiting
 for an answer.

Good luck...

 I don't have the knowledge for writting printer drivers, but if the
 driver works with other distributions, it shouldn't be that much change?
 Is there an for an beginner understandable howto which I can use do the
 changes by myself?

I found a binary-only package with Linux drivers on the Samsung
website. With such binary files, you can't do very much. Though your
problem might indeed be a minor one: most bugfix methods for Linux
assume that you can modify one or the other source file.

But if you tell a bit more about the problem, somebody on this list
might have a suggestion. (But keep in mind that most people reading
the mailing list do not feel responsible for other software
packages, especially those for which no source code is available...)

Abel

[sane-devel] MFP - Samsung SCX-4521F

[abel deuring]

Heiko Freundel wrote:

 It should work like this and the printer does.
 
 Ubuntu already installed Sane 1.0.14-1.
 
 I tried different things I found, like:
 http://www.elijahlofgren.com/ubuntu/#scx-4521f
 with no success.
 
 Trying to start xsane from shell shows the following message:
 insmod: can't read
 '/lib/modules/2.6.17-10-generic/kernel/drivers/mfpportctrl/mfpport.ko':
 No such file or directory
 Segmentation fault (core dumped)
 
 
 When I start the Samsung Unified Driver Configurator (which installs
 itself) and then click the scanner button, it closes, with the messages
 below.
 
 ~$ /opt/Samsung/mfp/bin/Configurator
 insmod: can't read
 '/lib/modules/2.6.17-10-generic/kernel/drivers/mfpportctrl/mfpport.ko':
 No such file or directory
 *** glibc detected *** /opt/Samsung/mfp/bin/Configurator: double free or
 corruption (!prev): 0x081c1258 ***
 === Backtrace: =
 /lib/tls/i686/cmov/libc.so.6[0xb74ad8bd]
 /lib/tls/i686/cmov/libc.so.6(__libc_free+0x84)[0xb74ada44]
 /usr/lib/libstdc++-libc6.2-2.so.3(__builtin_vec_delete+0x24)[0xb6baa464]
 /usr/lib/sane/libsane-samsung_scx4x21.so.1(init_mfp_port_control__4port+0x7f)[0xb6a6c62b]
 /usr/lib/sane/libsane-samsung_scx4x21.so.1(init_mfp_port_control__6device+0x16)[0xb6a6d11e]
 ...
 
 But I don't know, whether I need mfpport.ko or where I get it from.

grepping through the kernel sources for the word mfpport gives no
result. Neither are there any files with a name that matches
*mfpport*. But if you ask google for mfpport.ko, you'll get a lot
of error reports, often in conjunction with Samsung devices, but no
hint for useful patches, at least on the first 5 result pages. This
is an indication that mfpport.ko is a Samsung-specific kernel
module, for which no source code is available. You could try to find
this file somewhere in the Samsung driver package, and try to load
it manually, but if there is any incompatibility with the Ubuntu
kernel, this will not work.

 Samsung told me, the driver was not testet with Ubuntu.

...which they should state clearly on their website, in README files
and in other places where people might check, if a device is
supported under a specific operating system. Binary-only kernel
modules are a really bad idea.

And we (the Sane project) should tell more clearly in the *desc
files for external backends, if source code is available (at least
partially), if the backend works only under Linux, or even only with
very specific kernel versions...

Abel

[sane-devel] Kernel panic with Mustek scanner and aha1542 scsi card

[abel deuring]

JJL wrote:
 Hello,
 
 On a debian testing up to date, I'm triying to use a Mustek Paragon 600
 II CD connected to an Adaptec aha1542.
 But when I try scanimage -L I have a kernel panic. I found lot a
 informations on an old bug related to buffersize and sg module. But this
 one seems to be corrected for ages and every workaround described won't
 work for me.
 Note, this hardware was working well with a ubuntu dapper.
 
 The kernel panic is :
 Bad segment list supplied to aha1542.c (1,0)
 0: c0318000 5
 cptr c0342e00: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
 0Kernel panic - not syncing: Fod fight!
 
 Is there something I'm doing wrong ? or is it a regression ? where ?

Sounds indeed like a regression. Perhaps a sign that ISA cards are
meanwhile an endangered species ;) Since it is clearly a kernel /
adapter driver issue, I'd recommend to contact the author of the
aha154x driver.

Abel

[sane-devel] Well known option consensus

[abel deuring]

?tienne Bersac wrote:

   \section{Papersize}
 
   When using an Automatic Document Feeder, the user generally cannot
   preview. If the page being scanned is smaller than the maximum size
   supported by the hardware/backend, the frontend cannot determine
   the location of the document on the scan surface, and cannot limit
   the values of the scan area (tl-x/y and br-x/y) to match.
 
   If the backend implements options for the frontend user to set the
   paper size, the backend should limit the range of the scan area to 
   that defined by the paper. The scan area is then relative to paper
   origin, not scan surface origin.
 
   \begin{options}
 \option{paper-width}{\FIXED}{\MM}{Paper width.}
 \option{paper-height}{\FIXED}{\MM}{Paper height.}
   \end{options}


Now things become really tricky ;) Some Fujitsu ADF scanners (and
probably also devices from other manufacturers) have a so-called
overscan mode. In overscan mode, the scan window is larger than
the page size; for pixels outside tha page area, you get a
background colour (you can even select between white and black
background). This allows to detect and correct skewed scans and to
check the page size by analyzing the image.

So, stating that the scan window should not be larger than the page
size is not such a good idea...

It might be better if the backend tells the frontend, if scan window
coordinates are relative to the entire scan area or to the selected
page size.

Abel

[sane-devel] Well known option consensus

[abel deuring]

Allan,

 It might be better if the backend tells the frontend, if scan window
 coordinates are relative to the entire scan area or to the selected
 page size.

 
 abel- i tried this a few weeks ago with my 4120C2, and found that i also
 had to
 increase the paper size (lie to the scanner) to get it not to throw an
 error.
 
 can you check in your personal modification that you actually can set
 the br-x wider than paper-width? even if this is so, i bet you cannot
 set it very much higher. i think i can deal with this in backend- when
 overscan is set, i am going to add 16mm to your scan area dimensions
 anyway...


Yes and no... The following settings (for an A5 page, 148.5 mm x 210
mm)

[fujitsu] xres=300, tlx=0, brx=8512, pw=6993, maxx=10624
[fujitsu] yres=300, tly=0, bry=11435, ph=9923, maxy=40800


I get the background pixels at the top, at the right and at the
bottom of the image, but not on the left.


So I can set the image width larger than the page width, but in
order to get background pixels on the left side, the page width
value must be increased.

But back to the problem I have/had with Etienne's suggstion for the
relations between page size and scan window coordinates: It does
not make much sense to allow to set a scan window in overscan mode:
The backend should calculate the scan window settings automatically
from the page size, and disable the options tl-x, tl-y, br-x, br-y.
(Actually, Eikazo does that -- but I think this should be done by
the backend...)

Abel

[sane-devel] Well known option consensus

[abel deuring]

m. allan noah wrote:

  But back to the problem I have/had with Etienne's suggstion for the
  relations between page size and scan window coordinates: It does
  not make much sense to allow to set a scan window in overscan mode:
  The backend should calculate the scan window settings automatically
  from the page size, and disable the options tl-x, tl-y, br-x, br-y.

 No ! If a user want to scan only a portion of the paper, he must be able
 to set scan area, but as long as there is no scan surface, we use paper
 size as scan surface. That make sense !
 
 you missed the point here. we are talking about an overscan option, which
 causes the scanner to add space all around the scan, such that the back-
 ground shows thru.
 
 but i think a person might want to overscan and still have only a
 small area of the page (one of the corners?) i think i can work this
 out, and still be compatible with the text of our suggestion.

Since the level of page size and skew detection is quite low in
the scanners we're talking about, I think a backend does not need to
do much here: In overscan mode, the backend simply returns the image
of the document surrounded by easily distinguishable, typically
dark pixels; it is up to the frontend to detect the page borders
and rotation angle.

All this does not mean that the frontend cannot let the user select
a smaller scan window within the page area -- but the clipping of
the image must be done by the frontend.

Abel

[sane-devel] Well known option consensus

[abel deuring]

m. allan noah wrote:

 All this does not mean that the frontend cannot let the user select
 a smaller scan window within the page area -- but the clipping of
 the image must be done by the frontend.

 
 i agree completely other than the last sentence. it should be possible
 for the backend
 to let the user select overscan mode, and then adjust the scan
 area/papersize as needed
 to set tl-x/y 0,0 to the black area 16mm outside of the paper. i dont
 think this violates the
 spirit of the standard proposal, and it keeps overscan mode as similar
 to the other modes
 as possible. in fact, i think this is the right thing to do in sane1,
 given recent user complaints on this mailing list.

OK, misunderstanding cleared ;)

Perhaps we're beginning to discuss a far too special feature -- but
I would maintain nevertheless that it makes sense for a backend to
simply disable tl-x, br-x, tl-y, br-y in overscan mode, and that to
set the scan area automatically to a value that is somewhat larger
than the page size. After all, this would allow the backend to fix
the weird behaviour of the fi4210/5120 that the parameter page width
must be set to a wrong value: real page width + 32mm in overscan
mode, if one wants the dark background on the left side of the scan
area.

Abel

[sane-devel] failing make sane-backends-1.0.18; sanei_scsi question

[abel deuring]

Gerhard Jaeger wrote:

 So my guess is, that the (HAVE_SCSI_SG_H) path is used and the glibc
 headers have changed somehow. What's the glibc version on SuSE 10.2?
 Please call /lib/libc.so.6
 What do you mean with call? Anyway, HZ is defined somewhere in the
 kernel header files, and I don't think it is related to libc.
 
 callit means, do simply a /lib/libc.so.6 - call it from your shell
 like a real program to see, what's inside. I.e. on my SuSE10 it looks
 like:
 #~ /lib/libc.so.6
 GNU C Library stable release version 2.3.5 (20050802), by Roland McGrath et 
 al.

GNU C Library stable release version 2.5 (20061011), by Roland
McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 4.1.2 20061115 (prerelease) (SUSE Linux).
Compiled on a Linux 2.6.18 system on 2006-11-26.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
GNU libio by Per Bothner
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
NoVersion patch for broken glibc 2.0 binaries
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.

 Anyway could you guys please try and add the compiler.h only to the 
 HAVE_SCSI_SG_H path?
 Well, before making any real patch, the first thing I'd like to
 know is, if we have a special Suse 10.2 bug, or if something changed
 in the kernel headers...
 
 Hmmm - seems we need to check how they compile their glibc and which
 kernel-headers they use - I think Johannes is around and might could
 shade some light on that - maybe also on that resmgr stuff.

I think you spotted the cause in the diff file:

 BTW: they use the following patch:
 --- sanei/sanei_scsi.c.orig 2005-04-22 10:36:17.0 +0200
 +++ sanei/sanei_scsi.c  2006-07-04 10:16:49.0 +0200
 @@ -1273,7 +1273,7 @@
   disconnect... ;-( */
{
  int timeout;
 -timeout = sane_scsicmd_timeout * HZ;
 +timeout = sane_scsicmd_timeout * sysconf(_SC_CLK_TCK);
  ioctl (fd, SG_SET_TIMEOUT, timeout);
}
  #endif

Seems that the Suse folks did not trust the usage of the HZ macro
that much. IIRC, HZ gives something like the kernel-internal timer
resolution or similar, and specifiying this value outside a header
file make some sense.

Compiling sanei_scsi.c from sane-backends 1.1.18 with this patch
instead of the added #include line works fine.

Abel

[sane-devel] failing make sane-backends-1.0.18; sanei_scsi question

[abel deuring]

Julien Michielsen wrote:
 A couple of days ago I posted the message below. No one replied to it
 yet, so I may have been unclear, and I'll add a few sentences that may
 make my question clearer.
 Before upgrading my SuSE from 10.1 to 10.2 my Epson Perfection 2580
 fotoscan worked fine, and gave me good quality scans. I was unable to
 get it installed on SuSE 10.2, appearantly because (as written below) it
 could not read ../mfpportctrl/mfpport.ko.  Indeed no subdirectory
 ./mfpportctrl exists under /lib/../drivers. I am afraid to show my
 ignorance with this question, but yet:
 My system does not contain any scsi peripherals but stll appears to bomb
 on this sanei_scsi function. Points of error:
 -1 Warning
 sanei_scsi.c:781: warning: 'rsm_open_device' is deprecated (declared at
 /usr/include/resmgr.h:24)
 program-line 781: fd = rsm_open_device(file, O_RDWR);
 -2 Identical warning for line 1245
 progl 1245: fd = rsm_open_device(dev, O_RDWR | O_EXCL | O_NONBLOCK);
 -3 Error
 sanei_scsi.c:1276: error: 'HZ' undeclared (first use in this function)
 progl 1276:timeout = sane_scsicmd_timeout * HZ;
 
 I reported the failure of SuSE 10.2 to get my Epson working to the
 bug-list (jan. 1st) but did not get any reply. My knowledge (and
 interest ;-( ) are at a too low level to go much deeper into this. Would
 somebody be able to give me a hint how to get this installed and
 running? Bypassing the sanei_scsi-function will not be an option, I
 suppose.

Julien,

Seeing your mail, I too tried to compile Sane under Suse 10.2 -- and
got the same error message. HZ should be defined somewhere in the
kernel-related header files, and theoretically the right header
file should be included in sg.h , because HZ is used there too.

You can fix the error by adding the line

#include linux/compiler.h

to sanei/sanei_scsi.c, near line 89:

#if defined (HAVE_SCSI_SG_H)
# define USE LINUX_INTERFACE
#include linux/compiler.h
# include scsi/sg.h
#elif defined (HAVE__USR_SRC_LINUX_INCLUDE_SCSI_SG_H)
# define USE LINUX_INTERFACE
#include linux/compiler.h
# include /usr/src/linux/include/scsi/sg.h

(better add the line two times, as shown: I don't know, which
variant will be used on your system).

Out of curiosity, I compiled sane-backends 1.0.18 on Ubuntu 6.10 --
no problems there.

Suse 10.2 uses a slightly newer kernel version (2.6.18) than Ubuntu
6.10 (2.6.17). Does anybody know, if something serious changed in
the kernel related header files between these versions? Or is this
a problem specific for Suse 10.2?

Abel

[sane-devel] Sane and HAL

[abel deuring]

Hi Johannes,

 On Jan 4 19:32 abel deuring wrote (shortened):
  device
match key=usb.vendor_id int=0x043d
  match key=usb.product_id int=0x007c
append key=info.capabilities
type=strlistscanner/append
append key=scanner.vendor type=strlistLexmark/append
append key=scanner.model type=strlistX1140/append
append key=scanner.api type=strlistsane/append
append key=scanner.sane.backend
type=strlistlexmark/append
append key=scanner.sane.supportstatus
type=strlistuntested/append
merge key=scanner.sane.is_supported
   type=booltrue/merge
  /match
/match
  /device
 
 I see some problems:

right, now things are starting to become intersting ;)

 1) vendor and model strings:
 
 According to epkowa.desc the Epson Perfection 600 is a
 rebadged UMAX Astra 1200S so that the lshal entries would be
   scanner.model = {'Perfection 600', 'Astra 1200S'}
   scanner.vendor = {'Epson', 'UMAX'}
 
 But now it is not clear for an application which gets this values
 which model belongs to which vendor - or can the application really
 rely on the ordering?

I was too not 100% sure, if we can rely on the order of entries in
string lists, so that we can correlate the entries from two lists
by their indexes. Need to ask that on the HAL mailing list. But
let's assume for now that we can rely on the order.

 For example alphabetical sorting (which is often done somehow
 automatically when lists of strings are processed) results:
   scanner.model = {'Astra 1200S', 'Perfection 600'}
   scanner.vendor = {'Epson', 'UMAX'}

yes, this would indeed be nonsense ;)

 
 As usb.vendor_id and usb.product_id are used for unique device
 discovey and unique device identification, there is no need
 to keep the human readable strings for vendor and model seperated
 and one single scanner.model entry which contains also the vendor
 name in its values should be sufficient so that it would be
   scanner.model = {'Epson Perfection 600', 'UMAX Astra 1200S'}

One string for vendor/model is indeed fine, if it is used only for
user information, and if a user-visible list of such entries is
short enough, i.e., if this string is not used to build a list
like that for the printer configuration with hundreds of entries.
For the latter, the typical grouping of the models by vendor is
convenient. Admittedly, I don't see that such lists are a real
option for HAL, but I am not yet convinced that we should use the
same string for vendor/model. Additionally, we can get some
information about a device with a HAL callout, including the vendor
and model name as detected by Sane backends (struct SANE_Device),
and separate fields for for these values in the HAL database makes
it easier to find the matching data.

 2) support status:
 
 The support status depends on the individual backend (the status
 in the desc files is below the backend in the hierarchy).
 Therefore it should be scanner.sane.backend-name.supportstatus
 where backend-name is one of the values in scanner.sane.backend.
 And then there seems to be no need for a strlist because one
 might think that for each backend there can be only one support
 status for one usb.vendor_id and usb.product_id but unfortunately
 this is not true, see the example below for the
 Epson Perfection 1250 (Photo).

I intended supportstatus to be a string list of the same length as
the backend list, and the entries of both lists should correlate the
same way as the vendor and model lists. But anyway, a
sub-sub-namespace for each backend works too, and makes things
perhaps easier. But I think that these namespaces should get a
prefix, like scanner.sane.backend_backend-name.supportstatus .
Using only the backend names is a bit uncontrollable, I think.

 
 I think scanner.sane.is_supported is redundant because
 one could simply use the special backend name unsupported
 for the scanners in unsupported.desc. I think there is no need
 for a special processing for unsupported.desc, simply process
 it as any other desc file and leave it for the applications
 what they like to do with the information.

Right, is_supported is redundant. The key scanner.api should get the
value sane if and only if at least one backend supports the
device. If this is case, the sub-namespace scanner.sane is
populated, otherwise it is left empty.

 3) comments:
 
 Additionally it might be useful to have also the comment
from the desc files in the fdi file as
 scanner.sane.backend-name.comment
 so that the user can be informed.

OK; let's add the comments, at least those for individual devices.

 Example:
 
 Now a nice example which shows that it becomes all messed up
 if it is not unique (e.g. multiple model names and multiple
 backends).

Indeed a good choice ;)

 It is for the Epson Perfection 1250 (Photo) / GT-7200U
 which I made from the epkowa.desc and plustek.desc files, see
 http://www.sane-project.org/cgi-bin/driver.pl?v=04b8p=010f

[sane-devel] Sane and HAL

[abel deuring]

Hi Johannes,
 Hello,
 
 On Jan 3 20:40 abel deuring wrote (shortened):
https://bugzilla.novell.com/show_bug.cgi?id=160899#c20
So the Suse team is already doing basically the same as I proposed.
Seems that I am a bit too late ;) But I think it makes sense to add
information like the sane backend(s) that are useful for a
specific scanner to the data in the fdi file.
 
 Of course you are not late because currently all what we do

I was just joking ;)

 is to use udev-HAL-resmgr to set access permissions.
 For this it is currently sufficient for us to mark
 a HAL device as a scanner.
 
 What is needed for the future is an agreement which HAL keys
 with which possible values must/should/can be added to a HAL
 device which is a scanner so that applications know which keys
 they must/should/can query and which values HAL may return.

Indeed. Sorry, I should have mentioned the following earlier in this
list: I started already a discussion about useful keys on the HAL
list. The result so far would give an entry for a scanner in the fdi
file like so:

  device
match key=usb.vendor_id int=0x043d
  match key=usb.product_id int=0x007c
append key=info.capabilities
type=strlistscanner/append
append key=scanner.vendor type=strlistLexmark/append
append key=scanner.model type=strlistX1140/append
append key=scanner.api type=strlistsane/append
append key=scanner.sane.backend
type=strlistlexmark/append
append key=scanner.sane.supportstatus
type=strlistuntested/append
merge key=scanner.sane.is_supported
   type=booltrue/merge
  /match
/match
  /device

scanner.vendor and scanner.model are obvious, I think;
scanner.api is intended to allow for other APIs than Sane;
scanner.sane is a sub-namespace for Sane;
scanner.sane.backend lists, well, backends for this scanner
scanner.sane.is_supported is set to false for the devices in
unsupported.desc

As you see, most keys can have multiple values; this is hard to
avoid, because we have several cases, where different scanners share
the same ID. If we want to reduce this for a real entry, we will
need a HAL callout that lets the backend open the device.

The scanner.sane.backend key is a strlist to allow things as you
mention at the end of your mail: For some scanners, more than one
backend may be available. And if a user installs, as is your
example, iscan and the backends of the Sane project, we can assume
that s/he wants to have the option to select these backends. In this
case, a frontend must simply ask the user, which is the right one ;)

With this data, the output from lshal (i.e., everything HAL knows
about the scanner) looks like this (some line breaks added by the
mail client):

udi = '/org/freedesktop/Hal/devices/usb_device_4c5_10e0_noserial_if0'
  info.udi =
'/org/freedesktop/Hal/devices/usb_device_4c5_10e0_noserial_if0'
(string)
  scanner.sane.supportstatus = {'good'} (string list)
  scanner.sane.backend = {'fujitsu'} (string list)
  scanner.sane.is_supported = true  (bool)
  scanner.api = {'sane'} (string list)
  scanner.model = {'fi-5120C'} (string list)
  scanner.vendor = {'Fujitsu'} (string list)
  info.capabilities = {'scanner'} (string list)
  linux.subsystem = 'usb'  (string)
  linux.hotplug_type = 1  (0x1)  (int)
  info.product = 'USB Vendor Specific Interface'  (string)
  usb.interface.protocol = 255  (0xff)  (int)
  usb.interface.subclass = 255  (0xff)  (int)
  usb.interface.class = 255  (0xff)  (int)
  usb.interface.number = 0  (0x0)  (int)
  usb.linux.sysfs_path =
'/sys/devices/pci:00/:00:07.2/usb1/1-1/1-1:1.0'  (string)
  usb.configuration_value = 1  (0x1)  (int)
  usb.num_configurations = 1  (0x1)  (int)
  usb.num_interfaces = 1  (0x1)  (int)
  usb.device_class = 0  (0x0)  (int)
  usb.device_subclass = 0  (0x0)  (int)
  usb.device_protocol = 0  (0x0)  (int)
  usb.vendor_id = 1221  (0x4c5)  (int)
  usb.product_id = 4320  (0x10e0)  (int)
  usb.vendor = 'Fujitsu, Ltd'  (string)
  usb.product = 'USB Vendor Specific Interface'  (string)
  usb.device_revision_bcd = 256  (0x100)  (int)
  usb.max_power = 98  (0x62)  (int)
  usb.num_ports = 0  (0x0)  (int)
  usb.linux.device_number = 2  (0x2)  (int)
  usb.speed_bcd = 4608  (0x1200)  (int)
  usb.version_bcd = 512  (0x200)  (int)
  usb.is_self_powered = true  (bool)
  usb.can_wake_up = false  (bool)
  usb.bus_number = 1  (0x1)  (int)
  info.bus = 'usb'  (string)
  info.parent =
'/org/freedesktop/Hal/devices/usb_device_4c5_10e0_noserial'  (string)
  linux.sysfs_path_device =
'/sys/devices/pci:00/:00:07.2/usb1/1-1/1-1:1.0'  (string)
  linux.sysfs_path =
'/sys/devices/pci:00/:00:07.2/usb1/1-1/1-1:1.0'  (string)

A simple solution would be to restart hald
 
 No! (As far as I know.)
 Reason:
 Stopping and restarting the comlpete HAL service may cause that
 all those zillions of actions are re-done which happened since
 HAL was running (e.g. umount and mount of whatever

[sane-devel] Sane and HAL

[abel deuring]

Hi,

Johannes Meixner wrote:
 We use HAL in Suse Linux 10.1 and in openSUSE 10.2 to set
 access permissions for normal users.
 In Suse Linux 10.1 only for USB scanners and in
 openSUSE 10.2 for USB and SCSI scanners.
 Therefore I have a tiny experience in taming the udev-HAL beast.
 
 What happens is:
 When a device becomes detected by the kernel and when there
 is a udev event (which doesn't happen in any case), then HAL
 is notified by udev and then HAL adds it to its device list
 so that it will be listed in the lshal output.
 Furthermore HAL looks up its fdi files if something special
 is to be done for this device.
 If an entry in a fdi file matches to how it is listed in the
 lshal output, HAL would do the action specified in the
 fdi file but again there are some (unexpected) constraints:
 For example HAL may kill a program which was started as the
 action specified in the fdi file after a short timeout
 (I guess to avoid too long delays).

If timeouts turns out to be a serious problem, we'll need to consult
the HAL developers. An optional timeout parameter for callouts might
fix it.

 
 
The minimum we can (and IMO should) do is to provide an XML file (or
.fdi file in HAL terminology) that describes the scanners
supported by Sane, and optionally the unsupported scanners.
 
 Have a look at
 https://bugzilla.novell.com/show_bug.cgi?id=160899
 in particular my bash script in
 https://bugzilla.novell.com/show_bug.cgi?id=160899#c20

So the Suse team is already doing basically the same as I proposed.
Seems that I am a bit too late ;) But I think it makes sense to add
information like the sane backend(s) that are useful for a
specific scanner to the data in the fdi file.

 For some already known problems have a look at
 https://bugzilla.novell.com/show_bug.cgi?id=218393#c19
 starting at comment #19

I think this is a HAL problem; hald might need some way to re-read
the fdi files, when it receives a signal.

 and
 https://bugzilla.novell.com/show_bug.cgi?id=226044
 The latter may be in particular useful to show an example
 how to debug a problematic case.

That's a problem with the SCSI bus: At least its simple variants, as
used by scanners, are not hotplugging-aware, so there is no way to
detect if a device is powered on or off. (BTW, better avoid to
(dis-)connect SCSI devices while any device on the bus is powered
on: this can destroy the driver transistors, no joke. And _never_ do
this with NCR5380 SCSI bus chips. For these chips, fortunately quite
old ones and today not often found in use, it is a safe bet that
they are broken after hotplugging ;)

A simple solution would be to restart hald from a script like
rescan-scsi-bus -- but some fully automatic automatic detection of
device removal/addition on a SCSI bus is not possible. But I think
this is not a big problem, because most of todays scanners are USB
devices.

... interested applications
can use this data to find a scanner and a suitable Sane backend and
launch for example xsane or access the scanner directly.
 
 This does not work if a special setup for firmware upload
 is required.
 Therefore a firmware related entry would also be needed in
 the desc files and the in the fdi file.

Adressing the firmware question(s) would indeed be the next step.
(Note: this is a backseat driver comment: I don't have any
scanners that need firmware files, and I don't intend to buy one and
to start work on supporting it ;)

 My personal opinion is that I do not like it when my computer
 launches whatever program it thinks to be useful for me
 automatically (perhaps I don't want to use any graphical
 frontend at all or I prefer xscanimage).

I agree -- but the automatic start of an application seems to become
quite fashionable: When I plug in a USB memory stick, KDE starts a
file browser.

 
 Furthermore it becomes tricky if more than one backend works
 for a particular model (e.g. epson versus epkowa backend).
 Perhaps it is o.k. to simply activate all matching backends
 but more than one backend might confuse an unexperienced user?

Right -- but this is also the case, if you start a Sane frontend
manually: If you have more than one scanner (or one scanner with
more than one backend), frontends either ask you, which
backend/device should be used (like xsane), or they use the first
one they find, like scanimage.

But if we have a unique combination of scanner and backend, HAL can
be used by a desktop enviroment to not bother the user with
unnecessary questions, when a scan program is started.

 
 
Another option would be another meta-backend named udi, but I
believe that this would be overkill.
 
 I think SANE should not depend on udev/HAL (i.e. it should
 still work even without any udev/HAL running or installed).
 Perhaps therefore another meta-backend named udi might be
 not a bad idea to keep the udev/HAL stuff strictly seperated?

Absolutely. Sane should not _depend_ on HAL, but it should IMHO
_support_ HAL. I was perhaps a bit terse: I wanted to suggest to 

[sane-devel] SANE2 commitment

[abel deuring]

Alessandro Zummo wrote:
 
  Hello developers,
 
since there seems to be interest in developing sane2, I've decided
  to start this thread in order to collect the commitment of each developer.
 
  I'm willing to port the epson driver to sane2, help porting the
  coolscan driver and handle the command line frontend. 
 
  I think Giuseppe Sacco has showed interest to do coolscan
  bits. 
 
  A friend of mine, Stefano Merlo, has committed himself
  to the canon driver.
 
  I'd appreciate if everyone who is interested can reply
  with their own commitments for the 2007.. ehm.. sane2 :)

Firstly, kudos to Alessandro for starting a new attempt to get Sane2
going.

Let's make sure that we don't get again an ugly exchange of
arguments like we had, ummm, seven (?) years ago, which eventually
froze the first attempt of a new version of Sane.

Unfortunately, I can't make at present an honest commitment for
contributions to Sane2 in the next year -- it is quite unclear how
much time I will have.

If I find time, I will work on the Sharp backend, on the sanei_scsi
library (well, mostly it's Linux part... I don't know enough about
the other platforms supported by Sane) and a Python library for Sane.

I agree with Martin and Etienne that device detection and desktop
integration should be improved, but I also think that we should keep
support for operating systems that don't have any HAL support. My
problem is that I don't know anything about HAL implementation in
Linux or elsewhere -- can anybody give me a pointer to an introduction?

Abel

[sane-devel] strange SCSI behaviour

[abel deuring]

Alessandro,

Perhaps I am missing the point, but here one SCSI command finished
with an error, and below another SCSI command is sent to the device.
 Can't you check for the error here and decide to wait? Or handle
 
  I added that check. The problem was that the first command
  only returned after a couple of mins.

Ah, I missed that: Thought that only the second command needed so
much time.

 
 
the sense data in another way? Admitted, the data of the sense
buffer is not very enlightening: UNIT ATTENTION does not tell very
much by itself, but you know which command caused the error, and the
documentation of the scanner may give a better clue what might have
happened.

Calling TEST UNIT READY before a real command is often also a good
way to avoid longer hangs.
 
  that worked! It seems calling it before the first command
  is enough. Do you think it should be called before every command?

Difficult to give a definite advice. Some Sane backends call TEST
UNIT READY for most if not all commands; others use this command
only quite seldom. Generally, it can't hurt to call TEST UNIT READY
for most SCSI commands. (more specifically, to have a loop in which
usleep() is called and TEST UNIT READY is sent, until either test
unit ready succeeds or the loop terminates/times out.) The
documentation for your scanner(s) might give a better hint, if or
where it is reasonable to call test unit ready.

An exception might be the read commands for the scan data:
Especially some older scanners have quite small internal buffers for
the scan data, and the additional delay from the TEST UNIT READY
commands might cause this buffer to become full, in turn causing
scan heads stops. On the other hand, the last time I have seen scan
head stops with my scanners was some years ago, when processor
speeds were far below 1 GHz.

Abel

[sane-devel] strange SCSI behaviour

[abel deuring]

Alessandro,

I just discovered the problem I had with my FilmScan 200
  is not related to any particular command but just to the
  first one sent to the scanner (just after modprobe)
 
   After that one, which receives a sense condition, everything
  works perfectly.
 
   So, if there's a way to have the control immediately returned
  to the driver as soon as the sense condition is issued, I would
  just try reissuing the command and that should fix my problem.
 
   Any hint on how to do that?
 
  thanks!
 
 [epson2] inquiry: EPSON   FilmScan 2001.01
 [epson2] model  : FilmScan 2001.01
 [epson2] reset
 [epson2] epson_cmd_simple: size = 2
 [epson2] epson_send: ESC @
 [sanei_scsi] scsi_req_enter: entered 0xb7c75008
 [sanei_scsi] sanei_scsi.issue: 0xb7c75008
 [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 1
 [sanei_scsi] sanei_scsi_req_wait: waiting for 0xb7c75008
 [sanei_scsi] sanei_scsi.issue: 0xb7c75008
 [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
 [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
 [sanei_scsi] sense buffer: 70 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00
 [sanei_scsi] target status: 02 host status:  driver status: 0008
 [sanei_scsi] sanei_scsi_req_wait: SG driver returned resid 2
 [sanei_scsi]  NOTE: This value may be bogus
 [sanei_scsi] scsi_req_enter: entered 0xb7c75008
 [sanei_scsi] sanei_scsi.issue: 0xb7c75008

Perhaps I am missing the point, but here one SCSI command finished
with an error, and below another SCSI command is sent to the device.
 Can't you check for the error here and decide to wait? Or handle
the sense data in another way? Admitted, the data of the sense
buffer is not very enlightening: UNIT ATTENTION does not tell very
much by itself, but you know which command caused the error, and the
documentation of the scanner may give a better clue what might have
happened.

Calling TEST UNIT READY before a real command is often also a good
way to avoid longer hangs.

Abel

 [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 1
 [sanei_scsi] sanei_scsi_req_wait: waiting for 0xb7c75008
 [sanei_scsi] sanei_scsi.issue: 0xb7c75008
 
  [~2 min delay here, the the aic7xxx driver queues an ABORT and the scanner 
 resets ]
 
 [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
 [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
 [sanei_scsi] sense buffer: 70 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00
 [sanei_scsi] target status: 00 host status: 0001 driver status: 
 [sanei_scsi] sanei_scsi_req_wait: SG driver returned resid 1
 [sanei_scsi]  NOTE: This value may be bogus
 [epson2] epson_recv: expected = 1, got = 0
 [epson2] epson_cmd_simple: failed, Device busy
 
  this command has failed, but subsequent ones work
  correctly.   
 

[sane-devel] proposed changes to Python's / PIL Sane module

[abel deuring]

Hi all,

For those of you interested in using Sane from Python, but who are
not reading the Python image-sig mailing list, a quick heads-up:

I wrote a patch for PIL's Sane module that allows access to array
options, i.e., those options that have more than one value, like
gamma tables:

http://mail.python.org/pipermail/image-sig/2006-September/004133.html

While I am sure that this patch is useful, it may introduce
incompatibilities with existing applications -- its not very likely,
but I can't be sure, of course.

Abel

[sane-devel] [ANN] new Sane frontend

[abel deuring]

I have started work on Eikazo, a new Sane frontend
(http://eikazo.berlios.de). It focuses on mass scans, especially
with ADF scanners -- it is not intended to compete with XSane or
Kooka with their quite elaborate functions.

Some Eikazo features:

  - To maximize throughput for ADF scanners, a new scan is started,
while the previous scan is being processed and stored or
printed.
  - plugin mechanisms to support special device features, image
processing and output modules.

Currently, plugins exist for:
  o image rotation (If a duplex ADF scanner is used, different
rotation angles can be selected for frontside and backside)
duplex scanners)
  o automatic thresholding
  o dirt removal
  o support for some speical features of the Fujitsu fi4120 and
fi5120 scanners

  - Scanned images can be saved to a file and optionally
simultaneously printed (print only if course possible too).

  - scan parameters can be saved in an SQL database (MySQL and
PostgreSQL are supported). This option is probably not very
useful in most cases; it is intended as an example, how output
functions can be customized.

Technically, the frontend is based on Python, GTK/PyGTK and the
Python Imaging Library.

Thanks especially to the authors of the test backend: it was
invaluable when developing the GUI: it's faster than any real
backend, allows to test all variants of Sane options -- and it
uncovered a bug in the Sane module of the Python Imaging Library.

The program is released under the GPL.

Abel

[sane-devel] Out of memory in sanei_scsi_cmd [was: Annoying Out of MEmory Error...]

[abel deuring]

Oliver,

 a user reported a problem with an Acer 620ST plugged into a Artop 
 Electronic Corp AEC6712D SCSI controller (atp870u driver). The system 
 causing problems is running linux-2.6.17-gentoo-r8, gcc 4.1.1 and 
 glibc-2.4, sane-backends-1.0.18.
 
 On this system the following error occurs:
 
 ...
 [snapscan] open_scanner
 [sanei_debug] Setting debug level of sanei_scsi to 255.
 [sanei_scsi] sanei_scsi_open: SG driver version: 30533
 [sanei_scsi] sanei_scsi_open_extended: using 131072 bytes as SCSI 
 buffer
 [sanei_scsi] trying to enable low level command queueing
 [sanei_scsi] sanei_scsi_open: Host adapter queue depth: 1
 [sanei_scsi] sanei_scsi_open: SG driver can change buffer size at run 
 time
 [sanei_scsi] sanei_scsi_open: using new SG header structure
 [snapscan] sane_snapscan_open: waiting for scanner to warm up.
 [snapscan] wait_scanner_ready
 ...
 [snapscan] send
 [snapscan] snapscan_cmd
 [sanei_scsi] scsi_req_enter: entered 0xb7c5e008
 [sanei_scsi] sanei_scsi.issue: 0xb7c5e008
 dev_max(currently)=32 max_active_device=1 (origin 1)
  def_reserved_size=32768
   device=sg0 scsi1 chan=0 id=2 lun=0   em=0 sg_tablesize=128 excl=1
FD(1): timeout=12ms bufflen=131072 (res)sgat=4 low_dma=0
cmd_q=1 f_packid=0 k_orphan=0 closed=0
  rb act: id=9 blen=1024 t_o/elap=12/8ms sgat=1 op=0x2a
 [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 1
 [sanei_scsi] sanei_scsi_req_wait: waiting for 0xb7c5e008
 [sanei_scsi] sanei_scsi.issue: 0xb7c5e008
 dev_max(currently)=32 max_active_device=1 (origin 1)
  def_reserved_size=32768
   device=sg0 scsi1 chan=0 id=2 lun=0   em=0 sg_tablesize=128 excl=1
FD(1): timeout=12ms bufflen=131072 (res)sgat=4 low_dma=0
cmd_q=1 f_packid=0 k_orphan=0 closed=0
  rb rcv: id=9 blen=1024 dur=108ms sgat=1 op=0x2a
 [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
 [snapscan] measure_transfer_rate: have ring buffer
 [snapscan] scsi_read
 [snapscan] snapscan_cmd
 [sanei_scsi] scsi_req_enter: entered 0xb7c5e008
 [sanei_scsi] sanei_scsi.issue: 0xb7c5e008
 dev_max(currently)=32 max_active_device=1 (origin 1)
  def_reserved_size=32768
   device=sg0 scsi1 chan=0 id=2 lun=0   em=0 sg_tablesize=128 excl=1
FD(1): timeout=12ms bufflen=131072 (res)sgat=4 low_dma=0
cmd_q=1 f_packid=0 k_orphan=0 closed=0
  No requests active
 [sanei_scsi] sanei_scsi.issue: bad write (errno=12) Cannot allocate 
 memory -1
 [sanei_scsi] sanei_scsi.issue: SG_BIG_BUF inconsistency? Check file 
 PROBLEMS.
 [sanei_scsi] scsi_req_enter: queue_used: 0, queue_max: 1
 [sanei_scsi] sanei_scsi_req_wait: waiting for 0xb7c5e008
 [sanei_scsi] sanei_scsi.issue: 0xb7c5e008
 [snapscan] scsi_read: snapscan_cmd command failed: Out of memory
 [snapscan] measure_transfer_rate: scsi_read command failed: Out of 
 memory
 [snapscan] sane_snapscan_start: measure_transfer_rate command failed: 
 Out of memory
 scanimage: sane_start: Out of memory
 ...
 
 As far as I can tell I'm issuing a sanei_scsi_cmd with a send buffer 
 of ten bytes and a receive buffer of 130176 bytes. Both should fit 
 into the SCSI buffer of 131072 bytes easily.

is 130176 a typo, or does the backend really wants to read 4 bytes
more than reserved? (or do I misunderstand something?) I could not
find the the number 130176 anywhere else.

This point aside, I don't have a really good hint, except that I
have the impression that the Linux atp870u driver is not the best
piece of code in the kernel. Maintainance of the driver was, at
least some time ago, a bit unclear. Moreover, another user recently
reported problems with this driver on the list; he could use his
scanner fine after replacing the adapter with a properly supported one.

 
 To make matters even stranger, the same SCSI card and scanner works 
 fine on 
 Ubuntu 6.06 LTS,
 kernel: 2.6.15-23-386
 gcc: GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
 glibc:2.3.6
 sane-backends: 1.0.17
 
 Does anybody of the experts have any idea what's going on?

not really -- but I believe that it would be best to ask on the
linux-scsi mailing list for help: To me, it looks like a problem of
the driver or perhaps the kernel. But it might be easier for the
user to simply replace the adapter with one supported by the aic7xxx
driver or the sym83c5xx driver. They are available for a few
Euro/Dollar on Ebay.

Abel

[sane-devel] xsane hpaio with ADF bug report and PATCH

[abel deuring]

Alex Eskin wrote:
 The attached one-line patch against xsane-0.991 is needed
 to get the automatic document feeder on my OfficeJet 5610
 to work with xsane. The problem is that xsane does not
 call sane_cancel after scanning a page from the ADF, and
 the page is then not properly ejected.

this is a bug in the backend, but not in xsane. The funny thing is
that the Python module for Sane in the Pythin Imaging Library had to
be fixed a few months ago so that sane_cancel is _not_ automatically
called after every scan. If a frontend calls sane_cancel after every
scan, it can't read the backside data from duplex scanners supported
at least by the avision backend. This backend (and probably others)
discard the buffered backside data from a duplex scan in the
sane_cancel call -- an absolutely reasonable and legitimate behaviour.

 scanimage already does the right thing and  works with my
 scanner. So I think the problem is with xsane. From looking
 at various mailing lists, it seems that it affects at least
 some of the other hpaio devices.

 Is this the right place to report this?

uhhh, yes and no ;) I don't know, if Oliver runs a separate mailing
list for XSane, but anyway: you should tell the hpaio developers
about the problem and ask them for a fix.

Abel

[sane-devel] grey 4bit/pixel

[abel deuring]

Shashi Kumar M.S. wrote:
 hi, 
  
 iam searching a scanner that supports at about 300 dpi and 4 bit /pixel grey 
 scanner. i found from the scanner that most of the scanner support 8/16 bit 
 depth in grey mode. 
  
 is there any way to modify this code to support 4 bit grey scale depth per 
 pixel. 

well, the source code of scanimage, xsane etc is freely available ;)

 all suggestions are welcome 

- look for a (documented) file format that supports 4 bit images (or
  define your own format ;)
- patch scanimage or another frontend so that it can write the scan
  data in the format you selected. Alternatively, you can convert
  existing 8 bit images, as produced by a Sane frontend, with a
  converter program. I am not aware of any 4 bit image formats, but
  if they exist, you might already find such a converter in the
  usual Linux distributions. Otherwise, write one. The PPM, PGM, PBM
  formats (default for scanimage output) are very simple, and it is
  quite straightforward to read them with C, Python, Perl, Java or
  whichever other programming language.

Abel

[sane-devel] Acard AEC6712S (atp870u.ko) and HP 6100C C2520A (sg.ko) problems

[abel deuring]

Justin Findlay wrote:
 I have an HP 6100C scanjet (I wonder why they call it a scanjet) anyway
 I have this scanner connected to an Acard SCSI PCI adapter.  When I load
 the driver module for the SCSI card (atp870u) this is what gets printed
 out in /var/log/kernel:
 
  atp870u: use 32bit DMA mask.
 ACARD AEC-671X PCI Ultra/W SCSI-2/3 Host Adapter: 0 IO:cc00, IRQ:20.
   ID:  2  HP  C2520A  3644
   ID:  7  Host Adapter
  scsi5 : ACARD AEC-6710/6712/67160 PCI Ultra/W/LVD SCSI-3 Adapter Driver 
 V2.6+ac
   atp870u: abort Channel = 0
  working=1 last_cmd=2  quhdu=1 quendu=1  r 0= 6 r 1=2c r 2=cf r 3=12 r 4= 0 r 
 5= 0 r 6= 0 r 7=24 r 8= 0 r 9= 0 r a= 0 r b= 0 r c= 0 r d= 0 r e= 0 r f= 0 
 r10=36 r11=20 r12= 0 r13= 0 r14= 8 r15= 2 r16=80 r17=42 r1c=a1 r1f=37 in_snd= 
 0  d00= 9 d02= 0
  working=1 last_cmd=2  quhdu=1 quendu=2  r 0= 6 r 1=2c r 2=cf r 3=12 r 4= 0 r 
 5= 0 r 6= 0 r 7=24 r 8= 0 r 9= 0 r a= 0 r b= 0 r c= 0 r d= 0 r e= 0 r f= 0 
 r10=36 r11=20 r12= 0 r13= 0 r14= 8 r15= 2 r16=80 r17=42 r1c=a1 r1f=37 in_snd= 
 0  d00= 9 d02= 0
   que cdb=   0   0   0   0   0   0  last_lenu= 24 6scsi 5:0:2:0: scsi: 
 Device offlined - not ready after error recovery
 
 So my question is whether the scanner is bad or the sg SCSI driver
 doesn't like the scanner or something else I'm not thinking of.

No idea, what exactly is going wrong. This message comes from the
atp870u driver; obviously something is broken at a very basic level.
The cause can be the scanner, the SCSI host adapter, the atp870u
driver -- or simply a bad SCSI cable or missing SCSI bus
termination. If you have other devices connected to the same SCSI
bus, they could be the cause of the problem too.

If possible, try different cables and another SCSI adapter, or
connect another SCSI device to the Acard adapter to get a better
idea, where the error might come from.

Abel

[sane-devel] Help with Canon 2700F

[abel deuring]

Lutz wrote:
 Am Mittwoch, 16. August 2006 18:58 schrieb abel deuring:
Lutz wrote:
to me, it looks like that the (working) Epson scanner gives much more
info than the canon does.
right: the Epson seems to be OK, while something is broken with the
FS2700, see below.

I already tried to debug (eclipse, cdt) the call - but I did not manage
to have the source included when init() is called - the closest I got to,
is that sense_handler in canon.c seems to be called with a null argument
- seen in the debug output too - but here the mess has happened already.
The null argument in the sense handler is OK. 
 sorry - but, no it is _not_.
 if you look at the sense_handler function in canon.c, it is quite clear, that 
 this sense_handler will return via the
 
else
 {
   sense_str = problem not analyzed (unknown SCSI class);
   // status = SANE_STATUS_IO_ERROR;
 }

ouch. yes, you are right. The problem is that this error occurs
quite early during the setup of the device structures. Perhaps you
can simply comment out this call of TEST UNIT READY.

Besides, you can grep for strings like 
attach: sending TEST_UNIT_READY in the sources files of the
backend; you should be able to quickly find the correct lines; here
you can add for example additional DBG calls.
 (...) 
The authors of the backend decided to not let the backend continue
to access the scanner in this case -- a reasonable decision. You
might though try to ignore this specific error and patch the backend
accordingly.
 I already did - and got a lamp-error - the scanner works just fine on w2k - 
 no 
 lamp error.

If you look at the sense buffer of the first error and at the
function sense_handler in the canon sources, you'll see that lamp
error is exactly the error you get in the first place. It seems
that the Windows driver simply ignores this error. You could patch
sense_handler to simply print a warning in case of a lamp error, but
to return SANE_STATUS_GOOD in this case. But you should expect a
somewhat degraded scan quality.

 
 following your suggestions I found the lines where the calling of the 
 sense_handler with the null argument originates - it is in sanei/sanei_scsi.c
 in function at line 251ff:
 
   SANEI_SCSI_Sense_Handler handler
 = fd_info[req-fd].sense_handler;
   void *arg = fd_info[req-fd].sense_handler_arg;
 -

right: If sanei_scsi_cmd discovers an error, it calls the sense
handler so that the backend can decide, what to do.

 I'm still on my way to find out where this structure gets initialized.

As already said: in the function attach.

Abel

[sane-devel] Help with Canon 2700F

[abel deuring]

Lutz wrote:

 now the scanner is seen by scanimage -L - 
 but it does not work - if I continue with Lamp error, I finally end up with a 
 command sequence error.

 ---
 and her comes the not so nice part
 ---
 [canon] sense category: hardware error
 [canon] sense message: lamp failure
 [canon]  sense_handler
 [canon]  scan
 [canon]  get_data_status
 [sanei_scsi] scsi_req_enter: entered 0x401ae008
 [sanei_scsi] sanei_scsi.issue: 0x401ae008
 [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 2
 [sanei_scsi] sanei_scsi_req_wait: waiting for 0x401ae008
 [sanei_scsi] sanei_scsi.issue: 0x401ae008
 [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
 [canon]  get_data_status
 [canon]  GET DATA STATUS
 [canon] Scan Data Available=0
 [canon] Magnified Width=1938
 [canon] Magnified Length=485
 [canon] Rest Data=0 bytes
 [canon] Filled Data Buffer=0
 [canon]  GET DATA STATUS
 [canon] 323 pixels per line, 969 bytes, 485 lines high, total 469965 bytes, 
 dpi=340
 [canon]  sane_start
 [dll] sane_get_parameters(handle=0x80534c8,params=0xbfffdd30)
 [canon]  sane_get_parameters
 [canon] sane_get_parameters: xres='340', yres='340', pixels_per_line='323', 
 bytes_per_line='969', lines='485'
 [canon]  sane_get_parameters
 P6
 # SANE data follows
 323 485
 255
 [dll] sane_read(handle=0x80534c8,data=0x8060f68,maxlen=32768,lenp=0xbfffdd0c)
 [canon]  sane_read
 [canon]sane_read: nread=32768, bytes_to_read=469965
 [canon]  read_data
 [sanei_scsi] scsi_req_enter: entered 0x401ae008
 [sanei_scsi] sanei_scsi.issue: 0x401ae008
 [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 2
 [sanei_scsi] sanei_scsi_req_wait: waiting for 0x401ae008
 [sanei_scsi] sanei_scsi.issue: 0x401ae008
 [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
 [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
 [sanei_scsi] sense buffer: f0 00 45 00 00 00 00 06 00 00 00 00 2c 00 00 00
 [sanei_scsi] target status: 02 host status:  driver status: 0008
 [canon]  sense_handler modified lutz
 [canon] canon_sense_handler(3, 0x401ae060, 0x80737e8)
 [canon] sense buffer: f0 00 45 00 00 00 00 06 00 00 00 00 2c 00 00 00
 [canon] sense data interpretation for SCSI-2 devices
 [canon] sense category: illegal request
 [canon] sense message: command sequence error
 [canon]  sense_handler
 [sanei_scsi] sanei_scsi_req_wait: SG driver returned resid 65536
 [sanei_scsi]  NOTE: This value may be bogus
 [canon]  read_data
 ---
 hmmm.
 Windows asks for the film to be removed and does an initialization of the 
 scanner on first use after reboot - may be, this is what it expects?
 
 any ideas which command this would be?

unfortunately, no idea... I even don't have an FS2700.

 
 (...)
I'm still on my way to find out where this structure gets initialized.
As already said: in the function attach.
 yes, but at the end of it - and after the call to test_unit_ready - at least 
 as I see it - which may be wrong. 

well, patch it ;) But keep in mind that the sense handler needs to
know the scanner model, so you can't use the sense handler before
that is defined in attach.

Abel

[sane-devel] Help with Canon 2700f

[abel deuring]

John Bird wrote:
 Hi,
 Thanks to all for the past assistance but I'm still having problems getting a 
 canon 2700f SCSI film scanner to work with SANE. I have tried the suggestions 
 offered so far but as sane-find-scanner still produces the following output.
 
 found SCSI scanner CANON IX-27015C 1.15 at /dev/sg0
   # Your SCSI scanner was detected. It may or may not be supported by SANE. 
 Try
   # scanimage -L and read the backend's manpage.
 
 found USB scanner (vendor=0x055f, product=0x021c [USB Scanner], chip=GT-6816) 
 at libusb:001:005
 found USB scanner (vendor=0x0bc7, product=0x0004) at libusb:001:004
   # Your USB scanner was (probably) detected. It may or may not be supported 
 by
   # SANE. Try scanimage -L and read the backend's manpage.
 
 but scanimage -L only produces the following 
 
 scanimage -L
 Password:
 device `gt68xx:libusb:001:005' is a Mustek Bearpaw 1200 CU Plus flatbed 
 scanner
 
 I think that the problem is the canon conf file so if anybody has one of 
 these 
 running on a Linux box will they please post theirs 
 
 Additional information (in case it is relevent)
 
 The files for the scanner are located in the following directory.
 /sys/devices/platform/host0/target0:0:2:0/0:0:2:0
 
 and the output from cat  /proc/scsi/scsi is
 
 Attached devices:
 Host: scsi0 Channel: 00 Id: 02 Lun: 00
   Vendor: CANONModel: IX-27015CRev: 1.15
   Type:   Scanner  
 

John,

make sure that:

- /dev/sg0 is readable for the user running scanimage or another
  frontend, or, for a first test, run scanimage -L as root. /dev/sg0
  is the device file that will be used to access the scanner.
- /etc/sane.d/dll.conf (or /usr/local/etc/sane.d/dll.conf, if you
  installed Sane directly from the sources) has a line 'canon',
  without a leading '#'
- check the existence of /etc/sane.d/canon.conf resp.
  /usr/local/etc/sane.d/sanon.conf

The default version of canon.conf contains a line like
/dev/scanner. I am not sure, if this is enough; you might add a
line /dev/sg0.

If all this does not help, run

export SANE_DEBUG_DLL=255
export SANE_DEBUG_CANON=255
export SANE_DEBUG_SANEI_SCSI=255
scanimage -L 2 test.log

This will produce a (perhaps somewhat larger) file test.log that
contains much debug output. Send the file to me (may be too big for
the mailing list), and I'll see, what the cause of the problem might be.

Abel

[sane-devel] (fwd)

[abel deuring]

Bakos Gy|rgy wrote:
 Package:hplip
 Version:1.6.7-1
 
 Scan Issue: hplip or sane is the problem...
 Exactly the same error everywhere with HP laserjet 3300
 
 http://www.ubuntuforums.org/archive/index.php/t-190239.html
 http://ubuntuforums.org/showthread.php?t=148017highlight=sane+document+feeder
 
 It is complaining (sane_start) about the feeder, but this
 has not any feeder!!

The hplip backend is not a part of sane-backends; it is maintained
independently as a sourceforge project:
http://hplip.sourceforge.net/ . Since you obviously get an error
message from that backend, you should tell the hplip backend
maintainers about this bug.

Abel

[sane-devel] sane-find-scanner detects smartcard reader as scanner

[abel deuring]

Johannes Meixner wrote:
 Hello,
 
 On Aug 8 08:04 m. allan noah wrote (shortened):
unlike scsi, there is no usb class for scanners
 
 I thought there is even no SCSI class for scanners.
 At least my SCSI scanner HP ScanJet 6200C shows up as Processor:
 
 # lsscsi -c
 ...
 Host: scsi0 Channel: 00 Target: 04 Lun: 00
   Vendor: HP   Model: C6270A   Rev: 3846
   Type:   ProcessorANSI SCSI revision: 02
 

Some HP scanners don't support the SCSI command set for scanners;
they use some vendor specific command set instead. For these devices
it is probably correct that they identify themselves as
processors, i.e., a kind of generic SCSI devices.

But this means that sane-find-scanner will detect other fancy SCSI
devices too. If my memory does not deceive me, somebody reported
problems on this list with a SCSI RAID controller, which presented
its control part to the Linux kernel as a SCSI processor. Another
candidate for this device class would be a tape robot.

Abel

[sane-devel] Problem with HP ScanJet 8290 and scsi

[abel deuring]

Marc F. Clemente wrote:
 I have additional information that may be useful.  I connected a Nikon
 LS-2000 (also scsi) to the same scsi cable.  I do not have the same
 problem with the LS-2000.
 
 Disabling calibration and gamma-table in avision.conf makes no difference.
 
 I reproduce the error with the avision debug info.  Maybe it will help.
  Let me know what else I can do.

Great. That's exactly, what I forgot to ask you for in my last mail;)

 [avision] send_3x3_matrix:
 [avision] send_3x3_matrix: sending matrix
 [sanei_scsi] sanei_scsi_req_enter2 warning: truncating write data from
 requested 28 bytes to allowed 12 bytes

Turned out that I looked yesterday into a too old version of the
backend's source code... The problem is the call of avision_cmd at
the end of send_3x3_matrix (line 4737 in sane-backends-1.0.17):

status = avision_cmd (s-av_con, cmd, sizeof (cmd), 0, 0, 0, 0);

Try to change this to

status = avision_cmd (s-av_con, cmd, sizeof (cmd.scmd),
cmd.matrix, sizeof(cmd.matrix), 0, 0);

I have no idea though, how this change may affect scanners connected
via the USB bus...

Abel

[sane-devel] Problem with HP ScanJet 8290 and scsi

[abel deuring]

Marc F. Clemente wrote:
 I have a problem connecting a ScanJet 8290 by scsi.
[...]
 [sanei_scsi] sanei_scsi_open: Host adapter queue depth: 2
 [sanei_scsi] sanei_scsi_open: SG driver can change buffer size at run time
 [sanei_scsi] sanei_scsi_open: low level command queueing enabled
 [sanei_scsi] sanei_scsi_open: using new SG header structure
 [sanei_scsi] sanei_scsi_req_enter2 warning: truncating write data from 
 requested 28 bytes to allowed
 12 bytes
 [sanei_scsi] sanei_scsi.issue: bad write (errno=90) Message too long -1
 scanimage: sane_start: Error during device I/O
 Exit 9
 
 
 What am I doing wrong?

Nothing -- this is a really strange error, caused somewhere either
in sanei_scsi.c or in the avision backend.

  What's the meaning of truncating write data from requested 28 bytes...

Unfortunately, there are two lines in sanei_scsi.c that can print
this warning; my guess is that the second DBG statement with this
text in sanei_scsi.c prints this warning. Both warnings deal with
the possible problem that a backend tries to send more data than can
be passed to the Linux SG driver. The first warning is issued, if a
backend tries to send more SCSI _data_ than possible; the second
warning is issued, if a backend tries to send a too long SCSI
_command_. The maximum size for SCSI commands is 12 bytes, while the
buffer size for data sent to or from the scanner is set to 128 kB.
Hence we have most likely a warning for the latter case.

What really puzzles me is this: The error occurs for the first
command that is sent to the scanner after the call to
sanei_scsi_open. The Avision backend calls sanei_scsi_open in two
places:

- in attach(); in this case the first SCSI command is INQUIRY, and
the size of the command data is set to 6 bytes, if I read avision.c
and avision.h correctly.

- in sane_open(): here, the first SCSI command is RESERVE UNIT
(issued in reserve_unit()), and the size of the command data block
is again properly set to 6.

In other words: I believe that I know roughly where to look for the
error -- but I don't see where or how the CDB size changes from 6 to
28, as printed by the DBG statement in sanei_scsi.c.

Rene, do you have any idea?

Abel

[sane-devel] howto Duplex

[abel deuring]

abel deuring wrote:

 Perhaps the PIL source code file Sane/_sane.c is to blame. The
 function SaneDev_snap expects that sane_start has been called, but
 makes all other calls to the Sane library functions needed to
 retrieve an image (sane_getparameters and sane_read) -- and finally
 calls sane_cancel. This last call should optionally be disabled: I'd
 guess that it resets the backend so that backside data of a
 duplex scan is discarded.

Just for the record: my guess about the cause of the bug was right;
a fix will be included in PIL 1.6. Thanks to Horst Herb for testing
the patch.

Abel

[sane-devel] howto Duplex

[abel deuring]

Horst Herb wrote:
 I have an Avision AV220 duplex scanner. Works fine under SANE.
 However, I want to access the Duplex functionality programmatically and 
 cannot 
 figure out how to do it. I am using the Python SANE module to access the 
 scanner
 
 Horst
 

Horst,

first a disclaimer: I don't have a scanner for the Avision backend,
and I am too lazy to take a look into the backend's source code.

The Avision backend should have an option that enables the duplex
functionality. I have no idea what its name is, but you can ask a
Python-Sane device instance, which options are available:

#--
import sane, sys
sane.init()
devs = sane.get_devices()
if not devs:
print no scanner found
sys.exit()
print devices, devs
dev = sane.open(devs[0][0])
for optname in dev.opt.keys():
print OPT:, optname
try:
opt = dev.opt[optname]
print  index   , opt.index
print  name,  opt.name
print  title   , opt.title
print  desc, opt.desc
print  type, opt.type
print  unit, opt.unit
print  size, opt.size
print  cap , opt.cap
except:
print (inactive)
#pass

# set an option. A decent program should first check, if the
# option is active and settable to avoid an exception.
dev.resolution = 120

# we need to clean up before calling sane.exit, else we'll
# get a segfault
del dev
sane.exit()
#

Abel

[sane-devel] howto Duplex

[abel deuring]

Hi Horst, Hi Rene

Horst Herb wrote:
 On Sun, 12 Feb 2006 23:58, abel deuring wrote:
The Avision backend should have an option that enables the duplex
functionality. I have no idea what its name is, but you can ask a
Python-Sane device instance, which options are available:

 It has indeed, and I have no problems setting that property:
 scanner.source = 'ADF Duplex'
 I also notice from the scanner lights that it switches into Duplex
mode too
 while scanning with that option set
 What I can't do is retrieve the second image from the scanner -
only a single
 page image comes through instead of two

OK, next guess (Rene, can you as the author of the backend confirm
this?):

Perhaps the PIL source code file Sane/_sane.c is to blame. The
function SaneDev_snap expects that sane_start has been called, but
makes all other calls to the Sane library functions needed to
retrieve an image (sane_getparameters and sane_read) -- and finally
calls sane_cancel. This last call should optionally be disabled: I'd
guess that it resets the backend so that backside data of a
duplex scan is discarded.

If Rene confirms my guess, I can write a patch.

Abel

PS: IMHO, the code separation in PIL between sane.py and _sane.c
is a bit messy. If a missing del sane_device_object statement can
lead to a segfault, something is wrong in the code organisation ;)
Another point is that it is currently impossible to read the raw
scan data into some sort of Python sequence (string, tuple or list).
Of course its very handy to directly get a PIL image object via the
snap() method, but that's not necessary in every use case, and for
large scan resolutions and areas it can lead to huge memory consumption.

[sane-devel] sane SCSI 32bit emulation on 64bit

[abel deuring]

Volker Kuhlmann wrote:
 On Tue 10 Jan 2006 06:58:20 NZDT +1300, abel deuring wrote:
 
http://lists.alioth.debian.org/pipermail/sane-devel/2006-January/015886.html
 
 Thanks for this link, my ISP routed that particular email to /dev/null.
 
No, Dieter is right indeed. Sane backends too use sanei_scsi.c. The
problems he had with his SCSI scanner under a 64 bit Linux Sparc
 
 Ah, I was thinking it was solaris sparc.
 
kernel boiled down exactly to the fact that you can't pass a 32 bit
sg_io_hdr structure to a 64 bit kernel.
 
 Expanding the sg_io_hdr struct into 64 bit can be done by the
 application by copying members to a new memory area with 64 bit member
 alignment, and passing the new location to write(). As you say this
 doesn't extend the pointers from 32 bit into 64 bit pointer space, so it
 won't work. Darn.
 
 Patching the sg driver would only be for the dedicated user, if it's
 possible for the driver to autodetect whether the call was from a 32bit
 application.
 
It was also Dieter who tested #define DISABLE_LINUX_SG_IO .
 
 How much of a performance hit does this take?

A performance penalty should hardly be noticeable on a modern
system. The old interface worked fine even at a time of 100 MHz
processors. It mainly needs its own buffer malloced for the read and
write calls to the SCSI device. For the write call, the application
needs to memcpy the SCSI command data and the write data into this
buffer, for the read call, it needs to memcpy the SCSI read data
from the read() buffer into the the destination array provided by
the application.

The size of these read/write buffers depends on the backend; by
default sanei_scsi.c allows a maximum of 128 kB for the data; the
SCSI command and some additional data require a few dozen additional
bytes (I'm too lazy to look up the exact number right now).

Aside from the extra buffer, another drawback of the old interface
is that it simply concatenates the SCSI command data and the write
data, so that the SG driver must guess, where the SCSI command ends
and where the write data starts. This works fine in most cases, but
the guess goes wrong for one or two vendor specific commands used by
some Canon scanners. But sanei_scsi.c knows to handle this case.

Abel

[sane-devel] sane SCSI 32bit emulation on 64bit

[abel deuring]

Julien BLACHE wrote:
 abel deuring adeur...@gmx.net wrote:
 
I don't want to open a discussion about licenses, but IMHO Sane's
exception to the GPL encourages cases like this one. I think it
would be more reasonable to put sane-backends under the LGPL, which
 
 Good luck in getting every copyright holder (which includes every
 patch contributor) to agree to the relicensing :)

That's exactly, why I wrote that I don't want to open a discussion ;)

 
makes the rules for linking proprietary and free code very clear,
 
 Err, no, not really. It quickly becomes quite tricky to use LGPL code
 in an application in complete compliance with the license.

Really? Admittedly, it is some time ago that I took a closer look to
the LGPL, but I thought that the main reqirement is that a user must
be able to recompile the free library and to link this new library
version to the proprietary code. No big deal with shared libraries,
for example.

Abel

[sane-devel] sane SCSI 32bit emulation on 64bit

[abel deuring]

Volker Kuhlmann wrote:
 Hello Henning,

Just to make one thing clear: Vuescan is NOT a SANE frontend. I.e. it
does not use any SANE backend. It's a completely independent program
with independent scanner drivers.
 
It just happens to use a part of the internal low level SANE code
(sanei_scsi).

I don't want to open a discussion about licenses, but IMHO Sane's
exception to the GPL encourages cases like this one. I think it
would be more reasonable to put sane-backends under the LGPL, which
makes the rules for linking proprietary and free code very clear,
and especially enables end users to fiddle with the free code.
Exactly, what Volker would need here.

 
 You're totally right, I should have made this clearer.
 
Last time I looked at it (some years ago), this was done
without even adhering to the license.
 
 Very noughty. You should really point this out to him.
 
Abel posted a work-around for that.
 
 Thanks much Henning!! I take it you're referring to this thread:
 http://lists.alioth.debian.org/pipermail/sane-devel/2003-January/006083.html
 
 This is exactly what happens - the write() to the sg device returns
 EINVAL. The workaround of repacking the structure presents itself, I'll
 see if I can hack it (bad pun).

well, you'll need to find some way to map the values of 32 bit user
space pointers to 64 bit pointers (look for struct sg_io_hdr in the
kernel header file scsi/sg.h, fields dxferp, cmdp, sbp). That's
something the kernel (specifically, the SG driver in our case) can
easily do, but I am not aware of any way to do this inside an
application. The latter would require that a 64 bit kernel even has
something like a concept of 64 bit user space pointers for 32
applications. One way to go would be to patch the SG driver; the
other is to use the old SG interface, as I wrote in this mail:
http://lists.alioth.debian.org/pipermail/sane-devel/2006-January/015886.html

 Dieter, thanks for the thought - but it doesn't apply to vuescan, which
 is linked with sanei_scsi but doesn't use the sane backends.

No, Dieter is right indeed. Sane backends too use sanei_scsi.c. The
problems he had with his SCSI scanner under a 64 bit Linux Sparc
kernel boiled down exactly to the fact that you can't pass a 32 bit
sg_io_hdr structure to a 64 bit kernel.

It was also Dieter who tested #define DISABLE_LINUX_SG_IO .

Abel

[sane-devel] Microtek Film Scan 35

[abel deuring]

Henning Meier-Geinitz wrote:
 Hi,
 
 On 2006-01-08 14:27, Volker Kuhlmann wrote:
Most annoying that it doesn't work with SCSI scanners on 64bit machines,
something a recompile would fix. Hence my recent question about write()
encapsulation in sanei_scsi.c (which no-one replied to :( ).
 
 I didn't answer because I'm not really sure about SCSI and 64bit
 systems. As far as I know there is no special handling for 64bit
 systems in our SCSI code.
 
 If somebody else needs such a special handling because of the
 binary-only nature of his software, it's up to him to fix the problems
 caused by this. 
 
 If there are general problems with sanei_scsi/SANE on 64 bit systems,
 I'd like to know about this. As far as I know, this is not the case,
 however.

The problem is probably the same that has been discussed for Linux
on 64 bit Sparc machines some time ago. The SG interface version 3
can't deal with 32 bit programs on a 64 bit kernel. In read/write
calls of the SG driver, the application passes 32 bit pointers to
three buffers (SCSI command, data buffer, sense data) to the SG
driver, while the driver expects 64 bit pointers to these buffers.
As a workaround, one can enforce the usage of the old interface, by
inserting the line

#define DISABLE_LINUX_SG_IO 1

at the start of sanei_scsi.c. OK, a proper solution would be to add
a configure option, but I am not familiar enough with the details of
autoconf to tell how to implement such an option.

Abel

[sane-devel] Agfa SnapScan 310 SCSI lock-up

[abel deuring]

Ramius wrote:
 I have an Agfa SnapScan 310 SCSI scanner, that should be supported by SANE.
[...]
 The kernel found the scanner:
 
 | ramius@debian:~$ dmesg
 | Linux version 2.6.8-1-386 (joshk@trollwife) (gcc version 3.3.5 (Debian 
 1:3.3.5-2)) #1 Thu Nov 25 04:24:08 UTC 2004
 | [...]
 |   ACARD AEC-671X PCI Ultra/W SCSI-3 Host Adapter: 0 IO:e400, IRQ:11.
 | ID:  2  AGFASNAPSCAN 3101.20
 | ID:  7  Host Adapter
 | scsi0 : ACARD AEC-6710/6712/67160 PCI Ultra/W/LVD SCSI-3 Adapter 

that's probably the atp870u driver, which had some problems at least in 
older kernel versions. I thought though that these problems were fixed 
meanwhile.

 The problems begin when I try to scan with xsane (or scanimage). The 
 scan unit does startup moviments then locks up when begin to scan.
 The hardware should be ok, because with windows xp the scanner works 
 without problem. Now I have a Debian Sarge/testing, but I had the same 
 problem with other distributions.
 Thanks in advance for any suggestion.
 

Can you send the debug output from running scanimage or another frontend 
with the environmnet variables SANE_DEBUG_SANEI_SCSI=255 and 
SANE_DEBUG_SNAPSCAN=255 ?

Abel

[sane-devel] Problems with Canonscan 2700f

[abel deuring]

Tobias,

I have just sent an updated (still experimental) Canon backend
to your home address. I am not sure, however, that your case is
a backend problem.
 
 
 Thanks for the backend. You're right, the problem still exists. 
 I thought it could be the aic7xxx driver of my scsi-card, so I build a
 new kernel 2.6.8 with aic7xxx and aic7xxx_old as a module and tested
 both with the same result:
 
 scanimage -L
 
No scanners were identified.
 
 
 scanimage -d canon:/dev/scanner
 
scanimage: open of device canon:/dev/scanner failed: 
Error during device I

could you run scanimage with the environment variable 
SANE_DEBUG_SANEI_SCSI set to 255, together with SANE_DEBUG_CANON=225 and 
send me the output?

Abel

[sane-devel] Using an Officejet 7310 with its ethernet connection?

[abel deuring]

Scott wrote:

 According to the product specifications, this sounds like a REALLY nice
 AIO!  However, it seems that it supports connecting to a USB port and 
 that would probably be the best method.  The only other scanners that I could 
 find that have had a workaround for scanning via an ethernet connection
 to a SCSI generic device would be a section of the Sharp series.  An 
 article explaining the process along with links (and likely source code)
 can be found here:
 
 http://linux.about.com/library/cmd/blcmdl5_sane-sharp.htm

That's a copy of the sane-sharp man page.

 
 I'm not sure if this will work as HP != Sharp and so the code is likely
 to be different, but I would definately try hooking it up to the USB 
 port first and get it working right there, and then trying the ethernet
 out.  Good luck!

I'm afraid that no scanner supported by the the sane-sharp backend 
provides any ethernet interface, neither does the backend its provide 
any networking support. But the backend can be used like every other 
Sane backend by the saned daemon and its counterpart, the net backend.

Abel

[sane-devel] Suse-Kernel 2.6.5 and umax astra 1220 S

[abel deuring]

Wolfram Heider wrote:
 Hello list,
 
 when I recently updated from Suse 8.2 (2.4er kernel)  to Suse 9.1 with kernel 
 2.6.5, my scanner, a UMAX Astra 1220 S which had worked well troughout all 
 the kernel-versons of the last years, was gone without the slightest trace.  
 scanimage -L, sane-find-scanner and the other little helpers remainend silent 
 about it.
 Maybe it's not a really sane-problem but a controller-problem.

yes, it's most likely a problem in the Linux SCSI system. To look for 
SCSI scanners, sane-find-scanner reads /proc/scsi/scsi, and the contents 
of this proc file is managed by the SCSI system of the kernel.

 The controller in use is a Dawicontrol DC-2975-C which connected till now 
 over 
 the sym53c8xx/ncr53c8xx-module.
 The strange thing is that with the kernel 2.6.1 of the knoppix 
 3.4-distribution everthing works as usual.
 The Suse-Kernel still comes with the sym53c8xx-module, but something seems to 
 be wrong with it.

Are you sure that the sym/ncr53c8xx module is indeed loaded? And if it 
loaded, do you get any error messages in /var/log/messages?

The sym/ncr53c8xx drivers offer many parameters; perhaps it helps to 
play with some of them. The file
kernel source dir/drivers/scsi/README.ncr53c8xx describes these 
parameters quite detailed.

Abel

[sane-devel] No device available

[abel deuring]

jurek Ela Tryjarscy wrote:
 Hi ,
 In my box I have Redhat 9.
 I must connect via SCSI Interface Umax Mirage II scanner.
 SCSI adapter is Acard AEC-6712TU.

 Linux System logs contain:
 
 Oct  4 19:19:05 localhost kernel:ACARD AEC-671X PCI Ultra/W SCSI-3 
 Host Adapter: 0IO:1000, IRQ:11.
 Oct  4 19:19:05 localhost kernel:  ID:  7  Host Adapter
 Oct  4 19:19:05 localhost kernel: scsi0 : ACARD AEC-6710/6712/67160 PCI 
 Ultra/W/LVD SCSI-3 Adapter Driver V2.6+ac

I have never used the atp870u driver, but I assume that this driver 
should print some message about the devices it detected on the bus as 
other drivers do. In other words: for some reason it could not find the 
scanner.

 My qustion is:
 How to install correctly the scanner and the scsi adapter - I must make 
 any mistake.
 I do:
 modprobe sg
 modprobe atp870u
 
 [root@localhost scsi]# lsmod
 Module  Size  Used byNot tainted
 atp870u23856   0  (unused)
 sg 36524   0  (unused)
 scsi_mod  107160   2  [atp870u sg]
 ide-cd 35676   0  (autoclean)
 cdrom  33728   0  (autoclean) [ide-cd]
 parport_pc 19076   1  (autoclean)
 lp  8996   0  (autoclean)
 parport37056   1  (autoclean) [parport_pc lp]
 autofs 13268   0  (autoclean) (unused)
 8139too18120   1
 mii 3976   0  [8139too]
 keybdev 2976   0  (unused)
 mousedev5492   1
 hid22148   0  (unused)
 input   5888   0  [keybdev mousedev hid]
 usb-uhci   26348   0  (unused)
 usbcore78816   1  [hid usb-uhci]
 ext3   70784   2
 jbd51892   2  [ext3]
 
 [root@localhost root]# ls  /proc/scsi
 atp870u  scsi
 
 [root@localhost scsi]# more  scsi
 Attached devices: none

here you should get 3 lines describing the scanner.

 
 I think it should be also sg directory in  /proc/scsi

yes -- but I don't know, if the SG driver creates this directory, if it 
does not see any devices.

 
 [root@localhost root]# sane-find-scanner
 
 # No SCSI scanners found. If you expected something different, make sure 
 that

that's because sane-find-scanner simply reads /proc/scsi/scsi, and this 
file is empty.

 # you have loaded a SCSI driver for your SCSI adapter.
 # Also you need support for SCSI Generic (sg) in your operating system.
 # If using Linux, try modprobe sg.
 
 Can anyone help me ?

I don't have a really good hint. The core problem is that the atp870u 
driver does not find the scanner, hence any attempt to access it will 
fail. Unfortunately the kernel sources don't seem to contain useful 
documentation e.g. about module parameters.

A very simple attempt could be to issue the command

echo scsi add-single-device 0 0 6 0  /proc/scsi/scsi

If the atp870u driver performs a bus reset and does not wait long enough 
for SCSI devices to finish their reset procedure, it will not find the 
scanner, when it scans the bus for devices after the reset.

Abel

[sane-devel] SANE_Handle question

[abel deuring]

Paul wrote:
 Hi,
 
 I'm trying to implement using SANE within Scribus and I'm hitting a
 small snag. While the majority of the API is really simple to use, I'm
 having a problem with what SANE_Handle is.

Its great to hear that Scribus will support Sane.

 
 The sane.h header has it defined as 
 
 typedef void *SANE_Handle;
 
 There are plenty of functions which require SANE_Handle, but nothing
 which actually sets it!

Well, there is a function which sets a SANE_Handle variable:

SANE_Status sane_open (SANE_String_Const name, SANE_Handle * h);

But it's easy to miss (or forget) this function while reading the docs 
-- that could have had easily happened for me too ;)

 According to the sane website, SANE does not require that a value of
 this type be a legal pointer value and an application shouldn't attempt
 to interpret the value of SANE_Handle.

I think all currently existing backends interpret SANE_Handle as a 
pointer, but this is not required. A frontend should interpret 
SANE_Handle to be simply an identifier; any assumption that it might be 
possible to access some backend-internal stuff may fail.

 How should I set the handle? For instance, when I obtain the device
 list, I have two show for my USB webcam and one for my scanner. I have
 to be able to set the handle to the scanner. Is it enough to set the
 handle to the device name or should it be set to the physical /dev/sg0
 value (which is not a good idea!)

call sane_get_devices, and use the field SANE_Device.name from the 
elements of device_list as the first parameter in the of call sane_open. 
  Using something like '/dev/sg0' will not work, because Sane does not 
know in this case, which backend should be used; 'mustek:/dev/sg0' might 
work. But I am not sure, if this is reasonable for a graphical 
frontend, where users are not supposed to have read the Sane 
documentation ;) The assignment of device names to real devices can 
offer some suprises. For example, /dev/sg0 means for Linux usually the 
device with the lowest SCSI ID on the first bus of the first adapter. 
But if this device was not powered when the SCSI adapter driver was 
loaded, it can later be made known to the SCSI system by a command like 
'echo scsi add-single-device 0 0 4 0  /proc/scsi/scsi' , and if the 
system has already found three other SCSI devices, the new device will 
be assigned to the device file /dev/sg3.

Abel

[sane-devel] SANE_Handle question

[abel deuring]

Paul wrote:
 Hi,
 
 
I'm trying to implement using SANE within Scribus and I'm hitting a
small snag. While the majority of the API is really simple to use, I'm
having a problem with what SANE_Handle is.

Its great to hear that Scribus will support Sane.
 
 
 Still lots to do and a decision as to how much the support will be. Do I
 have it so that the scanner scans the image and then let GIMP deal with
 the rest or have a very basic area select mechanism? I'm happier to send
 things to GIMP, but then I'm lazy ;-p

Well, perhaps that's lazy, but reasonable: why reinvent the wheel ;)

There might be an alternative: XSane or XScanimage as a plugin for 
Scribus, similiary as you can plug these programs into Gimp. This way, 
you don't have to bother with the details of the scanning UI and of the 
Sane API, while you get what Scribus needs: a pixel image. Moreover, 
XSane has many useful features, like automatic gamma correction.

cheers
Abel

[sane-devel] Calculating maxlen

[abel deuring]

Paul wrote:
 Hi,
 
 
max_len is set by the frontend. The buffer is allocated by the frontend
and the size of the buffer must be at least max_len bytes.

max_len and the size of the buffer are arbitary. The backend must be
able to handle each size from max_len=1 to max_len  size of the image.
 
 
 Okay, I need to be clear here.
 
 max_len is some size large enough to scan something in. How do I know
 how big to make this to (say) scan an A4 picture at 8bpp resolution? To
 me, it looks like I multiply bytes_per_line * pixels_per_line * lines *
 depth to accomodate everything.
 
 I'm currently toying with the code so I know what has to be done when it
 comes to implementing the code for real.

Paul,

you can get the size of the entire image from the result of a call of 
sane_get_parameters. (Make sure that you call sane_get_parameters 
_after_ the call of sane_start. Earlier calls do not necessarily return 
precise values.) But you don't need to read all scan data with only one 
call of sane_read. An A4 size RGB scan with 300dpi has a data size of 
~24 MB, and this is perhaps more than you want to keep in RAM. For a 
preview, lower resolutions are often preferable. I assume that Scribus 
has some way to calculate such a preview from a high resolution image.

cheers
Abel

[sane-devel] Fwd: HP scanjet IIcx /t resolution

[abel deuring]

George Georgalis wrote:

 Thanks to some help on irc I've got my HP scanjet IIcx /t working.
 
 It's spec says 600 dpi but somewhere between 300 and 400 dpi it starts
 to do double passes (exactly when it starts depends on the image). I
 think I understand what's happening, though I don't know the
 vocabulary to explain it (software gets a higher resolution than the
 optical quality requiring multiple passes).
 
 Anyway what I was wondering is:
 1) why it would do this double take at anything less than the rated
 optical resolution? -- which is 600 dpi
 2) why would the image affect at which dpi the double take starts?

Do you mean the image width?

 
 I came across this determining the highest dpi I could use to do a
 scan quickly, ie no double takes.
 
 I should add, it doesn't  scan everything twice, it just backs up and
 rescans as little as 5% of the whole area; at resolutions above 300
 dpi, more % at higher resolutions.

George,

while I've never used an Scanjet IIcx, your description doesn't sound 
like real double scans. For higher resolutions, the scanner must 
transfer larger amount of data per scan line to the computer, and on the 
path scanner - SCSI cable - SCSI adapter - SCSI driver - sane 
backend - sane frontend are a number of possible bottlenecks, i.e., the 
scanner may aquire more scan data per time unit than can be sent or 
processed. If the internal buffer of the scanner is full, the scan head 
must be stopped. In order to prevent image distortions caused by 
mechanical margins (??? is this correct English? In German, I mean 
mechanisches Spiel or Toleranz), most scanners move the scanhead a bit 
back before continuing the scan.

Most scanners move the scan head with the same speed, independent of the 
scan width, hence you get also a larger data transfer rate for wider 
scans. If the scan head stops occur above a certain transfer rate, you 
can get this same data rate by doubling the scan width, while halving 
the resolution. This could explain your second quetsion.

Abel

[sane-devel] [fujitsu] scsi-buf-size patch

[abel deuring]

Paul,

first a disclaimer: I'm not the maintainer of the Fujitsu backend, but I 
know a bit about sanei_scsi.c ;)

 The user should be able to work around this problem by setting the
 scsi-buf-size parameter in the fujitsu.conf configuration file to the
 total size of the image, and setting the SANE_SG_BUFFERSIZE environment
 variable to the same value.  However, a bug in sane-fujitsu currently
 prevents any SCSI buffer size setting larger than the default
 sanei_scsi_max_request_size from taking effect, and 
 sanei_scsi_max_request_size is often much smaller than what is necessary.

 --- sane-backends-1.0.14/backend/fujitsu.c2004-03-04 13:09:56.0 
 -0700
 +++ sane-backends-1.0.14-patched/backend/fujitsu.c2004-07-05 
 23:25:15.241452840 -0600
 @@ -501,20 +501,19 @@
  {
int buf;
lp += 16;
lp = sanei_config_skip_whitespace (lp);
buf = atoi (lp);
 -  if ((buf = 4096)  (buf = sanei_scsi_max_request_size))
 +  if (buf = 4096)

This patch works only with a bit of luck ;) The value of 
sanei_scsi_max_request_size tells the backend the maximum data block 
size that can be safely transferred with a single SCSI command. There 
are situations where this is also a hard limit. An example: Most ISA 
SCSI adapters can only transfer up to 64 kB with one SCSI command, due 
to limitations of ISA DMA architecture. (OK, anybody who is using a fast 
and relatively expensive Fujitsu scanner with cheap and old ISA SCSI 
adapter is probably a bit crazy, but it is possible to do that.) The 
SCSI subsystems of some operating systems supported by Sane may have 
some hard coded limits for the maximum data size of a single SCSI 
command, and this limit could well be as low as 64 kB or 128 kB.

The Linux SG driver is quite smart with its attempts to deal with huge 
data block sizes, so your patch may work in most cases for Linux, but it 
can also lead to situations where a scan may fail in a mysterious way. 
When an SG device file is opened, the SG driver allocates a data buffer 
for the SCSI commands, and the size of this buffer can be adjusted. If a 
SCSI command needs a larger buffer, the driver tries to allocate more 
memory for this single command, but if the machine is for some reason 
short on memory, the command will simply fail.

Generally, I'd recommend the following:

(1) replace the sanei_scsi_open calls with sanei_scsi_open_extended; the 
latter function allows to set the buffer size for each device file 
separately. This avoids the bureaucracy to deal with the 
SANE_SG_BUFFERSSIZE enviroment variable.
(2) If sanei_scsi_open_extended does not return the required buffer 
size, the backend should simply return an error by default. If some 
environment variable or some option in the configuration file is set, 
the backend may alternatively print a warning, via a DBG message. 
Additionally, the function do_scsi_cmd should also check, if the call of 
sanei_scsi_cmd failed with a SANE_STATUS_NO_MEM error, and if it failed 
it should print a warning, that the failure may be caused by a too large 
buffer size.

This way, users may try to perform a scan anyway, but in order to do 
that, they have to read some documentation, where they should also get 
an explanation that they must expect (perhaps random) scan errors, and 
that ignoring the maximum SCSI buffer size may not work on all platforms 
supported by Sane.

cheers
Abel

[sane-devel] [fujitsu] scsi-buf-size patch

[abel deuring]

Paul,

 Just for the record, the second portion of the patch that I sent does
 check to see whether the SG driver did not accept the larger buffer size,
 and does at least emit a warning and reset the buffer size.  The patch

Ouch, yes, you are right. Sorry that I missed that. Again a proof that I 
should read mails a bit more carefully before responding ;)

 just moves that test from the configuration file parsing section, where it
 was useless, to after the backend tries to set the SG buffer to the
 requested size.  Anyway, I agree that it is better for the backend to stop
 and emit an error message.

Abel

[sane-devel] Mac OS X 10.3.3- Sane Backend 1.0.14 - Microtek ScanMaker II - New Information

[abel deuring]

since noboby with more knowlegde about MacOS has yet answered, here are 
my 2 cents:

David B Brown wrote:
 Hi,
 
 every time a new version of the Sane Backend's becomes available I 
 always have another go to see if anything has changed to make my 
 configuration work. I also find that when I come back to this afresh I 
 always get a little further forward.
 
 When you run scanimage, the Microtek scanner incorretly reports itself 8 
 times, each under a different LUN, this has been consistent since the 
 new Max OSX SCSI code was implemented to support Mac OS X 10.3.
 
 [MacCoylton:~] dave% scanimage -L
 device `microtek:iokitscsi@0163331e2a70b923' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 device `microtek:iokitscsi@0163381e28c472d6' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 device `microtek:iokitscsi@01633a1e18c239cd' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 device `microtek:iokitscsi@0162c41e05d02fe7' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 device `microtek:iokitscsi@01633d1e0530106a' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 device `microtek:iokitscsi@0162cc1e04869288' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 device `microtek:iokitscsi@0162cf1e03c78ee9' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 device `microtek:iokitscsi@0161e11e02a59e9b' is a Microtek 
 ScanMaker II/IIXE flatbed scanner
 [MacCoylton:~] dave%
 
 If you check using ioreg, each of these is on the same SCSI ID, but a 
 different LUN, the last one reported is actually on LUN 0.
 
 If I run scanimage without specifically specifying a device, then I 
 always get and error about the scsi buffer being smaller than one scan 
 line. The error is a bit of a red herring, and the real issue is that 
 the code is trying to communicate with the scanner using the wrong LUN, 
 in this case on LUN 7 in the above example which is the first one listed.
 
 ISSUE: My coding is rusty and my knowledge of the SCSI API used for Mac 
 OS X is worse, but I believe that the Mac OS X scsi code doesn't support 
 specifying a LUN and SCSI ID in the microtek.conf file. From my testing 
 if the code has to search for the scanners it only uses the vendor and 
 device name, and ends up attached to the wrong LUN

Right, from a quick look into the MacOS X part of sani_scsi.c, it seems 
that from the two functions possibly called by sanei_scsi_find_devices, 
only sanei_scsi_find_devices_old_api recognizes the LUN, while 
sanei_scsi_find_devices_stuc_api ignores any LUN specification. While it 
is essentially a bug of the scanner to respond to INQUIRY commands on 
all LUNs, applications should be able to deal with it.

 
 If I run scanimage with the -d option set to the last device listed ie 
 the one thats LUN 0, the scan actually starts. I then have two scenarios 
 each with there own problems as follows
 
 
 Scenario 1:- If I run with an unconstrained size, then the first pass 
 happens ok, and then scanimage exists with an error before the scanner 
 physically returns to the start for the second pass. Here's some debug 
 trace:-
 
 [microtek] sane_read: buffsize: 130900, unscanned: 13
 [microtek] pack_into_ring...
 [microtek] pack_into_dest...
 [microtek] pack_into_dest: rl: 32768 sz: 130900 hc: 0
 [microtek] sane_read...
 [microtek] pack_into_dest...
 [microtek] pack_into_dest: rl: 32768 sz: 130900 hc: 32768
 [microtek] sane_read...
 [microtek] pack_into_dest...
 [microtek] pack_into_dest: rl: 32768 sz: 130900 hc: 65536
 [microtek] sane_read...
 [microtek] pack_into_dest...
 [microtek] pack_into_dest: rl: 32596 sz: 130900 hc: 98304
 [microtek] sane_read...
 [microtek] read_from_scanner...
 [microtek] .get_scan_status 0...
 [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:6 isWrite:0
 [sanei_scsi] isRead dst_size:6
 [sanei_scsi] Executing command
 [sanei_scsi] ExecuteTaskSync OK Trasferred 6 bytes
 [microtek] get_scan_status(6): 0, 850, 13 - #0
 [microtek]  0 52 3 d 0 0
 [microtek] read_from_scanner: gss busy, linewidth, remaining: 0, 850, 13
 [microtek] sane_read: max_scsi: 154, rem: 13, nlines: 13
 [microtek] .read_scan_data...
 [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:11050 isWrite:0
 [sanei_scsi] isRead dst_size:11050
 [sanei_scsi] Executing command
 [sanei_scsi] ExecuteTaskSync OK Trasferred 11050 bytes
 [microtek] sane_read: buffsize: 11050, unscanned: 0
 [microtek] pack_into_ring...
 [microtek] pack_into_dest...
 [microtek] pack_into_dest: rl: 11050 sz: 130900 hc: 0
 [microtek] sane_read...
 [microtek] end_scan...
 [microtek] .stop_scan...
 [sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:0 isWrite:1
 [sanei_scsi] isWrite src_size:0
 [sanei_scsi] Executing command
 [sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes
 [microtek] sane_start...
 [microtek] sane_get_parameters...
 [microtek] sane_get_parameters: regular 3-pass color
 [microtek] sane_get_parameters: res_code = 33 (21)
 [microtek] sane_get_parameters: dots_per_mm: 

[sane-devel] stop and go and colour lines with epson 1250

[abel deuring]

Gerhard Jaeger wrote:
 Hi,
 
 the 1250 is a stupid LM983x based scanner which knows nothing about
 jpeg compression. The stop and go is a feature of the LM983x to avoid
 data loss (of course you encounter this problem...)
 
 I think that the libusb and or the usb-stack itself is the problem. I've
 currently not testet here with 2.6 kernels.
 Another thing is the image size you scan. Tests showed, that scanning
 only small portions of a picture in 600dpi will work fine (of course - less
 data), while scanning larger portions will not work very well, but full-size
 scanning @300dpi should be no problem, at least with the plustek backend.

I think that there are several possible causes for scan head stops. 
Aside from the relatively low bandwidth of USB 1, a small buffer inside 
the scanner, combined with an application that perhaps processes data in 
a somewhat complex way is another. If the backend can't read data from 
the scanner, while the frontend does some other work, the scanner's data 
buffer may be completely filled, and hence the scan head must stop.

In order to avoid scan head stops, the Sharp and NEC backends use shared 
memory to transfer data between the reader process and the main 
process. This way, the reader process is not stuck in a write call to 
the pipe used by other backends to forward data to the main process. 
This way, I could completely avoid scan head stops even with old Pentium 
100 processors. OK, there are some other differences -- the Sharp and 
NEC backends support only SCSI scanners --, but using shared memory is 
perhaps worth a try.

Abel

[sane-devel] backends-1.0.14 scsi epson

[abel deuring]

Klaus Dittrich wrote:
 I have an EPSON-1640 with an ADF.
 
 Since I use linux-2.6 which still has trouble with USB I was
 forced to use the SCSI-Interface of the scanner.
 
 The last sane-backends version that the scanner works with
 is still 1.0.12.
 
 I looked into the code of sane-backends-1.0.14 last day and tried
 to find out why it not worked with my scanner _and_ the ADF.
 
 I found that it works again if I comment out in feed()/epson.c
 
 /*
 if (SANE_STATUS_GOOD != (status = expect_ack (s)))
 {
   close_scanner (s);
   return status;
 }
 
 return status;
 */
 
 and instead add simple 
 
 expect_ack (s);
 return SANE_STATUS_GOOD;
 
 expect_ack here always returns 9.
 
 Starting with backend-1.0.13 the sanei_scsi layer has changed
 and therefore I assume a bug in the scsi status handling, because
 expect_ack() has not changed since sane-backends-1.0.12.
 
 Maybe one of the sanei_scsi developers can help here ?

As far as I can see, the only changes in sanei_scsi.c after the release 
of sane-backends-1.0.12 affecting Linux are indentation fixes and 
similar formal modifications. But the real code is the same. So I 
don't think that your problems are related to sanei_scsi.c. Anyway, 
could you send me the log output from trying a scan with the backend 
version 1.0.12 and a newer version,  while SANEI_DEBUG_EPSON and 
SANE_DEBUG_SANEI_SCSI are set to 255?

Abel

[sane-devel] backends-1.0.14 scsi epson

[abel deuring]

sorry Klaus, I should have had a closer look into your other mail 
containing the debug output.

abel deuring wrote:
 Klaus Dittrich wrote:
[...]
 Starting with backend-1.0.13 the sanei_scsi layer has changed
 and therefore I assume a bug in the scsi status handling, because
 expect_ack() has not changed since sane-backends-1.0.12.

 Maybe one of the sanei_scsi developers can help here ?
 T
 
 As far as I can see, the only changes in sanei_scsi.c after the release 
 of sane-backends-1.0.12 affecting Linux are indentation fixes and 
 similar formal modifications. But the real code is the same. So I 
 don't think that your problems are related to sanei_scsi.c. Anyway, 
 could you send me the log output from trying a scan with the backend 
 version 1.0.12 and a newer version,  while SANEI_DEBUG_EPSON and 
 SANE_DEBUG_SANEI_SCSI are set to 255?

the last lines from your debug data:

dev_max(currently)=6 max_active_device=4 (origin 1)
  def_reserved_size=32768
   device=sg3 scsi2 chan=0 id=5 lun=0   em=0 sg_tablesize=96 excl=1
FD(1): timeout=12ms bufflen=131072 (res)sgat=4 low_dma=0
cmd_q=1 f_packid=0 k_orphan=0 closed=0
  rb rcv: id=28 blen=1 dur=3ms sgat=0 op=0x08
[sanei_scsi] sanei_scsi_req_wait: read 64 bytes
[sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
[sanei_scsi] sense buffer: f0 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00
[sanei_scsi] target status: 02 host status:  driver status: 0008
[sanei_scsi] sanei_scsi_req_wait: SG driver returned resid 1
[sanei_scsi]  NOTE: This value may be bogus

That's the relevant part of the debug data you've sent: It simply tells 
us that the scanner returned the status CHECK CONDITION for the last 
command; The sense data means illegal request. This generally means 
that the SCSI command sent to the device contained some error. Within 
sanei_scsi.c, that's perfectly normal: This library does not issue any 
SCSI commands by itself during a scan, it only forwards commands 
issued by a backend to the kernel. So I assume that some change in the 
Epson backend caused the error.

Abel

[sane-devel] Umax Astra 2400S w/ AEC-6712D hanging

[abel deuring]

DN Dunham wrote:

 Yes, the Linux atp870u driver has/had a bug, which appears only for a 
 few SCSI commands, so the scanner is at first recognzed, but some Sane 
 backends issue commands that raise the bug. Some time ago, I tried to 
 find a maintainer for this driver to report the bug and a fix, but 
 there does not seem to exist any maintainer... So I suspect that the 
 bug exists even in recent kernels.

 IIRC, fixing the bug was easy, it just requires to change 2 or 3 
 source code lines. So you could recompile the atp870u driver. I you 
 want to do that, let me know -- I'll search old emails to find the 
 fix. But if you have never before compiled a Linux kernel, that might 
 be a small adventure ;)

 
 I would be interested in learning what needs to be changed, if you have 
 the time to go through some e-mails for me. While I have compiled a 
 Linux kernel before, it was for a class rather than my own machine so it 
 would be a small adventure - provided a driver recompile would require 
 that I also recompile the kernel. I guess I need to get used to it 
 eventually.

Well, things look a bit more complicated than I expected:

I found the mails about the bug: The problem was that the atp870u driver 
set the data length for the INQUIRY command to a maximum of 0x24 bytes, 
which is too small for many scanners, including Umax scanners. But 
looking into the sources of the 2.4.18 kernel, it seems that this bug is 
meanwhile fixed. (A SCSI device responds to the INQUIRY command by 
returning information about itself, like device and model name, vendor 
name, device type etc. While the meaning of the first 0x24 bytes 
standardized, manufacturers are free to append non-standard data. For 
scanners, this can be things like the size of scan area, available scan 
resolution and so on.) But I think that I found another bug. Line 768 ff 
from atp870u.c:

/*
  *  Check transfer direction
  */
if ((dev-ata_cdbu[0] == WRITE_6) || (dev-ata_cdbu[0] == WRITE_10) ||
 (dev-ata_cdbu[0] == WRITE_12) || (dev-ata_cdbu[0] == 
MODE_SELECT)) {ev-ata_cdbu[0] == WRITE_10)
 outb((unsigned char) (j | 0x20), tmport++);
} else {
 outb(j, tmport++);
}

So it seems that the driver assumes that only the commands WRITE_6 
(0x0a), WRITE_10 (0x2a), WRITE_12 (0xaa) and MODE_SELECT (0x15) send 
data to a SCSI device.

Now, after a quick glimpse into the sources of the Umax backend I think 
that the backend uses the SCSI command codes 0 and 0x21 to upload gamma 
tables to the scanner (Oliver, can you confirm this?), but the atp870u 
driver will never send this data to the scanner. (there may be more 
non-SCSI-standard commands that send data to the scanner -- I'm too lazy 
to search for them...)

Assuming that my guess is right, the atp870u driver would need another 
bugfix -- but fixing this bug would require a level of comprehension of 
the internals of the Linux SCSI system which I do not have :(

A simple workaround would _perhaps_ be to add

|| (dev-ata_cdbu[0] == 0x21) || (dev-ata_cdbu[0] == 0)

to the if expression, but especially the == 0 part might have some 
side effects. 0 is the command TEST_UNIT_READY. I don't know, if or how 
this patch affects regular TEST_UNIT_READY command (with no data to be 
read or written).

If Oliver confirms that the Umax backend issues some unusual SCSI 
commands which write data to the scanner, it would probably be best to 
consult the Linux SCSI specialists on their mailing list.

 After checking out other options (such as the recompile and seeing what 
 Mr. Rauch might be able to tell me from the debug output I sent to the 
 list). Thanks for your assistance.

seems that I missed this mail. The debug output might actually give 
another hint, if my guess about the cause of the problem is correct: 
could you send it to me?

Abel

[sane-devel] Xsane locks system w/UMAX Astra 1200S

[abel deuring]

David Anderson schrieb:
 No luck with the smaller buffer size, unfortunately.
 
 I did find this past thread on the Sane mailing list archives:
 http://lists.alioth.debian.org/pipermail/sane-devel/2002-September/004071.html
 
 Someone had the same problem as me.  One person was able to resolve the
 problem by disabling SCSI bus resets on their Adaptec card.  I checked
 my SCSI card BIOS (Adaptec 2930CU) and didn't see anything that was
 related to SCSI bus resets.  I tried disabling several things, powering
 off, booting up, and trying again - still hung every time.
 
 What irks me the most is that it used to work!  And I bet if I reloaded
 Gentoo (a rather large task), it would work again.  Something changed
 somewhere along the line that broke it.  I bet it was when I did an
 'emerge system' on my box, which will automatically update Gentoo.
 
 I work at a computer shop.  I'm going to see if I can borrow another
 SCSI card and give that a try.
 
 If anyone has any suggestions, I'm all ears.  

Not really, but: As I already wrote, the kernel must be involved in the 
crash in some way, because your machine freezes completely. Perhaps it 
helps if you contact Justin Gibbs, the maintainer of the aic7xxx driver, 
for further advice. You'll find his email address in the source files of 
the driver.

Abel

[sane-devel] Umax Astra 2400S w/ AEC-6712D hanging

[abel deuring]

Oliver Rauch wrote:

  No, the scsi command in the block is send.cmd (0x2a), the DCF?.cmd is not
  an scsi command, it is the beginning of the data structure that is sent
  with the send command:
 
memcpy(dev-buffer[0], send.cmd, send.size); 

set_S_datatype_code(dev-buffer[0], S_datatype_gamma); 

dest = dev-buffer[0] + send.size;
if (dev-inquiry_gamma_DCF == 0) 

{
  DBG(DBG_info, using gamma download curve format type 0\n);
  memcpy(dest, gamma_DCF0.cmd, gamma_DCF0.size);

Ouch. I should learn again to read entire functions...

Abel

[sane-devel] Xsane locks system w/UMAX Astra 1200S

[abel deuring]

Dave,

 A few updates.
 
 1)  I have confirmed that the CD Writer still functions fine.
 
 2)  I forced the SCSI card to use IRQ 4 (serial ports are disabled).  No
 change.  I pulled some extra, unused cards out of the system and also
 moved the SCSI card to a different slot.  No change.
 
 I'm going to try XSane .92 now.

As Oliver already wrote, updating XSane will probably not change very 
much regarding the crash. You could try to use another version of 
sane-backends, but I have doubts that this will help.

Sane frontends like XSane or scanimage are just ordinary user space 
programs, and the scanner specific backends are ordinary libraries 
linked to the frontends. While a frontend or a backend may contain bugs 
cuasing segfault or garbled images, it is highly unlikely that a user 
program itself can freeze a Linux box as you are experiencing. This is 
the reason that I suspect either a hardware failure -- or you hit 
perhaps a kernel bug.

One noticeable difference between most programs accessing CD 
drives/writers and Sane backend for SCSI scanners is that Sane uses 
comparatively large data sizes in its SCSI commands (typically 128 kB 
for READ commands), while CD writing software uses probably data block 
sizes  32 kB.

It could be that these larger data block sizes are somehow related with 
your bug. (though they are not the cause, I think - Sane uses these 
block sizes since several years without any problem)

You could try to reduce the block size by setting option 
scsi-buffer-size-min and option scsi-buffer-size-max to values like 
16384 or 32768.

Abel

[sane-devel] epson gt-8000 problem

[abel deuring]

Marcin Bukat wrote:
 Hello!
 I've got epson GT-8000 and I'm trying get it to work.
 
 bash-2.05b# sane-find-scanner
 
 found SCSI processor EPSON SC ANNER GT-8000 1.36 at /dev/sg0
 found SCSI processor EPSON SC ANNER GT-8000 1.36 at /dev/sga
 
 bash-2.05b# SANE_DEBUG_EPSON=128 scanimage -L
 [sanei_debug] Setting debug level of epson to 128.
 [epson] sane_init: sane-backends 1.0.13
 [epson] sane_init, # epson.conf
 [epson] sane_init, #
 [epson] sane_init, # here are some examples for how to configure the 
 EPSON backend
 [epson] sane_init, #
 [epson] sane_init, # SCSI scanner:
 [epson] sane_init, #scsi /dev/sg0
 [epson] sane_init, SCSI EPSON
 [epson] attach_one(SCSI EPSON)
 [epson] SANE Epson Backend v0.2.40 - 2003-10-27
 [epson] attach(SCSI EPSON, 1)
 [epson] attach: opening SCSI EPSON
 [epson] attach: open failed: Invalid argument
 [epson] sane_get_devices()
 
 Because this was from root account this is not permission problem. 

Marcin,

please check, if the SG driver is loaded and if you have correct SG 
device files (/dev/sg*).

If the driver is loaded and the device files exist and if they have the 
correct major numbers (SG device files should have the type char 
device; the major number should be 21), please set additionally to 
SANE_DEBUG_EPSON the environment variable SANE_DEBUG_SANEI_SCSI to 255 
and show us the the output.

Abel

[sane-devel] Umax Astra 2400S w/ AEC-6712D hanging

[abel deuring]

DN Dunham schrieb:
 I've been trying to figure this one out for a few months now on my own 
 and thought perhaps someone there might be able to help me.

Well, I hope did not wait so long posting your question because this 
mailing list appars to bite ;)

 
 The Problem:
 I have an old desktop from a mom and pop shop that I have slowly been 
 upgrading over the years. About a year ago, I started using Linux RedHat 
 on it. The problem is that not everything works under Linux. Right now, 
 I have three pieces of hardware I can't get to work on the desktop and 
 the most pressing need is for the scanner. Besides a few games, its the 
 only real reason we ever boot-up into Windows.  Anyways
 
 The scanner is a Umax Astra 2400S that I bought from CDW is 1998. CDW it 
 appears changed out the SCSI card that was included in the package to an 
 ACARD AEC-6712D.  This caused a few problems under Windows even, but I 
 found drivers to get it to work. I now run Linux RedHat 9.0 on my 
 system. RedHat 9 is able to detect both the card and the scanner. It 
 assigns a driver atp870u to the card. However, SANE (via xsane 0.89) is 
 unable to interface with the scanner.
 
 After first boot, SANE will detect that the scanner is there and allow 
 me to try and scan from it. It will actually detect the scanner in two 
 places (/dev/sg0 and /dev/scanner). However, if I do try and scan with 
 either, SANE will hang. I seem to recall that sometimes the scanner 
 appears to do things, but most of the time it doesn't (as in the test I 
 did right now trying to get a preview).
 
 After attempting to do anything the the scanner and having a failure, 
 the scanner is no longer recognized by the system until reboot. Not even 
 RedHat's hardware browser will see it there.
 
 According to the Sane website, the UMAX ASTRA 2400S is supported, but 
 most of this seems to be with other SCSI cards. I suspect that that may 
 be my problem yet the SCSI card itself also seems to be supported by the 
 atp870u driver. Thus, I'm not sure what to do or how to fix the problem.

Yes, the Linux atp870u driver has/had a bug, which appears only for a 
few SCSI commands, so the scanner is at first recognzed, but some Sane 
backends issue commands that raise the bug. Some time ago, I tried to 
find a maintainer for this driver to report the bug and a fix, but there 
does not seem to exist any maintainer... So I suspect that the bug 
exists even in recent kernels.

IIRC, fixing the bug was easy, it just requires to change 2 or 3 source 
code lines. So you could recompile the atp870u driver. I you want to do 
that, let me know -- I'll search old emails to find the fix. But if you 
have never before compiled a Linux kernel, that might be a small 
adventure ;)

 Can anyone give me any advice, info or (even better yet) a workable 
 solution? I'd prefer not to buy another SCSI card, but if it comes to it 
 I am willing.

Well, I think that it would be worth at least to test another (perhaps 
borrowed) adapter. From my experience, adapters for the sym53c8xx and 
the aic7xxx drivers work very well. And if you can't borrow an adapter, 
you can get used ones at Ebay for a few Dollar/Euro. (the postage can 
actually be higher than the purchase price itself...)

Abel

[sane-devel] Xsane locks system w/UMAX Astra 1200S

[abel deuring]

David Anderson schrieb:
 Gentoo Linux w/2.4.22 kernel.
 
 XSane .91 installed.
 
 When I run XSane, it detects the Umax Astra 1200S (Scsi) scanner.  When
 I click 'Acquire Preview' or 'Scan', the scanner starts to go and then
 the system hangs.  Mouse won't move, can't toggle numlock, and can't
 CTRL+ALT+BACKSPACE to kill X.  
 
 Any thoughts?  What's strange is this did work a few months ago. 
 Nothing has really changed as far as I know.  I.E.  No new devices have
 been added to the system, and no settings were changed, at least that I
 know of.  
 
 As far as I can guess, this is some sort of resource conflict.  I'm just
 not sure how to go about troubleshooting.  Advice is welcome.
 
 The SCSI card is Adaptec 2930.

The aic7xxx driver is quite stable, so even if you have a broken scanner 
or broken SCSI cabling, you should simply get some error messages. A 
completely frozen computer lets me suspect a serious problem with the 
hardware of your Linux box. I'd recommend to test another SCSI adapter 
(Adaptec are generally fine), and, if that's possible for you, to test 
the same Linux installation on a different computer.

 
 cat /proc/scsi/scsi shows:
 
 Attached devices:
 Host: scsi0 Channel: 00 Id: 05 Lun: 00
   Vendor: UMAX Model: Astra 1200S  Rev: V3.1
   Type:   Scanner  ANSI SCSI revision: 02
 Host: scsi0 Channel: 00 Id: 06 Lun: 00
   Vendor: HP   Model: CD-Writer+ 9200  Rev: 1.0e
   Type:   CD-ROM   ANSI SCSI revision: 04

Can you successfully access the CD writer?

Abel

[sane-devel] Canoscan 2700f

[abel deuring]

Jonathan Knight wrote:
 
 Arrggh...
 
 I cannot believe it was something so stupid that caused by 2700F not to
 work.
 
 Okay.  Here's what I did.
 
 I took Abel's advice.  I put the sg module back to the default.  I reset the
 default buffer size to the standard 32K and ran up sane 1.0.13.
 
 I duly collected the output and noted the error at the end
 
 [sanei_scsi] sanei_scsi_req_wait: read 64 bytes
 [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
 [sanei_scsi] sense buffer: f0 00 44 00 00 00 00 06 00 00 00 00 60 00 00 00
 [sanei_scsi] target status: 02 host status:  driver status: 0008
 [canon]  sense_handler
 [canon] canon_sense_handler(3, 0x8055718, (nil))
 [canon] sense buffer: f0 00 44 00 00 00 00 06 00 00 00 00 60 00 00 00
 [canon] sense message: problem not analyzed (unknown SCSI class)
 
 A quick rumage on the net reveals that 44 is hardware error and 60 00 is
 lamp failure.  I'd decoded this two days ago and ignored it because quite
 clearly the lamp was fine.


Jonathan,

firstly: great to hear that most of your problems are fixed now.

The lack of really meanful error messages in Sane bother me since quite 
some time. Many SCSI scanners can return sense data similar the to that 
you mentioned (other errors I've seen or read about are fuse blown 
[ok, obviously not for every fuse ;)], location of paper jam, 
calibration error), but to only way Sane can reported them at present is 
via debug messages. Hopefully we can fix that with Sane version 2. That 
should save users a few gray hairs.

 I quickly followed up with scanimage -d 'canon:/dev/sg3' which bombed.  
 H.
 Tried xsane which gave a segmentaion failure.  Not to worry - I've got five
 versions of sane ready to test, lets see what the latest version is that
 works.
 
 I can now report that sane-1.0.11 now works perfectly with my 2700F with no
 messing with the SG module and a default buffer size of 32768.  However
 1.0.12 and 1.0.13 do not work so something funny happened there.  Is anyone
 fixing the problem or shall I try to make ammends for my foolishness by
 trying to track down the bug?

I think we don't don't need amends or apologies or whatever ;) But if 
you feel comfortable debugging Sane, go ahead ;) Anyway, I don't know 
that much about the Canon backend, but some other part of Sane may also 
have caused the crash. So, could you run scanimage or xsane under gdb, 
so that we can get clue, where the error occurs? (as usual, setting 
SANE_DEBUG_SANEI_SCSI and SANE_DEBUG_CANON is also useful.)

cheers
Abel

[sane-devel] Canoscan 2700f

[abel deuring]

Jonathan Knight wrote:
 
 Hi everyone.
 
 I have a canoscan 2700F which has been the bain of my life on Linux since
 the day I bought it.  It basically doesn't work at all unless you fiddle
 a number of things to get it working.  I would like to make contact with
 other 2700F owners who have successfully got the canoscan to run on Redhat 9.
 
 I had the scanner running on redhat 9 until a recent up2date which patched
 the kernel and sane.  Since then nothing worked.  I've gone through my
 checklist of things that need to be fiddled with and all of those seem fine.
 The sense buffer that's returned for sane 1.0.12 gives a lamp failure.  On
 1.0.5 the process hangs when trying to preview or scan.
 
 For the record - here's the checklist I go through:
 
 1.  Make sure IRQ 10 is set for legacy ISA in the BIOS

So you have an ISA SCSI adapter? they may indeed be a bit difficult to
configure. If this really bothers you, I'd recommend to buy a cheap PCI
SCSI adapter. You can get good used one for a few Euro or Pound at Ebay.
My personal favourites are adapters that work with the sym53c8xx driver
or the aic7xxx driver. And with a PCI SCSI adapter, you'll be able to
use SCSI transfer block sizes larger then 64kB.

 2.  echo 131072  /proc/scsi/sg/def_reserved_size

A buffer size larger than 64k is not reasonable for ISA adapters, due to
the broken ISA DMA architecture. Moreover, Sane negotiates the size of
the buffer independly (OK, perhaps not in Sane 1.0.5 -- I'd need to look
into the sources to be sure), but version 1.0.12 definitely does this.

 3.  patch sg.c with the non-standard scsi command lengths

This patch is only necessary for really old SG drivers -- no need tor a
recent Linux version like RH9.

 4.  configure /etc/sane.d/canon.conf
 
 (I do smile when sane lists the 2700F driver status as good when in order
 to get it working you have to patch and recompile the kernel.  Hardly
 something most users will consider an easy option)

As said above, it should not be necessary to recompile the SG driver
since, ummm, I guess, at least 3 or 4 years. Can't recall, when exactly
the SG driver (version 2.x) got the ability to explicitly set the
command length, and when I made sanei_scsi.c aware of the capabilities
of version 3 of the SG driver.

 
 That list has managed to get the scanner to run under redhat 7 and 9 until
 now.  If anyone has the scanner running under the latest redhat 9 kernel
 then I'd like to know what else needs changing to achieve that.
 
 I intend to try and older version of sg.c to see if that's the problem.

Alternatively, it would be intersting to see what exactly goes wrong
with the unpatched SG driver. The output of SANE_DEBUG_CANON=255
SANE_DEBUG_SANEI_SCSI=255 scanimage (or the output some other Sane
program with SANE_DEBUG_CANON and SANE_DEBUG_SANEI_SCSI set to 255)
would give us a clue. 

Abel

[sane-devel] scanimage cannot see Umax Astra 2100S scanner.

[abel deuring]

Russ,
 
 Just in case I missed the intention I will repeat.
 
 a. run 'SANE_DEBUG_UMAX=255 scanimage -d umax:/dev/scanner'
 b. run 'SANE_DEBUG_SANEI_SCSI=255 scanimage -d umax:/dev/scanner'

These nearly the comamnd I meant ;) But I'd like to see the _combined_
output from SANE_DEBUG_UMAX and SANE_DEBUG_SANEI_SCSI, so the command
would be:

SANE_DEBUG_UMAX=255 SANE_DEBUG_SANEI_SCSI=255 scanimage -d
umax:/dev/scanner

 
 I have run each of these commands seperately several times.
 When first run after installing the scanner from the command line
 either command completes with a long pause near the end of the run
 and the scanner activity led out.

That's the situation, about which we'll hopefulls get better information
from the debug output.

 Running another command finally reports 'Device busy' and to get the led to
 light I have to repower the scanner. At all times cat /proc/scsi/scsi
 shows the scanner installed.
 
 How can I get the output of the command written to file? 'command  
 (somename)'
 doesn't work for me. There is copious output, do you really want all of that
 in an email?

The '' redirection catches data sent to stdout, while the debug
messages are sent to stderr. You can redirect stderr into a file using
'2' instead of '', i.e.:

SANE_DEBUG_UMAX=255 SANE_DEBUG_SANEI_SCSI=255 scanimage -d
umax:/dev/scanner 2 debug.txt

And yes, I'd indeed like to see the whole stuff ;) While most lines are
not that interesting, it is not that difficult to find the revelant
part(s) of the output. And the debug output is quite well compressed by
gzip or similar programs. So if you attach a compressed file to the
mail, nobody should complain. And if you think that the mail it is too
large for mailing list, send it only to me.

 Sorry for any misunderstanding.

never mind.

Abel

[sane-devel] scanimage cannot see Umax Astra 2100S scanner.

[abel deuring]

Russ Pitman wrote:
 
 abel deuring wrote:
  Russ,
  These nearly the comamnd I meant ;) But I'd like to see the _combined_
  output from SANE_DEBUG_UMAX and SANE_DEBUG_SANEI_SCSI, so the command
  would be:
 
  SANE_DEBUG_UMAX=255 SANE_DEBUG_SANEI_SCSI=255 scanimage -d
  umax:/dev/scanner
 
 Okay fine.
 
  SANE_DEBUG_UMAX=255 SANE_DEBUG_SANEI_SCSI=255 scanimage -d
  umax:/dev/scanner 2 debug.txt
 
 Maybe someone else has an interest,and you are right. It isn't so big after
 all.

Russ,

from a certain point on (line 679 in the debug output), many SCSI
commands sent to the scanner return an error: host status: 0004. A
non-zero host status means that something is wrong with the SCSI adapter
or with the driver of the adapter. A quick look into the advansys driver
gave me the impression that the driver returns this error as a sort of
generic failure indication (though I wouldn't claim to be a kernal
hacker). Perhaps /var/log/messages contains some details about the
problem.

Abel

[sane-devel] scanimage cannot see Umax Astra 2100S scanner.

[abel deuring]

Russ Pitman wrote:
 
 Thanks for replying.
 
 Henning Meier-Geinitz wrote:
 
  Check that /etc/sane.d exists and that there is a file dll.conf
  that's readable by everyone.
 
 My bad--dll.conf was missing. I confused the dll.conf file with the
 windows type .dll files and should know better :-(
 
  To enable debugging, try
 
  SANE_DEBUG_UMAX=255 scanimage -L
 
 Prints heaps and identifies the scanner at /dev/sg1 and/dev/scanner.
 
 Having found the scanner, running 'scanimage -d umax:/dev/scanner' fails.
 
 The scanner attempts to start up then dies, uninstalling the scanner in the
 process.
 Here is a partial screendump of the output of the command.
 
 ---
 hading_data
 [umax] 8 bit shading-line 63 read
 [umax] read_shading_data
 [umax] 8 bit shading-line 64 read
 [umax] send_shading_data
 [umax] shading-data sent
 [umax] start_scan
 [umax] starting scan
 [umax] sane_get_parameters
 [umax] reader_process started
 [umax] reader_process: allocating SCSI buffer[1]
 [umax] reader_process: starting to READ data
 [umax] trim_rowbufsize: row_bufsize = 84150 bytes = 33 lines
 [umax] reading 2983500 bytes in blocks of 84150 bytes
 [umax] wait_scanner
 [umax] scanner reports Error during device I/O, waiting ...
 

Russ,

could you run another test, this time with both SANE_DEBUG_UMAX and
SANE_DEBUG_SANEI_SCSI set to 255? This will give us probably better
clue, what is going wrong.

Abel