Merge with Linux 2.3.99-pre4.

10 files changed, 584 insertions, 351 deletions

diff --git a/Documentation/usb/CREDITS b/Documentation/usb/CREDITS
index b1230f70a..38bdbaee0 100644
--- a/Documentation/usb/CREDITS
+++ b/Documentation/usb/CREDITS
@@ -16,6 +16,7 @@ difficult to maintain, add yourself with a patch if desired.
   Paul Mackerras <paulus@cs.anu.edu.au>
   David E. Nelson <dnelson@jump.net>
   Vojtech Pavlik <vojtech@suse.cz>
+  Bill Ryder <bryder@sgi.com>
   Thomas Sailer <sailer@ife.ee.ethz.ch>
   Gregory P. Smith <greg@electricrain.com>
   Linus Torvalds <torvalds@transmeta.com>
diff --git a/Documentation/usb/acm.txt b/Documentation/usb/acm.txt
index c978974f1..e4fced658 100644
--- a/Documentation/usb/acm.txt
+++ b/Documentation/usb/acm.txt
@@ -1,94 +1,138 @@
-The ACM driver works with modems and ISDN TAs that use the USB Abstract
-Control Model standard. 
-
-****************************
-Test it:
-Watch out, the driver is not stable and tested. Sync often, make backups,
-most importand: don't blame me...
-
-Create device files:
-mknod /dev/ttyACM0 c 166 0
-mknod /dev/ttyACM1 c 166 1
-mknod /dev/ttyACM2 c 166 2
-mknod /dev/ttyACM3 c 166 3
-Compile a kernel with support for your host controller (uhci only for now!)
-and support for ACM. Boot this kernel. If you connect your device to the
-USB bus you should see messages like the following:
-
-Jul 19 20:14:29 office kernel: USB new device connect, assigned device number 1
-Jul 19 20:14:29 office kernel: Found 02:09
-Jul 19 20:14:29 office kernel: Found 04:09
-Jul 19 20:14:29 office kernel: Found 05:07
-Jul 19 20:14:29 office last message repeated 2 times
-Jul 19 20:14:29 office kernel: parsed = 39 len = 67
-Jul 19 20:14:29 office kernel: Expected descriptor 04/09, got 02/09 - skipping
-Jul 19 20:14:29 office kernel:    0 09
-Jul 19 20:14:29 office kernel:    1 02
-Jul 19 20:14:29 office kernel:    2 43
-Jul 19 20:14:29 office kernel:    3 00
-Jul 19 20:14:29 office kernel:    4 02
-Jul 19 20:14:29 office kernel:    5 02
-Jul 19 20:14:29 office kernel:    6 04
-Jul 19 20:14:29 office kernel:    7 60
-Jul 19 20:14:29 office kernel:    8 00
-Jul 19 20:14:29 office kernel: Found 04:09
-Jul 19 20:14:29 office kernel: Found 02:09
-Jul 19 20:14:29 office kernel: Found 04:09
-Jul 19 20:14:29 office kernel: Found 05:07
-Jul 19 20:14:29 office kernel: Found 04:09
-Jul 19 20:14:29 office kernel: Found 05:07
-Jul 19 20:14:29 office kernel: Found 05:07
-Jul 19 20:14:29 office kernel: parsed = 67 len = 0
-Jul 19 20:14:29 office kernel: getstringtable
-Jul 19 20:14:29 office kernel: acm_probe
-Jul 19 20:14:29 office kernel: USB ACM found
-
-Watch out for the line:
-Jul 19 20:14:29 office kernel: USB new device connect, assigned device number 1
-and the line:
-Jul 19 20:14:29 office kernel: USB ACM found
-These two lines show that the device was seen by the usb host controller and
-then recognized by the acm driver as a valid device.
-
-If you use a terminal emulation software like minicom with /dev/ttyACM0 you
-should be able to send AT commands to your device and get responses. I've 
-been able to do zmodem downloads to another pc. However downloads from one
-ISDN TA to another ISDN TA connected to the same PC didn't work. Don't
-know why. Flow control is not finised after all and i'd guess there might
-be problems on heavily loades PCs. I also did some tests with ppp but i'm
-not finised with this. There might be a chance to get it working. However
-i'd like to know if your device is recognized as an ACM device. I'm also
-interested if the thing is stable or if it crashes.
-(should i say how it crases?)
-
-You should be able to add and remove devices from the bus. The driver will
-always try to fill up unused ttys. This means if you hotplug devices their
-order may have changed after reboot. This is not the behaviour Linus liked
-to see but it's ok for now. (I hope ;-)
-
-Please report your experiences to me:
-fuerst@in.tum.de
-
-***************************
-I've tested it with:
-3Com ISDN Pro TA.
-
-It should work with (That means i know these devices conform to ACM):
-3Com Office Connect Modem
-3Com Sportster USB (I think that's what it's called)
-
-***************************
-Many thanks to 3Com which did not only support me with hardware but also
-with technical support in USB questions. They also allowed me to do tests in
-their lab. Great!
-
-***************************
-Known bugs:
-Flow control not tested (likely not to work)
-Some tty function calls not implemented (putchar, etc...)
-Huge amounts of debug output (compile in [*] Magic SysRq key and press ALT+PRTSCR+0 )
-Not all mem is freed at close (need terminate irq in hcd)
-
-***************************
-Have fun,
-	Armin Fuerst
+			  Linux ACM driver v0.16
+		 (c) 1999 Vojtech Pavlik <vojtech@suse.cz>
+			     Sponsored by SuSE
+----------------------------------------------------------------------------
+
+0. Disclaimer
+~~~~~~~~~~~~~
+  This program is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2 of the License, or (at your option)
+any later version.
+
+  This program is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+more details.
+
+  You should have received a copy of the GNU General Public License along
+with this program; if not, write to the Free Software Foundation, Inc., 59
+Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+  Should you need to contact me, the author, you can do so either by e-mail
+- mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik,
+Ucitelska 1576, Prague 8, 182 00 Czech Republic
+
+  For your convenience, the GNU General Public License version 2 is included
+in the package: See the file COPYING.
+
+1. Usage
+~~~~~~~~
+  The drivers/usb/acm.c drivers works with USB modems and USB ISDN terminal
+adapters that conform to the Universal Serial Bus Communication Device Class
+Abstract Control Model (USB CDC ACM) specification.
+
+  Many modems do, here is a list of those I know of:
+
+	3Com OfficeConnect 56k
+	3Com Voice FaxModem Pro
+	3Com Sportster
+	MultiTech MultiModem 56k
+	Zoom 2986L FaxModem
+	Compaq 56k FaxModem
+	ELSA Microlink 56k
+
+  I know of one ISDN TA that does work with the acm driver:
+
+	3Com USR ISDN Pro TA
+
+  Unfortunately many modems and most ISDN TAs use proprietary interfaces and
+thus won't work with this drivers. Check for ACM compliance before buying.
+
+  The driver (with devfs) creates these devices in /dev/usb/acm:
+
+	crw-r--r--   1 root     root     166,   0 Apr  1 10:49 0
+	crw-r--r--   1 root     root     166,   1 Apr  1 10:49 1
+	crw-r--r--   1 root     root     166,   2 Apr  1 10:49 2
+
+  And so on, up to 31, with the limit being possible to change in acm.c to up
+to 256, so you can use up to 256 USB modems with one computer (you'll need
+three USB cards for that, though).
+
+  If you don't use devfs, then you can create device nodes with the same
+minor/major numbers anywhere you want, but either the above location or
+/dev/usb/ttyACM0 is preferred.
+
+  To use the modems you need these modules loaded:
+
+	usbcore.o
+	usb-[uo]hci.o or uhci.o
+	acm.o
+
+  After that, the modem[s] should be accessible. You should be able to use
+minicom, ppp and mgetty with them.
+
+2. Verifying that it works
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+  The first step would be to check /proc/bus/usb/devices, it should look
+like this:
+
+T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
+B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
+D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
+P:  Vendor=0000 ProdID=0000 Rev= 0.00
+S:  Product=USB UHCI Root Hub
+S:  SerialNumber=6800
+C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
+I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
+E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
+T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
+D:  Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  2
+P:  Vendor=04c1 ProdID=008f Rev= 2.07
+S:  Manufacturer=3Com Inc.
+S:  Product=3Com U.S. Robotics Pro ISDN TA
+S:  SerialNumber=UFT53A49BVT7
+C:  #Ifs= 1 Cfg#= 1 Atr=60 MxPwr=  0mA
+I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=acm
+E:  Ad=85(I) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
+E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
+E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=128ms
+C:* #Ifs= 2 Cfg#= 2 Atr=60 MxPwr=  0mA
+I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm
+E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=128ms
+I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm
+E:  Ad=85(I) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
+E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
+
+The presence of these three lines (and the Cls= 'comm' and 'data' classes)
+is important, it means it's an ACM device. The Driver=acm means the acm
+driver is used for the device. If you see only Cls=ff(vend.) then you're out
+of luck, you have a device with vendor specific-interface.
+
+D:  Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  2
+I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm
+I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm
+
+In the system log you should see:
+
+usb.c: USB new device connect, assigned device number 2
+usb.c: kmalloc IF c7691fa0, numif 1
+usb.c: kmalloc IF c7b5f3e0, numif 2
+usb.c: skipped 4 class/vendor specific interface descriptors
+usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3
+usb.c: USB device number 2 default language ID 0x409
+Manufacturer: 3Com Inc.
+Product: 3Com U.S. Robotics Pro ISDN TA
+SerialNumber: UFT53A49BVT7
+acm.c: probing config 1
+acm.c: probing config 2
+ttyACM0: USB ACM device
+acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0
+acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7
+usb.c: acm driver claimed interface c7b5f3e0
+usb.c: acm driver claimed interface c7b5f3f8
+usb.c: acm driver claimed interface c7691fa0
+
+If all this seems to be OK, fire up minicom and set it to talk to the ttyACM
+device and try typing 'at'. If it responds with 'OK', then everything is
+working.
diff --git a/Documentation/usb/hid.txt b/Documentation/usb/hid.txt
deleted file mode 100644
index 3cd3373ff..000000000
--- a/Documentation/usb/hid.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-			   Linux HID driver v0.8
-		 (c) 1999 Vojtech Pavlik <vojtech@suse.cz>
-		    (c) 1999 Andreas Gal <agal@uwsp.edu>
-			     Sponsored by SuSE
-----------------------------------------------------------------------------
-
-0. Disclaimer
-~~~~~~~~~~~~~
-  This program is free software; you can redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 2 of the License, or (at your option)
-any later version.
-
-  This program is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-more details.
-
-  You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc., 59
-Temple Place, Suite 330, Boston, MA 02111-1307 USA
-
-  Should you need to contact me, the author, you can do so either by e-mail
-- mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik,
-Ucitelska 1576, Prague 8, 182 00 Czech Republic
-
-  For your convenience, the GNU General Public License version 2 is included
-in the package: See the file COPYING.
-
-1. Introduction
-~~~~~~~~~~~~~~~
-  This is a driver for USB devices conforming to the USB HID (Human Input
-Device) standard. These devices include namely keyboards, mice and
-joysticks.
-
-  However many other devices (monitors, speakers, UPSs ...) also communicate
-through the same protocol, which makes its specification somewhat bloated.
-This isn't a problem, though, because the driver doesn't need to know about
-all the possible devices it can control, and can just parse the protocol and
-leave the rest of the job (for example understanding what the UPS wants to
-say) to the userland.
-
-  Because of this, the USB HID driver has two interfaces. One is via the
-proc filesystem, allowing userland applications send and read arbitrary
-reports to and from a connected USB device. The other is via a very simple
-yet generic input device driver, which dispatches input events (keystrokes,
-mouse or joystick movements) to specific, backward compatible userland
-interfaces. This way a PS/2 mouse, an AT keyboard or a Linux joystick driver
-interface are emulated, and allow applications to immediately work with USB
-mice, USB keyboards and USB joysticks without any changes.
-
-  The input driver is aimed for a little more than USB device handling in
-the future, though. It's generic enough so that it can be used for any
-mouse, keyboard or joystick (and more, of course). A PS/2 mouse driver, a
-serial mouse, Sun mouse, and most of the busmouse drivers were rewritten to
-use this as well as the AT keyboard and Sun keyboard drivers. This will
-hopefully allow conversion of all Linux keyboard and mouse and joystick
-drivers to this scheme.
-
-  This effort has it's home page at:
-
-	http://www.suse.cz/development/input/
-
-You'll find both the latest HID driver and the complete Input driver there.
-There is also a mailing list for this:
-
-	listproc@atrey.karlin.mff.cuni.cz
-
-Send "subscribe linux-joystick Your Name" to subscribe to it.
-
-2. Usage
-~~~~~~~~
-  Since the driver comes with recent 2.3 kernels, all that's needed to use
-it is to enable it either as a module or compiled-in into the kernel. 
-
-  After that, after reboot (and possibly also inserting the USB and HID
-modules) the following will happen:
-
-* If you selected keyboard support, all USB keystrokes will be also routed
-  to the Linux keyboard driver as if being input through the ordinary system
-  keyboard.
-
-* If you selected mouse support, there will be (one or more) simulated PS/2
-  mouse devices on major 10, minor 32, 33 and more. These simulated mice can
-  in addition to a standard 3-button PS/2 mouse behave like MS Intellimice,
-  with a wheel. If you want to use the wheel, just specify '-t imps2' to gpm
-  and 'Protocol "ImPS/2"' to X, and it will work. A single emulated mouse
-  device can be open by any number of processes (unlike the /dev/psaux), and
-  for each of them the emulation is separate, each can use a different mode.
-  The mousedev driver, which emulates the mice, can also emulate a Genius
-  NewScroll 5 buttons-and-a-wheel mouse, if you set it to a Genius PS/2
-  mode ('-t netmouse' 'Protocol "NetMousePS/2"'). However, not gpm, nor X
-  can decode the 5 buttons yet, so this isn't very useful right now.
-
-* If you selected joystick support, the driver will take over major 15, the
-  joystick major number, and will emulate joysticks on it. This means the
-  normal joystick driver can't be used together with it (now, after the
-  normal joystick drivers are converted to the input scheme, all will work
-  nicely together). Also, you'll probably need to calibrate your joystick
-  manually ('man jscal') to be able to use it, because the USB
-  autocalibration is far from perfect yet.
-
-* If you selected event device support, there will be devices on major 10,
-  minors 64, 65 and more for each input device connected through this
-  driver. These devices output raw events the input driver dispatches. Each
-  has a timestamp. This hopefully will be THE way X will talk to keyboard
-  and mice, because it's hardware independent, and not limited by existing
-  de-facto standards.
-
-3. Verifying if it works
-~~~~~~~~~~~~~~~~~~~~~~~~
-  Typing a couple keys on the keyboard should be enough to check that a USB
-keyboard works and is correctly connected to the kernel keyboard driver.
-
-  Doing a cat /dev/hidmouse (c, 10, 32) will verify that a mouse is also
-emulated, characters should appear if you move it.
-
-  You can test the joystick emulation with the 'jstest' utility, available
-in the joystick package (see Documentation/joystick.txt).
-
-  You can test the event devics with the 'evtest' utitily available on the
-input driver homepage (see the URL above).
-
-4. FAQ
-~~~~~~
-Q: Why aren't any questions here yet?
-A: Because none were frequent enough yet.
-
-5. Event interface
-~~~~~~~~~~~~~~~~~~
-  Should you want to add event device support into any application (X, gpm,
-svgalib ...) I (vojtech@suse.cz) will be happy to provide you any help I
-can. Here goes a description of the current state of things, which is going
-to be extended, but not changed incompatibly as time goes:
-
-  You can use blocking and nonblocking reads, also select() on the
-/dev/inputX devices, and you'll always get a whole number of input events on
-a read. Their layout is:
-
-struct input_event {
-	struct timeval time;
-	unsigned short type;
-	unsigned short code;
-	unsigned int value;
-};
-
-  'time' is the timestamp, it returns the time at which the event happened.
-Type is for example EV_REL for relative momement, REL_KEY for a keypress or
-release. More types are defined in include/linux/input.h.
-
-  'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete
-list is in include/linux/input.h.
-
-  'value' is the value the event carries. Either a relative change for
-EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
-release, 1 for keypress and 2 for autorepeat.
-
-6. Proc interface
-~~~~~~~~~~~~~~~~~
-  For HID-specific devices there is also the /proc interface. It isn't
-present in this release yet, though, so it's description will appear here
-together with the code in the driver.
diff --git a/Documentation/usb/ibmcam.txt b/Documentation/usb/ibmcam.txt
index 5943227a6..21d07c0ba 100644
--- a/Documentation/usb/ibmcam.txt
+++ b/Documentation/usb/ibmcam.txt
@@ -7,8 +7,7 @@ the IBM camera. However most of needed features work well.
 
 This driver was developed using logs of observed USB traffic
 which was produced by standard Windows driver (c-it98.sys).
