[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread T. Ribbrock
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 08, 2003 at 12:23:44AM +0100, abel deuring wrote:
 Dr. Ing. Dieter Jurzitza wrote:

[Problem with Mustek Scanner on UltraSparc/Linux]

 [sanei_scsi] sanei_scsi.issue: 0x70260008
 dev_max(currently)=11 max_active_device=6 (origin 1)
  scsi_dma_free_sectors=2192 sg_pool_secs_aval=320 def_reserved_size=32768
   device=sg5 scsi1 chan=0 id=2 lun=0   em=0 sg_tablesize=127 excl=1
FD(1): timeout=6ms 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=22) Invalid argument -1
 
 errno 22 is EINVAL; this error is returned by the SG driver for version 
 3 SG headers, if the header size passed by the caller (i.e., 
 sanei_scai.c, functions sanei_scsi_req_enter and issue) in a write() or 
 read() call does not match the size expected by the SG driver.
[...]

Sorry to barge in here, but as it happens I've been stumped by the
very same problem, so I thought I'd add some data:

I've seen it happen on two different configurations (both times with a
Mustek 600 II CD Scanner):

Box 1: Sun UltraSparc 5/400, no-name Symbios 53c810 SCSI card, no SCSI
   disks, Aurora Sparc Linux 0.42 w/ kernel 2.4.20, sane-backends
   1.0.7 (as comes with Aurora 0.42) and 1.0.9 (test build from
   the tarball)

Box 2: Sun UltraSparc 1/140, on-board esd SCSI controller, two SCSI
   disks, Aurora Sparc Linux 0.42 w/ kernel 2.4.18, sane 1.0.7 and
   1.0.9.

I'll include the output from
SANE_DEBUG_SANEI_SCSI=255 sane-find-scanner -vv  logfile 21
for the latter config at the end.

Note: I built only sane-backends-1.0.9 and used this command to build:
CFLAGS=-g -O -Wall ./configure --disable-shared
(given in the README to use if you want to debug).


I can confirm the errno=22 and it occurs in the write on line 1744
(sane 1.0.9) in sane_scsi.c - not knowing sane very well, I had to use
ddd to get there... ;-)

I've used the very same scanner with Aurora 0.4, sane 1.0.7 and
kernel 2.4.18 on a SparcStation 20 SMP and with Aurora 0.32, sane 1.0.7,
kernel 2.4.18 on a SparcStation 5/170 without any problems, so my
guess would indeed be that we're talking about a 32bit-64bit issue,
especially, as the SparcStations are using the same SCSI controller
(esd) as the UltraSparc 1.
Unfortunately, I'm not knowledgable enought to solve this myself... I
can, however, offer to run tests on my box, if that's of any help.

It would be great if this was solvable... The U5 is a good bit faster
than the SS20... ;-)

Regards,

Thomas

P.S.: I've also taken this up with the Aurora developers, but from
  what I've seen in the sane archves, it seems to be more of a
  sane problem, as it does occur with other Linux's on UltraSparc
  as well.
-- 
-
  Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919
   You have to live on the edge of reality - to make your dreams come true!

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=logfile

