aiptek

NAME

aiptek - Aiptek USB Digital Tablet Input Driver for Linux  

SYNOPSIS

Section N`34`InputDeviceN`34` Identifier N`34`idevnameN`34` Driver N`34`aiptekN`34` Option N`34`DeviceN`34` N`34`devpathN`34`   ... EndSection

 

DESCRIPTION

aiptek is an Xorg input driver for Aiptek HyperPen USB-based tablet devices. This driver only supports the USB protocol, and only under Linux; for RS-232C-based HyperPens, please see the "hyperpen" driver.

The aiptek driver functions as a pointer input device, and may be used as the X server`s core pointer.  

SUPPORTED HARDWARE

This driver supports the Aiptek HyperPen 4000U, 5000U, 6000U, 8000U and 12000U USB-based input tablet on some Linux platforms.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

Multiple instances of the Aiptek devices can cohabit. It can be useful to define multiple devices with different active zones. Each device supports the following entries:

Option Type stylus|eraser|cursor

sets the type of tool the device represent. This option is mandatory.

Option Device path

sets the path to the special file which represents serial line where the tablet is plugged. You have to specify it for each subsection with the same value if you want to have multiple devices with the same tablet. This option is mandatory.

Option USB on

specifies that you are using the USB bus to communicate with your tablet. This setting is mandatory, as USB is the only protocol supported by this driver.

Option DeviceName name

sets the name of the X device.

Option Mode Relative|Absolute

sets the mode of the device.

Option HistorySize number

sets the motion history size. By default the value is zero.

Option AlwaysCore on

enables the sharing of the core pointer. When this feature is enabled, the device will take control of the core pointer (and thus will emit core events) and at the same time will be able, when asked so, to report extended events. You can use the last available integer feedback to control this feature. When the value of the feedback is zero, the feature is disabled. The feature is enabled for any other value.

Option XTop number

First of three sets of parameters to set the active zone. This sets the X coordinate of the top corner of the active zone. "TopX" is a synonym.

Option YTop number

First of three sets of parameters to set the active zone. This sets the Y coordinate of the top corner of the active zone. "TopY" is a synonym.

Option XBottom Inumber

First of three sets of parameters to set the active zone. This sets the X coordinate of the bottom corner of the active zone. "BottomX" is a synonym.

Option YBottom number

First of three sets of parameters to set the active zone. This sets the Y coordinate of the bottom corner of the active zone. "BottomY" is a synonym.

Option XMax number

Second of three sets of parameters to set the active zone. This sets the the X coordinate of the bottom corner of the active zone. The Top X corner`s coordinate is fixed at 0. "MaxX" is a synomyn.

Option YMax number

Second of three sets of parameters to set the active zone. This sets the the Y coordinate of the bottom corner of the active zone. The Top Y corner`s coordinate is fixed at 0. "MaxY" is a synomyn.

Option XOffset number

Third of three sets of parameters to set the active zone. This sets the X coordinate of the top corner of the active zone. "OffsetX" is a synomyn.

Option YOffset number

Third of three sets of parameters to set the active zone. This sets the Y coordinate of the top corner of the active zone. "OffsetY" is a synomyn.

Option XSize number

Third of three sets of parameters to set the active zone. This sets the X coordinate of the bottom corner of the active zone. Unlike others, this parameter is expressed in relative coordinates from the "XOffset" parameter. "XSize" is a synomyn.

Option YSize number

Third of three sets of parameters to set the active zone. This sets the Y coordinate of the bottom corner of the active zone. Unlike others, this parameter is expressed in relative coordinates from the "YOffset" parameter. "YSize" is a synomyn.

Option ZMin number

Minimum pressure reading that will be accepted from the Stylus tool. "MinZ" is a synomyn.

Option ZMax number

Maximum pressure reading that will be accepted from the Stylus tool. "MaxZ" is a synomyn.

Option XThreshold number

Minimal change in X coordinate position that will be accepted as data input. "ThresholdX" is a synomyn.

Option YThreshold number

Minimal change in Y coordinate position that will be accepted as data input. "ThresholdY" is a synomyn.

Option ZThreshold number

Minimal change in pressure reading that will be accepted as data input. "ThresholdZ" is a synomyn.

Option InvX on

Inverts X coordinate reports. "XInv" is a synomyn.

Option InvY on

Inverts Y coordinate reports. "YInv" is a synomyn.

Option Pressure soft|hard|linear

Pressure reports either delivered in linearly incremental values (default), or perturbed by one of two log-linear algorithms ("soft" or "hard".)

Option KeepShape on

When this option is enabled, the active zone begins according to TopX and TopY. The bottom corner is adjusted to keep the ratio width/height of the active zone the same as the screen while maximizing the area described by the active area set of parameters, XTop/YTop/XBottom/YBottom, XMax/YMax, or XOffset/YOffset/XSize/YSize.

Option DebugLevel number

sets the level of debugging info reported.

This driver is currently Linux specific.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x), hyperpen(4x).  

AUTHORS

Bryan W. Headley <bheadley@earthlink.net>  

PROJECT PAGE

http://aiptektablet.sourceforge.net tracks ongoing development of this driver, the Linux kernel driver, and a GUI front-end application that works in concert with the above.

atalk

NAME

atalk - AppleTalk protocol family  

SYNOPSIS

#include <sys/types.h>
#include <netatalk/at.h>  

DESCRIPTION

The AppleTalk protocol family is a collection of protocols layered above the Datagram Delivery Protocol (DDP), and using AppleTalk address format. The AppleTalk family may provide SOCK_STREAM (ADSP), SOCK_DGRAM (DDP), SOCK_RDM (ATP), and SOCK_SEQPACKET (ASP). Currently, only DDP is implemented in the kernel; ATP and ASP are implemented in user level libraries; and ADSP is planned.  

ADDRESSING

AppleTalk addresses are three byte quantities, stored in network byte order. The include file <netatalk/at.h> defines the AppleTalk address format.

Sockets in the AppleTalk protocol family use the following address structure:

struct sockaddr_at { short sat_family; u_char sat_port; struct at_addr sat_addr; char sat_zero[ 8 ]; };

The port of a socket may be set with bind(2). The node for bind must always be ATADDR_ANYNODE: ``this node.`` The net may be ATADDR_ANYNET or ATADDR_LATENET. ATADDR_ANYNET coresponds to the machine`s ``primary`` address (the first configured). ATADDR_LATENET causes the address in outgoing packets to be determined when a packet is sent, i.e. determined late. ATADDR_LATENET is equivalent to opening one socket for each network interface. The port of a socket and either the primary address or ATADDR_LATENET are returned with getsockname(2).  

SEE ALSO

bind(2), getsockname(2), atalkd(8).

cirrus

NAME

cirrus - Cirrus Logic video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`cirrusN`34`   ... EndSection

 

DESCRIPTION

cirrus is an Xorg driver for Cirrus Logic video chips. THIS MAN PAGE NEEDS TO BE FILLED IN.  

SUPPORTED HARDWARE

The cirrus driver supports...  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: ...

console

NAME

console - console terminal and virtual consoles  

DESCRIPTION

A Linux system has up to 63 virtual consoles (character devices with major number 4 and minor number 1 to 63), usually called /dev/ttyn with 1 < n < 63. The current console is also addressed by /dev/console or /dev/tty0, the character device with major number 4 and minor number 0. The device files /dev/* are usually created using the script MAKEDEV, or using mknod(1), usually with mode 0622 and owner root.tty.

Before kernel version 1.1.54 the number of virtual consoles was compiled into the kernel (in tty.h: #define NR_CONSOLES 8) and could be changed by editing and recompiling. Since version 1.1.54 virtual consoles are created on the fly, as soon as they are needed.

Common ways to start a process on a console are: (a) tell init(8) (in inittab(5)) to start a getty(8) on the console; (b) ask openvt(1) to start a process on the console; (c) start X - it will find the first unused console, and display its output there. (There is also the ancient doshell(8).)

Common ways to switch consoles are: (a) use Alt+Fn or Ctrl+Alt+Fn to switch to console n; AltGr+Fn might bring you to console n+12 [here Alt and AltGr refer to the left and right Alt keys, respectively]; (b) use Alt+RightArrow or Alt+LeftArrow to cycle through the presently allocated consoles; (c) use the program chvt(1). (The key mapping is user settable, see loadkeys(1); the above mentioned key combinations are according to the default settings.)

The command deallocvt(1) (formerly disalloc) will free the memory taken by the screen buffers for consoles that no longer have any associated process.

 

PROPERTIES

Consoles carry a lot of state. I hope to document that some other time. The most important fact is that the consoles simulate vt100 terminals. In particular, a console is reset to the initial state by printing the two characters ESC c. All escape sequences can be found in console_codes(4).

 

FILES

/dev/console
/dev/tty*  

SEE ALSO

chvt(1), deallocvt(1), loadkeys(1), mknod(1), openvt(1), console_codes(4), console_ioctl(4), tty(4), ttys(4), charsets(7), getty(8), init(8), mapscrn(8), resizecons(8), setfont(8)

console_ioctl

NAME

console ioctl - ioctl`s for console terminal and virtual consoles  

DESCRIPTION

The following Linux-peculiar ioctl() requests are supported. Each requires a third argument, assumed here to be argp.

KDGETLED

Get state of LEDs. argp points to a long int. The lower three bits of *argp are set to the state of the LEDs, as follows:

    LED_CAP       0x04   caps lock led
    LEC_NUM       0x02   num lock led
    LED_SCR       0x01   scroll lock led

KDSETLED

Set the LEDs. The LEDs are set to correspond to the lower three bits of argp. However, if a higher order bit is set, the LEDs revert to normal: displaying the state of the keyboard functions of caps lock, num lock, and scroll lock.

Before 1.1.54, the LEDs just reflected the state of the corresponding keyboard flags, and KDGETLED/KDSETLED would also change the keyboard flags. Since 1.1.54 the leds can be made to display arbitrary information, but by default they display the keyboard flags. The following two ioctl`s are used to access the keyboard flags.

KDGKBLED

Get keyboard flags CapsLock, NumLock, ScrollLock (not lights). argp points to a char which is set to the flag state. The low order three bits (mask 0x7) get the current flag state, and the low order bits of the next nibble (mask 0x70) get the default flag state. (Since 1.1.54.)

KDSKBLED

Set keyboard flags CapsLock, NumLock, ScrollLock (not lights). argp has the desired flag state. The low order three bits (mask 0x7) have the flag state, and the low order bits of the next nibble (mask 0x70) have the default flag state. (Since 1.1.54.)

KDGKBTYPE

Get keyboard type. This returns the value KB_101, defined as 0x02.

KDADDIO

Add I/O port as valid. Equivalent to ioperm(arg,1,1).

KDDELIO

Delete I/O port as valid. Equivalent to ioperm(arg,1,0).

KDENABIO

Enable I/O to video board. Equivalent to ioperm(0x3b4, 0x3df-0x3b4+1, 1).

KDDISABIO

Disable I/O to video board. Equivalent to ioperm(0x3b4, 0x3df-0x3b4+1, 0).

KDSETMODE

Set text/graphics mode. argp is one of these:

    KD_TEXT       0x00
    KD_GRAPHICS   0x01

KDGETMODE

Get text/graphics mode. argp points to a long which is set to one of the above values.

KDMKTONE

Generate tone of specified length. The lower 16 bits of argp specify the period in clock cycles, and the upper 16 bits give the duration in msec. If the duration is zero, the sound is turned off. Control returns immediately. For example, argp = (125<<16) + 0x637 would specify the beep normally associated with a ctrl-G. (Thus since 0.99pl1; broken in 2.1.49-50.)

KIOCSOUND

Start or stop sound generation. The lower 16 bits of argp specify the period in clock cycles (that is, argp = 1193180/frequency). argp = 0 turns sound off. In either case, control returns immediately.

GIO_CMAP

Get the current default colour map from kernel. argp points to a 48-byte array. (Since 1.3.3.)

PIO_CMAP

Change the default text-mode colour map. argp points to a 48-byte array which contains, in order, the Red, Green, and Blue values for the 16 available screen colours: 0 is off, and 255 is full intensity. The default colours are, in order: black, dark red, dark green, brown, dark blue, dark purple, dark cyan, light grey, dark grey, bright red, bright green, yellow, bright blue, bright purple, bright cyan and white. (Since 1.3.3.)

GIO_FONT

Gets 256-character screen font in expanded form. argp points to an 8192 byte array. Fails with error code EINVAL if the currently loaded font is a 512-character font, or if the console is not in text mode.

GIO_FONTX

Gets screen font and associated information. argp points to a struct consolefontdesc (see PIO_FONTX). On call, the charcount field should be set to the maximum number of characters that would fit in the buffer pointed to by chardata. On return, the charcount and charheight are filled with the respective data for the currently loaded font, and the chardata array contains the font data if the initial value of charcount indicated enough space was available; otherwise the buffer is untouched and errno is set to ENOMEM. (Since 1.3.1.)

PIO_FONT

Sets 256-character screen font. Load font into the EGA/VGA character generator. argp points to a 8192 byte map, with 32 bytes per character. Only first N of them are used for an 8xN font (0 < N <= 32). This call also invalidates the Unicode mapping.

PIO_FONTX

Sets screen font and associated rendering information. argp points to a

struct consolefontdesc { u_short charcount; /* characters in font (256 or 512) */ u_short charheight; /* scan lines per character (1-32) */ char *chardata; /* font data in expanded form */ };

If necessary, the screen will be appropriately resized, and SIGWINCH sent to the appropriate processes. This call also invalidates the Unicode mapping. (Since 1.3.1.)

PIO_FONTRESET

Resets the screen font, size and Unicode mapping to the bootup defaults. argp is unused, but should be set to NULL to ensure compatibility with future versions of Linux. (Since 1.3.28.)

GIO_SCRNMAP

Get screen mapping from kernel. argp points to an area of size E_TABSZ, which is loaded with the font positions used to display each character. This call is likely to return useless information if the currently loaded font is more than 256 characters.

GIO_UNISCRNMAP

Get full Unicode screen mapping from kernel. argp points to an area of size E_TABSZ*sizeof(unsigned short), which is loaded with the Unicodes each character represent. A special set of Unicodes, starting at U+F000, are used to represent ``direct to font`` mappings. (Since 1.3.1.)

PIO_SCRNMAP

Loads the ``user definable`` (fourth) table in the kernel which maps bytes into console screen symbols. argp points to an area of size E_TABSZ.

PIO_UNISCRNMAP

Loads the ``user definable`` (fourth) table in the kernel which maps bytes into Unicodes, which are then translated into screen symbols according to the currently loaded Unicode-to-font map. Special Unicodes starting at U+F000 can be used to map directly to the font symbols. (Since 1.3.1.)

GIO_UNIMAP

Get Unicode-to-font mapping from kernel. argp points to a

struct unimapdesc { u_short entry_ct; struct unipair *entries; };

where entries points to an array of

struct unipair { u_short unicode; u_short fontpos; };

(Since 1.1.92.)

PIO_UNIMAP

Put unicode-to-font mapping in kernel. argp points to a struct unimapdesc. (Since 1.1.92)

PIO_UNIMAPCLR

Clear table, possibly advise hash algorithm. argp points to a

struct unimapinit { u_short advised_hashsize; /* 0 if no opinion */ u_short advised_hashstep; /* 0 if no opinion */ u_short advised_hashlevel; /* 0 if no opinion */ };

(Since 1.1.92.)

KDGKBMODE

Gets current keyboard mode. argp points to a long which is set to one of these:

    K_RAW         0x00   
    K_XLATE       0x01   
    K_MEDIUMRAW   0x02   
    K_UNICODE     0x03

KDSKBMODE

Sets current keyboard mode. argp is a long equal to one of the above values.

KDGKBMETA

Gets meta key handling mode. argp points to a long which is set to one of these:

    K_METABIT     0x03   set high order bit 
    K_ESCPREFIX   0x04   escape prefix

KDSKBMETA

Sets meta key handling mode. argp is a long equal to one of the above values.

KDGKBENT

Gets one entry in key translation table (keycode to action code). argp points to a

struct kbentry { u_char kb_table; u_char kb_index; u_short kb_value; };

with the first two members filled in: kb_table selects the key table (0 <= kb_table < MAX_NR_KEYMAPS), and kb_index is the keycode (0 <= kb_index < NR_KEYS). kb_value is set to the corresponding action code, or K_HOLE if there is no such key, or K_NOSUCHMAP if kb_table is invalid.

KDSKBENT

Sets one entry in translation table. argp points to a struct kbentry.

KDGKBSENT

Gets one function key string. argp points to a

struct kbsentry { u_char kb_func; u_char kb_string[512]; };

kb_string is set to the (NULL terminated) string corresponding to the kb_functh function key action code.

KDSKBSENT

Sets one function key string entry. argp points to a struct kbsentry.

KDGKBDIACR

Read kernel accent table. argp points to a

struct kbdiacrs { unsigned int kb_cnt; struct kbdiacr kbdiacr[256]; };

where kb_cnt is the number of entries in the array, each of which is a

struct kbdiacr { u_char diacr, base, result; };

KDGETKEYCODE

Read kernel keycode table entry (scan code to keycode). argp points to a

struct kbkeycode { unsigned int scancode, keycode; };

keycode is set to correspond to the given scancode. (89 <= scancode <= 255 only. For 1 <= scancode <= 88, keycode==scancode.) (Since 1.1.63.)

KDSETKEYCODE

Write kernel keycode table entry. argp points to struct kbkeycode. (Since 1.1.63.)

KDSIGACCEPT

The calling process indicates its willingness to accept the signal argp when it is generated by pressing an appropriate key combination. (1 <= argp <= NSIG). (See spawn_console() in linux/drivers/char/keyboard.c.)

VT_OPENQRY

Returns the first available (non-opened) console. argp points to an int which is set to the number of the vt (1 <= *argp <= MAX_NR_CONSOLES).

VT_GETMODE

Get mode of active vt. argp points to a

struct vt_mode { char mode; /* vt mode */ char waitv; /* if set, hang on writes if not active */ short relsig; /* signal to raise on release req */ short acqsig; /* signal to raise on acquisition */ short frsig; /* unused (set to 0) */ };

mode is set to one of these values:

    VT_AUTO       auto vt switching 
    VT_PROCESS    process controls switching 
    VT_ACKACQ     acknowledge switch 

VT_SETMODE

Set mode of active vt. argp points to a struct vt_mode.

VT_GETSTATE

Get global vt state info. argp points to a

struct vt_stat { ushort v_active; /* active vt */ ushort v_signal; /* signal to send */ ushort v_state; /* vt bitmask */ };

For each vt in use, the corresponding bit in the v_state member is set. (Kernels 1.0 through 1.1.92.)

VT_RELDISP

Release a display.

VT_ACTIVATE

Switch to vt argp (1 <= argp <= MAX_NR_CONSOLES).

VT_WAITACTIVE

Wait until vt argp has been activated.

VT_DISALLOCATE

Deallocate the memory associated with vt argp. (Since 1.1.54.)

VT_RESIZE

Set the kernel`s idea of screensize. argp points to a

struct vt_sizes { ushort v_rows; /* # rows */ ushort v_cols; /* # columns */ ushort v_scrollsize; /* no longer used */ };

Note that this does not change the videomode. See resizecons(8). (Since 1.1.54.)

VT_RESIZEX

Set the kernel`s idea of various screen parameters. argp points to a

struct vt_consize { ushort v_rows; /* number of rows */ ushort v_cols; /* number of columns */ ushort v_vlin; /* number of pixel rows on screen */ ushort v_clin; /* number of pixel rows per character */ ushort v_vcol; /* number of pixel columns on screen */ ushort v_ccol; /* number of pixel columns per character */ };

Any parameter may be set to zero, indicating ``no change``, but if multiple parameters are set, they must be self-consistent. Note that this does not change the videomode. See resizecons(8). (Since 1.3.3.)

The action of the following ioctls depends on the first byte in the struct pointed to by argp, referred to here as the subcode. These are legal only for the superuser or the owner of the current tty.

TIOCLINUX, subcode=0

Dump the screen. Disappeared in 1.1.92. (With kernel 1.1.92 or later, read from /dev/vcsN or /dev/vcsaN instead.)

TIOCLINUX, subcode=1

Get task information. Disappeared in 1.1.92.

TIOCLINUX, subcode=2

Set selection. argp points to a

   struct {char subcode;
       short xs, ys, xe, ye;
       short sel_mode;
   }

xs and ys are the starting column and row. xe and ye are the ending column and row. (Upper left corner is row=column=1.) sel_mode is 0 for character-by-character selection, 1 for word-by-word selection, or 2 for line-by-line selection. The indicated screen characters are highlighted and saved in the static array sel_buffer in devices/char/console.c.

TIOCLINUX, subcode=3

Paste selection. The characters in the selection buffer are written to fd.

TIOCLINUX, subcode=4

Unblank the screen.

TIOCLINUX, subcode=5

Sets contents of a 256-bit look up table defining characters in a "word", for word-by-word selection. (Since 1.1.32.)

TIOCLINUX, subcode=6

argp points to a char which is set to the value of the kernel variable shift_state. (Since 1.1.32.)

TIOCLINUX, subcode=7

argp points to a char which is set to the value of the kernel variable report_mouse. (Since 1.1.33.)

TIOCLINUX, subcode=8

Dump screen width and height, cursor position, and all the character-attribute pairs. (Kernels 1.1.67 through 1.1.91 only. With kernel 1.1.92 or later, read from /dev/vcsa* instead.)

TIOCLINUX, subcode=9

Restore screen width and height, cursor position, and all the character-attribute pairs. (Kernels 1.1.67 through 1.1.91 only. With kernel 1.1.92 or later, write to /dev/vcsa* instead.)

TIOCLINUX, subcode=10

Handles the Power Saving feature of the new generation of monitors. VESA screen blanking mode is set to argp[1], which governs what screen blanking does:

    0: Screen blanking is disabled.

    1: The current video adapter register settings are saved, then the controller is programmed to turn off the vertical synchronization pulses. This puts the monitor into "standby" mode. If your monitor has an Off_Mode timer, then it will eventually power down by itself.

    2: The current  settings are saved, then both the vertical and horizontal synchronization pulses are turned off. This puts the monitor into "off" mode. If your monitor has no Off_Mode timer, or if you want your monitor to power down immediately when the blank_timer times out, then you choose this option. (Caution: Powering down frequently will damage the monitor.)

(Since 1.1.76.)

 

RETURN VALUE

On success, 0 is returned. On error -1 is returned, and errno is set.  

ERRORS

errno may take on these values:

EBADF

file descriptor is invalid.

ENOTTY

file descriptor is not associated with a character special device, or the specified request does not apply to it.

EINVAL

file descriptor or argp is invalid.

EPERM

permission violation.

 

WARNING

Do not regard this man page as documentation of the Linux console ioctl`s. This is provided for the curious only, as an alternative to reading the source. Ioctl`s are undocumented Linux internals, liable to be changed without warning. (And indeed, this page more or less describes the situation as of kernel version 1.1.94; there are many minor and not-so-minor differences with earlier versions.)
  Very often, ioctl`s are introduced for communication between the kernel and one particular well-known program (fdisk, hdparm, setserial, tunelp, loadkeys, selection, setfont, etc.), and their behavior will be changed when required by this particular program.

Programs using these ioctl`s will not be portable to other versions of Unix, will not work on older versions of Linux, and will not work on future versions of Linux.

Use POSIX functions.

 

SEE ALSO

kbd_mode(1), loadkeys(1), dumpkeys(1), mknod(1), setleds(1), setmetamode(1), ioperm(2), execve(2), fcntl(2), termios(3), console(4), console_codes(4), mt(4), sd(4), tty(4), ttys(4), tty_ioctl(4), vcs(4), vcsa(4), charsets(7), mapscrn(8), setfont(8), resizecons(8), /usr/include/linux/kd.h, /usr/include/linux/vt.h

dmc

NAME

dmc - DMC input driver  

SYNOPSIS

Section N`34`InputDeviceN`34`
Identifier N`34`idevnameN`34`
Driver N`34`dmcN`34`
Option N`34`DeviceN`34` N`34`devpathN`34`
  ...
EndSection  

DESCRIPTION

dmc is an Xorg input driver for DMC FIT10-controller...

The dmc driver functions as a pointer input device, and may be used as the X server`s core pointer. THIS MAN PAGE NEEDS TO BE FILLED IN.  

SUPPORTED HARDWARE

What is supported...  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

Config details...  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

Authors include...

dynapro

NAME

dynapro - Dynapro input driver  

SYNOPSIS

Section N`34`InputDeviceN`34` Identifier N`34`idevnameN`34` Driver N`34`dynaproN`34` Option N`34`DeviceN`34` N`34`devpathN`34`   ... EndSection

 

DESCRIPTION

dynapro is an Xorg input driver for Dynapro devices...

The dynapro driver functions as a pointer input device, and may be used as the X server`s core pointer. THIS MAN PAGE NEEDS TO BE FILLED IN.  

SUPPORTED HARDWARE

What is supported...  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

Config details...  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

Authors include...

english

NAME

english - flag format for English okspell dictionaries  

DESCRIPTION

English dictionaries for okspell(1) supports 3 prefix and 14 suffix flags. For a detailed description of how okspell handles flags and capitalization, see okspell(4). This manual page only describes flags usable in dictionaries built using the english.aff affix file.

In the following discussion of the flags, let # and @ be "variables" that can stand for any letter. Upper case letters are constants. "..." stands for any string of zero or more letters, but note that no word may exist in the dictionary which is not at least 2 letters long, so, for example, "fly" may not be produced by placing the "Y" flag on "f". Also, no flag is effective unless the word that it creates is at least 4 letters long, so, for example, "wed" may not be produced by placing the "D" flag on "we".

In the following list, an asterisk indicates that a flag participates in cross-product formation (see okspell(4)).

The meaning of the prefix flags is as follows:

*A

... --> re... as in cover --> recover

*I

... --> in... as in firm --> infirm

*U

... --> un... as in able --> unable

The meaning of the suffix flags is as follows:

V

...e --> ...ive as in create --> creative

if # .ne. e, ...# --> ...#ive as in prevent --> preventive

*N

...e --> ...ion as in create --> creation

...y --> ...ication as in multiply --> multiplication

if # .ne. e or y, ...# --> ...#en as in fall --> fallen

*X

...e --> ...ions as in create --> creations

...y --> ...ications as in multiply --> multiplications

if # .ne. e or y, ...# --> ...#ens as in weak --> weakens

H

...y --> ...ieth as in twenty --> twentieth

if # .ne. y, ...# --> ...#th as in hundred --> hundredth

*Y

... --> ...ly as in quick --> quickly

*G

...e --> ...ing as in file --> filing

if # .ne. e, ...# --> ...#ing as in cross --> crossing

*J

...e --> ...ings as in file --> filings

if # .ne. e, ...# --> ...#ings as in cross --> crossings

*D

...e --> ...ed as in create --> created



if @ .ne. a, e, i, o, or u, ...@y --> ...@ied as in imply --> implied

if # .ne. e or y, or (# = y and @ = a, e, i, o, or u) ...@# --> ...@#ed as in cross --> crossed or convey --> conveyed

T

...e --> ...est as in late --> latest

if @ .ne. a, e, i, o, or u, ...@y --> ...@iest as in dirty --> dirtiest

if # .ne. e or y, or (# = y and @ = a, e, i, o, or u) ...@# --> ...@#est as in small --> smallest or gray --> grayest

*R

...e --> ...er as in skate --> skater

if @ .ne. a, e, i, o, or u, ...@y --> ...@ier as in multiply --> multiplier

if # .ne. e or y, or (# = y and @ = a, e, i, o, or u) ...@# --> ...@#er as in build --> builder or convey --> conveyer

*Z

...e --> ...ers as in skate --> skaters

if @ .ne. a, e, i, o, or u, ...@y --> ...@iers as in multiply --> multipliers

if # .ne. e or y, or (# = y and @ = a, e, i, o, or u) ...@# --> ...@#ers as in build --> builders or slay --> slayers

*S

if @ .ne. a, e, i, o, or u, ...@y --> ...@ies as in imply --> implies

if # .eq. s, x, z, or h, ...# --> ...#es as in fix --> fixes

if # .ne. s, x, z, h, or y, or (# = y and @ = a, e, i, o, or u) ...@# --> ...@#s as in bat --> bats or convey --> conveys
if @ .ne. a, e, i, o, or u, ...@y --> ...@iness as in cloudy --> cloudiness

if # .ne. y, or @ = a, e, i, o, or u, ...@# --> ...@#ness as in late --> lateness or gray --> grayness

*M

... --> ...`s as in dog --> dog`s

To summarize more briefly:

Prefixes:

*A - re *I - in *U - un

Suffixes:

V - ive *N - ion, tion, en *X - ions, ications, ens H - th, ieth *Y - ly *G - ing *J - ings *D - ed T - est *R - er *Z - ers *S - s, es, ies *P - ness, iness *M - `s

 

SEE ALSO

okspell(1), okspell(4)

fbdev

NAME