-I did not have any input from Xirlink. Some people asked about
-data sheets, but nothing came out of that. I didn't try.
+I did not have data sheets from Xirlink.
 
 Video formats:
       128x96  [model 1]
@@ -29,14 +28,16 @@ SUPPORTED CAMERAS:
 IBM "C-It" camera, also known as "Xirlink PC Camera"
 The device uses proprietary ASIC (and compression method);
 it is manufactured by Xirlink. See http://www.xirlink.com/
-or http://www.c-itnow.com/ for details and pictures.
+http://www.ibmpccamera.com or http://www.c-itnow.com/ for
+details and pictures.
 
 The Linux driver was developed with camera with following
 model number (or FCC ID): KSX-XVP510. This camera has three
 interfaces, each with one endpoint (control, iso, iso). This
-type of cameras is referred to as "model 1".
+type of cameras is referred to as "model 1". These cameras are
+no longer manufactured.
 
-It appears that Xirlink made some changes in their cameras recently.
+Xirlink now manufactures new cameras which are somewhat different.
 In particular, following models [FCC ID] belong to that category:
 
 XVP300 [KSX-X9903]
@@ -46,29 +47,20 @@ XVP610 [KSX-X9902]
 (see http://www.xirlink.com/ibmpccamera/ for updates, they refer
 to these new cameras by Windows driver dated 12-27-99, v3005 BETA)
 These cameras have two interfaces, one endpoint in each (iso, bulk).
