OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /or1k/trunk/linux/linux-2.4/Documentation/usb
    from Rev 1275 to Rev 1765
    ↔ Reverse comparison
  •

Rev 1275 → Rev 1765

/brlvger.txt
0,0 → 1,36
Kernel Driver for the Tieman Voyager Braille Display (USB)
 
Authors:
 
 
 
Version 0.8, April 2002
 
The brlvger driver supports a Braille display (aka Braille terminal)
model Voyager from Tieman.
 
The driver has been in heavy use for about six months now (as of April
2002) by a very few users (about 3-4), who say it has worked very well
for them.
 
We have tested it with a Voyager 44, but it should also support
the Voyager 70.
 
This driver implements a character device which allows userspace programs
access to the braille displays raw functions. You still need a userspace
program to perform the screen-review functions and control the
display. Get BRLTTY from http://mielke.cc/brltty/ (version 2.99.8 or
later). It has a Voyager driver which interfaces with this kernel driver.
 
The interface is through a character device, major 180, minor 128, called
"brlvger" under devfs.
 
Many thanks to the Tieman people: Corand van Strien, Ivar Illing, Daphne
Vogelaar and Ingrid Vogel. They provided us with a Braille display (as
well as programming information) so that we could write this driver. They
replaced the display when it broke and they answered our technical
questions. It is very motivating when companies take an interest in such
projects and are so supportive.
 
Thanks to Andor Demarteau <ademarte@students.cs.uu.nl> who got this whole
project started and beta-tested all our early buggy attempts.
/hiddev.txt
0,0 → 1,162
Care and feeding of your Human Interface Devices
 
INTRODUCTION
 
In addition to the normal input type HID devices, USB also uses the
human interface device protocols for things that are not really human
interfaces, but have similar sorts of communication needs. The two big
examples for this are power devices (especially uninterruptable power
supplies) and monitor control on higher end monitors.
 
To support these disparite requirements, the Linux USB system provides
HID events to two seperate interfaces:
* the input subsystem, which converts HID events into normal input
device interfaces (such as keyboard, mouse and joystick) and a
normalised event interface - see Documentation/input/input.txt
* the hiddev interface, which provides fairly raw HID events
 
The data flow for a HID event produced by a device is something like
the following :
 
usb.c ---> hid.c ----> input.c ----> [keyboard/mouse/joystick/event]
|
|
--> hiddev.c ----> POWER / MONITOR CONTROL
 
In addition, other subsystems (apart from USB) can potentially feed
events into the input subsystem, but these have no effect on the hid
device interface.
 
USING THE HID DEVICE INTERFACE
 
The hiddev interface is a char interface using the normal USB major,
with the minor numbers starting at 96 and finishing at 111. Therefore,
you need the following commands:
mknod /dev/usb/hiddev0 c 180 96
mknod /dev/usb/hiddev1 c 180 97
mknod /dev/usb/hiddev2 c 180 98
mknod /dev/usb/hiddev3 c 180 99
mknod /dev/usb/hiddev4 c 180 100
mknod /dev/usb/hiddev5 c 180 101
mknod /dev/usb/hiddev6 c 180 102
mknod /dev/usb/hiddev7 c 180 103
mknod /dev/usb/hiddev8 c 180 104
mknod /dev/usb/hiddev9 c 180 105
mknod /dev/usb/hiddev10 c 180 106
mknod /dev/usb/hiddev11 c 180 107
mknod /dev/usb/hiddev12 c 180 108
mknod /dev/usb/hiddev13 c 180 109
mknod /dev/usb/hiddev14 c 180 110
mknod /dev/usb/hiddev15 c 180 111
 
So you point your hiddev compliant user-space program at the correct
interface for your device, and it all just works.
 
Assuming that you have a hiddev compliant user-space program, of
course. If you need to write one, read on.
 
 
THE HIDDEV API
This description should be read in conjunction with the HID
specification, freely available from http://www.usb.org, and
conveniently linked of http://www.linux-usb.org.
 
The hiddev API uses a read() interface, and a set of ioctl() calls.
 
 
read():
This is the event interface. When the HID device performs an
interrupt transfer, indicating a change of state, data will be made
available at the associated hiddev device with the content of a struct
hiddev_event:
 
struct hiddev_event {
unsigned hid;
signed int value;
};
 
containing the HID usage identifier for the status that changed, and
the value that it was changed to. Note that the structure is defined
within <linux/hiddev.h>, along with some other useful #defines and
structures.
 
 
ioctl():
This is the control interface. There are a number of controls:
 
HIDIOCGVERSION - int (read)
Gets the version code out of the hiddev driver.
 
HIDIOCAPPLICATION - (none)
This ioctl call returns the HID application usage associated with the
hid device. The third argument to ioctl() specifies which application
index to get. This is useful when the device has more than one
application collection. If the index is invalid (greater or equal to
the number of application collections this device has) the ioctl
returns -1. You can find out beforehand how many application
collections the device has from the num_applications field from the
hiddev_devinfo structure.
 
HIDIOCGDEVINFO - struct hiddev_devinfo (read)
Gets a hiddev_devinfo structure which describes the device.
 
HIDIOCGSTRING - struct struct hiddev_string_descriptor (read/write)
Gets a string descriptor from the device. The caller must fill in the
"index" field to indicate which descriptor should be returned.
 
HIDIOCINITREPORT - (none)
Instructs the kernel to retrieve all input and feature report values
from the device. At this point, all the usage structures will contain
current values for the device, and will maintain it as the device
changes.
 
HIDIOCGNAME - string (variable length)
Gets the device name
 
HIDIOCGREPORT - struct hiddev_report_info (write)
Instructs the kernel to get a feature or input report from the device,
in order to selectively update the usage structures (in contrast to
INITREPORT).
 
HIDIOCSREPORT - struct hiddev_report_info (write)
Instructs the kernel to send a report to the device. This report can
be filled in by the user through HIDIOCSUSAGE calls (below) to fill in
individual usage values in the report beforesending the report in full
to the device.
 
HIDIOCGREPORTINFO - struct hiddev_report_info (read/write)
Fills in a hiddev_report_info structure for the user. The report is
looked up by type (input, output or feature) and id, so these fields
must be filled in by the user. The ID can be absolute -- the actual
report id as reported by the device -- or relative --
HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT |
report_id) for the next report after report_id. Without a-priori
information about report ids, the right way to use this ioctl is to
use the relative IDs above to enumerate the valid IDs. The ioctl
returns non-zero when there is no more next ID. The real report ID is
filled into the returned hiddev_report_info structure.
 
HIDIOCGFIELDINFO - struct hiddev_field_info (read/write)
Returns the field information associated with a report in a
hiddev_field_info structure. The user must fill in report_id and
report_type in this structure, as above. The field_index should also
be filled in, which should be a number from 0 and maxfield-1, as
returned from a previous HIDIOCGREPORTINFO call.
 
HIDIOCGUCODE - struct hiddev_usage_ref (read/write)
Returns the usage_code in a hiddev_usage_ref structure, given that
given its report type, report id, field index, and index within the
field have already been filled into the structure.
 
HIDIOCGUSAGE - struct hiddev_usage_ref (read/write)
Returns the value of a usage in a hiddev_usage_ref structure. The
usage to be retrieved can be specified as above, or the user can
choose to fill in the report_type field and specify the report_id as
HID_REPORT_ID_UNKNOWN. In this case, the hiddev_usage_ref will be
filled in with the report and field infomation associated with this
usage if it is found.
 
HIDIOCSUSAGE - struct hiddev_usage_ref (write)
Sets the value of a usage in an output report.
 
 
/bluetooth.txt
0,0 → 1,44
INTRODUCTION
 
The USB Bluetooth driver supports any USB Bluetooth device.
It currently works well with the Linux USB Bluetooth stack from Axis
(available at http://developer.axis.com/software/bluetooth/ ) and
has been rumored to work with other Linux USB Bluetooth stacks.
 
 
CONFIGURATION
 
Currently the driver can handle up to 256 different USB Bluetooth
devices at once.
 
If you are not using devfs:
The major number that the driver uses is 216 so to use the driver,
create the following nodes:
mknod /dev/ttyUB0 c 216 0
mknod /dev/ttyUB1 c 216 1
mknod /dev/ttyUB2 c 216 2
mknod /dev/ttyUB3 c 216 3
.
.
.
mknod /dev/ttyUB254 c 216 254
mknod /dev/ttyUB255 c 216 255
 
If you are using devfs:
The devices supported by this driver will show up as
/dev/usb/ttub/{0,1,...}
 
When the device is connected and recognized by the driver, the driver
will print to the system log, which node the device has been bound to.
 
 
CONTACT:
 
If anyone has any problems using this driver, please contact me, or
join the Linux-USB mailing list (information on joining the mailing
list, as well as a link to its searchable archive is at
http://www.linux-usb.org/ )
 
 
Greg Kroah-Hartman
greg@kroah.com
/usb-serial.txt
0,0 → 1,418
INTRODUCTION
 
The USB serial driver currently supports a number of different USB to
serial converter products, as well as some devices that use a serial
interface from userspace to talk to the device.
 
See the individual product section below for specific information about
the different devices.
 
 
CONFIGURATION
 
Currently the driver can handle up to 256 different serial interfaces at
one time.
 
If you are not using devfs:
The major number that the driver uses is 188 so to use the driver,
create the following nodes:
mknod /dev/ttyUSB0 c 188 0
mknod /dev/ttyUSB1 c 188 1
mknod /dev/ttyUSB2 c 188 2
mknod /dev/ttyUSB3 c 188 3
.
.
.
mknod /dev/ttyUSB254 c 188 254
mknod /dev/ttyUSB255 c 188 255
 
If you are using devfs:
The devices supported by this driver will show up as
/dev/usb/tts/{0,1,...}
 
When the device is connected and recognized by the driver, the driver
will print to the system log, which node(s) the device has been bound
to.
 
SPECIFIC DEVICES SUPPORTED
 
 
ConnectTech WhiteHEAT 4 port converter
 
ConnectTech has been very forthcoming with information about their
device, including providing a unit to test with. This driver will end up
being fully supported.
 
Current status:
The device's firmware is downloaded on connection, the new firmware
runs properly and all four ports are successfully recognized and connected.
Data can be sent and received through the device on all ports.
Hardware flow control needs to be implemented.
 
For any questions or problems with this driver, please contact Greg
Kroah-Hartman at greg@kroah.com
 
 
 
 
 
devices.
 
Only when the device tries to connect to the host, will the device show
up to the host as a valid USB device. When this happens, the device is
properly enumerated, assigned a port, and then communication _should_ be
possible. The driver cleans up properly when the device is removed, or
the connection is canceled on the device.
 
NOTE:
This means that in order to talk to the device, the sync button must be
pressed BEFORE trying to get any program to communicate to the device.
This goes against the current documentation for pilot-xfer and other
packages, but is the only way that it will work due to the hardware
in the device.
When the device is connected, try talking to it on the second port
(this is usually /dev/ttyUSB1 if you do not have any other usb-serial
devices in the system.) The system log should tell you which port is
the port to use for the HotSync transfer. The "Generic" port can be used
for other device communication, such as a PPP link.
 
 
device. This is true for all OS version 3.5 devices, and most devices
that have had a flash upgrade to a newer version of the OS. See the
kernel system log for information on which is the correct port to use.
 
If after pressing the sync button, nothing shows up in the system log,
try resetting the device, first a hot reset, and then a cold reset if
necessary. Some devices need this before they can talk to the USB port
properly.
Devices that are not compiled into the kernel can be specified with module
parameters. e.g. modprobe visor vendor=0x54c product=0x66
There is a webpage and mailing lists for this portion of the driver at:
http://usbvisor.sourceforge.net/
 
For any questions or problems with this driver, please contact Greg
Kroah-Hartman at greg@kroah.com
 
 
PocketPC PDA Driver
 
This driver can be used to connect to Compaq iPAQ, HP Jornada, Casio EM500
and other PDAs running Windows CE 3.0 or PocketPC 2002 using a USB
cable/cradle.
Most devices supported by ActiveSync are supported out of the box.
For others, please use module parameters to specify the product and vendor
id. e.g. modprobe ipaq vendor=0x3f0 product=0x1125
 
The driver presents a serial interface (usually on /dev/ttyUSB0) over
which one may run ppp and establish a TCP/IP link to the PDA. Once this
is done, you can transfer files, backup, download email etc. The most
significant advantage of using USB is speed - I can get 73 to 113
kbytes/sec for download/upload to my iPAQ.
 
This driver is only one of a set of components required to utilize
the USB connection. Please visit http://synce.sourceforge.net which
contains the necessary packages and a simple step-by-step howto.
 
Once connected, you can use Win CE programs like ftpView, Pocket Outlook
from the PDA and xcerdisp, synce utilities from the Linux side.
 
To use Pocket IE, follow the instructions given at
http://www.tekguru.co.uk/EM500/usbtonet.htm to achieve the same thing
on Win98. Omit the proxy server part; Linux is quite capable of forwarding
packets unlike Win98. Another modification is required at least for the
iPAQ - disable autosync by going to the Start/Settings/Connections menu
and unchecking the "Automatically synchronize ..." box. Go to
Start/Programs/Connections, connect the cable and select "usbdial" (or
whatever you named your new USB connection). You should finally wind
up with a "Connected to usbdial" window with status shown as connected.
Now start up PIE and browse away.
 
If it doesn't work for some reason, load both the usbserial and ipaq module
with the module parameter "debug" set to 1 and examine the system log.
You can also try soft-resetting your PDA before attempting a connection.
 
Other functionality may be possible depending on your PDA. According to
Wes Cilldhaire <billybobjoehenrybob@hotmail.com>, with the Toshiba E570,
...if you boot into the bootloader (hold down the power when hitting the
reset button, continuing to hold onto the power until the bootloader screen
is displayed), then put it in the cradle with the ipaq driver loaded, open
a terminal on /dev/ttyUSB0, it gives you a "USB Reflash" terminal, which can
be used to flash the ROM, as well as the microP code.. so much for needing
Toshiba's $350 serial cable for flashing!! :D
NOTE: This has NOT been tested. Use at your own risk.
For any questions or problems with the driver, please contact Ganesh
Varadarajan <ganesh@veritas.com>
 
 
Keyspan PDA Serial Adapter
 
Single port DB-9 serial adapter, pushed as a PDA adapter for iMacs (mostly
sold in Macintosh catalogs, comes in a translucent white/green dongle).
Fairly simple device. Firmware is homebrew.
This driver also works for the Xircom/Entrgra single port serial adapter.
 
Current status:
Things that work:
basic input/output (tested with 'cu')
blocking write when serial line can't keep up
changing baud rates (up to 115200)
getting/setting modem control pins (TIOCM{GET,SET,BIS,BIC})
sending break (although duration looks suspect)
Things that don't:
device strings (as logged by kernel) have trailing binary garbage
device ID isn't right, might collide with other Keyspan products
changing baud rates ought to flush tx/rx to avoid mangled half characters
Big Things on the todo list:
parity, 7 vs 8 bits per char, 1 or 2 stop bits
HW flow control
not all of the standard USB descriptors are handled: Get_Status, Set_Feature
O_NONBLOCK, select()
 
For any questions or problems with this driver, please contact Brian
Warner at warner@lothar.com
 
 
Keyspan USA-series Serial Adapters
 
Single, Dual and Quad port adapters - driver uses Keyspan supplied
firmware and is being developed with their support.
Current status:
The USA-18X, USA-28X, USA-19, USA-19W and USA-49W are supported and
have been pretty throughly tested at various baud rates with 8-N-1
character settings. Other character lengths and parity setups are
presently untested.
 
The USA-28 isn't yet supported though doing so should be pretty
straightforward. Contact the maintainer if you require this
functionality.
More information is available at:
http://misc.nu/hugh/keyspan.html
For any questions or problems with this driver, please contact Hugh
Blemings at hugh@misc.nu
 
 
FTDI Single Port Serial Driver
 
This is a single port DB-25 serial adapter. More information about this
device and the Linux driver can be found at:
http://reality.sgi.com/bryder_wellington/ftdi_sio/
 
For any questions or problems with this driver, please contact Bill Ryder
at bryder@sgi.com
 
 
ZyXEL omni.net lcd plus ISDN TA
 
This is an ISDN TA. Please report both successes and troubles to the
author at omninet@kroah.com
 
 
Digi AccelePort Driver
 
This driver supports the Digi AccelePort USB 2 and 4 devices, 2 port
(plus a parallel port) and 4 port USB serial converters. The driver
does NOT yet support the Digi AccelePort USB 8.
 
This driver works under SMP with the usb-uhci driver. It does not
work under SMP with the uhci driver.
 
The driver is generally working, though we still have a few more ioctls
to implement and final testing and debugging to do. The paralled port
on the USB 2 is supported as a serial to parallel converter; in other
words, it appears as another USB serial port on Linux, even though
physically it is really a parallel port. The Digi Acceleport USB 8
is not yet supported.
 
Please contact Peter Berger (pberger@brimson.com) or Al Borchers
(alborchers@steinerpoint.com) for questions or problems with this
driver.
 
 
Belkin USB Serial Adapter F5U103
 
Single port DB-9/PS-2 serial adapter from Belkin with firmware by eTEK Labs.
The Peracom single port serial adapter also works with this driver, as
well as the GoHubs adapter.
 
Current status:
The following have been tested and work:
Baud rate 300-230400
Data bits 5-8
Stop bits 1-2
Parity N,E,O,M,S
Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)*
Break Set and clear
Line contrl Input/Output query and control **
 
* Hardware input flow control is only enabled for firmware
levels above 2.06. Read source code comments describing Belkin
firmware errata. Hardware output flow control is working for all
firmware versions.
** Queries of inputs (CTS,DSR,CD,RI) show the last
reported state. Queries of outputs (DTR,RTS) show the last
requested state and may not reflect current state as set by
automatic hardware flow control.
 
TO DO List:
-- Add true modem contol line query capability. Currently tracks the
states reported by the interrupt and the states requested.
-- Add error reporting back to application for UART error conditions.
-- Add support for flush ioctls.
-- Add everything else that is missing :)
 
For any questions or problems with this driver, please contact William
Greathouse at wgreathouse@smva.com
 
 
Empeg empeg-car Mark I/II Driver
 
This is an experimental driver to provide connectivity support for the
client synchronization tools for an Empeg empeg-car mp3 player.
 
Tips:
* Don't forget to create the device nodes for ttyUSB{0,1,2,...}
* modprobe empeg (modprobe is your friend)
* emptool --usb /dev/ttyUSB0 (or whatever you named your device node)
 
For any questions or problems with this driver, please contact Gary
Brubaker at xavyer@ix.netcom.com
 
 
MCT USB Single Port Serial Adapter U232
 
This driver is for the MCT USB-RS232 Converter (25 pin, Model No.
U232-P25) from Magic Control Technology Corp. (there is also a 9 pin
Model No. U232-P9). More information about this device can be found at
the manufacture's web-site: http://www.mct.com.tw.
 
The driver is generally working, though it still needs some more testing.
It is derived from the Belkin USB Serial Adapter F5U103 driver and its
TODO list is valid for this driver as well.
 