fbdev - video driver for framebuffer device  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`fbdevN`34` BusID N`34`pci:bus:dev:funcN`34`   ... EndSection

 

DESCRIPTION

fbdev is an Xorg driver for framebuffer devices. This is a non-accelerated driver, the following framebuffer depths are supported: 8, 15, 16, 24. All visual types are supported for depth 8, and TrueColor visual is supported for the other depths. Multi-head configurations are supported.  

SUPPORTED HARDWARE

The fbdev driver supports all hardware where a framebuffer driver is available. fbdev uses the os-specific submodule fbdevhw(4x) to talk to the kernel device driver. Currently a fbdevhw module is available for linux.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

For this driver it is not required to specify modes in the screen section of the config file. The fbdev driver can pick up the currently used video mode from the framebuffer driver and will use it if there are no video modes configured.

For PCI boards you might have to add a BusID line to the Device section. See above for a sample line. You can use N`34`Xorg -scanpciN`34` to figure out the correct values.

The following driver Options are supported:

Option N`34`fbdevN`34` N`34`stringN`34`

The framebuffer device to use. Default: /dev/fb0.

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. Default: on.

Option N`34`RotateN`34` N`34`stringN`34`

Enable rotation of the display. The supported values are "CW" (clockwise, 90 degrees), "UD" (upside down, 180 degrees) and "CCW" (counter clockwise, 270 degrees). Implies use of the shadow framebuffer layer. Default: off.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x), fbdevhw(4x)  

AUTHORS

Authors include: Gerd Knorr, Michel Dänzer, Geert Uytterhoeven

fd

NAME

fd - floppy disk device  

CONFIGURATION

Floppy drives are block devices with major number 2. Typically they are owned by root.floppy (i.e., user root, group floppy) and have either mode 0660 (access checking via group membership) or mode 0666 (everybody has access). The minor numbers encode the device type, drive number, and controller number. For each device type (that is, combination of density and track count) there is a base minor number. To this base number, add the drive`s number on its controller and 128 if the drive is on the secondary controller. In the following device tables, n represents the drive number.

Warning: If you use formats with more tracks than supported by your drive, you may cause it mechanical damage. Trying once if more tracks than the usual 40/80 are supported should not damage it, but no warranty is given for that. Don`t create device entries for those formats to prevent their usage if you are not sure.

Drive independent device files which automatically detect the media format and capacity:

Name	Base minor #
fdn	0

5.25 inch double density device files:

Name	Capac.	Cyl.	Sect.	Heads	Base minor #
fdnd360	360K	40	9	2	4

5.25 inch high density device files:

Name	Capac.	Cyl.	Sect.	Heads	Base minor #
fdnh360	360K	40	9	2	20
fdnh410	410K	41	10	2	48
fdnh420	420K	42	10	2	64
fdnh720	720K	80	9	2	24
fdnh880	880K	80	11	2	80
fdnh1200	1200K	80	15	2	8
fdnh1440	1440K	80	18	2	40
fdnh1476	1476K	82	18	2	56
fdnh1494	1494K	83	18	2	72
fdnh1600	1600K	80	20	2	92

3.5 inch double density device files:

Name	Capac.	Cyl.	Sect.	Heads	Base minor #
fdnD360	360K	80	9	1	12
fdnD720	720K	80	9	2	16
fdnD800	800K	80	10	2	120
fdnD1040	1040K	80	13	2	84
fdnD1120	1120K	80	14	2	88

3.5 inch high density device files:

Name	Capac.	Cyl.	Sect.	Heads	Base minor #
fdnH360	360K	40	9	2	12
fdnH720	720K	80	9	2	16
fdnH820	820K	82	10	2	52
fdnH830	830K	83	10	2	68
fdnH1440	1440K	80	18	2	28
fdnH1600	1600K	80	20	2	124
fdnH1680	1680K	80	21	2	44
fdnH1722	1722K	82	21	2	60
fdnH1743	1743K	83	21	2	76
fdnH1760	1760K	80	22	2	96
fdnH1840	1840K	80	23	2	116
fdnH1920	1920K	80	24	2	100

3.5 inch extra density device files:

Name	Capac.	Cyl.	Sect.	Heads	Base minor #
fdnE2880	2880K	80	36	2	32
fdnCompaQ	2880K	80	36	2	36
fdnE3200	3200K	80	40	2	104
fdnE3520	3520K	80	44	2	108
fdnE3840	3840K	80	48	2	112

 

DESCRIPTION

fd special files access the floppy disk drives in raw mode. The following ioctl(2) calls are supported by fd devices:

FDCLRPRM

clears the media information of a drive (geometry of disk in drive).

FDSETPRM

sets the media information of a drive. The media information will be lost when the media is changed.

FDDEFPRM

sets the media information of a drive (geometry of disk in drive). The media information will not be lost when the media is changed. This will disable autodetection. In order to re-enable autodetection, you have to issue an FDCLRPRM .

FDGETDRVTYP

returns the type of a drive (name parameter). For formats which work in several drive types, FDGETDRVTYP returns a name which is appropriate for the oldest drive type which supports this format.

FDFLUSH

invalidates the buffer cache for the given drive.

FDSETMAXERRS

sets the error thresholds for reporting errors, aborting the operation, recalibrating, resetting, and reading sector by sector.

FDSETMAXERRS

gets the current error thresholds.

FDGETDRVTYP

gets the internal name of the drive.

FDWERRORCLR

clears the write error statistics.

FDWERRORGET

reads the write error statistics. These include the total number of write errors, the location and disk of the first write error, and the location and disk of the last write error. Disks are identified by a generation number which is incremented at (almost) each disk change.

FDTWADDLE

Switch the drive motor off for a few microseconds. This might be needed in order to access a disk whose sectors are too close together.

FDSETDRVPRM

sets various drive parameters.

FDGETDRVPRM

reads these parameters back.

FDGETDRVSTAT

gets the cached drive state (disk changed, write protected et al.)

FDPOLLDRVSTAT

polls the drive and return its state.

FDGETFDCSTAT

gets the floppy controller state.

FDRESET

resets the floppy controller under certain conditions.

FDRAWCMD

sends a raw command to the floppy controller.

For more precise information, consult also the <linux/fd.h> and <linux/fdreg.h> include files, as well as the manual page for floppycontrol.  

NOTES

The various formats allow to read and write many types of disks. However, if a floppy is formatted with a too small inter sector gap, performance may drop, up to needing a few seconds to access an entire track. To prevent this, use interleaved formats. It is not possible to read floppies which are formatted using GCR (group code recording), which is used by Apple II and Macintosh computers (800k disks). Reading floppies which are hard sectored (one hole per sector, with the index hole being a little skewed) is not supported. This used to be common with older 8 inch floppies.  

FILES

/dev/fd*  

AUTHORS

Alain Knaff (Alain.Knaff@imag.fr), David Niemi (niemidc@clark.net), Bill Broadhurst (bbroad@netcom.com).  

SEE ALSO

floppycontrol(1), mknod(1), chown(1), getfdprm(1), superformat(1), mount(8), setfdprm(8)

fpit

NAME

fpit - Fujitsu Stylistic input driver  

SYNOPSIS

Section N`34`InputDeviceN`34` Identifier N`34`idevnameN`34` Driver N`34`fpitN`34` Option N`34`DeviceN`34` N`34`devpathN`34`   ... EndSection

 

DESCRIPTION

fpit is an Xorg input driver for Fujitsu Stylistic Tablet PCs.

The fpit driver functions as a pointer input device, and may be used as the X server`s core pointer.  

SUPPORTED HARDWARE

This driver supports the touchscreen of the Stylistic LT and (with special options) of the Stylistic 500, 1000 and 2300.

Under Linux the Fujitsus serial port is not, by default, detected. Therefore the following must be added to one of your start-up scripts. (Either one of the X scripts, or to rc.local or similar).

setserial /dev/ttyS3 autoconfig

setserial /dev/ttyS3 IRQ 15 baud_base 115200 port 0xfce8

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

The device supports the following options:

Option MaximumXPosition number

Sets the maximum X position, use this to callibrate your touchscreen`s right hand edge.

Option MinimumXPosition number

Sets the minimum X position, use this to callibrate your touchscreen`s left hand edge.

Option MaximumYPosition number

Option MinimumYPosition number

Same as for X axis, but for Y axis.

Option InvertX

Option InvertY

Invert the specified axis.

Option SwapXY

Swap the X and Y axis.

Option Rotate CW

Option Rotate CWW Manipulate the invert and swap options to match screen rotations.

Option DeviceName name

Option DeviceName name sets the name of the X device.

Option AlwaysCore on

enables the sharing of the core pointer. When this feature is enabled, the device will take control of the core pointer (and thus will emit core events) and at the same time will be able, when asked so, to report extended events. You can use the last available integer feedback to control this feature. When the value of the feedback is zero, the feature is disabled. The feature is enabled for any other value.

Option DebugLevel number

sets the level of debugging info reported.

Option BaudRate 38400, 19200 or 9600 (default)

changes the serial link speed.

Example, for Stylistic LT setup is:

Section N`34`InputDeviceN`34` Identifier N`34`mouse0N`34` Driver N`34`fpitN`34` Option N`34`DeviceN`34` N`34`/dev/ttyS3N`34` EndSection

And for other Stylistic devices try:

Section N`34`InputDeviceN`34` Identifier N`34`mouse0N`34` Driver N`34`fpitN`34` Option N`34`DeviceN`34` N`34`/dev/ttyS3N`34` Option N`34`BaudRateN`34` N`34`19200N`34` Option N`34`MaximumXPositionN`34` N`34`6250N`34` Option N`34`MaximumYPositionN`34` N`34`4950N`34` Option N`34`MinimumXPositionN`34` N`34`130N`34` Option N`34`MinimumYPositionN`34` N`34`0N`34` Option N`34`InvertYN`34` EndSection

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

Original FPIT port: Rob Tsuk <rob@tsuk.com> and John Apfelbaum <johnapf@linuxslate.com>

X4 Port: Richard Miller-Smith <richard.miller-smith@philips.com>, based on Elographics code from: Patrick Lecoanet

X4.2 Cleanup: Alan Cox

futex

NAME

futex - Fast Userspace Locking  

SYNOPSIS

#include <linux/futex.h>

 

DESCRIPTION

The Linux kernel provides futexes (`Fast Userspace muTexes`) as a building block for fast userspace locking and semaphores. Futexes are very basic and lend themselves well for building higher level locking abstractions such as POSIX mutexes.

This page does not set out to document all design decisions but restricts itself to issues relevant for application and library development. Most programmers will in fact not be using futexes directly but instead rely on system libraries built on them, such as the NPTL pthreads implementation.

A futex is identified by a piece of memory which can be shared between different processes. In these different processes, it need not have identical addresses. In its bare form, a futex has semaphore semantics; it is a counter that can be incremented and decremented atomically; processes can wait for the value to become positive.

Futex operation is entirely userspace for the non-contended case. The kernel is only involved to arbitrate the contended case. As any sane design will strive for non-contension, futexes are also optimised for this situation.

In its bare form, a futex is an aligned integer which is only touched by atomic assembler instructions. Processes can share this integer over mmap, via shared segments or because they share memory space, in which case the application is commonly called multithreaded.  

SEMANTICS

Any futex operation starts in userspace, but it may necessary to communicate with the kernel using the futex(2) system call.

To `up` a futex, execute the proper assembler instructions that will cause the host CPU to atomically increment the integer. Afterwards, check if it has in fact changed from 0 to 1, in which case there were no waiters and the operation is done. This is the non-contended case which is fast and should be common.

In the contended case, the atomic increment changed the counter from -1 (or some other negative number). If this is detected, there are waiters. Userspace should now set the counter to 1 and instruct the kernel to wake up any waiters using the FUTEX_WAKE operation.

Waiting on a futex, to `down` it, is the reverse operation. Atomically decrement the counter and check if it changed to 0, in which case the operation is done and the futex was uncontended. In all other circumstances, the process should set the counter to -1 and request that the kernel wait for another process to up the futex. This is done using the FUTEX_WAIT operation.

The futex system call can optionally be passed a timeout specifying how long the kernel should wait for the futex to be upped. In this case, semantics are more complex and the programmer is referred to futex(2) for more details. The same holds for asynchronous futex waiting.  

NOTES

To reiterate, bare futexes are not intended as an easy to use abstraction for end-users. Implementors are expected to be assembly literate and to have read the sources of the futex userspace library referenced below.

This man page illustrates the most common use of the futex(2) primitives: it is by no means the only one.  

AUTHORS

Futexes were designed and worked on by Hubertus Franke (IBM Thomas J. Watson Research Center), Matthew Kirkwood, Ingo Molnar (Red Hat) and Rusty Russell (IBM Linux Technology Center). This page written by bert hubert.  

VERSIONS

Initial futex support was merged in Linux 2.5.7 but with different semantics from those described above. Current semantics are available from Linux 2.5.40 onwards.  

SEE ALSO

futex(2), `Fuss, Futexes and Furwocks: Fast Userlevel Locking in Linux` (proceedings of the Ottawa Linux Symposium 2002), futex example library, futex-*.tar.bz2 <URL:ftp://ftp.kernel.org:/pub/linux/kernel/people/rusty/>.

glint

NAME

glint - GLINT/Permedia video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`glintN`34`   ... EndSection

 

DESCRIPTION

glint is an Xorg driver for 3Dlabs & Texas Instruments GLINT/Permedia based video cards. The driver is rather fully accelerated, and provides support for the following framebuffer depths: 8, 15 (may give bad results with FBDev support), 16, 24 (32 bpp recommended, 24 bpp has problems), 30, and an 8+24 overlay mode.  

SUPPORTED HARDWARE

The glint driver supports 3Dlabs (GLINT MX, GLINT 500TX, GLINT 300SX, GLINT GAMMA, GLINT DELTA, GLINT GAMMA2, Permedia, Permedia 2, Permedia 2v, Permedia 3, R3, R4) and Texas Instruments (Permedia, Permedia 2) chips.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The driver auto-detects the chipset type, but the following ChipSet names may optionally be specified in the config file N`34`DeviceN`34` section, and will override the auto-detection:

"ti_pm2", "ti_pm", "r4", "pm3", "pm2v", "pm2", "pm", "300sx", "500tx", "mx", "gamma", "gamma2", "delta"

The driver will try to auto-detect the amount of video memory present for all chips. If it`s not detected correctly, the actual amount of video memory should be specified with a VideoRam entry in the config file N`34`DeviceN`34` section.

Additionally, you may need to specify the bus ID of your card with a BusID entry in the config file N`34`DeviceN`34` section, especially with FBDev support.

The following driver Options are supported:

Option N`34`UseFlatPanelN`34` N`34`booleanN`34`

Enable the FlatPanel feature on the Permedia3. Default: off.

Option N`34`SWCursorN`34` N`34`booleanN`34`

Enable or disable the SW cursor. Default: off. This option disables the HWCursor option and vice versa.

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`OverlayN`34`

Enable 8+24 overlay mode. Only appropriate for depth 24, 32 bpp. (Note: This hasn`t been tested with FBDev support and probably won`t work.) Recognized values are: "8,24", "24,8". Default: off.

Option N`34`PciRetryN`34` N`34`booleanN`34`

Enable or disable PCI retries. (Note: This doesn`t work with Permedia2 based cards for Amigas.) Default: off.

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. (Note: This disables hardware acceleration.) Default: off.

Option N`34`UseFBDevN`34` N`34`booleanN`34`

Enable or disable use of an OS-specific fb interface (which is not supported on all OSs). See fbdevhw(4x) for further information. Default: off.

Option N`34`BlockWriteN`34` N`34`booleanN`34`

Enable or disable block writes for the various Permedia 2 chips. This improves acceleration in general, but disables it for some special cases. Default: off.

Option N`34`FireGL3000N`34` N`34`booleanN`34`

If you have a card of the same name, turn this on. Default: off.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Alan Hourihane, Dirk Hohndel, Stefan Dirsch, Michel Dänzer, Sven Luther

i128

NAME

i128 - Number 9 I128 video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`i128N`34`   ... EndSection

 

DESCRIPTION

i128 is an Xorg driver for Number 9 I128 video cards. The driver is accelerated and provides support for all versions of the I128 chip family, including the SGI flatpanel configuration. Multi-head configurations are supported.  

SUPPORTED HARDWARE

The i128 driver supports PCI and AGP video cards based on the following I128 chips:

I128 rev 1

(original)

I128-II

I128-T2R

Ticket 2 Ride

I128-T2R4

Ticket 2 Ride IV

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The driver auto-detects the chipset type and may not be overridden.

The driver auto-detects the amount of video memory present for all chips and may not be overridden.

The following driver Options are supported:

Option N`34`HWCursorN`34` N`34`booleanN`34`

Enable or disable the HW cursor. Default: on.

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`SyncOnGreenN`34` N`34`booleanN`34`

Enable or disable combining the sync signals with the green signal. Default: off.

Option N`34`Dac6BitN`34` N`34`booleanN`34`

Reduce DAC operations to 6 bits. Default: false.

Option N`34`DebugN`34` N`34`booleanN`34`

This turns on verbose debug information from the driver. Default: off.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Robin Cutshaw (driver), Galen Brooks (flatpanel support).

i810

NAME

i810 - Intel 8xx integrated graphics chipsets  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`i810N`34`   ... EndSection

 

DESCRIPTION

i810 is an Xorg driver for Intel integrated graphics chipsets. The driver supports depths 8, 15, 16 and 24. All visual types are supported in depth 8. For the i810/i815 other depths support the TrueColor and DirectColor visuals. For the 830M and later, only the TrueColor visual is supported for depths greater than 8. The driver supports hardware accelerated 3D via the Direct Rendering Infrastructure (DRI), but only in depth 16 for the i810/i815 and depths 16 and 24 for the 830M and later.  

SUPPORTED HARDWARE

i810 supports the i810, i810-DC100, i810e, i815, 830M, 845G, 852GM, 855GM, 865G and 915G chipsets.

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The Intel 8xx family of integrated graphics chipsets has a unified memory architecture and uses system memory for video ram. For the i810 and i815 familiy of chipset, operating system support for allocating system memory for video use is required in order to use this driver. For the 830M and later, this is required in order for the driver to use more video ram than has been pre-allocated at boot time by the BIOS. This is usually achieved with an "agpgart" or "agp" kernel driver. Linux, and recent versions of FreeBSD, OpenBSD and NetBSD have such kernel drivers available.

By default 8 Megabytes of system memory are used for graphics. For the 830M and later, the default is 8 Megabytes when DRI is not enabled and 32 Megabytes with DRI is enabled. This amount may be changed with the VideoRam entry in the config file Device section. It may be set to any reasonable value up to 64MB for older chipsets or 128MB for newer chipets. It is advisable to check the Xorg log file to check if any features have been disabled because of insufficient video memory. In particular, DRI support or tiling mode may be disabled with insufficient video memory. Either of these being disabled will reduce performance for 3D applications. Note however, that increasing this value too much will reduce the amount of system memory available for other applications.

The driver makes use of the video BIOS to program video modes for the 830M and later. This limits the video modes that can be used to those provided by the video BIOS, and to those that will fit into the amount of video memory that the video BIOS is aware of.

The following driver Options are supported

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`SWCursorN`34` N`34`booleanN`34`

Disable or enable software cursor. Default: software cursor is disable and a hardware cursor is used for configurations where the hardware cursor is available.

Option N`34`ColorKeyN`34` N`34`integerN`34`

This sets the default pixel value for the YUV video overlay key. Default: undefined.

Option N`34`CacheLinesN`34` N`34`integerN`34`

This allows the user to change the amount of graphics memory used for 2D acceleration and video. Decreasing this amount leaves more for 3D textures. Increasing it can improve 2D performance at the expense of 3D performance. Default: depends on the resolution, depth, and available video memory. The driver attempts to allocate at least enough to hold two DVD-sized YUV buffers by default. The default used for a specific configuration can be found by examining the Xorg log file.

Option N`34`DRIN`34` N`34`booleanN`34`

Disable or enable DRI support. Default: DRI is enabled for configurations where it is supported.

The following driver Options are supported for the i810 and i815 chipsets:

Option N`34`DDCN`34` N`34`booleanN`34`

Disable or enable DDC support. Default: enabled.

Option N`34`Dac6BitN`34` N`34`booleanN`34`

Enable or disable 6-bits per RGB for 8-bit modes. Default: 8-bits per RGB for 8-bit modes.

Option N`34`XvMCSurfacesN`34` N`34`integerN`34`

This option enables XvMC. The integer parameter specifies the number of surfaces to use. Valid values are 6 and 7. Default: XvMC is disabled.

The following driver Options are supported for the 830M and later chipsets:

Option N`34`VBERestoreN`34` N`34`booleanN`34`

Enable or disable the use of VBE save/restore for saving and restoring the initial text mode. This is disabled by default because it causes lockups on some platforms. However, there are some cases where it must enabled for the correct restoration of the initial video mode. If you are having a problem with that, try enabling this option. Default: Disabled.

Option N`34`VideoKeyN`34` N`34`integerN`34`

This is the same as the N`34`ColorKeyN`34` option described above. It is provided for compatibility with most other drivers.

Option N`34`XVideoN`34` N`34`booleanN`34`

Disable or enable XVideo support. Default: XVideo is enabled for configurations where it is supported.

Option N`34`MonitorLayoutN`34` N`34`anystrN`34`

Allow different monitor configurations. e.g. N`34`CRT,LFPN`34` will configure a CRT on Pipe A and an LFP on Pipe B. Regardless of the primary heads` pipe it is always configured as N`34`<PIPEA>,<PIPEB>N`34`. Additionally you can add different configurations such as N`34`CRT+DFP,LFPN`34` which would put a digital flat panel and a CRT on pipe A, and a local flat panel on pipe B. For single pipe configurations you can just specify the monitors types on Pipe A, such as N`34`CRT+DFPN`34` which will enable the CRT and DFP on Pipe A. Valid monitors are CRT, LFP, DFP, TV, CRT2, LFP2, DFP2, TV2 and NONE. NOTE: Some configurations of monitor types may fail, this depends on the Video BIOS and system configuration. Default: Not configured, and will use the current head`s pipe and monitor.

Option N`34`CloneN`34` N`34`booleanN`34`

Enable Clone mode on pipe B. This will setup the second head as a complete mirror of the monitor attached to pipe A. NOTE: Video overlay functions will not work on the second head in this mode. If you require this, then use the MonitorLayout above and do (as an example) N`34`CRT+DFP,NONEN`34` to configure both a CRT and DFP on Pipe A to achieve local mirroring and disable the use of this option. Default: Clone mode on pipe B is disabled.

Option N`34`CloneRefreshN`34` N`34`integerN`34`

When the Clone option is specified we can drive the second monitor at a different refresh rate than the primary. Default: 60Hz.

Option N`34`CheckLidN`34` N`34`booleanN`34`

On mobile platforms it`s desirable to monitor the lid status and switch the outputs accordingly when the lid is opened or closed. By default this option is on, but may incur a very minor performance penalty as we need to poll a register on the card to check for this activity. It can be turned off using this option. This only works with the 830M, 852GM and 855GM systems. Default: enabled.

Option N`34`FlipPrimaryN`34` N`34`booleanN`34`

When using a dual pipe system, it may be preferable to switch the primary screen to the alternate pipe to display on the other monitor connection. NOTE: Using this option may cause text mode to be restored incorrectly, and thus should be used with caution. Default: disabled.

Option N`34`DisplayInfoN`34` N`34`booleanN`34`

It has been found that a certain BIOS call can lockup the Xserver because of a problem in the Video BIOS. The log file will identify if you are suffering from this problem and tell you to turn this option off. Default: enabled

Option N`34`DevicePresenceN`34` N`34`booleanN`34`

Tell the driver to perform an active detect of the currently connected monitors. This option is useful if the monitor was not connected when the machine has booted, but unfortunately it doesn`t always work and is extremely dependent upon the Video BIOS. Default: disabled

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Keith Whitwell, and also Jonathan Bian, Matthew J Sottek, Jeff Hartmann, Mark Vojkovich, Alan Hourihane, H. J. Lu. 830M and 845G support reworked for XFree86 4.3 by David Dawes and Keith Whitwell. 852GM, 855GM, and 865G support added by David Dawes and Keith Whitwell. 915G support added by Alan Hourihane and Keith Whitwell. Dual Head, Clone and lid status support added by Alan Hourihane.

initrd

NAME

initrd - boot loader initialized RAM disk  

DESCRIPTION

The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the the block device /dev/initrd`s contents for a two phased system boot-up.

In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device`s contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.  

BOOT-UP OPERATION

When booting up with initrd, the system boots as follows:

1. The boot loader loads the kernel program and /dev/initrd`s contents into memory.

2. On kernel startup, the kernel uncompresses and copies the contents of the device /dev/initrd onto device /dev/ram0 and then frees the memory used by /dev/initrd.

3. The kernel then read-write mounts device /dev/ram0 as the initial root file system.

4. If the indicated normal root file system is also the initial root file-system (e.g. /dev/ram0 ) then the kernel skips to the last step for the usual boot sequence.

5. If the executable file /linuxrc is present in the initial root file-system, /linuxrc is executed with uid 0. (The file /linuxrc must have executable permission. The file /linuxrc can be any valid executable, including a shell script.)

6. If /linuxrc is not executed or when /linuxrc terminates, the normal root file system is mounted. (If /linuxrc exits with any file-systems mounted on the initial root file-system, then the behavior of the kernel is UNSPECIFIED. See the NOTES section for the current kernel behavior.)

7. If the normal root file has directory /initrd, device /dev/ram0 is moved from / to /initrd. Otherwise if directory /initrd does not exist device /dev/ram0 is unmounted. (When moved from / to /initrd, /dev/ram0 is not unmounted and therefore processes can remain running from /dev/ram0. If directory /initrd does not exist on the normal root file-system and any processes remain running from /dev/ram0 when /linuxrc exits, the behavior of the kernel is UNSPECIFIED. See the NOTES section for the current kernel behavior.)

8. The usual boot sequence (e.g. invocation of /sbin/init) is performed on the normal root file system.

 

OPTIONS

The following boot loader options when used with initrd, affect the kernel`s boot-up operation:

initrd=filename

Specifies the file to load as the contents of /dev/initrd. For LOADLIN this is a command line option. For LILO you have to use this command in the LILO configuration file /etc/lilo.config. The filename specified with this option will typically be a gzipped file-system image.

noinitrd

This boot time option disables the two phase boot-up operation. The kernel performs the usual boot sequence as if /dev/initrd was not initialized. With this option, any contents of /dev/initrd loaded into memory by the boot loader contents are preserved. This option permits the contents of /dev/initrd to be any data and need not be limited to a file system image. However, device /dev/initrd is read-only and can be read only one time after system startup.

root=device-name

Specifies the device to be used as the normal root file system. For LOADLIN this is a command line option. For LILO this is a boot time option or can be used as an option line in the LILO configuration file /etc/lilo.config. The device specified by the this option must be a mountable device having a suitable root file-system.

 

CHANGING THE NORMAL ROOT FILE SYSTEM