-Such type of cameras is referred to as "model 2". They are supported.
+Such type of cameras is referred to as "model 2". They are supported
+(with exception of 352x288 native mode).
 
 Quirks of Model 2 cameras:
 -------------------------
 
-These cameras apparently produce only 176x144 native video stream;
-the 352x288 formats are produced from 176x144 RGB stream. In fact,
-Xirlink broke perfectly good Model 1 (which used I420 on all sizes)
-and instead switched to color-separated RGB which is a terrible waste
-of bandwidth and resolution. However it probably allowed to simplify
-the camera and use less RAM. Model 2 camera works visibly worse than
-model 1 even using Xirlink's own driver on Windows. The image quality
-is better on Linux than on Windows, partly thanks to _absence_ of
-annoying automatic color corrections which Windows driver feeds into
-the camera several times per second.
-
 Model 2 does not have hardware contrast control. Corresponding V4L
 control is not used at the moment. It may be possible to implement
 contrast control in software, at cost of extra processor cycles.
 
-The bandwidth demand imposed by RGB quasi-352x288 mode (800 Kbits per
-frame) essentially limits this mode to 10 frames per second or less, in
-ideal conditions on the bus (USB is shared, after all). The frame rate
+This driver provides 352x288 mode by switching the camera into
+quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting
+this mode to 10 frames per second or less, in ideal conditions on
+the bus (USB is shared, after all). The frame rate
 has to be programmed very conservatively. Additional concern is that
 frame rate depends on brightness setting; therefore the picture can
 be good at one brightness and broken at another! I did not want to fix
