* 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