By default, the kernel`s settings (e.g. set in the kernel file with rdev or compiled into the kernel file), or the boot loader option setting is used for the normal root file systems. For a NFS-mounted normal root file system, one has to use the nfs_root_name and nfs_root_addrs boot options to give the NFS settings. For more information on NFS-mounted root see the kernel documentation file nfsroot.txt. For more information on setting the root file system also see the LILO and LOADLIN documentation.

It is also possible for the /linuxrc executable to change the normal root device. For /linuxrc to change the normal root device, /proc must be mounted. After mounting /proc, /linuxrc changes the normal root device by writing into the proc files /proc/sys/kernel/real-root-dev, /proc/sys/kernel/nfs-root-name, and /proc/sys/kernel/nfs-root-addrs. For a physical root device, the root device is changed by having /linuxrc write the new root file system device number into /proc/sys/kernel/real-root-dev. For a NFS root file system, the root device is changed by having /linuxrc write the NFS setting into files /proc/sys/kernel/nfs-root-name and /proc/sys/kernel/nfs-root-addrs and then writing 0xff (e.g. the pseudo-NFS-device number) into file /proc/sys/kernel/real-root-dev. For example, the following shell command line would change the normal root device to /dev/hdb1:

echo 0x365 >/proc/sys/kernel/real-root-dev

For a NFS example, the following shell command lines would change the normal root device to the NFS directory /var/nfsroot on a local networked NFS server with IP number 193.8.232.7 for a system with IP number 193.8.232.7 and named `idefix`:

echo /var/nfsroot >/proc/sys/kernel/nfs-root-name echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix >/proc/sys/kernel/nfs-root-addrs echo 255 >/proc/sys/kernel/real-root-dev

 

USAGE

The main motivation for implementing initrd was to allow for modular kernel configuration at system installation.

A possible system installation scenario is as follows:

1. The loader program boots from floppy or other media with a minimal kernel (e.g. support for /dev/ram, /dev/initrd, and the ext2 file-system) and loads /dev/initrd with a gzipped version of the initial file-system.

2. The executable /linuxrc determines what is needed to (1) mount the normal root file-system (i.e. device type, device drivers, file system) and (2) the distribution media (e.g. CD-ROM, network, tape, ...). This can be done by asking the user, by auto-probing, or by using a hybrid approach.

3. The executable /linuxrc loads the necessary modules from the initial root file-system.

4. The executable /linuxrc creates and populates the root file system. (At this stage the normal root file system does not have to be a completed system yet.)

5. The executable /linuxrc sets /proc/sys/kernel/real-root-dev, unmount /proc, the normal root file system and any other file systems it has mounted, and then terminates.

6. The kernel then mounts the normal root file system.

7. Now that the file system is accessible and intact, the boot loader can be installed.

8. The boot loader is configured to load into /dev/initrd a file system with the set of modules that was used to bring up the system. (e.g. Device /dev/ram0 can be modified, then unmounted, and finally, the image is written from /dev/ram0 to a file.)

9. The system is now bootable and additional installation tasks can be performed.

The key role of /dev/initrd in the above is to re-use the configuration data during normal system operation without requiring initial kernel selection, a large generic kernel or, recompiling the kernel.

A second scenario is for installations where Linux runs on systems with different hardware configurations in a single administrative network. In such cases, it may be desirable to use only a small set of kernels (ideally only one) and to keep the system-specific part of configuration information as small as possible. In this case, create a common file with all needed modules. Then, only the the /linuxrc file or a file executed by /linuxrc would be different.

A third scenario is more convenient recovery disks. Because information like the location of the root file-system partition is not needed at boot time, the system loaded from /dev/initrd can use a dialog and/or auto-detection followed by a possible sanity check.

Last but not least, Linux distributions on CD-ROM may use initrd for easy installation from the CD-ROM. The distribution can use LOADLIN to directly load /dev/initrd from CD-ROM without the need of any floppies. The distribution could also use a LILO boot floppy and then bootstrap a bigger ram disk via /dev/initrd from the CD-ROM.  

CONFIGURATION

The /dev/initrd is a read-only block device assigned major number 1 and minor number 250. Typically /dev/initrd is owned by root.disk with mode 0400 (read access by root only). If the Linux system does not have /dev/initrd already created, it can be created with the following commands:

mknod -m 400 /dev/initrd b 1 250 chown root:disk /dev/initrd

Also, support for both "RAM disk" and "Initial RAM disk" (e.g. CONFIG_BLK_DEV_RAM=y and CONFIG_BLK_DEV_INITRD=y ) support must be compiled directly into the Linux kernel to use /dev/initrd. When using /dev/initrd, the RAM disk driver cannot be loaded as a module.  

FILES

/dev/initrd
/dev/ram0
/linuxrc
/initrd  

SEE ALSO

chown(1), mknod(1), ram(4), freeramdisk(8), rdev(8), The documentation file initrd.txt in the kernel source package, the LILO documentation, the LOADLIN documentation, the SYSLINUX documentation.  

NOTES

1. With the current kernel, any file systems that remain mounted when /dev/ram0 is moved from / to /initrd continue to be accessible. However, the /proc/mounts entries are not updated.

2. With the current kernel, if directory /initrd does not exist, then /dev/ram0 will NOT be fully unmounted if /dev/ram0 is used by any process or has any file-system mounted on it. If /dev/ram0 is NOT fully unmounted, then /dev/ram0 will remain in memory.

3. Users of /dev/initrd should not depend on the behavior give in the above notes. The behavior may change in future versions of the Linux kernel.  

AUTHOR

The kernel code for device initrd was written by Werner Almesberger <almesber@lrc.epfl.ch> and Hans Lermen <lermen@elserv.ffm.fgan.de>. The code for initrd was added to the baseline Linux kernel in development version 1.3.73.

irnet

NAME

irnet - IrNET protocol device  

DESCRIPTION

File /dev/irnet is used to access and configure the IrNET protocol part of the Linux-IrDA stack.

IrNET is a protocol allowing to create TCP/IP connections between two IrDA peers in an efficient fashion, and generally to enable standard networking over IrDA. It is a thin layer, passing PPP packets to IrTTP and vice versa. It uses PPP in synchronous mode, because IrTTP offer a reliable sequenced packet service (as opposed to a byte stream). In fact, you could see IrNET as carrying TCP/IP in a IrDA socket, using PPP to provide the glue.

The main difference with traditional PPP over IrCOMM is that it avoids the framing and serial emulation which are a performance bottleneck. It also allows multipoint communications in a sensible fashion. And finally, it can automatically handle incomming connections through irnetd.

The main difference with IrLAN is that we use PPP for the link management, which is more standard, interoperable and flexible than the IrLAN protocol. For example, PPP adds authentication, encryption, compression, header compression and automated routing setup. And, as IrNET let PPP do the hard work, the implementation is much simpler than IrLAN.

IrNET connections are initiated and managed with pppd(8). File /dev/irnet also offer a control channel. Reads from /dev/irnet will return various IrNET events. Write to /dev/irnet allow to configure the IrNET connection.  

CONFIGURATION

If your system does not have /dev/irnet created already, it can be created with the following commands:

mknod -m 644 /dev/irnet c 10 187 chown root:root /dev/irnet

You will also need to have IrNET support in your kernel or as module and the Linux-IrDA stack installed and configured (see irattach(8)).

File /dev/irnet is supposed to only be used with the PPP line discipline or for accessing the control channel, other use are unsupported. IrNET support multiple concurent connections (limited by the IrDA stack), all those connections are multiplexed on a single /dev/irnet device (as opposed to IrCOMM which as one device per connection).  

PARAMETERS

Writing commands to /dev/irnet allow to configure the IrNET connection being made. This need to be done through pppd(8) (see below for examples). Commands are separated by comas.

name <peer>

Connect to the IrDA device which IrDA nickname is <peer>. The IrDA nickname is a string up to 31 characters.

daddr <peer>

Connect to the IrDA device which IrDA address is <peer>. The IrDA address is a 32 bits hexadecimal number.

raddr <port>

Restrict connections to the local IrDA interface which IrDA address is <port>. The IrDA address is a 32 bits hexadecimal number.

 

DISPLAY

Reading from /dev/irnet will show various IrNET events. This is usually done with the command cat /dev/irnet.

Found

Dump of the current IrNET discovery log.

Discovered

New IrNET device discovered.

Expired

Previously discovered IrNET device no longer present.

Connected to

This computer successfully established an IrNET connection to a peer.

Connection from

A peer successfully established an IrNET connection to this computer.

Request from

A peer attempted to connect to this computer, but no IrNET connection was waiting for it.

No-answer from

This computer attempted to connect to a peer, but no IrNET connection was waiting for it.

Blocked link with

The IrDA link of the IrNET connection is currently blocked.

Disconnection from

A peer successfully terminated an IrNET connection with this computer.

Disconnected to

This computer successfully terminated an IrNET connection with a peer.

File /proc/net/irda/irnet will also show the current state of the various IrNET connections.  

EXAMPLE

Start a IrNET server accepting any incomming connection:
      pppd /dev/irnet 9600 local noauth nolock passive

Start a IrNET client connecting to any IrDA peer:

      pppd /dev/irnet 9600 local noauth nolock

Start a IrNET client connecting to the IrDA peer called
MyIrDANode:
      pppd /dev/irnet 9600 local noauth nolock connect echo name MyIrDANode

Start a IrNET server accepting incomming connection from peer with IrDA address 0x12345678 only on IrDA port 0x87654321:

      pppd /dev/irnet 9600 local noauth nolock passive connect echo daddr 0x12345678 , saddr 0x87654321  

AUTHOR

Jean Tourrilhes - jt@hpl.hp.com
 

FILES

/dev/irnet
/proc/net/irda/irnet  

SEE ALSO

irda(7), irnetd(8), pppd(8), irattach(8), irdadump(8).

isdninfo

NAME

isdninfo - ISDN status device  

SYNOPSIS

#include <linux/isdn.h>  

DESCRIPTION

/dev/isdninfo is a character device with major number 45 and minor number 255. It delivers status information from the Linux <FONT SIZE="-1">ISDN</FONT> subsystem to user level.  

DATA FORMAT

When reading from this device, the current status of the Linux <FONT SIZE="-1">ISDN</FONT> subsystem is delivered in 6 lines of text. Each line starts with a tag string followed by a colon and whitespace. After that the status values are appended separated by whitespace.

idmap

is the tag of the first line. In this line for every virtual channel, the Id-string of the corresponding lowlevel driver is shown. If no driver is loaded, a - (hyphen) is shown.

chmap

is the tag of line 2. In this line for every virtual channel, the channel number of the corresponding lowlevel driver is shown. If no driver is loaded, -1 is shown.

drmap

is the tag of line 3. In this line for every virtual channel, the index number of the corresponding lowlevel driver is shown. If no driver is loaded, -1 is shown.

usage

is the tag of line 4. In this line for every virtual channel, the current usage is shown. The following usage constants are defined:

ISDN_USAGE_NONE (0)

Unused channel

ISDN_USAGE_RAW (1)

Channel used by raw device (currently unsupported)

ISDN_USAGE_MODEM (2)

Channel used by some ttyI

ISDN_USAGE_NET (3)

Channel used by an ISDN net-interface

ISDN_USAGE_VOICE (4)

Channel used by some ttyI in voice mode.

ISDN_USAGE_EXCLUSIVE (64)

Channel exclusively preserved for a net-interface. This value is logically or`ed with one of the other codes.

ISDN_USAGE_OUTGOING (128)

Channel is used outgoing. This value is logically or`ed with one of the other codes. It is set, when dialling is started and reset, when either dialling failed or after hangup. Therefore, it is not always an indicator for an established connection. To get a reliable indicator for an established connection, the driver flags (see below) have to be inspected also.

flags

is the tag of line 5. In this line for every driver slot, it`s B-Channel status is shown. If no driver is registered in a slot, a ? is shown. For every established B-Channel of the driver, a bit is set in the shown value. The driver`s first channel is mapped to bit 0, the second channel to bit 1 and so on.

phone

is the tag of line 6. In this line for every virtual channel, the remote phone number is shown if the channel is active. A ??? is shown, if the channel is inactive.

 

BLOCKING BEHAVIOUR

After opening the device, at most 6 lines can be read by a user process. After that, the user process is blocked. Whenever a status change happens, the process is allowed to read 6 more lines, starting with line one.

 

IOCTL FUNCTIONS

Currently, there are two ioctl calls supported:

IIOCGETDVR

Get Revision information.

Returns an unsigned long value v, representing various user level interface revisions, where

(v & 0xff)

is the revision of the modem-register info, available via ioctl on /dev/isdnctrl.

((v >> 8) & 0xff)

is the revision of the net-interface config data, available via ioctl on /dev/isdnctrl. and

((v >> 16) & 0xff)

is the revision of the data delivered via /dev/isdninfo itself.

IIOCGETCPS

Get transfer statistics.

Returns the number of bytes transferred so far for all virtual channels. The third parameter should be a pointer to an array of unsigned long of size ISDN_MAX_CHANNELS * 2. This array is filled with the byte counter values upon return.

 

OTHER CONSTANTS

There are some more useful constants defined in /usr/include/linux/isdn.h:

ISDN_TTY_MAJOR

The major device number of /dev/ttyI.

ISDN_TTYAUX_MAJOR

The major device number of /dev/cui.

ISDN_MAJOR

The major device number of /dev/isdnctrl, /dev/isdninfo, /dev/ippp and /dev/isdn

ISDN_MAX_DRIVERS

The number of driver slots.

ISDN_MAX_CHANNELS

The number of virtual channels.

ISDN_MINOR_CTRL

The minor device number of /dev/isdnctrl0.

ISDN_MINOR_CTRLMAX

The minor device number of /dev/isdnctrl63.

ISDN_MINOR_PPP

The minor device number of /dev/ippp0.

ISDN_MINOR_PPPMAX

The minor device number of /dev/ippp64.

ISDN_MINOR_STATUS

The minor device number of /dev/isdninfo.

Other constants, necessary for ioctl`s on /dev/isdnctrl are listed in isdnctrl(4).  

AUTHOR

Fritz Elfert <fritz@isdn4linux.de>  

SEE ALSO

isdnctrl(4), icnctrl(4).

ispell

NAME

ispell - format of ispell dictionaries and affix files  

DESCRIPTION

Ispell(1) requires two files to define the language that it is spell-checking. The first file is a dictionary containing words for the language, and the second is an "affix" file that defines the meaning of special flags in the dictionary. The two files are combined by buildhash (see ispell(1)) and written to a hash file which is not described here.

A raw ispell dictionary (either the main dictionary or your own personal dictionary) contains a list of words, one per line. Each word may optionally be followed by a slash ("/") and one or more flags, which modify the root word as explained below. Depending on the options with which ispell was built, case may or may not be significant in either the root word or the flags, independently. Specifically, if the compile-time option CAPITALIZATION is defined, case is significant in the root word; if not, case is ignored in the root word. If the compile-time option MASKBITS is set to a value of 32, case is ignored in the flags; otherwise case is significant in the flags. Contact your system administrator or ispell maintainer for more information (or use the -vv flag to find out). The dictionary should be sorted with the -f flag of sort(1) before the hash file is built; this is done automatically by munchlist(1), which is the normal way of building dictionaries.

If the dictionary contains words that have string characters (see the affix-file documentation below), they must be written in the format given by the defstringtype statement in the affix file. This will be the case for most non-English languages. Be careful to use this format, rather than that of your favorite formatter, when adding words to a dictionary. (If you add words to your personal dictionary during an ispell session, they will automatically be converted to the correct format. This feature can be used to convert an entire dictionary if necessary:)

echo qqqqq > dummy.dict buildhash dummy.dict affix-file dummy.hash awk `{print "*"}END{print "#"}` old-dict-file | ispell -a -T old-dict-string-type -d ./dummy.hash -p ./new-dict-file > /dev/null rm dummy.*

The case of the root word controls the case of words accepted by ispell, as follows:

(1)

If the root word appears only in lower case (e.g., bob), it will be accepted in lower case, capitalized, or all capitals.

(2)

If the root word appears capitalized (e.g., Robert), it will not be accepted in all-lower case, but will be accepted capitalized or all in capitals.

(3)

If the root word appears all in capitals (e.g., UNIX), it will only be accepted all in capitals.

(4)

If the root word appears with a "funny" capitalization (e.g., ITCorp), a word will be accepted only if it follows that capitalization, or if it appears all in capitals.

(5)

More than one capitalization of a root word may appear in the dictionary. Flags from different capitalizations are combined by OR-ing them together.

Redundant capitalizations (e.g., bob and Bob) will be combined by buildhash and by ispell (for personal dictionaries), and can be removed from a raw dictionary by munchlist.

For example, the dictionary:

bob Robert UNIX ITcorp ITCorp

will accept bob, Bob, BOB, Robert, ROBERT, UNIX, ITcorp, ITCorp, and ITCORP, and will reject all others. Some of the unacceptable forms are bOb, robert, Unix, and ItCorp.

As mentioned above, root words in any dictionary may be extended by flags. Each flag is a single alphabetic character, which represents a prefix or suffix that may be added to the root to form a new word. For example, in an English dictionary the D flag can be added to bathe to make bathed. Since flags are represented as a single bit in the hashed dictionary, this results in significant space savings. The munchlist script will reduce an existing raw dictionary by adding flags when possible.

When a word is extended with an affix, the affix will be accepted only if it appears in the same case as the initial (prefix) or final (suffix) letter of the word. Thus, for example, the entry UNIX/M in the main dictionary (M means add an apostrophe and an "s" to make a possessive) would accept UNIX`S but would reject UNIX`s. If UNIX`s is legal, it must appear as a separate dictionary entry, and it will not be combined by munchlist. (In general, you don`t need to worry about these things; munchlist guarantees that its output dictionary will accept the same set of words as its input, so all you have to do is add words to the dictionary and occasionally run munchlist to reduce its size).

As mentioned, the affix definition file describes the affixes associated with particular flags. It also describes the character set used by the language.

