* Kai Timmer <em...@kait.de> [2006-02-17 16:06]:
> Hello,
> i have a problem with my "Umax AstraSlim SE". The scanner only produces
> output like this: http://arda.kait.de/out.png any ideas?
Nobody with an idea what i can do? Under Windows the Scanner runs fine.
So it is not ab problem with the Hardware.

Greets,
-- 
Kai Timmer             | Jabber-ID: k...@jabber.ccc.de
PGP-Key ID: 0x69502566 | Blog: http://www.kaitimmer.de
  "Information ist schnell. Wahrheit braucht Zeit."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060218/27443c9a/attachment.pgp
From jaros...@aster.pl  Sat Feb 18 09:01:17 2006
From: jaros...@aster.pl (Jaroslaw Gorny)
Date: Sat Feb 18 09:20:57 2006
Subject: [sane-devel] snapscan: scanner model
Message-ID: <200602181001.27217.jaros...@aster.pl>

Hi,
Please, forgive me if this is too easy question for You, but I'm starting 
playing with sane.
I've got Epson Perfection 2580 Photo which is recognized by snapscan as 2480, 
because they both got the same id: 0x04b8/0x0121.

I'm wondering if there is a way to know real model in such a situation.
It can be helpful, because 2580 differs from 2480 (has a motor which 
transports 36mm film).

thanks,

-- 

Jaroslaw Gorny
jaros...@aster.pl


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GMU/E/CS d+/-- s+: a- c++ UL++/US P+>++ L+++>++++
E>++ W N++ o? K w--- !O M V- PS+++ PE++ Y PGP>++ t 5
X- R- tv--/!tv b++ DI-- D G- e++>+++ h-- r+++ z+++
-----END GEEK CODE BLOCK-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060218/7e030d06/attachment.pgp
From lorenzo.del...@tiscali.it  Fri Feb 17 20:10:39 2006
From: lorenzo.del...@tiscali.it (Lorenzo Delana)
Date: Sat Feb 18 09:33:18 2006
Subject: [sane-devel] Mustek BP 1200 CU PLUS / Bug
In-Reply-To: <200601262134.30414.lorenzo.del...@tiscali.it>
References: <200601180008.18776.lorenzo.del...@tiscali.it>
        <20060122155958.gf10...@meier-geinitz.de>
        <200601262134.30414.lorenzo.del...@tiscali.it>
Message-ID: <200602172110.39315.lorenzo.del...@tiscali.it>