@@ -81,24 +73,21 @@ try to adjust brightness - brighter image is slower, so USB will be able
 to send all data. However if you regularly use Model 2 cameras you may
 prefer videosize=1 which makes perfectly good I420, with no scaling and
 lesser demands on USB (300 Kbits per second, or 26 frames per second).
-Remember that model 2 cameras never produce images with resolution
-better than "true" 176x144 - or so it seems.
 
 The camera that I had also has a hardware quirk: if disconnected,
 it needs few minutes to "relax" before it can be plugged in again
 (poorly designed USB processor reset circuit?)
 
-Finally, to say something good about Model 2: it is much simpler to program
-than Model 1. Commands are few, and they all are straightforward. This camera
-can be programmed for very high sensitivity (starlight may be enough), this
-makes it convenient for tinkering with. The driver code has enough comments
-to help a programmer to tweak the camera as s/he feels necessary.
+Model 2 camera can be programmed for very high sensitivity (even starlight
+may be enough), this makes it convenient for tinkering with. The driver
+code has enough comments to help a programmer to tweak the camera
+as s/he feels necessary.
 
 WHAT YOU NEED:
 
 - A supported IBM PC (C-it) camera (model 1 or 2)
 
-- A Linux box with USB support (2.3/2.4 or 2.2 w/backport)
+- A Linux box with USB support (2.3/2.4; 2.2 w/backport may work)
 
 - A Video4Linux compatible frame grabber program such as xawtv.
   
@@ -179,6 +168,19 @@ flags           This is a bit mask, and you can combine any number of
                 FLAGS_OVERLAY_STATS     8  Shows tiny numbers on screen,
                                            useful only for debugging.
                 FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers.
+                FLAGS_SEPARATE_FRAMES   32 Shows each frame separately, as
+                                           it was received from the camera.
+                                           Default (not set) is to mix the
+                                           preceding frame in to compensate
+                                           for occasional loss of Isoc data
+                                           on high frame rates.
+                FLAGS_CLEAN_FRAMES      64 Forces "cleanup" of each frame
+                                           prior to use; relevant only if
+                                           FLAGS_SEPARATE_FRAMES is set.
+                                           Default is not to clean frames,
+                                           this is a little faster but may
+                                           produce flicker if frame rate is
+                                           too high and Isoc data gets lost.
 
 framerate       This setting controls frame rate of the camera. This is
                 an approximate setting (in terms of "worst" ... "best")