This driver has also been found to work for other products, which have
the same Vendor ID but different Product IDs. Sitecom's U232-P25 serial
converter uses Product ID 0x230 and Vendor ID 0x711 and works with this
driver. Also, D-Link's DU-H3SP USB BAY also works with this driver.
 
For any questions or problems with this driver, please contact Wolfgang
Grandegger at wolfgang@ces.ch
 
 
Inside Out Networks Edgeport Driver
 
This driver supports all devices made by Inside Out Networks, specifically
the following models:
Edgeport/4
Rapidport/4
Edgeport/4t
Edgeport/2
Edgeport/4i
Edgeport/2i
Edgeport/421
Edgeport/21
Edgeport/8
Edgeport/8 Dual
Edgeport/2D8
Edgeport/4D8
Edgeport/8i
Edgeport/2 DIN
Edgeport/4 DIN
Edgeport/16 Dual
 
For any questions or problems with this driver, please contact Greg
Kroah-Hartman at greg@kroah.com
 
 
REINER SCT cyberJack pinpad/e-com USB chipcard reader
Interface to ISO 7816 compatible contactbased chipcards, e.g. GSM SIMs.
Current status:
This is the kernel part of the driver for this USB card reader.
There is also a user part for a CT-API driver available. A site
for downloading is TBA. For now, you can request it from the
maintainer (linux-usb@sii.li).
 
For any questions or problems with this driver, please contact
linux-usb@sii.li
 
 
Prolific PL2303 Driver
 
This driver support any device that has the PL2303 chip from Prolific
in it. This includes a number of single port USB to serial
converters and USB GPS devices. Devices from Aten (the UC-232) and
IO-Data work with this driver.
 
For any questions or problems with this driver, please contact Greg
Kroah-Hartman at greg@kroah.com
 
KL5KUSB105 chipset / PalmConnect USB single-port adapter
Current status:
The driver was put together by looking at the usb bus transactions
done by Palm's driver under Windows, so a lot of functionality is
still missing. Notably, serial ioctls are sometimes faked or not yet
implemented. Support for finding out about DSR and CTS line status is
however implemented (though not nicely), so your favorite autopilot(1)
and pilot-manager -daemon calls will work. Baud rates up to 115200
are supported, but handshaking (software or hardware) is not, which is
why it is wise to cut down on the rate used is wise for large
transfers until this is settled.
Options supported:
If this driver is compiled as a module you can pass the following
options to it:
debug - extra verbose debugging info
(default: 0; nonzero enables)
use_lowlatency - use low_latency flag to speed up tty layer
when reading from from the device.
(default: 0; nonzero enables)
 
See http://www.uuhaus.de/linux/palmconnect.html for up-to-date
information on this driver.
 
 
Generic Serial driver
 
If your device is not one of the above listed devices, compatible with
the above models, you can try out the "generic" interface. This
interface does not provide any type of control messages sent to the
device, and does not support any kind of device flow control. All that
is required of your device is that it has at least one bulk in endpoint,
or one bulk out endpoint.
To enable the generic driver to recognize your device, build the driver
as a module and load it by the following invocation:
insmod usbserial vendor=0x#### product=0x####
where the #### is replaced with the hex representation of your device's
vendor id and product id.
 
This driver has been successfully used to connect to the NetChip USB
development board, providing a way to develop USB firmware without
having to write a custom driver.
 
For any questions or problems with this driver, please contact Greg
Kroah-Hartman at greg@kroah.com
 
 
CONTACT:
 