On Thursday 26 January 2006 21:34, Lorenzo Delana wrote:
> At 16:59, 22 jan 2006, Henning Meier-Geinitz wrote:
> > Hi,
> >
> > On 2006-01-18 00:08, Lorenzo Delana wrote:
> > > I have a Mustek BP 1200 CU PLUS scanner A4, that /proc/bus/usb/devices
> > > describe as:
> >
> > I have the same scanner and it works flawlessly. Also many others use
> > this scanner.
> >
> > > 1) I installed cvs version of sane-backend and when I use scanimage the
> > > problem go in Segmentation Fault;
> > > to solve this I have to add a NULL POINTER check on the line 461 of the
> > > code so that:
> >
> > I assume this is in sanei/sanei_usb.c?
>
> right
>
> > > -------------
> > >   case USB_CLASS_PER_INTERFACE:
> > >             if (dev->config[0].interface[interface].altsetting)
> > >             switch (dev->config[0].interface[interface].altsetting[0].
> > >                     bInterfaceClass)
> > >               {
> > > ----------------
> > > This because altsetting something got me a NULL, then altsetting[0] is
> > > dereferencing a null pointer.
> >
> > How can altsetting[0] be 0? This means that an interface exists but no
> > altsetting. I'm not that used to the USB spec but I would be surprised
> > if this is allowed. Anyway, if your scanner does this, it can't scan
> > because it's broken. I rather assume that it happens with some other
> > device connected to your USB. Could you try to find out which device
> > behaves this way? And please send a log with USB debugging enabled:
> > SANE_DEBUG_SANEI_USB=255 scanimage -L
>
> I'm sorry but I'm not able to reproduce this behavior.
>
> Now that I'm completed the installation of my linux os from scratch maybe
> that something that lacks before in the system now is present ( I think
> something about devices udevd etc.. ) not generate more the error :(
>

Now the problem of SEGMENTATION FAULT goes, so this is the log:

/usr/src/i/sane-backends# SANE_DEBUG_SANEI_USB=255 scanimage -L
[sanei_debug] Setting debug level of sanei_usb to 255.
[sanei_usb] sanei_usb_init: Looking for kernel scanner devices
[sanei_usb] sanei_usb_init: Looking for libusb devices
usb_set_debug: Setting debugging level to 255 (on)
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_busses: Skipping non bus directory devices
usb_os_find_devices: Found 002 on 002
usb_os_find_devices: Found 001 on 002
error obtaining child information: Inappropriate ioctl for device
usb_os_find_devices: Found 007 on 001
usb_os_find_devices: Found 005 on 001
usb_os_find_devices: Found 004 on 001
usb_os_find_devices: Found 002 on 001
invalid descriptor length of 114
Unable to parse descriptors
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Invalid argument
[sanei_usb] sanei_usb_init: device 0x04a9/0x1091, interface 0 doesn't look 
like a scanner (0/7)
[sanei_usb] sanei_usb_init: device 0x04a9/0x1091: no suitable interfaces
[sanei_usb] sanei_usb_init: device 0x0000/0x0000 looks like a root hub
[sanei_usb] sanei_usb_init: found libusb device (0x055f/0x021c) interface 0  
at libusb:001:007
[sanei_usb] sanei_usb_init: found libusb device (0x2040/0x9301) interface 0  
at libusb:001:005
[sanei_usb] sanei_usb_init: device 0x05e3/0x0605, interface 0 doesn't look 
like a scanner (9/9)
[sanei_usb] sanei_usb_init: device 0x05e3/0x0605: no suitable interfaces
Segmentation fault

AFTER PATCHING:

/usr/src/sane-backends# 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.

  # No SCSI scanners found. If you expected something different, make sure 
that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

found USB scanner (vendor=0x055f, product=0x021c [USB Scanner], chip=GT-6816) 
at libusb:001:007
found USB scanner (vendor=0x2040 [Hauppaug], product=0x9301 [SOHO-FX2]) at 
libusb:001:005
  # Your USB scanner was (probably) detected. It may or may not be supported 
by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

AND THE SCANNER WORKS...

Available to make more debug log hope help in make wonderful sane more stable 
than already it is in major cases.

lore

> > As an alernative to a strangely acting device, there could be a
> > problem with libusb. However, this is the first time I hear about such
> > trouble.
> >
> > I'll add some checks for altsetting !=0 to sanei_usb as they don't
> > harm. But I think the problem is somewhere else.
>
> Is a good idea, maybe some other user in future can occur in my same
> problem and can read a line like
> "altsetting bug: this should not happen, please send email to mailing-list
> with `SANE_DEBUG_SANEI_USB=255 scanimage -L' output result" :-)
>
> > > 3) as for 1) in tools/sane-find-scanner.c at line 627
> >
> > Could you send the output of "sane-find-scanner -v -v", please?
> >
> > > 4) at backend/gt68xx_high.c
> > > I have commented out the check for the status, because in this point
> > > the program blocks forever ( for my scanner ). changing status =
> > > SANE_STATUS_GOOD for quickly replacement.
> >
> > Which status exactly? Which line of the code? Please send a log file
> > of a scan where it blocks (without your change).
>
> --- p/sane-backends/backend/gt68xx_high.c       2006-01-02
> 17:59:02.000000000 +0100
> +++ gt68xx_high.c       2006-01-25 21:54:17.000000000 +0100
> @@ -669,11 +669,14 @@
>
>    if (scanner->auto_afe)
>      {
> -      if (scanner->dev->model->is_cis)
> -       status = gt68xx_afe_cis_auto (scanner);
> -      else
> -       status = gt68xx_afe_ccd_auto (scanner, request);
> +      /*
> +            if (scanner->dev->model->is_cis)
> +       status = gt68xx_afe_cis_auto (scanner);
> +            else
> +       status = gt68xx_afe_ccd_auto (scanner, request);
> +      */
>
> +  status = SANE_STATUS_GOOD;
>        if (status != SANE_STATUS_GOOD)
>         {
>           DBG (5, "gt68xx_scanner_calibrate: gt68xx_afe_*_auto failed:
> %s\n",
>
> I tried to break with the debugger at `gt68xx_scanner_calibrate' before
> calling `gt68_afe_cis_auto` and the result for struct request is:
>
> (gdb) print *request
> $8 = {x0 = 0, y0 = 0, xs = 14221312, ys = 19595264, xdpi = 300, ydpi = 300,
> depth = 8, color = 0,
>   mbs = -4172048, mds = 32767, mas = -1431604571, lamp = 1, calculate = 0,
> use_ta = 0, backtrack = 1,
>   backtrack_lines = 16}
>
> and the result for *scanner is in the attached `log3'.
>
> NOTE: my platform is an AMD 64bit X2 with 64bit linux kernel and mixed
> 32/64 bit multilib and the OS installed is from scratch
> (www.linuxfromscratch.org). My kernel 2.6.14.5
> Linux alpha 2.6.14.5 #12 SMP Thu Jan 19 CET 2006 x86_64 x86_64 x86_64
> GNU/Linux
> My compiler is gnu gcc 4.0.2
>
> my scanimage dependancies:
> ldd `which scanimage`
>         libsane.so.1 => /opt/lib/libsane.so.1 (0x00002aaaaabc7000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaaaccd000)
>         libusb-0.1.so.4 => /opt/lib/libusb-0.1.so.4 (0x00002aaaaadd1000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaaaeda000)
>         libm.so.6 => /lib64/libm.so.6 (0x00002aaaaafef000)
>         libjpeg.so.62 => /opt/lib/libjpeg.so.62 (0x00002aaaab174000)
>         libc.so.6 => /lib64/libc.so.6 (0x00002aaaab2a2000)
>         /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
>
> Now I found the thing: the problem is that calibrate process takes long
> time for me depending if I have the cover of the scanner opened or closed,
> but in any case takes very long time before start and I thinked that's
> forever loop for the program but thisn't.
>
> In fact if I have the cover opened before scanimage start it takes 53
> seconds
>
> real    0m53.263s
> user    0m0.024s
> sys     0m0.028s
> attached log file : calib_log2
>
> If the cover is closed the scanimage takes 11 seconds to start
>
> real    0m11.465s
> user    0m0.008s
> sys     0m0.012s
> attached log file : calib_log1
>
> in any case for the 4) the scanner works, the only problem is the slow
> startup caused by the calibration process.
>
> It's normal this long calibration time ?
>
> > Bye,
> >   Henning
>
> thnx
> lorenzo

Reply via email to