Although the affix-definition grammar is designed for a line-oriented layout, it is actually a free-format yacc grammar and can be laid out weirdly if you want. Comments are started by a pound (sharp) sign (#), and continue to the end of the line. Backslashes are supported in the usual fashion (nnn, plus specials , , , v, f, , and the new hex format xnn). Any character with special meaning to the parser can be changed to an uninterpreted token by backslashing it; for example, you can declare a flag named `asterisk` or `colon` with flag *: or flag ::.

The grammar will be presented in a top-down fashion, with discussion of each element. An affix-definition file must contain exactly one table:

table : [headers] [prefixes] [suffixes]

At least one of prefixes and suffixes is required. They can appear in either order.

headers : [ options ] char-sets

The headers describe options global to this dictionary and language. These include the character sets to be used and the formatter, and the defaults for certain ispell flags.

options : { fmtr-stmt | opt-stmt | flag-stmt | num-stmt }

The options statements define the defaults for certain ispell flags and for the character sets used by the formatters.

fmtr-stmt : { nroff-stmt | tex-stmt }

A fmtr-stmt describes characters that have special meaning to a formatter. Normally, this statement is not necessary, but some languages may have preempted the usual defaults for use as language-specific characters. In this case, these statements may be used to redefine the special characters expected by the formatter.

nroff-stmt : { nroffchars | troffchars } string

The nroffchars statement allows redefinition of certain nroff control characters. The string given must be exactly five characters long, and must list substitutions for the left and right parentheses ("()") , the period ("."), the backslash (""), and the asterisk ("*"). (The right parenthesis is not currently used, but is included for completeness.) For example, the statement:

nroffchars {}.\*

would replace the left and right parentheses with left and right curly braces for purposes of parsing nroff/troff strings, with no effect on the others (admittedly a contrived example). Note that the backslash is escaped with a backslash.

tex-stmt : { TeXchars | texchars } string

The TeXchars statement allows redefinition of certain TeX/LaTeX control characters. The string given must be exactly thirteen characters long, and must list substitutions for the left and right parentheses ("()") , the left and right square brackets ("[]"), the left and right curly braces ("{}"), the left and right angle brackets ("<>"), the backslash (""), the dollar sign ("$"), the asterisk ("*"), the period or dot ("."), and the percent sign ("%"). For example, the statement:

texchars ()[]<><>\$*.%

would replace the functions of the left and right curly braces with the left and right angle brackets for purposes of parsing TeX/LaTeX constructs, while retaining their functions for the tib bibliographic preprocessor. Note that the backslash, the left square bracket, and the right angle bracket must be escaped with a backslash.

opt-stmt : { cmpnd-stmt | aff-stmt } cmpnd-stmt : compoundwords compound-opt aff-stmt : allaffixes on-or-off on-or-off : { on | off } compound-opt : { on-or-off | controlled character }

An opt-stmt controls certain ispell defaults that are best made language-specific. The allaffixes statement controls the default for the -P and -m options to ispell. If allaffixes is turned off (the default), ispell will default to the behavior of the -P flag: root/affix suggestions will only be made if there are no "near misses". If allaffixes is turned on, ispell will default to the behavior of the -m flag: root/affix suggestions will always be made. The compoundwords statement controls the default for the -B and -C options to ispell. If compoundwords is turned off (the default), ispell will default to the behavior of the -B flag: run-together words will be reported as errors. If compoundwords is turned on, ispell will default to the behavior of the -C flag: run-together words will be considered as compounds if both are in the dictionary. This is useful for languages such as German and Norwegian, which form large numbers of compound words. Finally, if compoundwords is set to controlled, only words marked with the flag indicated by character (which should not be otherwise used) will be allowed to participate in compound formation. Because this option requires the flags to be specified in the dictionary, it is not available from the command line.

flag-stmt : flagmarker character

The flagmarker statement describes the character which is used to separate affix flags from the root word in a raw dictionary file. This must be a character which is not found in any word (including in string characters; see below). The default is "/" because this character is not normally used to represent special characters in any language.

num-stmt : compoundmin digit

The compoundmin statement controls the length of the two components of a compound word. This only has an effect if compoundwords is turned on or if the -C flag is given to ispell. In that case, only words at least as long as the given minimum will be accepted as components of a compound. The default is 3 characters.

char-sets : norm-sets [ alt-sets ]

The character-set section describes the characters that can be part of a word, and defines their collating order. There must always be a definition of "normal" character sets; in addition, there may be one or more partial definitions of "alternate" sets which are used with various text formatters.

norm-sets : [ deftype ] charset-group

A "normal" character set may optionally begin with a definition of the file suffixes that make use of this set. Following this are one or more character-set declarations.

deftype : defstringtype name deformatter suffix*

The defstringtype declaration gives a list of file suffixes which should make use of the default string characters defined as part of the base character set; it is only necessary if string characters are being defined. The name parameter is a string giving the unique name associated with these suffixes; often it is a formatter name. If the formatter is a member of the troff family, "nroff" should be used for the name associated with the most popular macro package; members of the TeX family should use "tex". Other names may be chosen freely, but they should be kept simple, as they are used in ispell `s -T switch to specify a formatter type. The deformatter parameter specifies the deformatting style to use when processing files with the given suffixes. Currently, this must be either tex or nroff. The suffix parameters are a whitespace-separated list of strings which, if present at the end of a filename, indicate that the associated set of string characters should be used by default for this file. For example, the suffix list for the troff family typically includes suffixes such as ".ms", ".me", ".mm", etc.

charset-group : { char-stmt | string-stmt | dup-stmt}*

A char-stmt describes single characters; a string-stmt describes characters that must appear together as a string, and which usually represent a single character in the target language. Either may also describe conversion between upper and lower case. A dup-stmt is used to describe alternate forms of string characters, so that a single dictionary may be used with several formatting programs that use different conventions for representing non-ASCII characters.

char-stmt : wordchars character-range | wordchars lowercase-range uppercase-range | boundarychars character-range | boundarychars lowercase-range uppercase-range string-stmt : stringchar string | stringchar lowercase-string uppercase-string

Characters described with the boundarychars statement are considered part of a word only if they appear singly, embedded between characters declared with the wordchars or stringchar statements. For example, if the hyphen is a boundary character (useful in French), the string "foo-bar" would be a single word, but "-foo" would be the same as "foo", and "foo--bar" would be two words separated by non-word characters.

If two ranges or strings are given in a char-stmt or string-stmt, the first describes characters that are interpreted as lowercase and the second describes uppercase. In the case of a stringchar statement, the two strings must be of the same length. Also, in a stringchar statement, the actual strings may contain both uppercase and characters themselves without difficulty; for instance, the statement

stringchar "\*(sS" "\*(Ss"

is legal and will not interfere with (or be interfered with by) other declarations of of "s" and "S" as lower and upper case, respectively.

A final note on string characters: some languages collate certain special characters as if they were strings. For example, the German "a-umlaut" is traditionally sorted as if it were "ae". Ispell is not capable of this; each character must be treated as an individual entity. So in certain cases, ispell will sort a list of words into a different order than the standard "dictionary" order for the target language.

alt-sets : alttype [ alt-stmt* ]

Because different formatters use different notations to represent non-ASCII characters, ispell must be aware of the representations used by these formatters. These are declared as alternate sets of string characters.

alttype : altstringtype name suffix*

The altstringtype statement introduces each set by declaring the associated formatter name and filename suffix list. This name and list are interpreted exactly as in the defstringtype statement above. Following this header are one or more alt-stmts which declare the alternate string characters used by this formatter.

alt-stmt : altstringchar alt-string std-string

The altstringchar statement describes alternate representations for string characters. For example, the -mm macro package of troff represents the German "a-umlaut" as a*:, while TeX uses the sequence "a. If the troff versions are declared as the standard versions using stringchar, the TeX versions may be declared as alternates by using the statement

altstringchar \"a a\*:

When the altstringchar statement is used to specify alternate forms, all forms for a particular formatter must be declared together as a group. Also, each formatter or macro package must provide a complete set of characters, both upper- and lower-case, and the character sequences used for each formatter must be completely distinct. Character sequences which describe upper- and lower-case versions of the same printable character must also be the same length. It may be necessary to define some new macros for a given formatter to satisfy these restrictions. (The current version of buildhash does not enforce these restrictions, but failure to obey them may result in errors being introduced into files that are processed with ispell.)

An important minor point is that ispell assumes that all characters declared as wordchars or boundarychars will occupy exactly one position on the terminal screen.

A single character-set statement can declare either a single character or a contiguous range of characters. A range is given as in egrep and the shell: [a-z] means lowercase alphabetics; [^a-z] means all but lowercase, etc. All character-set statements are combined (unioned) to produce the final list of characters that may be part of a word. The collating order of the characters is defined by the order of their declaration; if a range is used, the characters are considered to have been declared in ASCII order. Characters that have case are collated next to each other, with the uppercase character first.

The character-declaration statements have a rather strange behavior caused by its need to match each lowercase character with its uppercase equivalent. In any given wordchars or boundarychars statement, the characters in each range are first sorted into ASCII collating sequence, then matched one-for-one with the other range. (The two ranges must have the same number of characters). Thus, for example, the two statements:

wordchars [aeiou] [AEIOU] wordchars [aeiou] [UOIEA]

would produce exactly the same effect. To get the vowels to match up "wrong", you would have to use separate statements:

wordchars a U wordchars e O wordchars i I wordchars o E wordchars u A

which would cause uppercase `e` to be `O`, and lowercase `O` to be `e`. This should normally be a problem only with languages which have been forced to use a strange ASCII collating sequence. If your uppercase and lowercase letters both collate in the same order, you shouldn`t have to worry about this "feature".

The prefixes and suffixes sections have exactly the same syntax, except for the introductory keyword.

prefixes : prefixes flagdef* suffixes : suffixes flagdef* flagdef : flag [*|~] char : repl*

A prefix or suffix table consists of an introductory keyword and a list of flag definitions. Flags can be defined more than once, in which case the definitions are combined. Each flag controls one or more repls (replacements) which are conditionally applied to the beginnings or endings of various words.

Flags are named by a single character char. Depending on a configuration option, this character can be either any uppercase letter (the default configuration) or any 7-bit ASCII character. Most languages should be able to get along with just 26 flags.

A flag character may be prefixed with one or more option characters. (If you wish to use one of the option characters as a flag character, simply enclose it in double quotes.)

The asterisk (*) option means that this flag participates in cross-product formation. This only matters if the file contains both prefix and suffix tables. If so, all prefixes and suffixes marked with an asterisk will be applied in all cross-combinations to the root word. For example, consider the root fix with prefixes pre and in, and suffixes es and ed. If all flags controlling these prefixes and suffixes are marked with an asterisk, then the single root fix would also generate prefix, prefixes, prefixed, infix, infixes, infixed, fix, fixes, and fixed. Cross-product formation can produce a large number of words quickly, some of which may be illegal, so watch out. If cross-products produce illegal words, munchlist will not produce those flag combinations, and the flag will not be useful.

repl : condition* > [ - strip-string , ] append-string

The ~ option specifies that the associated flag is only active when a compound word is being formed. This is useful in a language like German, where the form of a word sometimes changes inside a compound.

A repl is a conditional rule for modifying a root word. Up to 8 conditions may be specified. If the conditions are satisfied, the rules on the right-hand side of the repl are applied, as follows:

(1)

If a strip-string is given, it is first stripped from the beginning or ending (as appropriate) of the root word.

(2)

Then the append-string is added at that point.

For example, the condition . means "any word", and the condition Y means "any word ending in Y". The following (suffix) replacements:

. > MENT Y > -Y,IES

would change induce to inducement and fly to flies. (If they were controlled by the same flag, they would also change fly to flyment, which might not be what was wanted. Munchlist can be used to protect against this sort of problem; see the command sequence given below.)

No matter how much you might wish it, the strings on the right must be strings of specific characters, not ranges. The reasons are rooted deeply in the way ispell works, and it would be difficult or impossible to provide for more flexibility. For example, you might wish to write:

[EY] > -[EY],IES

This will not work. Instead, you must use two separate rules:

E > -E,IES Y > -Y,IES

The application of repls can be restricted to certain words with conditions:

condition : { . | character | range }

A condition is a restriction on the characters that adjoin, and/or are replaced by, the right-hand side of the repl. Up to 8 conditions may be given, which should be enough context for anyone. The right-hand side will be applied only if the conditions in the repl are satisfied. The conditions also implicitly define a length; roots shorter than the number of conditions will not pass the test. (As a special case, a condition of a single dot "." defines a length of zero, so that the rule applies to all words indiscriminately). This length is independent of the separate test that insists that all flags produce an output word length of at least four.

Conditions that are single characters should be separated by white space. For example, to specify words ending in "ED", write:

E D > -ED,ING # As in covered > covering

If you write:

ED > -ED,ING

the effect will be the same as:

[ED] > -ED,ING

As a final minor, but important point, it is sometimes useful to rebuild a dictionary file using an incompatible suffix file. For example, suppose you expanded the "R" flag to generate "er" and "ers" (thus making the Z flag somewhat obsolete). To build a new dictionary newdict that, using newaffixes, will accept exactly the same list of words as the old list olddict did using oldaffixes, the -c switch of munchlist is useful, as in the following example:

$ munchlist -c oldaffixes -l newaffixes olddict > newdict

If you use this procedure, your new dictionary will always accept the same list the original did, even if you badly screwed up the affix file. This is because munchlist compares the words generated by a flag with the original word list, and refuses to use any flags that generate illegal words. (But don`t forget that the munchlist step takes a long time and eats up temporary file space).  

EXAMPLES

As an example of conditional suffixes, here is the specification of the S flag from the English affix file:

flag *S: [^AEIOU]Y > -Y,IES # As in imply > implies [AEIOU]Y > S # As in convey > conveys [SXZH] > ES # As in fix > fixes [^SXZHY] > S # As in bat > bats

The first line applies to words ending in Y, but not in vowel-Y. The second takes care of the vowel-Y words. The third then handles those words that end in a sibilant or near-sibilant, and the last picks up everything else.

Note that the conditions are written very carefully so that they apply to disjoint sets of words. In particular, note that the fourth line excludes words ending in Y as well as the obvious SXZH. Otherwise, it would convert "imply" into "implys".

Although the English affix file does not do so, you can also have a flag generate more than one variation on a root word. For example, we could extend the English "R" flag as follows:

flag *R: E > R # As in skate > skater E > RS # As in skate > skaters [^AEIOU]Y > -Y,IER # As in multiply > multiplier [^AEIOU]Y > -Y,IERS # As in multiply > multipliers [AEIOU]Y > ER # As in convey > conveyer [AEIOU]Y > ERS # As in convey > conveyers [^EY] > ER # As in build > builder [^EY] > ERS # As in build > builders

This flag would generate both "skater" and "skaters" from "skate". This capability can be very useful in languages that make use of noun, verb, and adjective endings. For instance, one could define a single flag that generated all of the German "weak" verb endings.  

SEE ALSO

ispell(1)

kbd

NAME

kbd - Keyboard input driver  

SYNOPSIS

Section N`34`InputDeviceN`34` Identifier N`34`idevnameN`34` Driver N`34`kbdN`34`   ... EndSection

 

DESCRIPTION

kbd is an Xorg input driver for keyboards. The driver supports the standard OS-provided keyboard interface, but these are currently only available to this driver module for Linux and BSD. This driver is experimental, but will soon replace the built-in keyboard driver.

The kbd driver functions as a keyboard input device, and may be used as the X server`s core keyboard.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

The following driver Options are supported:

Option N`34`DeviceN`34` N`34`stringN`34`

Specify the keyboard device. Default: the OS`s default console keyboard input source.

Option N`34`ProtocolN`34` N`34`stringN`34`

Specify the keyboard protocol. Valid protocol types include:

Standard, Xqueue.

Not all protocols are supported on all platforms. Default: "Standard".

Option N`34`AutoRepeatN`34` N`34`delay rateN`34`

sets the auto repeat behaviour for the keyboard. This is not implemented on all platforms. delay is the time in milliseconds before a key starts repeating. rate is the number of times a key repeats per second. Default: "500 30".

Option N`34`XLedsN`34` N`34`ledlistN`34`

makes the keyboard LEDs specified in ledlist available for client use instead of their traditional function (Scroll Lock, Caps Lock and Num Lock). The numbers in the list are in the range 1 to 3. Default: empty list.

Option N`34`XkbRulesN`34` N`34`rulesN`34`

specifies which XKB rules file to use for interpreting the XkbModel, XkbLayout, XkbVariant, and XkbOptions settings. Default: "xfree86" for most platforms, but "xfree98" for the Japanese PC-98 platforms.

Option N`34`XkbModelN`34` N`34`modelnameN`34`

specifies the XKB keyboard model name. Default: "pc101" for most platforms, but "pc98" for the Japanese PC-98 platforms, and "pc101_sol8x86" for Solaris 8 on x86.

Option N`34`XkbLayoutN`34` N`34`layoutnameN`34`

specifies the XKB keyboard layout name. This is usually the country or language type of the keyboard. Default: "us" for most platforms, but "nec/jp" for the Japanese PC-98 platforms.

Option N`34`XkbVariantN`34` N`34`variantsN`34`

specifies the XKB keyboard variant components. These can be used to enhance the keyboard layout details. Default: not set.

Option N`34`XkbOptionsN`34` N`34`optionsN`34`

specifies the XKB keyboard option components. These can be used to enhance the keyboard behaviour. Default: not set.

Some other XKB-related options are available, but they are incompatible with the ones listed above and are not recommended, so they are not documented here.  

SEE ALSO

keyboard(4x), Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).

kmem

NAME

mem, kmem, port - system memory, kernel memory and system ports  

DESCRIPTION

Mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system.

Byte addresses in mem are interpreted as physical memory addresses. References to non-existent locations cause errors to be returned.

Examining and patching is likely to lead to unexpected results when read-only or write-only bits are present.

It is typically created by:

mknod -m 660 /dev/mem c 1 1
chown root:mem /dev/mem

The file kmem is the same as mem, except that the kernel virtual memory rather than physical memory is accessed.

It is typically created by:

mknod -m 640 /dev/kmem c 1 2
chown root:mem /dev/kmem

Port is similar to mem, but the IO ports are accessed.

It is typically created by:

mknod -m 660 /dev/port c 1 4
chown root:mem /dev/port

 

FILES

/dev/mem
/dev/kmem
/dev/port  

SEE ALSO

chown(1), mknod(1), ioperm(2)

magic

NAME

magic - file command`s magic number file  

DESCRIPTION

This manual page documents the format of the magic file as used by the file(1) command, version 4.09. The file command identifies the type of a file using, among other tests, a test for whether the file begins with a certain magic number. The file /usr/share/misc/file/magic specifies what magic numbers are to be tested for, what message to print if a particular magic number is found, and additional information to extract from the file.

Each line of the file specifies a test to be performed. A test compares the data starting at a particular offset in the file with a 1-byte, 2-byte, or 4-byte numeric value or a string. If the test succeeds, a message is printed. The line consists of the following fields:

offset

A number specifying the offset, in bytes, into the file of the data which is to be tested.

type

The type of the data to be tested. The possible values are:

byte

A one-byte value.

short

A two-byte value (on most systems) in this machine`s native byte order.

long

A four-byte value (on most systems) in this machine`s native byte order.

string

A string of bytes. The string type specification can be optionally followed by /[Bbc]*. The ``B`` flag compacts whitespace in the target, which must contain at least one whitespace character. If the magic has n consecutive blanks, the target needs at least n consecutive blanks to match. The ``b`` flag treats every blank in the target as an optional blank. Finally the ``c`` flag, specifies case insensitive matching: lowercase characters in the magic match both lower and upper case characters in the targer, whereas upper case characters in the magic, only much uppercase characters in the target.

date

A four-byte value interpreted as a UNIX date.

ldate

A four-byte value interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

beshort

A two-byte value (on most systems) in big-endian byte order.

belong

A four-byte value (on most systems) in big-endian byte order.

bedate

A four-byte value (on most systems) in big-endian byte order, interpreted as a Unix date.

leshort

A two-byte value (on most systems) in little-endian byte order.

lelong

A four-byte value (on most systems) in little-endian byte order.

ledate

A four-byte value (on most systems) in little-endian byte order, interpreted as a UNIX date.

leldate

A four-byte value (on most systems) in little-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

The numeric types may optionally be followed by & and a numeric value, to specify that the value is to be AND`ed with the numeric value before any comparisons are done. Prepending a u to the type indicates that ordered comparisons should be unsigned.

test

The value to be compared with the value from the file. If the type is numeric, this value is specified in C form; if it is a string, it is specified as a C string with the usual escapes permitted (e.g. for new-line).

Numeric values may be preceded by a character indicating the operation to be performed. It may be =, to specify that the value from the file must equal the specified value, <, to specify that the value from the file must be less than the specified value, >, to specify that the value from the file must be greater than the specified value, &, to specify that the value from the file must have set all of the bits that are set in the specified value, ^, to specify that the value from the file must have clear any of the bits that are set in the specified value, or x, to specify that any value will match. If the character is omitted, it is assumed to be =.

Numeric values are specified in C form; e.g. 13 is decimal, 013 is octal, and 0x13 is hexadecimal.

For string values, the byte string from the file must match the specified byte string. The operators =, < and > (but not &) can be applied to strings. The length used for matching is that of the string argument in the magic file. This means that a line can match any string, and then presumably print that string, by doing > (because all strings are greater than the null string).

message

The message to be printed if the comparison succeeds. If the string contains a printf(3) format specification, the value from the file (with any specified masking performed) is printed using the message as the format string.

Some file formats contain additional information which is to be printed along with the file type. A line which begins with the character > indicates additional tests and messages to be printed. The number of > on the line indicates the level of the test; a line with no > at the beginning is considered to be at level 0. Each line at level n+1 is under the control of the line at level n most closely preceding it in the magic file. If the test on a line at level n succeeds, the tests specified in all the subsequent lines at level n+1 are performed, and the messages printed if the tests succeed. The next line at level n terminates this. If the first character following the last > is a ( then the string after the parenthesis is interpreted as an indirect offset. That means that the number after the parenthesis is used as an offset in the file. The value at that offset is read, and is used again as an offset in the file. Indirect offsets are of the form: ((x[.[bslBSL]][+-][y]). The value of x is used as an offset in the file. A byte, short or long is read at that offset depending on the [bslBSL] type specifier. The capitalized types interpret the number as a big endian value, whereas the small letter versions interpret the number as a little endian value. To that number the value of y is added and the result is used as an offset in the file. The default type if one is not specified is long.

Sometimes you do not know the exact offset as this depends on the length of preceding fields. You can specify an offset relative to the end of the last uplevel field (of course this may only be done for sublevel tests, i.e. test beginning with > ). Such a relative offset is specified using & as a prefix to the offset.  

BUGS

The formats long, belong, lelong, short, beshort, leshort, date, bedate, and ledate are system-dependent; perhaps they should be specified as a number of bytes (2B, 4B, etc), since the files being recognized typically come from a system on which the lengths are invariant.

There is (currently) no support for specified-endian data to be used in indirect offsets.  

SEE ALSO

file(1) - the command that reads this file.

md

NAME

md - Multiple Device driver aka Linux Software Raid  

SYNOPSIS

/dev/mdn
/dev/md/n  

DESCRIPTION

The md driver provides virtual devices that are created from one or more independent underlying devices. This array of devices often contains redundancy, and hence the acronym RAID which stands for a Redundant Array of Independent Devices.

md supports RAID levels 1 (mirroring) 4 (striped array with parity device), 5 (striped array with distributed parity information) and 6 (striped array with distributed dual redundancy information.) If a some number of underlying devices fails while using one of these levels, the array will continue to function; this number is one for RAID levels 4 and 5, two for RAID level 6, and all but one (N-1) for RAID level 1.

md also supports a number of pseudo RAID (non-redundant) configurations including RAID0 (striped array), LINEAR (catenated array) and MULTIPATH (a set of different interfaces to the same device).

 

MD SUPER BLOCK

With the exception of Legacy Arrays described below, each device that is incorporated into an MD array has a super block written towards the end of the device. This superblock records information about the structure and state of the array so that the array can be reliably re-assembled after a shutdown.

The superblock is 4K long and is written into a 64K aligned block that starts at least 64K and less than 128K from the end of the device (i.e. to get the address of the superblock round the size of the device down to a multiple of 64K and then subtract 64K). The available size of each device is the amount of space before the super block, so between 64K and 128K is lost when a device in incorporated into an MD array.

The superblock contains, among other things:

LEVEL

The manner in which the devices are arranged into the array (linear, raid0, raid1, raid4, raid5, multipath).

UUID

a 128 bit Universally Unique Identifier that identifies the array that this device is part of.

 

LEGACY ARRAYS

Early versions of the md driver only supported Linear and Raid0 configurations and so did not use an MD superblock (as there is no state that needs to be recorded). While it is strongly recommended that all newly created arrays utilise a superblock to help ensure that they are assembled properly, the md driver still supports legacy linear and raid0 md arrays that do not have a superblock.

 

LINEAR

A linear array simply catenates the available space on each drive together to form one large virtual drive.

One advantage of this arrangement over the more common RAID0 arrangement is that the array may be reconfigured at a later time with an extra drive and so the array is made bigger without disturbing the data that is on the array. However this cannot be done on a live array.

 

RAID0

A RAID0 array (which has zero redundancy) is also known as a striped array. A RAID0 array is configured at creation with a Chunk Size which must be a power of two, and at least 4 kibibytes.

The RAID0 driver assigns the first chunk of the array to the first device, the second chunk to the second device, and so on until all drives have been assigned one chunk. This collection of chunks forms a stripe. Further chunks are gathered into stripes in the same way which are assigned to the remaining space in the drives.

If devices in the array are not all the same size, then once the smallest device has been exhausted, the RAID0 driver starts collecting chunks into smaller stripes that only span the drives which still have remaining space.

 

RAID1

A RAID1 array is also known as a mirrored set (though mirrors tend to provide reflected images, which RAID1 does not) or a plex.

Once initialised, each device in a RAID1 array contains exactly the same data. Changes are written to all devices in parallel. Data is read from any one device. The driver attempts to distribute read requests across all devices to maximise performance.

All devices in a RAID1 array should be the same size. If they are not, then only the amount of space available on the smallest device is used. Any extra space on other devices is wasted.

 

RAID4

A RAID4 array is like a RAID0 array with an extra device for storing parity. This device is the last of the active devices in the array. Unlike RAID0, RAID4 also requires that all stripes span all drives, so extra space on devices that are larger than the smallest is wasted.

When any block in a RAID4 array is modified the parity block for that stripe (i.e. the block in the parity device at the same device offset as the stripe) is also modified so that the parity block always contains the "parity" for the whole stripe. i.e. its contents is equivalent to the result of performing an exclusive-or operation between all the data blocks in the stripe.

This allows the array to continue to function if one device fails. The data that was on that device can be calculated as needed from the parity block and the other data blocks.

 

RAID5

RAID5 is very similar to RAID4. The difference is that the parity blocks for each stripe, instead of being on a single device, are distributed across all devices. This allows more parallelism when writing as two different block updates will quite possibly affect parity blocks on different devices so there is less contention.

This also allows more parallelism when reading as read requests are distributed over all the devices in the array instead of all but one.

 

RAID6

RAID6 is similar to RAID5, but can handle the loss of any two devices without data loss. Accordingly, it requires N+2 drives to store N drives worth of data.

The performance for RAID6 is slightly lower but comparable to RAID5 in normal mode and single disk failure mode. It is very slow in dual disk failure mode, however.

 

MUTIPATH

MULTIPATH is not really a RAID at all as there is only one real device in a MULTIPATH md array. However there are multiple access points (paths) to this device, and one of these paths might fail, so there are some similarities.

A MULTIPATH array is composed of a number of logical different devices, often fibre channel interfaces, that all refer the the same real device. If one of these interfaces fails (e.g. due to cable problems), the multipath driver to attempt to redirect requests to another interface.

 

UNCLEAN SHUTDOWN

When changes are made to a RAID1, RAID4, RAID5 or RAID6 array there is a possibility of inconsistency for short periods of time as each update requires are least two block to be written to different devices, and these writes probably wont happen at exactly the same time. Thus if a system with one of these arrays is shutdown in the middle of a write operation (e.g. due to power failure), the array may not be consistent.

To handle this situation, the md driver marks an array as "dirty" before writing any data to it, and marks it as "clean" when the array is being disabled, e.g. at shutdown. If the md driver finds an array to be dirty at startup, it proceeds to correct any possibly inconsistency. For RAID1, this involves copying the contents of the first drive onto all other drives. For RAID4, RAID5 and RAID6 this involves recalculating the parity for each stripe and making sure that the parity block has the correct data. This process, known as "resynchronising" or "resync" is performed in the background. The array can still be used, though possibly with reduced performance.

If a RAID4, RAID5 or RAID6 array is degraded (missing at least one drive) when it is restarted after an unclean shutdown, it cannot recalculate parity, and so it is possible that data might be undetectably corrupted. The 2.4 md driver does not alert the operator to this condition. The 2.5 md driver will fail to start an array in this condition without manual intervention.

 

RECOVERY

If the md driver detects any error on a device in a RAID1, RAID4, RAID5 or RAID6 array, it immediately disables that device (marking it as faulty) and continues operation on the remaining devices. If there is a spare drive, the driver will start recreating on one of the spare drives the data what was on that failed drive, either by copying a working drive in a RAID1 configuration, or by doing calculations with the parity block on RAID4, RAID5 or RAID6.

While this recovery process is happening, the md driver will monitor accesses to the array and will slow down the rate of recovery if other activity is happening, so that normal access to the array will not be unduly affected. When no other activity is happening, the recovery process proceeds at full speed. The actual speed targets for the two different situations can be controlled by the speed_limit_min and speed_limit_max control files mentioned below.

 

KERNEL PARAMETERS

The md driver recognised three different kernel parameters.

raid=noautodetect

This will disable the normal detection of md arrays that happens at boot time. If a drive is partitioned with MS-DOS style partitions, then if any of the 4 main partitions has a partition type of 0xFD, then that partition will normally be inspected to see if it is part of an MD array, and if any full arrays are found, they are started. This kernel paramenter disables this behaviour.

md=n,dev,dev,...

This tells the md driver to assemble /dev/md n from the listed devices. It is only necessary to start the device holding the root filesystem this way. Other arrays are best started once the system is booted.

md=n,l,c,i,dev...

This tells the md driver to assemble a legacy RAID0 or LINEAR array without a superblock. n gives the md device number, l gives the level, 0 for RAID0 or -1 for LINEAR, c gives the chunk size as a base-2 logarithm offset by twelve, so 0 means 4K, 1 means 8K. i is ignored (legacy support).

 

FILES

/proc/mdstat

Contains information about the status of currently running array.

/proc/sys/dev/raid/speed_limit_min

A readable and writable file that reflects the current goal rebuild speed for times when non-rebuild activity is current on an array. The speed is in Kibibytes per second, and is a per-device rate, not a per-array rate (which means that an array with more disc will shuffle more data for a given speed). The default is 100.

/proc/sys/dev/raid/speed_limit_max

A readable and writable file that reflects the current goal rebuild speed for times when no non-rebuild activity is current on an array. The default is 100,000.

 

SEE ALSO

mdadm(8), mkraid(8).

mga

NAME

mga - Matrox video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`mgaN`34`   ... EndSection

 

DESCRIPTION

mga is an Xorg driver for Matrox video cards. The driver is fully accelerated, and provides support for the following framebuffer depths: 8, 15, 16, 24, and an 8+24 overlay mode. All visual types are supported for depth 8, and both TrueColor and DirectColor visuals are supported for the other depths except 8+24 mode which supports PseudoColor, GrayScale and TrueColor. Multi-card configurations are supported. XVideo is supported on G200 and newer systems, with either TexturedVideo or video overlay. The second head of dual-head cards is supported for the G450 and G550. Support for the second head on G400 cards requires a binary-only "mga_hal" module that is available from Matrox <http://www.matrox.com>, and may be on the CD supplied with the card. That module also provides various other enhancements, and may be necessary to use the DVI (digital) output on the G550 (and other cards).  

SUPPORTED HARDWARE

The mga driver supports PCI and AGP video cards based on the following Matrox chips:

MGA2064W

Millennium (original)

MGA1064SG

Mystique

MGA2164W

Millennium II

G100

G200

Millennium G200 and Mystique G200

G400

G450

G550

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The driver auto-detects the chipset type, but the following ChipSet names may optionally be specified in the config file N`34`DeviceN`34` section, and will override the auto-detection:

"mga2064w", "mga1064sg", "mga2164w", "mga2164w agp", "mgag100", "mgag200", "mgag200 pci", "mgag400", "mgag550".

The G450 is Chipset "mgag400" with ChipRev 0x80.

The driver will auto-detect the amount of video memory present for all chips except the Millennium II. In the Millennium II case it defaults to 4096 kBytes. When using a Millennium II, the actual amount of video memory should be specified with a VideoRam entry in the config file N`34`DeviceN`34` section.

The following driver Options are supported:

Option N`34`ColorKeyN`34` N`34`integerN`34`

Set the colormap index used for the transparency key for the depth 8 plane when operating in 8+24 overlay mode. The value must be in the range 2-255. Default: 255.

Option N`34`HWCursorN`34` N`34`booleanN`34`

Enable or disable the HW cursor. Default: on.

Option N`34`MGASDRAMN`34` N`34`booleanN`34`

Specify whether G100, G200 or G400 cards have SDRAM. The driver attempts to auto-detect this based on the card`s PCI subsystem ID. This option may be used to override that auto-detection. The mga driver is not able to auto-detect the presence of of SDRAM on secondary heads in multihead configurations so this option will often need to be specified in multihead configurations. Default: auto-detected.

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`NoHalN`34` N`34`booleanN`34`

Disable or enable loading the "mga_hal" module. Default: the module is loaded when available and when using hardware that it supports.

Option N`34`OverclockMemN`34`

Set clocks to values used by some commercial X-Servers (G100, G200 and G400 only). Default: off.

Option N`34`OverlayN`34` N`34`valueN`34`

Enable 8+24 overlay mode. Only appropriate for depth 24. Recognized values are: "8,24", "24,8". Default: off. (Note: the G100 is unaccelerated in the 8+24 overlay mode due to a missing hardware feature.)

Option N`34`PciRetryN`34` N`34`booleanN`34`

Enable or disable PCI retries. Default: off.

Option N`34`RotateN`34` N`34`CWN`34`

Option N`34`RotateN`34` N`34`CCWN`34`

Rotate the display clockwise or counterclockwise. This mode is unaccelerated. Default: no rotation.

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. Default: off.

Option N`34`SyncOnGreenN`34` N`34`booleanN`34`

Enable or disable combining the sync signals with the green signal. Default: off.

Option N`34`UseFBDevN`34` N`34`booleanN`34`

Enable or disable use of on OS-specific fb interface (and is not supported on all OSs). See fbdevhw(4x) for further information. Default: off.

Option N`34`VideoKeyN`34` N`34`integerN`34`

This sets the default pixel value for the YUV video overlay key. Default: undefined.

Option N`34`TexturedVideoN`34` N`34`booleanN`34`

This has XvImage support use the texture engine rather than the video overlay. This option is only supported by the G200 and G400, and only in 16 and 32 bits per pixel. Default: off.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Radoslaw Kapitan, Mark Vojkovich, and also David Dawes, Guy Desbief, Dirk Hohndel, Doug Merritt, Andrew E. Mileski, Andrew van der Stock, Leonard N. Zubkoff, Andrew C. Aitchison.

microtouch

NAME

microtouch - MicroTouch input driver  

SYNOPSIS

Section N`34`InputDeviceN`34` Identifier N`34`idevnameN`34` Driver N`34`microtouchN`34` Option N`34`DeviceN`34` N`34`devpathN`34`   ... EndSection

 

DESCRIPTION

microtouch is an Xorg input driver for MicroTouch devices...

The microtouch driver functions as a pointer input device, and may be used as the X server`s core pointer. THIS MAN PAGE NEEDS TO BE FILLED IN.  

SUPPORTED HARDWARE

What is supported...  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

Config details...  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

Authors include...

mouse

NAME

mouse - Mouse input driver  

SYNOPSIS

Section N`34`InputDeviceN`34` Identifier N`34`idevnameN`34` Driver N`34`mouseN`34` Option N`34`ProtocolN`34` N`34`protonameN`34` Option N`34`DeviceN`34` N`34`devpathN`34`   ... EndSection

 

DESCRIPTION

mouse is an Xorg input driver for mice. The driver supports most available mouse types and interfaces. USB mice are only supported on some OSs, and the level of support for PS/2 mice depends on the OS.

The mouse driver functions as a pointer input device, and may be used as the X server`s core pointer. Multiple mice are supported by multiple instances of this driver.  

SUPPORTED HARDWARE

There is a detailed list of hardware that the mouse driver supports in the README.mouse document. This can be found in /usr/X11R6/lib/X11/doc/, or online at http://www.xfree86.org/current/mouse.html.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

The driver can auto-detect the mouse type on some platforms On some platforms this is limited to plug and play serial mice, and on some the auto-detection works for any mouse that the OS`s kernel driver supports. On others, it is always necessary to specify the mouse protocol in the config file. The README.mouse document contains some detailed information about this.

The following driver Options are supported:

Option N`34`ProtocolN`34` N`34`stringN`34`

Specify the mouse protocol. Valid protocol types include:

Auto, Microsoft, MouseSystems, MMSeries, Logitech, MouseMan, MMHitTab, GlidePoint, IntelliMouse, ThinkingMouse, ValuMouseScroll, AceCad, PS/2, ImPS/2, ExplorerPS/2, ThinkingMousePS/2, MouseManPlusPS/2, GlidePointPS/2, NetMousePS/2, NetScrollPS/2, BusMouse, SysMouse, WSMouse, USB, Xqueue.

Not all protocols are supported on all platforms. The "Auto" platform specifies that protocol auto-detection should be attempted. There is no default protocol setting, and specifying this option is mandatory.

Option N`34`DeviceN`34` N`34`stringN`34`

Specifies the device through which the mouse can be accessed. A common setting is "/dev/mouse", which is often a symbolic link to the real device. This option is mandatory, and there is no default setting.

Option N`34`ButtonsN`34` N`34`integerN`34`

Specifies the number of mouse buttons. In cases where the number of buttons cannot be auto-detected, the default value is 3.

Option N`34`Emulate3ButtonsN`34` N`34`booleanN`34`

Enable/disable the emulation of the third (middle) mouse button for mice which only have two physical buttons. The third button is emulated by pressing both buttons simultaneously. Default: off

Option N`34`Emulate3TimeoutN`34` N`34`integerN`34`

Sets the timeout (in milliseconds) that the driver waits before deciding if two buttons where pressed "simultaneously" when 3 button emulation is enabled. Default: 50.

Option N`34`ChordMiddleN`34` N`34`booleanN`34`

Enable/disable handling of mice that send left+right events when the middle button is used. Default: off.

Option N`34`EmulateWheelN`34` N`34`booleanN`34`

Enable/disable "wheel" emulation. Wheel emulation means emulating button press/release events when the mouse is moved while a specific real button is pressed. Wheel button events (typically buttons 4 and 5) are usually used for scrolling. Wheel emulation is useful for getting wheel-like behaviour with trackballs. It can also be useful for mice with 4 or more buttons but no wheel. See the description of the EmulateWheelButton, EmulateWheelInertia, XAxisMapping, and YAxisMapping options below. Default: off.

Option N`34`EmulateWheelButtonN`34` N`34`integerN`34`

Specifies which button must be held down to enable wheel emulation mode. While this button is down, X and/or Y pointer movement will generate button press/release events as specified for the XAxisMapping and YAxisMapping settings. Default: 4.

Option N`34`EmulateWheelInertiaN`34` N`34`integerN`34`

Specifies how far (in pixels) the pointer must move to generate button press/release events in wheel emulation mode. Default: 50.

Option N`34`XAxisMappingN`34` N`34`N1 N2N`34`

Specifies which buttons are mapped to motion in the X direction in wheel emulation mode. Button number N1 is mapped to the negative X axis motion and button number N2 is mapped to the positive X axis motion. Default: no mapping.

Option N`34`YAxisMappingN`34` N`34`N1 N2N`34`

Specifies which buttons are mapped to motion in the Y direction in wheel emulation mode. Button number N1 is mapped to the negative Y axis motion and button number N2 is mapped to the positive Y axis motion. Default: "4 5".

Option N`34`ZAxisMappingN`34` N`34`XN`34`

Option N`34`ZAxisMappingN`34` N`34`YN`34`

Option N`34`ZAxisMappingN`34` N`34`N1 N2N`34`

Option N`34`ZAxisMappingN`34` N`34`N1 N2 N3 N4N`34`

Set the mapping for the Z axis (wheel) motion to buttons or another axis (X or Y). Button number N1 is mapped to the negative Z axis motion and button number N2 is mapped to the positive Z axis motion. For mice with two wheels, four button numbers can be specified, with the negative and positive motion of the second wheel mapped respectively to buttons number N3 and N4. Default: no mapping.

Option N`34`FlipXYN`34` N`34`booleanN`34`

Enable/disable swapping the X and Y axes. This transformation is applied after the InvX, InvY and AngleOffset transformations. Default: off.

Option N`34`InvXN`34` N`34`booleanN`34`

Invert the X axis. Default: off.

Option N`34`InvYN`34` N`34`booleanN`34`

Invert the Y axis. Default: off.

Option N`34`AngleOffsetN`34` N`34`integerN`34`

Specify a clockwise angular offset (in degrees) to apply to the pointer motion. This transformation is applied before the FlipXY, InvX and InvY transformations. Default: 0.

Option N`34`SampleRateN`34` N`34`integerN`34`

Sets the number of motion/button events the mouse sends per second. Setting this is only supported for some mice, including some Logitech mice and some PS/2 mice on some platforms. Default: whatever the mouse is already set to.

Option N`34`ResolutionN`34` N`34`integerN`34`

Sets the resolution of the device in counts per inch. Setting this is only supported for some mice, including some PS/2 mice on some platforms. Default: whatever the mouse is already set to.

Option N`34`DragLockButtonsN`34` N`34`L1 B2 L3 B4N`34`

Sets N`34`drag lock buttonsN`34` that simulate holding a button down, so that low dexterity people do not have to hold a button down at the same time they move a mouse cursor. Button numbers occur in pairs, with the lock button number occurring first, followed by the button number that is the target of the lock button.

Option N`34`DragLockButtonsN`34` N`34`M1N`34`

Sets a N`34`master drag lock buttonN`34` that acts as a N`34`Meta KeyN`34` indicating that the next button pressed is to be N`34`drag lockedN`34`.

Option N`34`ClearDTRN`34` N`34`booleanN`34`

Enable/disable clearing the DTR line on the serial port used by the mouse. Some dual-protocol mice require the DTR line to be cleared to operate in the non-default protocol. This option is for serial mice only. Default: off.

Option N`34`ClearRTSN`34` N`34`booleanN`34`

Enable/disable clearing the RTS line on the serial port used by the mouse. Some dual-protocol mice require the RTS line to be cleared to operate in the non-default protocol. This option is for serial mice only. Default: off.

Option N`34`BaudRateN`34` N`34`integerN`34`

Set the baud rate to use for communicating with a serial mouse. This option should rarely be required because the default is correct for almost all situations. Valid values include: 300, 1200, 2400, 4800, 9600, 19200. Default: 1200.

There are some other options that may be used to control various parameters for serial port communication, but they are not documented here because the driver sets them correctly for each mouse protocol type.  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x), README.mouse.

mwmrc

NAME

mwmrc --- the Motif Window Manager Resource Description File  

DESCRIPTION

The mwmrc file is a supplementary resource file that controls much of the behavior of the Motif window manager mwm. It contains descriptions of resources that cannot easily be written using standard X Window System, Version 11 resource syntax. The resource description file contains entries that are referred to by X resources in defaults files (for example, /usr/X11R6/lib/X11/app-defaults/Mwm) or in the RESOURCE_MANAGER property on the root window. For example, the resource description file enables you to specify different types of window menus; however, an X resource is used to specify which of these window menus mwm should use for a particular window.  

Location

The window manager searches for one of the following resource description files, where $LANG is the value of the language environment on a per-user basis:

$HOME/$LANG/.mwmrc $HOME/.mwmrc /usr/X11R6/lib/X11/$LANG/system.mwmrc /usr/X11R6/lib/X11/system.mwmrc

The first file found is the first used. If no file is found, a set of built-in specifications is used. A particular resource description file can be selected using the configFile resource. The following shows how a different resource description file can be specified from the command line:

/usr/X11R6/bin/X11/mwm -xrm "mwm*configFile: mymwmrc"

 

Resource Types

The following types of resources can be described in the mwm resource description file:

Buttons

Window manager functions can be bound (associated) with button events.

Keys

Window manager functions can be bound (associated) with key press events.

Menus

Menu panes can be used for the window menu and other menus posted with key bindings and button bindings.

 

MWM RESOURCE DESCRIPTION FILE SYNTAX

The mwm resource description file is a standard text file that contains items of information separated by blanks, tabs, and new lines characters. Blank lines are ignored. Items or characters can be quoted to avoid special interpretation (for example, the comment character can be quoted to prevent it from being interpreted as the comment character). A quoted item can be contained in double quotes (" "). Single characters can be quoted by preceding them by the back-slash character (). If a line ends with a back-slash, the next line is considered a continuation of that line. All text from an unquoted # to the end of the line is regarded as a comment and is not interpreted as part of a resource description. If ! is the first character in a line, the line is regarded as a comment.  

Window Manager Functions

Window manager functions can be accessed with button and key bindings, and with window manager menus. Functions are indicated as part of the specifications for button and key binding sets, and menu panes. The function specification has the following syntax:

function = function_name [function_args] function_name = window manager function function_args = {quoted_item | unquoted_item}

The following functions are supported. If a function is specified that isn`t one of the supported functions then it is interpreted by mwm as f.nop.

f.beep

This function causes a beep.

f.circle_down [ icon | window]

This function causes the window or icon that is on the top of the window stack to be put on the bottom of the window stack (so that it is no longer obscuring any other window or icon). This function affects only those windows and icons that are obscuring other windows and icons, or that are obscured by other windows and icons. Secondary windows (that is, transient windows) are restacked with their associated primary window. Secondary windows always stay on top of the associated primary window and there can be no other primary windows between the secondary windows and their primary window. If an icon function argument is specified, then the function applies only to icons. If a window function argument is specified then the function applies only to windows.

f.circle_up [ icon | window]

This function raises the window or icon on the bottom of the window stack (so that it is not obscured by any other windows). This function affects only those windows and icons that are obscuring other windows and icons, or that are obscured by other windows and icons. Secondary windows (that is, transient windows) are restacked with their associated primary window. If an icon function argument is specified then the function applies only to icons. If an window function argument is specified then the function applies only to windows.

f.exec command (or ! command)

This function causes command to be executed (using the value of the $MWMSHELL or $SHELL environment variable if set; otherwise, /bin/sh ). The ! notation can be used in place of the f.exec function name.

f.focus_color

This function sets the colormap focus to a client window. If this function is done in a root context, then the default colormap (setup by the X Window System for the screen where mwm is running) is installed and there is no specific client window colormap focus. This function is treated as f.nop if colormapFocusPolicy is not explicit.

f.focus_key

This function sets the keyboard input focus to a client window or icon. This function is treated as f.nop if keyboardFocusPolicy is not explicit or the function is executed in a root context.

f.kill

This function is used to close application windows. The actual processing that occurs depends on the protocols that the application observes. The application lists the protocols it observes in the WM_PROTOCOLS property on its top level window. If the application observes the WM_DELETE_WINDOW protocol, it is sent a message that requests the window be deleted. If the application observes both WM_DELETE_WINDOW and WM_SAVE_YOURSELF, it is sent one message requesting the window be deleted and another message advising it to save its state. If the application observes only the WM_SAVE_YOURSELFprotocol , it is sent a message advising it to save its state. After a delay (specified by the resource quitTimeout), the application`s connection to the X server is terminated. If the application observes neither of these protocols, its connection to the X server is terminated.

f.lower [- client | within | freeFamily]

This function lowers a primary window to the bottom of the global window stack (where it obscures no other window) and lowers the secondary window (transient window or dialog box) within the client family. The arguments to this function are mutually exclusive. The client argument indicates the name or class of a client to lower. The name or class of a client appears in the WM_CLASS property on the client`s top-level window. If the client argument is not specified, the context that the function was invoked in indicates the window or icon to lower. Specifying within lowers the secondary window within the family (staying above the parent) but does not lower the client family in the global window stack. Specifying freeFamily lowers the window to the bottom of the global windows stack from its local family stack.

f.maximize

This function causes a client window to be displayed with its maximum size. Refer to the maximumClientSize, maximumMaximumSize, and limitResize resources in mwm(1).

f.menu menu_name

This function associates a cascading (pull-right) menu with a menu pane entry or a menu with a button or key binding. The menu_name function argument identifies the menu to be used.

f.minimize

This function causes a client window to be minimized (iconified). When a window is minimized with no icon box in use, and if the lowerOnIconify resource has the value True (the default), the icon is placed on the bottom of the window stack (such that it obscures no other window). If an icon box is used, then the client`s icon changes to its iconified form inside the icon box. Secondary windows (that is, transient windows) are minimized with their associated primary window. There is only one icon for a primary window and all its secondary windows.

f.move

This function initiates an interactive move of a client window.

f.next_cmap

This function installs the next colormap in the list of colormaps for the window with the colormap focus.

f.next_key [ icon | window | transient]

This function sets the keyboard input focus to the next window/icon in the set of windows/icons managed by the window manager (the ordering of this set is based on the stacking of windows on the screen). This function is treated as f.nop if keyboardFocusPolicy is not explicit. The keyboard input focus is only moved to windows that do not have an associated secondary window that is application modal. If the transient argument is specified, then transient (secondary) windows are traversed (otherwise, if only window is specified, traversal is done only to the last focused window in a transient group). If an icon function argument is specified, then the function applies only to icons. If a window function argument is specified, then the function applies only to windows.

f.nop

This function does nothing.

f.normalize

This function causes a client window to be displayed with its normal size. Secondary windows (that is, transient windows) are placed in their normal state along with their associated primary window.

f.normalize_and_raise

This function causes a client window to be displayed with its normal size and raised to the top of the window stack. Secondary windows (that is, transient windows) are placed in their normal state along with their associated primary window.

f.pack_icons

This function is used to relayout icons (based on the layout policy being used) on the root window or in the icon box. In general this causes icons to be "packed" into the icon grid.

f.pass_keys

This function is used to enable/disable (toggle) processing of key bindings for window manager functions. When it disables key binding processing all keys are passed on to the window with the keyboard input focus and no window manager functions are invoked. If the f.pass_keys function is invoked with a key binding to disable key binding processing the same key binding can be used to enable key binding processing.

f.post_wmenu

This function is used to post the window menu. If a key is used to post the window menu and a window menu button is present, the window menu is automatically placed with its top-left corner at the bottom-left corner of the window menu button for the client window. If no window menu button is present, the window menu is placed at the top-left corner of the client window.

f.prev_cmap

This function installs the previous colormap in the list of colormaps for the window with the colormap focus.

f.prev_key [ icon | window | transient]

This function sets the keyboard input focus to the previous window/icon in the set of windows/icons managed by the window manager (the ordering of this set is based on the stacking of windows on the screen). This function is treated as f.nop if keyboardFocusPolicy is not explicit. The keyboard input focus is only moved to windows that do not have an associated secondary window that is application modal. If the transient argument is specified, then transient (secondary) windows are traversed (otherwise, if only window is specified, traversal is done only to the last focused window in a transient group). If an icon function argument is specified then the function applies only to icons. If an window function argument is specified then the function applies only to windows.

f.quit_mwm

This function terminates mwm (but NOT the X window system).

f.raise [-client | within | freeFamily]

This function raises a primary window to the top of the global window stack (where it is obscured by no other window) and raises the secondary window (transient window or dialog box) within the client family. The arguments to this function are mutually exclusive. The client argument indicates the name or class of a client to lower. If the client is not specified, the context that the function was invoked in indicates the window or icon to lower. Specifying within raises the secondary window within the family but does not raise the client family in the global window stack. Specifying freeFamily raises the window to the top of its local family stack and raises the family to the top of the global window stack.

f.raise_lower [ within | freeFamily]

This function raises a primary window to the top of the global window stack if it is partially obscured by another window; otherwise, it lowers the window to the bottom of the window stack. The arguments to this function are mutually exclusive. Specifying within raises a secondary window within the family (staying above the parent window), if it is partially obscured by another window in the application`s family; otherwise, it lowers the window to the bottom of the family stack. It has no effect on the global window stacking order. Specifying freeFamily raises the window to the top of its local family stack, if obscured by another window, and raises the family to the top of the global window stack; otherwise, it lowers the window to the bottom of its local family stack and lowers the family to the bottom of the global window stack.

f.refresh

This function causes all windows to be redrawn.

f.refresh_win

This function causes a client window to be redrawn.

f.resize

This function initiates an interactive resize of a client window.

f.restore

This function restores the previous state of an icon`s associated window. If a maximized window is iconified, then f.restore restores it to its maximized state. If a normal window is iconified, then f.restore restores it to its normalized state.

f.restore_and_raise

This function restores the previous state of an icon`s associated window and raises the window to the top of the window stack. If a maximized window is iconified, then f.restore_and_raise restores it to its maximized state and raises it to the top of the window stack. If a normal window is iconified, then f.restore_and_raise restores it to its normalized state and raises it to the top of the window stack.

f.restart

This function causes mwm to be restarted (effectively terminated and re-executed). Restart is necessary for mwm to incorporate changes in both the mwmrc file and X resources.

f.screen [ next | prev | back | screen_number]

This function causes the pointer to be warp to a specific screen number or to the next, previous, or last visited (back) screen. The arguments to this function are mutually exclusive. The screen_number argument indicates the screen number that the pointer is to be warped. Screens are numbered starting from screen 0. Specifying next cause the pointer to warp to the next managed screen (skipping over any unmanaged screens). Specifying prev cause the pointer to warp to the previous managed screen (skipping over any unmanaged screens). Specifying back cause the pointer to warp to the last visited screen.

f.send_msg message_number

This function sends an XClientMessageEvent of type _MOTIF_WM_MESSAGES with message_type set to message_number. The client message is sent only if message_number is included in the client`s _MOTIF_WM_MESSAGES property. A menu item label is grayed out if the menu item is used to do f.send_msg of a message that is not included in the client`s _MOTIF_WM_MESSAGES property.

f.separator

This function causes a menu separator to be put in the menu pane at the specified location (the label is ignored).

f.set_behavior

This function causes the window manager to restart with the default behavior (if a custom behavior is configured) or a custom behavior (if a default behavior is configured). By default this is bound to Shift Ctrl Alt <Key>!.

f.title

This function inserts a title in the menu pane at the specified location.

f.version

This function causes the window manager to display its release version in a dialog box.

 

Function Constraints

Each function may be constrained as to which resource types can specify the function (for example, menu pane) and also what context the function can be used in (for example, the function is done to the selected client window). Function contexts are:

root

No client window or icon has been selected as an object for the function.

window

A client window has been selected as an object for the function. This includes the window`s title bar and frame. Some functions are applied only when the window is in its normalized state (for example, f.maximize) or its maximized state (for example, f.normalize).

icon

An icon has been selected as an object for the function.

If a function is specified in a type of resource where it is not supported or is invoked in a context that does not apply then the function is treated as f.nop. The following table indicates the resource types and function contexts in which window manager functions apply.

Function	Contexts	Resources
f.beep	root,icon,window	button,key,menu
f.circle_down	root,icon,window	button,key,menu
f.circle_up	root,icon,window	button,key,menu
f.exec	root,icon,window	button,key,menu
f.focus_color	root,icon,window	button,key,menu
f.focus_key	root,icon,window	button,key,menu
f.kill	icon,window	button,key,menu
f.lower	root,icon,window	button,key,menu
f.maximize	icon,window(normal)	button,key,menu
f.menu	root,icon,window	button,key,menu
f.minimize	window	button,key,menu
f.move	icon,window	button,key,menu
f.next_cmap	root,icon,window	button,key,menu
f.next_key	root,icon,window	button,key,menu
f.nop	root,icon,window	button,key,menu
f.normalize	icon,window(maximized)	button,key,menu
f.normalize_and_raise	icon,window	button,key,menu
f.pack_icons	root,icon,window	button,key,menu
f.pass_keys	root,icon,window	button,key,menu
f.post_wmenu	root,icon,window	button,key
f.prev_cmap	root,icon,window	button,key,menu
f.prev_key	root,icon,window	button,key,menu
f.quit_mwm	root	button,key,menu (root only)
f.raise	root,icon,window	button,key,menu
f.raise_lower	icon,window	button,key,menu
f.refresh	root,icon,window	button,key,menu
f.refresh_win	window	button,key,menu
f.resize	window	button,key,menu
f.restart	root	button,key,menu (root only)
f.restore	icon,window	button,key,menu
f.restore_and_raise	icon,window	button,key,menu
f.screen	root,icon,window	button,key,menu
f.send_msg	icon,window	button,key,menu
f.separator	root,icon,window	menu
f.set_behavior	root,icon,window	button,key,menu
f.title	root,icon,window	menu
f.version	root,icon,window	button,key,menu

 

WINDOW MANAGER EVENT SPECIFICATION

Events are indicated as part of the specifications for button and key binding sets, and menu panes. Button events have the following syntax:

button =~[modifier_list ]<button_event_name > modifier_list =~modifier_name { modifier_name}

The following table indicates the values that can be used for modifier_name. Note that [Alt] and [Meta] can be used interchangably on some hardware.

Modifier	Description
Ctrl	Control Key
Shift	Shift Key
Alt	Alt Key
Meta	Meta Key
Mod1	Modifier1
Mod2	Modifier2
Mod3	Modifier3
Mod4	Modifier4
Mod5	Modifier5

Locking modifiers are ignored when processing button and key bindings. The following table lists keys that are interpreted as locking modifiers. The X server may map some of these symbols to the Mod1 - Mod5 modifier keys. These keys may or may not be available on your hardware: Key Symbol Caps Lock Shift Lock Kana Lock Num Lock Scroll Lock The following table indicates the values that can be used for button_event_name.

Button	Description
Btn1Down	Button 1 Press
Btn1Up	Button 1 Release
Btn1Click	Button 1 Press and Release
Btn1Click2	Button 1 Double Click
Btn2Down	Button 2 Press
Btn2Up	Button 2 Release
Btn2Click	Button 2 Press and Release
Btn2Click2	Button 2 Double Click
Btn3Down	Button 3 Press
Btn3Up	Button 3 Release
Btn3Click	Button 3 Press and Release
Btn3Click2	Button 3 Double Click
Btn4Down	Button 4 Press
Btn4Up	Button 4 Release
Btn4Click	Button 4 Press and Release
Btn4Click2	Button 4 Double Click
Btn5Down	Button 5 Press
Btn5Up	Button 5 Release
Btn5Click	Button 5 Press and Release
Btn5Click2	Button 5 Double Click

Key events that are used by the window manager for menu mnemonics and for binding to window manager functions are single key presses; key releases are ignored. Key events have the following syntax:

key =~[modifier_list] <Key>key_name modifier_list =~modifier_name { modifier_name}

All modifiers specified are interpreted as being exclusive (this means that only the specified modifiers can be present when the key event occurs). Modifiers for keys are the same as those that apply to buttons. The key_name is an X11 keysym name. Keysym names can be found in the keysymdef.h file (remove the XK_ prefix).  

BUTTON BINDINGS

The buttonBindings resource value is the name of a set of button bindings that are used to configure window manager behavior. A window manager function can be done when a button press occurs with the pointer over a framed client window, an icon or the root window. The context for indicating where the button press applies is also the context for invoking the window manager function when the button press is done (significant for functions that are context sensitive). The button binding syntax is

Buttons bindings_set_name { button context function button context function ... button context function }

The syntax for the context specification is: context = object[| context] object = root | icon | window | title | frame | border | app The context specification indicates where the pointer must be for the button binding to be effective. For example, a context of window indicates that the pointer must be over a client window or window management frame for the button binding to be effective. The frame context is for the window management frame around a client window (including the border and titlebar), the border context is for the border part of the window management frame (not including the titlebar), the title context is for the title area of the window management frame, and the app context is for the application window (not including the window management frame). If an f.nop function is specified for a button binding, the button binding is not done.  

KEY BINDINGS

The keyBindings resource value is the name of a set of key bindings that are used to configure window manager behavior. A window manager function can be done when a particular key is pressed. The context in which the key binding applies is indicated in the key binding specification. The valid contexts are the same as those that apply to button bindings. The key binding syntax is:

Keys bindings_set_name { key context function key context function ... key context function }

If an f.nop function is specified for a key binding, the key binding is not done. If an f.post_wmenu or f.menu function is bound to a key, mwm automatically uses the same key for removing the menu from the screen after it has been popped up. The context specification syntax is the same as for button bindings with one addition. The context ifkey may be specified for binding keys that may not be available on all displays. If the key is not available and if ifkey is in the context, then reporting of the error message to the error log is suppressed. This feature is useful for networked, heterogeneous environments. For key bindings, the frame, title, border, and app contexts are equivalent to the window context. The context for a key event is the window or icon that has the keyboard input focus (root if no window or icon has the keyboard input focus).  

MENU PANES

Menus can be popped up using the f.post_wmenu and f.menu window manager functions. The context for window manager functions that are done from a menu is root, icon or window depending on how the menu was popped up. In the case of the window menu or menus popped up with a key binding, the location of the keyboard input focus indicates the context. For menus popped up using a button binding, the context of the button binding is the context of the menu. The menu pane specification syntax is:

Menu menu_name { label [mnemonic] [accelerator ] function label [mnemonic] [accelerator ] function ... label [mnemonic] [accelerator ] function }

Each line in the Menu specification identifies the label for a menu item and the function to be done if the menu item is selected. Optionally a menu button mnemonic and a menu button keyboard accelerator may be specified. Mnemonics are functional only when the menu is posted and keyboard traversal applies. The label may be a string or a bitmap file. The label specification has the following syntax:

label = text | bitmap_file bitmap_file = @file_name text = quoted_item | unquoted_item

The string encoding for labels must be compatible with the menu font that is used. Labels are greyed out for menu items that do the f.nop function or an invalid function or a function that doesn`t apply in the current context. A mnemonic specification has the following syntax:

mnemonic = _ character

The first matching character in the label is underlined. If there is no matching character in the label, no mnemonic is registered with the window manager for that label. Although the character must exactly match a character in the label, the mnemonic does not execute if any modifier (such as Shift) is pressed with the character key. The accelerator specification is a key event specification with the same syntax as is used for key bindings to window manager functions.  

INCLUDING FILES

You may include other files into your mwmrc file by using the include construct. For example,

INCLUDE { /usr/local/shared/mwm.menus /home/kmt/personal/my.bindings }

causes the files named to be read in and interpreted in order as an additional part of the mwmrc file. Include is a top-level construct. It cannot be nested inside another construct.  

WARNINGS

Errors that occur during the processing of the resource description file are recorded in: $HOME/.mwm/errorlog. Be sure to check this file if the appearance or behavior of mwm is not what you expect.  

FILES

$HOME/$LANG/.mwmrc $HOME/.mwmrc /usr/X11R6/lib/X11/$LANG/system.mwmrc /usr/X11R6/lib/X11/system.mwmrc

 

RELATED INFORMATION

mwm(1), X(1).

newport

NAME

newport - Newport video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`newportN`34`   ... EndSection

 

DESCRIPTION

newport is an Xorg driver for the SGI Indy`s and Indigo2`s newport video cards.  

SUPPORTED HARDWARE

The newport driver supports the Newport (also called XL) cards found in SGI Indys and Indigo2s. It supports both the 8bit and 24bit versions of the Newport.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The following driver options are supported:

Option N`34`bitplanesN`34` N`34`integerN`34`

number of bitplanes of the board (8 or 24) Default: auto-detected.

Option N`34`HWCursorN`34` N`34`booleanN`34`

Enable or disable the HW cursor. Default: on.

Option N`34`BusIDN`34` N`34`integerN`34`

Set to 1 for the Indigo2 XL. Default: 0

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors: Guido GÜnther agx@sigxcpu.org

null

NAME

null, zero - data sink  

DESCRIPTION

Data written on a null or zero special file is discarded.

Reads from the null special file always return end of file, whereas reads from zero always return characters.

null and zero are typically created by:

mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
chown root:mem /dev/null /dev/zero

 

NOTES

If these devices are not writable and readable for all users, many programs will act strange.  

FILES

/dev/null
/dev/zero  

SEE ALSO

chown(1), mknod(1)

palmax

NAME

palmax - Palmax (TR88L803) touchscreen driver  

SYNOPSIS

Section N`34`InputDeviceN`34`
Identifier N`34`idevnameN`34`
Driver N`34`palmaxN`34`
Option N`34`DeviceN`34` N`34`devpathN`34`
  ...
EndSection  

DESCRIPTION

palmax is an Xorg input driver for the Palmax PD1000/PD1100

The palmax driver functions as a pointer input device, and is normally used as the X server`s core pointer. It supports positioning and mouse buttons using the touchscreen display and lid buttons on the Palmax machines.  

SUPPORTED HARDWARE

Palmax PD1000, Palmax PD1100. In theory also any other system using a TR88L803 wired to a serial port.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

The following driver options are supported

Option N`34`MinXN`34` N`34`integerN`34`

Set the left hand X value from the touchscreen, for calibration.

Option N`34`MaxXN`34` N`34`integerN`34`

Set the right hand X value from the touchscreen, for calibration.

Option N`34`MinYN`34` N`34`integerN`34`

Set the top Y value from the touchscreen, for calibration.

Option N`34`MaxYN`34` N`34`integerN`34`

Set the bottom Y value from the touchscreen, for calibration.

Option N`34`ScreenN`34` N`34`integerN`34`

The screen to attach to the touchscreen when running with multiple screens. The default is screen 0.

Option N`34`DeviceN`34` N`34`stringN`34`

The serial port that is attached to the touchscreen interface. On the Palmax PD1000 and PD1100 this is ttyS0.

Option N`34`DeviceNameN`34` N`34`stringN`34`

Set the X11 device name for the touchscreen. This defaults to TOUCHSCREEN.

Option N`34`PortraitModeN`34` N`34`stringN`34`

Set the display orientation. The default is "landscape" but you can rotate the screen clockwise ("portrait") or anticlockwise ("portraitCCW").

Option N`34`SwapXYN`34` N`34`booleanN`34`

Swap the X and Y values on the display. The default is false.

Option N`34`TapButtonN`34` N`34`booleanN`34`

Set the touchscreen tap to act as mouse button 1. This allows single handed operation except when using the menu buttons. The default is false.

 

BUGS

The driver has been tested on the Palmax systems, the defaults reflect the Palmax hardware and should work out of the box. No testing has been done on other systems using the same digitizer.

Support for a double-tap menu button option would be nice.

The smoothing algorithm would benefit from real mathematics.

Xorg needs a nice calibration tool.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

Authors include...
 Alan Cox

port

NAME

mem, kmem, port - system memory, kernel memory and system ports  

DESCRIPTION

Mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system.

Byte addresses in mem are interpreted as physical memory addresses. References to non-existent locations cause errors to be returned.

Examining and patching is likely to lead to unexpected results when read-only or write-only bits are present.

It is typically created by:

mknod -m 660 /dev/mem c 1 1
chown root:mem /dev/mem

The file kmem is the same as mem, except that the kernel virtual memory rather than physical memory is accessed.

It is typically created by:

mknod -m 640 /dev/kmem c 1 2
chown root:mem /dev/kmem

Port is similar to mem, but the IO ports are accessed.

It is typically created by:

mknod -m 660 /dev/port c 1 4
chown root:mem /dev/port

 

FILES

/dev/mem
/dev/kmem
/dev/port  

SEE ALSO

chown(1), mknod(1), ioperm(2)

pts

NAME

ptmx and pts - pseudo-terminal master and slave  

DESCRIPTION

The file /dev/ptmx is a character file with major number 5 and minor number 2, usually of mode 0666 and owner.group of root.root. It is used to create a pseudo-terminal master and slave pair.

When a process opens /dev/ptmx, it gets a file descriptor for a pseudo-terminal master (PTM), and a pseudo-terminal slave (PTS) device is created in the /dev/pts directory. Each file descriptor obtained by opening /dev/ptmx is an independent PTM with its own associated PTS, whose path can be found by passing the descriptor to ptsname(3).

Before opening the pseudo-terminal slave, you must pass the master`s file descriptor to grantpt(3) and unlockpt(3).

Once both the pseudo-terminal master and slave are open, the slave provides processes with an interface that is identical to that of a real terminal.

Data written to the slave is presented on the master descriptor as input. Data written to the master is presented to the slave as input.

In practice, pseudo-terminals are used for implementing terminal emulators such as xterm(1), in which data read from the pseudo-terminal master is interpreted by the application in the same way a real terminal would interpret the data, and for implementing remote-login programs such as sshd(8), in which data read from the pseudo-terminal master is sent across the network to a client program that is connected to a terminal or terminal emulator.

Pseudo-terminals can also be used to send input to programs that normally refuse to read input from pipes (such as su(8), and passwd(8)).  

FILES

/dev/ptmx, /dev/pts/*  

NOTES

The Linux support for the above (known as Unix98 pty naming) is done using the devpts filesystem, that should be mounted on /dev/pts.

Before this Unix98 scheme, master ptys were called /dev/ptyp0, ... and slave ptys /dev/ttyp0, ... and one needed lots of preallocated device nodes.  

SEE ALSO

getpt(3), grantpt(3), ptsname(3), unlockpt(3)

random

NAME

random, urandom - kernel random number source devices  

DESCRIPTION

The character special files /dev/random and /dev/urandom (present since Linux 1.3.30) provide an interface to the kernel`s random number generator. File /dev/random has major device number 1 and minor device number 8. File /dev/urandom has major device number 1 and minor device number 9.

The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created.

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

When read, /dev/urandom device will return as many bytes as are requested. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.  

CONFIGURING

If your system does not have /dev/random and /dev/urandom created already, they can be created with the following commands:

mknod -m 644 /dev/random c 1 8 mknod -m 644 /dev/urandom c 1 9 chown root:root /dev/random /dev/urandom

  When a Linux system starts up without much operator interaction, the entropy pool may be in a fairly predictable state. This reduces the actual amount of noise in the entropy pool below the estimate. In order to counteract this effect, it helps to carry entropy pool information across shut-downs and start-ups. To do this, add the following lines to an appropriate script which is run during the Linux system start-up sequence:

echo "Initializing kernel random number generator..." # Initialize kernel random number generator with random seed # from last shut-down (or start-up) to this start-up. Load and # then save 512 bytes, which is the size of the entropy pool. if [ -f /var/random-seed ]; then cat /var/random-seed >/dev/urandom fi dd if=/dev/urandom of=/var/random-seed count=1

Also, add the following lines in an appropriate script which is run during the Linux system shutdown:
 

# Carry a random seed from shut-down to start-up for the random # number generator. Save 512 bytes, which is the size of the # random number generator`s entropy pool. echo "Saving random seed..." dd if=/dev/urandom of=/var/random-seed count=1

 

PROC INTERFACE

The files in the directory /proc/sys/kernel/random (present since 2.3.16) provide an additional interface to the /dev/random device.

The read-only file entropy_avail gives the available entropy. Normally, this will be 4096 (bits), a full entropy pool.

The file poolsize gives the size of the entropy pool. Normally, this will be 512 (bytes). It can be changed to any value for which an algorithm is available. Currently the choices are 32, 64, 128, 256, 512, 1024, 2048.

The file read_wakeup_threshold contains the number of bits of entropy required for waking up processes that sleep waiting for entropy from /dev/random. The default is 64. The file write_wakeup_threshold contains the number of bits of entropy below which we wake up processes that do a select() or poll() for write access to /dev/random. These values can be changed by writing to the files.

The read-only files uuid and boot_id contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9. The former is generated afresh for each read, the latter was generated once.  

FILES

/dev/random
/dev/urandom  

AUTHOR

The kernel`s random number generator was written by Theodore Ts`o (tytso@athena.mit.edu).  

SEE ALSO

mknod (1)
RFC 1750, "Randomness Recommendations for Security"

s3virge

NAME

s3virge - S3 ViRGE video driver  

SYNOPSIS

Section N`34`DeviceN`34`
Identifier N`34`devnameN`34`
Driver N`34`s3virgeN`34`
  ...
  [ Option "optionname" ["optionvalue"]]
EndSection  

DESCRIPTION

s3virge is an Xorg driver for S3 based video cards. The driver is fully accelerated, and provides support for the following framebuffer depths: 8, 15, 16, and 24. All visual types are supported for depth 8, and TrueColor visuals are supported for the other depths. XVideo hardware up scaling is supported in depth 16 and 24 on the DX, GX, GX2, MX, MX+, and Trio3D/2X. Doublescan modes are supported and tested in depth 8 and 16 on DX, but disable XVideo. Doublescan modes on other chipsets are untested.  

SUPPORTED HARDWARE

The s3virge driver supports PCI and AGP video cards based on the following S3 chips:

ViRGE

86C325

ViRGE VX

86C988

ViRGE DX

86C375

ViRGE GX

86C385

ViRGE GX2

86C357

ViRGE MX

86C260

ViRGE MX+

86C280

Trio 3D

86C365

Trio 3D/2X

86C362, 86C368

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver. All options names are case and white space insensitive when parsed by the server, for example, "virge vx" and "VIRGEvx" are equivalent.

The driver auto-detects the chipset type, but the following ChipSet names may optionally be specified in the config file N`34`DeviceN`34` section, and will override the auto-detection:

"virge", "86c325", "virge vx", "86c988", "virge dx", "86c375", "virge gx", "86c385", "virge gx2", "86c357", "virge mx", "86c260", "virge mx+", "86c280", "trio 3d", "86c365", "trio 3d/2x", "86c362", "86c368".

The following Cursor Options are supported:

Option N`34`HWCursorN`34` [N`34`booleanN`34`]

Enable or disable the HW cursor. Default: on.

Option N`34`SWCursorN`34` [N`34`booleanN`34`]

Inverse of "HWCursor". Default: off.

The following display Options are supported:

Option N`34`ShadowFBN`34` [N`34`booleanN`34`]

Use shadow framebuffer. Disables HW acceleration. Default: off.

Option N`34`RotateN`34` N`34`cw | ccwN`34`

Rotate the screen CW - clockwise or CCW - counter clockwise. Disables HW Acceleration and HW Cursor, uses ShadowFB. Default: no rotation.

Option N`34`XVideoN`34` [N`34`booleanN`34`]

Disable XVideo support by using the off option. This changes FIFO settings which prevent screen noise for high-res modes. Default: on

The following video memory Options are supported:

Option N`34`slow_edodramN`34`

Switch the standard ViRGE to 2-cycle edo mode. Try this if you encounter pixel corruption on the ViRGE. Using this option will cause a large decrease in performance. Default: off.

Option N`34`fpm_vramN`34`

Switch the ViRGE/VX to fast page mode vram mode. Default: off.

Option N`34`slow_dram | fast_dramN`34`

Change Trio 3D and 3D/2X memory options. Default: Use BIOS defaults.

Option N`34`early_ras_precharge | late_ras_prechargeN`34`

adjust memory parameters. One of these will us the same settings as your video card defaults, and using neither in the config file does the same. Default: none.

Option N`34`set_mclkN`34` N`34`integerN`34`

sets the memory clock, where integer is in kHz, and integer <= 100000. Default: probe the memory clock value, and use it at server start.

Option N`34`set_refclkN`34` N`34`integerN`34`

sets the ref clock for ViRGE MX, where integer is in kHz. Default: probe the memory clock value, and use it at server start.

The following acceleration and graphics engine Options are supported:

Option N`34`NoAccelN`34`

Disable acceleration. Very useful for determining if the driver has problems with drawing and acceleration routines. This is the first option to try if your server runs but you see graphic corruption on the screen. Using it decreases performance, as it uses software emulation for drawing operations the video driver can accelerate with hardware. Default: acceleration is enabled.

Option N`34`UseFBN`34`

There are two framebuffer rendering methods. fb and cfb. Both are available in the driver. fb is the newer and default method. To switch back to cfb use this option with no, off or other negative parameter. Default: on.

Option N`34`fifo_aggressive | fifo_moderate | fifo_conservativeN`34`

alter the settings for the threshold at which the pixel FIFO takes over the internal memory bus to refill itself. The smaller this threshold, the better the acceleration performance of the card. You may try the fastest setting (fifo_aggressive) and move down if you encounter pixel corruption. The optimal setting will probably depend on dot-clock and on color depth. Note that specifying any of these options will also alter other memory settings which may increase performance, so trying fifo_conservative will in most cases be a slight benefit (this uses the chip defaults). If pixel corruption or transient streaking is observed during drawing operations then removing any fifo options is recommended. Default: none.

The following PCI bus Options are supported:

Option N`34`pci_burstN`34` [N`34`booleanN`34`]

will enable PCI burst mode. This should work on all but a few broken PCI chipsets, and will increase performance. Default: off.

Option N`34`pci_retryN`34` [N`34`booleanN`34`]

will allow the driver to rely on PCI Retry to program the ViRGE registers. pci_burst must be enabled for this to work. This will increase performance, especially for small fills/blits, because the driver does not have to poll the ViRGE before sending it commands to make sure it is ready. It should work on most recent PCI chipsets. Default: off.

The following ViRGE MX LCD Options are supported:

Option N`34`lcd_centerN`34`

Option N`34`set_lcdclkN`34` N`34`integerN`34`

allows setting the clock for a ViRGE MX LCD display. integer is in Hz. Default: use probed value.

The following additional Options are supported:

Option N`34`ShowCacheN`34` [N`34`booleanN`34`]

Enable or disable viewing offscreen cache memory. A development debug option. Default: off.

Option N`34`mx_cr3a_fixN`34` [N`34`booleanN`34`]

Enable or disable a cr3a fix added for ViRGE MX. Default: on.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)

 

KNOWN BUGS

The VideoRam generic driver parameter is presently ignored by the s3virge driver. On PPC this is reported to cause problems for 2M cards, because they may autodetect as 4M.

 

SUPPORT

For assistance with this driver, or Xorg in general, check the web site at http://www.x.org. If you find a problem with Xorg or have a question not answered in the FAQ please use our bug report form available on the web site. When reporting problems with the driver send as much detail as possible, including chipset type, a server output log, and operating system specifics.

 

AUTHORS

Kevin Brosius, Matt Grossman, Harald Koenig, Sebastien Marineau, Mark Vojkovich.

sd

NAME

sd - Driver for SCSI Disk Drives  

SYNOPSIS

#include <linux/hdreg.h> /* for HDIO_GETGEO */ #include <linux/fs.h> /* for BLKGETSIZE and BLKRRPART */  

CONFIG

The block device name has the following form: sdlp, where l is a letter denoting the physical drive, and p is a number denoting the partition on that physical drive. Often, the partition number, p, will be left off when the device corresponds to the whole drive.

SCSI disks have a major device number of 8, and a minor device number of the form (16 * drive_number) + partition_number, where drive_number is the number of the physical drive in order of detection, and partition_number is as follows:

partition 0 is the whole drive
partitions 1-4 are the DOS "primary" partitions
partitions 5-8 are the DOS "extended" (or "logical") partitions

For example, /dev/sda will have major 8, minor 0, and will refer to all of the first SCSI drive in the system; and /dev/sdb3 will have major 8, minor 19, and will refer to the third DOS "primary" partition on the second SCSI drive in the system.

At this time, only block devices are provided. Raw devices have not yet been implemented.  

DESCRIPTION

The following ioctls are provided:

HDIO_GETGEO

Returns the BIOS disk parameters in the following structure:

struct hd_geometry { unsigned char heads; unsigned char sectors; unsigned short cylinders; unsigned long start; };

A pointer to this structure is passed as the ioctl(2) parameter.

The information returned in the parameter is the disk geometry of the drive as understood by DOS! This geometry is not the physical geometry of the drive. It is used when constructing the drive`s partition table, however, and is needed for convenient operation of fdisk(1), efdisk(1), and lilo(1). If the geometry information is not available, zero will be returned for all of the parameters.

BLKGETSIZE

Returns the device size in sectors. The ioctl(2) parameter should be a pointer to a long.

BLKRRPART

Forces a re-read of the SCSI disk partition tables. No parameter is needed.

The scsi(4) ioctls are also supported. If the ioctl(2) parameter is required, and it is NULL, then ioctl() will return -EINVAL.

 

FILES

/dev/sd[a-h]: the whole device
/dev/sd[a-h][0-8]: individual block partitions  

SEE ALSO

scsi(4)

sis

NAME

sis - SiS video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`sisN`34`   ... EndSection

 

DESCRIPTION

sis is an XFree86 driver for SiS (Silicon Integrated Systems) video chips. The driver is accelerated, and provides support for colordepths of 8, 16 and 24 bpp. XVideo, Render and other extensions are supported as well.  

SUPPORTED HARDWARE

The sis driver supports PCI and AGP video cards based on the following chipsets:

SiS5597/5598 SiS530/620 SiS6326/AGP/DVD SiS300/305 SiS540 SiS630/730 SiS315/H/PRO SiS550/551/552 SiS650/651/M650/661FX/M661FX/M661MX/740/741/741GX/M741 SiS330 (Xabre) SiS760/M760

In the following text, the following terms are used:

old series for SiS5597/5598, 530/620 and 6326/AGP/DVD

300 series for SiS300/305, 540 and 630/730

315/330 series for SiS315, 55x and (M)65x/(M)661xX/74x(GX), 330, 760

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

Detailed information on all supported options can be obtained at http://www.winischhofer.net/linuxsisvga.shtml

This manpage only covers a subset of the supported options.

1. For all supported chipsets

The following driver Options are supported on all chipsets:

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable 2D acceleration. Default: acceleration is enabled.

Option N`34`HWCursorN`34` N`34`booleanN`34`

Enable or disable the HW cursor. Default: HWCursor is on.

Option N`34`SWCursorN`34` N`34`booleanN`34`

The opposite of HWCursor. Default: SWCursor is off.

Option N`34`RotateN`34` N`34`CWN`34`

Rotate the display clockwise. This mode is unaccelerated, and uses the Shadow Frame Buffer layer. Using this option disables the Resize and Rotate extension (RandR). Default: no rotation.

Option N`34`RotateN`34` N`34`CCWN`34`

Rotate the display counterclockwise. This mode is unaccelerated, and uses the Shadow Frame Buffer layer. Using this option disables the Resize and Rotate extension (RandR). Default: no rotation.

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. Default: Shadow framebuffer is off.

Option N`34`CRT1GammaN`34` N`34`booleanN`34`

Enable or disable gamma correction. Default: Gamma correction is on.

2. Old series specific information

The driver will auto-detect the amount of video memory present for all these chips, but in the case of the 6326, it will limit the memory size to 4MB. This is because the 6326`s 2D engine can only address 4MB. The remaining memory seems to be intended for 3D texture data, since only the 3D engine can address RAM above 4MB. However, you can override this limitation using the N`34`VideoRAMN`34` option in the Device section if your board has more than 4MB and you need to use it. However, 2D acceleration, Xvideo and the HWCursor will be disabled in this case.

The driver will also auto-detect the maximum dotclock and DAC speed. If you have problems getting high resolutions because of dot clock limitations, try using the N`34`DacSpeedN`34` option, also in the Device section. However, this is not recommended for the 6326. For this chip, the driver has two built-in modes for high resolutions which you should use instead. These are named N`34`SIS1280x1024-75N`34` and N`34`SIS1600x1200-60N`34` and they will be added to the list of default modes. To use these modes, just place them in your Screen section. Example:

Modes N`34`SIS1600x1200-60N`34` N`34`SIS1280x1024x75N`34` N`34`1024x768N`34` ...

Of these modes, 1280x1024 is only available at 8, 15 and 16bpp. 1600x1200 is available at 8bpp only.

TV support for the 6326

TV output is supported for the 6326. The driver will auto detect a TV connected and in this case add the following modes to the list of default modes: "PAL800x600", "PAL800x600U", "PAL720x540", "PAL640x480", "NTSC640x480", "NTSC640x480U" and "NTSC640x400". Use these modes like the hi-res modes described above.

The following driver Options are supported on the old series:

Option N`34`TurboQueueN`34` N`34`booleanN`34`

Enable or disable TurboQueue mode. Default: off for SIS530/620, on for the others

Option N`34`FastVramN`34` N`34`booleanN`34`

Enable or disable FastVram mode. Enabling this sets the video RAM timing to one cycle per read operation instead of two cycles. Disabling this will set two cycles for read and write operations. Leaving this option out uses the default, which varies depending on the chipset.

Option N`34`NoHostBusN`34` N`34`booleanN`34`

(SiS5597/5598 only). Disable CPU-to-VGA host bus support. This speeds up CPU to video RAM transfers. Default: Host bus is enabled.

Option N`34`NoXVideoN`34` N`34`booleanN`34`

Disable XV (XVideo) extension support. Default: XVideo is on.

Option N`34`NoYV12N`34` N`34`booleanN`34`

Disable YV12 Xv support. This might me required due to hardware bugs in some chipsets. Disabling YV12 support forces Xv-aware applications to use YUV2 or XShm for video output. Default: YV12 support is on.

Option N`34`TVStandardN`34` N`34`stringN`34`

(6326 only) Valid parameters are PAL or NTSC. The default is set by a jumper on the card.

Option N`34`TVXPosOffsetN`34` N`34`integerN`34`

(6326 only) This option allows tuning the horizontal position of the image for TV output. The range is from -16 to 16. Default: 0

Option N`34`TVYPosOffsetN`34` N`34`integerN`34`

(6326 only) This option allows tuning the vertical position of the image for TV output. The range is from -16 to 16. Default: 0

Option N`34`SIS6326TVEnableYFilterN`34` N`34`booleanN`34`

(6326 only) This option allows enabling/disabling the Y (chroma) filter for TV output.

Option N`34`SIS6326TVAntiFlickerN`34` N`34`stringN`34`

(6326 only) This option allow enabling/disabling the anti flicker facility for TV output. Possible parameters are OFF, LOW, MED, HIGH or ADAPTIVE. By experience, ADAPTIVE yields the best results, hence it is the default.

2. 300 and 315/330 series specific information

The 300 and 315/330 series feature two CRT controllers and very often come with a video bridge for controlling LCD and TV output. Hereinafter, the term CRT1 refers to the VGA output of the chip, and CRT2 refers to either LCD, TV or secondary VGA. Due to timing reasons, only one CRT2 output can be active at the same time. But this limitation does not apply to using CRT1 and CRT2 at the same time which makes it possible to run the driver in dual head mode.

The driver supports the following video bridges:

SiS301 SiS301B(-DH) SiS301C SiS301LV SiS302(E)LV

Instead of a video bridge, some machines have a third party LVDS transmitter to control LCD panels, and/or a Chrontel 7005 or 7019 for TV output. All these are supported as well.

About TV output

The driver fully supports standard (PAL, NTSC, PAL-N, PAL-M) S-video or composite output as well as high definition TV (HDTV) output via YPbPr plugs. For more information on HDTV, please consult the author`s website.

As regards S-video and CVBS output, the SiS301 and the Chrontel 7005 only support resolutions up to 800x600. All others support resolutions up to 1024x768. However, due to a hardware bug, Xvideo might be distorted on SiS video bridges if running NTSC or PAL-M at 1024x768.

About XVideo support

XVideo is supported on all chipsets of both families. However, there are some differences in hardware features which cause limitations. The 300 series as well as the SiS55x, M650, 651, 661FX, M661FX, M661MX, 741, 741GX, M741, 760, M760 support two video overlays. The SiS315/H/PRO, 650/740 and 330 support only one such overlay. On chips with two overlays, one overlay is used for CRT1, the other for CRT2. On the other chipsets, the option N`34`XvOnCRT2N`34` can be used to select the desired output channel.

About Merged Framebuffer support

Merged framebuffer mode is similar to dual head/Xinerama mode, but has a few advantages which make me recommend it strongly over Xinerama. Please see http://www.winischhofer.net/linuxsisvga.shtml for detailed information.

About dual-head support

Dual head mode with or without Xinerama is fully supported. Note that colordepth 8 is not supported in dual head mode.

The following driver Options are supported on the 300 and 315/330 series:

Option N`34`NoXVideoN`34` N`34`booleanN`34`

Disable XV (XVideo) extension support. Default: XVideo is on.

Option N`34`XvOnCRT2N`34` N`34`booleanN`34`

On chipsets with only one video overlay, this option can used to bind the overlay to CRT1 ( if a monitor is detected and if this option is either unset or set to false ) or CRT2 ( if a CRT2 device is detected or forced, and if this option is set to true ). If either only CRT1 or CRT2 is detected, the driver decides automatically. In Merged Framebuffer mode, this option is ignored. Default: overlay is used on CRT1

Option N`34`ForceCRT1N`34` N`34`booleanN`34`

Force CRT1 to be on of off. If a monitor is connected, it will be detected during server start. However, some old monitors are not detected correctly. In such cases, you may set this option to on in order to make the driver initialize CRT1 anyway. If this option is set to off , the driver will switch off CRT1. Default: auto-detect

Option N`34`ForceCRT2TypeN`34` N`34`stringN`34`

Force display type to one of: NONE , TV , SVIDEO , COMPOSITE , SVIDEO+COMPOSITE , SCART , LCD , VGA ; NONE will disable CRT2. The SVIDEO, COMPOSITE, SVIDEO+COMPOSITE and SCART parameters are for SiS video bridges only and can be used to force the driver to use a specific TV output connector (if present). For further parameters, see the author`s website. Default: auto detect.

Option N`34`CRT2GammaN`34` N`34`booleanN`34`

Enable or disable gamma correction for CRT2. Only supported for SiS video bridges. Default: Gamma correction for CRT2 is on.

Option N`34`TVStandardN`34` N`34`stringN`34`

Force the TV standard to either PAL or NTSC. On some machines with 630, 730 and the 315/330 series, PALM , PALN and NTSCJ are supported as well. Default: BIOS setting.

Option N`34`TVXPosOffsetN`34` N`34`integerN`34`

This option allows tuning the horizontal position of the image for TV output. The range is from -32 to 32. Not supported on the Chrontel 7019. Default: 0

Option N`34`TVYPosOffsetN`34` N`34`integerN`34`

This option allows tuning the vertical position of the image for TV output. The range is from -32 to 32. Not supported on the Chrontel 7019. Default: 0

Option N`34`SISTVXScaleN`34` N`34`integerN`34`

This option selects the horizontal zooming level for TV output. The range is from -16 to 16. Only supported on SiS video bridges. Default: 0

Option N`34`SISTVYScaleN`34` N`34`integerN`34`

This option selects the vertical zooming level for TV output in the following modes: 640x480, 800x600. On the 315/330 series, also 720x480, 720x576 and 768x576. The range is from -4 to 3. Only supported on SiS video bridges. Default: 0

Option N`34`CHTVOverscanN`34` N`34`booleanN`34`

On machines with a Chrontel TV encoder, this can be used to force the TV mode to overscan or underscan. on means overscan, off means underscan. Default: BIOS setting.

Option N`34`CHTVSuperOverscanN`34` N`34`booleanN`34`

On machines with a Chrontel 7005 TV encoder, this option enables a super-overscan mode. This is only supported if the TV standard is PAL. Super overscan will produce an image on the TV which is larger than the viewable area.

The driver supports many more options. Please see http://www.winischhofer.net/linuxsisvga.shtml for more information.

3. 300 series specific information

DRI is supported on the 300 series only. On Linux, prior to kernel 2.6.3, DRI requires the kernel`s SiS framebuffer driver ( sisfb ) and some other modules which come with either the kernel or the X server.

Sisfb takes care of memory management for texture data. In order to prevent the X Server and sisfb from overwriting each other`s data, sisfb reserves an amount of video memory for the X driver. This amount can either be selected using sisfb`s mem parameter, or auto-selected depending on the amount of total video RAM available.

Sisfb can be used for memory management only, or as a complete framebuffer driver. If you start sisfb with a valid mode (ie you gain a graphical console), the X driver can communicate with sisfb and doesn`t require any manual configuration for finding out about the video memory it is allowed to use.

However, if you are running a 2.4 series Linux kernel and use sisfb for video memory management only, ie you started sisfb with mode=none and still have a text mode console, there is no communication between sisfb and the X driver. For this purpose, the

Option N`34`MaxXFBMemN`34` N`34`integerN`34`

exists. This option must be set to the same value as given to sisfb through its "mem" parameter, ie the amount of memory to use for X in kilobytes.

If you started sisfb without the mem argument, sisfb will reserve

12288KB if more than 16MB of total video RAM is available,

8192KB if between 12 and 16MB of video RAM is available,

4096KB in all other cases.

If you intend to use DRI, I recommend setting the total video memory in the BIOS to 64MB in order to at least overcome the lack of memory swap functions.

As of Linux 2.6.3 and under *BSD, sisfb is not required for memory management. Hence, this option is mandatory on such systems not running sisfb to decide how much memory X should reserve for DRI.

Option N`34`DRIN`34` N`34`booleanN`34`

This option allows enabling or disabling DRI. By default, DRI is on.

Option N`34`AGPSizeN`34` N`34`integerN`34`

This option allows selecting the amount of AGP memory to be used for DRI. The amount is to be specified in megabyte, the default is 8.

 

KNOWN BUGS

none.  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)

http://www.winischhofer.net/linuxsisvga.shtml for more information and updates  

AUTHORS

Authors include: Alan Hourihane, Mike Chapman, Juanjo Santamarta, Mitani Hiroshi, David Thomas, Sung-Ching Lin, Ademar Reis, Thomas Winischhofer

st

NAME

st - SCSI tape device  

SYNOPSIS

#include <sys/mtio.h> int ioctl(int fd, int request [, (void *)arg3]); int ioctl(int fd, <FONT SIZE="-1">MTIOCTOP</FONT>, (struct mtop *)mt_cmd); int ioctl(int fd, <FONT SIZE="-1">MTIOCGET</FONT>, (struct mtget *)mt_status); int ioctl(int fd, <FONT SIZE="-1">MTIOCPOS</FONT>, (struct mtpos *)mt_pos);

 

DESCRIPTION

The st driver provides the interface to a variety of SCSI tape devices. Currently, the driver takes control of all detected devices of type lqsequential-access.rq The st driver uses major device number 9.

Each device uses eight minor device numbers. The lower-most five bits in the minor numbers are assigned sequentially in the order of detection. The minor numbers can be grouped into two sets of four numbers: the principal (auto-rewind) minor device numbers, n, and a lqno-rewindrq device numbers, (n+ 128). Devices opened using the principal device number will be sent a <FONT SIZE="-1">REWIND</FONT> command when they are closed. Devices opened using the lqno-rewindrq device number will not. (Note that using an auto-rewind device for positioning the tape with, for instance, mt does not lead to the desired result: the tape is rewound after the mt command and the next command starts from the beginning of the tape).

Within each group, four minor numbers are available to define devices with different characteristics (block size, compression, density, etc.) When the system starts up, only the first device is available. The other three are activated when the default characteristics are defined (see below). (By changing compile-time constants, it is possible to change the balance between the maximum number of tape drives and the number of minor numbers for each drive. The default allocation allows control of 32 tape drives. For instance, it is possible to control up to 64 tape drives with two minor numbers for different options.)

Devices are typically created by:

mknod -m 666 /dev/st0 c 9 0 mknod -m 666 /dev/st0l c 9 32 mknod -m 666 /dev/st0m c 9 64 mknod -m 666 /dev/st0a c 9 96 mknod -m 666 /dev/nst0 c 9 128 mknod -m 666 /dev/nst0l c 9 160 mknod -m 666 /dev/nst0m c 9 192 mknod -m 666 /dev/nst0a c 9 224

There is no corresponding block device.

The driver uses an internal buffer that has to be large enough to hold at least one tape block. In kernels before 2.1.121, the buffer is allocated as one contiguous block. This limits the block size to the largest contiguous block of memory the kernel allocator can provide. The limit is currently 128 kB for the 32-bit architectures and 256 kB for the 64-bit architectures. In newer kernels the driver allocates the buffer in several parts if necessary. By default, the maximum number of parts is 16. This means that the maximum block size is very large (2 MB if allocation of 16 blocks of 128 kB succeeds).

The driver`s internal buffer size is determined by a compile-time constant which can be overridden with a kernel startup option. In addition to this, the driver tries to allocate a larger temporary buffer at run-time if necessary. However, run-time allocation of large contiguous blocks of memory may fail and it is advisable not to rely too much on dynamic buffer allocation with kernels older than 2.1.121 (this applies also to demand-loading the driver with kerneld or kmod).

The driver does not specifically support any tape drive brand or model. After system start-up the tape device options are defined by the drive firmware. For example, if the drive firmware selects fixed block mode, the tape device uses fixed block mode. The options can be changed with explicit ioctl() calls and remain in effect when the device is closed and reopened. Setting the options affects both the auto-rewind and the non-rewind device.

Different options can be specified for the different devices within the subgroup of four. The options take effect when the device is opened. For example, the system administrator can define one device that writes in fixed block mode with a certain block size, and one which writes in variable block mode (if the drive supports both modes).

The driver supports tape partitions if they are supported by the drive. (Note that the tape partitions have nothing to do with disk partitions. A partitioned tape can be seen as several logical tapes within one medium.) Partition support has to be enabled with an ioctl. The tape location is preserved within each partition across partition changes. The partition used for subsequent tape operations is selected with an ioctl. The partition switch is executed together with the next tape operation in order to avoid unnecessary tape movement. The maximum number of partitions on a tape is defined by a compile-time constant (originally four). The driver contains an ioctl that can format a tape with either one or two partitions.

Device /dev/tape is usually created as a hard or soft link to the default tape device on the system.  

DATA TRANSFER

The driver supports operation in both fixed block mode and variable block mode (if supported by the drive). In fixed block mode the drive writes blocks of the specified size and the block size is not dependent on the byte counts of the write system calls. In variable block mode one tape block is written for each write call and the byte count determines the size of the corresponding tape block. Note that the blocks on the tape do don`t contain any information about the writing mode: when reading, the only important thing is to use commands that accept the block sizes on the tape.

In variable block mode the read byte count does not have to match the tape block size exactly. If the byte count is larger than the next block on tape, the driver returns the data and the function returns the actual block size. If the block size is larger than the byte count, the requested amount of data from the start of the block is returned and the rest of the block is discarded.

In fixed block mode the read byte counts can be arbitrary if buffering is enabled, or a multiple of the tape block size if buffering is disabled. Kernels before 2.1.121 allow writes with arbitrary byte count if buffering is enabled. In all other cases (kernel before 2.1.121 with buffering disabled or newer kernel) the write byte count must be a multiple of the tape block size.

A filemark is automatically written to tape if the last tape operation before close was a write.

When a filemark is encountered while reading, the following happens. If there are data remaining in the buffer when the filemark is found, the buffered data is returned. The next read returns zero bytes. The following read returns data from the next file. The end of recorded data is signaled by returning zero bytes for two consecutive read calls. The third read returns an error.  

IOCTLS

The driver supports three ioctl requests. Requests not recognized by the st driver are passed to the SCSI driver. The definitions below are from /usr/include/linux/mtio.h:  

<FONT SIZE="-1">MTIOCTOP</FONT> - Perform a tape operation

This request takes an argument of type (struct mtop *). Not all drives support all operations. The driver returns an EIO error if the drive rejects an operation.

/* Structure for <FONT SIZE="-1">MTIOCTOP</FONT> - mag tape op command: */ struct mtop { short mt_op; /* operations defined below */ int mt_count; /* how many of them */ };

Magnetic Tape operations for normal tape use:

MTBSF

Backward space over mt_count filemarks.

MTBSFM

Backward space over mt_count filemarks. Reposition the tape to the EOT side of the last filemark.

MTBSR

Backward space over mt_count records (tape blocks).

MTBSS

Backward space over mt_count setmarks.

MTCOMPRESSION

Enable compression of tape data within the drive if mt_count is non-zero and disable compression if mt_count is zero. This command uses the MODE page 15 supported by most DATs.

MTEOM

Go to the end of the recorded media (for appending files).

MTERASE

Erase tape.

MTFSF

Forward space over mt_count filemarks.

MTFSFM

Forward space over mt_count filemarks. Reposition the tape to the BOT side of the last filemark.

MTFSR

Forward space over mt_count records (tape blocks).

MTFSS

Forward space over mt_count setmarks.

MTLOAD

Execute the SCSI load command. A special case is available for some HP autoloaders. If mt_count is the constant MT_ST_HPLOADER_OFFSET plus a number, the number is sent to the drive to control the autoloader.

MTLOCK

Lock the tape drive door.

MTMKPART

Format the tape into one or two partitions. If mt_count is non-zero, it gives the size of the first partition and the second partition contains the rest of the tape. If mt_count is zero, the tape is formatted into one partition. This command is not allowed for a drive unless the partition support is enabled for the drive (see MT_ST_CAN_PARTITIONS below).

MTNOP

No op - flushes the driver`s buffer as a side effect. Should be used before reading status with <FONT SIZE="-1">MTIOCGET</FONT>.

MTOFFL

Rewind and put the drive off line.

MTRESET

Reset drive.

MTRETEN

Retension tape.

MTREW

Rewind.

MTSEEK

Seek to the tape block number specified in mt_count. This operation requires either a SCSI-2 drive that supports the <FONT SIZE="-1">LOCATE</FONT> command (device-specific address) or a Tandberg-compatible SCSI-1 drive (Tandberg, Archive Viper, Wangtek, ... ). The block number should be one that was previously returned by <FONT SIZE="-1">MTIOCPOS</FONT> if device-specific addresses are used.

MTSETBLK

Set the drive`s block length to the value specified in mt_count. A block length of zero sets the drive to variable block size mode.

MTSETDENSITY

Set the tape density to the code in mt_count. The density codes supported by a drive can be found from the drive documentation.

MTSETPART

The active partition is switched to mt_count . The partitions are numbered from zero. This command is not allowed for a drive unless the partition support is enabled for the drive (see MT_ST_CAN_PARTITIONS below).

MTUNLOAD

Execute the SCSI unload command (does not eject the tape).

MTUNLOCK

Unlock the tape drive door.

MTWEOF

Write mt_count filemarks.

MTWSM

Write mt_count setmarks.

Magnetic Tape operations for setting of device options (by the superuser):

MTSETDRVBUFFER

Set various drive and driver options according to bits encoded in mt_count. These consist of the drive`s buffering mode, 13 Boolean driver options, the buffer write threshold, defaults for the block size and density, and timeouts (only in kernels >= 2.1). A single operation can affect only one item in the list above (the Booleans counted as one item.)

A value having zeros in the high-order 4 bits will be used to set the drive`s buffering mode. The buffering modes are:

0

The drive will not report <FONT SIZE="-1">GOOD</FONT> status on write commands until the data blocks are actually written to the medium.

1

The drive may report <FONT SIZE="-1">GOOD</FONT> status on write commands as soon as all the data has been transferred to the drive`s internal buffer.

2

The drive may report <FONT SIZE="-1">GOOD</FONT> status on write commands as soon as (a) all the data has been transferred to the drive`s internal buffer, and (b) all buffered data from different initiators has been successfully written to the medium.

To control the write threshold the value in mt_count must include the constant <FONT SIZE="-1">MT_ST_WRITE_THRESHOLD</FONT> logically ORed with a block count in the low 28 bits. The block count refers to 1024-byte blocks, not the physical block size on the tape. The threshold cannot exceed the driver`s internal buffer size (see <FONT SIZE="-1">DESCRIPTION</FONT>, above).

To set and clear the Boolean options the value in mt_count must include one the constants <FONT SIZE="-1">MT_ST_BOOLEANS</FONT>, <FONT SIZE="-1">MT_ST_SETBOOLEANS</FONT>, <FONT SIZE="-1">MT_ST_CLEARBOOLEANS</FONT>, or <FONT SIZE="-1">MT_ST_DEFBOOLEANS</FONT> logically ORed with whatever combination of the following options is desired. Using <FONT SIZE="-1">MT_ST_BOOLEANS</FONT> the options can be set to the values defined in the corresponding bits. With <FONT SIZE="-1">MT_ST_SETBOOLEANS</FONT> the options can be selectively set and with <FONT SIZE="-1">MT_ST_DEFBOOLEANS</FONT> selectively cleared.

The default options for a tape device are set with <FONT SIZE="-1">MT_ST_DEFBOOLEANS</FONT>. A non-active tape device (e.g., device with minor 32 or 160) is activated when the default options for it are defined the first time. An activated device inherits from the device activated at start-up the options not set explicitly.

The Boolean options are:

<FONT SIZE="-1">MT_ST_BUFFER_WRITES</FONT> (Default: true)

Buffer all write operations in fixed block mode. If this option is false and the drive uses a fixed block size, then all write operations must be for a multiple of the block size. This option must be set false to write reliable multi-volume archives.

<FONT SIZE="-1">MT_ST_ASYNC_WRITES</FONT> (Default: true)

When this options is true write operations return immediately without waiting for the data to be transferred to the drive if the data fits into the driver`s buffer. The write threshold determines how full the buffer must be before a new SCSI write command is issued. Any errors reported by the drive will be held until the next operation. This option must be set false to write reliable multi-volume archives.

<FONT SIZE="-1">MT_ST_READ_AHEAD</FONT> (Default: true)

This option causes the driver to provide read buffering and read-ahead in fixed block mode. If this option is false and the drive uses a fixed block size, then all read operations must be for a multiple of the block size.

<FONT SIZE="-1">MT_ST_TWO_FM</FONT> (Default: false)

This option modifies the driver behavior when a file is closed. The normal action is to write a single filemark. If the option is true the driver will write two filemarks and backspace over the second one.

Note: This option should not be set true for QIC tape drives since they are unable to overwrite a filemark. These drives detect the end of recorded data by testing for blank tape rather than two consecutive filemarks. Most other current drives also detect the end of recorded data and using two filemarks is usually necessary only when interchanging tapes with some other systems.

<FONT SIZE="-1">MT_ST_DEBUGGING</FONT> (Default: false)

This option turns on various debugging messages from the driver (effective only if the driver was compiled with <FONT SIZE="-1">DEBUG</FONT> defined non-zero).

<FONT SIZE="-1">MT_ST_FAST_EOM</FONT> (Default: false)

This option causes the <FONT SIZE="-1">MTEOM</FONT> operation to be sent directly to the drive, potentially speeding up the operation but causing the driver to lose track of the current file number normally returned by the <FONT SIZE="-1">MTIOCGET</FONT> request. If <FONT SIZE="-1">MT_ST_FAST_EOM</FONT> is false the driver will respond to an <FONT SIZE="-1">MTEOM</FONT> request by forward spacing over files.

<FONT SIZE="-1">MT_ST_AUTO_LOCK</FONT> (Default: false)

When this option is true, the drive door is locked when the device is opened and unlocked when it is closed.

<FONT SIZE="-1">MT_ST_DEF_WRITES</FONT> (Default: false)

The tape options (block size, mode, compression, etc.) may change when changing from one device linked to a drive to another device linked to the same drive depending on how the devices are defined. This option defines when the changes are enforced by the driver using SCSI-commands and when the drives auto-detection capabilities are relied upon. If this option is false, the driver sends the SCSI-commands immediately when the device is changed. If the option is true, the SCSI-commands are not sent until a write is requested. In this case the drive firmware is allowed to detect the tape structure when reading and the SCSI-commands are used only to make sure that a tape is written according to the correct specification.

<FONT SIZE="-1">MT_ST_CAN_BSR</FONT> (Default: false)

When read-ahead is used, the tape must sometimes be spaced backward to the correct position when the device is closed and the SCSI command to space backwards over records is used for this purpose. Some older drives can`t process this command reliably and this option can be used to instruct the driver not to use the command. The end result is that, with read-ahead and fixed block mode, the tape may not be correctly positioned within a file when the device is closed.

<FONT SIZE="-1">MT_ST_NO_BLKLIMS</FONT> (Default: false)

Some drives don`t accept the READ BLOCK LIMITS SCSI command. If this is used, the driver does not use the command. The drawback is that the driver can`t check before sending commands if the selected block size is acceptable to the drive.

<FONT SIZE="-1">MT_ST_CAN_PARTITIONS</FONT> (Default: false)

This option enables support for several partitions within a tape. The option applies to all devices linked to a drive.

<FONT SIZE="-1">MT_ST_SCSI2LOGICAL</FONT> (Default: false)

This option instructs the driver to use the logical block addresses defined in the SCSI-2 standard when performing the seek and tell operations (both with MTSEEK and MTIOCPOS commands and when changing tape partition). Otherwise the device-specific addresses are used. It is highly advisable to set this option if the drive supports the logical addresses because they count also filemarks. There are some drives that only support the logical block addresses.

<FONT SIZE="-1">MT_ST_SYSV</FONT> (Default: false)

When this option is enabled, the tape devices use the SystemV semantics. Otherwise the BSD semantics are used. The most important difference between the semantics is what happens when a device used for reading is closed: in SYSV semantics the tape is spaced forward past the next filemark if this has not happened while using the device. In BSD semantics the tape position is not changed.

<FONT SIZE="-1">EXAMPLE</FONT>

struct mtop mt_cmd; mt_cmd.mt_op = <FONT SIZE="-1">MTSETDRVBUFFER</FONT>; mt_cmd.mt_count = <FONT SIZE="-1">MT_ST_BOOLEANS</FONT> | <FONT SIZE="-1">MT_ST_BUFFER_WRITES</FONT> | <FONT SIZE="-1">MT_ST_ASYNC_WRITES</FONT>; ioctl(fd, <FONT SIZE="-1">MTIOCTOP</FONT>, &mt_cmd);

The default block size for a device can be set with
<FONT SIZE="-1">MT_ST_DEF_BLKSIZE</FONT> and the default density code can be set with <FONT SIZE="-1">MT_ST_DEFDENSITY</FONT>. The values for the parameters are ORed with the operation code.

With kernels 2.1.x and later, the timeout values can be set with the subcommand <FONT SIZE="-1">MT_ST_SET_TIMEOUT</FONT> or`ed with the timeout in seconds. The long timeout (used for rewinds and other commands that may take a long time) can be set with <FONT SIZE="-1">MT_ST_SET_LONG_TIMEOUT</FONT>. The kernel defaults are very long to make sure that a successful command is not timed out with any drive. Because of this the driver may seem stuck even if it is only waiting for the timeout. These commands can be used to set more practical values for a specific drive. The timeouts set for one device apply for all devices linked to the same drive.

 

<FONT SIZE="-1">MTIOCGET</FONT> - Get status

This request takes an argument of type (struct mtget *).

/* structure for <FONT SIZE="-1">MTIOCGET</FONT> - mag tape get status command */ struct mtget { long mt_type; long mt_resid; /* the following registers are device dependent */ long mt_dsreg; long mt_gstat; long mt_erreg; /* The next two fields are not always used */ daddr_t mt_fileno; daddr_t mt_blkno; };

mt_type

The header file defines many values for mt_type, but the current driver reports only the generic types <FONT SIZE="-1">MT_ISSCSI1</FONT> (Generic SCSI-1 tape) and <FONT SIZE="-1">MT_ISSCSI2</FONT> (Generic SCSI-2 tape).

mt_resid

contains the current tape partition number.

mt_dsreg

reports the drive`s current settings for block size (in the low 24 bits) and density (in the high 8 bits). These fields are defined by <FONT SIZE="-1">MT_ST_BLKSIZE_SHIFT</FONT>, <FONT SIZE="-1">MT_ST_BLKSIZE_MASK</FONT>, <FONT SIZE="-1">MT_ST_DENSITY_SHIFT</FONT>, and <FONT SIZE="-1">MT_ST_DENSITY_MASK</FONT>.

mt_gstat

reports generic (device independent) status information. The header file defines macros for testing these status bits:

<FONT SIZE="-1">GMT_EOF(</FONT>x<FONT SIZE="-1">)</FONT>:

The tape is positioned just after a filemark (always false after an <FONT SIZE="-1">MTSEEK</FONT> operation).

<FONT SIZE="-1">GMT_BOT(</FONT>x<FONT SIZE="-1">)</FONT>:

The tape is positioned at the beginning of the first file (always false after an <FONT SIZE="-1">MTSEEK</FONT> operation).

<FONT SIZE="-1">GMT_EOT(</FONT>x<FONT SIZE="-1">)</FONT>:

A tape operation has reached the physical End Of Tape.

<FONT SIZE="-1">GMT_SM(</FONT>x<FONT SIZE="-1">)</FONT>:

The tape is currently positioned at a setmark (always false after an <FONT SIZE="-1">MTSEEK</FONT> operation).

<FONT SIZE="-1">GMT_EOD(</FONT>x<FONT SIZE="-1">)</FONT>:

The tape is positioned at the end of recorded data.

<FONT SIZE="-1">GMT_WR_PROT(</FONT>x<FONT SIZE="-1">)</FONT>:

The drive is write-protected. For some drives this can also mean that the drive does not support writing on the current medium type.

<FONT SIZE="-1">GMT_ONLINE(</FONT>x<FONT SIZE="-1">)</FONT>:

The last open() found the drive with a tape in place and ready for operation.

<FONT SIZE="-1">GMT_D_6250(</FONT>x<FONT SIZE="-1">)</FONT>, <FONT SIZE="-1">GMT_D_1600(</FONT>x<FONT SIZE="-1">)</FONT>, <FONT SIZE="-1">GMT_D_800(</FONT>x<FONT SIZE="-1">)</FONT>:

This lqgenericrq status information reports the current density setting for 9-track ½" tape drives only.

<FONT SIZE="-1">GMT_DR_OPEN(</FONT>x<FONT SIZE="-1">)</FONT>:

The drive does not have a tape in place.

<FONT SIZE="-1">GMT_IM_REP_EN(</FONT>x<FONT SIZE="-1">)</FONT>:

Immediate report mode. This bit is set if there are no guarantees that the data has been physically written to the tape when the write call returns. It is set zero only when the driver does not buffer data and the drive is set not to buffer data.

mt_erreg

The only field defined in mt_erreg is the recovered error count in the low 16 bits (as defined by <FONT SIZE="-1">MT_ST_SOFTERR_SHIFT</FONT> and <FONT SIZE="-1">MT_ST_SOFTERR_MASK</FONT>). Due to inconsistencies in the way drives report recovered errors, this count is often not maintained (most drives do not by default report soft errors but this can be changed with a SCSI MODE SELECT command).

mt_fileno

reports the current file number (zero-based). This value is set to -1 when the file number is unknown (e.g., after <FONT SIZE="-1">MTBSS</FONT> or <FONT SIZE="-1">MTSEEK</FONT>).

mt_blkno

reports the block number (zero-based) within the current file. This value is set to -1 when the block number is unknown (e.g., after <FONT SIZE="-1">MTBSF</FONT>, <FONT SIZE="-1">MTBSS</FONT>, or <FONT SIZE="-1">MTSEEK</FONT>).

 

<FONT SIZE="-1">MTIOCPOS</FONT> - Get tape position

This request takes an argument of type (struct mtpos *) and reports the drive`s notion of the current tape block number, which is not the same as mt_blkno returned by <FONT SIZE="-1">MTIOCGET</FONT>. This drive must be a SCSI-2 drive that supports the <FONT SIZE="-1">READ POSITION</FONT> command (device-specific address) or a Tandberg-compatible SCSI-1 drive (Tandberg, Archive Viper, Wangtek, ... ).

/* structure for <FONT SIZE="-1">MTIOCPOS</FONT> - mag tape get position command */ struct mtpos { long mt_blkno; /* current block number */ };

 

RETURN VALUE

EIO

The requested operation could not be completed.

ENOSPC

A write operation could not be completed because the tape reached end-of-medium.

EACCES

An attempt was made to write or erase a write-protected tape. (This error is not detected during open().)

EFAULT

The command parameters point to memory not belonging to the calling process.

ENXIO

During opening, the tape device does not exist.

EBUSY

The device is already in use or the driver was unable to allocate a buffer.

EOVERFLOW

An attempt was made to read or write a variable-length block that is larger than the driver`s internal buffer.

EINVAL

An ioctl() had an illegal argument, or a requested block size was illegal.

ENOSYS

Unknown ioctl().

EROFS

Open is attempted with O_WRONLY or O_RDWR when the tape in the drive is write-protected.

 

FILES

/dev/st* : the auto-rewind SCSI tape devices
/dev/nst* : the non-rewind SCSI tape devices  

AUTHOR

The driver has been written by Kai M:akisara (Kai.Makisara@metla.fi) starting from a driver written by Dwayne Forsyth. Several other people have also contributed to the driver.  

SEE ALSO

mt(1)

The file README.st in the kernel sources contains the most recent information about the driver and its configuration possibilities.  

NOTES

1. When exchanging data between systems, both systems have to agree on the physical tape block size. The parameters of a drive after startup are often not the ones most operating systems use with these devices. Most systems use drives in variable block mode if the drive supports that mode. This applies to most modern drives, including DATs, 8mm helical scan drives, DLTs, etc. It may be advisable use these drives in variable block mode also in Linux (i.e., use MTSETBLK or MTSETDEFBLK at system startup to set the mode), at least when exchanging data with foreign system. The drawback of this is that a fairly large tape block size has to be used to get acceptable data transfer rates on the SCSI bus.

2. Many programs (e.g., tar) allow the user to specify the blocking factor on command line. Note that this determines the physical block size on tape only in variable block mode.

3. In order to use SCSI tape drives, the basic SCSI driver, a SCSI-adapter driver and the SCSI tape driver must be either configured into the kernel or loaded as modules. If the SCSI-tape driver is not present, the drive is recognized but the tape support described in this page is not available.

4. The driver writes error messages to the console/log. The SENSE codes written into some messages are automatically translated to text if verbose SCSI messages are enabled in kernel configuration.  

COPYRIGHT

Copyright © 1995 Robert K. Nichols.
Copyright © 1999 Kai M:akisara.

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Additional permissions are contained in the header of the source file.

suncg14

NAME

suncg14 - CG14 video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`suncg14N`34`   ... EndSection

 

DESCRIPTION

suncg14 is an Xorg driver for Sun CG14 video cards. THIS MAN PAGE NEEDS TO BE FILLED IN.  

SUPPORTED HARDWARE

The suncg14 driver supports...  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Jakub Jelinek <jakub@redhat.com>

suncg6

NAME

suncg6 - GX/Turbo GX video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`suncg6N`34`   ... EndSection

 

DESCRIPTION

suncg6 is an Xorg driver for Sun GX and Turbo GX (also known as cgsix) video cards. THIS MAN PAGE NEEDS TO BE FILLED IN.  

SUPPORTED HARDWARE

The suncg6 driver supports...  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Jakub Jelinek <jakub@redhat.com>

sunleo

NAME

sunleo - Leo video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`sunleoN`34`   ... EndSection Section N`34`ScreenN`34`   ... Device N`34`devnameN`34`   ... DefaultDepth 32   ... EndSection

 

DESCRIPTION

leo is an Xorg driver for Sun Leo (ZX) video cards.

Also known as the ZX or T(urbo)ZX, Leo is a 24 bit accelerated 3D graphics card. Both cards are double-width, but the TZX also requires extra cooling in the form of an additional double-width fan card, so effectively takes up 4 SBus slots.

 

SUPPORTED HARDWARE

The leo driver supports all Sun stations that include a Leo chipset:

Workstations:

Sun 4/15, 4/30, 4/75
SPARCstation 5, 10, 20
Ultra 1, 1E, 2

Servers:

SPARCserver 1000,
SPARCcenter 2000

 

CONFIGURATION DETAILS

You must set "DefaultDepth" to "32" in the Screen Section.

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Driver authors include: Jakub Jelinek <jakub@redhat.com>
Man page: Arnaud Quette <arnaud.quette@mgeups.com>

tdfx

NAME

tdfx - 3Dfx video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`tdfxN`34`   ... EndSection

 

DESCRIPTION

tdfx is an Xorg driver for 3Dfx video cards.  

SUPPORTED HARDWARE

The tdfx driver supports Voodoo Banshee, Voodoo3, Voodoo4 and Voodoo5 cards.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The following driver Options are supported:

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`SWCursorN`34` N`34`booleanN`34`

Disable or enable software cursor. Default: software cursor is disable and a hardware cursor is used for configurations where the hardware cursor is available.

Option N`34`DRIN`34` N`34`booleanN`34`

Disable or enable DRI support. By default, DRI is on.

Option N`34`TexturedVideoN`34` N`34`booleanN`34`

This has XvImage support use the texture engine rather than the video overlay.

Option N`34`VideoKeyN`34` N`34`integerN`34`

This sets the default pixel value for the YUV video overlay key. Default: undefined.

The following additional Options are supported:

Option N`34`ShowCacheN`34` N`34`booleanN`34`

Enable or disable viewing offscreen cache memory. A development debug option. Default: off.

 

FILES

tdfx_drv.o  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: ...

trident

NAME

trident - Trident video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`tridentN`34`   ... EndSection

 

DESCRIPTION

trident is an Xorg driver for Trident video cards. The driver is accelerated, and provides support for the following framebuffer depths: 1, 4, 8, 15, 16, and 24. Multi-head configurations are supported. The XvImage extension is supported on TGUI96xx and greater cards.  

SUPPORTED HARDWARE

The trident driver supports PCI,AGP and ISA video cards based on the following Trident chips:

Blade

Blade3D, CyberBlade series i1, i7 (DSTN), i1, i1 (DSTN), Ai1, Ai1 (DSTN), CyberBlade/e4, CyberBladeXP, CyberBladeAi1/XP, BladeXP

Image

3DImage975, 3DImage985, Cyber9520, Cyber9525, Cyber9397, Cyber9397DVD

ProVidia

9682, 9685, Cyber9382, Cyber9385, Cyber9388

TGUI

9440AGi, 9660, 9680

ISA/VLBus

8900C, 8900D, 9000, 9200CXr, Cyber9320, 9400CXi, 9440AGi These cards have been ported but need further testing and may not work.

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The following driver Options are supported:

Option N`34`SWCursorN`34` N`34`booleanN`34`

Enable or disable the SW cursor. Default: off.

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`PciRetryN`34` N`34`booleanN`34`

Enable or disable PCI retries. Default: off.

Option N`34`CyberShadowN`34` N`34`booleanN`34`

For Cyber chipsets only, turn off shadow registers. If you only see a partial display - this may be the option for you. Default: on.

Option N`34`CyberStretchN`34` N`34`booleanN`34`

For Cyber chipsets only, turn on stretching. When the resolution is lower than the LCD`s screen, this option will stretch the graphics mode to fill the entire LCD. Default: off.

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. Default: off.

Option N`34`VideoKeyN`34` N`34`integerN`34`

This sets the default pixel value for the YUV video overlay key. Default: undefined.

Option N`34`TVChipsetN`34` N`34`stringN`34`

This sets the TV chipset. Options are CH7005 or VT1621. Default: off.

Option N`34`TVSignalN`34` N`34`integerN`34`

This sets the TV signalling. Options are 0 for NTSC or 1 for PAL. Default: undefined.

Option N`34`NoPciBurstN`34` N`34`booleanN`34`

Turn off PCI burst mode, PCI Bursting is on by default. Default: off.

Option N`34`XvHsyncN`34` N`34`integerN`34`

Override the default Horizontal-sync value for the Xv extension. This is used to center the Xv image on the screen. By default the values are assigned based on the video card. Default: 0.

Option N`34`XvVsyncN`34` N`34`integerN`34`

Override the default Vertical-sync value for the Xv extension. This is used to center the Xv image on the screen. By default the values are assigned based on the video card. Default: 0.

Option N`34`XvBskewN`34` N`34`integerN`34`

Override the default Bottom skew value for the Xv extension. This is used to extend the Xv image on the screen at the bottom. By default the values are assigned based on the video card. Default: 0.

Option N`34`XvRskewN`34` N`34`integerN`34`

Override the default Right skew value for the Xv extension. This is used to extend the Xv image on the screen at the right. By default the values are assigned based on the video card. Default: 0.

Option N`34`DisplayN`34` N`34`stringN`34`

Override the display. Possible values are N`34`CRTN`34`, N`34`LCDN`34` and N`34`DualN`34`. Please note that this option is only experimentally. Default: Use display active when X started.

Option N`34`Display1400N`34` N`34`booleanN`34`

Inform driver to expect 1400x1050 display instead of a 1280x1024. Default: off.

Option N`34`GammaBrightnessN`34` N`34`stringN`34`

Set display gamma value and brightness. N`34`stringN`34` is N`34`gamma, brightnessN`34`, where gamma is a floating point value greater than 0 and less or equal to 10. brightness is an integer value greater or equal to 0 and less than 128. Default: gamma and brightness control is turned off. Note: This is not supported on all chipsets.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHOR

Author: Alan Hourihane

tty

NAME

tty - controlling terminal  

DESCRIPTION

The file /dev/tty is a character file with major number 5 and minor number 0, usually of mode 0666 and owner.group root.tty. It is a synonym for the controlling terminal of a process, if any.

In addition to the ioctl() requests supported by the device that tty refers to, the ioctl() request TIOCNOTTY is supported.  

TIOCNOTTY

Detach the current process from its controlling terminal.

If the process is the session leader, then SIGHUP and SIGCONT signals are sent to the foreground process group and all processes in the current session lose their controlling tty.

This ioctl() call only works on file descriptors connected to /dev/tty. It is used by daemon processes when they are invoked by a user at a terminal. The process attempts to open /dev/tty. If the open succeeds, it detaches itself from the terminal by using TIOCNOTTY, while if the open fails, it is obviously not attached to a terminal and does not need to detach itself.  

FILES

/dev/tty  

SEE ALSO

mknod(1), chown(1), getty(1), ioctl(2), termios(3), console(4), ttys(4)

ttyS

NAME

ttyS - serial terminal lines  

DESCRIPTION

ttyS[0-3] are character devices for the serial terminal lines.

They are typically created by:

mknod -m 660 /dev/ttyS0 c 4 64 # base address 0x3f8
mknod -m 660 /dev/ttyS1 c 4 65 # base address 0x2f8
mknod -m 660 /dev/ttyS2 c 4 66 # base address 0x3e8
mknod -m 660 /dev/ttyS3 c 4 67 # base address 0x2e8
chown root:tty /dev/ttyS[0-3]

 

FILES

/dev/ttyS[0-3]  

SEE ALSO

mknod(1), chown(1), getty(1), tty(4), setserial(8)

ur98

NAME

UR-98 - UR98 (TR88L803) head tracker driver  

SYNOPSIS

Section N`34`InputDeviceN`34`
Identifier N`34`idevnameN`34`
Driver N`34`UR-98N`34`
Option N`34`DeviceN`34` N`34`devpathN`34`
  ...
EndSection  

DESCRIPTION

UR-98 is an Xorg input driver for the Union Reality UR-F98 headtracker.

The UR-98 driver functions as a pointer input device, and can be used either as an additional input device or as the X server`s core pointer. The driver provides support for the three axes, throttle and four buttons of the controller. If mapped as the core pointer the headtracker provides headtracking to try and place the mouse cursor where you look. As a secondary input device the unit can be used for gaming, for example to provide the look up/down and the turn in quake, and with the Z axis bound to ack/forward to provide movement control.

The default mapping maps left-right movement to X, up-down movement to Y and near/far movement to the Z axis. The throttle is mapped as the fourth axis by default but can also be mapped as button 5.

For use in "head only" mode the Z axis can be mapped as a button. This allows the user to select objects with head/neck movement alone but takes some practice to use well.

 

SUPPORTED HARDWARE

Union Reality UR-98. While this is a joystick driver the behaviour is absolute so this driver is not useful for true joystick interfaces.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

The following driver options are supported

Option N`34`MinXN`34` N`34`integerN`34`

Set the left hand X value from the headgear, for calibration.

Option N`34`MaxXN`34` N`34`integerN`34`

Set the right hand X value from the headgear, for calibration.

Option N`34`MinYN`34` N`34`integerN`34`

Set the top Y value from the headgear, for calibration.

Option N`34`MaxYN`34` N`34`integerN`34`

Set the bottom Y value from the headgear, for calibration.

Option N`34`MinZN`34` N`34`integerN`34`

Set the nearest Z value from the headgear, for calibration.

Option N`34`MaxZN`34` N`34`integerN`34`

Set the furthest Z value from the headgear, for calibration.

Option N`34`MinTN`34` N`34`integerN`34`

Set the low throttle value from the headgear, for calibration.

Option N`34`MaxTN`34` N`34`integerN`34`

Set the high throttle value from the headgear, for calibration.

Option N`34`ScreenN`34` N`34`integerN`34`

The screen to attach to the headgear when running with multiple screens. The default is screen 0.

Option N`34`DeviceN`34` N`34`stringN`34`

The joystick port that is attached to the headgear interface. This is usually /dev/input/js0. The digital port is not supported due to lack of documentation.

Option N`34`DeviceNameN`34` N`34`stringN`34`

Set the X11 device name for the headgear. This defaults to HEAD.

Option N`34`PortraitModeN`34` N`34`stringN`34`

Set the display orientation. The default is "landscape" but you can rotate the screen clockwise ("portrait") or anticlockwise ("portraitCCW").

Option N`34`SwapXYN`34` N`34`booleanN`34`

Swap the X and Y values on the display. The default is false.

Option N`34`Button5N`34` N`34`booleanN`34`

Map the throttle as a button instead of axis 4. For some gaming applications this can be more useful. The default is to map the throttle as axis 4.

Option N`34`HeadButtonN`34` N`34`booleanN`34`

Map the Z axis as button 1. This defaults to false.

Option N`34`HeadThreshN`34` N`34`booleanN`34`

Set the distance that is held to be mouse down.

Option N`34`HeadLockN`34` N`34`booleanN`34`

Set the range of depth around the mouse down point where mouse x and y movement is locked out. Set to zero to disable.

 

BUGS

The "HeadButton" option is currently not implemented.

The hardware or kernel driver has some idiosyncracies. Notably on kernel initialization the interface occasionally gets into a state where the readings rapidly cycle left-right-left-right or top-bottom-top-bottom. In those cases it seems to be neccessary to unload the driver, unplug, replug and reload the joystick drivers. Once it initializes sanely it remains sane.

If the device refuses to work check the gray/black cables are plugged into the right ports on the unit. Be careful about this as crossing the cables can lead to the device failing with a nasty burning electronics smell. The author writes from direct experience.

This driver is currently Linux specific.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

Authors include...
 Alan Cox

v4l

NAME

v4l - video4linux driver  

SYNOPSIS

Section N`34`ModuleN`34`   ... Load N`34`v4lN`34` EndSection

 

DESCRIPTION

v4l is an Xorg driver for video4linux cards. It provides a Xvideo extention port for video overlay. Just add the driver to the module list within the module section of your xorg.conf file if you want to use it. There are no config options. Note that the the extmod module is also required for the Xvideo support (and lots of other extentions too).  

SUPPORTED HARDWARE

The v4l driver works with every piece of hardware which is supported by a video4linux (kernel-) device driver and is able to handle video overlay. bt848/bt878-based TV cards are the most popular hardware these days.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.  

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Gerd Knorr <kraxel@bytesex.org>

vcsa

NAME

vcs, vcsa - virtual console memory  

DESCRIPTION

/dev/vcs0 is a character device with major number 7 and minor number 0, usually of mode 0644 and owner root.tty. It refers to the memory of the currently displayed virtual console terminal.

/dev/vcs[1-63] are character devices for virtual console terminals, they have major number 7 and minor number 1 to 63, usually mode 0644 and owner root.tty. /dev/vcsa[0-63] are the same, but including attributes, and prefixed with four bytes giving the screen dimensions and cursor position: lines, columns, x, y. (x = y = 0 at the top left corner of the screen.)

These replace the screendump ioctls of console(4), so the system administrator can control access using file system permissions.

The devices for the first eight virtual consoles may be created by:

for x in 0 1 2 3 4 5 6 7 8; do mknod -m 644 /dev/vcs$x c 7 $x; mknod -m 644 /dev/vcsa$x c 7 $[$x+128]; done chown root:tty /dev/vcs*

No ioctl() requests are supported.  

EXAMPLES

You may do a screendump on vt3 by switching to vt1 and typing cat /dev/vcs3 >foo. Note that the output does not contain newline characters, so some processing may be required, like in fold -w 81 /dev/vcs3 | lpr or (horrors) setterm -dump 3 -file /proc/self/fd/1.

The /dev/vcsa0 device is used for Braille support.

This program displays the character and screen attributes under the cursor of the second virtual console, then changes the background color there:

#include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <fcntl.h> int main() { int fd; char *device = "/dev/vcsa2"; struct {unsigned char lines, cols, x, y;} scrn; char ch, attrib; fd = open(device, O_RDWR); if (fd < 0) { perror(device); exit(1); } (void)read(fd, &scrn, 4); (void)lseek(fd, 4 + 2*(scrn.y*scrn.cols + scrn.x), 0); (void)read(fd, &ch, 1); (void)read(fd, &attrib, 1); printf("ch=`%c` attrib=0x%02x ", ch, attrib); attrib ^= 0x10; (void)lseek(fd, -1, 1); (void)write(fd, &attrib, 1); return 0; }

 

FILES

/dev/vcs[0-63]
/dev/vcsa[0-63]  

AUTHOR

Andries Brouwer <aeb@cwi.nl>  

HISTORY

Introduced with version 1.1.92 of the Linux kernel.  

SEE ALSO

console(4), tty(4), ttys(4), selection(1)

vga

NAME

vga - Generic VGA video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`vgaN`34`   ... EndSection

 

DESCRIPTION

vga is an Xorg driver for generic VGA video cards. It can drive most VGA-compatible video cards, but only makes use of the basic standard VGA core that is common to these cards. The driver supports depths 1, 4 and 8. All relevant visual types are supported at each depth. Multi-head configurations are supported in combination with some other drivers, but only when the vga driver is driving the primary head.  

SUPPORTED HARDWARE

The vga driver supports most VGA-compatible video cards. There are some known exceptions, and those should be listed here.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The driver auto-detects the presence of VGA-compatible hardware. The ChipSet name may optionally be specified in the config file N`34`DeviceN`34` section, and will override the auto-detection:

"generic"

The driver will only use 64k of video memory for depth 1 and depth 8 operation, and 256k of video memory for depth 4 (this is the standard VGA limit).

When operating at depth 8, only a single built-in 320x200 video mode is available. At other depths there is more flexibility regarding mode choice.

The following driver Options are supported:

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. Default: off.

This option is recommended for performance reasons when running at depths 1 and 4, especially when using modern PCI-based hardware. It is required when using those depths in a multi-head configuration where one or more of the other screens is operating at a different depth.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: Marc La France, David Dawes, and Dirk Hohndel.

vmware

NAME

vmware - VMware SVGA video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`vmwareN`34`   ... EndSection

 

DESCRIPTION

vmware is an Xorg driver for VMware virtual video cards.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The driver auto-detects the version of any virtual VMware SVGA adapter.

The following driver Options are supported:

Option N`34`HWCursorN`34` N`34`booleanN`34`

Enable or disable the HW cursor. Default: off.

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Copyright (c) 1999-2001 VMware, Inc.

wacom

NAME

wacom - Wacom input driver  

SYNOPSIS

Section N`34`InputDeviceN`34` Identifier N`34`idevnameN`34` Driver N`34`wacomN`34` Option N`34`DeviceN`34` N`34`devpathN`34`   ... EndSection

 

DESCRIPTION

wacom is an Xorg input driver for Wacom devices.

The wacom driver functions as a pointer input device, and may be used as the X server`s core pointer.  

SUPPORTED HARDWARE

This driver supports the Wacom IV and Wacom V protocols. Preliminary support is available for USB devices on some Linux platforms.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

Multiple instances of the Wacom devices can cohabit. It can be useful to define multiple devices with different active zones. Each device supports the following entries:

Option Type stylus|eraser|cursor

sets the type of tool the device represent. This option is mandatory.

Option Device path

sets the path to the special file which represents serial line where the tablet is plugged. You have to specify it for each subsection with the same value if you want to have multiple devices with the same tablet. This option is mandatory.

Option USB on

tells the driver to dialog with the tablet the USB way. This option is only available on some Linux platforms.

Option DeviceName name

sets the name of the X device.

Option Suppress Inumber

sets the position increment under which not to transmit coordinates. This entry must be specified only in the first Wacom subsection if you have multiple devices for one tablet. If you don`t specify this entry, the default value is computed to

Option Mode Relative|Absolute

sets the mode of the device.

Option Tilt on

enables tilt report if your tablet supports it (ROM version 1.4 and above). If this is enabled, multiple devices at the same time will not be reported.

Option HistorySize number

sets the motion history size. By default the value is zero.

Option AlwaysCore on

enables the sharing of the core pointer. When this feature is enabled, the device will take control of the core pointer (and thus will emit core events) and at the same time will be able, when asked so, to report extended events. You can use the last available integer feedback to control this feature. When the value of the feedback is zero, the feature is disabled. The feature is enabled for any other value.

Option TopX number

X coordinate of the top corner of the active zone.

Option TopY number

Y coordinate of the top corner of the active zone.

Option BottomX Inumber

X coordinate of the bottom corner of the active zone.

Option BottomY number

Y coordinate of the bottom corner of the active zone.

Option KeepShape on

When this option is enabled, the active zone begins according to TopX and TopY. The bottom corner is adjusted to keep the ratio width/height of the active zone the same as the screen while maximizing the area described by TopX, TopY, BottomX, BottomY.

Option DebugLevel number

sets the level of debugging info reported.

Option BaudRate 38400, 19200 or 9600 (default)

changes the serial link speed. This option is only available for wacom V models (Intuos).

Option Serial number

sets the serial number associated with the physical device. This allows to have multiple devices of the same type (i.e. multiple pens). This option is only available on wacom V devices (Intuos). To see which serial number belongs to a device, you have to set the DebugLevel to 6 and watch the output of the X server.

Option Threshold number

sets the pressure threshold used to generate a button 1 events of stylus devices for some models of tablets (Intuos and Graphire).

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

Frederic Lepied <lepied@xfree86.org>

zero

NAME

null, zero - data sink  

DESCRIPTION

Data written on a null or zero special file is discarded.

Reads from the null special file always return end of file, whereas reads from zero always return characters.

null and zero are typically created by:

mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
chown root:mem /dev/null /dev/zero

 

NOTES

If these devices are not writable and readable for all users, many programs will act strange.  

FILES

/dev/null
/dev/zero  

SEE ALSO

chown(1), mknod(1)

apm

NAME

apm - Alliance ProMotion video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`apmN`34`   ... EndSection

 

DESCRIPTION

apm is an Xorg driver for Alliance ProMotion video cards. The driver is accelerated for supported hardware/depth combination. It supports framebuffer depths of 8, 15, 16, 24 and 32 bits. For 6420, 6422, AT24, AT3D and AT25, all depths are fully accelerated except 24 bpp for which only screen to screen copy and rectangle filling is accelerated.  

SUPPORTED HARDWARE

The apm driver supports PCI and ISA video cards on the following Alliance ProMotion chipsets

ProMotion 6420

ProMotion 6422

AT24

AT3D

AT25

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The driver auto-detects the chipset type, but the following ChipSet names may optionally be specified in the config file N`34`DeviceN`34` section, and will override the auto-detection:

"6422", "at24", "at3d".

The AT25 is Chipset "at3d" and the 6420 is 6422.

The driver will auto-detect the amount of video memory present for all chips. The actual amount of video memory can also be specified with a VideoRam entry in the config file N`34`DeviceN`34` section.

The following driver Options are supported:

Option N`34`HWCursorN`34` N`34`booleanN`34`

Enable or disable the hardware cursor. Default: on.

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`NoLinearN`34` N`34`booleanN`34`

Disable or enable use of linear frame buffer. Default: on. Note: it may or may not work. Tell me if you need it.

Option N`34`PciRetryN`34` N`34`booleanN`34`

Enable or disable PCI retries. Default: off.

Option N`34`Remap_DPMS_OnN`34` N`34`stringN`34`

Option N`34`Remap_DPMS_StandbyN`34` N`34`stringN`34`

Option N`34`Remap_DPMS_SuspendN`34` N`34`stringN`34`

Option N`34`Remap_DPMS_OffN`34` N`34`stringN`34`

Remaps the corresponding DPMS events. I`ve found that my Hercules 128/3D swaps Off and Suspend events. You can correct that with

Option N`34`Remap_DPMS_SuspendN`34` N`34`OffN`34` Option N`34`Remap_DPMS_OffN`34` N`34`SuspendN`34`

in the Device section of the config file.

Option N`34`SWCursorN`34` N`34`booleanN`34`

Force the software cursor. Default: off.

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. Default: off.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)  

