[sane-devel] Formulardaten

2007-04-29 Thread cgi-mai...@kundenserver.de


===
== Neuer Eintrag
===

  
---
-- Formular: 'adddev'
---

1. Your email address:
   'guido.iod...@tiscali.it'
2. Manufacturer (e.g. Mustek):
   'Lexmark'
3. Model name (e.g. ScanExpress 1200UB):
   'x1270'
4. Bus type:
   'USB'
5. Vendor id (e.g. 0x001):
   ''
6. Product id (e.g. 0x0002):
   ''
7. Chipset (e.g. lm9831):
   ''
8. Comments (e.g. similar to Mustek 1234):
   'multifunction printer-scanner by lexmark

'
9. Data (e.g. sane-find-scanner -v -v):
   'checking /dev/usbscanner1... failed to open (Invalid argument)
checking /dev/usbscanner2... failed to open (Invalid argument)
checking /dev/usbscanner3... failed to open (Invalid argument)
checking /dev/usbscanner4... failed to open (Invalid argument)
checking /dev/usbscanner5... failed to open (Invalid argument)
checking /dev/usbscanner6... failed to open (Invalid argument)
checking /dev/usbscanner7... failed to open (Invalid argument)
checking /dev/usbscanner8... failed to open (Invalid argument)
checking /dev/usbscanner9... failed to open (Invalid argument)
checking /dev/usbscanner10... failed to open (Invalid argument)
checking /dev/usbscanner11... failed to open (Invalid argument)
checking /dev/usbscanner12... failed to open (Invalid argument)
checking /dev/usbscanner13... failed to open (Invalid argument)
checking /dev/usbscanner14... failed to open (Invalid argument)
checking /dev/usbscanner15... failed to open (Invalid argument)
trying libusb:

device descriptor of 0x/0x at 005:001
bLength   18
bDescriptorType   1
bcdUSB2.00
bDeviceClass  9
bDeviceSubClass   0
bDeviceProtocol   1
bMaxPacketSize0   64
idVendor  0x
idProduct 0x
bcdDevice 2.06
iManufacturer 3 ((null))
iProduct  2 ((null))
iSerialNumber 1 ((null))
bNumConfigurations1
 configuration 0
 bLength  9
 bDescriptorType  2
 wTotalLength 25
 bNumInterfaces   1
 bConfigurationValue  1
 iConfiguration   0 ()
 bmAttributes 224 (Self-poweredRemote Wakeup)
 MaxPower 0 mA
  interface 0
   altsetting 0
   bLength9
   bDescriptorType4
   bInterfaceNumber   0
   bAlternateSetting  0
   bNumEndpoints  1
   bInterfaceClass9
   bInterfaceSubClass 0
   bInterfaceProtocol 0
   iInterface 0 ()
endpoint 0
bLength   7
bDescriptorType   5
bEndpointAddress  0x81 (in 0x01)
bmAttributes  3 (interrupt)
wMaxPacketSize4
bInterval 12 ms
bRefresh  0
bSynchAddress 0

device descriptor of 0x043d/0x00ff at 003:004
bLength   18
bDescriptorType   1
bcdUSB1.10
bDeviceClass  0
bDeviceSubClass   0
bDeviceProtocol   0
bMaxPacketSize0   8
idVendor  0x043D
idProduct 0x00FF
bcdDevice 1.00
iManufacturer 1 ((null))
iProduct  2 ((null))
iSerialNumber 3 ((null))
bNumConfigurations1
 configuration 0
 bLength  9
 bDescriptorType  2
 wTotalLength 32
 bNumInterfaces   1
 bConfigurationValue  1
 iConfiguration   0 ()
 bmAttributes 192 (Self-powered)
 MaxPower 4 mA
  interface 0
   altsetting 0
   bLength9
   bDescriptorType4
   bInterfaceNumber   0
   bAlternateSetting  0
   bNumEndpoints  2
   bInterfaceClass7
   bInterfaceSubClass 1
   bInterfaceProtocol 2
   iInterface 0 ()