[sanei_debug] Setting debug level of sanei_scsi to 255.
[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=4 lun=0  num=2
[sanei_scsi] lx_chk_id: 0,0  0,0  4,4  0,0
[sanei_scsi] lx_chk_devicename: matched device(direct): /dev/sg2
[sanei_scsi] get_max_buffer_size for /dev/sg2: 131072
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: sanei_scsi_max_request_size=131072 bytes
[sanei_scsi] sanei_scsi_open: SG driver version: 30123
[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
[sanei_scsi] scsi_req_enter: entered 0x70242008
[sanei_scsi] sanei_scsi.issue: 0x70242008
dev_max(currently)=9 max_active_device=3 (origin 1)
 scsi_dma_free_sectors=96 sg_pool_secs_aval=320 def_reserved_size=32768
  device=sg2 scsi0 chan=0 id=4 lun=0   em=0 sg_tablesize=255 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=22) Invalid argument -1
[sanei_scsi] scsi_req_enter: queue_used: 0, queue_max: 1
[sanei_scsi] sanei_scsi_req_wait: waiting for 0x70242008
[sanei_scsi] sanei_scsi.issue: 0x70242008
[sanei_debug] Setting debug level of sanei_scsi to 255.
[sanei_scsi] sanei_scsi_open: SG driver version: 30123
[sanei_scsi] sanei_scsi_open: The device found for /dev/sg0 does not look like 
a scanner
[sanei_debug] Setting debug level of sanei_scsi to 255.

[sane-devel] configuration headaches on Mandrake 9.0

2003-01-10 Thread Olaf Meeuwissen
Hi all,

I've noticed that my hand-edited /etc/sane.d/epson.conf on a Mandrake
9.0 system may get truncated over a reboot.  Similar symptoms (empty
configuration file that is) have been reported in

 http://www.mostang.com/pipermail/sane-devel/2002-November/005006.html

if I understand correctly.

I have absolutely no trouble scanning with SCSI and USB EPSON scanners
when my /etc/sane.d/epson.conf reads:

  scsi EPSON
  usb /dev/usb/scanner0

The problem is that this file (and as far as I've been able to check,
only this file) may(!) get truncated over a reboot.  It's as if some
place an ` /etc/sane.d/epson.conf` is executed.  I've tried editing
several other configuration files, but so far these have survived all
reboots (as did my epson.conf, so far for reproducability :-()

I suspect that (one of) the Mandrake configuration tool(s), notably
scannerDrake, is not playing nice.  Does anyone have a clue?

I seriously dislike something zapping my hand-crafted configuation
files!
-- 
Olaf MeeuwissenEPSON KOWA Corporation, ECS
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
Penguin's lib!   -- I hack, therefore I am --   LPIC-2


[sane-devel] Canon-SCSI backend

2003-01-10 Thread Ulrich Deiters
I just made a few minor changes (fixed an uninitialized variable, inserted
checks for return status of some subroutines).

Sincerely yours,

Ulrich Deiters


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread abel deuring
T. Ribbrock wrote:
 On Wed, Jan 08, 2003 at 12:23:44AM +0100, abel deuring wrote:
 
Dr. Ing. Dieter Jurzitza wrote:
 
 
 [Problem with Mustek Scanner on UltraSparc/Linux]
 
 
[sanei_scsi] sanei_scsi.issue: 0x70260008
dev_max(currently)=11 max_active_device=6 (origin 1)
 scsi_dma_free_sectors=2192 sg_pool_secs_aval=320 def_reserved_size=32768
  device=sg5 scsi1 chan=0 id=2 lun=0   em=0 sg_tablesize=127 excl=1
   FD(1): timeout=6ms 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=22) Invalid argument -1

errno 22 is EINVAL; this error is returned by the SG driver for version 
3 SG headers, if the header size passed by the caller (i.e., 
sanei_scai.c, functions sanei_scsi_req_enter and issue) in a write() or 
read() call does not match the size expected by the SG driver.
 
 [...]
 
 Sorry to barge in here, but as it happens I've been stumped by the
 very same problem, so I thought I'd add some data:

Thomas,

More opinions / suggestions / reports are always welcome ;)

 
 I've seen it happen on two different configurations (both times with a
 Mustek 600 II CD Scanner):
 
 Box 1: Sun UltraSparc 5/400, no-name Symbios 53c810 SCSI card, no SCSI
disks, Aurora Sparc Linux 0.42 w/ kernel 2.4.20, sane-backends
1.0.7 (as comes with Aurora 0.42) and 1.0.9 (test build from
the tarball)
 
 Box 2: Sun UltraSparc 1/140, on-board esd SCSI controller, two SCSI
disks, Aurora Sparc Linux 0.42 w/ kernel 2.4.18, sane 1.0.7 and
1.0.9.
 
 I'll include the output from
 SANE_DEBUG_SANEI_SCSI=255 sane-find-scanner -vv  logfile 21
 for the latter config at the end.
 
 Note: I built only sane-backends-1.0.9 and used this command to build:
 CFLAGS=-g -O -Wall ./configure --disable-shared
 (given in the README to use if you want to debug).
 
 
 I can confirm the errno=22 and it occurs in the write on line 1744
 (sane 1.0.9) in sane_scsi.c - not knowing sane very well, I had to use
 ddd to get there... ;-)
 
 I've used the very same scanner with Aurora 0.4, sane 1.0.7 and
 kernel 2.4.18 on a SparcStation 20 SMP and with Aurora 0.32, sane 1.0.7,
 kernel 2.4.18 on a SparcStation 5/170 without any problems, so my
 guess would indeed be that we're talking about a 32bit-64bit issue,
 especially, as the SparcStations are using the same SCSI controller
 (esd) as the UltraSparc 1.
 Unfortunately, I'm not knowledgable enought to solve this myself... I
 can, however, offer to run tests on my box, if that's of any help.
 
 It would be great if this was solvable... The U5 is a good bit faster
 than the SS20... ;-)