AUTHORS

Authors include: ...

chips

NAME

chips - Chips and Technologies video driver  

SYNOPSIS

Section N`34`DeviceN`34` Identifier N`34`devnameN`34` Driver N`34`chipsN`34`   ... EndSection

 

DESCRIPTION

chips is an Xorg driver for Chips and Technologies video processors. The majority of the Chips and Technologies chipsets are supported by this driver. In general the limitation on the capabilities of this driver are determined by the chipset on which it is run. Where possible, this driver provides full acceleration and supports the following depths: 1, 4, 8, 15, 16, 24 and on the latest chipsets an 8+16 overlay mode. All visual types are supported for depth 1, 4 and 8 and both TrueColor and DirectColor visuals are supported where possible. Multi-head configurations are supported on PCI or AGP buses.  

SUPPORTED HARDWARE

The chips driver supports video processors on most of the bus types currently available. The chipsets supported fall into one of three architectural classes. A basic architecture, the WinGine architecture and the newer HiQV architecture.

Basic Architecture

The supported chipsets are ct65520, ct65525, ct65530, ct65535, ct65540, ct65545, ct65546 and ct65548

Color depths 1, 4 and 8 are supported on all chipsets, while depths 15, 16 and 24 are supported only on the 65540, 65545, 65546 and 65548 chipsets. The driver is accelerated when used with the 65545, 65546 or 65548 chipsets, however the DirectColor visual is not available.