endpoint 0
bLength   7
bDescriptorType   5
bEndpointAddress  0x05 (out 0x05)
bmAttributes  2 (bulk)
wMaxPacketSize64
bInterval 0 ms
bRefresh  0
bSynchAddress 0
endpoint 1
bLength   7
bDescriptorType   5
bEndpointAddress  0x81 (in 0x01)
bmAttributes  2 (bulk)
wMaxPacketSize16
bInterval 0 ms
bRefresh  0
bSynchAddress 0

device descriptor of 0x043d/0x007d at 003:003
bLength   18
bDescriptorType   1
bcdUSB1.10
bDeviceClass  0
bDeviceSubClass   0
bDeviceProtocol   0
bMaxPacketSize0   8
idVendor  0x043D
idProduct 0x007D
bcdDevice 1.00
iManufacturer 1 ((null))
iProduct  2 ((null))
iSerialNumber 7 ((null))
bNumConfigurations1
 configuration 0
 bLength  9
 bDescriptorType  2
 wTotalLength 39
 bNumInterfaces   1
 bConfigurationValue  1
 iConfiguration   6 ((null))
 bmAttributes 224 (Self-poweredRemote Wakeup)
 MaxPower 0 mA
  interface 0
   altsetting 0
   bLength9
   bDescriptorType4
   bInterfaceNumber   0
   bAlternateSetting  0
   bNumEndpoints  3
   bInterfaceClass255
   

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

2007-04-29 Thread Julien BLACHE
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 ...)


Bertrand, feel free to try this patch on your sparc64; as I said, it
works fine here (at least as long as nothing goes wrong ;), but better
keep your finger on the scanner's power button just in case. Tell us
how it goes.


That's a saturday afternoon well spent.

JB.

-- 
 Julien BLACHE - Debian  GNU/Linux Developer - jbla...@debian.org 
 
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 

-- next part --
A non-text attachment was scrubbed...
Name: sanei_scsi_SG_IO_ioctl.patch
Type: text/x-diff
Size: 4796 bytes
Desc: sanei_scsi PoC patch for SG_IO ioctl
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070428/f23c0321/sanei_scsi_SG_IO_ioctl.bin
From dasjour...@gmail.com  Sun Apr 29 00:27:24 2007
From: dasjour...@gmail.com (Hugh McMaster)
Date: Sun Apr 29 00:27:34 2007
Subject: [sane-devel] Saned Service
Message-ID: 813e5f920704281727x2f6f95c3u2fcb7b96d8f24...@mail.gmail.com

Hi everyone,

I am trying to use the Sane Network Daemon (saned) to access my
scanner.  However, while I can connect to sane, the service just exits
after finishing the connection.

Here is some output from 'saned -d':
[saned] main: starting debug mode (level 2)
[saned] main: could not find `sane' service (Operation not permitted)
[saned] main: using default port 6566
[saned] saned from sane-backends 1.0.18 ready
[saned] check_host: access by remote host: my.ip.address.here
[saned] init: access granted to u...@my.ip.address.here
[saned] quit: exiting

Does anyone have any ideas for this?

Thankyou.

Hugh


[sane-devel] Saned Service

2007-04-29 Thread m. allan noah
dont use -d :)

allan

On 4/28/07, Hugh McMaster dasjour...@gmail.com wrote:
 Hi everyone,

 I am trying to use the Sane Network Daemon (saned) to access my
 scanner.  However, while I can connect to sane, the service just exits
 after finishing the connection.

 Here is some output from 'saned -d':
 [saned] main: starting debug mode (level 2)
 [saned] main: could not find `sane' service (Operation not permitted)
 [saned] main: using default port 6566
 [saned] saned from sane-backends 1.0.18 ready
 [saned] check_host: access by remote host: my.ip.address.here
 [saned] init: access granted to u...@my.ip.address.here
 [saned] quit: exiting

 Does anyone have any ideas for this?

 Thankyou.

 Hugh

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



-- 
The truth is an offense, but not a sin


[sane-devel] HP 3500c -- Error during device I/O

2007-04-29 Thread David Liontooth