diff --git a/Documentation/usb/input.txt b/Documentation/usb/input.txt
new file mode 100644
index 000000000..ebf9058de
--- /dev/null
+++ b/Documentation/usb/input.txt
@@ -0,0 +1,294 @@
+			  Linux Input drivers v0.9
+		 (c) 1999 Vojtech Pavlik <vojtech@suse.cz>
+			     Sponsored by SuSE
+----------------------------------------------------------------------------
+
+0. Disclaimer
+~~~~~~~~~~~~~
+  This program is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2 of the License, or (at your option)
+any later version.
+
+  This program is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+more details.
+
+  You should have received a copy of the GNU General Public License along
+with this program; if not, write to the Free Software Foundation, Inc., 59
+Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+  Should you need to contact me, the author, you can do so either by e-mail
+- mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik,
+Ucitelska 1576, Prague 8, 182 00 Czech Republic
+
+  For your convenience, the GNU General Public License version 2 is included
+in the package: See the file COPYING.
+
+1. Introduction
+~~~~~~~~~~~~~~~
+  This is a collection of drivers that is designed to support all input
+devices under Linux. However, in the current kernels, although it's
+possibilities are much bigger, it's limited to USB devices only. This is
+also why it resides in the drivers/usb subdirectory.
+
+  The center of the input drivers is the input.o module, which must be
+loaded before any other of the input modules - it serves as a way of
+communication between two groups of modules:
+
+1.1 Device drivers
+~~~~~~~~~~~~~~~~~~
+  These modules talk to the hardware (for example via USB), and provide
+events (keystrokes, mouse movements) to the input.o module.
+
+1.2 Event handlers
+~~~~~~~~~~~~~~~~~~
+  These modules get events from input.o and pass them where needed via
+various interfaces - keystrokes to the kernel, mouse movements via a
+simulated PS/2 interface to GPM and X and so on.
+
+2. Simple Usage
+~~~~~~~~~~~~~~~
+  For the most usual configuration, with one USB mouse and one USB keyboard,
+you'll have to load the following modules (or have them built in to the
+kernel):
+
+	input.o
+	mousedev.o
+	keybdev.o
+	usbcore.o
+	usb-[uo]hci.o
+	hid.o
+
+  After this, the USB keyboard will work straight away, and the USB mouse
+will be available as a character device on major 13, minor 32:
+
+	crw-r--r--   1 root     root      13,  32 Mar 28 22:45 mouse0
+
+  This device, has to be created, unless you use devfs, in which case it's
+created automatically. The commands to do that are:
+
+	cd /dev
+	mkdir input
+	mknod input/mouse0 c 13 32
+
+  After that you have to point GPM (the textmode mouse cut&paste tool) and
+XFree to this device to use it - GPM should be called like:
+
+	gpm -t ps2 -m /dev/input/mouse0
+
+  And in X:
+
+	Section "Pointer"
+	    Protocol    "ImPS/2"
+	    Device      "/dev/input/mouse0"
+	    ZAxisMapping 4 5
+	EndSection
+
+  When you do all of the above, you can use your USB mouse and keyboard.
+
+3. Detailed Description
+~~~~~~~~~~~~~~~~~~~~~~~
+3.1 Device drivers
+~~~~~~~~~~~~~~~~~~
+  Device drivers are the modules that generate events. The events are
+however not useful without being handled, so you also will need to use some
+of the modules from section 3.2.
+
+3.1.1 hid.c
+~~~~~~~~~~~
+  Hid.c is the largest and most complex driver of the whole suite. It
+handles all HID devices, and because there is a very wide variety of them,
+and because the USB HID specification isn't simple, it needs to be this big.
+
+  Currently, it handles USB mice, joysticks, gamepads, steering wheels
+keyboards, trackballs and digitizers.
+
+ However, USB uses HID also for monitor controls, speaker controls, UPSs,
+LCDs and many other purposes.
+
+ The monitor and speaker controls should be easy to add to the hid/input
+interface, but for the UPSs and LCDs it doesn't make much sense. The driver
+doesn't support these yet, and a new, non-event interface should be designed
+for them. If you have any of these devices (I don't), feel free to design
+something and if it's good, it'll get into the driver.
+
+  The usage of the hid.o module is very simple, it takes no parameters,
+detects everything automatically and when a HID device is inserted, it
+detects it appropriately.
+
+  However, because the devices vary wildly, you might happen to have a
+device that doesn't work well. In that case #define DEBUG at the beginning
+of hid.c and send me the syslog traces.
+
+3.1.2 usbmouse.c
+~~~~~~~~~~~~~~~~
+  For embedded systems, for mice with broken HID descriptors and just any
+other use when the big hid.c wouldn't be a good choice, there is the
+usbmouse.c driver. It handles USB mice only. It uses a simpler HIDBP
+protocol. This also means the mice must support this simpler protocol. Not
+all do. If you don't have any strong reason to use this module, use hid.c
+instead.
+
+3.1.3 usbkbd.c
+~~~~~~~~~~~~~~
+  Much like usbmouse.c, this module talks to keyboards with a simpplified
+HIDBP protocol. It's smaller, but doesn't support any extra special keys.
+Use hid.c instead if there isn't any special reason to use this.
+
+3.1.4 wacom.c
+~~~~~~~~~~~~~
+  This is a driver for Wacom Graphire and Intuos tablets. Not for Wacom
+PenPartner, that one is handled by the HID driver. Although the Intuos and
+Graphire tablets claim that they are HID tablets as well, they are not and
+thus need this specific driver.
+
+3.1.5 wmforce.c
+~~~~~~~~~~~~~~~
+  A driver for the Logitech WingMan Force joysticks, when connected via the
+USB port. It works quite well, but there is no force feedback support yet,
+because the interface to do that is a trade secret of Immersion Corp, and
+even Logitech can't disclose it.
+
+  Support for Logitech WingMan Force Wheel isn't present in this driver, but
+if someone has the device, and is willing to cooperate, it should be a
+matter of a couple days to add it.
+
+3.2 Event handlers
+~~~~~~~~~~~~~~~~~~
+  Event handlers distrubite the events from the devices to userland and
+kernel, as needed.
+
+3.2.1 keybdev.c
+~~~~~~~~~~~~~~~
+  Keybdev is currently a rather ugly hack that translates the input events
+into architecture-specific keyboard raw mode (Xlated AT Set2 on x86), and
+passes them into the handle_scancode function of the keyboard.c module. This
+works well enough on all architectures that keybdev can generate rawmode on,
+other architectures can be added to it.
+
+  The right way would be to pass the events to keyboard.c directly, best if
+keyboard.c would itself be an event handler. This is done in the input
+patch, available on the webpage mentioned below.
+
+3.2.2 mousedev.c
+~~~~~~~~~~~~~~~~
+  Mousedev is also a hack to make programs that use mouse input work. It
+takes events from either mice or digitizers/tablets and makes a PS/2-style
+(a la /dev/psaux) mouse device available to the userland. Ideally, the
+programs could use a more reasonable interface, for example evdev.c
+
+  Mousedev devices in /dev/input (as shown above) are:
+
+	crw-r--r--   1 root     root      13,  32 Mar 28 22:45 mouse0
+	crw-r--r--   1 root     root      13,  33 Mar 29 00:41 mouse1
+	crw-r--r--   1 root     root      13,  34 Mar 29 00:41 mouse2
+	crw-r--r--   1 root     root      13,  35 Apr  1 10:50 mouse3
+
+and so on, up to mouse31. Each is assigned to a single mouse or digitizer,
+unless CONFIG_INPUT_MOUSEDEV_MIX is set. In that case all mice and
+digitizers share a single character device, mouse0, and even when none are
+connected, mouse0 is present. This is useful for hotplugging USB mice, so
+that programs can open the device even when no mice are present.
+
+  CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] in the kernel configuration are the size
+of your screen (in pixels) in XFree86. This is needed if you want to use
+your digitizer in X, because it's movement is sent to X via a virtual PS/2
+mouse.
+
+  Mousedev.c will generate either PS/2, ImPS/2 (microsoft intellimouse) or
+GenPS/2 (genius netmouse/netscroll) protocols, depending on what the program
+wishes. You can set GPM and X to any of these. You'll need ImPS/2 if you
+want to make use of a wheel on a USB mouse and GenPS/2 if you want to use
+extra (up to 5) buttons. I'm not sure how much is GenPS/2 supported in X,
+though.
+
+3.2.3 joydev.c
+~~~~~~~~~~~~~~
+  Joydev implements v0.x and v1.x Linux joystick api, much like
+drivers/char/joystick/joystick.c. See joystick-api.txt in the Documentation
+subdirectory for details. Joydev does it on top of the input subsystem,
+though. As soon as any USB joystick is connected, it can be accessed in
+/dev/input on:
+
+	crw-r--r--   1 root     root      13,   0 Apr  1 10:50 js0
+	crw-r--r--   1 root     root      13,   1 Apr  1 10:50 js1
+	crw-r--r--   1 root     root      13,   2 Apr  1 10:50 js2
+	crw-r--r--   1 root     root      13,   3 Apr  1 10:50 js3
+
+And so on up to js31.
+
+3.2.4 evdev.c
+~~~~~~~~~~~~~
+  Evdev is the generic input event interface. It passes the events generated
+in the kernel straight to the program, with timestamps. The API is still
+evolving, but should be useable now. It's described in section 5.
+
+  This should be the way for GPM and X to get keyboard and mouse mouse
+events. It allows for multihead in X without any specific multihead kernel
+support. The event codes are the same on all architectures and are hardware
+independent.
+
+  The devices are in /dev/input:
+
+	crw-r--r--   1 root     root      13,  64 Apr  1 10:49 event0
+	crw-r--r--   1 root     root      13,  65 Apr  1 10:50 event1
+	crw-r--r--   1 root     root      13,  66 Apr  1 10:50 event2
+	crw-r--r--   1 root     root      13,  67 Apr  1 10:50 event3
+
+3. Contacts
+~~~~~~~~~~~
+  This effort has it's home page at:
+
+	http://www.suse.cz/development/input/
+
+You'll find both the latest HID driver and the complete Input driver there.
+There is also a mailing list for this:
+
+	majordomo@atrey.karlin.mff.cuni.cz
+
+Send "subscribe linux-input" to subscribe to it.
+
+4. Verifying if it works
+~~~~~~~~~~~~~~~~~~~~~~~~
+  Typing a couple keys on the keyboard should be enough to check that a USB
+keyboard works and is correctly connected to the kernel keyboard driver.
+
+  Doing a cat /dev/input/mouse0 (c, 13, 32) will verify that a mouse is also
+emulated, characters should appear if you move it.
+
+  You can test the joystick emulation with the 'jstest' utility, available
+in the joystick package (see Documentation/joystick.txt).
+
+  You can test the event devics with the 'evtest' utitily available on the
+input driver homepage (see the URL above).
+
+5. Event interface
+~~~~~~~~~~~~~~~~~~
+  Should you want to add event device support into any application (X, gpm,
+svgalib ...) I <vojtech@suse.cz> will be happy to provide you any help I
+can. Here goes a description of the current state of things, which is going
+to be extended, but not changed incompatibly as time goes:
+
+  You can use blocking and nonblocking reads, also select() on the
+/dev/inputX devices, and you'll always get a whole number of input events on
+a read. Their layout is:
+
+struct input_event {
+	struct timeval time;
+	unsigned short type;
+	unsigned short code;
+	unsigned int value;
+};
+
+  'time' is the timestamp, it returns the time at which the event happened.
+Type is for example EV_REL for relative momement, REL_KEY for a keypress or
+release. More types are defined in include/linux/input.h.
+
+  'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete
+list is in include/linux/input.h.
+
+  'value' is the value the event carries. Either a relative change for
+EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
+release, 1 for keypress and 2 for autorepeat.
diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt
index 757f7458f..b4c536ec1 100644
--- a/Documentation/usb/ov511.txt
+++ b/Documentation/usb/ov511.txt
@@ -5,42 +5,17 @@ Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC
 Author: Mark McClelland
 Homepage: http://alpha.dyndns.org/ov511
 
