> I vote for removing this file and add a paragraph in scanner.txt about > where to find documentation about SANE.
I'd say kill it. > Documentation/usb/scanner.txt > > | REQUIREMENTS > | > | A host with a USB port. Ideally, either a UHCI (Intel) or OHCI > | (Compaq and others) hardware port should work. At the time of this > | writing, there are two UHCI drivers and one OHCI. > > I guess it also works with EHCI? It should. > | A Linux kernel with USB support enabled or a backported version to > | linux-2.2.x. See http://www.linux-usb.org for more information on > | accomplishing this. > > Well, if you read scanner.txt, you alredy have a kernel with USB > capability. > > | 'lspci' which is only needed to determine the type of USB hardware > | available/installed in your machine. > | > | CONFIGURATION > | > | Using `lspci -v`, determine the type of USB hardware available/installed. > | > | If you see something like: > | > | USB Controller: ...... > | Flags: ..... > | I/O ports at .... > > At least my version of lsusb doesn't list anything if the hcd isn't > loaded. And if it's loaded, you already know which one to use. > Even if it's loaded, it doesn't show the above mentioned output. > > Should this paragraph be just removed or is there an easy way to find > out if you have ohci or uhci? Remove it. Just stating that you need working USB should be enough. You cannot replace a HOWTO with a single paragraph anyway. > | Beginning with version 0.4 of the driver, up to 16 scanners can be > | connected/used simultaneously. For devfs support, see next section. > | If you intend to use more than one scanner at a time w/o devfs support: > | > | Add a device for the USB scanner: > | `mknod /dev/usbscanner0 c 180 48` > | `mknod /dev/usbscanner1 c 180 49` > | . > | . > | `mknod /dev/usbscanner15 c 180 63` > > Shouldn't this be changed to "/dev/usb/scanner0"? At least that's what > MAKEDEV and Documentation/devices.txt mentions. > > Apropos MAKEDEV. I would add a reference to that script here. Definitely. [..] > | There is a small test program (hp_scan.c -- appended below) that can > | be used to test the scanner device if it's an HP scanner that supports > | SCL (Scanner Control Language). Known HP scanner that support SCL are > | the 4100, 5200, 6200, the 6300 -- note that the 4200 is *not* > | supported since it does not understand SCL; it's also strongly > | suspected that the 3300 and the PhotoSmart S20 are not SCL compliant. > | Hp_scan.c's purpose is to test the driver without having to > | retrieve/configure SANE. Hp_scan.c will scan the entire bed and put > | the output into a file called 'out.dat' in the current directory. The > | data in the file is raw data so it's not very useful for imaging. > > Should a C program that works with some old HP scanners be really > included in kernel documentation? I don't think so. If necessary, I > can put it on a website and add a link here. How does it hurt having it in the kernel? > Without getting SANE (or another user space application), the user > can't do much with his scanner anyway. But it'll show him whether to use scanner.o or hpusbscsi.o > | funky result -- Most of the time the data flow between the computer > | and the scanner goes smoothly. However, due to whatever reason, > | whether it be solar flares or stray neutrons, sometimes the > | communications don't work as expected. The driver tries to handle > | most types of errors but not all. When this message is seen, > | something weird happened. Please contact the maintaner listed at the > | top of this file. > > Well, that would be > > | Copyright (C) 1999, 2000 David E. Nelson <[EMAIL PROTECTED]> > > Add a link to the linux-usb mailing list instead? Yes. > | SUPPORTED SCANNERS > | > | NOTE: Just because a product is listed here does not mean that > | applications exist that support the product. It's in the hopes that > | this will allow developers a means to produce applications that will > | support the listed USB products. > | > | At the time of this writing, the following scanners were supported by > | scanner.c: > | > | Acer > | Prisa Acerscan 620U & 640U (!) > > [...] > > Should we really duplicate the list that is already in scanner.h? The > manufacturer and product names are mentioned in the comments. This list is getting too large to be useful. > | MODULE PARAMETERS > | > | If you have a device that you wish to experiment with or try using > | this driver with, but the Vendor and Product ID's are not coded in, > | don't despair. If the driver was compiled as a module, you can pass > | options to the driver. Simply add > | > | options scanner vendor=0x#### product=0x**** > | > | to the /etc/modules.conf file replacing the #'s and the *'s with the > | correct ID's. The ID's can be retrieved from the messages file or > | using `cat /proc/bus/usb/devices`. Note that USB /proc support must be > > USB /proc support? Is this superceded by usbfs now? > > | enabled during kernel configuration. If the 'scanner' module is > | already loaded into memory, it must be reloaded for the module > | parameters to take effect. In essence, `rmmod scanner; modprobe > | scanner` must be performed. Delete that section. Those who don't know that they need proc mounted on /proc shouldn't be configuring a machine anyway. > | **NOTE**: In later kernels (2.3.38+), a new filesystem was introduced, > | usbdevfs. To mount the filesystem, issue the command (as root): > > Isn't this called "usbfs" now? In 2.5. We should not change the name in a stable series. [..] > Just remove the email address/web page link? Yes. Merry Christmas Oliver ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