Wingine Architecture

The supported chipsets are ct64200 and ct64300

Color depths 1, 4 and 8 are supported on both chipsets, while depths 15, 16 and 24 are supported only on the 64300 chipsets. The driver is accelerated when used with the 64300 chipsets, however the DirectColor visual is not available.

HiQV Architecture

The supported chipsets are ct65550, ct65554, ct65555, ct68554, ct69000 and ct69030

Color depths 1, 4, 8, 15, 16, 24 and 8+16 are supported on all chipsets. The DirectColor visual is supported on all color depths except the 8+16 overlay mode. Full acceleration is supplied for all chipsets.  

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details. This section only covers configuration details specific to this driver.

The driver auto-detects the chipset type, but the following ChipSet names may optionally be specified in the config file N`34`DeviceN`34` section, and will override the auto-detection:

"ct65520", "ct65525", "ct65530", "ct65535", "ct65540", "ct65545", "ct65546", "ct65548", "ct65550", "ct65554", "ct65555", "ct68554", "ct69000", "ct69030", "ct64200", "ct64300".

The driver will auto-detect the amount of video memory present for all chipsets. But maybe overridden with the VideoRam entry in the config file N`34`DeviceN`34` section.

The following driver Options are supported, on one or more of the supported chipsets:

Option N`34`NoAccelN`34` N`34`booleanN`34`