If anyone has any problems using these drivers, with any of the above
specified products, please contact the specific driver's author listed
above, or join the Linux-USB mailing list (information on joining the
mailing list, as well as a link to its searchable archive is at
http://www.linux-usb.org/ )
 
 
Greg Kroah-Hartman
greg@kroah.com
/ehci.txt
0,0 → 1,212
27-Dec-2002
 
The EHCI driver is used to talk to high speed USB 2.0 devices using
USB 2.0-capable host controller hardware. The USB 2.0 standard is
compatible with the USB 1.1 standard. It defines three transfer speeds:
 
- "High Speed" 480 Mbit/sec (60 MByte/sec)
- "Full Speed" 12 Mbit/sec (1.5 MByte/sec)
- "Low Speed" 1.5 Mbit/sec
 
USB 1.1 only addressed full speed and low speed. High speed devices
can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds.
 
USB 1.1 devices may also be used on USB 2.0 systems. When plugged
into an EHCI controller, they are given to a USB 1.1 "companion"
controller, which is a OHCI or UHCI controller as normally used with
such devices. When USB 1.1 devices plug into USB 2.0 hubs, they
interact with the EHCI controller through a "Transaction Translator"
(TT) in the hub, which turns low or full speed transactions into
high speed "split transactions" that don't waste transfer bandwidth.
 
At this writing, this driver has been seen to work with implementations
of EHCI from (in alphabetical order): Intel, NEC, Philips, and VIA.
Other EHCI implementations are becoming available from other vendors;
you should expect this driver to work with them too.
 
While usb-storage devices have been available since mid-2001 (working
quite speedily on the 2.4 version of this driver), hubs have only
been available since late 2001, and other kinds of high speed devices
appear to be on hold until more systems come with USB 2.0 built-in.
Such new systems have been available since early 2002, and became much
more typical in the second half of 2002.
 
Note that USB 2.0 support involves more than just EHCI. It requires
other changes to the Linux-USB core APIs, including the hub driver,
but those changes haven't needed to really change the basic "usbcore"
APIs exposed to USB device drivers.
 
- David Brownell
<dbrownell@users.sourceforge.net>
 
 
FUNCTIONALITY
 
This driver is regularly tested on x86 hardware, and has also been
used on PPC hardware so big/little endianness issues should be gone.
It's believed to do all the right PCI magic so that I/O works even on
systems with interesting DMA mapping issues.
 
Transfer Types
 
At this writing the driver should comfortably handle all control, bulk,
and interrupt transfers, including requests to USB 1.1 devices through
transaction translators (TTs) in USB 2.0 hubs. But you may find bugs.
 
High Speed Isochronous (ISO) transfer support is also functional, but
at this writing no Linux drivers have been using that support.
 
Full Speed Isochronous transfer support, through transaction translators,
is not yet available. Note that split transaction support for ISO
transfers can't share much code with the code for high speed ISO transfers,
since EHCI represents these with a different data structure. So for now,
most USB audio and video devices can't be connected to high speed buses.
 
Driver Behavior
 
Transfers of all types can be queued. This means that control transfers
from a driver on one interface (or through usbfs) won't interfere with
ones from another driver, and that interrupt transfers can use periods
of one frame without risking data loss due to interrupt processing costs.
 
The EHCI root hub code hands off USB 1.1 devices to its companion
controller. This driver doesn't need to know anything about those
drivers; a OHCI or UHCI driver that works already doesn't need to change
just because the EHCI driver is also present.
 
There are some issues with power management; suspend/resume doesn't
behave quite right at the moment.
 
Also, some shortcuts have been taken with the scheduling periodic
transactions (interrupt and isochronous transfers). These place some
limits on the number of periodic transactions that can be scheduled,
and prevent use of polling intervals of less than one frame.
 
 
USE BY
 
Assuming you have an EHCI controller (on a PCI card or motherboard)
and have compiled this driver as a module, load this like:
 
# modprobe ehci-hcd
 
and remove it by:
 
# rmmod ehci-hcd
 
You should also have a driver for a "companion controller", such as
"ohci-hcd" or "uhci-hcd". In case of any trouble with the EHCI driver,
remove its module and then the driver for that companion controller will
take over (at lower speed) all the devices that were previously handled
by the EHCI driver.
 
Module parameters (pass to "modprobe") include:
 
log2_irq_thresh (default 0):
Log2 of default interrupt delay, in microframes. The default
value is 0, indicating 1 microframe (125 usec). Maximum value
is 6, indicating 2^6 = 64 microframes. This controls how often
the EHCI controller can issue interrupts.
 
If you're using this driver on a 2.5 kernel, and you've enabled USB
debugging support, you'll see three files in the "sysfs" directory for
any EHCI controller:
 
"async" dumps the asynchronous schedule, used for control
and bulk transfers. Shows each active qh and the qtds
pending, usually one qtd per urb. (Look at it with
usb-storage doing disk I/O; watch the request queues!)
"periodic" dumps the periodic schedule, used for interrupt
and isochronous transfers. Doesn't show qtds.
"registers" show controller register state, and
 
The contents of those files can help identify driver problems.
 
 
Device drivers shouldn't care whether they're running over EHCI or not,
but they may want to check for "usb_device->speed == USB_SPEED_HIGH".
High speed devices can do things that full speed (or low speed) ones
can't, such as "high bandwidth" periodic (interrupt or ISO) transfers.
Also, some values in device descriptors (such as polling intervals for
periodic transfers) use different encodings when operating at high speed.
 
However, do make a point of testing device drivers through USB 2.0 hubs.
Those hubs report some failures, such as disconnections, differently when
transaction translators are in use; some drivers have been seen to behave
badly when they see different faults than OHCI or UHCI report.
 
 
PERFORMANCE
 
USB 2.0 throughput is gated by two main factors: how fast the host
controller can process requests, and how fast devices can respond to
them. The 480 Mbit/sec "raw transfer rate" is obeyed by all devices,
but aggregate throughput is also affected by issues like delays between
individual high speed packets, driver intelligence, and of course the
overall system load. Latency is also a performance concern.
 
Bulk transfers are most often used where throughput is an issue. It's
good to keep in mind that bulk transfers are always in 512 byte packets,
and at most 13 of those fit into one USB 2.0 microframe. Eight USB 2.0
microframes fit in a USB 1.1 frame; a microframe is 1 msec/8 = 125 usec.
 
So more than 50 MByte/sec is available for bulk transfers, when both
hardware and device driver software allow it. Periodic transfer modes
(isochronous and interrupt) allow the larger packet sizes which let you
approach the quoted 480 MBit/sec transfer rate.
 
Hardware Performance
 
At this writing, individual USB 2.0 devices tend to max out at around
20 MByte/sec transfer rates. This is of course subject to change;
and some devices now go faster, while others go slower.
 
The first NEC implementation of EHCI seems to have a hardware bottleneck
at around 28 MByte/sec aggregate transfer rate. While this is clearly
enough for a single device at 20 MByte/sec, putting three such devices
onto one bus does not get you 60 MByte/sec. The issue appears to be
that the controller hardware won't do concurrent USB and PCI access,
so that it's only trying six (or maybe seven) USB transactions each
microframe rather than thirteen. (Seems like a reasonable trade off
for a product that beat all the others to market by over a year!)
 
It's expected that newer implementations will better this, throwing
more silicon real estate at the problem so that new motherboard chip
sets will get closer to that 60 MByte/sec target. That includes an
updated implementation from NEC, as well as other vendors' silicon.
 
There's a minimum latency of one microframe (125 usec) for the host
to receive interrupts from the EHCI controller indicating completion
of requests. That latency is tunable; there's a module option. By
default ehci-hcd driver uses the minimum latency, which means that if
you issue a control or bulk request you can often expect to learn that
it completed in less than 250 usec (depending on transfer size).
 
Software Performance
 
To get even 20 MByte/sec transfer rates, Linux-USB device drivers will
need to keep the EHCI queue full. That means issuing large requests,
or using bulk queuing if a series of small requests needs to be issued.
When drivers don't do that, their performance results will show it.
 
In typical situations, a usb_bulk_msg() loop writing out 4 KB chunks is
going to waste more than half the USB 2.0 bandwidth. Delays between the
I/O completion and the driver issuing the next request will take longer
than the I/O. If that same loop used 16 KB chunks, it'd be better; a
sequence of 128 KB chunks would waste a lot less.
 
But rather than depending on such large I/O buffers to make synchronous
I/O be efficient, it's better to just queue up several (bulk) requests
to the HC, and wait for them all to complete (or be canceled on error).
Such URB queuing should work with all the USB 1.1 HC drivers too.
 
In the Linux 2.5 kernels, new usb_sg_*() api calls have been defined; they
queue all the buffers from a scatterlist. They also use scatterlist DMA
mapping (which might apply an IOMMU) and IRQ reduction, all of which will
help make high speed transfers run as fast as they can.
 
 
TBD: Interrupt and ISO transfer performance issues. Those periodic
transfers are fully scheduled, so the main issue is likely to be how
to trigger "high bandwidth" modes.
 
/philips.txt
0,0 → 1,203
This file contains some additional information for the Philips webcams.
E-mail: webcam@smcc.demon.nl Last updated: 2001-09-24
 
The main webpage for the Philips driver is http://www.smcc.demon.nl/webcam/.
It contains a lot of extra information, a FAQ, and the binary plugin
'PWCX'. This plugin contains decompression routines that allow you to
use higher image sizes and framerates; in addition the webcam uses less
bandwidth on the USB bus (handy if you want to run more than 1 camera
simultaneously). These routines fall under an NDA, and may therefor not be
distributed as source; however, its use is completely optional.
 
You can build this code either into your kernel, or as a module. I recommend
the latter, since it makes troubleshooting a lot easier. The built-in
microphone is supported through the USB Audio class.
 
When you load the module you can set some default settings for the
camera; some programs depend on a particular image-size or -format and
don't know how to set it properly in the driver. The options are:
 
size
Can be one of 'sqcif', 'qsif', 'qcif', 'sif', 'cif' or
'vga', for an image size of resp. 128x96, 160x120, 176x144,
320x240, 352x288 and 640x480 (of course, only for those cameras that
support these resolutions).
 
fps
Specifies the desired framerate. Is an integer in the range of 4-30.
 
fbufs
This paramter specifies the number of internal buffers to use for storing
frames from the cam. This will help if the process that reads images from
the cam is a bit slow or momentarely busy. However, on slow machines it
only introduces lag, so choose carefully. The default is 3, which is
reasonable. You can set it between 2 and 5.
 
mbufs
This is an integer between 1 and 4. It will tell the module the number of
buffers to reserve for mmap(), VIDIOCCGMBUF, VIDIOCMCAPTURE and friends.
The default is 2, which is adequate for most applications (double
buffering).
Should you experience a lot of 'Dumping frame...' messages during
grabbing with a tool that uses mmap(), you might want to increase if.
However, it doesn't really buffer images, it just gives you a bit more
slack when your program is behind. But you need a multi-threaded or
forked program to really take advantage of these buffers.
 
The absolute maximum is 4, but don't set it too high! Every buffer takes
up 1.22 MB of RAM, so unless you have a lot of memory setting this to
something more than 2 is an absolute waste. This memory is only
allocated during open(), so nothing is wasted when the camera is not in
use.
 
power_save
When power_save is enabled (set to 1), the module will try to shut down
the cam on close() and re-activate on open(). This will save power and
turn off the LED. Not all cameras support this though (the 645 and 646
don't have power saving at all), and some models don't work either (they
will shut down, but never wake up). Consider this experimental. By
default this option is disabled.
 
compression (only useful with the plugin)
With this option you can control the compression factor that the camera
uses to squeeze the image through the USB bus. You can set the
parameter between 0 and 3:
0 = prefer uncompressed images; if the requested mode is not available
in an uncompressed format, the driver will silently switch to low
compression.
1 = low compression.
2 = medium compression.
3 = high compression.
High compression takes less bandwidth of course, but it could also
introduce some unwanted artefacts. The default is 2, medium compression.
See the FAQ on the website for an overview of which modes require
compression.
The compression parameter only applies to the Vesta & ToUCam cameras.
The 645 and 646 have fixed compression parameters.
 
leds
This settings takes 2 integers, that define the on/off time for the LED
(in milliseconds). One of the interesting things that you can do with
this is let the LED blink while the camera is in use. This:
 
leds=500,500
will blink the LED once every second. But with:
 
leds=0,0
 
the LED never goes on, making it suitable for silent survaillance.
 
By default the camera's LED is on solid while in use, and turned off
when the camera is not used anymore.
 
This parameter works only with the ToUCam range of cameras (730, 740,
750). For other cameras this command is silently ignored, and the LED
cannot be controlled.
 
dev_hint
A long standing problem with USB devices is their dynamic nature: you
never know what device a camera gets assigned; it depends on module load
order, the hub configuration, the order in which devices are plugged in,
and the phase of the moon (i.e. it can be random). With this option you
can give the driver a hint as to what video device node (/dev/videoX) it
should use with a specific camera. This is also handy if you have two
cameras of the same model.
 
A camera is specified by its type (the number from the camera model,
like PCA645, PCVC750VC, etc) and optionally the serial number (visible
in /proc/bus/usb/devices). A hint consists of a string with the following
format:
 
[type[.serialnumber]:]node
The square brackets mean that both the type and the serialnumber are
optional, but a serialnumber cannot be specified without a type (which
would be rather pointless). The serialnumber is separated from the type
by a '.'; the node number by a ':'.
This somewhat cryptic syntax is best explained by a few examples:
 
dev_hint=3,5 The first detected cam gets assigned
/dev/video3, the second /dev/video5. Any
other cameras will get the first free
available slot (see below).
 
dev_hint=645:1,680=2 The PCA645 camera will get /dev/video1,
and a PCVC680 /dev/video2.
dev_hint=645.0123:3,645.4567:0 The PCA645 camera with serialnumber
0123 goes to /dev/video3, the same
camera model with the 4567 serial
gets /dev/video0.
 
dev_hint=750:1,4,5,6 The PCVC750 camera will get /dev/video1, the
next 3 Philips cams will use /dev/video4
through /dev/video6.
 
Some points worth knowing:
- Serialnumbers are case sensitive and must be written full, including
leading zeroes (it's treated as a string).
- If a device node is already occupied, registration will fail and
the webcam is not available.
- You can have up to 64 video devices; be sure to make enough device
nodes in /dev if you want to spread the numbers (this does not apply
to devfs). After /dev/video9 comes /dev/video10 (not /dev/videoA).
- If a camera does not match any dev_hint, it will simply get assigned
the first available device node, just as it used to be.
 
trace
In order to better detect problems, it is now possible to turn on a
'trace' of some of the calls the module makes; it logs all items in your
kernel log at debug level.
 
The trace variable is a bitmask; each bit represents a certain feature.
If you want to trace something, look up the bit value(s) in the table
below, add the values together and supply that to the trace variable.
 
Value Value Description Default
(dec) (hex)
1 0x1 Module initialization; this will log messages On
while loading and unloading the module
 
2 0x2 probe() and disconnect() traces On
 
4 0x4 Trace open() and close() calls Off
 
8 0x8 read(), mmap() and associated ioctl() calls Off
 
16 0x10 Memory allocation of buffers, etc. Off
 
32 0x20 Showing underflow, overflow and Dumping frame On
messages
 
64 0x40 Show viewport and image sizes Off
 
 
For example, to trace the open() & read() fuctions, sum 8 + 4 = 12,
so you would supply trace=12 during insmod or modprobe. If
you want to turn the initialization and probing tracing off, set trace=0.
The default value for trace is 35 (0x23).
 
Example:
# modprobe pwc size=cif fps=15 power_save=1
 
The fbufs, mbufs and trace parameters are global and apply to all connected
cameras. Each camera has its own set of buffers.
 
size, fps, palette only specify defaults when you open() the device; this is
to accommodate some tools that don't set the size or colour palette. You can
change these settings after open() with the Video4Linux ioctl() calls. The
default of defaults is QCIF size at 10 fps, BGR order.
 
The compression parameter is semiglobal; it sets the initial compression
preference for all camera's, but this parameter can be set per camera with
the VIDIOCPWCSCQUAL ioctl() call.
 
All parameters are optional.
 
 
/stv680.txt
0,0 → 1,55
Linux driver for STV0680 based USB cameras
 
Copyright, 2001, Kevin Sisson
 
 
INTRODUCTION:
 
STMicroelectronics produces the STV0680B chip, which comes in two
types, -001 and -003. The -003 version allows the recording and downloading
of sound clips from the camera, and allows a flash attachment. Otherwise,
it uses the same commands as the -001 version. Both versions support a
variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20
CIF pictures. The STV0680 supports either a serial or a usb interface, and
video is possible through the usb interface.
 
The following cameras are known to work with this driver, although any
camera with Vendor/Product codes of 0553/0202 should work:
 
Aiptek Pencam (various models)
Nisis QuickPix 2
Radio Shack 'Kid's digital camera' (#60-1207)
At least one Trust Spycam model
Several other European brand models
 
WHAT YOU NEED:
 
- USB support
- VIDEO4LINUX support
 
More information about USB support for linux can be found at:
http://www.linux-usb.org
 
 
MODULE OPTIONS:
 
When the driver is compiled as a module, you can set a "swapRGB=1"
option, if necessary, for those applications that require it
(such as xawtv). However, the driver should detect and set this
automatically, so this option should not normally be used.
 
 
KNOWN PROBLEMS:
 
The driver seems to work better with the usb-ohci than the usb-uhci host
controller driver.
 
HELP:
 
The latest info on this driver can be found at:
http://personal.clt.bellsouth.net/~kjsisson or at
http://stv0680-usb.sourceforge.net
 
Any questions to me can be send to: kjsisson@bellsouth.net
 
 
/ov511.txt
0,0 → 1,311
-------------------------------------------------------------------------------
Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC
-------------------------------------------------------------------------------
 
Author: Mark McClelland
Homepage: http://alpha.dyndns.org/ov511
 
INTRODUCTION:
 
This is a driver for the OV511, a USB-only chip used in many "webcam" devices.
Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work.
Video capture devices that use the Philips SAA7111A decoder also work. It
supports streaming and capture of color or monochrome video via the Video4Linux
API. Most V4L apps are compatible with it. Most resolutions with a width and
height that are a multiple of 8 are supported.
 
If you need more information, please visit the OV511 homepage at the above URL.
 
WHAT YOU NEED:
 
- If you want to help with the development, get the chip's specification docs at
http://www.ovt.com/omniusbp.html
 
- A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv)
vidcat is part of the w3cam package: http://www.hdk-berlin.de/~rasca/w3cam/
xawtv is available at: http://www.in-berlin.de/User/kraxel/xawtv.html
 
HOW TO USE IT:
 
Note: These are simplified instructions. For complete instructions see:
http://alpha.dyndns.org/ov511/install.html
 
You must have first compiled USB support, support for your specific USB host
controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend
making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled.
 
Next, (as root):
 
modprobe usbcore
modprobe usb-uhci <OR> modprobe usb-ohci
modprobe videodev
modprobe ov511
 
If it is not already there (it usually is), create the video device:
 
mknod /dev/video0 c 81 0
 
Optionally, symlink /dev/video to /dev/video0
 
You will have to set permissions on this device to allow you to read/write
from it:
 
chmod 666 /dev/video
chmod 666 /dev/video0 (if necessary)
Now you are ready to run a video app! Both vidcat and xawtv work well for me
at 640x480.
[Using vidcat:]
 
vidcat -s 640x480 -p c > test.jpg
xview test.jpg
[Using xawtv:]
 
From the main xawtv directory:
 
make clean
./configure
make
make install
 
Now you should be able to run xawtv. Right click for the options dialog.
 
MODULE PARAMETERS:
 
You can set these with: insmod ov511 NAME=VALUE
There is currently no way to set these on a per-camera basis.
 
NAME: autobright
TYPE: integer (Boolean)
DEFAULT: 1
DESC: Brightness is normally under automatic control and can't be set
manually by the video app. Set to 0 for manual control.
 
NAME: autogain
TYPE: integer (Boolean)
DEFAULT: 1
DESC: Auto Gain Control enable. This feature is not yet implemented.
 
NAME: autoexp
TYPE: integer (Boolean)
DEFAULT: 1
DESC: Auto Exposure Control enable. This feature is not yet implemented.
 
NAME: debug
TYPE: integer (0-6)
DEFAULT: 3
DESC: Sets the threshold for printing debug messages. The higher the value,
the more is printed. The levels are cumulative, and are as follows:
0=no debug messages
1=init/detection/unload and other significant messages
2=some warning messages
3=config/control function calls
4=most function calls and data parsing messages
5=highly repetitive mesgs
 
NAME: fix_rgb_offset
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Some people have reported that the blue component of the image is one
or so lines higher than the red component. This is only apparent in
images with white objects on black backgrounds at 640x480. Setting this
to 1 will realign the color planes correctly. NOTE: You will likely
need a fast (500 MHz) CPU.
 
NAME: snapshot
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until
the snapshot button is pressed. Note: enabling this mode disables
/proc/video/ov511/<minor#>/button
 
NAME: force_rgb (Deprecated; may be removed in the future)
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Force image to be read in RGB instead of BGR. This option allow
programs that expect RGB data (e.g. gqcam) to work with this driver. If
your colors look VERY wrong, you may want to change this.
 
NAME: cams
TYPE: integer (1-4 for OV511, 1-31 for OV511+)
DEFAULT: 1
DESC: Number of cameras allowed to stream simultaneously on a single bus.
Values higher than 1 reduce the data rate of each camera, allowing two
or more to be used at once. If you have a complicated setup involving
both OV511 and OV511+ cameras, trial-and-error may be necessary for
finding the optimum setting.
 
NAME: compress
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Set this to 1 to turn on the camera's compression engine. This can
potentially increase the frame rate at the expense of quality, if you
have a fast CPU. You must load the proper compression module for your
camera before starting your application (ov511_decomp or ov518_decomp).
 
NAME: testpat
TYPE: integer (Boolean)
DEFAULT: 0
DESC: This configures the camera's sensor to transmit a colored test-pattern
instead of an image. This does not work correctly yet.
 
NAME: dumppix
TYPE: integer (0-2)
DEFAULT: 0
DESC: Dumps raw pixel data and skips post-processing and format conversion.
It is for debugging purposes only. Options are:
0: Disable (default)
1: Dump raw data from camera, excluding headers and trailers
2: Dumps data exactly as received from camera
 
NAME: led
TYPE: integer (0-2)
DEFAULT: 1 (Always on)
DESC: Controls whether the LED (the little light) on the front of the camera
is always off (0), always on (1), or only on when driver is open (2).
This is not supported with the OV511, and might only work with certain
cameras (ones that actually have the LED wired to the control pin, and
not just hard-wired to be on all the time).
 
NAME: dump_bridge
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system
log. Only useful for serious debugging/development purposes.
 
NAME: dump_sensor
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Dumps the sensor register values to the system log. Only useful for
serious debugging/development purposes.
 
NAME: printph
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This
is only useful if you are trying to debug problems with the isoc data
stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be
warned that this dumps a large number of messages to your kernel log.
 
NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv
TYPE: integer (0-63 for phy and phuv, 0-255 for rest)
DEFAULT: OV511 default values
DESC: These are registers 70h - 77h of the OV511, which control the
prediction ranges and quantization thresholds of the compressor, for
the Y and UV channels in the horizontal and vertical directions. See
the OV511 or OV511+ data sheet for more detailed descriptions. These
normally do not need to be changed.
 
NAME: lightfreq
TYPE: integer (0, 50, or 60)
DEFAULT: 0 (use sensor default)
DESC: Sets the sensor to match your lighting frequency. This can reduce the
appearance of "banding", i.e. horizontal lines or waves of light and
dark that are often caused by artificial lighting. Valid values are:
0 - Use default (depends on sensor, most likely 60 Hz)
50 - For European and Asian 50 Hz power
60 - For American 60 Hz power
 
NAME: bandingfilter
TYPE: integer (Boolean)
DEFAULT: 0 (off)
 
or stabilizes the "banding" caused by some artificial light sources
(especially fluorescent). You might have to set lightfreq correctly for
this to work right. As an added bonus, this sometimes makes it
 
 
NAME: fastset
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Allows picture settings (brightness, contrast, color, and hue) to take
effect immediately, even in the middle of a frame. This reduces the
time to change settings, but can ruin frames during the change. Only
affects OmniVision sensors.
 
NAME: force_palette
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Forces the palette (color format) to a specific value. If an
application requests a different palette, it will be rejected, thereby
forcing it to try others until it succeeds. This is useful for forcing
greyscale mode with a color camera, for example. Supported modes are:
0 (Allows all the following formats)
1 VIDEO_PALETTE_GREY (Linear greyscale)
3 VIDEO_PALETTE_RGB565 (565 16 bit RGB)
4 VIDEO_PALETTE_RGB24 (24bit RGB)
7 VIDEO_PALETTE_YUV422 (YUV422 capture)
8 VIDEO_PALETTE_YUYV (YUV422 capture; same as 7)
10 VIDEO_PALETTE_YUV420 (YUV 4:2:0 Planar)
13 VIDEO_PALETTE_YUV422P (YUV 4:2:2 Planar)
15 VIDEO_PALETTE_YUV420P (YUV 4:2:0 Planar, same as 10)
 
NAME: backlight
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Setting this flag changes the exposure algorithm for OmniVision sensors
such that objects in the camera's view (i.e. your head) can be clearly
seen when they are illuminated from behind. It reduces or eliminates
the sensor's auto-exposure function, so it should only be used when
needed. Additionally, it is only supported with the OV6620 and OV7620.
 
NAME: unit_video
TYPE: Up to 16 comma-separated integers
DEFAULT: 0,0,0... (automatically assign the next available minor(s))
DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices.
For example, "unit_video=1,3" will make the driver use /dev/video1 and
/dev/video3 for the first two devices it detects. Additional devices
will be assigned automatically starting at the first available device
node (/dev/video0 in this case). Note that you cannot specify 0 as a
minor number. This feature requires kernel version 2.4.5 or higher.
 
NAME: remove_zeros
TYPE: integer (Boolean)
DEFAULT: 0 (do not skip any incoming data)
DESC: Setting this to 1 will remove zero-padding from incoming data. This
will compensate for the blocks of corruption that can appear when the
camera cannot keep up with the speed of the USB bus (eg. at low frame
resolutions). This feature is always enabled when compression is on.
 
NAME: mirror
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This
might be necessary if your camera has a custom lens assembly. This has
no effect with video capture devices.
 
NAME: ov518_color
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Enable OV518 color support. This is off by default since it doesn't
work most of the time. If you want to try it, you must also load
ov518_decomp with the "nouv=0" parameter. If you get improper colors or
diagonal lines through the image, restart your video app and try again.
Repeat as necessary.
 
WORKING FEATURES:
o Color streaming/capture at most widths and heights that are multiples of 8.
o RGB24, RGB565, YUV420/YUV420P, YUV422/YUYV, and YUV422P color
o Monochrome (use force_palette=1 to enable)
o Setting/getting of saturation, contrast, brightness, and hue (only some of
them work the OV7620 and OV7620AE)
o /proc status reporting
o SAA7111A video capture support at 320x240 and 640x480
o Compression support
o SMP compatibility
 
HOW TO CONTACT ME:
 
You can email me at mark@alpha.dyndns.org . Please prefix the subject line
with "OV511: " so that I am certain to notice your message.
 
CREDITS:
 
The code is based in no small part on the CPiA driver by Johannes Erdfelt,
Randy Dunlap, and others. Big thanks to them for their pioneering work on that
and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and
image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio
Matsuoka for their work as well.
 
/w9968cf.txt
0,0 → 1,472
 
W996[87]CF JPEG USB Dual Mode Camera Chip
Linux 2.4 driver (basic version)
=========================================
 
- Documentation -
 
 
Index
=====
1. Copyright
2. License
3. Overview
4. Supported devices
5. Module dependencies
6. Module loading
7. Module paramaters
8. Credits
 
 
1. Copyright
============
Copyright (C) 2002 2003 by Luca Risolia <luca.risolia@studio.unibo.it>
 
 
2. License
==========
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., 675 Mass Ave, Cambridge, MA 02139, USA.
 
 
3. Overview
===========
This driver supports the video streaming capabilities of the devices mounting
Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips, when they
are being commanded by USB.
 
The full-featured driver is divided into two modules: the basic one, "w9968cf",
is needed for the supported devices to work; the second one, "w9968cf-vpp",
is an optional module, which provides some useful video post-processing
functions like video decoding, up-scaling and colour conversions. Once the
driver is installed, every time an application tries to open a recognized
device, "w9968cf" checks the presence of the "w9968cf-vpp" module and loads it
automatically by default.
 
Please keep in mind that official kernels do NOT include the second module for
performance purposes. However it is always recommended to download and install
the latest and complete release of the driver, replacing the existing one, if
present: it will be still even possible not to load the "w9968cf-vpp" module at
all, if you ever want to. Another important missing feature of the version in
the official Linux 2.4 kernels is the writeable /proc filesystem interface.
 
The latest and full-featured version of the W996[87]CF driver can be found at:
http://go.lamarinapunto.com/
 
Up to 32 cameras can be handled at the same time. They can be connected and
disconnected from the host many times without turning off the computer, if
your system supports the hotplug facility.
 
To change the default settings for each camera, many paramaters can be passed
through command line when the module is loaded into memory.
 
The driver relies on the Video4Linux, USB and I2C core modules of the official
Linux kernels, version 2.4.19 or greater, and is not compatible in any way with
previous versions. It has been designed to run properly on SMP systems as well.
At the moment, an additional module, "ovcamchip", is mandatory; it provides
support for some OmniVision CMOS sensors connected to the W996[87]CF chips.
 
The "ovcamchip" module is part of the OV511 driver, version 2.27, which can be
downloaded from internet:
http://alpha.dyndns.org/ov511/
To know how to compile it, read the documentation included in the OV511
package.
 
 
4. Supported devices
====================
At the moment, known W996[87]CF based devices are:
- Aroma Digi Pen ADG-5000 Refurbished
- AVerTV USB
- Creative Labs Video Blaster WebCam Go
- Creative Labs Video Blaster WebCam Go Plus
- Die Lebon LDC-D35A Digital Kamera
- Ezonics EZ-802 EZMega Cam
- OPCOM Digi Pen VGA Dual Mode Pen Camera
 
If you know any other W996[87]CF based cameras, please contact me.
 
The list above does NOT imply that all those devices work with this driver: up
until now only webcams that have a CMOS sensor supported by the "ovcamchip"
module work.
For a list of supported CMOS sensors, please visit the the author's homepage on
this module: http://alpha.dyndns.org/ov511/
 
Possible external microcontrollers of those webcams are not supported: this
means that still images cannot be downloaded from the device memory.
 
Furthermore, it's worth to note that I was only able to run tests on my
"Creative Labs Video Blaster WebCam Go". Donations of other models, for
additional testing and full support, would be much appreciated.
 
 
5. Module dependencies
======================
The driver needs kernel support for Video4Linux, USB and I2C, and a third-party
module for the CMOS sensor.
 
The following options of the kernel configuration file must be enabled and
corresponding modules must be compiled:
 
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
 
# I2C support
#
CONFIG_I2C=m
 
The I2C core module can be compiled statically in the kernel as well.
 
# USB support
#
CONFIG_USB=m
 
In addition, depending on the hardware being used, only one of the modules
below is necessary:
 
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI=m
CONFIG_USB_UHCI_ALT=m
CONFIG_USB_OHCI=m
 
And finally:
 
# USB Multimedia devices
#
CONFIG_USB_W9968CF=m
 
Also, make sure "Enforce bandwidth allocation" is NOT enabled.
 
The /proc filesystem can be optionally built into the kernel:
 
# File systems
#
CONFIG_PROC_FS=y
 
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y
 
The last module we need is "ovcamchip.o". To obtain it, you have to download
the OV511, version 2.27 - don't use other versions - and compile it according
to its documentation.
The package is available at http://alpha.dyndns.org/ov511/ .
 
 
6. Module loading
=================
To use the driver, it is necessary to load the "w9968cf" module into memory
after every other module required: for the 2.4 series of the kernel, they are
named, in order: "videodev", "usbcore", then "ehci-hcd", "usb-uhci", "uhci",
"usb-ohci" (just one), and also "i2c-core" and "ovcamchip".
 
Loading can be done this way, from root:
 
[root@localhost home]# modprobe i2c-core
[root@localhost ov511-x.xx]# insmod ./ovcamchip.o
[root@localhost home]# modprobe w9968cf
 
At this point the devices should be recognized. There are two ways of verifying
that the loading process has gone well: the first is to analyze kernel
messages:
 
[user@localhost home]$ dmesg
 
A second way is to retrieve informations from the entries that have just been
created in the /proc/video/w9968cf/ directory; this feature works if and only
if the kernel has been built with the /proc filesystem support.
As an example, the following command will print the list of registered cameras:
 
[user@localhost home]$ cat /proc/video/w9968cf/global
 
There are a lot of parameters the module can use to change the default
settings for each device. To list every possible parameter with a brief
explanation about them and which syntax to use, it is recommended to run the
"modinfo" command:
 
[root@locahost home]# modinfo w9968cf
 
 
7. Module paramaters
====================
Module paramaters are listed below:
-------------------------------------------------------------------------------
Name: vppmod_load
Type: bool
Syntax: <0|1>
Description: Automatic 'w9968cf-vpp' module loading: 0 disabled, 1 enabled.
If enabled, every time an application attempts to open a
camera, 'insmod' searches for the video post-processing module
in the system and loads it automatically (if present).
The 'w9968cf-vpp' module adds extra image manipulation
capabilities to the 'w9968cf' module,like software up-scaling,
colour conversions and video decoding.
Default: 1
-------------------------------------------------------------------------------
Name: simcams
Type: int
Syntax: <n>
Description: Number of cameras allowed to stream simultaneously.
n may vary from 0 to 32.
Default: 32
-------------------------------------------------------------------------------
Name: video_nr
Type: int array (min = 0, max = 32)
Syntax: <-1|n[,...]>
Description: Specify V4L minor mode number.
-1 = use next available
n = use minor number n
You can specify 32 cameras this way.
For example:
video_nr=-1,2,-1 would assign minor number 2 to the second
recognized camera and use auto for the first one and for every
other camera.
Default: -1
-------------------------------------------------------------------------------
Name: packet_size
Type: int array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Specify the maximum data payload size in bytes for alternate
settings, for each device. n is scaled between 63 and 1023.
Default: 1023
-------------------------------------------------------------------------------
Name: max_buffers
Type: int array (min = 0, max = 32)
Syntax: <n[,...]>
Description: For advanced users.
Specify the maximum number of video frame buffers to allocate
for each device, from 2 to 32.
Default: 2
-------------------------------------------------------------------------------
Name: double_buffer
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Hardware double buffering: 0 disabled, 1 enabled.
It should be enabled if you want smooth video output: if you
obtain out of sync. video, disable it, or try to
decrease the 'clockdiv' module paramater value.
Default: 1 for every device.
-------------------------------------------------------------------------------
Name: clamping
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Video data clamping: 0 disabled, 1 enabled.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: filter_type
Type: int array (min = 0, max = 32)
Syntax: <0|1|2[,...]>
Description: Video filter type.
0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter.
The filter is used to reduce noise and aliasing artifacts
produced by the CCD or CMOS sensor.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: largeview
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Large view: 0 disabled, 1 enabled.
Default: 1 for every device.
-------------------------------------------------------------------------------
Name: upscaling
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Software scaling (for non-compressed video only):
0 disabled, 1 enabled.
Disable it if you have a slow CPU or you don't have enough
memory.
Default: 0 for every device.
Note: If 'w9968cf-vpp' is not loaded, this paramater is set to 0.
-------------------------------------------------------------------------------
Name: decompression
Type: int array (min = 0, max = 32)
Syntax: <0|1|2[,...]>
Description: Software video decompression:
0 = disables decompression
(doesn't allow formats needing decompression).
1 = forces decompression
(allows formats needing decompression only).
2 = allows any permitted formats.
Formats supporting (de)compressed video are YUV422P and
YUV420P/YUV420 in any resolutions where width and height are
multiples of 16.
Default: 2 for every device.
Note: If 'w9968cf-vpp' is not loaded, forcing decompression is not
allowed; in this case this paramater is set to 2.
-------------------------------------------------------------------------------
Name: force_palette
Type: int array (min = 0, max = 32)
Syntax: <0|9|10|13|15|8|7|1|6|3|4|5[,...]>
Description: Force picture palette.
In order:
0 = Off - allows any of the following formats:
9 = UYVY 16 bpp - Original video, compression disabled
10 = YUV420 12 bpp - Original video, compression enabled
13 = YUV422P 16 bpp - Original video, compression enabled
15 = YUV420P 12 bpp - Original video, compression enabled
8 = YUVY 16 bpp - Software conversion from UYVY
7 = YUV422 16 bpp - Software conversion from UYVY
1 = GREY 8 bpp - Software conversion from UYVY
6 = RGB555 16 bpp - Software conversion from UYVY
3 = RGB565 16 bpp - Software conversion from UYVY
4 = RGB24 24 bpp - Software conversion from UYVY
5 = RGB32 32 bpp - Software conversion from UYVY
When not 0, this paramater will override 'decompression'.
Default: 0 for every device. Initial palette is 9 (UYVY).
Note: If 'w9968cf-vpp' is not loaded, this paramater is set to 9.
-------------------------------------------------------------------------------
Name: force_rgb
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Read RGB video data instead of BGR:
1 = use RGB component ordering.
0 = use BGR component ordering.
This parameter has effect when using RGBX palettes only.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: autobright
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: CMOS sensor automatically changes brightness:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: autoexp
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: CMOS sensor automatically changes exposure:
0 = no, 1 = yes
Default: 1 for every device.
-------------------------------------------------------------------------------
Name: lightfreq
Type: int array (min = 0, max = 32)
Syntax: <50|60[,...]>
Description: Light frequency in Hz:
50 for European and Asian lighting, 60 for American lighting.
Default: 50 for every device.
-------------------------------------------------------------------------------
Name: bandingfilter
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Banding filter to reduce effects of fluorescent
lighting:
0 disabled, 1 enabled.
This filter tries to reduce the pattern of horizontal
light/dark bands caused by some (usually fluorescent) lighting.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: clockdiv
Type: int array (min = 0, max = 32)
Syntax: <-1|n[,...]>
Description: Force pixel clock divisor to a specific value (for experts):
n may vary from 0 to 127.
-1 for automatic value.
See also the 'double_buffer' module paramater.
Default: -1 for every device.
-------------------------------------------------------------------------------
Name: backlight
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Objects are lit from behind:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: mirror
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Reverse image horizontally:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: monochrome
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: The CMOS sensor is monochrome:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: brightness
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture brightness (0-65535).
This parameter has no effect if 'autobright' is enabled.
Default: 31000 for every device.
-------------------------------------------------------------------------------
Name: hue
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture hue (0-65535).
Default: 32768 for every device.
-------------------------------------------------------------------------------
Name: colour
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture saturation (0-65535).
Default: 32768 for every device.
-------------------------------------------------------------------------------
Name: contrast
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture contrast (0-65535).
Default: 50000 for every device.
-------------------------------------------------------------------------------
Name: whiteness
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture whiteness (0-65535).
Default: 32768 for every device.
-------------------------------------------------------------------------------
Name: debug
Type: int
Syntax: <n>
Description: Debugging information level, from 0 to 6:
0 = none (use carefully)
1 = critical errors
2 = significant informations
3 = configuration or general messages
4 = warnings
5 = called functions
6 = function internals
Level 5 and 6 are useful for testing only, when just one
device is used.
Default: 2
-------------------------------------------------------------------------------
Name: specific_debug
Type: bool
Syntax: <0|1>
Description: Enable or disable specific debugging messages:
0 = print messages concerning every level <= 'debug' level.
1 = print messages concerning the level indicated by 'debug'.
Default: 0
-------------------------------------------------------------------------------
 
 
8. Credits
==========
The development would not have proceed much further without having looked at
the source code of other drivers and without the help of several persons; in
particular:
 
- the I2C interface to kernel and high-level CMOS sensor control routines have
been taken from the OV511 driver by Mark McClelland;
 
- memory management code has been copied from the bttv driver by Ralph Metzler,
Marcus Metzler and Gerd Knorr;
 
- the low-level I2C read function has been written by Frederic Jouault;
 
- the low-level I2C fast write function has been written by Piotr Czerczak.
/usb-help.txt
0,0 → 1,19
usb-help.txt
2000-July-12
 
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/
and http://it.linux-usb.org
Linux USB Guide: http://linux-usb.sourceforge.net
Linux-USB device overview (working devices and drivers):
http://www.qbik.ch/usb/devices/
The Linux-USB mailing lists are:
linux-usb-users@lists.sourceforge.net for general user help
linux-usb-devel@lists.sourceforge.net for developer discussions
 
###
/CREDITS
0,0 → 1,175
Credits for the Simple Linux USB Driver:
 
The following people have contributed to this code (in alphabetical
order by last name). I'm sure this list should be longer, its
difficult to maintain, add yourself with a patch if desired.
 
Georg Acher <acher@informatik.tu-muenchen.de>
David Brownell <dbrownell@users.sourceforge.net>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Randy Dunlap <randy.dunlap@intel.com>
Johannes Erdfelt <johannes@erdfelt.com>
Deti Fliegl <deti@fliegl.de>
ham <ham@unsuave.com>
Bradley M Keryan <keryan@andrew.cmu.edu>
Greg Kroah-Hartman <greg@kroah.com>
Pavel Machek <pavel@suse.cz>
Paul Mackerras <paulus@cs.anu.edu.au>
Petko Manlolov <petkan@dce.bg>
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>
Roman Weissgaerber <weissg@vienna.at>
<Kazuki.Yasumatsu@fujixerox.co.jp>
 
Special thanks to:
 
Inaky Perez Gonzalez <inaky@peloncho.fis.ucm.es> for starting the
Linux USB driver effort and writing much of the larger uusbd driver.
Much has been learned from that effort.
 
The NetBSD & FreeBSD USB developers. For being on the Linux USB list
and offering suggestions and sharing implementation experiences.
 
Additional thanks to the following companies and people for donations
of hardware, support, time and development (this is from the original
THANKS file in Inaky's driver):
 
The following corporations have helped us in the development
of Linux USB / UUSBD:
 
- 3Com GmbH for donating a ISDN Pro TA and supporting me
in technical questions and with test equipment. I'd never
expect such a great help.
 
- USAR Systems provided us with one of their excellent USB
Evaluation Kits. It allows us to test the Linux-USB driver
for compliance with the latest USB specification. USAR
Systems recognized the importance of an up-to-date open
Operating System and supports this project with
Hardware. Thanks!.
 
- Thanks to Intel Corporation for their precious help.
 
- We teamed up with Cherry to make Linux the first OS with
built-in USB support. Cherry is one of the biggest keyboard
makers in the world.
 
- CMD Technology, Inc. sponsored us kindly donating a CSA-6700
PCI-to-USB Controller Board to test the OHCI implementation.
 
- Due to their support to us, Keytronic can be sure that they
will sell keyboards to some of the 3 million (at least)
Linux users.
 
 
It was almost impossible to get a PC backplate USB connector
for the motherboard here at Europe (mine, home-made, was
quite lousy :). Now I know where to acquire nice USB stuff!
 
- Genius Germany donated a USB mouse to test the mouse boot
protocol. They've also donated a F-23 digital joystick and a
NetMouse Pro. Thanks!
 
- AVM GmbH Berlin is supporting the development of the Linux
USB driver for the AVM ISDN Controller B1 USB. AVM is a
leading manufacturer for active and passive ISDN Controllers
and CAPI 2.0-based software. The active design of the AVM B1
is open for all OS platforms, including Linux.
 
- Thanks to Y-E Data, Inc. for donating their FlashBuster-U
USB Floppy Disk Drive, so we could test the bulk transfer
code.
 
- Many thanks to Logitech for contributing a three axis USB
mouse.
 
Logitech designs, manufactures and markets
Human Interface Devices, having a long history and
experience in making devices such as keyboards, mice,
trackballs, cameras, loudspeakers and control devices for
gaming and professional use.
 
Being a recognized vendor and seller for all these devices,
they have donated USB mice, a joystick and a scanner, as a
way to acknowledge the importance of Linux and to allow
Logitech customers to enjoy support in their favorite
operating systems and all Linux users to use Logitech and
other USB hardware.
 
Logitech is official sponsor of the Linux Conference on
Feb. 11th 1999 in Vienna, where we'll will present the
current state of the Linux USB effort.
 
- CATC has provided means to uncover dark corners of the UHCI
inner workings with a USB Inspector.
 
- Thanks to Entrega for providing PCI to USB cards, hubs and
converter products for development.
 
- Thanks to ConnectTech for providing a WhiteHEAT usb to
serial converter, and the documentation for the device to
allow a driver to be written.
 
- Thanks to ADMtek for providing Pegasus and Pegasus II
evaluation boards, specs and valuable advices during
the driver development.
And thanks go to (hey! in no particular order :)
 
- Oren Tirosh <orenti@hishome.net>, for standing so patiently
all my doubts'bout USB and giving lots of cool ideas.
 
- Jochen Karrer <karrer@wpfd25.physik.uni-wuerzburg.de>, for
pointing out mortal bugs and giving advice.
 
- Edmund Humemberger <ed@atnet.at>, for it's great work on
public relationships and general management stuff for the
Linux-USB effort.
 
- Alberto Menegazzi <flash@flash.iol.it> is starting the
documentation for the UUSBD. Go for it!
 
- Ric Klaren <ia_ric@cs.utwente.nl> for doing nice
introductory documents (competing with Alberto's :).
 
- Christian Groessler <cpg@aladdin.de>, for it's help on those
itchy bits ... :)
 
- Paul MacKerras for polishing OHCI and pushing me harder for
the iMac support, giving improvements and enhancements.
 
- Fernando Herrera <fherrera@eurielec.etsit.upm.es> has taken
charge of composing, maintaining and feeding the
long-awaited, unique and marvelous UUSBD FAQ! Tadaaaa!!!
 
- Rasca Gmelch <thron@gmx.de> has revived the raw driver and
pointed bugs, as well as started the uusbd-utils package.
 
- Peter Dettori <dettori@ozy.dec.com> is uncovering bugs like
crazy, as well as making cool suggestions, great :)
 
- All the Free Software and Linux community, the FSF & the GNU
project, the MIT X consortium, the TeX people ... everyone!
You know who you are!
 
- Big thanks to Richard Stallman for creating Emacs!
 
- The people at the linux-usb mailing list, for reading so
many messages :) Ok, no more kidding; for all your advises!
 
- All the people at the USB Implementors Forum for their
help and assistance.
 
- Nathan Myers <ncm@cantrip.org>, for his advice! (hope you
liked Cibeles' party).
 
- Linus Torvalds, for starting, developing and managing Linux.
 
- Mike Smith, Craig Keithley, Thierry Giron and Janet Schank
for convincing me USB Standard hubs are not that standard
and that's good to allow for vendor specific quirks on the
standard hub driver.
/hotplug.txt
0,0 → 1,148
LINUX HOTPLUGGING
 
In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
into the bus with power on. In most cases, users expect the devices to become
immediately usable. That means the system must do many things, including:
 
- Find a driver that can handle the device. That may involve
loading a kernel module; newer drivers can use modutils to
publish their device (and class) support to user utilities.
 
- Bind a driver to that device. Bus frameworks do that using a
device driver's probe() routine.
- Tell other subsystems to configure the new device. Print
queues may need to be enabled, networks brought up, disk
partitions mounted, and so on. In some cases these will
be driver-specific actions.
 
This involves a mix of kernel mode and user mode actions. Making devices
be immediately usable means that any user mode actions can't wait for an
administrator to do them: the kernel must trigger them, either passively
(triggering some monitoring daemon to invoke a helper program) or
actively (calling such a user mode helper program directly).
 
Those triggered actions must support a system's administrative policies;
such programs are called "policy agents" here. Typically they involve
shell scripts that dispatch to more familiar administration tools.
 
Because some of those actions rely on information about drivers (metadata)
that is currently available only when the drivers are dynamically linked,
you get the best hotplugging when you configure a highly modular system.
 
 
KERNEL HOTPLUG HELPER (/sbin/hotplug)
 
When you compile with CONFIG_HOTPLUG, you get a new kernel parameter:
/proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug".
That parameter names a program which the kernel may invoke at various times.
 
The /sbin/hotplug program can be invoked by any subsystem as part of its
reaction to a configuration change, from a thread in that subsystem.
Only one parameter is required: the name of a subsystem being notified of
some kernel event. That name is used as the first key for further event
dispatch; any other argument and environment parameters are specified by
the subsystem making that invocation.
 
Hotplug software and other resources is available at:
 
http://linux-hotplug.sourceforge.net
 
Mailing list information is also available at that site.
 
 
--------------------------------------------------------------------------
 
 
USB POLICY AGENT
 
The USB subsystem currently invokes /sbin/hotplug when USB devices
are added or removed from system. The invocation is done by the kernel
hub daemon thread [khubd], or else as part of root hub initialization
(done by init, modprobe, kapmd, etc). Its single command line parameter
is the string "usb", and it passes these environment variables:
 
ACTION ... "add", "remove"
PRODUCT ... USB vendor, product, and version codes (hex)
TYPE ... device class codes (decimal)
INTERFACE ... interface 0 class codes (decimal)
 
If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is
the pathname of the device, and is useful for devices with multiple and/or
alternate interfaces that complicate driver selection. By design, USB
hotplugging is independent of "usbdevfs": you can do most essential parts
of USB device setup without using that filesystem, and without running a
user mode daemon to detect changes in system configuration.
 
Currently available policy agent implementations can load drivers for
modules, and can invoke driver-specific setup scripts. The newest ones
leverage USB modutils support. Later agents might unload drivers.
 
 
USB MODUTILS SUPPORT
 
Current versions of modutils will create a "modules.usbmap" file which
contains the entries from each driver's MODULE_DEVICE_TABLE. Such files
can be used by various user mode policy agents to make sure all the right
driver modules get loaded, either at boot time or later.
 
See <linux/usb.h> for full information about such table entries; or look
at existing drivers. Each table entry describes one or more criteria to
be used when matching a driver to a device or class of devices. The
specific criteria are identified by bits set in "match_flags", paired
with field values. You can construct the criteria directly, or with
macros such as these, and use driver_info to store more information.
 
USB_DEVICE (vendorId, productId)
... matching devices with specified vendor and product ids
USB_DEVICE_VER (vendorId, productId, lo, hi)
... like USB_DEVICE with lo <= productversion <= hi
USB_INTERFACE_INFO (class, subclass, protocol)
... matching specified interface class info
USB_DEVICE_INFO (class, subclass, protocol)
... matching specified device class info
 
A short example, for a driver that supports several specific USB devices
and their quirks, might have a MODULE_DEVICE_TABLE like this:
 
static const struct usb_device_id mydriver_id_table = {
{ USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X },
{ USB_DEVICE (0xbbbb, 0x8888), driver_info: QUIRK_Y|QUIRK_Z },
...
{ } /* end with an all-zeroes entry */
}
MODULE_DEVICE_TABLE (usb, mydriver_id_table);
 
Most USB device drivers should pass these tables to the USB subsystem as
well as to the module management subsystem. Not all, though: some driver
frameworks connect using interfaces layered over USB, and so they won't
need such a "struct usb_driver".
 
Drivers that connect directly to the USB subsystem should be declared
something like this:
 
static struct usb_driver mydriver = {
name: "mydriver",
id_table: mydriver_id_table,
probe: my_probe,
disconnect: my_disconnect,
 
/*
if using the usb chardev framework:
minor: MY_USB_MINOR_START,
fops: my_file_ops,
if exposing any operations through usbdevfs:
ioctl: my_ioctl,
*/
}
 
When the USB subsystem knows about a driver's device ID table, it's used when
choosing drivers to probe(). The thread doing new device processing checks
drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and
device descriptors for the device. It will only call probe() if there is a
match, and the third argument to probe() will be the entry that matched.
 
If you don't provide an id_table for your driver, then your driver may get
probed for each new device; the third parameter to probe() will be null.
 
 
/ohci.txt
0,0 → 1,98
 
The OHCI HCD layer is a simple but nearly complete implementation of what the
USB people would call a HCD for the OHCI.
(ISO coming soon, Bulk, INT u. CTRL transfers enabled)
It is based on Linus Torvalds UHCI code and Gregory Smith OHCI fragments (0.03 source tree).
The layer (functions) on top of it, is for interfacing to the alternate-usb device-drivers.
 
- Roman Weissgaerber <weissg@vienna.at>
 
* v4.0 1999/08/18 removed all dummy eds, unlink unused eds, code cleanup, bulk transfers
* v2.1 1999/05/09 ep_addr correction, code cleanup
* v0.2.0 1999/05/04
* everything has been moved into 2 files (ohci-hcd.c, ohci-hub-root.c and headers)
* virtual root hub is now an option,
* memory allocation based on kmalloc and kfree now, simple Bus error handling,
* INT and CTRL transfers enabled, Bulk included but disabled, ISO needs completion
*
* from Linus Torvalds (uhci.c): APM (not tested); hub, usb_device, bus and related stuff
* from Greg Smith (ohci.c): better reset ohci-controller handling, hub
*
* v0.1.0 1999/04/27 initial release
to remove the module try:
rmmod usb-ohci
 
Features:
- virtual root hub, all basic hub descriptors and commands (state: complete)
this is an option now (v0.2.0)
#define CONFIG_USB_OHCI_VROOTHUB includes the virtual hub code, (VROOTHUB)
default is with.
(at the moment: the Virtual Root Hub is included automatically)
files: ohci-root-hub.c, ohci-root-hub.h
 
- Endpoint Descriptor (ED) handling more static approach
(EDs should be allocated in parallel to the SET CONFIGURATION command and they live
as long as the function (device) is alive or another configuration is chosen.
In the HCD layer the EDs has to be allocated manually either by calling a subroutine
or by sending a USB root hub vendor specific command to the virtual root hub.
At the alternate linux usb stack EDs will be added (allocated) at their first use.
ED will be unlinked from the HC chains if they are not busy.
files: ohci-hcd.c ohci-hcd.h
routines: (do not use for drivers, use the top layer alternate usb commands instead)
int usb_ohci_add_ep(struct ohci * ohci, unsigned int ep_addr1,
int interval, int load, f_handler handler, int ep_size, int speed)
adds an endpoint, (if the endpoint already exists some parameters will be updated)
int usb_ohci_rm_ep( )
removes an endpoint and all pending TDs of that EP
usb_ohci_rm_function( )
removes all Endpoints of a function (device)
 
- Transfer Descriptors (TD): handling and allocation of TDs is transparent to the upper layers
The HCD takes care of TDs and EDs memory allocation whereas the upper layers (UBSD ...) has
to take care of buffer allocation.
files: ohci-hcd.c ohci-hcd.h
 
There is one basic command for all types of bus transfers (INT, BULK, ISO, CTRL):
int ohci_trans_req(struct ohci * ohci, hcd_ed, int ctrl_len, void *ctrl, void * data, int data_len, __OHCI_BAG lw0, __OHCI_BAG lw1)
CTRL: ctrl, ctrl_len ... cmd buffer
data, data_len ... data buffer (in or out)
INT, BULK: ctrl = NULL, ctrl_len=0,
data, data_len ... data buffer (in or out)
ISO: tbd
 
There is no buffer reinsertion done by the internal HCD function.
(The interface layer does this for a INT-pipe on request.)
If you want a transfer then you have to
provide buffers by sending ohci_trans_req requests. As they are queued as TDs on an ED
you can send as many as you like. They should come back by the callback f_handler in
the same order (for each endpoint, not globally) If an error occurs all
queued transfers of an endpoint will return unsent. They will be marked with an error status.
e.g double-buffering for int transfers:
 
ohci_trans_req(ohci, ep_addr, 0, NULL, data0, data0_len, 0,0)
ohci_trans_req(ohci, ep_addr, 0, NULL, data1, data1_len, 0,0)
and when a data0 packet returns by the callback f_handler requeue it:
ohci_trans_req(ohci, ep_addr, 0, NULL, data0, data0_len, 0,0)
and when a data1 packet returns by the callback f_handler requeue it:
ohci_trans_req(ohci, ep_addr, 0, NULL, data1, data1_len, 0,0)
lw0, lw1 are private fields for upper layers for ids or fine grained handlers.
The alternate usb uses them for dev_id and usb_device_irq handler.
 
 
- Done list handling: returns the requests (callback f_handler in ED) and does
some error handling, root-hub request dequeuing
(files: ohci-done-list.c in ohci-hcd.c now(v0.2.0))
 
/silverlink.txt
0,0 → 1,76
-------------------------------------------------------------------------
Readme for Linux device driver for the Texas Instruments SilverLink cable
-------------------------------------------------------------------------
 
 
Homepage: http://lpg.ticalc.org/prj_usb
 
INTRODUCTION:
 
This is a driver for the TI-GRAPH LINK USB (aka SilverLink) cable, a cable
designed by TI for connecting their TI8x/9x calculators to a computer
(PC or Mac usually).
 
If you need more information, please visit the 'SilverLink drivers' homepage
at the above URL.
 
WHAT YOU NEED:
 
A TI calculator of course and a program capable to communicate with your
calculator.
TiLP will work for sure (since I am his developer !). yal92 may be able to use
it by changing tidev for tiglusb (may require some hacking...).
 
HOW TO USE IT:
 
You must have first compiled USB support, support for your specific USB host
controller (UHCI or OHCI).
 
Next, (as root) from your appropriate modules directory (lib/modules/2.5.XX):
 
insmod usb/usbcore.o
insmod usb/usb-uhci.o <OR> insmod usb/ohci-hcd.o
insmod tiglusb.o
 
If it is not already there (it usually is), create the device:
 
mknod /dev/tiglusb0 c 115 16
 
You will have to set permissions on this device to allow you to read/write
from it:
 
chmod 666 /dev/tiglusb0
Now you are ready to run a linking program such as TiLP. Be sure to configure
it properly (RTFM).
MODULE PARAMETERS:
 
You can set these with: insmod tiglusb NAME=VALUE
There is currently no way to set these on a per-cable basis.
 
NAME: timeout
TYPE: integer
DEFAULT: 15
DESC: Timeout value in tenth of seconds. If no data is available once this
time has expired then the driver will return with a timeout error.
 
QUIRKS:
 
The following problem seems to be specific to the link cable since it appears
on all platforms (Linux, Windows, Mac OS-X).
 
In some very particular cases, the driver returns with success but
without any data. The application should retry a read operation at least once.
 
HOW TO CONTACT US:
 
You can email me at roms@lpg.ticalc.org. Please prefix the subject line
with "TIGLUSB: " so that I am certain to notice your message.
You can also mail JB at jb@jblache.org: he has written the first release of
this driver but he better knows the Mac OS-X driver.
 
CREDITS:
 
The code is based on dabusb.c, printer.c and scanner.c !
The driver has been developed independantly of Texas Instruments.
/sl811hc.txt
0,0 → 1,331
README for embedded host controller SL811 (i386)
================================================
 
Original drivers from Pei Liu <pbl@cypress.com> for ARM architecture only.
Documentaion and readme for Architecture x86 (ADNP/1486) premealy.
 
 
Kernel configuration:
---------------------
o Patch USB drivers into your kerneltree
cd Your_kernel_root
 
gunzip linux-2.4.20-usb-1.patch.gz
patch -p1 -T < linux-2.4.20-usb*.patch
OR
gunzip -dc linux-2.4.20-usb*.patch.gz | patch -p1 -T
 
o Load default configuration for CP486SX/2 with ADNP/1486 and USB
arch/i386/adnp1486-usb104-SSV20030516
 
o Run "make configure" and set / verify this entries
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
General setup --->
[*] PCI support
(BIOS) PCI access mode
[ ] PCI device name database
SCSI support --->
<M> SCSI support
<M> SCSI disk support
(8) Maximum number of SCSI disks that can be loaded as modules
... Disable all other options ...
SCSI low-level drivers --->
... Disable all low level drivers ...
Input core support --->
<M> Input core support (Need only for Keyboard or Mouse)
<M> Keyboard support
<M> Mouse support
Character devices --->
[*] Virtual terminal (Need only for Keyboard)
Console drivers --->
[*] VGA text console (Need only for Key/Mouse)
Frame-buffer support ---> (... or use FB)
USB support --->
<M> Support for USB
[ ] USB verbose debug messages (Optional)
[*] Preliminary USB device filesystem (Optional for debugging)
--- USB Host Controller Drivers
<M> SL811HS Alternate (support isochronous mode)
...
<M> SL811HS (x86, StrongARM) support (old driver)
Disable all others "USB Host Controller Drivers"
--- USB Device Class drivers
<M> USB Mass Storage support
... and some aditional devices ...
<M> USB Printer support
<M> USB HIDBP Keyboard (basic) support
<M> USB HIDBP Mouse (basic) support
USB Serial Converter support --->
<M> USB Serial Converter support
<M> USB FTDI Single Port Serial Driver
o We have no PCI- and no SCSI-System, but all USB-drivers need CONFIG_PCI=y.
USB-Floppy driver need the SCSI-Subsystem, so we must enable this global
and disable all low level drivers in this menu.
--- OR ---
Download origanal kerneltree, and patch comlplete ADNP
with USB support and load configuration for this:
bunzip2 -c linux-2.4.20.tar.bz2 | tar xvf -
gunzip -c linux-2.4.20-SSV20030516.diff.gz | patch -p1 -T
Configuration: arch/i386/adnp1486-usb104-SSV20030516
o Compile the kernel
make dep
make ROOT_DEV=/dev/ram0 zImage
make modules
export INSTALL_MOD_PATH="`pwd`/_install" ; make modules_install
 
 
Default device configuration hc_sl811.o for USB1/104:
-----------------------------------------------------
io = 0x220
irq = 12
Remember: Second Controller was handled internal with IO offset +2.
 
 
Installation hc_sl811.o for CF1/USB:
------------------------------------
Compact Flash to USB adapter in io address of ide driver. It is for embedded
deviced only.
Please disable IDE driver in kernel configuration or do not load IDE drivers!
Change MAX_CONTROLERS = 1 into source asm/sl811-hw.h, recompile driver!
First Controller only
insmod hc_sl811.o io=0x1F0 irq=14
Second Controller only
insmod hc_sl811.o io=0x3F6 irq=14
 
Driver hc_sl811.o can not handle both controllers at same time.
This driver need a address-offset of 2 between controllers.
Please use alternate driver sl811.o instand.
 
 
Installation Alternate driver sl811.o:
--------------------------------------
This driver have a better interrupt handler, but don't tested with all devices.
 
Install both controllers on USB1-104 (default):
insmod sl811.o io=0x220,0x222 irq=12,12
 
Install both controllers on CF/USB1:
insmod sl811.o io=0x1f0,0x3f6 irq=14,14
 
Second controller can disable with specific IOBASE=0 for this controller.
 
 
General about USB:
------------------
Please install first the driver for hardware,
and than plugin the hardware into first USB port.
 
If your hardware find no driver the usbcore give ub a massage for missing
driver on conole or in file /proc/kmsg such as:
new USB device <NULL>-1.9, assigned address 7
USB device 7 (vend/prod 0x403/0x8372) is not claimed by any active drive
In this case remove the hardware from USB port, install the driver and
than plugin hardware again.
A list of driver for this missing hardware can found in file
/_install/lib/modules/2.4.20/modules.usbmap
Search the number 8372 in this file an verify the vendor ID. So you will
find the driver name "ftdi_sio" in this file.
If your hardware not listen in this file. Look into source and search your
numbers in source.
More read file:/Documentation/usb/proc_usb_info.txt
 
Drivers are all under contructions. So some drivers make a kernel panic. In
this case read all about the drivers dokumentaiona and the drivers source.
Some drivers need a other kernel driver, but not strictly checked in kenel
configuration. Here can help the ksymsoops.
 
 
 
Install a Floppy (NEC UF0001) or USB Stick Fujitsu/Siemens/iomega:
------------------------------
Copy files to target (FTP) and load all drivers.
Load Generic USB-Handler
insmod usbcore.o
Load USB-Host controller, parameters are optional (default urb_debug=0 io=220 irq=12)
insmod hc_sl811.o
Run the USB-Filesystem
mount -t usbdevfs usbdevfs /proc/bus/usb
Load drivers for disk storage and file systems
insmod scsi_mod.o
insmod usb-storage.o
insmod fat.o
insmod vfat.o
insmod sd_mod.o
Create node for floppy
mknod /dev/sda b 8 0
 
Put a disk into your floppy anth than plugin a USB-Floppy (such NEC Model UF0001)
into first USB-Port. Some Messages will be list on console or in file /proc/kmsg.
The disk is power on and the SCSI driver will search some partions on disk. Floppy
have no partions, so must use the first SCSI device without a partion number for mount.
Than mount the floppy:
mount /dev/sda /mnt -t vfat
 
If you see a partions check with valid partion 1, you should mount this partion.
Mostly Memory Sticks are formated with one partion. But if Windows format it again,
no partions is use.
 
You see that:
Partition check:
sda: sda1
Than mount with follow steps:
mknod /dev/sda1 b 8 1
mount /dev/sda1 /mnt -t vfat
 
Create complete list of nodes for SCSI-devices:
# First inserted device
echo -n "Create /dev/sda... "
mknod /dev/sda b 8 0
for i in 1 2 3 4 5 6 7
do
echo -n "$i "
mknod sda$i c 8 $i
done
# Second inserted device
echo -n "Create /dev/sdb... "
mknod /dev/sdb b 8 16
mknod /dev/sdb1 b 8 17
echo " done"
# Set some rights
chown root.disk sd*
chmod 660 sd*
 
 
Install a Keyboard:
-------------------
Copy files to target (FTP) and load all drivers.
Load Generic USB-Handler
insmod usbcore.o
Load USB-Host controller, parameters are optional (default urb_debug=0 io=220 irq=12)
insmod hc_sl811.o
Run the USB-Filesystem
mount -t usbdevfs usbdevfs /proc/bus/usb
Load drivers for USB-Keyboard
insmod input.o
insmod keybdev.o
insmod usbkbd.o
Now you can plugin Keyboard into first USB-Port and login on first console.
 
Something stuff:
"Undefined Symbols handle_scancode, keyboard_tasklet, kbd_ledfunc" at install ???
USB keyboard need PC-style keyboard driver, because the USB driver
simulate standard AT-Keycodes. A normaly AT- or PS/2-Keyboard must not
exist for this. The driver says normaly error (Timeout) on boot.
You must enable CONFIG_VT in kernel konfiguration!
Character devices --->
[*] Virtual terminal
[ ] Support for console on virtual terminal
 
Read <file:Documentation/input/input.txt>
 
 
Install a Mouse:
----------------
Load Generic USB-Handle
insmod usbcore.o
Load USB-Host controller
insmod hc_sl811.o
Run the USB-Filesystem
mount -t usbdevfs usbdevfs /proc/bus/usb
Load Generic Input device
insmod input.o
Load USB-Mouse driver
insmod input.o
insmod mousedev.o
insmod usbmouse.o
 
Read <file:Documentation/input/input.txt>
 
 
Install a serial adapter (Sample FTDI):
---------------------------------------
Load Generic USB-Handle
insmod usbcore.o
Load USB-Host controller
insmod hc_sl811.o
Run the USB-Filesystem
mount -t usbdevfs usbdevfs /proc/bus/usb
Load Generic derial device and hardware specific device
insmod usbserial.o
insmod ftdi_sio.o
Create node entry for this device
mknod /dev/ttyUSB0 c 188 0
Than plugin the hardware into first USB port and
use serial device on /dev/ttyUSB0, such call a login:
/sbin/getty 115200 ttyUSB0 vt100 &
 
 
USB-Utils:
----------
- usb-0.6-7.rpm, usb-0.6-7.src.rpm
/usr/sbin/lsusb, /usr/share/usb.ids
Good tool to list devices parameters.
You must load usbcore.o, hc_sl811.o and proc-usb before
program works right (use script usb.sh).
More details: Install usb-0.6-7.rpm on Your desktop and use "man lsusb".
 
 
Known Bugs:
-----------
 
PL2302 Profilic USB to serial converter will not work with hc_sl811.c (Bulk/Timeout).
USB Floppy will not work with alternate driver sl811.o (Sector not found)
 
 
CHANGELOG:
----------
* Fri 03 Okt 2003 hne
- Patch for 2.4.23-pre6
- Only low level port io in hardware include as inline functions.
- Move hc_sl811 and sl811 into host directory.
- sl811 for two controllers (alternate x86 only).
 
* Mit 24 Sep 2003 hne
- Misplaced "host/uhci.o" in Makefile.
- Move all x86/arm arch depens from main sl811.c to sl811-hw.h.
 
* Die 23 Sep 2003 hne
- Put arm and x86 architectur into separate file in include directory.
- Modifications for both controllers on CF/USB1, alternate sl811 only.
Parameter for CF/USB1: "io=0x1f0,0x3f6 irq=14".
 
* Fri 19 Sep 2003 hne
- First version for both controllers on USB1-104.
- Alternative driver sl811.c from kernel 2.4.22 (thanks Yinah),
also for 2.4.20. USB Sticks works, Floppy not.
 
* Die 02 Sep 2003 hne
- IO range only 2 address. For CF1USB we need io addres 3F6 and 3F7,
but do not use 3f8 (ttyS0).
 
* Mon 11 Aug 2003 hne
- Comments for using iomega Memory Stick
 
* Don 12 Jun 2003 hne
- Added Bus-Name for Kernel 2.4.20, no pattern_test at unload driver.
- more doc
 
* Fri May 16 2003 hne
- More comments, new patchfile, include usb-konfiguration as file
 
* Wed May 14 2003 hne
- Patch error: Old Sources was in Kerneltree!
 
* Mon Mar 17 2003 hne
- Copy usb SL811 from 2.4.19-rc into 2.4.20 kerneltree
- Add SL811 in Config and Make
 
* 18.11.2002 hne
- hc_sl811_rh.c:
rh_unlink_urb: Use usb_dec_dev_use instand of usb_put_dev. Function
usb_put_dev isn't known in this module. Some others have a macro for
this. What is right usb_put_dev or usb_dec_dev_use?
- hc_sl811.c:
Split into 3 files. Arcitectures store in hc_sl811-arm.c and hc_sl811-x86.c
Correct release_region() for both io address, so we can unload modul and
load again without reboot.
All IO access use 8 bit Data and register number (type __u8).
All functions static.
Only x86: base_addr renamed to io. data_reg_addr not used.
/error-codes.txt
0,0 → 1,130
Revised: 2000-Dec-05.
 
This is the documentation of (hopefully) all possible error codes (and
their interpretation) that can be returned from the host controller drivers
and from usbcore.
 
NOTE:
The USB_ST_* codes are deprecated and are only listed for compatibility;
new software should use only -E* instead!
 
 
 
**************************************************************************
* Error codes returned by usb_submit_urb *
**************************************************************************
 
Non-USB-specific:
 
USB_ST_NOERROR
0 URB submission went fine
 
-ENOMEM no memory for allocation of internal structures
 
USB-specific:
 
-ENODEV specified USB-device or bus doesn't exist
 
USB_ST_REQUEST_ERROR
-ENXIO a control or interrupt URB is already queued to this endpoint; or
a bulk URB is already queued to this endpoint and
USB_QUEUE_BULK wasn't used (UHCI HCDs only)
 
USB_ST_URB_INVALID_ERROR
-EINVAL a) Invalid transfer type specified (or not supported)
b) Invalid interrupt interval (0<=n<256)
c) more than one interrupt packet requested
d) ISO: number_of_packets is < 0
 