+NEW IN THIS VERSION:
+ o Support for OV511+
+ o Support for OV7620
+
 INTRODUCTION:
 
 This is a preliminary version of my OV511 Linux device driver. Currently, it can
 grab a frame in color (YUV420) at 640x480 or 320x240 using either vidcat or
 xawtv. Other utilities may work but have not yet been tested.
 
-NEW IN THIS VERSION:
- o Preliminary snapshot support
- o Experimental red-blue misalignment fixes
- o Better YUV420 color conversion
- o Module options
- o Finer-grained debug message control
- o Support for new cameras (4, 36)
- o Uses initcalls
-
-SUPPORTED CAMERAS:
-_________________________________________________________
-Manufacturer     | Model           | Custom ID | Status
------------------+-----------------+-----------+---------
-MediaForte       | MV300           | 0         | Working
-Aiptek           | HyperVCam ?     | 0         | Working
-NetView          | NV300M          | 0         | Working
-D-Link           | DSB-C300        | 3         | Working
-Hawking Tech.    | ???             | 3         | Working
-???              | Generic         | 4         | Untested
-Puretek          | PT-6007         | 5         | Working
-Creative Labs    | WebCam 3        | 21        | Working
-???              | Koala-Cam       | 36        | Untested
-Lifeview         | RoboCam         | 100       | Untested
-AverMedia        | InterCam Elite  | 102       | Working
-MediaForte       | MV300           | 112       | Working
-Omnivision       | OV7110 EV board | 112       | Working*
----------------------------------------------------------
-(*) uses OV7110 (monochrome)
-
-Any camera using the OV511 and the OV7610 CCD should work with this driver. The
+Any camera using the OV511/OV511+ and the OV7610/20/20AE CCD should work. The
 driver only detects known cameras though, based on their custom id number. If
 you have a currently unsupported camera, the ID number should be reported to you
 in the kernel logs. Please send me the model, manufacturer and ID number and I 