I'm trying to get an HP 3500c scanner working on a friend's computer,
where I only have ssh access. He's running Ubuntu Dapper, which uses the
1.0.17 libraries; a friendly soul patched in the rts8801-sane code and
posted the debs at
http://ubuntuforums.org/showthread.php?p=1030523#post1030523

The scanner is now correctly detected with lsusb:

Bus 002 Device 002: ID 03f0:2205 Hewlett-Packard ScanJet 3500c

Or in detail below.  The scanner starts, but then fails to produce a
scan, exiting with scanimage: sane_read: Error during device I/O. We
plugged the scanner straight into the usb port, with no intervening hubs.

The scanimage test looks promising, but then just sits there:

# scanimage -T -v
scanimage: rounded value of br-x from 215.9 to 215.893
scanimage: rounded value of br-y from 298.45 to 298.454
scanimage: scanning image of size 5099x7050 pixels at 24 bits/pixel
scanimage: acquiring RGB frame, 8 bits/sample
scanimage: reading one scanline, 15297 bytes...

What's likely the problem? Is it just a matter of getting the new
driver, or could there be a problem with some other subsystem? Any other
tests we could run?

Dave



More details:

If I run strace, I get this sort of thing:

#strace scanimage -d hp_rts88xx:libusb:002:002 image.pnm
snip
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de58) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [], NULL, {0, 1000})= 0 (Timeout)
gettimeofday({1177791050, 891210}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de58) = 0
gettimeofday({1177791050, 891849}, NULL) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0xbff3de24) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de68) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 1 (out [3], left {0, 1000})
gettimeofday({1177791050, 892424}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de68) = 0
gettimeofday({1177791050, 892509}, NULL) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0xbff3de04) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de48) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 0 (Timeout)
gettimeofday({1177791050, 893218}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de48) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0})

snip

write(2, scanimage: sane_read: Error duri..., 46scanimage:
sane_read: Error during device I/O
) = 46

snip

ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3ef98) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 1 (out [3], left {0, 1000})
gettimeofday({1177791092, 724348}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3ef98) = 0
ioctl(3, USBDEVFS_RELEASEINTERFACE, 0xbff3f044) = 0
close(3)= 0
munmap(0xb7db7000, 266240)  = 0
munmap(0xb7d76000, 266240)  = 0
munmap(0xb7d35000, 266240)  = 0
munmap(0xb7df8000, 97164)   = 0
write(1,
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 455) = 455
munmap(0xb7fc3000, 4096)= 0
exit_group(9)

# lsusb -s 2:2 -v

Bus 002 Device 002: ID 03f0:2205 Hewlett-Packard ScanJet 3500c
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x03f0 Hewlett-Packard
  idProduct  0x2205 ScanJet 3500c
  bcdDevice1.00
  iManufacturer   1 Hewlett-Packard
  iProduct2 hp scanjet 3500c series
  iSerial 8 SCN2A8N31DP1P
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  6 USB SCANNER
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol255
  iInterface  7
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
 

[sane-devel] HP 3500c -- Error during device I/O

2007-04-29 Thread David Liontooth

I'm trying to get an HP 3500c scanner working on a friend's computer,
where I only have ssh access. He's running Ubuntu Dapper, which uses the
1.0.17 libraries; a friendly soul patched in the rts8801-sane code and
posted the debs at
http://ubuntuforums.org/showthread.php?p=1030523#post1030523

The scanner is now correctly detected with lsusb:

Bus 002 Device 002: ID 03f0:2205 Hewlett-Packard ScanJet 3500c

Or in detail below.  The scanner starts, but then fails to produce a
scan, exiting with scanimage: sane_read: Error during device I/O. We
plugged the scanner straight into the usb port, with no intervening hubs.

The scanimage test looks promising, but then just sits there:

# scanimage -T -v
scanimage: rounded value of br-x from 215.9 to 215.893
scanimage: rounded value of br-y from 298.45 to 298.454
scanimage: scanning image of size 5099x7050 pixels at 24 bits/pixel
scanimage: acquiring RGB frame, 8 bits/sample
scanimage: reading one scanline, 15297 bytes...