-EAGAIN a) specified ISO start frame too early
b) (using ISO-ASAP) too much scheduled for the future
wait some time and try again.
 
-EFBIG too much ISO frames requested (currently uhci>900)
 
USB_ST_STALL
-EPIPE specified pipe-handle is already stalled
 
-EMSGSIZE endpoint message size is zero, do interface/alternate setting
 
USB_ST_BANDWIDTH_ERROR
-ENOSPC The host controller's bandwidth is already consumed and
this request would push it past its allowed limit.
 
-ESHUTDOWN The host controller has been disabled due to some
problem that could not be worked around.
 
 
**************************************************************************
* Error codes returned by in urb->status *
* or in iso_frame_desc[n].status (for ISO) *
**************************************************************************
 
USB_ST_NOERROR
0 Transfer completed successfully
 
USB_ST_URB_KILLED
-ENOENT URB was canceled by usb_unlink_urb
 
USB_ST_URB_PENDING
-EINPROGRESS URB still pending, no results yet
(actually no error until now;-)
 
USB_ST_BITSTUFF
USB_ST_INTERNALERROR
-EPROTO a) bitstuff error
b) unknown USB error
 
USB_ST_CRC
-EILSEQ CRC mismatch
 
USB_ST_STALL
-EPIPE endpoint stalled
 