Disable or enable acceleration. Default: acceleration is enabled.

Option N`34`NoLinearN`34` N`34`booleanN`34`

Disables linear addressing in cases where it is enabled by default. Default: off

Option N`34`LinearN`34` N`34`booleanN`34`

Enables linear addressing in cases where it is disabled by default. Default: off

Option N`34`HWCursorN`34` N`34`booleanN`34`

Enable or disable the HW cursor. Default: on.

Option N`34`SWCursorN`34` N`34`booleanN`34`

Enable or disable the HW cursor. Default: off.

Option N`34`STNN`34` N`34`booleanN`34`

Force detection of STN screen type. Default: off.

Option N`34`UseModelineN`34` N`34`booleanN`34`

Reprogram flat panel timings with values from the modeline. Default: off

Option N`34`FixPanelSizeN`34` N`34`booleanN`34`

Reprogram flat panel size with values from the modeline. Default: off

Option N`34`NoStretchN`34` N`34`booleanN`34`

This option disables the stretching on a mode on a flat panel to fill the screen. Default: off

Option N`34`LcdCenterN`34` N`34`booleanN`34`

Center the mode displayed on the flat panel on the screen. Default: off

Option N`34`HWclocksN`34` N`34`booleanN`34`

Force the use of fixed hardware clocks on chips that support both fixed and programmable clocks. Default: off

