summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/Configure.help102
-rw-r--r--Documentation/fb/00-INDEX11
-rw-r--r--Documentation/i386/boot.txt394
-rw-r--r--Documentation/joystick-api.txt4
-rw-r--r--Documentation/joystick.txt2
-rw-r--r--Documentation/usb/ov511.txt21
-rw-r--r--Documentation/usb/usb-serial.txt23
-rw-r--r--Documentation/video4linux/bttv/CARDLIST4
-rw-r--r--Documentation/video4linux/bttv/CONTRIBUTORS2
-rw-r--r--Documentation/video4linux/bttv/Insmod-options17
10 files changed, 560 insertions, 20 deletions
diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index 8a1b4ad9b..8c765fd52 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -11297,6 +11297,20 @@ CONFIG_NCPFS_EXTRAS
To use the new attributes, it is recommended to use the flags
'-f 600 -d 755' on the ncpmount command line.
+nls default codepage
+CONFIG_NLS_DEFAULT
+ The default NLS used when mounting filesystem. Currently, the valid
+ values are:
+ big5, cp437, cp737, cp775, cp850, cp852, cp855, cp857, cp860, cp861,
+ cp862, cp863, cp864, cp865, cp866, cp869, cp874, cp932, cp936,
+ cp949, cp950, euc-jp, euc-kr, gb2312, iso8859-1, iso8859-2, iso8859-3,
+ iso8859-4, iso8859-5, iso8859-6, iso8859-7, iso8859-8, iso8859-9,
+ iso8859-14, iso8859-15, koi8-r, sjis
+ If you specify a wrong value, it will use the built-in NLS; compatible
+ with iso8859-1.
+
+ If unsure, specify it as "iso8859-1".
+
nls codepage 437
CONFIG_NLS_CODEPAGE_437
The Microsoft FAT file system family can deal with filenames in
@@ -11472,6 +11486,50 @@ CONFIG_NLS_CODEPAGE_874
only, not to the file contents. You can include several codepages;
say Y here if you want to include the DOS codepage for Thai.
+nls codepage 932
+CONFIG_NLS_CODEPAGE_932
+ The Microsoft fat filesystem family can deal with filenames in
+ native language character sets. These character sets are stored in
+ so-called DOS codepages. You need to include the appropriate
+ codepage if you want to be able to read/write these filenames on
+ DOS/Windows partitions correctly. This does apply to the filenames
+ only, not to the file contents. You can include several codepages;
+ say Y here if you want to include the DOS codepage for Shift-JIS
+ or EUC-JP. To use EUC-JP, you can use 'euc-jp' as mount option or
+ NLS Default value during kernel configuration , instead of 'cp932'
+
+nls codepage 936
+CONFIG_NLS_CODEPAGE_936
+ The Microsoft fat filesystem family can deal with filenames in
+ native language character sets. These character sets are stored in
+ so-called DOS codepages. You need to include the appropriate
+ codepage if you want to be able to read/write these filenames on
+ DOS/Windows partitions correctly. This does apply to the filenames
+ only, not to the file contents. You can include several codepages;
+ say Y here if you want to include the DOS codepage for Simplified
+ Chinese(GBK).
+
+nls codepage 949
+CONFIG_NLS_CODEPAGE_949
+ The Microsoft fat filesystem family can deal with filenames in
+ native language character sets. These character sets are stored in
+ so-called DOS codepages. You need to include the appropriate
+ codepage if you want to be able to read/write these filenames on
+ DOS/Windows partitions correctly. This does apply to the filenames
+ only, not to the file contents. You can include several codepages;
+ say Y here if you want to include the DOS codepage for UHC.
+
+nls codepage 950
+CONFIG_NLS_CODEPAGE_950
+ The Microsoft fat filesystem family can deal with filenames in
+ native language character sets. These character sets are stored in
+ so-called DOS codepages. You need to include the appropriate
+ codepage if you want to be able to read/write these filenames on
+ DOS/Windows partitions correctly. This does apply to the filenames
+ only, not to the file contents. You can include several codepages;
+ say Y here if you want to include the DOS codepage for Traditional
+ Chinese(Big5).
+
nls iso8859-1
CONFIG_NLS_ISO8859_1
If you want to display filenames with native language characters
@@ -15707,15 +15765,51 @@ CONFIG_SA1100_ASSABET
Say Y here if you are using the Intel(R) StrongARM(R) SA-1110
Microprocessor Development Board (also known as the Assabet).
-Include support for the Compaq iPAQ 3600
+Include support for Neponset
+CONFIG_ASSABET_NEPONSET
+ Say Y here if you are using the Intel(R) StrongARM(R) SA-1110
+ Microprocessor Development Board (Assabet) with the SA-1111
+ Development Board (Nepon).
+
+Include support for the Compaq iPAQ H3600 (Bitsy)
CONFIG_SA1100_BITSY
- Say Y here if you intend to run this kernel on the Compaq iPAQ 3600
- handheld computer. Information about this machine and the Linux
- port to this machine can be found at:
+ Say Y here if you intend to run this kernel on the Compaq iPAQ
+ H3600 handheld computer. Information about this machine and the
+ Linux port to this machine can be found at:
http://www.handhelds.org/Compaq/index.html#iPAQ_H3600
http://www.compaq.com/products/handhelds/pocketpc/
+Include support for Brutus
+CONFIG_SA1100_BRUTUS
+ Say Y here if you are using the Intel(R) StrongARM(R) SA-1100
+ Microprocessor Development Board (also known as the Brutus).
+
+Include support for LART
+CONFIG_SA1100_LART
+ Say Y here if you are using the Linux Advanced Radio Terminal
+ (also known as the LART). See http://www.lart.tudelft.nl/ for
+ information on the LART.
+
+Include support for ThinClient
+CONFIG_SA1100_THINCLIENT
+ Say Y here if you are using an Applied Data Systems Intel(R)
+ StrongARM(R) SA-1100 based Thin Client SBC. See
+ http://www.flatpanels.com/ for information on this system.
+
+Include support for GraphicsClient
+CONFIG_SA1100_GRAPHICSCLIENT
+ Say Y here if you are using an Applied Data Systems Intel(R)
+ StrongARM(R) SA-1100 based Graphics Client SBC. See
+ http://www.flatpanels.com/ for information on this system.
+
+Include support for Victor
+CONFIG_SA1100_VICTOR
+ Say Y here if you are using a Visu Aide Intel(R) StrongARM(R)
+ SA-1100 based Victor Digital Talking Book Reader. See
+ http://www.visuaide.com/pagevictor.en.html for information on
+ this system.
+
Math emulation
CONFIG_NWFPE
Say Y to include the NWFPE floating point emulator in the kernel.
diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX
index 32b2e760e..54bb5161c 100644
--- a/Documentation/fb/00-INDEX
+++ b/Documentation/fb/00-INDEX
@@ -9,6 +9,15 @@ framebuffer.txt
- introduction to frame buffer devices
internals.txt
- quick overview of frame buffer device internals
+modedb.txt
+ - info on the video mode database
+aty128fb.txt
+ - info on the ATI Rage128 frame buffer driver
+clgenfb.txt
+ - info on the Cirrus Logic frame buffer driver
+matroxfb.txt
+ - info on the Matrox frame buffer driver
+tgafb.txt
+ - info on the TGA (DECChip 21030) frame buffer driver
vesafb.txt
- info on the VESA frame buffer device
-
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
new file mode 100644
index 000000000..1622e4af3
--- /dev/null
+++ b/Documentation/i386/boot.txt
@@ -0,0 +1,394 @@
+ THE LINUX/I386 BOOT PROTOCOL
+ ----------------------------
+
+ H. Peter Anvin <hpa@zytor.com>
+ Updated as of protocol version 2.02
+
+On the i386 platform, the Linux kernel uses a rather complicated boot
+convention. This has evolved partially due to historical aspects, as
+well as the desire in the early days to have the kernel itself be a
+bootable image, the complicated PC memory model and due to changed
+expectations in the PC industry caused by the effective demise of
+real-mode DOS as a mainstream operating system.
+
+Currently, four versions of the Linux/i386 boot protocol exist.
+
+Old kernels: zImage/Image support only. Some very early kernels
+ may not even support a command line.
+
+Protocol 2.00: (Kernel 1.3.73) Added bzImage and initrd support, as
+ well as a formalized way to communicate between the
+ boot loader and the kernel. setup.S made relocatable,
+ although the traditional setup area still assumed
+ writable.
+
+Protocol 2.01: (Kernel 1.3.76) Added a heap overrun warning.
+
+Protocol 2.02: (Kernel 2.4.0-test3-pre3) New command line protocol.
+ Lower the conventional memory ceiling. No overwrite
+ of the traditional setup area, thus making booting
+ safe for systems which use the EBDA from SMM or 32-bit
+ BIOS entry points. zImage deprecated but still
+ supported.
+
+
+**** MEMORY LAYOUT
+
+The traditional memory map for the kernel loader, used for Image or
+zImage kernels, typically looks like:
+
+ | |
+0A0000 +------------------------+
+ | Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
+09A000 +------------------------+
+ | Stack/heap/cmdline | For use by the kernel real-mode code.
+098000 +------------------------+
+ | Kernel setup | The kernel real-mode code.
+090200 +------------------------+
+ | Kernel boot sector | The kernel legacy boot sector.
+090000 +------------------------+
+ | Protected-mode kernel | The bulk of the kernel image.
+010000 +------------------------+
+ | Boot loader | <- Boot sector entry point 0000:7C00
+001000 +------------------------+
+ | Reserved for MBR/BIOS |
+000800 +------------------------+
+ | Typically used by MBR |
+000600 +------------------------+
+ | BIOS use only |
+000000 +------------------------+
+
+
+When using bzImage, the protected-mode kernel was relocated to
+0x100000 ("high memory"), and the kernel real-mode block (boot sector,
+setup, and stack/heap) was made relocatable to any address between
+0x10000 and end of low memory. Unfortunately, in protocols 2.00 and
+2.01 the command line is still required to live in the 0x9XXXX memory
+range, and that memory range is still overwritten by the early kernel.
+The 2.02 protocol fixes that.
+
+It is desirable to keep the "memory ceiling" -- the highest point in
+low memory touched by the boot loader -- as low as possible, since
+some newer BIOSes have begun to allocate some rather large amounts of
+memory, called the Extended BIOS Data Area, near the top of low
+memory. The boot loader should use the "INT 12h" BIOS call to verify
+how much low memory is available.
+
+Unfortunately, if INT 12h reports that the amount of memory is too
+low, there is usually nothing the boot loader can do but to report an
+error to the user. The boot loader should therefore be designed to
+take up as little space in low memory as it reasonably can. For
+zImage or old bzImage kernels, which need data written into the
+0x90000 segment, the boot loader should make sure not to use memory
+above the 0x9A000 point; too many BIOSes will break above that point.
+
+
+**** THE REAL-MODE KERNEL HEADER
+
+In the following text, and anywhere in the kernel boot sequence, "a
+sector" refers to 512 bytes. It is independent of the actual sector
+size of the underlying medium.
+
+The first step in loading a Linux kernel should be to load the
+real-mode code (boot sector and setup code) and then examine the
+following header at offset 0x01f1. The real-mode code can total up to
+32K, although the boot loader may choose to load only the first two
+sectors (1K) and then examine the bootup sector size.
+
+The header looks like:
+
+Offset Proto Name Meaning
+Size
+
+01F1/1 ALL setup_sects The size of the setup in sectors
+01F2/2 ALL root_flags If set, the root is mounted readonly
+01F4/2 ALL syssize DO NOT USE - for bootsect.S use only
+01F6/2 ALL swap_dev DO NOT USE - obsolete
+01F8/2 ALL ram_size DO NOT USE - for bootsect.S use only
+01FA/2 ALL vid_mode Video mode control
+01FC/2 ALL root_dev Default root device number
+01FE/2 ALL boot_flag 0xAA55 magic number
+0200/2 2.00+ jump Jump instruction
+0202/4 2.00+ header Magic signature "HdrS"
+0206/2 2.00+ version Boot protocol version supported
+0208/4 2.00+ realmode_swtch Boot loader hook (see below)
+020C/4 2.00+ start_sys Points to kernel version string
+0210/1 2.00+ type_of_loader Boot loader identifier
+0211/1 2.00+ loadflags Boot protocol option flags
+0212/2 2.00+ setup_move_size Move to high memory size (used with hooks)
+0214/4 2.00+ code32_start Boot loader hook (see below)
+0218/4 2.00+ ramdisk_image initrd load address (set by boot loader)
+021C/4 2.00+ ramdisk_size initrd size (set by boot loader)
+0220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only
+0224/4 2.01+ heap_end_ptr Free memory after setup end
+0226/2 N/A pad1 Unused
+0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line
+
+For backwards compatibility, if the setup_sects field contains 0, the
+real value is 4.
+
+If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
+the boot protocol version is "old". Loading an old kernel, the
+following parameters should be assumed:
+
+ Image type = zImage
+ initrd not supported
+ Real-mode kernel must be located at 0x90000.
+
+Otherwise, the "version" field contains the protocol version,
+e.g. protocol version 2.01 will contain 0x0201 in this field. When
+setting fields in the header, you must make sure only to set fields
+supported by the protocol version in use.
+
+Most boot loaders will simply load the kernel at its target address
+directly. Such boot loaders do not need to worry about filling in
+most of the fields in the header. The following fields should be
+filled out, however:
+
+ type_of_loader:
+ If your boot loader has an identifier assigned in
+ arch/i386/boot/setup.S, enter that value. Otherwise, enter
+ 0xFF here.
+
+ loadflags, heap_end_ptr:
+ If the protocol version is 2.01 or higher, enter the
+ offset limit of the setup heap into heap_end_ptr and set the
+ 0x80 bit (CAN_USE_HEAP) of loadflags. heap_end_ptr appears to
+ be relative to the start of setup (offset 0x0200).
+
+ setup_move_size:
+ When using protocol 2.00 or 2.01, if the real mode
+ kernel is not loaded at 0x90000, it gets moved there later in
+ the loading sequence. Fill in this field if you want
+ additional data (such as the kernel command line) moved in
+ addition to the real-mode kernel itself.
+
+ ramdisk_image, ramdisk_size:
+ If your boot loader has loaded an initial ramdisk (initrd),
+ set ramdisk_image to the 32-bit pointer to the ramdisk data
+ and the ramdisk_size to the size of the ramdisk data.
+
+ The initrd should typically be located as high in memory as
+ possible, as it may otherwise get overwritten by the early
+ kernel initialization sequence. However, it must never be
+ located above address 0x3C000000 if you want all kernels to
+ read it.
+
+ cmd_line_ptr:
+ If the protocol version is 2.02 or higher, this is a 32-bit
+ pointer to the kernel command line. The kernel command line
+ can be located anywhere between the end of setup and 0xA0000.
+ Fill in this field even if your boot loader does not support a
+ command line, in which case you can point this to an empty
+ string (or better yet, to the string "auto".) If this field
+ is left at zero, the kernel will assume that your boot loader
+ does not support the 2.02 protocol.
+
+
+**** THE KERNEL COMMAND LINE
+
+The kernel command line has become an important way for the boot
+loader to communicate with the kernel. Some of its options are also
+relevant to the boot loader itself, see "special command line options"
+below.
+
+The kernel command line is a null-terminated string up to 255
+characters long, plus the final null.
+
+If the boot protocol version is 2.02 or later, the address of the
+kernel command line is given by the header field cmd_line_ptr (see
+above.)
+
+If the protocol version is *not* 2.02 or higher, the kernel
+command line is entered using the following protocol:
+
+ At offset 0x0020 (word), "cmd_line_magic", enter the magic
+ number 0xA33F.
+
+ At offset 0x0022 (word), "cmd_line_offset", enter the offset
+ of the kernel command line (relative to the start of the
+ real-mode kernel).
+
+ The kernel command line *must* be within the memory region
+ covered by setup_move_size, so you may need to adjust this
+ field.
+
+
+**** SAMPLE BOOT CONFIGURATION
+
+As a sample configuration, assume the following layout of the real
+mode segment:
+
+ 0x0000-0x7FFF Real mode kernel
+ 0x8000-0x8FFF Stack and heap
+ 0x9000-0x90FF Kernel command line
+
+Such a boot loader should enter the following fields in the header:
+
+ unsigned long base_ptr; /* base address for real-mode segment */
+
+ if ( setup_sects == 0 ) {
+ setup_sects = 4;
+ }
+
+ if ( protocol >= 0x0200 ) {
+ type_of_loader = <type code>;
+ if ( loading_initrd ) {
+ ramdisk_image = <initrd_address>;
+ ramdisk_size = <initrd_size>;
+ }
+ if ( protocol >= 0x0201 ) {
+ heap_end_ptr = 0x9000 - 0x200;
+ loadflags |= 0x80; /* CAN_USE_HEAP */
+ }
+ if ( protocol >= 0x0202 ) {
+ cmd_line_ptr = base_ptr + 0x9000;
+ } else {
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = 0x9000;
+ setup_move_size = 0x9100;
+ }
+ } else {
+ /* Very old kernel */
+
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = 0x9000;
+
+ /* A very old kernel MUST have its real-mode code
+ loaded at 0x90000 */
+
+ if ( base_ptr != 0x90000 ) {
+ /* Copy the real-mode kernel */
+ memcpy(0x90000, base_ptr, (setup_sects+1)*512);
+ /* Copy the command line */
+ memcpy(0x99000, base_ptr+0x9000, 256);
+
+ base_ptr = 0x90000; /* Relocated */
+ }
+
+ /* It is recommended to clear memory up to the 32K mark */
+ memset(0x90000 + (setup_sects-1)*512, 0,
+ (64-setup_sects-1)*512);
+ }
+
+
+**** LOADING THE REST OF THE KERNEL
+
+The non-real-mode kernel starts at offset (setup_sects+1)*512 in the
+kernel file (again, if setup_sects == 0 the real value is 4.) It
+should be loaded at address 0x10000 for Image/zImage kernels and
+0x100000 for bzImage kernels.
+
+The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01
+bit (LOAD_HIGH) in the loadflags field is set:
+
+ is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
+ load_address = is_bzImage ? 0x100000 : 0x10000;
+
+Note that Image/zImage kernels can be up to 512K in size, and thus use
+the entire 0x10000-0x90000 range of memory. This means it is pretty
+much a requirement for these kernels to load the real-mode part at
+0x90000. bzImage kernels allow much more flexibility.
+
+
+**** SPECIAL COMMAND LINE OPTIONS
+
+If the command line provided by the boot loader is entered by the
+user, the user may expect the following command line options to work.
+They should normally not be deleted from the kernel command line even
+though not all of them are actually meaningful to the kernel.
+
+ vga=<mode>
+ <mode> here is either an integer (in C notation, either
+ decimal, octal, or hexadecimal) or one of the strings
+ "normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
+ (meaning 0xFFFD). This value should be entered into the
+ vid_mode field, as it is used by the kernel before the command
+ line is parsed.
+
+ mem=<size>
+ <size> is an integer in C notation optionally followed by K, M
+ or G (meaning << 10, << 20 or << 30). This specifies to the
+ kernel the memory size. This affects the possible placement
+ of an initrd, since an initrd should be placed near end of
+ memory.
+
+ initrd=<file>
+ An initrd should be loaded. The meaning of <file> is
+ obviously bootloader-dependent.
+
+In addition, some boot loaders add the following options to the
+user-specified command line:
+
+ BOOT_IMAGE=<file>
+ The boot image which was loaded. Again, the meaning of <file>
+ is obviously bootloader-dependent.
+
+ auto
+ The kernel was booted without explicit user intervention.
+
+If these options are added by the boot loader, it is highly
+recommended that they are located *first*, before the user-specified
+or configuration-specified command line. Otherwise, "init=/bin/sh"
+gets confused by the "auto" option.
+
+
+**** RUNNING THE KERNEL
+
+The kernel is started by jumping to the kernel entry point, which is
+located at *segment* offset 0x20 from the start of the real mode
+kernel. This means that if you loaded your real-mode kernel code at
+0x90000, the kernel entry point is 9020:0000.
+
+At entry, ds = es = ss = fs = gs should point to the start of the
+real-mode kernel code (0x9000 if the code is loaded at 0x90000), and
+sp should be set up properly, normally pointing to the top of the
+heap. In our example from above, we would do:
+
+ /* Note: in the case of the "old" kernel protocol, base_ptr must
+ be == 0x90000 at this point; see the previous sample code */
+
+ seg = base_ptr >> 4;
+
+ cli(); /* Enter with interrupts disabled! */
+
+ /* Set up the real-mode kernel stack */
+ _SS = seg;
+ _SP = 0x9000; /* Load SP right after loading SS! */
+
+ _DS = _ES = _FS = _GS = seg;
+ jmp_far(seg+0x20, 0); /* Run the kernel */
+
+If your boot sector accesses a floppy drive, it is recommended to
+switch off the floppy motor before running the kernel, since the
+kernel boot leaves interrupts off and thus the motor will not be
+switched off, especially if the loaded kernel has the floppy driver as
+a demand-loaded module!
+
+
+**** ADVANCED BOOT TIME HOOKS
+
+If the boot loader runs in a particularly hostile environment (such as
+LOADLIN, which runs under DOS) it may be impossible to follow the
+standard memory location requirements. Such a boot loader may use the
+following hooks that, if set, are invoked by the kernel at the
+appropriate time. The use of these hooks should probably be
+considered an absolutely last resort!
+
+IMPORTANT: All the hooks are required to preserve %ebp, %esi and %edi
+across invocation.
+
+ realmode_swtch:
+ A 16-bit real mode far subroutine invoked immediately before
+ entering protected mode. The default routine disables NMI, so
+ your routine should probably do so, too.
+
+ code32_start:
+ A 32-bit flat-mode routine *jumped* to immediately after the
+ transition to protected mode, but before the kernel is
+ uncompressed. No segments, except CS, are set up; you should
+ set them up to KERNEL_DS (0x18) yourself.
+
+ After completing your hook, you should jump to the address
+ that was in this field before your boot loader overwrote it.
+
diff --git a/Documentation/joystick-api.txt b/Documentation/joystick-api.txt
index 622c67d17..b3a0c20c7 100644
--- a/Documentation/joystick-api.txt
+++ b/Documentation/joystick-api.txt
@@ -1,7 +1,7 @@
Joystick API Documentation -*-Text-*-
- Ragnar Hojland Espinosa
- <ragnar@lightside.dhis.org>
+ Ragnar Hojland Espinosa
+ <ragnar@macula.net>
7 Aug 1998
diff --git a/Documentation/joystick.txt b/Documentation/joystick.txt
index 4e53bd281..18fc52232 100644
--- a/Documentation/joystick.txt
+++ b/Documentation/joystick.txt
@@ -565,7 +565,7 @@ to the joystick driver development:
Benji York <benji@cookeville.com>
Leslie F. Donaldson <donaldlf@cs.rose-hulman.edu>
Eng-Jon Ong <ongej@dcs.qmw.ac.uk>
- Ragnar Hojland Espinosa <ragnar@lightside.ddns.org>
+ Ragnar Hojland Espinosa <ragnar@macula.net>
Brian Gerst <bgerst@quark.vpplus.com>
Andree Borrmann <a.borrmann@tu-bs.de>
Martin Giguere <zefrench@hotmail.com>
diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt
index 4380ed791..bd519ec07 100644
--- a/Documentation/usb/ov511.txt
+++ b/Documentation/usb/ov511.txt
@@ -176,6 +176,26 @@ MODULE PARAMETERS:
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: buf_timeout
+ TYPE: integer
+ DEFAULT: 5 (seconds)
+ DESC: Number of seconds before unused frame buffers are deallocated.
+ Previously, memory was allocated upon open() and deallocated upon
+ close(). Deallocation now occurs only if the driver is closed and this
+ timeout is reached. If you are capturing frames less frequently than
+ the default timeout, increase this. This will not make any difference
+ with programs that capture multiple frames during an open/close cycle.
+
+ 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.
+
+
WORKING FEATURES:
o Color streaming/capture at 640x480, 448x336, 384x288, 352x288, and 320x240
o YUV420 and YUV422P color
@@ -210,7 +230,6 @@ TODO:
o Get rid of the memory management functions (put them in videodev.c??)
o Setting of contrast and brightness not working with 7620
o Driver/camera state save/restore for when USB supports suspend/resume
- o Multiple cameras reportedly do not work simultaneously
o Unstable on SMP systems
HOW TO CONTACT ME:
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 00248f36e..b5b30911b 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -47,8 +47,8 @@ ConnectTech WhiteHEAT 4 port converter
Current status:
The device's firmware is downloaded on connection, the new firmware
runs properly and all four ports are successfuly recognized and connected.
- Now data flow needs to be implemented properly.
- This driver is not fully operational.
+ Data can be sent and received through the device on all ports.
+ Hardware flow control needs to be implemented.
HandSpring Visor USB docking station
@@ -101,6 +101,25 @@ Current status:
O_NONBLOCK, select()
+Keyspan USA-series Serial Adapters
+
+ Single and Dual port adapters - driver uses Keyspan supplied
+ firmware and is being developed with their support.
+
+ Driver isn't as far advanced as Keyspan PDA driver mentioned above.
+
+Current status:
+ Things that work:
+ Firmware upload for USA-18X, USA-28, USA-28X, USA-19 and USA-19W
+ Simple character I/O fixed at 9600 baud on USA-19 only
+
+ Things that don't:
+ Everything else. (for now...)
+
+ Big Things on the todo list:
+ Driver is in infancy, much functionality remains to be added
+
+
FTDI Single Port Serial Driver
This is a single port DB-25 serial adapter. More information about this
diff --git a/Documentation/video4linux/bttv/CARDLIST b/Documentation/video4linux/bttv/CARDLIST
index 28f11aeac..0d36761d1 100644
--- a/Documentation/video4linux/bttv/CARDLIST
+++ b/Documentation/video4linux/bttv/CARDLIST
@@ -44,6 +44,10 @@ bttv.o
card=42 - ProVideo PV951
card=43 - Little OnAir TV
card=44 - Sigma TVII-FM
+ card=45 - MATRIX-Vision MV-Delta 2
+ card=46 - Zoltrix Genie TV
+ card=47 - Terratec TV/Radio+
+ card=48 - Dynalink Magic TView
tuner.o
type=0 - Temic PAL
diff --git a/Documentation/video4linux/bttv/CONTRIBUTORS b/Documentation/video4linux/bttv/CONTRIBUTORS
index 1ee99f6f5..aef49db88 100644
--- a/Documentation/video4linux/bttv/CONTRIBUTORS
+++ b/Documentation/video4linux/bttv/CONTRIBUTORS
@@ -13,7 +13,7 @@ Gerd Knorr <kraxel@cs.tu-berlin.de>
Radio card (ITT sound processor)
bigfoot <bigfoot@net-way.net>
-Ragnar Hojland Espinosa <ragnar@lightside.dhis.org>
+Ragnar Hojland Espinosa <ragnar@macula.net>
ConferenceTV card
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options
index b6d4c5a6c..68818a532 100644
--- a/Documentation/video4linux/bttv/Insmod-options
+++ b/Documentation/video4linux/bttv/Insmod-options
@@ -10,8 +10,8 @@ bttv.o
1: 28 MHz crystal installed
2: 35 MHz crystal installed
triton1=0/1 for Triton1 compatibility
- Triton1 is automatically recognized
- but this might also help with other chipsets
+ Triton1 is automatically recognized
+ but this might also help with other chipsets
bigendian=n Set the endianness of the gfx framebuffer.
Default is native endian.
fieldnr=0/1 Count fields. Some TV descrambling software
@@ -19,14 +19,14 @@ bttv.o
50 useless IRQs/sec. default is 0 (off).
autoload=0/1 autoload helper modules (tuner, audio).
default is 1 (on).
- verbose=0/1/2 verbose level (at insmod time, while looking at
- the hardware). default is 1.
- debug=0/1 debug messages (for capture).
+ bttv_verbose=0/1/2 verbose level (at insmod time, while looking
+ at the hardware). default is 1.
+ bttv_debug=0/1 debug messages (for capture).
default is 0 (off).
gbuffers=2-64 number of capture buffers for mmap'ed capture.
default is 2.
- gbufsize=n size of capture buffers. default and
- maximum value is 0x208000 (~2MB)
+ gbufsize= size of capture buffers. default and
+ maximum value is 0x208000 (~2MB)
remap, card, radio and pll accept up to four comma-separated arguments
(for multiple boards).
@@ -63,7 +63,8 @@ msp3400.o
2 is more verbose.
simple=1 Use the "short programming" method. Newer
msp34xx versions support this. You need this
- for dbx stereo.
+ for dbx stereo. Default is on if supported by
+ the chip.
once=1 Don't check the TV-stations Audio mode
every few seconds, but only once after
channel switches.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 22:52:21 +0000