USB_ST_BUFFEROVERRUN
-ECOMM During an IN transfer, the host controller
received data from an endpoint faster than it
could be written to system memory
 
USB_ST_BUFFERUNDERRUN
-ENOSR During an OUT transfer, the host controller
could not retrieve data from system memory fast
enough to keep up with the USB data rate
 
USB_ST_DATAOVERRUN
-EOVERFLOW The amount of data returned by the endpoint was
greater than either the max packet size of the
endpoint or the remaining buffer size. "Babble".
 
USB_ST_DATAUNDERRUN
-EREMOTEIO The endpoint returned less than max packet size
and that amount did not fill the specified buffer
USB_ST_NORESPONSE
USB_ST_TIMEOUT
-ETIMEDOUT transfer timed out, NAK
 
USB_ST_REMOVED
-ENODEV device was removed
 
USB_ST_SHORT_PACKET
-EREMOTEIO short packet detected
 
USB_ST_PARTIAL_ERROR
-EXDEV ISO transfer only partially completed
look at individual frame status for details
 
USB_ST_URB_INVALID_ERROR
-EINVAL ISO madness, if this happens: Log off and go home
 
-ECONNRESET the URB is being unlinked asynchronously
 
**************************************************************************
* Error codes returned by usbcore-functions *
* (expect also other submit and transfer status codes) *
**************************************************************************
 