@@ -140,7 +115,7 @@ MODULE PARAMETERS:
   DESC: The camera normally adjusts exposure, gain, and hue automatically. This
         can be set to 0 to disable this automatic adjustment. Note that there is
         currently no way to set these parameters manually once autoadjust is
-        disabled. (This feature is not working yet)
+        disabled.
 
   NAME: debug
   TYPE: integer (0-6)
@@ -174,7 +149,8 @@ WORKING FEATURES:
  o Color streaming/capture at 640x480 and 320x240
  o YUV420 color
  o Monochrome
- o Setting/getting of saturation, contrast and brightness (no color yet)
+ o Setting/getting of saturation, contrast and brightness (no hue yet; only
+   works with OV7610, not the OV7620 or OV7620AE)
 
 EXPERIMENTAL FEATURES:
  o fix_rgb_offset: Sometimes works, but other times causes errors with xawtv and
@@ -197,13 +173,13 @@ TODO:
  o Get hue (red/blue channel balance) adjustment working (in ov511_get_picture()
    and ov511_set_picture())
  o Get autoadjust disable working
- o Devise some clean way to support different types of CCDs (based on Custom ID)
- o OV511A support
  o V4L2 support (Probably not until it goes into the kernel)
  o Fix I2C initialization. Some people are reporting problems with reading the
    7610 registers. This could be due to timing differences, an excessive I2C
    clock rate, or a problem with ov511_i2c_read().
  o Get rid of the memory management functions (put them in videodev.c??)
+ o Setting of contrast and brightness not working with 7620
+ o Driver/camera state save/restore for when USB supports suspend/resume
 
 HOW TO CONTACT ME:
 
diff --git a/Documentation/usb/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt
index 8d1066a9f..84510b950 100644
--- a/Documentation/usb/proc_usb_info.txt
+++ b/Documentation/usb/proc_usb_info.txt
@@ -1,16 +1,17 @@
 /proc/bus/usb filesystem output
 ===============================
-(version 19991218)
+(version 2000.03.24)
 
 
 The /proc filesystem for USB devices generates
 /proc/bus/usb/drivers and /proc/bus/usb/devices.
 
-/proc/bus/usb/drivers just lists the registered drivers,
-one per line.  Not very interesting or pretty.
+/proc/bus/usb/drivers lists the registered drivers,
+one per line, with each driver's USB minor dev node
+number range if applicable.
 
 In /proc/bus/usb/devices, each device's output has multiple
-lines (except for a root hub) of ASCII output.
+lines of ASCII output.
 I made it ASCII instead of binary on purpose, so that someone
 can obtain some useful data from it without the use of an
 auxiliary program.  However, with an auxiliary program, the numbers
@@ -22,11 +23,12 @@ different topo/connections and it looked possible.)
 Each line is tagged with a one-character ID for that line:
 
 T = Topology (etc.)
-B = Bandwidth
+B = Bandwidth (applies only to USB host controllers, which are
+    virtualized as root hubs)
 D = Device descriptor info.
 P = Product ID info. (from Device descriptor, but they won't fit
     together on one line)
-S = String info
+S = String descriptors.
 C = Configuration descriptor info. (* = active configuration)
 I = Interface descriptor info.
 E = Endpoint descriptor info.
@@ -93,7 +95,17 @@ S:  Manufacturer=ssss
 |__String info tag
 
 S:  Product=ssss
-|   |__Product description of this device as read from the device.
+|   |__Product description of this device as read from the device,
+|      except that it is a generated string for USB host controllers
+|      (virtual root hubs), in the form "USB *HCI Root Hub".
+|__String info tag
+
+S:  SerialNumber=ssss
+|   |__Serial Number of this device as read from the device,
+|      except that it is a generated string for USB host controllers
+|      (virtual root hubs), and represent's the host controller's
+|      unique identification in the system (currently I/O or
+|      memory-mapped base address).
 |__String info tag
 
 
@@ -142,7 +154,7 @@ where the valid characters are TDPCIE.  With a slightly more able
 script, it can display any selected lines (for example, only T, D,
 and P lines) and change their output format.  (The "procusb"
 Perl script is the beginning of this idea.  It will list only
-selected lines [selected from TDPCIE] or "All" lines from
+selected lines [selected from TBDPSCIE] or "All" lines from
 /proc/bus/usb/devices.)
 
 The Topology lines can be used to generate a graphic/pictorial
@@ -163,6 +175,13 @@ a serial converter connected to the external hub.
 
 T:  Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
 B:  Alloc= 28/900 us ( 3%), #Int=  2, #Iso=  0
+D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
+P:  Vendor=0000 ProdID=0000 Rev= 0.00
+S:  Product=USB UHCI Root Hub
+S:  SerialNumber=dce0
+C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
+I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
+E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
 T:  Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 4
 D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
 P:  Vendor=0451 ProdID=1446 Rev= 1.00
diff --git a/Documentation/usb/scanner-hp-sane.txt b/Documentation/usb/scanner-hp-sane.txt
index a1cbcd1b4..c47491765 100644
--- a/Documentation/usb/scanner-hp-sane.txt
+++ b/Documentation/usb/scanner-hp-sane.txt
@@ -1,10 +1,11 @@
 Copyright (C) 1999, 2000 David E. Nelson
 
-Jan. 22, 2000
+Mar. 23, 2000
 
 CHANGES
 
 - Amended for Linux-2.3.40
+- Updated for multiple scanner support
 
 
 INTRODUCTION
@@ -30,13 +31,13 @@ http://www.mostang.com/sane/.  Testing has been performed using
 version SANE-1.0.1.  For instructions on building and installing SANE,
 refer to the various README files within the SANE distribution.
 
-The latest SANE HP backend available from http://www.kirchgessner.net.
+The latest SANE HP backend is available from http://www.kirchgessner.net.
 At the time of this writing, version 0.83 was available.
 
 
 OK, I'VE INSTALLED SANE. SO WHAT DO I DO NOW?
 
-NOTE: $INSTALL_DIR is the location where SANE was installed.  It may
+NOTE: $INSTALL_DIR is the location where SANE is installed.  It may
 be /usr/local, /usr, /opt or somewhere else.  If you don't know, ask
 your system administrator.
 