The SS20 is as 32 bit machine, so this looks indeed like a 32/64 bit 
problem.

But is there really no way to compile Sane as a 64 bit program on an 
UltraSparc?

Another option could be to define a 64 bit version of struct sg_io_hdr 
in sanei_scsi.c and to use this struct for SG driver write calls. I am 
not sure though, if it is simply possible to convert 32 bit pointers to 
64 bit pointers by filling in leading zeros. Would be good to know a bit 
more, how 32 bit programs are run on the 64 bit platform.

Abel




[sane-devel] Canon-SCSI backend

2003-01-10 Thread Henning Meier-Geinitz
Hi,

On Fri, Jan 10, 2003 at 08:16:35AM +0100, Ulrich Deiters wrote:
 I just made a few minor changes (fixed an uninitialized variable, inserted
 checks for return status of some subroutines).

Ok. ChangeLog entry is missing :-)

Bye,
 Henning


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread T. Ribbrock
On Fri, Jan 10, 2003 at 10:41:45AM +0100, abel deuring wrote:
[...]
 The SS20 is as 32 bit machine, so this looks indeed like a 32/64 bit 
 problem.
 
 But is there really no way to compile Sane as a 64 bit program on an 
 UltraSparc?

I jst checked back with some Aurora folks and they confirmed what I
already thought: Userland on UltraSparc is mostly 32bit - only where
it's really needed 64bit is used. 32bit apps and libs are also assumed
to be faster.

For sane this means that to compile sane 64bit one would have to
(re-)build *all* related libraries (starting with libc, libm, etc.pp.)
64bit - quite a lot of work.

The default is 32bit, so I'd say that sane should be able to cope with
that... :-}


 Another option could be to define a 64 bit version of struct sg_io_hdr 
 in sanei_scsi.c and to use this struct for SG driver write calls. I am 
 not sure though, if it is simply possible to convert 32 bit pointers to 
 64 bit pointers by filling in leading zeros. Would be good to know a bit 
 more, how 32 bit programs are run on the 64 bit platform.

Unfortunately, neither do I know this. Has that issue been resolved
for Alpha machines?

Cheerio,

Thomas
-- 
-
  Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919
   You have to live on the edge of reality - to make your dreams come true!


[sane-devel] backend for HP5470c (and probably HP5400 family)

2003-01-10 Thread Thomas Soumarmon
Hello everybody,

Owning an excellent HP scanjet 5470c scanner, I would like to make it wor=
k=20
with my mandrake 9.0 linux box as I would like to get rid of Win2k.

USB Snoopy helped me to get some logs of :
* turn on/off the scanner
* turn on/off the HP scanning software
* preview scan in full color
* scan whole area in Black  White