usb_register():
-EINVAL error during registering new driver
 
usb_get_*/usb_set_*():
All USB errors (submit/status) can occur
/auerswald.txt
0,0 → 1,37
Auerswald USB kernel driver
===========================
 
What is it? What can I do with it?
==================================
The auerswald USB kernel driver connects your linux 2.4.x
system to the auerswald usb-enabled devices.
 
There are two types of auerswald usb devices:
a) small PBX systems (ISDN)
b) COMfort system telephones (ISDN)
 
The driver installation creates the devices
/dev/usb/auer0..15. These devices carry a vendor-
specific protocol. You may run all auerswald java
software on it. The java software needs a native
library "libAuerUsbJNINative.so" installed on
your system. This library is available from
auerswald and shipped as part of the java software.
 
You may create the devices with:
mknod -m 666 /dev/usb/auer0 c 180 112
...
mknod -m 666 /dev/usb/auer15 c 180 127
 
ISDN support
============
If you enable CONFIG_USB_AUERISDN, you will get full
ISDN modem support via the HISAX ISDN4LINUX driver.
 
Of course, as for every USB-based ISDN adaptor, you
will have to modify your hotplug scripts to load
the isdn subsystem and configure the network interfaces.
Same procedure as for the ST5481 driver.
 
 
The maintainer of this driver is wolfgang@iksw-muees.de
/proc_usb_info.txt
0,0 → 1,394
/proc/bus/usb filesystem output
===============================
(version 2002.03.18)
 
 
The /proc filesystem for USB devices provides /proc/bus/usb/drivers
and /proc/bus/usb/devices, as well as /proc/bus/usb/BBB/DDD files.
 
 
**NOTE**: If /proc/bus/usb appears empty, and a host controller
driver has been linked, then you need to mount the
filesystem. Issue the command (as root):
 
mount -t usbfs none /proc/bus/usb
 
An alternative and more permanent method would be to add
 
none /proc/bus/usb usbfs defaults 0 0
 
to /etc/fstab. This will mount usbfs at each reboot.
You can then issue `cat /proc/bus/usb/devices` to extract
USB device information, and user mode drivers can use usbfs
to interact with USB devices.
 
There are a number of mount options supported by usbfs.
Consult the source code (linux/drivers/usb/inode.c) for
information about those options.
 
**NOTE**: The filesystem has been renamed from "usbdevfs" to
"usbfs", to reduce confusion with "devfs". You may
still see references to the older "usbdevfs" name.
 
For more information on mounting the usbfs file system, see the
"USB Device Filesystem" section of the USB Guide. The latest copy
of the USB Guide can be found at http://www.linux-usb.org/
 
 
THE /proc/bus/usb/BBB/DDD FILES:
--------------------------------
Each connected USB device has one file. The BBB indicates the bus
number. The DDD indicates the device address on that bus. Both
of these numbers are assigned sequentially, and can be reused, so
you can't rely on them for stable access to devices. For example,
it's relatively common for devices to re-enumerate while they are
still connected (perhaps someone jostled their power supply, hub,
or USB cable), so a device might be 002/027 when you first connect
it and 002/048 sometime later.
 
These files can be read as binary data. The binary data consists
of first the device descriptor, then the descriptors for each
configuration of the device. That information is also shown in
text form by the /proc/bus/usb/devices file, described later.
 
These files may also be used to write user-level drivers for the USB
devices. You would open the /proc/bus/usb/BBB/DDD file read/write,
read its descriptors to make sure it's the device you expect, and then
bind to an interface (or perhaps several) using an ioctl call. You
would issue more ioctls to the device to communicate to it using
control, bulk, or other kinds of USB transfers. The IOCTLs are
listed in the <linux/usbdevice_fs.h> file, and at this writing the
source code (linux/drivers/usb/devio.c) is the primary reference
for how to access devices through those files.
 
Note that since by default these BBB/DDD files are writable only by
root, only root can write such user mode drivers. You can selectively
grant read/write permissions to other users by using "chmod". Also,
usbfs mount options such as "devmode=0666" may be helpful.
 
 
 
THE /proc/bus/usb/drivers FILE:
-------------------------------
Each of the USB device drivers linked into your kernel (statically,
or dynamically using "modprobe") is listed in the "drivers" file.
Here's an example from one system:
 
usbdevfs
hub
0- 15: usblp
usbnet
serial
usb-storage
pegasus
 
If you see this file, "usbdevfs" and "hub" will always be listed,
since those are part of the "usbcore" framework.
 
Drivers that use the USB major number (180) to provide character devices
will include a range of minor numbers, as shown above for the "usblp"
(actually "printer.o") module. USB device drivers can of course use any
major number, but it's easy to use the USB range since there's explicit
support for subdividing it in the USB device driver framework.
 
 
THE /proc/bus/usb/devices FILE:
-------------------------------
In /proc/bus/usb/devices, each device's output has multiple
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
in the first 4 columns of each "T:" line (topology info:
Lev, Prnt, Port, Cnt) can be used to build a USB topology diagram.
 
Each line is tagged with a one-character ID for that line:
 
T = Topology (etc.)
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 descriptors.
C = Configuration descriptor info. (* = active configuration)
I = Interface descriptor info.
E = Endpoint descriptor info.
 
=======================================================================
 
/proc/bus/usb/devices output format:
 
Legend:
d = decimal number (may have leading spaces or 0's)
x = hexadecimal number (may have leading spaces or 0's)
s = string
 
 
Topology info:
 
T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd
| | | | | | | | |__MaxChildren
| | | | | | | |__Device Speed in Mbps
| | | | | | |__DeviceNumber
| | | | | |__Count of devices at this level
| | | | |__Connector/Port on Parent for this device
| | | |__Parent DeviceNumber
| | |__Level in topology for this bus
| |__Bus number
|__Topology info tag
 
Speed may be:
1.5 Mbit/s for low speed USB
12 Mbit/s for full speed USB
480 Mbit/s for high speed USB (added for USB 2.0)
 
 
Bandwidth info:
B: Alloc=ddd/ddd us (xx%), #Int=ddd, #Iso=ddd
| | | |__Number of isochronous requests
| | |__Number of interrupt requests
| |__Total Bandwidth allocated to this bus
|__Bandwidth info tag
 
Bandwidth allocation is an approximation of how much of one frame
(millisecond) is in use. It reflects only periodic transfers, which
are the only transfers that reserve bandwidth. Control and bulk
transfers use all other bandwidth, including reserved bandwidth that
is not used for transfers (such as for short packets).
The percentage is how much of the "reserved" bandwidth is scheduled by
those transfers. For a low or full speed bus (loosely, "USB 1.1"),
90% of the bus bandwidth is reserved. For a high speed bus (loosely,
"USB 2.0") 80% is reserved.
 
 
Device descriptor info & Product ID info:
 
D: Ver=x.xx Cls=xx(s) Sub=xx Prot=xx MxPS=dd #Cfgs=dd
P: Vendor=xxxx ProdID=xxxx Rev=xx.xx
 
where
D: Ver=x.xx Cls=xx(sssss) Sub=xx Prot=xx MxPS=dd #Cfgs=dd
| | | | | | |__NumberConfigurations
| | | | | |__MaxPacketSize of Default Endpoint
| | | | |__DeviceProtocol
| | | |__DeviceSubClass
| | |__DeviceClass
| |__Device USB version
|__Device info tag #1
 
where
P: Vendor=xxxx ProdID=xxxx Rev=xx.xx
| | | |__Product revision number
| | |__Product ID code
| |__Vendor ID code
|__Device info tag #2
 
 
String descriptor info:
 
S: Manufacturer=ssss
| |__Manufacturer of this device as read from the device.
| For USB host controller drivers (virtual root hubs) this may
| be omitted, or (for newer drivers) will identify the kernel
| version and the driver which provides this hub emulation.
|__String info tag
 
S: Product=ssss
| |__Product description of this device as read from the device.
| For older USB host controller drivers (virtual root hubs) this
| indicates the driver; for newer ones, it's a product (and vendor)
| description that often comes from the kernel's PCI ID database.
|__String info tag
 
S: SerialNumber=ssss
| |__Serial Number of this device as read from the device.
| For USB host controller drivers (virtual root hubs) this is
| some unique ID, normally a bus ID (address or slot name) that
| can't be shared with any other device.
|__String info tag
 
 
 
Configuration descriptor info:
 
C:* #Ifs=dd Cfg#=dd Atr=xx MPwr=dddmA
| | | | | |__MaxPower in mA
| | | | |__Attributes
| | | |__ConfiguratioNumber
| | |__NumberOfInterfaces
| |__ "*" indicates the active configuration (others are " ")
|__Config info tag
USB devices may have multiple configurations, each of which act
rather differently. For example, a bus-powered configuration
might be much less capable than one that is self-powered. Only
one device configuration can be active at a time; most devices
have only one configuration.
 
Each configuration consists of one or more interfaces. Each
interface serves a distinct "function", which is typically bound
to a different USB device driver. One common example is a USB
speaker with an audio interface for playback, and a HID interface
for use with software volume control.
 
 
Interface descriptor info (can be multiple per Config):
 
I: If#=dd Alt=dd #EPs=dd Cls=xx(sssss) Sub=xx Prot=xx Driver=ssss
| | | | | | | |__Driver name
| | | | | | | or "(none)"
| | | | | | |__InterfaceProtocol
| | | | | |__InterfaceSubClass
| | | | |__InterfaceClass
| | | |__NumberOfEndpoints
| | |__AlternateSettingNumber
| |__InterfaceNumber
|__Interface info tag
 
A given interface may have one or more "alternate" settings.
For example, default settings may not use more than a small
amount of periodic bandwidth. To use significant fractions
of bus bandwidth, drivers must select a non-default altsetting.
Only one setting for an interface may be active at a time, and
only one driver may bind to an interface at a time. Most devices
have only one alternate setting per interface.
 
 
Endpoint descriptor info (can be multiple per Interface):
 
E: Ad=xx(s) Atr=xx(ssss) MxPS=dddd Ivl=dddms
| | | | |__Interval (max) between transfers
| | | |__EndpointMaxPacketSize
| | |__Attributes(EndpointType)
| |__EndpointAddress(I=In,O=Out)
|__Endpoint info tag
 
The interval is nonzero for all periodic (interrupt or isochronous)
endpoints. For high speed endpoints the transfer interval may be
measured in microseconds rather than milliseconds.
 
For high speed periodic endpoints, the "MaxPacketSize" reflects
the per-microframe data transfer size. For "high bandwidth"
endpoints, that can reflect two or three packets (for up to
3KBytes every 125 usec) per endpoint.
 
With the Linux-USB stack, periodic bandwidth reservations use the
transfer intervals and sizes provided by URBs, which can be less
than those found in endpoint descriptor.
 
 
=======================================================================
 
 
If a user or script is interested only in Topology info, for
example, use something like "grep ^T: /proc/bus/usb/devices"
for only the Topology lines. A command like
"grep -i ^[tdp]: /proc/bus/usb/devices" can be used to list
only the lines that begin with the characters in square brackets,
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 TBDPSCIE] or "All" lines from
/proc/bus/usb/devices.)
 
The Topology lines can be used to generate a graphic/pictorial
of the USB devices on a system's root hub. (See more below
on how to do this.)
 
The Interface lines can be used to determine what driver is
being used for each device.
 
The Configuration lines could be used to list maximum power
(in milliamps) that a system's USB devices are using.
For example, "grep ^C: /proc/bus/usb/devices".
 
 
Here's an example, from a system which has a UHCI root hub,
an external hub connected to the root hub, and a mouse and
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
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms
T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=04b4 ProdID=0001 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse
E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms
T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0565 ProdID=0001 Rev= 1.08
S: Manufacturer=Peracom Networks, Inc.
S: Product=Peracom USB to Serial Converter
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl= 16ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 16 Ivl= 16ms
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl= 8ms
 
 
Selecting only the "T:" and "I:" lines from this (for example, by using
"procusb ti"), we have:
 
T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse
T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial
 
 
Physically this looks like (or could be converted to):
 