Option N`34`UseVclk1N`34` N`34`booleanN`34`

Use the Vclk1 programmable clock on HiQV chipsets instead of Vclk2. Default: off

Option N`34`FPClock8N`34` N`34`floatN`34`

Option N`34`FPClock16N`34` N`34`floatN`34`

Option N`34`FPClock24N`34` N`34`floatN`34`

Option N`34`FPClock32N`34` N`34`floatN`34`

Force the use of a particular video clock speed for use with the flat panel at a specified depth

Option N`34`MMION`34` N`34`booleanN`34`

Force the use of memory mapped IO for acceleration registers. Default: off

Option N`34`FullMMION`34` N`34`booleanN`34`

Force the use of memory mapped IO where it can be used. Default: off

Option N`34`SuspendHackN`34` N`34`booleanN`34`

Force driver to leave centering and stretching registers alone. This can fix some laptop suspend/resume problems. Default: off

Option N`34`OverlayN`34`

Enable 8+24 overlay mode. Only appropriate for depth 24. Default: off.

Option N`34`ColorKeyN`34` N`34`integerN`34`

Set the colormap index used for the transparency key for the depth 8 plane when operating in 8+16 overlay mode. The value must be in the range 2-255. Default: 255.

Option N`34`VideoKeyN`34` N`34`integerN`34`

This sets the default pixel value for the YUV video overlay key. Default: undefined.

Option N`34`ShadowFBN`34` N`34`booleanN`34`

Enable or disable use of the shadow framebuffer layer. Default: off.

Option N`34`SyncOnGreenN`34` N`34`booleanN`34`

Enable or disable combining the sync signals with the green signal. Default: off.

Option N`34`ShowCacheN`34` N`34`booleanN`34`

Enable or disable viewing offscreen memory. Used for debugging only Default: off.

Option N`34`18bitBusN`34` N`34`booleanN`34`

Force the driver to assume that the flat panel has an 18bit data bus. Default: off.

Option N`34`Crt2MemoryN`34` N`34`integerN`34`

In a dual-head mode (69030 only) this option selects the amount of memory to set aside for the second head. If not specified, half the memory is used. Default: off.

Option N`34`DualRefreshN`34` N`34`integerN`34`

The 69030 supports independent refresh rates on its two display channels. This mode of operations uses additional memory bandwidth and thus limits the maximum colour depth and refresh rate that can be achieved, and so is off by default. Using this option forces the use of an independent refresh rate on the two screens. Default: off.

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x)

You are also recommended to read the README.chips file that comes with all Xorg distributions, which discusses the chips driver in more detail.  

AUTHORS

Authors include: Jon Block, Mike Hollick, Regis Cridlig, Nozomi Ytow, Egbert Eich, David Bateman and Xavier Ducoin

citron

NAME

citron - Citron Infrared Touch Driver (CiTouch)  

SYNOPSIS

Section InputDevice
Identifier idevname
Driver citron
Option Device devpath
  ...
EndSection  

DESCRIPTION

citron is a Xorg input driver for Citron Infrared Touch devices.

The citron driver acts as a pointer input device, and may be used as the X server`s core pointer. It is connected via a "RS232" with the host.  

SUPPORTED HARDWARE

At the moment the following touches are supported. They are also available as ZPress touches.
  IRT6I5-V2.x
 6.5 inch Infrared Touch

IRT10I4-V4.x
 10.4 inch Infrared Touch

IRT12I1-V2.x
 12.1 inch Infrared Touch

IRT15I1-V1.x
 15.1 inch Infrared Touch

 

CONFIGURATION DETAILS

Please refer to xorg.conf(5x) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver. For better understanding please read also the CTS and various IRT manuals which are available in "pdf" format from Citron web page www.citron.de or directly from Citron.

The following driver Options are supported:

Option Device devpath

Specify the device path for the citron touch. Valid devices are:

/dev/ttyS0, /dev/ttyS1, .... This option is mandatory.

It`s important to specify the right device Note: com1 -> /dev/ttyS0, com2 -> /dev/ttyS1 ....

Option ScreenNumber screennumber

sets the screennumber for the citron InputDevice.

Default: ScreenNumber: "0"

Option MinX, MinY value

These are the minimum X and Y values for the citron input device.

Note: MinX, MinY must be less than MaxX, MaxY.

Range: "0" - "65535"

Default: MinX: "0" MinY: "0"

Option MaxX, MaxY value

These are the maximum X and Y values for the citron input device.

Note: MaxX, MaxY must be greater than MinX, MinY.

Range: "0" - "65535"

Default: MaxX: "65535" MaxY: "65535"

Option ButtonNumber value

This value is responsible for the button number that is returned within the xf86PostButton event message

Range: "0" - "255"

Default: "1"

Option ButtonThreshold value

This value is responsible for the button threshold. It changes the pressure sensitivity of the touch. A higher number corresponds to a higher pressure.

Note: This feature is only available with pressure sensitive hardware.

Range: "0" - "255"

Default: "20"

Sleep-Mode

If the IRT is in Doze-Mode and Touch Zone is not interrupted for another certain span of time, the so-called Sleep-Mode is activated. The Sleep-Mode decreases the scan rate of the beams even further than the Doze-Mode does (see below). This way the life expectancy of the beams is prolonged and the power consumption of the IRT is reduced. As soon as an interruption of the Touch Zone is detected, the Sleep-Mode is deactivated and the Touch Zone will again be scanned with the maximum speed. With the Sleep-Mode activated, depending on the set scan rate the IRT`s response time can be considerably longer as in normal operation. If, for example, a scan rate of 500 ms / scan is set, it may last up to a half of a second until the IRT detects the interruption and deactivates the Sleep-Mode.

Option SleepMode mode

This value is responsible for the sleep-mode of the touch.

Determines the behaviour of the Sleep-Mode.

0x00
 No message at either activation or deactivation

0x01
 Message at activation

0x02
 Message at deactivation

0x03
 Message at activation and deactivation

0x10 GP_OUT output set according to the Sleep-Mode status

Values: "0" "1" "2" "3" "16"

Default: "0"

Option SleepTime time

This value is responsible for the sleep-time of the touch. It is the activation time in seconds ("0" = immediately activated, "65535" = always deactivated).

Range: "0" - "65535" [s]

Default: "65535" => deactivated

Option SleepScan scan

This value is responsible for the scan-time of the touch. This is the time interval between two scan operations while in Sleep-Mode. The time interval is set in steps of milliseconds.

Range: "0" - "65535" [ms]

Default: "500"

Option PWMAdjSrc value

Option PWMAdjDst value

These parameters are used to adjust the brightness of different backlight inverters. At the moment 2 backlight inverters are used: 0=TDK 1=AC. If you want a AC backlight inverter to behave like an AC type you have to set PWMAdjSrc to 0 (TDK) and PWMAdjDst to 1 (AC).

Range: "0" - "1"

Default: "-1" (no adjustment)

Option PWMActive value

This value determines the mark-to-space ratio of the PWM output while in normal operation (sleep-mode not active). Higher values result in longer pulse widths. This output signal can be used in conjunction with the Citron AWBI to do backlight-dimming via the touch.

Range: "0" - "255"

Default: "255" (max. brightness)

Option PWMSleep value

This value determines the mark-to-space ratio of the PWM output while in sleep-mode (-> SleepMode, SleepScan, SleepTime ) operation (sleep-mode active). Higher values result in longer pulse widths.

Range: "0" - "255"

Default: "255" (max. brightness)

Option PWMFreq value

This value determines the PWM frequency in Hertz

Range: "39" - "9803"

Default: "9803" (max. frequency)

Option ClickMode mode

With mode one can select between 5 ClickModes

1 = ClickMode Enter

With this mode every interruption of the infrared beams will activate a ButtonPress event and after the interruption a ButtonRelease event will be sent.

2 = ClickMode Dual

With this mode every interruption will sent a Proximity event and every second interruption a ButtonPress event. With the release of the interruption (while one interruption is still active) a ButtonRelease event will be sent.

3 = ClickMode Dual Exit

With this mode every interruption will sent a ProximityIn event and every second interruption a ButtonPress event. With the release of the interruption (while one interruption is still active) no ButtonRelease event will be sent. Only if all interruptions are released a ButtonRelease followed by a ProximityOut event will be sent.

4 = ClickMode ZPress

With this mode every interruption will sent a ProximityIn event. Only if a certain pressure is exceeded a ButtonPress event will occur. If the pressure falls below a certain limit a ButtonRelease event will be sent. After also the interruption is released a ProximityOut event is generated.

5 = ClickMode ZPress Exit

This mode is similat to "Clickmode Dual Exit". The first interruption of the beams will sent a ProximityIn event. Only if a certain pressure is exceeded a ButtonPress event will occur. If the pressure falls below a certain limit no ButtonRelease event will be sent. After the interruption is also released a ButtonRelease followed by a ProximityOut event is generated.

Range: "1" - "5"

Default: "1" (ClickMode Enter)

Option Origin value

This value sets the coordinates origin to one of the four corners of the screen. The following values are accepted: "0" TOPLEFT: Origin set to the left-hand side top corner. "1" TOPRIGHT: Origin set to the right-hand side top corner. "2" BOTTOMRIGHT: Origin set to the right-hand side bottom corner. "3" BOTTOMLEFT: Origin set to the left-hand side bottom corner.

Range: "0" - "3"

Default: "0" (TOPLEFT)

Doze-Mode

If for a certain span of time the Touch Zone is not interrupted, the so-called Doze-Mode is automatically activated. The activated Doze-Mode slightly decreases the scan rate of the beams. This way the power consumption of the IRT is reduced. As soon as an interruption of the Touch Zone is detected, the Doze-Mode is deactivated and the Touch Zone will again be scanned with the maximum speed.

Option DozeMode mode

This value is responsible for the doze-mode of the touch.

Determines the behaviour of the Doze-Mode.

0x00 No message at either activation or deactivation

0x01 Message at activation

0x02 Message at deactivation

0x03 Message at activation and deactivation

0x10 GP_OUT output set according to the Doze-Mode status

If the GP_OUT output is already controlled by the Sleep-Mode it is no longer available as an output port anymore.

Values: "0" "1" "2" "3" "16"

Default: "0"

Option DozeTime time

This value is responsible for the doze-time of the touch. It is the activation time in seconds ("0" = immediately activated, "65535" = always deactivated).

Range: "0" - "65535" [s]

Default: "65535" => deactivated

Option DozeScan scan

This value is responsible for the scan-time of the touch. This is the time interval between two scan operations while in Doze-Mode. The time interval is set in steps of milliseconds.

Range: "0" - "65535" [ms]

Default: "500"

Option DeltaX value

This value determines a virtual area at the left and right side of the current cursor position where the cursor didn`t move. Within this area no "MotionNotify" event will be sent.

Range: "0" - "255"

Default: "0" (no deltaX)

Option DeltaY value

This value determines a virtual area at the top and bottom of the current cursor position where the cursor didn`t move. Within this area no "MotionNotify" event will be sent.

Range: "0" - "255"

Default: "0" (no deltaY)

Option Beep value

This value determines if a "ButtonPress" and/or a "ButtonRelease" event should sound the buzzer. "0" deactivates the buzzer while every other value will activate it.

Range: "0" - "1"

Default: "0" (deactivated)

Option PressVol value

This value determines the volume of the buzzer (0-100%) when a "ButtonPress" event is sent.

Range: "0" - "100"

Default: "100"

Option PressPitch value

This value determines the pitch of the tone when a "ButtonPress" event is sent.

Range: "0" - "3000"

Default: "880"

Option PressDur value

This value determines the duration of the tone in ms when a "ButtonPress" event is sent.

Range: "0" - "255"

Default: "15"

Option ReleaseVol value

This value determines the volume of the buzzer (0-100%) when a "ButtonRelease" event is sent.

Range: "0" - "100"

Default: "100"

Option ReleasePitch value

This value determines the pitch of the tone when when a "ButtonRelease" event is sent.

Range: "0" - "3000"

Default: "1200"

Option ReleseDur value

This value determines the duration of the tone in ms when when a "ButtonRelease" event is sent.

Range: "0" - "255"

Default: "10"

Option BeamTimeout value

Determines the time span in seconds, that has to elapse before a beam is considered defective, blanked-out and excluded from the coordinates evaluation.

Range: "0" - "65535"

Default: "30" (30 seconds)

Option TouchTime value

Determines the minimum time span in steps of 10ms for a valid interruption. In order for an interruption to be reported to the host computer as valid, it needs to remain at the same spot for at least the time span declared here.

Range: "0" - "255"

Default: "0" (=6,5 ms)

Option EnterCount count

Number of skipped "enter reports". Reports are sent approx. every 20ms.

Range: "0" - "31"

Default: "3" (3 skipped messages = 60ms)

Option ZEnterCount count

Number of skipped "enter reports" while in pressure sensitive mode. Reports are sent approx. every 20ms.

Range: "0" - "31"

Default: "1" (1 skipped messages = 20ms)

Option LockZEnterTime count

Minimum duration of an AreaPressEnter state (Pressure > AreaPressure) before a PressEnter event is issued. The time is given in 10ms steps.

Range: "0" - "255"

Default: "1" (10ms)

Option LockZExitTime count

Minimum duration of an AreaPressExit state (Pressure < AreaPressure/2) before a PressExit event is issued. The time is given in 10ms steps.

Range: "0" - "255"

Default: "1" (10ms)

Option LockZLockTime count

Minimum gap between a PressExit and a PressEnter event. The time is in 10ms steps.

Range: "0" - "255"

Default: "10" (100ms)

Option DualCount count

Number of skipped "dual touch error". Reports are sent approx. every 20ms. This option is only available for "ZPress" and "ZPress Exit" modes.

Range: "0" - "31"

Default: "2" (2 skipped messages = 40ms)

 

SEE ALSO

Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7x).  

AUTHORS

2000-2003 - written by Citron GmbH (support@citron.de)