using these logs and the testtool upon libusb by Bertrik Sikken=20
(http://home.kabelfoon.nl/~bertrik/hp5400/index.html),  I managed to make=
 the=20
scanner move but not to scan as some bulk_written data are missing in the=
=20
logs and also because I have till now no experience with writing device=20
drivers.

Finally, is there anyone out there who dedicates some time to write a bac=
k-end
for this family of scanner ? Could I help him/her in some way ?
Else, is there a how-to about writing sane backend ?


Happy new year to the sane family.

Thomas


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread T. Ribbrock
On Fri, Jan 10, 2003 at 01:26:34PM +0100, abel deuring wrote:
 T. Ribbrock wrote:
[...]
  For sane this means that to compile sane 64bit one would have to
  (re-)build *all* related libraries (starting with libc, libm, etc.pp.)
  64bit - quite a lot of work.
 
 So you run *only* 32 bit applications?

Pretty much so. Solaris 8 on an UltraSparc is the same, by the way -
just checked. Userland is pretty much 32bit, unless 64bit is
explicitly needed.


 I asked Doug Gilbert, the maintainer of the SG driver, for hints how to
 solve the problem. While he agrees with my diagnosis, he had no easy
 solution at hand. It simply does not work to pass 32 bit pointers from a
 application, where the kernel expects 64 bit pointers. Using the old SG
 interface would make things a bit easier, because no pointers are passed
 as parameters. But the size of the ints in struct sg_header might
 nevertheless be a problem.

Hm. I am by no means an expert in any way, but I'd naively assume that
this type of problem must have been encountered (and maybe solved) by
other programs as well? I wonder how things like cdrecord or suchlike
work on these platforms. Mind you, I'm just brainstorming a bit... :-}


  Unfortunately, neither do I know this. Has that issue been resolved
  for Alpha machines?
 
 I don't know. But according to Doug , similar problems exist for Itanium
 processors. 

Then I'd be surprised if Alpha was any better - I find it kind of
telling that http://www.mostang.com/sane/sane-support.html lists lots
of ? for the 64bit platforms... ;-)

Cheerio,

Thomas
-- 
-
  Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919
   You have to live on the edge of reality - to make your dreams come true!


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread Henning Meier-Geinitz
Hi,

On Fri, Jan 10, 2003 at 01:46:55PM +0100, T. Ribbrock wrote:
   Unfortunately, neither do I know this. Has that issue been resolved
   for Alpha machines?
  
  I don't know. But according to Doug , similar problems exist for Itanium
  processors. 
 
 Then I'd be surprised if Alpha was any better - I find it kind of
 telling that http://www.mostang.com/sane/sane-support.html lists lots
 of ? for the 64bit platforms... ;-)

??? really means untested. E.g. I have access to some exotic
platforms, but only remote and they don't have scanners. So I can only
test compilation but not USB or SCSI.

If we get reports about real tests with scanners, the entries will be
changed to yes or no.

Bye,
  Henning


[sane-devel] backend for HP5470c (and probably HP5400 family)

2003-01-10 Thread Henning Meier-Geinitz
Hi,

On Fri, Jan 10, 2003 at 01:01:58PM +0100, Thomas Soumarmon wrote:
 Else, is there a how-to about writing sane backend ?

No howto, but some things to check for or to avoid:
doc/backend-writing.txt.

Bye,
  Henning


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread T. Ribbrock
On Fri, Jan 10, 2003 at 02:21:48PM +0100, Henning Meier-Geinitz wrote:
[...]
 ??? really means untested. E.g. I have access to some exotic
 platforms, but only remote and they don't have scanners. So I can only
 test compilation but not USB or SCSI.

Ah, thanks for the clarification!


 If we get reports about real tests with scanners, the entries will be
 changed to yes or no.

Should we ever get this to work I'll happily submit a report... For
the time being, the User-level SCSI support status for Linux 2.4
Sparc64 should probably be no... :-}

And while we're at it - for sane 1.0.7:

Linux 2.4 Sparc32, gcc 2.96, User-level SCSI support: yes, USB: ???,
shared and dynamic library support: yes, X11 clients: ???
URL: http://www.ultralinux.org
Tested with only one Mustek scanner, but on two different
SparcStations...


Cheerio,

Thomas
-- 
-
  Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919
   You have to live on the edge of reality - to make your dreams come true!


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread T. Ribbrock
On Fri, Jan 10, 2003 at 01:46:55PM +0100, T. Ribbrock wrote:
[...]
 Hm. I am by no means an expert in any way, but I'd naively assume that
 this type of problem must have been encountered (and maybe solved) by
 other programs as well? I wonder how things like cdrecord or suchlike
 work on these platforms. Mind you, I'm just brainstorming a bit... :-}
[...]

While I'm at it (the brainstorming, I mean) - I had a look at the
cdrecord source - besides the fact the Joerg Schilling doesn't seem to
happy with Linux' sg driver :-} I noticed that he's got some code in
his scsi-linux with regard to misalignment, especially for non-ix86 -
could that be something? Shot in the dark, I know...

Cheerio,

Thomas
-- 
-
  Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919
   You have to live on the edge of reality - to make your dreams come true!


[sane-devel] epson perfection 660

