[sane-devel] Third revision of Scanner HOWTO available
Hi, On Sat, Jul 19, 2003 at 04:45:12PM -0500, Howard Shane wrote: ...at http://66.25.191.66/docs/HOWTOS/Scanner/index.html This is your last chance to point out any remaining technical errata prior to grammatical review and (hopefully) publication by TLDP. Ok, lets see if I can nitpick a bit :-) I'm not a native english speaker, so grammar/spelling corrections may be wrong. | 1. Introduction | | within X-windows -The X Consortium requests that the following names be used when referring to this software: X, X Window System, X Version 11, X Window System, Version 11, X11 (from man X) | It does not address how use the available software -- how to use (?) | 2.1. SCSI Devices | While most SCSI-cards that linux supports allow scanning, you should | be aware that if your SCSI card came come bundled with your scanner | you may run into problems, as these may not be complete SCSI cards | (much like a winmodem). I don't think that's a very good comparison. While a winmodem is not a modem at all (it's more a sound chip), the bundled SCSI adapter are real SCSI cards. They may not be of good qquality, i.e. don't have IRQ/DMA support. But at least the ones I know of can be used for e.g. CDROMS, too. Well, I wouldn't do that but anyway. | 3.1. USB Scanners and Libusb | $ grep -e USB_DEVICEFS /boot/config-X.XX -- I think it's easier to do grep \(usbfs\)\|\(usbdevfs\) /proc/filesystems This way you are checking the currently running kernel. | If you have USB device filesystem running, and you have usb devices | loaded already you can confirm this with cat /proc/bus/usb, which | should give you a list of active devices the kernel is aware of. -- It's cat /proc/bus/usb/devices. | IMPORTANT: You cannot have both kernel scanner support enabled (i.e., | compiled in statically or the module loaded if a module) and libusb | installed and access the hardware at the same time, or nothing will | work. Well, I know what you mean but it's not completely true the way you have written it. If the scanner driver is loaded and has detected the scanner it will lock it. So libusb can't use it. But the scanner driver can still use it. After unloading the scanner driver, libusb can use it again. So there is no real conflict. The scanner driver just has the higher priority. | (A hint for newbies: [...] | where 'file.txt' will contain the info that can then be accessed with | cat.) -- with less, otherwse it will scroll again too fast. | 3.2.2. Kernel USB Support | USB-ohci, USB-ehci, -- lower case (usb-ohci) | 3.3.2. Directio | | Some parallel port scanners can be accessed with directio (a.k.a. | direct_IO) instead; you will likely need to compile your own SANE | binaries and have libieee1484 installed. You will need generic scsi | device support in your kernel. At compile time use the | --enable-parport-directio --enable-scsi-directio with the ./configure | script. I'm not an expert in these things but I think you are mixing different topics here. --enable-parport-directio means, that direct hardware access to the ports (inb/outb assembler commands) is used. So you don't need libieee1284 (not 1448) here. This is only used in the mustek_pp and umax_pp backends. --enable-scsi-directio
[sane-devel] Third revision of Scanner HOWTO available
Howard Shane schrieb: ...at http://66.25.191.66/docs/HOWTOS/Scanner/index.html This is your last chance to point out any remaining technical errata prior to grammatical review and (hopefully) publication by TLDP. Perhaps I'm jumping a bit too late into the discussion of your Howto, but anyway, here are my 2 cents: 2.1. SCSI Devices These scanners connect to an SCSI adapter. In general just about any scanner using an SCSI interface should work, though some with difficulty. While most SCSI-cards that linux supports allow scanning, you should be aware that if your SCSI card came come bundled with your scanner you may run into problems, as these may not be complete SCSI cards (much like a winmodem). I don't think that just about any scanner using a SCSI interface works with Sane -- users should first check on the Sane web site, if a scanner is indeed supported. 3.2.1. Kernel SCSI Support If you have an SCSI-type interface, when invoking make config, make menuconfig or make xconfig etc., be aware that in addition to the option to support your particular SCSI adapter, generic SCSI device support is also required. Such generic devices are usually named /dev/sg0, /dev/sg1... Since you probably already know if your card is supported from the supported devices and backends list, all that is ^^^ required after confirming that your kernel supports your hardware and generic SCSI devices is to load the appropriate module(s): The text supported devices and backends list links to the page http://www.mostang.com/sane/sane-mfgs.html (SANE: supported devices), which does not list any SCSI adapters, but only scanners, while you are writing here about kernel SCSI support. I think it would be good to point out (either in 3.2.1 or perhaps in section 2.1) that one must have support for a SCSI adapter card in the kernel, regardless of the SCSI scanner model. And it would perhaps help to mention that any combination of SCSI adapter and SCSI scanner will work, provided that the SCSI adapter is suported by the kernel and that the scanner is supported by Sane. (there are some nasty combinations though, like HP scanners / 2.4 kernels / Bus Logic adapters.) In 7. Sane Frontends, you write only about xsane and xscanimage. While I agree that xsane is probably the most advanced frontend, I think it would be fair to mention at least shortly that other frontends exist, like Quiteinsane and Kooka. Even Openoffice has builtin support for Sane (though not with a very comfortable user interface...). Abel
[sane-devel] Sane API Suggestion
The initial version of my based application (written in scheme) does not use the sane api directly, but utilizes scanimage and scanadf to perform scanning. In a future release, I would like to use the sane api directly for better control. Although I have a number of years of experience programming C/C++/Java, I now prefer to use scheme for most of my programming. After briefly looking at the sane api, I noticed that callbacks are sometimes used. I am aware of a number of ways and various ffi libraries to handle callbacks from non-C to C, but it sure would be nice if the sane API was a little more non-C friendly. Specifically, when a callback pointer is required, why not also require a user data void pointer (or perhaps an integer id) that would be returned untouched to the callback as a parameter? This would allow non-C languages to interface more easily to the sane api. A thin C interface layer could then use one callback dispatcher to handle all C callbacks. The callback dispatcher could use stdarg.h to process the other args or perhaps they could be passed to the callback using a count and array. In the future, I would be happy to contribute a scheme-sane interface library to the sane project, but it sure would be nice if the sane api was more non-C friendly. Peter
[sane-devel] re: Sane API Suggestion
Oops, sorry for the typo in my first paragraph. Here's my previous post with a corrected first paragraph: The initial version of my application (written in scheme) does not use the sane api directly, but utilizes scanimage and scanadf to perform scanning. In a future release, I would like to use the sane api directly for better control. Although I have a number of years of experience programming C/C++/Java, I now prefer to use scheme for most of my programming. After briefly looking at the sane api, I noticed that callbacks are sometimes used. I am aware of a number of ways and various ffi libraries to handle callbacks from non-C to C, but it sure would be nice if the sane API was a little more non-C friendly. Specifically, when a callback pointer is required, why not also require a user data void pointer (or perhaps an integer id) that would be returned untouched to the callback as a parameter? This would allow non-C languages to interface more easily to the sane api. A thin C interface layer could then use one callback dispatcher to handle all C callbacks. The callback dispatcher could use stdarg.h to process the other args or perhaps they could be passed to the callback using a count and array. In the future, I would be happy to contribute a scheme-sane interface library to the sane project, but it sure would be nice if the sane api was more non-C friendly. Peter
[sane-devel] Does anyone need help writing a backend?
Hi, On Sat, Jul 19, 2003 at 02:38:36PM +0200, Jaeger, Gerhard wrote: On Samstag, 19. Juli 2003 12:10, Henning Meier-Geinitz wrote: Hi, Usually people ask for help here. In this case it's the other way round: I may have some spare time during the next few weeks so if anyone needs help writing a backend I may able to spend some time on it. Oh, what a lucky man he is Ha, I just finished my PhD examination so I think it's fair to have some free time now :-) The list of unsupported scanners gets longer and longer so I thought something should be done :-) I prefer working on fairly recent not too expensive USB scanners so I can get one of these devices for coding. Well, I think that by supporting the GeneSys Logic stuff we can cover a lot of currently available devices. I know that Oliver Rauch is working on that but I don't know the status. The only thing I know is, that he's short of time... -- Just a proposal! Ok, I'll get a UMAX 4500 and will see what I can do. From my quick scan of our lists it looks like these scanners use a GL646 chip: Avision iVina FB1600 http://www.meier-geinitz.de/sane/misc/umax-astra-4500.txt Genius ColorPage HR7X http://www.meier-geinitz.de/sane/misc/genius-colorpage-hr7x.txt Lexmark X83 http://www.meier-geinitz.de/sane/misc/lexmark-x83.txt Medion/Tevion MD 5345 http://www.meier-geinitz.de/sane/misc/medion-MD5345.txt Medion MD6228 Medion MD5345 http://www.meier-geinitz.de/sane/misc/medion-md6228.txt Plustek OpticPro S12 Plustek OpticPro S24 UMAX Astra 4500 http://www.meier-geinitz.de/sane/misc/umax-astra-4500.txt And maybe the: Canon CanoScan D2400UF (maybe) http://www.meier-geinitz.de/sane/misc/canon-d2400uf.txt But the interval for the interrupt endpoint is different here: Ivl=10ms. I'm not sure if that matters. Any more scanners that use the GL646 chipset? Are there any other chipsets around that may have the same spreading? There are some more Genesys chipsets (e.g. the gl841). I have no idea how common they are and how different they are from the gl646. The Realtek RTS8801B and C chips are also fairly common. E.g. some HP and Visioneer scanners use these chips. Ok, so I'd like to know everything about the gl646. I know the data sheet from http://www.genesyslogic.com/GL646.htm but nothing more. Are there already any logs or code (Oliver?)? Bye, Henning
[sane-devel] Sane API Suggestion
Hi, On Sun, Jul 20, 2003 at 08:48:54AM -0400, Peter Santoro wrote: Although I have a number of years of experience programming C/C++/Java, I now prefer to use scheme for most of my programming. After briefly looking at the sane api, I noticed that callbacks are sometimes used.
[sane-devel] Sane API Suggestion
Hi, I forgot to add: On Sun, Jul 20, 2003 at 08:48:54AM -0400, Peter Santoro wrote: In the future, I would be happy to contribute a scheme-sane interface library to the sane project, but it sure would be nice if the sane api was more non-C friendly. I don't want to discourage you: A scheme-sane interface and interfaces to other languages are higly appreciated. I rememebr someone writing a C++ interface and there is a (extremely outdated) java interface. Bye, Henning
[sane-devel] Third revision of Scanner HOWTO available
Howard, Thanks for any input, Sorry for joining the discussion so late, and sorry for possibly duplicating what others have said (I didn't have time to read their responses). chapter 2.: There is no mention of IEEE 1394 devices. There should be, since several of those are supported by SANE, and setup might not be trivial. (See problems with LS-8000 with certain kernel versions.) (Oh, I've just spotted Firewire in there -- please refer to it as IEEE 1394, because that's the standard name, Firewire and i.Link are proprietary names for the same thing by Apple and Sony.) Most USB devices are supported ... with the SANE application programming interface. This is very confusing, I think you should split that into two sentences. One thing is that they are supported by SANE, the other is that SANE uses a homogeneous API throughout, regardless of the hardware. chapter 3.: IMPORTANT: You cannot have both kernel scanner support enabled (i.e., compiled in statically or the module loaded if a module) and libusb installed and access the hardware at the same time, or nothing will work. Why not? The only thing that won't work is sane-backends with a USB scanner if it was built with libusb support. nothing will work is a bit of an exaggeration. Also, libusb can safely be installed when the kernel USB scanner module is loaded, even SANE will work as long as sane-backend was built without libusb support. I'd write Directio as DirectIO in the title, or even Direct I/O, to avoid confusion (directio can be mistaken as a typo, or a latin word!). chapter 4.: There is no mention of libusb here -- you don't need any device files outside /proc/bus/usb/ if you use libusb. Somewhere on the line, you should also include instructions on how to use hotplug to modify permissions to devices in /proc/bus/usb/ so that a regular user can access the scanner. WARNING: If you enable 'devfs' without devfsd you will be left with an unbootable system! -- not true: this only applies if CONFIG_DEVFS_MOUNT is also set. chapter 5.: saned section: there's no mention at all of the changes required to net.conf. Also, what's the warning all about? I'd say it's advisable to run saned as a dedicated user (I usually call it saned), but it's not a group. Also, once saned is set up properly, _everyone_ has access to the scanner without requiring root privileges, as long as their computer is listed in saned.conf. chapter 6.: It would be very important to note here that sane-find-scanner isn't related to any backends, therefore cannot tell whether the scanner is supported or not. It only looks for devices which claim to be scanners. BTW, it also works for IEEE 1394 devices (which essentially behave as SCSI once SBP2 is set up). chapter 7.: X-windows is misleading and even wrong. Please use X11 or The X Window System. X-windows sounds like a sci-fi version of M$ Windows. gtk+-1.2: version unnecessary, write GTK+ (in capitals please) It would be nice to elaborate on the GIMP-xsane relationship, i.e. that xsane can be used as a GIMP plugin, and maybe even how. Most people I know only ever scan with the GIMP plugin because they're used to TWAIN scanners under Windows that only support scanning from within an application. A more spartan solution (though technically a meta-backend) is xscanimage, which is bundled with SANE: 1. it's not really spartan, given the gamma adjustment capabilities which surpass those of xsane, 2. it's NOT a meta-backend but a frontend, 3. it's bundled with sane-frontends, SANE is too general. This was just a quick run through the document, hope it all makes sense. I like the overall structure of the document. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
[sane-devel] Sane API Suggestion
A thin C interface layer could then use one callback dispatcher to handle all C callbacks. The callback dispatcher could use stdarg.h to process the other args or perhaps they could be passed to the callback using a count and array. Well, maybe the other developers have more experience with other languages. My first impression however, is that this makes the interface more complicated and complex. However, I'm no expert in interface design so if the other developers say it's better that way, I'll accept that. Scheme is a full-blown functional language, and thus very different from a pure procedural language. You can see from GObject (loosely part of GTK+) how difficult it is to approach object-oriented programming with C, and emulating functional programming in C would certainly be totally impractical. No C API will ever approach the full closure capabilities of Scheme, so some sacrifices on the Scheme side must always be made when interfacing C code. In the future, I would be happy to contribute a scheme-sane interface library to the sane project, but it sure would be nice if the sane api was more non-C friendly. Well, it's a C interface so beeing C-friendly is a feature :-) The SANE API is designed to be simple and portable, and any change towards object orientation or functional programming would only bloat it unnecessarily. Sorry, if you want to interface Scheme to SANE, you'll have to adapt to the way things are. Adding a callback data argument to both sane_init() and SANE_Authorization_Callback would cause a number of problems, in particular that of network transparency. Scheme or C++ programmers would certainly like to use that parameter as a pointer to a structure, but that only works if the size of the argument is at least that of void*. Since the latter varies across platforms, this would be ugly and non-portable. Since the only callback in SANE is the one responsible for authentication, I'd say it wouldn't be worth changing anything. A Scheme frontend would either have to relay the authentication request to the user, in which case the callback data is not used, or look up username and password in a database, in which case the resource string supplied is sufficient. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
[sane-devel] Third revision of Scanner HOWTO available
Hi, On Sun, Jul 20, 2003 at 03:55:17PM +0100, Major A wrote: IMPORTANT: You cannot have both kernel scanner support enabled (i.e., compiled in statically or the module loaded if a module) and libusb installed and access the hardware at the same time, or nothing will work. Why not? The only thing that won't work is sane-backends with a USB scanner if it was built with libusb support. nothing will work is a bit of an exaggeration. Also, libusb can safely be installed when the kernel USB scanner module is loaded, even SANE will work as long as sane-backend was built without libusb support. Even if SANE was built with libusb support there is no problem. If the backend asks sanei_usb for a vendor/product id combination, sanei_usb will try both the kernel scanner driver and libusb. If the kernel scanner driver is loaded, it has priority over libusb and is used. Otherwise libusb is used. I can't think of any problem here at all. bye, Henning
[sane-devel] Third revision of Scanner HOWTO available
Major A wrote:
chapter 5.:
saned section: there's no mention at all of the changes required to
net.conf. Also, what's the warning all about? I'd say it's advisable
to run saned as a dedicated user (I usually call it saned), but it's
not a group. Also, once saned is set up properly, _everyone_ has
access to the scanner without requiring root privileges, as long as
their computer is listed in saned.conf.
I didn´t look into the document, but it should be mentioned that with
saned and the net backend acting on one and the same machine as both
client and server parallel scanners which are normally only accessible
by root (e. g. Canon) can be accessed by normal users. Here a Mini-HOWTO:
The problem is that the SANE driver for your scanner accesses the
parallel port directly, without use of the kernel. Such way of device
access is only possible for root. Due to the kernel not being used there
is no special file in /dev or /proc which represents the scanner and
whose permissions can be opened for normal users.
Scanning-as-Normal-User-on-Wierd-Scanner-Mini-HOWTO
---
Original version I presented on MandrakeClub:
http://www.mandrakeclub.com/modules.php?op=modloadname=Splatt_Forumfile=viewtopictopic=5895forum=13
This version can also be used with non-Mandrake distros.
1. Make sure that saned is installed as in some distros it can be in an
extra package (for example in Mandrake, type urpmi saned as root or
use rpmdrake there).
2. Get root and stay root for the next steps. Create or edit
/etc/xinetd.d/saned (we assume xinetd is used as in most modern distros):
# default: off
# description: The sane server accepts requests \
# for network access to a local scanner via the \
# network.
service sane
{
disable = no
port= 6566
socket_type = stream
wait= no
groups = yes
user= root
group = root
server = /usr/sbin/saned
}
It can be already provided by your distro, but probably with
user = saned
group = saned
Make sure that you have
user = root
group = root
Add the line
sane 6566/tcp # SANE Control Port
to /etc/services if your distro didn´t put it there already.
3. Restart xinetd with
service xinetd restart
4. Add a line only containing localhost in both /etc/sane.d/saned.conf
and /etc/sane.d/net.conf. Make sure that in /etc/sane.d/dll.conf is a
line containing only net and a line containing only the name of the
driver for your scanner, both without comment sign (#) in the
beginning. Make also sure that the configuration file for your scanner
driver /etc/sane.d/your scanner´s driver.conf is correctly set up (see
man sane-your scanner´s driver).
Mandrake Linux users can also proceed as follows:
Start Scannerdrake
scannerdrake
and click on Scanner sharing. Mark The scanners on this machine are
available to other computers and Use scanners on remote computers.
Click on Scanner sharing to hosts and in the next window on Add
host. Then choose Name/IP address of host: and type localhost in
the input line. Click OK and Done. Now click Use scanners on hosts:
... and in the dialog appearing Add host. In the next window choose
This machine and click OK. Click Done to get back into the
Scanner sharing and OK to get back into the main window of
Scannerdrake. Now you can close Scannerdrake.
5. Run X-Sane (or your preferred frontend) as normal user and you should
be able to scan. Please report here whether it really works.
6. You can still share your scanner on a network, simply add the
addresses of the clients to your /etc/sane.d/saned.conf file.
How does this work?
We use the network scanning facility of SANE, but our network consists
of only one machine, the machine where your parallel scanner is
connected to. You do not need a network card for it. Linux has a virtual
network consisting of only the local machine which is used when your
machine is called with the name localhost or the IP address 127.0.0.1.
So the server and the client are on the same machine. The server is the
saned which you have installed in step (1). It calls the scanner
driver and communicates with the scanner. To make this possible you let
it run with root privileges. This you have configured in step (2) and
(3). In step (4) you have told that the local machine and no other
machine can access to your scanner (/etc/sane.d/saned.conf or
scannerdrake's Scanner sharing to hosts: button) and that locally
started scanning software should search for scanner servers on the local
machine (/etc/sane.d/net.conf or scannerdrake's Use the scanners on
hosts: button). The client is the X-Sane running as a normal user,
started in step (5). It searches for local scanners where a normal user
has access to and for remote scanners. In your case it searches only on
the local machine and finds the saned providing your
[sane-devel] Third revision of Scanner HOWTO available
Thanks to everyone for all the suggestions. I though I had addressed most of the concerns up to now, but it looks like there will need to be one more revision prior to publication. A few of the comments I've received are contradictory; I'm going out of town for a week and upon return I'll negotiate/incorporate everyone's ideas and corrections, so definitely keep the comments coming. Also, its not nitpicking if it makes the document more accurate and effective. :^) Henning Meier-Geinitz wrote: Hi, On Sat, Jul 19, 2003 at 04:45:12PM -0500, Howard Shane wrote: ...at http://66.25.191.66/docs/HOWTOS/Scanner/index.html This is your last chance to point out any remaining technical errata prior to grammatical review and (hopefully) publication by TLDP. Ok, lets see if I can nitpick a bit :-) I'm not a native english speaker, so grammar/spelling corrections may be wrong. | 1. Introduction | | within X-windows -The X Consortium requests that the following names be used when referring to this software: X, X Window System, X Version 11, X Window System, Version 11, X11 (from man X) | It does not address how use the available software -- how to use (?) | 2.1. SCSI Devices | While most SCSI-cards that linux supports allow scanning, you should | be aware that if your SCSI card came come bundled with your scanner | you may run into problems, as these may not be complete SCSI cards | (much like a winmodem). I don't think that's a very good comparison. While a winmodem is not a modem at all (it's more a sound chip), the bundled SCSI adapter are real SCSI cards. They may not be of good qquality, i.e. don't have IRQ/DMA support. But at least the ones I know of can be used for e.g. CDROMS, too. Well, I wouldn't do that but anyway. | 3.1. USB Scanners and Libusb | $ grep -e USB_DEVICEFS /boot/config-X.XX -- I think it's easier to do grep \(usbfs\)\|\(usbdevfs\) /proc/filesystems This way you are checking the currently running kernel. | If you have USB device filesystem running, and you have usb devices | loaded already you can confirm this with cat /proc/bus/usb, which | should give you a list of active devices the kernel is aware of. -- It's cat /proc/bus/usb/devices. | IMPORTANT: You cannot have both kernel scanner support enabled (i.e., | compiled in statically or the module loaded if a module) and libusb | installed and access the hardware at the same time, or nothing will | work. Well, I know what you mean but it's not completely true the way you have written it. If the scanner driver is loaded and has detected the scanner it will lock it. So libusb can't use it. But the scanner driver can still use it. After unloading the scanner driver, libusb can use it again. So there is no real conflict. The scanner driver just has the higher priority. | (A hint for newbies: [...] | where 'file.txt' will contain the info that can then be accessed with | cat.) -- with less, otherwse it will scroll again too fast. | 3.2.2. Kernel USB Support | USB-ohci, USB-ehci, -- lower case (usb-ohci) | 3.3.2. Directio | | Some parallel port scanners can be accessed with directio (a.k.a. | direct_IO) instead; you will likely need to compile your own SANE | binaries and have libieee1484 installed. You will need generic scsi | device support in your kernel. At compile time use the | --enable-parport-directio --enable-scsi-directio with the ./configure | script. I'm not an expert in these things but I think you are mixing different topics here. --enable-parport-directio means, that direct hardware access to the ports (inb/outb assembler commands) is used. So you don't need libieee1284 (not 1448) here. This is only used in the mustek_pp and umax_pp backends. --enable-scsi-directio From README.linux: SCSI Direct IO: Recent versions of the Linux SG driver for the 2.4 kernels support direct IO, i.e., the SCSI adapter's DMA chip copies data directly to/from user memory. Direct IO reduces memory usage, but it can lead to access conflicts, if a backend uses shared memory. SANE does not use direct IO by default. If you want to use it, run configure --enable-scsi-directio=yes I don't think you should mention --enable-scsi-directio in a HOWTO document. it's seldomly (if at all?) used. | 5.1. Getting SANE | that of the Software Building HOWTO. -- the link to the HOWTO seems to be wrong. | For Debian users there is a sane package in stable (Woody), testing | (Sarge) and unstable (Sid) package repositories, so a simple apt-get | install sane is all that is required whatever version you are using. The package in Woody is quite old but there are backports from Aurelien Jarno: http://people.debian.org/~aurel32/sane.html | There is an excellent write-up of how to compile SANE from source and | get an SCSI scanner working at Laurent-jan's HOWTO page originally | written by Steve Sheriff