+------------------+
| PC/root_hub (12)| Dev# = 1
+------------------+ (nn) is Mbps.
Level 0 | CN.0 | CN.1 | [CN = connector/port #]
+------------------+
/
/
+-----------------------+
Level 1 | Dev#2: 4-port hub (12)|
+-----------------------+
|CN.0 |CN.1 |CN.2 |CN.3 |
+-----------------------+
\ \____________________
\_____ \
\ \
+--------------------+ +--------------------+
Level 2 | Dev# 3: mouse (1.5)| | Dev# 4: serial (12)|
+--------------------+ +--------------------+
 
 
 
Or, in a more tree-like structure (ports [Connectors] without
connections could be omitted):
 
PC: Dev# 1, root hub, 2 ports, 12 Mbps
|_ CN.0: Dev# 2, hub, 4 ports, 12 Mbps
|_ CN.0: Dev #3, mouse, 1.5 Mbps
|_ CN.1:
|_ CN.2: Dev #4, serial, 12 Mbps
|_ CN.3:
|_ CN.1:
 
 
### END ###
/URB.txt
0,0 → 1,228
Revised: 2000-Dec-05.
 
1. Specification of the API
 
1.1. Basic concept or 'What is an URB?'
 
The basic idea of the new driver is message passing, the message itself is
called USB Request Block, or URB for short.
 
- An URB consists of all relevant information to execute any USB transaction
and deliver the data and status back.
 
- Execution of an URB is inherently an asynchronous operation, i.e. the
usb_submit_urb(urb) call returns immediately after it has successfully queued
the requested action.
 
- Ongoing transfers for one URB (e.g. ISO) can simply be canceled with
usb_unlink_urb(urb) at any time.
 
- Each URB has a completion handler, which is called after the action
has been successfully completed or canceled (INT transfers behave a bit
differently, see below). The URB also contains a context-pointer for free
usage and information passing to the completion handler.
 
- URBs can be linked. After completing one URB, the next one can be
automatically submitted. This is especially useful for ISO transfers:
You only have read/write the data from/to the buffers in the completion
handler, the continuous streaming itself is transparently done by the
URB-machinery.
 
 
1.2. The URB structure
 
typedef struct urb
{
spinlock_t lock; // lock for the URB
 
// ignore, for host controller/URB machine internal use
void *hcpriv; // private data for host controller
struct list_head urb_list; // list pointer to all active urbs
 
// This is used for urb linking
struct urb* next; // pointer to next URB
struct usb_device *dev; // pointer to associated USB device
 
// pipe is assembled by the various well-known pipe macros in usb.h
unsigned int pipe; // pipe information
 
// status after each completion
int status; // returned status
unsigned int transfer_flags; // ASAP, DISABLE_SPD, etc.
 
// for data stage (CTRL), BULK, INT and ISO
void *transfer_buffer; // associated data buffer
 
// expected length
int transfer_buffer_length; // data buffer length
int actual_length; // actual data buffer length
 
// setup stage for CTRL (always 8 bytes!)
unsigned char* setup_packet; // setup packet (control only)
 
// with ASAP, start_frame is set to the determined frame
int start_frame; // start frame (iso/irq)
int number_of_packets; // # of packets (iso/int)
int interval; // polling interval (irq only)
int error_count; // number of errors (iso only)
//
void *context; // context for completion routine
usb_complete_t complete; // pointer to completion routine
//
// specification of the requested data offsets and length for ISO
iso_packet_descriptor_t iso_frame_desc[0];
} urb_t, *purb_t;
 
 
1.3. How to get an URB?
 
URBs are allocated with the following call
 
purb_t usb_alloc_urb(int isoframes)
 
Return value is a pointer to the allocated URB, 0 if allocation failed.
The parameter isoframes specifies the number of isochronous transfer frames
you want to schedule. For CTRL/BULK/INT, use 0.
 
To free an URB, use
 
void usb_free_urb(purb_t purb)
 
This call also may free internal (host controller specific) memory in the
future.
 
 
1.4. What has to be filled in?
 
Depending on the type of transaction, there are some macros
(FILL_CONTROL_URB, FILL_CONTROL_URB_TO, FILL_BULK_URB,
FILL_BULK_URB_TO, and FILL_INT_URB, defined in usb.h)
that simplify the URB creation. In general, all macros need the usb
device pointer, the pipe (usual format from usb.h), the transfer buffer,
the desired transfer length, the completion handler, and its context.
Take a look at the usb_control_msg function that converts the old API
into the URB API.
 
Flags:
For ISO there are two startup behaviors: Specified start_frame or ASAP.
For ASAP set USB_ISO_ASAP in transfer_flags.
 
If short packets should NOT be tolerated, set USB_DISABLE_SPD in
transfer_flags.
 
Usually, to reduce restart time, the completion handler is called
AFTER the URB re-submission. However, it is called BEFORE URB
re-submission for INT transfers that are being continued.
 
 
1.5. How to submit an URB?
 
Just call
 
int usb_submit_urb(purb_t purb)
 
It immediately returns, either with status 0 (request queued) or some
error code, usually caused by the following:
 
- Out of memory (-ENOMEM)
- Wrong pipe handle (-ENXIO)
- Unplugged device (-ENODEV)
- Stalled endpoint (-EPIPE)
- Too many queued ISO transfers (-EAGAIN)
- Too many requested ISO frames (-EFBIG)
- Invalid INT interval (-EINVAL)
- More than one packet for INT (-EINVAL)
 
After submission, urb->status is USB_ST_URB_PENDING (-EINPROGRESS).
 
For isochronous endpoints, subsequent submitting of URBs to the same endpoint
with the ASAP flag result in a seamless ISO streaming. Exception: The
execution cannot be scheduled later than 900 frames from the 'now'-time.
The same applies to INT transfers, but here the seamless continuation is
independent of the transfer flags (implicitly ASAP).
 
 
1.6. How to cancel an already running URB?
 
For an URB which you've submitted, but which hasn't been returned to
your driver by the host controller, call
 
int usb_unlink_urb(purb_t purb)
 
It removes the urb from the internal list and frees all allocated
HW descriptors. The status is changed to USB_ST_URB_KILLED. After
usb_unlink_urb() returns, you can safely free the URB with usb_free_urb(urb)
and all other possibly associated data (urb->context etc.)
 
There is also an asynchronous unlink mode. To use this, set the
the USB_ASYNC_UNLINK flag in urb->transfer flags before calling
usb_unlink_urb(). When using async unlinking, the URB will not
normally be unlinked when usb_unlink_urb() returns. Instead, wait
for the completion handler to be called.
 
 
1.7. What about the completion handler?
 
The completion handler is optional, but useful for fast data processing
or wakeup of a sleeping process (as shown in the compatibility wrapper's
completion handler).
 
The handler is of the following type:
 
typedef void (*usb_complete_t)(struct urb *);
 
i.e. it gets just the URB that caused the completion call.
In the completion handler, you should have a look at urb->status to
detect any USB errors. Since the context parameter is included in the URB,
you can pass information to the completion handler.
 
NOTE: ***** WARNING *****
AVOID using the urb->dev field in your completion handler; it's cleared
as part of URB unlinking. Instead, use urb->context to hold all the
data your driver needs.
 
NOTE: ***** WARNING *****
Also, NEVER SLEEP IN A COMPLETION HANDLER. These are normally called
during hardware interrupt processing. If you can, defer substantial
work to a tasklet (bottom half) to keep system latencies low. You'll
probably need to use spinlocks to protect data structures you manipulate
in completion handlers.
 
 
1.8. How to do isochronous (ISO) transfers?
 
For ISO transfers you have to append the iso_packet_descriptor_t structure
to the URB for each frame you want to schedule. When using usb_alloc_urb(n)
(recommended), the iso_packets parameter can be used to allocate the
structures for iso_packets frames.
 
For each entry you have to specify the data offset for this frame (base is
transfer_buffer), and the length you want to write/expect to read.
After completion, actual_length contains the actual transferred length and
status contains the resulting USB-status for the ISO transfer for this frame.
It is allowed to specify a varying length from frame to frame (e.g. for
audio synchronisation/adaptive transfer rates). You can also use the length
0 to omit one or more frames (striping).
 
As can be concluded from above, the UHCI-driver does not care for continuous
data in case of short packet ISO reads! There's no fixup_isoc() like in the
old driver. There may be a common routine to do this in the future, but this
has nothing to do with the UHCI-driver!
 
For scheduling you can choose your own start frame or ASAP. As written above,
queuing more than one ISO frame with ASAP to the same device&endpoint result
in seamless ISO streaming. For continuous streaming you have to use URB
linking.
 
 
1.9. How to start interrupt (INT) transfers?
 
INT transfers are currently implemented with different queues for intervals
for 1, 2, 4,... 128ms. Only one URB is allocated for each interrupt. After
calling the completion handler, that URB is recycled by the host controller
driver (HCD).
With the submission of one URB, the interrupt is scheduled until it is
canceled by usb_unlink_urb.
 
The usb_submit_urb() call modifies urb->interval to the implemented interval
value that is less than or equal to the requested interval value.
/ibmcam.txt
0,0 → 1,324
README for Linux device driver for the IBM "C-It" USB video camera
 
INTRODUCTION:
 
This driver does not use all features known to exist in
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 data sheets from Xirlink.
 
Video formats:
128x96 [model 1]
176x144
320x240 [model 2]
352x240 [model 2]
352x288
Frame rate: 3 - 30 frames per second (FPS)
External interface: USB
Internal interface: Video For Linux (V4L)
Supported controls:
- by V4L: Contrast, Brightness, Color, Hue
- by driver options: frame rate, lighting conditions, video format,
default picture settings, sharpness.
 
SUPPORTED CAMERAS:
 
Xirlink "C-It" camera, also known as "IBM PC Camera".
The device uses proprietary ASIC (and compression method);
it is manufactured by Xirlink. See http://www.xirlink.com/
http://www.ibmpccamera.com or http://www.c-itnow.com/ for
details and pictures.
 
This very chipset ("X Chip", as marked at the factory)
is used in several other cameras, and they are supported
as well:
 
- IBM NetCamera
- Veo Stingray
 
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". These cameras are
no longer manufactured.
 
Xirlink now manufactures new cameras which are somewhat different.
In particular, following models [FCC ID] belong to that category:
 
XVP300 [KSX-X9903]
XVP600 [KSX-X9902]
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
(with exception of 352x288 native mode).
 
Some IBM NetCameras (Model 4) are made to generate only compressed
video streams. This is great for performance, but unfortunately
nobody knows how to decompress the stream :-( Therefore, these
cameras are *unsupported* and if you try to use one of those, all
you get is random colored horizontal streaks, not the image!
If you have one of those cameras, you probably should return it
to the store and get something that is supported.
 
Tell me more about all that "model" business
--------------------------------------------
 
I just invented model numbers to uniquely identify flavors of the
hardware/firmware that were sold. It was very confusing to use
brand names or some other internal numbering schemes. So I found
by experimentation that all Xirlink chipsets fall into four big
classes, and I called them "models". Each model is programmed in
its own way, and each model sends back the video in its own way.
 
Quirks of Model 2 cameras:
-------------------------
 
Model 2 does not have hardware contrast control. Corresponding V4L
control is implemented in software, which is not very nice to your
CPU, but at least it works.
 
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
the frame rate at slowest setting, but I had to move it pretty much down
the scale (so that framerate option barely matters). I also noticed that
camera after first powering up produces frames slightly faster than during
consecutive uses. All this means that if you use 352x288 (which is
default), be warned - you may encounter broken picture on first connect;
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 176x144 which makes perfectly good I420, with no scaling and
lesser demands on USB (300 Kbits per second, or 26 frames per second).
 
Another strange effect of 352x288 mode is the fine vertical grid visible
on some colored surfaces. I am sure it is caused by me not understanding
what the camera is trying to say. Blame trade secrets for that.
 
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?)
 
[Veo Stingray with Product ID 0x800C is also Model 2, but I haven't
observed this particular flaw in it.]
 
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; 2.2 w/backport may work)
 
- A Video4Linux compatible frame grabber program such as xawtv.
HOW TO COMPILE THE DRIVER:
 
You need to compile the driver only if you are a developer
or if you want to make changes to the code. Most distributions
precompile all modules, so you can go directly to the next
section "HOW TO USE THE DRIVER".
 
The ibmcam driver uses usbvideo helper library (module),
so if you are studying the ibmcam code you will be led there.
 
The driver itself consists of only one file in usb/ directory:
ibmcam.c. This file is included into the Linux kernel build
process if you configure the kernel for CONFIG_USB_IBMCAM.
Run "make xconfig" and in USB section you will find the IBM
camera driver. Select it, save the configuration and recompile.
 
HOW TO USE THE DRIVER:
 
I recommend to compile driver as a module. This gives you an
easier access to its configuration. The camera has many more
settings than V4L can operate, so some settings are done using
module options.
 
To begin with, on most modern Linux distributions the driver
will be automatically loaded whenever you plug the supported
camera in. Therefore, you don't need to do anything. However
if you want to experiment with some module parameters then
you can load and unload the driver manually, with camera
plugged in or unplugged.
 
Typically module is installed with command 'modprobe', like this:
 
# modprobe ibmcam framerate=1
 
Alternatively you can use 'insmod' in similar fashion:
 
# insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1
 
Module can be inserted with camera connected or disconnected.
 
The driver can have options, though some defaults are provided.
 
Driver options: (* indicates that option is model-dependent)
 
Name Type Range [default] Example
-------------- -------------- -------------- ------------------
debug Integer 0-9 [0] debug=1
flags Integer 0-0xFF [0] flags=0x0d
framerate Integer 0-6 [2] framerate=1
hue_correction Integer 0-255 [128] hue_correction=115
init_brightness Integer 0-255 [128] init_brightness=100
init_contrast Integer 0-255 [192] init_contrast=200
init_color Integer 0-255 [128] init_color=130
init_hue Integer 0-255 [128] init_hue=115
lighting Integer 0-2* [1] lighting=2
sharpness Integer 0-6* [4] sharpness=3
size Integer 0-2* [2] size=1
 
Options for Model 2 only:
 
Name Type Range [default] Example
-------------- -------------- -------------- ------------------
init_model2_rg Integer 0..255 [0x70] init_model2_rg=128
init_model2_rg2 Integer 0..255 [0x2f] init_model2_rg2=50
init_model2_sat Integer 0..255 [0x34] init_model2_sat=65
init_model2_yb Integer 0..255 [0xa0] init_model2_yb=200
 
debug You don't need this option unless you are a developer.
If you are a developer then you will see in the code
what values do what. 0=off.
 
flags This is a bit mask, and you can combine any number of
bits to produce what you want. Usually you don't want
any of extra features this option provides:
 
FLAGS_RETRY_VIDIOCSYNC 1 This bit allows to retry failed
VIDIOCSYNC ioctls without failing.
Will work with xawtv, will not
with xrealproducer. Default is
not set.
FLAGS_MONOCHROME 2 Activates monochrome (b/w) mode.
FLAGS_DISPLAY_HINTS 4 Shows colored pixels which have
magic meaning to developers.
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.
FLAGS_NO_DECODING 128 This flag turns the video stream
decoder off, and dumps the raw
Isoc data from the camera into
the reading process. Useful to
developers, but not to users.
 
framerate This setting controls frame rate of the camera. This is
an approximate setting (in terms of "worst" ... "best")
because camera changes frame rate depending on amount
of light available. Setting 0 is slowest, 6 is fastest.
Beware - fast settings are very demanding and may not
work well with all video sizes. Be conservative.
 
hue_correction This highly optional setting allows to adjust the
hue of the image in a way slightly different from
what usual "hue" control does. Both controls affect
YUV colorspace: regular "hue" control adjusts only
U component, and this "hue_correction" option similarly
adjusts only V component. However usually it is enough
to tweak only U or V to compensate for colored light or
color temperature; this option simply allows more
complicated correction when and if it is necessary.
 
init_brightness These settings specify _initial_ values which will be
init_contrast used to set up the camera. If your V4L application has
init_color its own controls to adjust the picture then these
init_hue controls will be used too. These options allow you to
preconfigure the camera when it gets connected, before
any V4L application connects to it. Good for webcams.
 
init_model2_rg These initial settings alter color balance of the
init_model2_rg2 camera on hardware level. All four settings may be used
init_model2_sat to tune the camera to specific lighting conditions. These
init_model2_yb settings only apply to Model 2 cameras.
 
lighting This option selects one of three hardware-defined
photosensitivity settings of the camera. 0=bright light,
1=Medium (default), 2=Low light. This setting affects
frame rate: the dimmer the lighting the lower the frame
rate (because longer exposition time is needed). The
Model 2 cameras allow values more than 2 for this option,
thus enabling extremely high sensitivity at cost of frame
rate, color saturation and imaging sensor noise.
 
sharpness This option controls smoothing (noise reduction)
made by camera. Setting 0 is most smooth, setting 6
is most sharp. Be aware that CMOS sensor used in the
camera is pretty noisy, so if you choose 6 you will
be greeted with "snowy" image. Default is 4. Model 2
cameras do not support this feature.
 
size This setting chooses one of several image sizes that are
supported by this driver. Cameras may support more, but
it's difficult to reverse-engineer all formats.
Following video sizes are supported:
 
size=0 128x96 (Model 1 only)
size=1 160x120
size=2 176x144
size=3 320x240 (Model 2 only)
size=4 352x240 (Model 2 only)
size=5 352x288
size=6 640x480 (Model 3 only)
 
The 352x288 is the native size of the Model 1 sensor
array, so it's the best resolution the camera can
yield. The best resolution of Model 2 is 176x144, and
larger images are produced by stretching the bitmap.
Model 3 has sensor with 640x480 grid, and it works too,
but the frame rate will be exceptionally low (1-2 FPS);
it may be still OK for some applications, like security.
Choose the image size you need. The smaller image can
support faster frame rate. Default is 352x288.
 
For more information and the Troubleshooting FAQ visit this URL:
 
http://www.linux-usb.org/ibmcam/
 
WHAT NEEDS TO BE DONE:
 
- The button on the camera is not used. I don't know how to get to it.
I know now how to read button on Model 2, but what to do with it?
 
- Camera reports its status back to the driver; however I don't know
what returned data means. If camera fails at some initialization
stage then something should be done, and I don't do that because
I don't even know that some command failed. This is mostly Model 1
concern because Model 2 uses different commands which do not return
status (and seem to complete successfully every time).
 
- Some flavors of Model 4 NetCameras produce only compressed video
streams, and I don't know how to decode them.
 
CREDITS:
 
The code is based in no small part on the CPiA driver by Johannes Erdfelt,
Randy Dunlap, and others. Big thanks to them for their pioneering work on that
and the USB stack.
 
I also thank John Lightsey for his donation of the Veo Stingray camera.
/uhci.txt
0,0 → 1,165
Specification and Internals for the New UHCI Driver (Whitepaper...)
 
brought to you by
 
Georg Acher, acher@in.tum.de (executive slave) (base guitar)
Deti Fliegl, deti@fliegl.de (executive slave) (lead voice)
Thomas Sailer, sailer@ife.ee.ethz.ch (chief consultant) (cheer leader)
$Id: uhci.txt,v 1.1.1.1 2004-04-15 02:32:08 phoenix Exp $
 
This document and the new uhci sources can be found on
http://hotswap.in.tum.de/usb
 
1. General issues
 
1.1 Why a new UHCI driver, we already have one?!?
 
Correct, but its internal structure got more and more mixed up by the (still
ongoing) efforts to get isochronous transfers (ISO) to work.
Since there is an increasing need for reliable ISO-transfers (especially
for USB-audio needed by TS and for a DAB-USB-Receiver build by GA and DF),
this state was a bit unsatisfying in our opinion, so we've decided (based
on knowledge and experiences with the old UHCI driver) to start
from scratch with a new approach, much simpler but at the same time more
powerful.
It is inspired by the way Win98/Win2000 handles USB requests via URBs,
but it's definitely 100% free of MS-code and doesn't crash while
unplugging an used ISO-device like Win98 ;-)
Some code for HW setup and root hub management was taken from the
original UHCI driver, but heavily modified to fit into the new code.
The invention of the basic concept, and major coding were completed in two
days (and nights) on the 16th and 17th of October 1999, now known as the
great USB-October-Revolution started by GA, DF, and TS ;-)
 
Since the concept is in no way UHCI dependent, we hope that it will also be
transferred to the OHCI-driver, so both drivers share a common API.
 
1.2. Advantages and disadvantages
 
+ All USB transfer types work now!
+ Asynchronous operation
+ Simple, but powerful interface (only two calls for start and cancel)
+ Easy migration to the new API, simplified by a compatibility API
+ Simple usage of ISO transfers
+ Automatic linking of requests
+ ISO transfers allow variable length for each frame and striping
+ No CPU dependent and non-portable atomic memory access, no asm()-inlines
+ Tested on x86 and Alpha
 
- Rewriting for ISO transfers needed
 
1.3. Is there some compatibility to the old API?
 
Yes, but only for control, bulk and interrupt transfers. We've implemented
some wrapper calls for these transfer types. The usbcore works fine with
these wrappers. For ISO there's no compatibility, because the old ISO-API
and its semantics were unnecessary complicated in our opinion.
 
1.4. What's really working?
 
As said above, CTRL and BULK already work fine even with the wrappers,
so legacy code wouldn't notice the change.
Regarding to Thomas, ISO transfers now run stable with USB audio.
INT transfers (e.g. mouse driver) work fine, too.
 
1.5. Are there any bugs?
 
No ;-)
Hm...
Well, of course this implementation needs extensive testing on all available
hardware, but we believe that any fixes shouldn't harm the overall concept.
 
1.6. What should be done next?
 
A large part of the request handling seems to be identical for UHCI and
OHCI, so it would be a good idea to extract the common parts and have only
the HW specific stuff in uhci.c. Furthermore, all other USB device drivers
should need URBification, if they use isochronous or interrupt transfers.
One thing missing in the current implementation (and the old UHCI driver)
is fair queueing for BULK transfers. Since this would need (in principle)
the alteration of already constructed TD chains (to switch from depth to
breadth execution), another way has to be found. Maybe some simple
heuristics work with the same effect.
 
---------------------------------------------------------------------------
 
2. Internal structure and mechanisms
 
To get quickly familiar with the internal structures, here's a short
description how the new UHCI driver works. However, the ultimate source of
truth is only uhci.c!
 
2.1. Descriptor structure (QHs and TDs)
 
During initialization, the following skeleton is allocated in init_skel:
 
framespecific | common chain
 
framelist[]
[ 0 ]-----> TD --> TD -------\
[ 1 ]-----> TD --> TD --------> TD ----> QH -------> QH -------> QH ---> NULL
... TD --> TD -------/
[1023]-----> TD --> TD ------/
^^ ^^ ^^ ^^ ^^ ^^
1024 TDs for 7 TDs for 1 TD for Start of Start of End Chain
ISO INT (2-128ms) 1ms-INT CTRL Chain BULK Chain
 
For each CTRL or BULK transfer a new QH is allocated and the containing data
transfers are appended as (vertical) TDs. After building the whole QH with its
dangling TDs, the QH is inserted before the BULK Chain QH (for CTRL) or
before the End Chain QH (for BULK). Since only the QH->next pointers are
affected, no atomic memory operation is required. The three QHs in the
common chain are never equipped with TDs!
 
For ISO or INT, the TD for each frame is simply inserted into the appropriate
ISO/INT-TD-chain for the desired frame. The 7 skeleton INT-TDs are scattered
among the 1024 frames similar to the old UHCI driver.
 
For CTRL/BULK/ISO, the last TD in the transfer has the IOC-bit set. For INT,
every TD (there is only one...) has the IOC-bit set.
 
Besides the data for the UHCI controller (2 or 4 32bit words), the descriptors
are double-linked through the .vertical and .horizontal elements in the
SW data of the descriptor (using the double-linked list structures and
operations), but SW-linking occurs only in closed domains, i.e. for each of
the 1024 ISO-chains and the 8 INT-chains there is a closed cycle. This
simplifies all insertions and unlinking operations and avoids costly
bus_to_virt()-calls.
 
2.2. URB structure and linking to QH/TDs
 
During assembly of the QH and TDs of the requested action, these descriptors
are stored in urb->urb_list, so the allocated QH/TD descriptors are bound to
this URB.
If the assembly was successful and the descriptors were added to the HW chain,
the corresponding URB is inserted into a global URB list for this controller.
This list stores all pending URBs.
 
2.3. Interrupt processing
 
Since UHCI provides no means to directly detect completed transactions, the
following is done in each UHCI interrupt (uhci_interrupt()):
 
For each URB in the pending queue (process_urb()), the ACTIVE-flag of the
associated TDs are processed (depending on the transfer type
process_{transfer|interrupt|iso}()). If the TDs are not active anymore,
they indicate the completion of the transaction and the status is calculated.
Inactive QH/TDs are removed from the HW chain (since the host controller
already removed the TDs from the QH, no atomic access is needed) and
eventually the URB is marked as completed (OK or errors) and removed from the
pending queue. Then the next linked URB is submitted. After (or immediately
before) that, the completion handler is called.
 
