[sane-devel] (no subject)
Ok, herewith I join the long list of people having this trouble. Scanner: HP Scanjet 4P, SCSI card: Buslogic BT-54xC (ISA) SuSE Linux 7.3 i386 sane 1.0.5 from the distribution host CPU: P-III 450 > uname -a Linux ruru 2.4.16-4GB #1 Mon Apr 15 08:57:26 GMT 2002 i686 unknown > cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: HP Model: C1130A Rev: 3540 Type: ProcessorANSI SCSI revision: 02 > cdrecord -scanbus Cdrecord 1.10a04 (i486-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling Linux sg driver version: 3.1.20 Using libscg version 'schily-0.4' scsibus0: 0,0,0 0) * 0,1,0 1) * 0,2,0 2) * 0,3,0 3) 'HP ' 'C1130A ' '3540' Processor 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * > cat /etc/sane.d/hp.conf scsi HP /dev/sg0 option connect-scsi option disable-scsi-request # this make no difference > cat /etc/sane.d/dll.conf hp > sane-find-scanner ... sane-find-scanner: found processor "HP C1130A 3540" at device /dev/sg0 > scanimage -d hp:/dev/sg0 scanimage: open of device hp:/dev/sg0 failed: Error during device I/O With the card's bios (ctrl-B during boot) I set "fast transfers = no", "negotiate synchronous = no", "negotiate disconnect = no". No difference. I then compiled sane-1.0.7 backend, but no difference. The following output is from 1.0.7. If anyone has any ideas I'd really appreciate them... thanks. > env SANE_DEBUG_HP=255 /tmp/sane/bin/scanimage -d hp:/dev/sg0 [sanei_debug] Setting debug level of hp to 255. [hp] sane_init called [hp] sane_init will finish with Success [hp] sane_open called [hp] hp_read_config: hp backend v0.95 starts reading config file [hp] hp_read_config: processing line [hp] hp_read_config: processing line [hp] hp_read_config: attach scsi HP [hp] hp_get_dev: New device /dev/sg0, connect-scsi, scsi-request=1 [hp] sanei_hp_device_new: /dev/sg0 [hp] scsi_inquire: sending INQUIRE [hp] scsi_new: sending TEST_UNIT_READY [hp] scsi_flush: writing 2 bytes: [hp] 0x 1B 45.E [hp] scsi_flush: writing 7 bytes: [hp] 0x 1B 2A 73 32 35 37 45 .*s257E [hp] scl_inq: read failed (Error during device I/O) [hp] scl_errcheck: Can't read SCL error stack: Error during device I/O [hp] sanei_hp_device_new: SCL reset failed [hp] scsi_close: closing fd 5 [hp] hp_read_config: processing line [hp] hp_read_config: processing line <#option connect-device> [hp] hp_read_config: processing line [hp] hp_read_config: attach /dev/sg0 [hp] hp_get_dev: New device /dev/sg0, connect-scsi, scsi-request=0 [hp] sanei_hp_device_new: /dev/sg0 [hp] scsi_inquire: sending INQUIRE [hp] scsi_new: sending TEST_UNIT_READY [hp] scsi_flush: writing 2 bytes: [hp] 0x 1B 45.E [hp] scsi_flush: writing 7 bytes: [hp] 0x 1B 2A 73 32 35 37 45 .*s257E [hp] scl_inq: read failed (Error during device I/O) [hp] scl_errcheck: Can't read SCL error stack: Error during device I/O [hp] sanei_hp_device_new: SCL reset failed [hp] scsi_close: closing fd 4 [hp] hp_get_dev: New device /dev/sg0, connect-scsi, scsi-request=0 [hp] sanei_hp_device_new: /dev/sg0 [hp] scsi_inquire: sending INQUIRE [hp] scsi_new: sending TEST_UNIT_READY [hp] scsi_flush: writing 2 bytes: [hp] 0x 1B 45.E [hp] scsi_flush: writing 7 bytes: [hp] 0x 1B 2A 73 32 35 37 45 .*s257E [hp] scl_inq: read failed (Error during device I/O) [hp] scl_errcheck: Can't read SCL error stack: Error during device I/O [hp] sanei_hp_device_new: SCL reset failed [hp] scsi_close: closing fd 3 scanimage: open of device hp:/dev/sg0 failed: Error during device I/O [hp] sane_exit called [hp] sane_exit will finish > env SANE_DEBUG_SANEI_SCSI=1 /tmp/sane/bin/scanimage -d hp:/dev/sg0 [sanei_debug] Setting debug level of sanei_scsi to 1. [sanei_scsi] lx_chk_devicename: matched device(direct): /dev/sg0 [sanei_debug] Setting debug level of sanei_scsi to 1. [sanei_debug] Setting debug level of sanei_scsi to 1. [sanei_debug] Setting debug level of sanei_scsi to 1. [sanei_scsi] lx_chk_devicename: matched device(direct): /dev/sg0 [sanei_scsi] sanei_scsi_open: SG driver version: 30120 [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: 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_wait: SCSI command complained: Success [sanei_debug] Setting debug level of sanei_scsi to 1. [sanei_scsi] sanei_scsi_open: SG driver version: 30120 [sanei_scsi] sanei_scsi_open_extended: us
[sane-devel] building sane-frontends on OS/2
Hi, The sane-frontends build on OS/2 but I still have to make some small manual modifications. To build I have to 1. add '#define HAVE_VSYSLOG 1' to sane-frontends/include/sane/config.h 2. add '-llibsane -lsyslog -lpthreads -lsocket' to 'LIBS =' in sane-frontends/src/Makefile -lsocket is needed because of: g:\emx\lib/syslog.a(syslog.o): Undefined symbol _send referenced from text segment g:\emx\lib/syslog.a(syslog.o): Undefined symbol _socket referenced from text segment g:\emx\lib/syslog.a(syslog.o): Undefined symbol _connect referenced from text segment -lpthreads is needed because of: xcam.o: Undefined symbol _pthread_write referenced from text segment xcam.o: Undefined symbol _pthread_write referenced from text segment xcam.o: Undefined symbol _pthread_read referenced from text segment 3. Change 'GIMP_LIBS = -lgimp' to 'GIMP_LIBS = -lgimp121' in sane-frontends/src/Makefile Perhaps it is possible to reduce the number of the needed modifications. At least the HAVE_VSYSLOG problem was allready solved for sane-backends some time ago. config.log contains: ... configure:2415: checking for vsyslog configure:2443: gcc -o conftest.exe -D__EMX__ -DOS2 -Zmtd -D__ST_MT_ERRNO__ \ -fstack-check -O2 -mprobe -Wall -D_GNU_SOURCE -Zmtd -D__ST_MT_ERRNO__ \ -O2 -Zsysv-signals conftest.c -lm 1>&5 G:/TEMP\cca03801: Undefined symbol _vsyslog referenced from text segment ... Regards Franz
[sane-devel] Feature freeze for sane-1.0.8 active
Hello. Feature freeze for sane-1.0.8 is active. It is not allowed to add any new features to the CVS of sane. Allowed changes are bugfixes and documentation changes!!! - Code freeze is planned for may 21. - Release of sane-1.0.8 is planned for may 27. A sane CVS snapshot from 2002-05-02 can be downloaded from: http://www.mostang.com/sane Please test the CVS snapshot on all system you have access to and report all bugs and success! Bye Oliver -- Homepage: http://www.rauch-domain.de sane-umax: http://www.rauch-domain.de/sane-umax xsane: http://www.xsane.org E-Mail: mailto:oliver.ra...@rauch-domain.de
[sane-devel] segfault
--2fSbKhQ/kwrfWINy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, May 02, 2002 at 11:12:04PM -0400, Vladimir Dergachev wrote:
> Program received signal SIGSEGV, Segmentation fault.
> sane_sm3600_init (version_code=0xb278, authCB=0x8049270
> )
> at sm3600.c:384
> 384 DBG(DEBUG_JUNK,"found dev %04X/%04X\n",
> (gdb) list
> 379 DBG(DEBUG_JUNK,"scanning bus %s\n", pbus->dirname);
> 380 for (pdev=pbus->devices; pdev; pdev = pdev->next)
> 381 {
> 382 unsigned short *pidProduct;
> 383 iDev++;
> 384 DBG(DEBUG_JUNK,"found dev %04X/%04X\n",
> 385 pdev->descriptor.idVendor,
> 386 pdev->descriptor.idProduct);
> 387 /* the loop is not SO effective, but straight! */
> 388 for (pidProduct=aidProduct; *pidProduct; pidProduct++)
Hmm, smells like the same thing the gPhoto2 people have been seeing
with libusb.
> (gdb) print pdev
..but unfortunately, you didn't include enough information to be
sure. Does a recompile of libusb, and the sane, fix the problem?
Tim.
*/
--2fSbKhQ/kwrfWINy
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE80jpxyaXy9qA00+cRAjY1AKCAKCbR+SwgUhemFk0JtltYIp3/aACdFWUf
jhiWHf81h8nTMXMf/8URmSU=
=7HPR
-END PGP SIGNATURE-
--2fSbKhQ/kwrfWINy--
[sane-devel] building sane-frontends on OS/2
Hi, On Fri, May 03, 2002 at 12:05:52AM +0200, Franz Bakan wrote: > To build I have to > > 1. add '#define HAVE_VSYSLOG 1' to sane-frontends/include/sane/config.h > 2. add '-llibsane -lsyslog -lpthreads -lsocket' to 'LIBS =' in > sane-frontends/src/Makefile libsane should be automatically detected (sane-config --libs). > -lsocket is needed because of: > g:\emx\lib/syslog.a(syslog.o): Undefined symbol _send referenced from text > segment > g:\emx\lib/syslog.a(syslog.o): Undefined symbol _socket referenced from text > segment > g:\emx\lib/syslog.a(syslog.o): Undefined symbol _connect referenced from text > segment -lsocket/-lsyslog should work with the same "fix" as in sane-backends. This should also fix the #HAVE_VSYSLOG problem. Please try the latest sane-frontends CVS, I have just commited the change. > -lpthreads is needed because of: > xcam.o: Undefined symbol _pthread_write referenced from text segment > xcam.o: Undefined symbol _pthread_write referenced from text segment > xcam.o: Undefined symbol _pthread_read referenced from text segment Hm, as far as I know, sane-frontends doesn't use libpthred at all. Can you try to find out where this comes from? If this is from libgtk, the gtk-config script should take care to supply the correct libs. > 3. Change 'GIMP_LIBS = -lgimp' to 'GIMP_LIBS = -lgimp121' in > sane-frontends/src/Makefile Same here. gimp-config (or gimp-tool) --libs should return the correct names. I don't think we can do anything about this in SANE, because the name seems to change with every version (1.2.1 = 121, 1.2.2 = 122?) of gimp. Maybe the call of sane-config --libs, gtk-config and gimp-config doesn't work with OS/2? Bye, Henning
[sane-devel] (no subject)
V K wrote: > > Ok, herewith I join the long list of people having this trouble. > > Scanner: HP Scanjet 4P, SCSI > card: Buslogic BT-54xC (ISA) > SuSE Linux 7.3 i386 > sane 1.0.5 from the distribution > host CPU: P-III 450 > > > uname -a > Linux ruru 2.4.16-4GB #1 Mon Apr 15 08:57:26 GMT 2002 i686 unknown > > > cat /proc/scsi/scsi > Attached devices: > Host: scsi0 Channel: 00 Id: 03 Lun: 00 > Vendor: HP Model: C1130A Rev: 3540 > Type: ProcessorANSI SCSI revision: 02 > [...] > [sanei_scsi] sanei_scsi_req_wait: read 64 bytes > [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success > [sanei_scsi] sense buffer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > [sanei_scsi] target status: 00 host status: 0007 driver status: 0027 > scanimage: open of device hp:/dev/sg0 failed: Error during device I/O Volker, that's a bug of the Buslogic driver. The author of the driver knows about the problem but he seems to be really short of time... Abel
[sane-devel] segfault
On Fri, 3 May 2002, Tim Waugh wrote:
> On Thu, May 02, 2002 at 11:12:04PM -0400, Vladimir Dergachev wrote:
>
> > Program received signal SIGSEGV, Segmentation fault.
> > sane_sm3600_init (version_code=0xb278, authCB=0x8049270
> > )
> > at sm3600.c:384
> > 384 DBG(DEBUG_JUNK,"found dev %04X/%04X\n",
> > (gdb) list
> > 379 DBG(DEBUG_JUNK,"scanning bus %s\n", pbus->dirname);
> > 380 for (pdev=pbus->devices; pdev; pdev = pdev->next)
> > 381 {
> > 382 unsigned short *pidProduct;
> > 383 iDev++;
> > 384 DBG(DEBUG_JUNK,"found dev %04X/%04X\n",
> > 385 pdev->descriptor.idVendor,
> > 386 pdev->descriptor.idProduct);
> > 387 /* the loop is not SO effective, but straight! */
> > 388 for (pidProduct=aidProduct; *pidProduct; pidProduct++)
>
> Hmm, smells like the same thing the gPhoto2 people have been seeing
> with libusb.
>
> > (gdb) print pdev
>
> ..but unfortunately, you didn't include enough information to be
> sure. Does a recompile of libusb, and the sane, fix the problem?
I am using libusb-0.1.5 the latest, it was compiled recently, just before
I compiled sane. The error above appears when using CVS snapshot from a
couple of days ago.
Vladimir Dergachev
>
> Tim.
> */
>
[sane-devel] segfault
Hi, On Thu, May 02, 2002 at 11:12:04PM -0400, Vladimir Dergachev wrote: > System: PIII-500mhz, One unsupported (yet) USB scanner. No supported usb > scanners. scanimage segfaults, gdb trace at the bottom of this e-mail. This one doesn't look like the usual crash in libusb. Nevertheless, please check that libusb is at least 0.1.3b. If you don't have a Microtek ScanMaker 3600, you can just disable sm3600 in dll.conf. Bye, Henning
[sane-devel] ANN: New backend for Tevion MD9693/Medion MD9705
Hi, the first version of the backend is available here: http://www.angelfire.com/linux/crapsite/ This backend will probably also work with the Artec E+ 48U (untested). Features: Scan-modes: gray/color Bitdepth: 8/16 bit per channel Resolutions: 50,100,200,300,600 dpi Please note: I still don't know, how the calibration works, therefore you currently need the calibration files generated by the windoze driver. You also need the firmware file, which is located in the Win98 (e.g) directory on the installation CD. If you don't have windoze, you can't use the scanner under Linux/Unix (quite strange :-). Thanks to -Sergey Vlasov, for writing the gt68xx test program, on which the backend is based, and for his useful advice. -David Stevenson for his help. -Martin Moeller for testing. Please report bugs, there are plenty of them :-) Michael
[sane-devel] Handling buttons
I need to include some options of type BUTTON in a new backend. These are for things like calibration which take a significant time to complete. When I use scanimage as a test, it always goes ahead and attempts a scan when those options are specified. Other than using a different, possibly home-grown, frontend for testing, is there any standard solution? -- Dave CloseDreamworks SKG, Animation Technology +1 818 695 6962 Glendale California 91201-3007 dcl...@anim.dreamworks.comhttp://www.dreamworks.com/
[sane-devel] Handling buttons
Dave Close wrote: > > I need to include some options of type BUTTON in a new backend. These are > for things like calibration which take a significant time to complete. > When I use scanimage as a test, it always goes ahead and attempts a scan > when those options are specified. Other than using a different, possibly > home-grown, frontend for testing, is there any standard solution? Add option "-h" after the option of the button, then scanimage does not start a scan. To avoid the output redirect output of scanimage to /dev/null: scanimage --buttonfunction -h >/dev/null Bye Oliver -- Homepage: http://www.rauch-domain.de sane-umax: http://www.rauch-domain.de/sane-umax xsane: http://www.xsane.org E-Mail: mailto:oliver.ra...@rauch-domain.de
[sane-devel] Dimension ranges
Henning Meier-Geinitz wrote:
>I see. I don't like counting starting by 0 :-)
SANE permits the boundaries of a scan to be expressed in whatever units
the backend supports. Many support standard units like millimeters or
inches. Some support actual pixels. But I'm a little confused about how
to think about the difference.
Consider a scanner capable of an image up to US letter size, 8.5 inches
by 11 inches. If expressed in inches, the X SANE_Range might be { 0,
8.5, 0 }. If the resolution is 300 dots per inch, this would translate
to a SANE_Range in pixels of { 0, 2550, 0 }. But that isn't quite right.
To achieve an image of maximum width, a frontend might set the top-left
X position to 0 inches and the bottom-right X position to 8.5 inches.
Converted to pixels, these settings would be 0 and 2550. But that can't
be: there are 2551 pixels in that range, one too many.
A backend which wants to use pixels for dimensions might solve this by
setting the range to either { 0, 2449, 0 } or { 1, 2550, 0 }. Is there
a preferred solution?
--
Dave CloseDreamworks SKG, Animation Technology
+1 818 695 6962 Glendale California 91201-3007
dcl...@anim.dreamworks.comhttp://www.dreamworks.com/
[sane-devel] Dimension ranges
Hello Dave,
the backend should not use the length unit pixel when it
can use the length unit millimeters.
The lngth unit pixle e.g. is for digital cameras and other
devices that do not use or know about a resolution.
Bye
Oliver
Dave Close wrote:
>
> Henning Meier-Geinitz wrote:
> >I see. I don't like counting starting by 0 :-)
>
> SANE permits the boundaries of a scan to be expressed in whatever units
> the backend supports. Many support standard units like millimeters or
> inches. Some support actual pixels. But I'm a little confused about how
> to think about the difference.
>
> Consider a scanner capable of an image up to US letter size, 8.5 inches
> by 11 inches. If expressed in inches, the X SANE_Range might be { 0,
> 8.5, 0 }. If the resolution is 300 dots per inch, this would translate
> to a SANE_Range in pixels of { 0, 2550, 0 }. But that isn't quite right.
>
> To achieve an image of maximum width, a frontend might set the top-left
> X position to 0 inches and the bottom-right X position to 8.5 inches.
> Converted to pixels, these settings would be 0 and 2550. But that can't
> be: there are 2551 pixels in that range, one too many.
>
> A backend which wants to use pixels for dimensions might solve this by
> setting the range to either { 0, 2449, 0 } or { 1, 2550, 0 }. Is there
> a preferred solution?
> --
> Dave CloseDreamworks SKG, Animation Technology
> +1 818 695 6962 Glendale California 91201-3007
> dcl...@anim.dreamworks.comhttp://www.dreamworks.com/
>
> ___
> Sane-devel mailing list
> sane-de...@www.mostang.com
> http://www.mostang.com/mailman/listinfo/sane-devel
--
Homepage: http://www.rauch-domain.de
sane-umax: http://www.rauch-domain.de/sane-umax
xsane: http://www.xsane.org
E-Mail: mailto:oliver.ra...@rauch-domain.de
[hpoj-devel] [sane-devel] xsane infinite recursion
Oliver Rauch wrote: > David Paschal wrote: > > Or did you mean to say that the backend uses "int" instead of "float"? :-) > > > > So if the float->int round-up is the problem, then I should change the > > backend to use SANE_TYPE_FIXED(=2) for the geometry options fix this > > problem. > > This would solve the problem, but I think xsane also will be able to handle > int values in this case. > > Changin the option type to float also would allow xsane to specify the scan a > rea > more exact than 1 mm. Hi, Oliver. I have changed the backend to use SANE_TYPE_FIXED instead of SANE_TYPE_INT, and it fixes the problem with switching xsane to "Copy" or "Fax" mode. Hopefully you can still fix the problem in xsane that allowed the runaway recursion to happen in the first place. Once you have fixed that, I can test it by changing one line in the backend to temporarily switch back to SANE_TYPE_INT. David