2003-01-10 Thread Jaeger, Gerhard
Hi there,

in the end we got it so far:
The Epson 660 seems to be a rebadged AGFA scnapscan e26
-- see below.

As scanimage currently does not work you might ask
the AGFA specialists on the sane mailing list...

Gerhard

BTW: No need to cc the mail to me!

On Friday, 10. January 2003 00:06, tcp-isim tcp-isim wrote:
 Hi

 I saw in a window directory this file called
 scanner.dat:

 [SupportScannerNo]
 Number=2

 [ScannerModel]
 ;   Model Name,Length,NeedCheckOem

 0Scanner=AGFASNAPSCAN e26,24,0
 1Scanner=EPSON   Perfection 660  ,24,0

 ;A4 color CCD model firefly,Push Button
 ;0=CCD,1=CIS
 ;0=SCSI,1=Parallel,2=USB, 3=USBCIS

 [0Scanner]
 Name=Perfection 660
 SensorType=0
 Interface=2
 RefSize=8.426,11.6
 TPOSize=5,7
 Limit=TRUE

 [1Scanner]
 Name=Perfection 660
 SensorType=0
 Interface=2
 RefSize=8.426,11.6
 TPOSize=5,7
 Limit=TRUE

 [Other]
 Name=%s
 SensorType=0
 Interface=0,2
 RefSize=8.5,11.693
 TPOSize=5,7
 Limit=TRUE

 [DS]
 OPEN=0
 EVENT=0
 EXIT=0
 CLR=245
 CLG=215
 CLB=52

 Interresting, isn't it ?

 So, like snapscan scanners, I tried to load a
 firmware. I found the firmware taill_05.bin. So I
 tested agfafirm tail_058.bin
 the light scanner switch on, and move !

 But, scanimage doesn't work !

  --- Jaeger, Gerhard gerh...@gjaeger.de a écrit :
  Hi,
 
  this doesn't look too good, I think that the 660
  does
  not contain a LM983x chipset. Ain't it possible that
  you open the scanner?
  Or does anybody else know what chipset it uses?
 
  Cheers
 Gerhard
 
  On Monday, 6. January 2003 22:29, you wrote:
   On Debian testing I did :
   #insmod scanner vendor=0x4b8 product=0x114
  
   #sane-find-scanner
   found USB scanner (vendor = 0x04b8, product =
 
  0x0114)
 
   at device /dev/usbscanner
  
   #./checkm
   Checking /dev/usbscanner for MERLIN chipset...
   sanei_usb_read_bulk: read failed: Input/output
 
  error
 
   UIO error
  
   #scanimage -d plustek:/dev/usbscanner -h return
   segmentation fault !!
  
   I'll try with the latest release (Debian unstable
   package)
  
  
   --- Jaeger, Gerhard gerh...@gjaeger.de a écrit
  
   On Sunday, 5. January 2003 13:58, Karl Heinz
 
  Kremer
 
wrote:
 It may work with the Plustek backend.
   
Or may not! I suggest to check for the chip
 
  inside!
 
There's a LM983x check on the download site for
 
  the
 
Plustek backend, called merlin testprogram:

 http://www.gjaeger.de/scanner/test/checkmerlin.tar.gz

You should have loaded the scanner kernel
 
  module...
 
Gerhard
   
 On Sun, Jan 05, 2003 at 01:31:54PM +0100,
 
  tcp-isim
 
tcp-isim wrote:
  Is is possible to use the EPSON PERFECTION
 
  660
 
under
   
  linux? I didn't see an article witch
 
  explains
 
it's
   
  possible to use it.
  Who hnows how to use the EPSON PERFECTION
 
  660
 
with
   
  SANE ?
  David
 


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread Henning Meier-Geinitz
Hi,

On Fri, Jan 10, 2003 at 02:35:04PM +0100, T. Ribbrock wrote:
  If we get reports about real tests with scanners, the entries will be
  changed to yes or no.
 
 Should we ever get this to work I'll happily submit a report... For
 the time being, the User-level SCSI support status for Linux 2.4
 Sparc64 should probably be no... :-}