@@ -54,6 +55,9 @@ files: dll.conf, hp.conf.
     /dev/usbscanner
     option connect-device
 
+NOTE: If you are using multiple scanners, make sure to have the correct
+devince, ie /dev/usbscanner0.  See scanner.txt for more info.
+
 3) You should now be able to use SANE (xscanimage or scanimage).
 
 Don't forget to read any relevant man pages regarding the usage of
diff --git a/Documentation/usb/scanner.txt b/Documentation/usb/scanner.txt
index 193035085..a750e191d 100644
--- a/Documentation/usb/scanner.txt
+++ b/Documentation/usb/scanner.txt
@@ -1,12 +1,15 @@
 Copyright (C) 1999, 2000 David E. Nelson
 
-Jan. 22, 2000
+Mar. 23, 2000
 
 CHANGES
 
 - Amended for linux-2.3.40
 - Appended hp_scan.c to end of this README
 - Removed most references to HP
+- Updated uhci/ohci host controller info
+- Updated support for multiple scanner support
+- Updated supported scanners list
 
 
 OVERVIEW
@@ -28,10 +31,8 @@ http://www.linux-usb.org/
 REQUIREMENTS
 
 A host with a USB port.  Ideally, either a UHCI (Intel) or OHCI
-(Compaq and others) hardware port should work.  However, I've only
-been able to really use an OHCI controller.  At the time of this
-writing, both uhci and ohci work with scanner.c *except* for the HP
-4100C which only works with ohci.  This problem is being investigated.
+(Compaq and others) hardware port should work.  At the time of this
+writing, there are two UHCI drivers and one OHCI.
 
 A Linux development kernel (2.3.x) with USB support enabled or a
 backported version to linux-2.2.x.  See http://www.linux-usb.org for
@@ -69,12 +70,26 @@ hardware (determined from the steps above), 'USB Scanner support', and
 (you may need to execute `depmod -a` to update the module
 dependencies).  Testing was performed only as modules, YMMV.
 
-Add a device for the USB scanner:
-  `mknod /dev/usbscanner c 180 48`
+Beginning with version 0.4 of the driver, up to 16 scanners can be
+connected/used simultaneously.  If you intend to use more than
+one scanner at a time:
 
-Set appropriate permissions for /dev/usbscanner (don't forget about
-group and world permissions).  Both read and write permissions are
-required for proper operation.
+   Add a device for the USB scanner:
+	`mknod /dev/usbscanner0 c 180 48`
+	`mknod /dev/usbscanner1 c 180 49`
+                      . 
+                      .
+	`mknod /dev/usb/scanner15 180 63`
+
+
+If you forsee using only one scanner:
+	`mknod /dev/usbscanner0 c 180 48`
+	`ln -s /dev/usbscanner0 /dev/usbscanner`
+
+
+Set appropriate permissions for /dev/usbscanner[0-15] (don't forget
+about group and world permissions).  Both read and write permissions
+are required for proper operation.
 
 Load the appropriate modules (if compiled as modules):
 
@@ -110,25 +125,49 @@ support the listed USB products.
 At the time of this writing, the following scanners were supported by
 scanner.c:
 
+  Acer
+
+    Prisa AcerScan 620U
+
+  Agfa
+
+    SnapScan 1212U, SnapScan Touch
+
+  Genius
+
+    ColorPage Vivid Pro
+
   Hewlett Packard
 
     3300, 4100, 4200, 5200, 6200, 6300, PhotoSmart S20
 
-  AGFA
+  Microtek
 
-    SnapScan 1212U
+    ScanMaker X6-X6U, Phantom 336CX - C3, Phantom C6, ScanMaker V6USL,
+    ScanMaker V6UL - SpicyU
 
-  Umax
+  Mustek
+
+    1200 CU
 
-    Astra 2000U
+  Primax/Colorado
+
+    G2-300, G2-600, G2E-300, G2E-600, ReadyScan 636i, Colorado USB
+    19200, Colorado 600u, Colorado 1200u
 
   Seiko/Epson
 
-    Perfection 636, Perfection 1200U
+    Perfection Perfection 610, Perfection 636U/636Photo, Perfection
+    1200U/1200Photo
 
-  Mustek
+  Umax
+
+    Astra 1220U, 1236U, 2000U
+
+  Visioneer
+
+    OneTouch 5300, OneTouch 7600, 6100,
 
-    1200 CU
 
   User Specified.  See MODULE PARAMETERS for details.
 
@@ -142,11 +181,11 @@ options to the driver.  Simply add 'options scanner vendor=0x####
 product=0x****' to the conf.modules/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` if USB /proc
-support was selected during kernel configuration.  In later kernels
-(2.3.38+), a new filesystem was introduced, usbdevfs.  To mount the
-filesystem, issue the command `mount -t usbdevfs /proc/bus/usb
-/proc/bus/usb`.  You can then issue ` cat /proc/bus/usb/devices` to
-extract USB device information.
+support was selected during kernel configuration.  **NOTE**:In later
+kernels (2.3.38+), a new filesystem was introduced, usbdevfs.  To
+mount the filesystem, issue the command `mount -t usbdevfs
+/proc/bus/usb /proc/bus/usb`.  You can then issue ` cat
+/proc/bus/usb/devices` to extract USB device information.
 
 
 BUGS
diff --git a/Documentation/usb/usb-help.txt b/Documentation/usb/usb-help.txt
new file mode 100644
index 000000000..9abd4a08b
--- /dev/null
+++ b/Documentation/usb/usb-help.txt
@@ -0,0 +1,16 @@
+usb-help.txt
+2000-March-24
+
+For USB help other than the readme files that are located in
+linux/Documentation/usb/*, see the following:
+
+Linux-USB project:  http://www.linux-usb.org
+  mirrors at        http://www.suse.cz/development/linux-usb/
+         and        http://usb.in.tum.de/linux-usb/
+Linux USB Guide:    http://linuxusbguide.sourceforge.net
+Linux-USB device overview (working devices and drivers):
+                    http://www.qbik.ch/usb/devices/
+    
+The Linux-USB mailing list is linux-usb@suse.com .
+
+###