What's likely the problem? Is it just a matter of getting the new
driver, or could there be a problem with some other subsystem? Any other
tests we could run?

Dave



More details:

If I run strace, I get this sort of thing:

#strace scanimage -d hp_rts88xx:libusb:002:002 image.pnm
snip
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de58) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [], NULL, {0, 1000})= 0 (Timeout)
gettimeofday({1177791050, 891210}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de58) = 0
gettimeofday({1177791050, 891849}, NULL) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0xbff3de24) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de68) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 1 (out [3], left {0, 1000})
gettimeofday({1177791050, 892424}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de68) = 0
gettimeofday({1177791050, 892509}, NULL) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0xbff3de04) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de48) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 0 (Timeout)
gettimeofday({1177791050, 893218}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3de48) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0})
   
snip

write(2, scanimage: sane_read: Error duri..., 46scanimage:
sane_read: Error during device I/O
) = 46

snip

ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3ef98) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, NULL, [3], NULL, {0, 1000})   = 1 (out [3], left {0, 1000})
gettimeofday({1177791092, 724348}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbff3ef98) = 0
ioctl(3, USBDEVFS_RELEASEINTERFACE, 0xbff3f044) = 0
close(3)= 0
munmap(0xb7db7000, 266240)  = 0
munmap(0xb7d76000, 266240)  = 0
munmap(0xb7d35000, 266240)  = 0
munmap(0xb7df8000, 97164)   = 0
write(1,
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 455) = 455
munmap(0xb7fc3000, 4096)= 0
exit_group(9) 

# lsusb -s 2:2 -v

Bus 002 Device 002: ID 03f0:2205 Hewlett-Packard ScanJet 3500c
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x03f0 Hewlett-Packard
  idProduct  0x2205 ScanJet 3500c
  bcdDevice1.00
  iManufacturer   1 Hewlett-Packard
  iProduct2 hp scanjet 3500c series
  iSerial 8 SCN2A8N31DP1P
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  6 USB SCANNER
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol255
  iInterface  7
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer Type  

[sane-devel] Canon FB630u Scanner

2007-04-29 Thread Dr. Ralf Wepler
Hi,
I try to get to work a Canon FB630u Scanner. I use openSUSE 10.2, Kernel
2.6. Hard- and software is found, but the Scanner does'nt move. I ran a
test programm, here is part of the output:


1.  I have found the SANE library (libsane.so) at the following
location: /usr/lib
2.  I have found the SANE configuration files (dll.conf) at the
following location: /etc/sane.d
3.  I have found the SANE header file (sane/sane.h) at the following
location: /usr/include/sane

4.  I'm now trying to connect to the SANE library. If I'm successful,
I'll try to open the test backend just to make sure that the library is
installed correctly. If you get any errors, you should exit and restart
me after fixing the problem.
5. WARNING: The version of the SANE backends on your system is 1.0.18. I
don't know this version yet, so you may want to update sane-troubleshoot.
6.  I was able to open the test backend. That's fine, you can go ahead now.
7.  So your CANON Canoscan FB630U was found by SANE. That's good. Your
scanner is supported by the canon630u SANE backend so you should find
more information on fine-tuning in the sane-canon630u manual page.
Just run man sane-canon630u to view it. I'm now trying to scan a small
image. This will take some time. I'm enabling debug messages
(SANE_DEBUG_CANON630U=255), so you will be able to see what's going on
in the logfile.

8.  ERROR: I tried to call sane_start but it returned the following
error message: Device busy. I think that's a bug in the canon630u
backend.
__

As I'm not an expert, I don't know what to do now. I'll attach the
log-file for further details.