Ok. This is for SANE 1.0.8? gcc version? Compilation worked without any
patches? bosth shared libs and dynamic loading works? USB and X
clients are unknown?

 And while we're at it - for sane 1.0.7:
 
 Linux 2.4 Sparc32, gcc 2.96, User-level SCSI support: yes, USB: ???,
 shared and dynamic library support: yes, X11 clients: ???
 URL: http://www.ultralinux.org
 Tested with only one Mustek scanner, but on two different
 SparcStations...

Thanks, will be added to web page.

Bye,
  Henning


[sane-devel] epson perfection 660

2003-01-10 Thread Oliver Schwartz
Hi,

 in the end we got it so far:
 The Epson 660 seems to be a rebadged AGFA scnapscan e26

I received an USB log of a windows scan and the protocol looks indeed=20
similar. I'll change the snapscan backend to make it recognize the=20
scanner, maybe we're lucky.

Regards,

Oliver


[sane-devel] Re: Sane on Ultra Sparc

2003-01-10 Thread T. Ribbrock
On Fri, Jan 10, 2003 at 05:38:12PM +0100, abel deuring wrote:
 T. Ribbrock wrote:
[...]
 Hmmm. Are you sure that cdrecord works as a 32 bit application on a 64
 bit Linux kernel using the SG interface?

Aparently yes... I don't have a burner in an Ultra myself, but on
aurora-devel, there's at least one person happily buring away on his
U10. And the app itself is indeed compiled as 32bit, as is libc on
which it depends.


[...]
 
 But the point, where the SG driver complains, is different: Sane uses
 the SG3 interface. This means to define a variable of type strct
 sg_io_hdr, defined in sg.h, to fill in the proper value and to issue a
 write() call for an SG device with this variable.
 
 struct sg_io_hdr is defined as:
[...]
 One of the first things done by the SG driver is to check, if the 3rd
 parameter of the write call, i.e., the write size, equals
 sizeof(sg_io_hdr). If this is not the case, errno is set to EINVAL (22
 for SPARC Linux). And exactly this happens, because sizeof(sg_io_hdr) is
 different for 32 bit and 64 bit programs.

Ah. Thanks for the clarification! Very enlightening, indeed!


 So, what you can do:
[...]

 I'd prefer (1) or (2), because the SG3 interface is much cleaner than
 the old interface, but it might be a bit easier, because the the old
 interface did paass any pointers to the driver. 


[sane-devel] mac osx with epson usb backend

2003-01-10 Thread rchar...@sonicwall.com
Howdy,

I'm seeking help with getting an epson USB u636 scanner working with =
sane (xsane  scanimage). I've come down quite a long path to arrive at =
it's just so close but not yet working. I hope to find the needed help =
to get the job done here.

My current problem is that scanimage does not find my scanner. But note 
=
that sane-find-scanner does find it.

sane-find-scanner reports:

found USB scanner (vendor=3D0x04b8 [EPSON], product=3D0x0101 =
[Perfection636]) at libusb:-08:005

I have compiled sane with libusb. I had to trick up both the libusb and 
=
the sane compile to get through. During the libusb compile, it failed to =
link and I had to manually run ranlib on libusb.a before the make would =
continue. During the sane compile, the compile failed during the cannon =
backend. I edited the make file to remove all the backend objects excpet =
for the epson object which I think is the only one I need (at least for =
the time being) (and I also had to do the famous apple -no-cpp-precomp =
in the CFLAGS.)

But ok, they have compiled. And they installed just fine (seems like to 
=
me anyway).

At this point sane-find-scanner is working and reporting my usb =
scanner. But scanimage -L cannot find it.=20

So I try to edit my /usr/local/etc/sane.d/epson.conf file to say
usb libusb:-08:005

Still scanimage -L cannot find it.

So I tried to do a `mknod /dev/usbscanner0 c 180 48` with an =
appropriate `chmod`.

Still scanimage -L cannot find it.

xsane also cannot find the scanner through all of this either.



What shall I try next? I'm willing to do some debugging work, but I =
don't have much of a good idea of what to try. How could I isolate if =
this is an epson-backend issue or a usb issue? Where would I go from =
there?

Thanks in advance


--
They that can give up essential liberty to obtain a little temporary =
safety deserve neither liberty nor safety.  Benjamin Franklin=20

Ricky Charletrchar...@sonicwall.comUSA (408) 962-8711

=20