2.4. Unlinking URBs
 
First, all QH/TDs stored in the URB are unlinked from the HW chain.
To ensure that the host controller really left a vertical TD chain, we
wait for one frame. After that, the TDs are physically destroyed.
 
2.5. URB linking and the consequences
 
Since URBs can be linked and the corresponding submit_urb is called in
the UHCI-interrupt, all work associated with URB/QH/TD assembly has to be
interrupt save. This forces kmalloc to use GFP_ATOMIC in the interrupt.
/dc2xx.txt
0,0 → 1,111
14 April 2000
david-b@pacbell.net
 
This is an overview of how to use the "dc2xx" USB driver with certain
digital still cameras from Kodak and other vendors.
 
 
CAMERAS
 
This driver will mostly be used with Kodak DC-2xx series digital still
cameras, but it should be trivial to tell it about several non-Kodak
USB-enabled cameras.
 
You'll most likely want to hook it up to recent versions of "gPhoto"
(www.gphoto.org), since version 0.4 and later know how to use it to talk
to Kodak DC-240 and DC-280 cameras over USB.
 
In addition the DC-220, DC-260, DC-265, and DC-290 are also recognized.
However, like other cameras using the "Digita OS" (from www.flashpoint.com)
there is no gPhoto support for this camera. There is a python script
for accessing these cameras (see archives of the linux-usb mailing list)
and a "Digita Services" library that can also use this driver.
 
The HP PhotoSmart C500 should also work, since it's another Digita camera
with USB support.
 
 
USB HARDWARE
 
Recent kernels have had no particular problems using this driver with
either OHCI or UHCI chipsets, and have worked on the PowerMac platform.
 
Note that in some cases changes in BIOS settings may be needed before
your USB works. At least one user has reported a need for SMP-related
settings as well, and some old hardware may not handle USB correctly.
 
 
SETUP
 
Configure in the DC2XX USB driver, and have it in your kernel. It works
as a module, or compiled in directly.
 
Create at least one device, perhaps like this (both read and write):
 
# mknod -m 0660 /dev/usb/dc2xx0 c 180 80
# mknod -m 0660 /dev/usb/dc2xx1 c 180 81
...
 
NOTE: you would normally configure PAM so that the user logged in at
the console is granted ownership of these devices. console.perms(5)
explains how to do this.
 
The driver supports multiple device nodes. The USB framework supports
a maximum of sixteen device nodes (up to minor device number 96).
 
When you plug in one camera, it will use the first device node (dc2xx0
in the example above). A second camera will use the second device node,
and so on.
 
 
SANITY TESTING
 
First: if you've got /proc support, make sure that the driver has hooked
itself up correctly.
 
- You should see an entry in /proc/bus/usb/drivers for "dc2xx",
if you enabled USB /proc support and correctly mounted the
usbdevfs on /proc/bus/usb.
 
Second: when you connect your camera to the computer, does it get recognized
by the driver? (Make sure the camera is powered on!)
 
- if you've got /proc/bus/usb/devices, you should see an entry
something like this. The "ProdID" may be different if you didn't
plug in a DC-240, as may the strings presented, but "Driver=dc2xx"
had better be there.
 
T: Lev=01 Prnt=00 Port=00 Cnt=01 Dev#= 1 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=040a ProdID=0120 Rev= 1.08
S: Manufacturer=Eastman Kodak Company
S: Product=KODAK DC240 Zoom Digital Camera
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=dc2xx
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
 
- see if "dmesg" output tells you that you plugged in your camera.
 
Manufacturer: Eastman Kodak Company
Product: KODAK DC240 Zoom Digital Camera
dc2xx.c: USB Camera #0 connected
 
Third: (optional) can you use gPhoto to talk to the camera?
 
- When you configure your camera, tell it to use "/dev/usb/dc2xx0"
(or whatever name you used). Right now, gPhoto emits a diagnostic
message (non-GUI) saying that it since it didn't act like a TTY,
it's assuming it's got a USB connection.
 
- With the camera turned on, get the "camera summary". It'll
talk to the camera -- and tell you you're using USB.
 
If you got that far, you should be able to use everything fine.
 
 
ADDITIONAL INFORMATION
 
You may find that you need more driver-specific information, which is
currently accessible through a link from http://www.linux-usb.org/
along with other Linux USB resources.
/scanner.txt
0,0 → 1,335
Copyright (C) 1999, 2000 David E. Nelson <dnelson@jump.net>
Updated 2003 by Henning Meier-Geinitz <henning@meier-geinitz.de>
 
 
OVERVIEW
 
This README addresses issues regarding how to configure the kernel to access a
USB scanner. Although the driver was originally conceived for USB HP
scanners, it's general enough so that it can be used with most other USB
scanners. Also, one can pass the USB Vendor and Product IDs using module
parameters for unknown scanners.
 
There are two drivers for SCSI-over-USB scanners:
* The "hpusbscsi" module for Hewlett-Packard 53xx series, Hewlett-Packard 7400,
Minolta Scan Dual II, Minolta Elite II
* The "microtek" module for the Microtek Scanmaker X6
 
In addition to the kernel driver, user-space tools like SANE are necessary to
actually use the scanner. SANE ("Scanner Access Now Easy") provides drivers
for a variety of USB scanners. See the appropriate SANE man page for details,
e.g. man sane-usb and man sane-hp (for HP scanners).
 
NOTE: Just because a product is detected by this driver 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.
 
 
ADDITIONAL INFORMATION
 
http://www.linux-usb.org/ (General information, mailing lists, links)
http://www.mostang.com/sane/ (SANE user-space tools)
http://www.meier-geinitz.de/kernel/ (USB scanner driver information and patches)
 
 
REQUIREMENTS
 
A host with a USB port. Ideally, either a UHCI (Intel), OHCI (Compaq and
others) or EHCI hardware should work.
 
Using "make menuconfig" or your preferred method for configuring the kernel,
select "Support for USB", "OHCI/UHCI/EHCI" depending on your hardware, "USB
Scanner support", and "Preliminary USB device filesystem". Compile and
install the modules (you may need to execute "depmod -a" to update the module
dependencies). If any of the USB sections were compiled into the kernel, a
reboot is necessary. NOTE: Updating the boot disk with "lilo" may also be
required. Testing was performed only as modules, YMMV.
 
Up to 16 scanners can be connected/used simultaneously. If devfs support is
enabled, see next section. Otherwise, the device files must be created
manually if they don't exist yet, either by MAKEDEV or mknod.
 
MAKEDEV method:
cd /dev
MAKEDEV usb
Check that the device files "/dev/usb/scanner0" - "/dev/usb/scanner15" have
been created.
 
mknod method:
mknod /dev/usb/scanner0 c 180 48
mknod /dev/usb/scanner1 c 180 49
.
.
mknod /dev/usb/scanner15 c 180 63
 
Set appropriate permissions for /dev/usb/scanner[0-15] (don't forget
about group and world permissions). Both read and write permissions
are required for proper operation. For example:
chmod 666 /dev/usb/scanner0
 
Load the appropriate modules (if compiled as modules):
 
modprobe usb-ohci (or uhci, usb-uhci, ehci)
modprobe scanner
 
 
DEVFS
 
The later versions of the Linux kernel (2.4.8'ish) included a dynamic
device filesystem call "devfs". With devfs, there is no need to
create the device files as explained above; instead, they are
dynamically created for you. For USB Scanner, the device is created
in /dev/usb/scannerX where X can range from 0 to 15 depending on the
number of scanners connected to the system.
 
To see if you have devfs, issue the command "cat /proc/filesytems".
If devfs is listed you should be ready to go. You should also have a
process running called "devfsd". In order to make sure, issue the
command "ps aux | grep '[d]evfsd'".
 
 
CONCLUSION
 
That's it. SANE should now be able to access the device. To make sure the
device was detected, use "cat /proc/bus/usb/devices". Your scanner should be
listed and the line starting with "I:" should look similar to this example:
 
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbscanner
 
The important part is "Driver=usbscanner". If it reads "Driver=(none)", the
USB scanner driver didn't recognize the scanner. Have a look at the MODULE
PARAMETERS section for what to do in this case.
 
For more details on the format of "/proc/bus/usb/devices" see
Documentation/usb/proc_usb_info.txt.
 
 
MESSAGES
 
usb_control/bulk_msg: timeout -- On occasions this message will appear
in "/var/adm/messages", on the console, or both depending on how
your system is configured. This is a side effect that scanners are
sometimes very slow at warming up and/or initializing. In most cases,
however, only several of these messages should appear and is generally
considered to be normal.
 
excessive NAK's received -- This message should be considered abnormal
and generally indicates that the USB system is unable to communicate
with the scanner for some particular reason.
 
probe_scanner: Undetected endpoint -- The USB Scanner driver is fairly
general when it comes to communicating to scanners. Unfortunately,
some vendors have designed their scanners in one way or another that
this driver doesn't account for.
 
probe_scanner: Endpoint determination failed -- This means that the
driver is unable to detect a supported configuration for means to
communicate with the scanner. See also "probe_scanner: Undetected
endpoint".
 
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 mailing list (see
CONTACT section for details).
 
 
MODULE PARAMETERS
 
If you have a device that you wish to experiment with or try using
this driver with, but the Vendor and Product IDs 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 IDs. The IDs can be retrieved from the messages file or
using "cat /proc/bus/usb/devices".
 
If the default timeout is too low, i.e. there are frequent "timeout" messages,
you may want to increase the timeout manually by using the parameter
"read_timeout". The time is given in seconds. This is an example for
modules.conf with a timeout of 60 seconds:
 
options scanner read_timeout=60
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.
 
 
BUGS
 
Just look at the list of fixes in the source files.
 
 
CONTACT
 
For asking about problems and fixes, use the linux-usb-users mailing list. For
patches, linux-usb-devel should be used. Information on both lists can be
found on http://www.linux-usb.org/.
 
 
CHANGES
 
- Added information about read_timeout
- Added more details about /proc/bus/usb/devices
- Added/updated links
- Added pointers two "special" scanner drivers
- Reordering, spell-checking, formatting
- Used /dev/usb/scanner[0-15] instead of /dev/usbscanner[0-15]
- Removed some basic USB configuration stuff
- Added EHCI
- Removed some more references to HP
- Amended for linux-2.4.12
- Updated devfs support
- Amended for linux-2.3.99-pre6-3
- 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
- Updated usbdevfs info
- Spellcheck
 
 
HP TEST PROGRAM
 
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.
 
--------------- snip -- hp_scan.c -- snip ---------------
/*
 
This is a really crude attempt at writing a short test program. It's
mostly only to be used to test connectivity with USB HP scanners that
understand SCL. Currently, the supported models are 4100C, 5200C,
6200C, and the 6300C. Note that the 4200C is *NOT* acceptable.
 
Copyright (C) David E. Nelson <dnelson@jump.net>, 1999
 
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.
 
*/
 
#include <stdio.h>
#include <stdlib.h>
#include <error.h>
#include <unistd.h>
#include <fcntl.h>
 
/*
Gray Output produces about a 8945400 byte file.
Color Output produces a 26836200 byte file.
To compile: gcc -o hp_scan hp_scan.c
*/
 
// #define COLOR /* Undef to scan GrayScale */
 
int send_cmd(int, const char *, int);
int read_cmd(int, char *, int);
 
int
main(void) {
 
ssize_t cnt = 0, total_cnt = 0;
 
FILE *fpout;
 
int fp;
int data_size = 32768;
 
char *data;
 
static char reset_cmd[] = {'\x1b','E'};
 
#ifdef COLOR
static char data_type_cmd[] = {'\x1b','*','a','5','T'}; /* Color */
static char data_width_cmd[] = {'\x1b','*','a','2','4','G'}; /* 24 Bit Color */
#else
static char data_type_cmd[] = {'\x1b','*','a','4','T'}; /* Gray */
static char data_width_cmd[] = {'\x1b','*','a','8','G'}; /* 8 Bit Gray */
#endif
 
static char query_cmd[] = {'\x1b', '*', 's', '2', '5', '7', 'E'};
static char start_scan_cmd[] = {'\x1b','*','f','0','S'};
if(!(data=malloc(data_size))) {
perror("malloc failed");
exit (1);
}
if((fp=open("/dev/usb/scanner0", O_RDWR)) < 0) {
perror("Unable to open scanner device");
exit (1);
}
 
if((fpout=fopen("out.dat", "w+")) == NULL) {
perror("Unable to open ouput file");
exit(1);
}
 
send_cmd(fp, reset_cmd, sizeof(reset_cmd));
send_cmd(fp, data_type_cmd, sizeof(data_type_cmd));
send_cmd(fp, data_width_cmd, sizeof(data_width_cmd));
send_cmd(fp, start_scan_cmd, sizeof(start_scan_cmd));
 
while ((cnt = read(fp, data, data_size)) > 0) {
printf("Read: %u\n", cnt);
if(fwrite(data, sizeof(char), cnt, fpout) < 0) {
perror("Write to output file failed");
exit (1);
}
total_cnt += cnt;
}
if (cnt < 0) {
perror("Read from scanner failed");
exit (1);
}
 
printf("\nRead %lu bytes.\n", total_cnt);
 
send_cmd(fp, reset_cmd, sizeof(reset_cmd));
 
close(fp);
fclose(fpout);
return (0);
}
 
int
send_cmd(int fp, const char * cmd, int length) {
 
int result;
int x;
 
if((result = write(fp, cmd, length)) != length) {
printf ("Write warning: %d bytes requested, %d written\n");
} else if (result < 0) {
perror ("send_cmd failure");
exit (1);
}
return (result);
}
int
read_cmd(int fp, char * response, int length) {
 
return read(fp, response, length);
 
}
/rio.txt
0,0 → 1,138
Copyright (C) 1999, 2000 Bruce Tenison
Portions Copyright (C) 1999, 2000 David Nelson
Thanks to David Nelson for guidance and the usage of the scanner.txt
and scanner.c files to model our driver and this informative file.
 
Mar. 2, 2000
 
CHANGES
 
- Initial Revision
 
 
OVERVIEW
 
This README will address issues regarding how to configure the kernel
to access a RIO 500 mp3 player.
Before I explain how to use this to access the Rio500 please be warned:
 
W A R N I N G:
--------------
 
Please note that this software is still under development. The authors
are in no way responsible for any damage that may occur, no matter how
inconsequential.
 
It seems that the Rio has a problem when sending .mp3 with low batteries.
I suggest when the batteries are low and want to transfer stuff that you
replace it with a fresh one. In my case, what happened is I lost two 16kb
blocks (they are no longer usable to store information to it). But I don't
know if thats normal or not. It could simply be a problem with the flash
memory.
 
In an extreme case, I left my Rio playing overnight and the batteries wore
down to nothing and appear to have corrupted the flash memory. My RIO
needed to be replaced as a result. Diamond tech support is aware of the
problem. Do NOT allow your batteries to wear down to nothing before
changing them. It appears RIO 500 firmware does not handle low battery
power well at all.
 
On systems with OHCI controllers, the kernel OHCI code appears to have
power on problems with some chipsets. If you are having problems
connecting to your RIO 500, try turning it on first and then plugging it
into the USB cable.
 
Contact information:
--------------------
 
The main page for the project is hosted at sourceforge.net in the following
address: http://rio500.sourceforge.net You can also go to the sourceforge
project page at: http://sourceforge.net/project/?group_id=1944 There is
also a mailing list: rio500-users@lists.sourceforge.net
 
Authors:
-------
 
Most of the code was written by Cesar Miquel <miquel@df.uba.ar>. Keith
Clayton <kclayton@jps.net> is incharge of the PPC port and making sure
things work there. Bruce Tenison <btenison@dibbs.net> is adding support
for .fon files and also does testing. The program will mostly sure be
re-written and Pete Ikusz along with the rest will re-design it. I would
also like to thank Tri Nguyen <tmn_3022000@hotmail.com> who provided use
with some important information regarding the communication with the Rio.
 
ADDITIONAL INFORMATION and Userspace tools
 
http://rio500.sourceforge.net/
 
 
REQUIREMENTS
 
A host with a USB port. Ideally, either a UHCI (Intel) or OHCI
(Compaq and others) hardware port should work.
 
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
more information on accomplishing this.
 
A Linux kernel with RIO 500 support enabled.
 
'lspci' which is only needed to determine the type of USB hardware
available in your machine.
 
CONFIGURATION
 
Using `lspci -v`, determine the type of USB hardware available.
 
If you see something like:
 
USB Controller: ......
Flags: .....
I/O ports at ....
 
Then you have a UHCI based controller.
 
If you see something like:
 
USB Controller: .....
Flags: ....
Memory at .....
 
Then you have a OHCI based controller.
 
Using `make menuconfig` or your preferred method for configuring the
kernel, select 'Support for USB', 'OHCI/UHCI' depending on your
hardware (determined from the steps above), 'USB Diamond Rio500 support', and
'Preliminary USB device filesystem'. Compile and install the modules
(you may need to execute `depmod -a` to update the module
dependencies).
 
Add a device for the USB rio500:
`mknod /dev/usb/rio500 c 180 64`
 
Set appropriate permissions for /dev/usb/rio500 (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):
 
OHCI:
modprobe usbcore
modprobe usb-ohci
modprobe rio500
 
UHCI:
modprobe usbcore
modprobe usb-uhci (or uhci)
modprobe rio500
 
That's it. The Rio500 Utils at: http://rio500.sourceforge.net should
be able to access the rio500.
 
BUGS
 
If you encounter any problems feel free to drop me an email.
 
Bruce Tenison
btenison@dibbs.net
 
/se401.txt
0,0 → 1,54
Linux driver for SE401 based USB cameras
 
Copyright, 2001, Jeroen Vreeken
 
 
INTRODUCTION:
 
The SE401 chip is the used in low-cost usb webcams.
It is produced by Endpoints Inc. (www.endpoints.com).
It interfaces directly to a cmos image sensor and USB. The only other major
part in a se401 based camera is a dram chip.
 
The following cameras are known to work with this driver:
 
Aox se401 (non-branded) cameras
Philips PVCV665 USB VGA webcam 'Vesta Fun'
Kensington VideoCAM PC Camera Model 67014
Kensington VideoCAM PC Camera Model 67015
Kensington VideoCAM PC Camera Model 67016
Kensington VideoCAM PC Camera Model 67017
 
 
WHAT YOU NEED:
 
- USB support
- VIDEO4LINUX support
 
More information about USB support for linux can be found at:
http://www.linux-usb.org
 
 
MODULE OPTIONS:
 
When the driver is compiled as a module you can also use the 'flickerless'
option. With it exposure is limited to values that do not interfere with the
net frequency. Valid options for this option are 0, 50 and 60. (0=disable,
50=50hz, 60=60hz)
 
 
KNOWN PROBLEMS:
 
The driver works fine with the usb-ohci and uhci host controller drivers,
the default settings also work with usb-uhci. But sending more then one bulk
transfer at a time with usb-uhci doesn't work yet.
Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in
order to increase the throughput (and thus framerate).
 
 
HELP:
 
The latest info on this driver can be found at:
http://www.chello.nl/~j.vreeken/se401/
And questions to me can be send to:
pe1rxq@amsat.org
/acm.txt
0,0 → 1,138
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.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.