Does anyone have an idea what to do now?
Thank you for help
Ralf
-- next part --
A non-text attachment was scrubbed...
Name: sane-troubleshoot.log
Type: text/x-log
Size: 38518 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070429/7c50df68/sane-troubleshoot-0001.bin
From dasjour...@gmail.com  Sun Apr 29 01:45:50 2007
From: dasjour...@gmail.com (Hugh McMaster)
Date: Sun Apr 29 11:02:44 2007
Subject: [sane-devel] Saned Service
In-Reply-To: 97246d0e0704281740s736e270fta1ad045c40f31...@mail.gmail.com
References: 813e5f920704281727x2f6f95c3u2fcb7b96d8f24...@mail.gmail.com
97246d0e0704281740s736e270fta1ad045c40f31...@mail.gmail.com
Message-ID: 813e5f920704281845y4e90368ao75dbb803961c...@mail.gmail.com

Hi M. Allan Noah,

On 29/04/07, m. allan noah wrote:
 dont use -d :)

 On 4/28/07, Hugh McMaster wrote:
  I am trying to use the Sane Network Daemon (saned) to access my
  scanner.  However, while I can connect to sane, the service just exits
  after finishing the connection.
 
  Here is some output from 'saned -d':
  [saned] main: starting debug mode (level 2)
  [saned] main: could not find `sane' service (Operation not permitted)
  [saned] main: using default port 6566
  [saned] saned from sane-backends 1.0.18 ready
  [saned] check_host: access by remote host: my.ip.address.here
  [saned] init: access granted to u...@my.ip.address.here
  [saned] quit: exiting

It would seem that if I do not use the -s or -d[n] flags, then saned
starts and then finishes immediately.  I can post the 'saned -d128'
output if you would like it.

When it says 'could not find 'sane' service', does this mean that the
path to the executable file is incorrect?

Hugh


[sane-devel] Saned Service

2007-04-29 Thread Julien BLACHE
Hugh McMaster dasjour...@gmail.com wrote:

Hi,

  Here is some output from 'saned -d':
  [saned] main: starting debug mode (level 2)
  [saned] main: could not find `sane' service (Operation not permitted)
  [saned] main: using default port 6566
  [saned] saned from sane-backends 1.0.18 ready
  [saned] check_host: access by remote host: my.ip.address.here
  [saned] init: access granted to u...@my.ip.address.here
  [saned] quit: exiting

 When it says 'could not find 'sane' service', does this mean that the
 path to the executable file is incorrect?

No, it means that saned couldn't do a lookup in /etc/services to
determine the port number associated to the saned-port
service. Getting EPERM here is quite interesting.

JB.

-- 
Julien BLACHE   http://www.jblache.org 
j...@jblache.org  GPG KeyID 0xF5D65169


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

2007-04-29 Thread 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] [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

2007-04-29 Thread Julien BLACHE
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.

 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 ...)

JB.

-- 
 Julien BLACHE jbla...@debian.org  |  Debian, because code matters more 
 Debian  GNU/Linux Developer|   http://www.debian.org
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


[sane-devel] gt68xx backend problems

2007-04-29 Thread Vishal Shah
Hello,

I am trying to get my OpticSlim M12 scanner from Plustek to run using
the sane-gt68xx backend.

sane-find-scanner

returns:

found USB scanner (vendor=0x07b3, product=0x0412 [600dpi USB Scanner],
chip=GT-6816) at libusb:003:005

I am not able to get my scanner to scan pages.

When I do scanimage  1.pnm (with export SANE_DEBUG_GT68XX=255)

the debug output is:


[gt68xx] SANE GT68xx backend version 1.0 build 81 from sane-backends 1.0.18
[gt68xx] sane_init: authorize != null
[gt68xx] sane_init: debug options are enabled, handle with care
[gt68xx] sane_init: little endian machine
[gt68xx] sane_init: reading config file `gt68xx.conf'
[gt68xx] sane_init: config file line 1: ignoring empty line
[gt68xx] sane_init: config file line 2: ignoring comment line
[gt68xx] sane_init: config file line 3: ignoring comment line
[gt68xx] sane_init: config file line 4: ignoring empty line
[gt68xx] sane_init: config file line 5: ignoring comment line
[gt68xx] sane_init: config file line 6: ignoring empty line
[gt68xx] sane_init: config file line 7: ignoring comment line
[gt68xx] sane_init: config file line 8: ignoring comment line
[gt68xx] sane_init: config file line 9: ignoring comment line
[gt68xx] sane_init: config file line 10: ignoring comment line
[gt68xx] sane_init: config file line 11: ignoring empty line
[gt68xx] sane_init: config file line 12: ignoring comment line
[gt68xx] sane_init: config file line 13: ignoring comment line
[gt68xx] sane_init: config file line 14: ignoring comment line
[gt68xx] sane_init: config file line 15: ignoring comment line
[gt68xx] sane_init: config file line 16: ignoring comment line
[gt68xx] sane_init: config file line 17: ignoring empty line
[gt68xx] sane_init: config file line 18: ignoring comment line
[gt68xx] sane_init: config file line 19: ignoring comment line
[gt68xx] sane_init: config file line 20: ignoring comment line
[gt68xx] sane_init: config file line 21: ignoring empty line
[gt68xx] sane_init: config file line 22: ignoring comment line
[gt68xx] sane_init: config file line 23: ignoring comment line
[gt68xx] sane_init: config file line 24: ignoring comment line
[gt68xx] sane_init: config file line 25: trying to attach `usb 0x05d8 0x4002'
[gt68xx] sane_init: config file line 26: ignoring empty line
[gt68xx] sane_init: config file line 27: ignoring comment line
[gt68xx] sane_init: config file line 28: ignoring empty line
[gt68xx] sane_init: config file line 29: ignoring comment line
[gt68xx] sane_init: config file line 30: ignoring comment line
[gt68xx] sane_init: config file line 31: ignoring empty line
[gt68xx] sane_init: config file line 32: ignoring comment line
[gt68xx] sane_init: config file line 33: ignoring comment line
[gt68xx] sane_init: config file line 34: ignoring comment line
[gt68xx] sane_init: config file line 35: ignoring comment line
[gt68xx] sane_init: config file line 36: ignoring empty line
[gt68xx] sane_init: config file line 37: ignoring comment line
[gt68xx] sane_init: config file line 38: ignoring comment line
[gt68xx] sane_init: config file line 39: ignoring comment line
[gt68xx] sane_init: config file line 40: ignoring comment line
[gt68xx] sane_init: config file line 41: ignoring empty line
[gt68xx] sane_init: config file line 42: ignoring comment line
[gt68xx] sane_init: config file line 43: ignoring comment line
[gt68xx] sane_init: config file line 44: ignoring empty line
[gt68xx] sane_init: config file line 45: ignoring comment line
[gt68xx] sane_init: config file line 46: ignoring comment line
[gt68xx] sane_init: config file line 47: ignoring comment line
[gt68xx] sane_init: config file line 48: ignoring empty line
[gt68xx] sane_init: config file line 49: ignoring comment line
[gt68xx] sane_init: config file line 50: ignoring comment line
[gt68xx] sane_init: config file line 51: ignoring comment line
[gt68xx] sane_init: config file line 52: ignoring comment line
[gt68xx] sane_init: config file line 53: ignoring empty line
[gt68xx] sane_init: config file line 54: ignoring comment line
[gt68xx] sane_init: config file line 55: ignoring comment line
[gt68xx] sane_init: config file line 56: ignoring comment line
[gt68xx] sane_init: config file line 57: ignoring comment line
[gt68xx] sane_init: config file line 58: ignoring empty line
[gt68xx] sane_init: config file line 59: ignoring comment line
[gt68xx] sane_init: config file line 60: ignoring comment line
[gt68xx] sane_init: config file line 61: ignoring comment line
[gt68xx] sane_init: config file line 62: ignoring comment line
[gt68xx] sane_init: config file line 63: ignoring empty line
[gt68xx] sane_init: config file line 64: ignoring comment line
[gt68xx] sane_init: config file line 65: ignoring comment line
[gt68xx] sane_init: config file line 66: ignoring comment line
[gt68xx] sane_init: config file line 67: ignoring comment line
[gt68xx] sane_init: config file line 68: ignoring empty line
[gt68xx] sane_init: config file line 69: ignoring comment line
[gt68xx] sane_init: config file