Menu
▾
▴
[LV-kern-commit] CVS: kernel-2.4/Documentation/usb hiddev.txt,NONE,1.1 philips.txt,NONE,1.1 se401.txt,NONE,1.1 CREDITS,1.1.1.1,1.2 error-codes.txt,1.1.1.1,1.2 hotplug.txt,1.1.1.2,1.2 scanner.txt,1.1.1.1,1.2 uhci.txt,1.1.1.2,1.2 usb-serial.txt,1.1.1.2,1.2 input.txt,1.1.1.1,NONE
|
From: Andy P. <at...@us...> - 2002-04-09 16:55:53
|
Update of /cvsroot/linux-vax/kernel-2.4/Documentation/usb
In directory usw-pr-cvs1:/tmp/cvs-serv7449/usb
Modified Files:
CREDITS error-codes.txt hotplug.txt scanner.txt uhci.txt
usb-serial.txt
Added Files:
hiddev.txt philips.txt se401.txt
Removed Files:
input.txt
Log Message:
synch 2.4.15 commit 28
--- NEW FILE ---
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.
--- NEW FILE ---
This file contains some additional information for the Philips webcams.
E-mail: we...@sm... Last updated: 2001-07-27
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.
(Taken from install.html)
When you load the module you can set some default settings for the
camera; some programs depend on a particular image-size or -format. 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.
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.
--- NEW FILE ---
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:
pe...@am...
Index: CREDITS
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/usb/CREDITS,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- CREDITS 14 Jan 2001 20:06:45 -0000 1.1.1.1
+++ CREDITS 9 Apr 2002 16:55:47 -0000 1.2
@@ -8,7 +8,7 @@
David Brownell <dbr...@us...>
Alan Cox <al...@lx...>
Randy Dunlap <ran...@in...>
- Johannes Erdfelt <jer...@sv...>
+ Johannes Erdfelt <joh...@er...>
Deti Fliegl <de...@fl...>
ham <ha...@un...>
Bradley M Keryan <ke...@an...>
Index: error-codes.txt
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/usb/error-codes.txt,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- error-codes.txt 14 Jan 2001 20:06:49 -0000 1.1.1.1
+++ error-codes.txt 9 Apr 2002 16:55:47 -0000 1.2
@@ -79,8 +79,7 @@
-EILSEQ CRC mismatch
USB_ST_STALL
--EPIPE a) babble detect
- b) endpoint stalled
+-EPIPE endpoint stalled
USB_ST_BUFFEROVERRUN
-ECOMM During an IN transfer, the host controller
@@ -95,7 +94,7 @@
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
+ endpoint or the remaining buffer size. "Babble".
USB_ST_DATAUNDERRUN
-EREMOTEIO The endpoint returned less than max packet size
Index: hotplug.txt
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/usb/hotplug.txt,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- hotplug.txt 25 Feb 2001 23:15:25 -0000 1.1.1.2
+++ hotplug.txt 9 Apr 2002 16:55:47 -0000 1.2
@@ -69,7 +69,10 @@
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.
+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
@@ -85,14 +88,26 @@
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.
+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 = {
- { idVendor: 0x9999, idProduct 0xaaaa, driver_info: QUIRK_X },
- { idVendor: 0xbbbb, idProduct 0x8888, driver_info: QUIRK_Y|QUIRK_Z },
+ { USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X },
+ { USB_DEVICE (0xbbbb, 0x8888), driver_info: QUIRK_Y|QUIRK_Z },
...
{ } /* end with an all-zeroes entry */
}
Index: scanner.txt
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/usb/scanner.txt,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- scanner.txt 14 Jan 2001 20:06:54 -0000 1.1.1.1
+++ scanner.txt 9 Apr 2002 16:55:47 -0000 1.2
@@ -1,9 +1,11 @@
-Copyright (C) 1999, 2000 David E. Nelson
+Copyright (C) 1999, 2000 David E. Nelson <dn...@ju...>
April 26, 2000
CHANGES
+- 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
@@ -35,11 +37,9 @@
(Compaq and others) hardware port should work. At the time of this
writing, there are two UHCI drivers and one OHCI.
-A Linux development kernel (2.3.x) with USB support enabled or a
-backported version to linux-2.2.x. See http://www.linux-usb.org for
-more information on accomplishing this.
-
-A Linux kernel with USB Scanner support enabled.
+A Linux kernel with USB support enabled or a backported version to
+linux-2.2.x. See http://www.linux-usb.org for more information on
+accomplishing this.
'lspci' which is only needed to determine the type of USB hardware
available/installed in your machine.
@@ -75,15 +75,15 @@
YMMV.
Beginning with version 0.4 of the driver, up to 16 scanners can be
-connected/used simultaneously. If you intend to use more than
-one scanner at a time:
+connected/used simultaneously. For devfs support, see next section.
+If you intend to use more than one scanner at a time w/o devfs support:
Add a device for the USB scanner:
`mknod /dev/usbscanner0 c 180 48`
`mknod /dev/usbscanner1 c 180 49`
.
.
- `mknod /dev/usb/scanner15 180 63`
+ `mknod /dev/usbscanner15 180 63`
If you foresee using only one scanner it is best to:
@@ -106,6 +106,32 @@
modprobe usb-uhci
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 sould also have a
+process running called 'devfsd'. In order to make sure, issue the
+command `ps aux | grep '[d]evfsd'`.
+
+If you would like to maintain /dev/usbscanner0 in order to maintain
+compatibility with applications, then add the following to
+/etc/devfsd.conf:
+
+REGISTER ^usb/scanner0$ CFUNCTION GLOBAL symlink usb/scanner0 usbscanner0
+UNREGISTER ^usb/scanner0$ CFUNCTION GLOBAL unlink usbscanner0
+
+Then reset the scanner (reseat the USB connector or power cycle). This
+will create the necessary symlinks in /dev to /dev/usb.
+
+CONCLUSION
+
That's it. SANE should now be able to access the device.
There is a small test program (hp_scan.c -- appended below) that can
@@ -121,15 +147,34 @@
MESSAGES
-On occasions the message 'usb_control/bulk_msg: timeout' or something
-similar will appear in '/var/adm/messages' or 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. If you see
-a message of the type 'excessive NAK's received' then this should
-be considered abnormal and generally indicates that the USB system is
-unable to communicate with the scanner for some particular reason.
+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 maintaner listed at the
+top of this file.
SUPPORTED SCANNERS
Index: uhci.txt
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/usb/uhci.txt,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
Index: usb-serial.txt
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/usb/usb-serial.txt,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- usb-serial.txt 25 Feb 2001 23:15:25 -0000 1.1.1.2
+++ usb-serial.txt 9 Apr 2002 16:55:47 -0000 1.2
@@ -44,28 +44,33 @@
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.
+ 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 gr...@kr...
-HandSpring Visor USB docking station
-
-Current status:
- Only when the Visor tries to connect to the host, does the docking
- station show up as a valid USB device. When this happens, the device is
+
+HandSpring Visor, Palm USB, and Clié USB driver
+
+ This driver works with all HandSpring USB, Palm USB, and Sony Clié USB
+ 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 Visor.
+ the connection is canceled on the device.
NOTE:
- This means that in order to talk to the Visor, the sync button must be
- pressed BEFORE trying to get any program to communicate to the Visor.
+ 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 Visor.
+ 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
@@ -73,37 +78,49 @@
the port to use for the HotSync transfer. The "Generic" port can be used
for other device communication, such as a PPP link.
+ For some Sony Clié devices, /dev/ttyUSB0 must be used to talk to the
+ 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 Visor, first a hot reset, and then a cold reset if
- necessary. Some Visors need this before they can talk to the USB port
+ 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.
- There is a webpage and mailing lists for this portion of the driver at:
+ 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 gr...@kr...
+
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()
-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 wa...@lo...
Keyspan USA-series Serial Adapters
@@ -111,19 +128,22 @@
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.
+ 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://www.linuxcare.com.au/hugh/keyspan.html
+ http://misc.nu/hugh/keyspan.html
+ For any questions or problems with this driver, please contact Hugh
+ Blemings at hu...@mi...
+
FTDI Single Port Serial Driver
@@ -131,6 +151,9 @@
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 br...@sg...
+
ZyXEL omni.net lcd plus ISDN TA
@@ -162,67 +185,123 @@
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.
+ 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 :)
-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 wgr...@sm...
-Empeg empeg-car Mark I/II Driver (empeg.c)
+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)
- The driver is still pretty new, so some testing 'in the wild' would be
- helpful. :)
+ For any questions or problems with this driver, please contact Gary
+ Brubaker at xa...@ix...
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.
+ 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 wol...@ce...
+
+
+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 gr...@kr...
+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 (lin...@si...).
+
+ For any questions or problems with this driver, please contact
+ lin...@si...
+
+
+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 gr...@kr...
+
+
Generic Serial driver
If your device is not one of the above listed devices, compatible with
@@ -242,13 +321,17 @@
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 gr...@kr...
+
CONTACT:
- If anyone has any problems using this driver, with any of the above
- specified products, 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/ )
+ 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
--- input.txt DELETED ---
|
