The Linux keyboard and console HOWTO <author>Andries Brouwer, <tt/aeb@cwi.nl/ <date>v2.13, 2002-10-12 <abstract>This note contains some information about the Linux keyboard and console, and the use of non-ASCII characters. It describes Linux 2.0. <nidx>HOWTOs!keyboard and console</nidx> <nidx>HOWTOs!console and keyboard</nidx> </abstract> <toc> <sect>Useful programs<p> <nidx>programs!keyboard-related</nidx> <nidx>programs!console-related</nidx> <nidx>keyboard!programs related to</nidx> <nidx>console!programs related to</nidx> The following packages contain keyboard or console related programs. <p> <tt/kbd-1.06.tar.gz/ contains <tt/loadkeys/, <tt/dumpkeys/, <tt/showkey/, <tt/setmetamode/, <tt/setleds/, <tt/setfont/, <tt/showconsolefont/, <tt/mapscrn/, <tt/kbd_mode/, <tt/kbdrate/, <tt/loadunimap/, <tt/chvt/, <tt/resizecons/, <tt/deallocvt/, <tt/getkeycodes/, <tt/setkeycodes/. It also contains <tt/openvt/, formerly called <tt/open/. <p> There exists a clone of the kbd package, namely <tt/console-tools/, that contains more or less the same stuff. The latest version, <tt/console-tools-0.3.3/ is roughly up-to-date with <tt/kbd-0.99/. <p> <tt/SVGATextMode-1.10/ contains <tt/SVGATextMode/, a program that obsoletes <tt/resizecons/. <p> <tt/util-linux-2.11/ contains <tt/setterm/. <p> <tt/sh-utils-1.12/ contains <tt/stty/. <p> See also <tt/dynamic-vc-1.2.tar.gz/ and <tt/consd-1.3.tgz/ for programs that exploit the `Keyboard Signal' key. Very primitive versions are <tt/spawn_login/ or <tt/spawn_console/ found in the kbd package. <p> See <htmlurl name="font.tgz" url="http://www.cix.co.uk/~mayday/font.tgz"> for a package that handles console fonts. <p> Packages like <tt/recode/ and <tt/konwert-1.8/ allow one to convert between different character encodings. <p> The X distribution contains <tt/xmodmap/, <tt/xset/, <tt/kbd_mode/. (See also X386keybd(1) for the situation under XFree86 1.3, and Xserver(1) for the XKEYBOARD extension under X11R6.) A handy interface to <tt/xmodmap/ is <tt/xkeycaps/, see <htmlurl name="http://www.jwz.org/xkeycaps/" url="www.jwz.org/xkeycaps/">. <tt/termcap-2.0.8.tar.gz/ contains <tt/termcap/, an old terminal capabilities data base. <tt/ncurses-1.9.9e.tar.gz/ contains the <tt/termlib/ data base which obsoletes <tt/termcap/. (However, there are still many programs using <tt/termcap/.) See loadkeys(1), setleds(1) and setmetamode(1) for the codes generated by the various keys and the setting of leds when not under X. Under X, see xmodmap(1) and xset(1). See setfont(8) for loading console fonts. Many people will want to load a font like <tt/iso01.f16/ because the default font is the hardware font of the video card, and often is a `Code Page 437' font missing accented characters and other Latin-1 symbols. See setterm(1) and kbdrate(8) for properties such as foreground and background colors, screen blanking and character repeat rate when not under X. Under X, see xset(1), also for key click and bell volume. The file <tt>/etc/termcap</tt> defines the escape sequences used by many programs addressing the console (or any other terminal). See termcap(5). A more modern version is found in <tt>/usr/lib/terminfo</tt>. See terminfo(5). Terminfo files are compiled by the terminfo compiler <tt>/usr/lib/terminfo/tic</tt>, see tic(1). Their contents can be examined using the program <tt/infocmp/, see infocmp(1). The Linux console sequences are documented in console_codes(4). The package <tt>funkey</tt> by Rick van Rein provides support for all these new keys modern keyboards have. See <htmlurl url="http://rick.vanrein.org/linux/funkey" name="rick.vanrein.org/linux/funkey">. <sect>Keyboard generalities<p> <nidx>keyboard!theory of operation</nidx> You press a key, and the keyboard controller sends <htmlurl name="scancodes" url="http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html"> to the kernel keyboard driver. Some keyboards can be programmed, but usually the scancodes corresponding to your keys are fixed. The kernel keyboard driver just transmits whatever it receives to the application program when it is in <em>scancode mode</em>, like when <tt/X/ is running. Otherwise, it parses the stream of scancodes into keycodes, corresponding to key press or key release events. (A single key press can generate up to 6 scancodes.) These keycodes are transmitted to the application program when it is in <em>keycode mode</em> (as used, for example, by <tt/showkey/ and some X servers). Otherwise, these keycodes are looked up in the keymap, and the character or string found there is transmitted to the application, or the action described there is performed. (For example, if one presses and releases the <tt/a/ key, then the keyboard produces scancodes 0x1e and 0x9e, this is converted to keycodes 30 and 158, and then transmitted as 0141, the ASCII or latin-1 code for `a'; if one presses and releases <tt/Delete/, then the keyboard produces scancodes 0xe0 0x53 0xe0 0xd3, these are converted to keycodes 111 and 239, and then transmitted as the 4-symbol sequence ESC [ 3 ˜, all assuming a US keyboard and a default keymap. An example of a key combination to which an action is assigned is Ctrl-Alt-Del.) <P> The translation between unusual scancodes and keycodes can be set using the utility <tt/setkeycodes/ - only few people will need it. The translation between keycodes and characters or strings or actions, that is, the keymap, is set using the utilities <tt/loadkeys/ and <tt/setmetamode/. For details, see getkeycodes(8), setkeycodes(8), dumpkeys(1), loadkeys(1), setmetamode(1). The format of the files output by <tt/dumpkeys/ and read by <tt/loadkeys/ is described in keymaps(5). <P> Where it says `transmitted to the application' in the above description, this really means `transmitted to the terminal driver'. That is, further processing is just like that of text that comes in over a serial line. The details of this processing are set by the program <tt/stty/. <sect>Console generalities<p> <nidx>console!theory of operation</nidx> Conversely, when you output something to the console, it first undergoes the standard tty processing, and then is fed to the console driver. The console driver emulates a VT100, and parses the input in order to recognize VT100 escape sequences (for cursor movement, clear screen, etc.). The characters that are not part of an escape sequence are first converted into Unicode, using one of four mapping tables if the console was not in UTF-8 mode to start with, then looked up in the table describing the correspondence between Unicode values and font positions, and the obtained 8- or 9-bit font indices are then written to video memory, where they cause the display of character shapes found in the video card's character ROM. One can load one's own fonts into character ROM using <tt/setfont/. The obsolete programs <tt/loadunimap/ and <tt/mapscrn/ can be used to manipulate the Unicode map belonging to the font, or the mapping table of the console. More details will be given below. There are many consoles (called <it/Virtual Consoles/ or <it/Virtual Terminals/, abbreviated VCs or VTs) that share the same screen. You can use them as independent devices, either to run indendent login sessions, or just to send some output to, perhaps from <tt/top/, or the tail of the system log or so. See below (`Console switching') on how to set them up and switch between them. <sect>Resetting your terminal<p> <nidx>terminal!resetting</nidx> <nidx>screen!clearing</nidx> <nidx>console!clearing</nidx> There is garbage on the screen, or all your keystrokes are echoed as line drawing characters. What to do? Many programs will redraw the screen when Ctrl-L is typed. This might help when there is some modem noise or broadcast message on your screen. The command <tt/clear/ will clear the screen. The command <tt/reset/ will reset the console driver. This helps when the screen is full of funny graphic characters, and also if it is reduced to the bottom line. If you don't have this command, or if it does something else, make your own by putting the following two lines in an executable file <tt/reset/ in your PATH: <tscreen><verb> #!/bin/sh echo -e \\033c </verb></tscreen> that is, you want to send the two characters ESC c to the console. Why is it that the display sometimes gets confused and gives you a 24-line or 1-line screen, instead of the usual 25 lines? Well, the main culprit is the use of <tt/TERM=vt100/ (or some other entry with 24 lines) instead of <tt/TERM=linux/ when logged in remotely. If this happens on <tt>/dev/tty2</tt> then typing <tscreen><verb> % cat > /dev/tty2 ^[c ^D </verb></tscreen> on some other VT (where 4 symbols are typed to <tt/cat/: ESC, c, ENTER, Ctrl-D) and refreshing the screen on <tt>/dev/tty2</tt> (perhaps using Ctrl-L) will fix things. Of course the permanent fix is to use the right termcap or terminfo entry. A command that only changes the number of lines is <tscreen><verb> % echo -e "\033[1;25r" </verb></tscreen> Why is it that you sometimes get a lot of line-drawing characters, e.g., after catting a binary to the screen? Well, there are various character set changing escape sequences, and by accident your binary might contain some of these. The ESC c is a general reset, a cure for all, but if you know precisely what went wrong you can repair it without resetting other console attributes. For example, after <tscreen><verb> % cat ^N ^D </verb></tscreen> your shell prompt will be all line-drawing characters. Now do (typing blindly) <tscreen><verb> % cat ^O ^D </verb></tscreen> and all is well again. (Three symbols typed to each <tt/cat/: Ctrl-N (or Ctrl-O), ENTER, Ctrl-D.) To understand what is happening, see `The console character sets' below. If you loaded some strange font, and want to return to the default, <tscreen><verb> % setfont </verb></tscreen> will do (provided you stored the default font in the default place). If this default font does not contain an embedded Unicode map (and gives the wrong symbols for accented characters), then say <tscreen><verb> % loadunimap </verb></tscreen> For example, if I do <tscreen><verb> % loadkeys de-latin1 </verb></tscreen> then I have a German keyboard, and the key left of the Enter key gives me a-umlaut. This works, because the a-umlaut occurs on the CP437 code page and the kernel Unicode map is initialized to CP437, and my video card has a CP437 font built-in. If I now load an ISO 8859-1 font with <tscreen><verb> % setfont iso01.f16 </verb></tscreen> then everything still works, because <tt/setfont/ invalidates the kernel Unicode map (if there is no Unicode map attached to the font), and without map the kernel goes directly to the font, and that is precisely correct for an ISO 8859-1 system with <tt/iso01.f16/ font. But going back to the previous font with <tscreen><verb> % setfont </verb></tscreen> gives capital Sigma's instead of a-umlaut - all accented letters are mixed up because also this font has no embedded Unicode map. After <tscreen><verb> % loadunimap </verb></tscreen> which loads the default Unicode map (which is right for the default font) all works correctly again. Usually <tt/loadunimap/ is not invoked directly, but via <tt/setfont/. Thus, the previous two commands may be replaced by <tscreen><verb> % setfont -u def </verb></tscreen> These days most fonts have embedded Unicode maps (often this is indicated by the extension <tt/.psfu/), and none of this nonsense is needed anymore. On very old terminals output involving tabs may require a delay, and you have to say <tscreen><verb> % stty tab3 </verb></tscreen> (see stty(1)). You can change the video mode using <tt/resizecons/ or <tt/SVGATextMode/. Or by rebooting and having "vga=ask" in the LILO configuration file. This usually settles the output side. On the input side there are many things that might be wrong. If <tt/X/ or <tt/DOOM/ or some other program using raw mode crashed, your keyboard may still be in raw (or mediumraw) mode, and it is difficult to give commands. (See "How to get out of raw mode" below.) If you loaded a bad keymap, then <tscreen><verb> % loadkeys -d </verb></tscreen> loads the default map again, but it may well be difficult to type `-'! An alternative is <tscreen><verb> % loadkeys defkeymap </verb></tscreen> Sometimes even the letters are garbled. It is useful to know that there are four main types of keyboards: QWERTY, QWERTZ, AZERTY and DVORAK. The first three are named after the first six letter keys, and roughly represent the English, German and French speaking countries. Compared to QWERTY, the QWERTZ map interchanges Y and Z. Compared to QWERTY, the AZERTY map interchanges Q and A, W and Z, and has its M right of the L, at the semicolon position. DVORAK has an entirely different letter ordering. There are two types of Turkish keyboard. The so-called `Q'-keyboard has a QWERTY layout, while the `F'-keyboard has an entirely different layout, let us say fgGIod, where G stands for Gbreve and I for dotlessi. <sect1>Keyboard hardware reset<p> <nidx>keyboard!resetting</nidx> Things may be wrong on a lower level than Linux knows about. There are at least two distinct lower levels (keyboard and keyboard controller) where one can give the command "keyboard disable" to the keyboard hardware. Keyboards can often be programmed to use one out of three different sets of scancodes. <p> However, I do not know of cases where this turned out to be a problem. <p> Some keyboards have a remapping capability built in. Stormy Henderson (<tt/stormy@Ghost.Net/) writes: `If it's your keyboard accidently being reprogrammed, you can (on a Gateway AnyKey keyboard) press control-alt-suspend_macro to reset the keys to normal.' <sect>Delete and Backspace<p> <nidx>delete key!problems with</nidx> <nidx>backspace key!problems with</nidx> Getting Delete and Backspace to work just right is nontrivial, especially in a mixed environment, where you talk to console, to <tt/X/, to <tt/bash/, to <tt/emacs/, login remotely, etc. You may have to edit several configuration files to tell all of the programs involved precisely what you want. On the one hand, there is the matter of which keys generate which codes (and how these codes are remapped by e.g. <tt/kermit/ or <tt/emacs/), and on the other hand the question of what functions are bound to what codes. People often complain `my backspace key does not work', as if this key had a built-in function `delete previous character'. Unfortunately, all this key, or any key, does is producing a code, and one only can hope that the kernel tty driver and all application programs can be configured such that the backspace key indeed does function as a `delete previous character' key. Most Unix programs get their tty input via the kernel tty driver in `cooked' mode, and a simple <tt/stty/ command determines the erase character. However, programs like <tt/bash/ and <tt/emacs/ and <tt/X/ do their own input handling, and have to be convinced one-by-one to do the right thing. <sect1>How to tell Unix what character you want to use to delete the last typed character<p> <nidx>stty!using to set erase character</nidx> <tscreen><verb> % stty erase ^? </verb></tscreen> If the character is erased, but in a funny way, then something is wrong with your tty settings. If <tt/echoprt/ is set, then erased characters are enclosed between <tt>\</tt> and <tt>/</tt>. If <tt/echoe/ is not set, then the erase char is echoed (which is reasonable when it is a printing character, like #). Most people will want <tt/stty echoe -echoprt/. Saying <tt/stty sane/ will do this and more. Saying <tt/stty -a/ shows your current settings. How come this is not right by default? It is, if you use the right <tt/getty/. Note that many programs (like <tt/bash/, <tt/emacs/ etc.) have their own keybindings (defined in <tt>˜/.inputrc</tt>, <tt>˜/.emacs</tt> etc.) and are unaffected by the setting of the erase character. The standard Unix tty driver does not recognize a cursor, or keys (like the arrow keys) to move the current position, and hence does not have a command `delete current character' either. But for example you can get <tt/bash/ on the console to recognize the Delete key by putting <tscreen><verb> set editing-mode emacs "\e[3˜":delete-char </verb></tscreen> into <tt>˜/.inputrc</tt>. <sect2>`Getty used to do the right thing with DEL and BS but is broken now?'<p> <nidx>getty!problems with BS and DEL</nidx> Earlier, the console driver would do BS Space BS (<tt>\010\040\010</tt>) when it got a DEL (<tt>\177</tt>). Nowadays, DEL's are ignored (as they should be, since the driver emulates a vt100). Get a better getty, i.e., one that does not output DEL. <sect2>`Login behaves differently at the first and second login attempts?'<p> <nidx>login!problems with BS and DEL</nidx> At the first attempt, you are talking to <tt/getty/. At the second attempt, you are talking to <tt/login/, a different program. <sect1>How to tell Linux what code to generate when a key is pressed<p> <nidx>keyboard!keycode remapping</nidx> <nidx>keycode remapping</nidx> On the console, or, more precisely, when not in (MEDIUM)RAW mode, use <tscreen><verb> % loadkeys mykeys.map </verb></tscreen> and under X use <tscreen><verb> % xmodmap mykeys.xmap </verb></tscreen> Note that (since XFree86-2.1) X reads the Linux settings of the keymaps when initialising the X keymap. Although the two systems are not 100% compatible, this should mean that in many cases the use of <tt/xmodmap/ has become superfluous. For example, suppose that you would like the Backspace key to send a BackSpace (Ctrl-H, octal 010) and the grey Delete key a DEL (octal 0177). Add the following to <tt>/etc/rc.local</tt> (or wherever you keep your local boot-time stuff): <tscreen><verb> /usr/bin/loadkeys << EOF keycode 14 = BackSpace keycode 111 = Delete EOF </verb></tscreen> Note that this will only change the function of these keys when no modifiers are used. (You need to specify a keymaps line to tell which keymaps should be affected if you want to change bindings on more keymaps.) The Linux kernel default lets Ctrl-Backspace generate BackSpace - this is sometimes useful as emergency escape, when you find you can only generate DELs. The left Alt key is sometimes called the Meta key, and by default the combinations AltL-X are bound to the symbol MetaX. But what character sequence is MetaX? That is determined (per-tty) by the Meta flag, set by the command <tt/setmetamode/. The two choices are: ESC X or X or-ed with 0200. Many distributions have a <tt/loadkeys/ command somewhere in the bootup sequence. For example, one may have the name of the desired keymap in <tt>/etc/sysconfig/keyboard</tt> and the <tt/loadkeys/ command that loads it in <tt>/etc/rc.d/init.d/keytable</tt>. Or one may have the actual default keymap in <tt>/etc/default.keytab</tt> and the loadkeys command that loads it in <tt>/etc/rc.d/boot</tt>. Etc. Instead of adding a local modification to the default, one can of course change the default by editing the default keymap or changing the name of the keymap to be loaded at boot time. Note that <tt/loadkeys/ itself has default keymap <tt/defkeymap.map/ located somewhere under <tt>/usr/lib/kbd</tt> or <tt>/usr/share/kbd</tt> (just like all other keymaps) and this may not yet be available in single user boot before <tt>/usr</tt> has been mounted. <sect2>`How do I get a dvorak keyboard?'<p> <nidx>dvorak keyboard</nidx> The command <tscreen><verb> % loadkeys dvorak </verb></tscreen> will give you a dvorak layout, probably by loading something like <tt>/usr/lib/kbd/keymaps/i386/dvorak/dvorak.map.gz</tt>. Under <tt/X/, put <tscreen><verb> XkbLayout "dvorak" </verb></tscreen> in <tt>XF86Config</tt>. <sect2>`Why doesn't the Backspace key generate BackSpace by default?'<p> <nidx>backspace key!not generating correct keycode</nidx> (i) Because the VT100 had a Delete key above the Enter key. <p> (ii) Because Linus decided so. <sect1>How to tell X to interchange Delete and Backspace<p> <nidx>X!swapping DEL, BS</nidx> <nidx>xmodmap!using to swap DEL, BS</nidx> <tscreen><verb> % xmodmap -e "keysym BackSpace = Delete" -e "keysym Delete = BackSpace" </verb></tscreen> Or, if you just want the Backspace key to generate a BackSpace: <tscreen><verb> % xmodmap -e "keycode 22 = BackSpace" </verb></tscreen> Or, if you just want the Delete key to generate a Delete: <tscreen><verb> % xmodmap -e "keycode 107 = Delete" </verb></tscreen> (but usually this is the default binding already). <sect1>How to tell emacs what to do when it receives a Delete or Backspace<p> <nidx>emacs!binding DEL, BS</nidx> Put in your <tt/.emacs/ file lines like <tscreen><verb> (global-set-key "\?" 'help-command) (global-set-key "\C-h" 'delete-backward-char) </verb></tscreen> Of course you can bind other commands to other keys in the same way. Note that various major and minor modes redefine keybindings. For example, in incremental search mode one finds the code <tscreen><verb> (define-key map "\177" 'isearch-delete-char) (define-key map "\C-h" 'isearch-mode-help) </verb></tscreen> This means that it may be a bad idea to use the above two global-set-key commands. There are too many places where there are built-in assumptions about Ctrl-H = help and DEL = delete. That doesn't mean that you have to setup keys so that Backspace generates DEL. But if it doesn't then it is easiest to remap them at the lowest possible level in emacs. <sect1>How to tell emacs to interchange Delete and Backspace<p> <nidx>emacs!swapping DEL, BS</nidx> Put in your <tt/.emacs/ file lines <tscreen><verb> (setq keyboard-translate-table (make-string 128 0)) (let ((i 0)) (while (< i 128) (aset keyboard-translate-table i i) (setq i (1+ i)))) (aset keyboard-translate-table ?\b ?\^?) (aset keyboard-translate-table ?\^? ?\b) </verb></tscreen> Recent versions of emacs have a function <tt/keyboard-translate/ and one may simplify the above to <tscreen><verb> (keyboard-translate ?\C-h ?\C-?) (keyboard-translate ?\C-? ?\C-h) </verb></tscreen> Note that under X emacs can distinguish between Ctrl-h and the Backspace key (regardless of what codes these produce on the console), and by default emacs will view the Backspace key as DEL (and do deletion things, as bound to that character, rather than help things, bound to Ctrl-H). One can distinguish Backspace and Delete, e.g. by <tscreen><verb> (global-unset-key [backspace] ) (global-set-key [backspace] 'delete-backward-char) (global-unset-key [delete] ) (global-set-key [delete] 'delete-char) </verb></tscreen> <sect1>How to tell kermit to interchange Delete and Backspace<p> <nidx>kermit!swapping DEL, BS</nidx> Put in your <tt/.kermrc/ file the lines <tscreen><verb> set key \127 \8 set key \8 \127 </verb></tscreen> <sect1>How to tell xterm to interchange Delete and Backspace<p> <nidx>xterm!swapping DEL, BS</nidx> <tscreen><verb> XTerm*VT100.Translations: #override\n\ <KeyPress> BackSpace : string(0x7f)\n\ <KeyPress> Delete : string(0x08)\n </verb></tscreen> <sect1>How to tell xterm about your favourite tty modes<p> <nidx>xterm!setting tty modes for</nidx> Normally xterm will inherit the tty modes from its invoker. Under <tt/xdm/, the default erase and kill characters are <tt/#/ and <tt/@/, as in good old Unix Version 6. If you don't like that, you might put something like <tscreen><verb> XTerm*ttymodes: erase ^? kill ^U intr ^C quit ^\ eof ^D \ susp ^Z start ^Q stop ^S eol ^@ </verb></tscreen> in <tt>/usr/lib/X11/app-defaults/XTerm</tt> or in <tt>$HOME/.Xresources</tt>, assuming that you have a line <tscreen><verb> xrdb -merge $HOME/.Xresources </verb></tscreen> in your <tt>$HOME/.xinitrc</tt> or <tt>$HOME/.xsession</tt>. <sect1>How to tell non-Motif X applications that the Del key deletes forward<p> Put <tscreen><verb> *Text.translations: #override \ ~Shift ~Meta <Key>Delete: delete-next-character() </verb></tscreen> into <tt>.Xresources</tt> to make non-Motif X applications such as <tt>xfig</tt>, <tt>xedit</tt>, etc., work correctly. (Daniel T. Cobra) <sect1>How to tell xmosaic that the Backspace key generates a DEL<p> <nidx>xmosaic!remapping BS key</nidx> <nidx>Netscape!remapping BS</nidx> Putting <tscreen><verb> *XmText.translations: #override\n\ <Key>osfDelete: delete-previous-character() *XmTextField.translations: #override\n\ <Key>osfDelete: delete-previous-character() </verb></tscreen> in your <tt>$HOME/.Xdefaults</tt> or <tt>$HOME/.Xresources</tt> helps. (What file? The file that is fed to <tt>xrdb</tt>, for example in <tt>.xinitrc</tt>.) The netscape FAQ, however, says: <verb> Why doesn't my Backspace key work in text fields? By default, Linux and XFree86 come with the Backspace and Delete keys misconfigured. All Motif programs (including, of course, Netscape Navigator) will malfunction in the same way. The Motif spec says that Backspace is supposed to delete the previous character and Delete is supposed to delete the following character. Linux and XFree86 come configured with both the Backspace and Delete keys generating Delete. You can fix this by using any one of the xmodmap, xkeycaps, or loadkeys programs to make the key in question generate the BackSpace keysym instead of Delete. You can also fix it by having a .motifbind file; see the man page for VirtualBindings(3). Note: Don't use the *XmText.translations or *XmTextField.translations resources to attempt to fix this problem. If you do, you will blow away Netscape Navigator's other text-field key bindings. </verb> <sect1>A better solution for Motif-using programs, like netscape<p> <nidx>Netscape!remapping BS</nidx> <nidx>Motif!remapping BS</nidx> Ted Kandell (<tt/ted@tcg.net/) suggests the following: Somewhere in your .profile add the following: <tscreen><verb> stty erase ^H </verb></tscreen> If you are using <tt/bash/, add the following lines to your <tt/.inputrc/: <tscreen><verb> "\C-?": delete-char "\C-h": backward-delete-char </verb></tscreen> Add the following lines to your .xinitrc file: <tscreen><verb> xmodmap <<-EOF keycode 22 = BackSpace osfBackSpace keycode 107 = Delete EOF # start your window manager here, for example: #(fvwm) 2>&1 | tee /dev/tty /dev/console stty sane stty erase ^H loadmap <<-EOF keycode 14 = BackSpace keycode 111 = Delete EOF </verb></tscreen> This will definitely work for a PC 101 or 102 key keyboard with any Linux/XFree86 layout. The important part to making Motif apps like Netscape work properly is adding osfBackSpace to keycode 22 in addition to BackSpace. Note that there must be spaces on either side of the = sign. <sect1>What about termcap and terminfo?<p> <nidx>termcap!remapping BS with</nidx> <nidx>terminfo!remapping BS with</nidx> When people have problems with backspace, they tend to look at their termcap (or terminfo) entry for the terminal, and indeed, there does exist a kb (or kbs) capability describing the code generated by the Backspace key. However, not many programs use it, so unless you are having problems with one particular program only, probably the fault is elsewhere. Of course it is a good idea anyway to correct your termcap (terminfo) entry. See also below under "The TERM variable". <sect1>A complete solution<p> There are many possibilities to get a functioning system. Can't you give one complete set of settings that works? <nidx>delete key!a solution</nidx> <nidx>backspace key!a solution</nidx> <p> One way of getting a setup that works in all contexts is to have the Backspace key generate DEL when on the console (or xterm), and BackSpace when under X. Maybe that is most convenient - there are too many X utilities that expect BackSpace, and emacs on the console or xterm expects DEL, while emacs under X can distinguish [BackSpace] from Ctrl-H and does the right thing. <p> What is needed? No loadkeys changes, since the Backspace key already generates DEL by default. No stty settings, they are OK by default. No X settings, they are OK by default. One just has to tell xterm that the Backspace key should generate DEL: put <tscreen><verb> XTerm*VT100.Translations: #override\n\ <KeyPress> BackSpace : string(0x7f)\n\ </verb></tscreen> in <tt/.Xresources/, and <tscreen><verb> xrdb -merge .Xresources </verb></tscreen> in <tt/.xinitrc/, and you are settled. For a much more extensive discussion of these things, and alternative solutions, see <htmlurl url="http://www.ibb.net/~anne/keyboard.html" name="Anne Baretta's page">. <sect>The console character sets<p> <nidx>console character sets</nidx> <nidx>character sets, console</nidx> The kernel first tries to figure out what symbol is meant by any given user byte, and next where this symbol is located in the current font. The kernel knows about 5 translations of bytes into console-screen symbols. In Unicode (UTF-8) mode, the UTF-8 code is just converted directly into Unicode. The assumption is that almost all symbols one needs are present in Unicode, and for the cases where this does not hold the codes 0xf000-0xf1ff are reserved for direct font access. When not in Unicode mode, one of four translation tables is used. The four tables are: a) Latin1 -> Unicode, b) VT100 graphics -> Unicode, c) PC -> Unicode, d) user-defined. There are two character sets, called G0 and G1, and one of them is the current character set. (Initially G0.) Typing Ctrl-N causes G1 to become current, Ctrl-O causes G0 to become current. These variables G0 and G1 point at a translation table, and can be changed by the user. Initially they point at tables a) and b), respectively. The sequences ESC ( B and ESC ( 0 and ESC ( U and ESC ( K cause G0 to point at translation table a), b), c) and d), respectively. The sequences ESC ) B and ESC ) 0 and ESC ) U and ESC ) K cause G1 to point at translation table a), b), c) and d), respectively. The sequence ESC c causes a terminal reset, which is what you want if the screen is all garbled. The oft-advised <tt/echo ˆVˆO/ will only make G0 current, but there is no guarantee that G0 points at table a). In some distributions there is a program reset(1) that just does <tt>echo ˆ[c</tt>. If your termcap entry for the console is correct (and has an entry <tt>:rs=\Ec:</tt>), then also <tt/setterm -reset/ will work. The user-defined mapping table can be set using mapscrn(8). The result of the mapping is that if a symbol c is printed, the symbol <tt>s = map[c]</tt> is sent to the video memory. The bitmap that corresponds to <tt/s/ is found in the character ROM, and can be changed using setfont(8). <sect>Console switching<p> <nidx>console!switching</nidx> By default, console switching is done using Alt-Fn or Ctrl-Alt-Fn. Under <tt/X/ (or recent versions of <tt/dosemu/), only Ctrl-Alt-Fn works. Many keymaps will allow cyclic walks through all allocated consoles using Alt-RightArrow and Alt-LeftArrow. XFree86 1.3 does not know that Alt is down when you switch to the X window. Thus, you cannot switch immediately to some other VT again but have to release Alt first. In the other direction this should work: the kernel always keeps track of the up/down status of all keys. (As far as possible: on some keyboards some keys do not emit a scancode when pressed (e.g.: the PFn keys of a FOCUS 9000) or released (e.g.: the Pause key of many keyboards).) XFree86 1.3 saves the fonts loaded in the character ROMs when started, and restores it on a console switch. Thus, the result of <tt/setfont/ on a VT is wiped out when you go to X and back. Using <tt/setfont/ under X will lead to funny results. One can change VT under program control using the <tt/chvt/ command. <sect1>Changing the number of Virtual Consoles<p> <nidx>console!changing number of</nidx> This question still comes up from time to time, but the answer is: you already have enough of them. Since kernel version 1.1.54, there are between 1 and 63 virtual consoles. A new one is created as soon as it is opened. It is removed by the utility <tt/deallocvt/ (but it can be removed only when no processes are associated to it anymore, and no text on it has been selected by programs like <tt/selection/ or <tt/gpm/). For older kernels, change the line <tscreen><verb> #define NR_CONSOLES 8 </verb></tscreen> in <tt>include/linux/tty.h</tt> (don't increase this number beyond 63), and recompile the kernel. If they do not exist yet, create the tty devices with <tt/MAKEDEV/ or <tt/mknod tty/N <tt/c 4/ N where N denotes the tty number. For example, <tscreen><verb> for i in 9 10 11 12; do mknod /dev/tty$i c 4 $i; done </verb></tscreen> or, better (since it also takes care of owner and permissions), <tscreen><verb> for i in 9 10 11 12; do /dev/MAKEDEV tty$i; done </verb></tscreen> If you want the new VCs to run <tt/getty/, add lines in <tt>/etc/inittab</tt>. (But it is much better to have only two <tt/getty/'s running, and to create more consoles dynamically as the need arises. That way you'll have more memory when you don't use all these consoles, and also more consoles, in case you really need them. Edit <tt>/etc/inittab</tt> and comment out all <tt/getty/'s except for the first two.) When the consoles are allocated dynamically, it is usually easiest to have only one or two running <tt/getty/. More are opened by <tt>open -l -s bash</tt>. Unused consoles (without associated processes) are deallocated using <tt/deallocvt/ (formerly <tt/disalloc/). But, you say, I am involved in activities when I suddenly need more consoles, and do not have a bash prompt available to give the <tt/open/ command. Fortunately it is possible to create a new console upon a single keystroke, regardless of what is happening at the current console. If you have <tt/spawn_login/ from <tt/kbd-1.04.tar.gz/ and you put <tscreen><verb> loadkeys << EOF alt keycode 103 = Spawn_Console EOF spawn_login & </verb></tscreen> in <tt>/etc/rc.local</tt>, then typing Alt-UpArrow will create a fresh VC running <tt/login/ (and switch to it). With <tt/spawn_console &/ instead of <tt/spawn_login &/ you'll have bash running there. See also <tt>open-1.4.tgz</tt> and <tt/dynamic-vc-1.1.tar.gz/. What action should be taken upon this Spawn_Console keypress can also be set in <tt>/etc/inittab</tt> under <tt/kbrequest/, if you have a recent <tt/init/. See inittab(5). (This action can be something entirely different - I just called the key Spawn_Console because that is what I used it for. When used for other purposes it is less confusing to use its synonym KeyboardSignal. For example, some people like to put the lines <tscreen><verb> kb::kbrequest:/sbin/shutdown -h now </verb></tscreen> in <tt>/etc/inittab</tt>, and <tscreen><verb> control alt keycode 79 = KeyboardSignal control alt keycode 107 = KeyboardSignal </verb></tscreen> in their keymap. Now Ctrl-Alt-End will do a system shutdown.) You can only login as "root" on terminals listed in <tt>/etc/securetty</tt>. There exist programs that read terminal settings from files <tt>/etc/ttys</tt> and <tt>/etc/ttytype</tt>. If you have such files, and create additional consoles, then it might be a good idea to also add entries for them in these files. <sect>Ctrl-Alt-Del and other special key combinations<p> <sect1>Ctrl-Alt-Del (Boot)<p> <nidx>ctrl-alt-del!action taken by</nidx> If you press Ctrl-Alt-Del (or whatever key was assigned the keysym Boot by loadkeys) then either the machine reboots immediately (without sync), or <tt/init/ is sent a SIGINT. The former behaviour is the default. The default can be changed by root, using the system call reboot(), see ctrlaltdel(8). Some <tt/init/'s change the default. What happens when <tt/init/ gets SIGINT depends on the version of <tt/init/ used - often it will be determined by the pf entry in <tt>/etc/inittab</tt> (which means that you can run an arbitrary program in this case). In the current kernel Ctrl-AltGr-Del is no longer by default assigned to Boot. <sect1>Other combinations<p> <nidx>keyboard!special key combinations</nidx> <nidx>key combinations, special</nidx> <verb> Name Default binding ------------------------------- Show_Memory Shift-Scrollock Show_Registers AltGr-ScrollLock Show_State Ctrl-ScrollLock Console_n Alt-Fn and Ctrl-Alt-Fn (1 <= n <= 12) Console_{n+12} AltGr-Fn (1 <= n <= 12) Incr_Console Alt-RightArrow Decr_Console Alt-LeftArrow Last_Console Alt[Gr]-PrintScreen Scroll_Backward Shift-PageUp Scroll_Forward Shift-PageDown Caps_On (CapsLock is a toggle; this key sets) Compose Ctrl-. </verb> <sect1>X Combinations<p> <nidx>keyboard!key combinations for X</nidx> <nidx>key combinations, X</nidx> <nidx>X!key combinations for</nidx> <verb> Ctrl-Alt-Fn Switch to VT n Ctrl-Alt-KP+ Next mode Ctrl-Alt-KP- Previous mode Ctrl-Alt-Backspace Kill X </verb> On some motherboards, Ctrl-Alt-KP- and Ctrl-Alt-KP+ will be equivalent to pressing the Turbo button. That is, both will produce the scancodes 1d 38 4a ca b8 9d and 1d 38 4e ce b8 9d, and both will switch between Turbo (>= 25MHz) and non-Turbo (8 or 12 MHz). (Often these key combinations only function this way when enabled by jumpers on the motherboard.) Perry F Nguyen (<tt/pfnguyen@netcom22.netcom.com/) writes: AMI BIOS has a feature that locks up the keyboard and flashes the LED's if the Ctrl-Alt-Backspace combination is pressed while a BIOS password is enabled, until the CMOS/BIOS password is typed in. On some SiS based motherboards the combination Ctrl-Alt-Backspace will cause a power off, or puts the machine in power save mode. (Reported for SiS 630 and for SiS645DX.) <sect1>Dosemu Combinations<p> <nidx>key combinations!dosemu</nidx> <nidx>dosemu!key combinations for</nidx> <verb> Ctrl-Alt-Fn Switch to VT n (from version 0.50; earlier Alt-Fn) Ctrl-Alt-PgDn Kill dosemu (when in RAW keyboard mode) (and many other combinations - see the dosemu documentation) </verb> <sect1>Composing symbols<p> <nidx>keyboard!composing symbols with</nidx> <nidx>symbols!composing with keyboard</nidx> One symbol may be constructed using several keystrokes. <itemize> <item> LeftAlt-press, followed by a decimal number typed on the keypad, followed by LeftAlt-release, yields the symbol with code given by this number. (In Unicode mode this same mechanism, but then with 4 hexadecimal digits, may be used to define a Unicode symbol.) <item> A dead diacritic followed by a symbol, yields that symbol adorned with that diacritic. If the combination is undefined, both keys are taken separately. Which keys are dead diacritics is user-settable; none is by default. Five (since 2.0.25 six) dead diacritics can be defined (using loadkeys(1)): dead_grave, dead_acute, dead_circumflex, dead_tilde, dead_diaeresis (and dead_cedilla). Precisely what this adorning means is also user-settable: dead-diacritic, symbol is equivalent to Compose + diacritic + symbol. <item> Compose followed by two symbols yields a combination symbol. These combinations are user-settable. Today there are 68 combinations defined by default; you can see them by saying "dumpkeys | grep compose". <item> Then there are `Sticky' modifier keys (since 1.3.33). For example, one can type Ctrl-C as SControl, C and Ctrl-Alt-BackSpace as SControl, SAlt, BackSpace. </itemize> Note that there are at least four such composition mechanisms: <enum> <item> The Linux keyboard driver mechanism, used in conjunction with loadkeys. <item> The X mechanism - see X386keybd(1), later XFree86kbd(1). Under X11R6: edit <tt>/usr/X11R6/lib/X11/locale/iso8859-1/Compose</tt>.<p> See also Andrew D. Balsa's comments at <htmlurl url="http://wauug.erols.com/~balsa/linux/deadkeys/index.html" name="http://wauug.erols.com/~balsa/linux/deadkeys/index.html">. <item> The emacs mechanism obtained by loading "iso-insert.el" or calling `iso-accents-mode'. <item> The vim mechanism: insert a composed symbol by pressing Ctrl-K followed by two symbols. A list of the possible combinations is obtained by the command <tt>:digraphs</tt>. </enum> For X the order of the two symbols is arbitrary: both Compose-,-c and Compose-c-, yield a c-cedilla; for Linux and emacs only the former sequence works by default. For X and vim the list of compose combinations is fixed. Linux and emacs are flexible. The default lists are somewhat similar, but the details are different. <sect1>The SysRq key<p> <nidx>SysRq key</nidx> In case your kernel was compiled with CONFIG_MAGIC_SYSRQ enabled (a feature that is present since Linux 2.1.43) there is a single key (defined in <tt><linux/keyboard.h></tt>) to which special system functions are attached, regardless of the current keyboard mode. For the PC architecture this special key is, naturally, the Alt+SysRq key, and any of the two Alt keys will work. (Note that if CONFIG_MAGIC_SYSRQ was not enabled, the default action of this key is to return to the previous console.) <p> If you press this key, do not release it, and hit another key, a corresponding action is performed. The action is performed whether anybody is logged in or not, is root or not. For the details, see <tt>drivers/char/sysrq.c</tt>. Since this feature is meant only for kernel hackers, that should suffice. Still, let me add a few remarks. <p> For the key r the keyboard mode is reset to K_XLATE. For the key k a SAK and console reset is done. For the key b the machine is rebooted immediately. (See, not something you want to have enabled on a production machine.) For the key o the power is turned off (when the machine is capable of that). For the key s an emergency sync is scheduled. For the key u an emergency read-only remount is scheduled. For the keys p,t,m various information is shown (namely the same information also shown for RAlt,RCtrl,RShift+ScrollLock). For the keys e,i,l all processes get a SIG_TERM or SIG_KILL, respectively; for l even the init process is killed. Digits set the log level. Anything else prints a short summary: <tt>SysRq: unRaw saK Boot Off Sync Unmount showPc showTasks showMem loglevel0-8 tErm kIll killalL</tt>. <p> Note: These are very dangerous actions! And they do not use your keymap - indeed, are meant for emergency cases where the state of your keymap, or even of the entire kernel, is uncertain. If you use a dvorak keyboard - bad luck! Most other people will be able to survive: the dangerous letters A,M,Q,W,Y,Z that are differently placed on English, French and German keyboards, are not used for actions. (But if your finger slips and you hit L instead of K - bye bye to your system.) <p> In Linux 2.3.13 the possibility to enable/disable SysRq was added. <tscreen><verb> echo 0 > /proc/sys/kernel/sysrq </verb></tscreen> will disable it (if the kernel was compiled with CONFIG_MAGIC_SYSRQ). <sect1>Problems<p> A good keyboard accurately reports multiple key presses. Especially for people using a keyboard as Braille input device, where they have to be able to press up to six keys simultaneously, this is important. Many modern keyboards fail here due to sloppy design and testing - they misreport or fail in other ways when four or more keys are pressed simultaneously, sometimes already when two non-modifier keys are pressed simultaneously. This affects Linux users a bit: the SysRq key is not a modifier key, and people report problems using Alt-SysRq-<it>X</it> for various letters or digits <it>X</it>. <p> Long ago a similar problem (`ghosting') was caused by the design of the scan matrix: when three keys were pressed a fourth was also seen. That problem was solved by the use of diodes. Today it is the interface logic that is deficient. <sect>How to get out of raw mode<p> <nidx>raw mode, exiting</nidx> If some program using K_RAW keyboard mode exits without restoring the keyboard mode to K_XLATE, then it is difficult to do anything - not even Ctrl-Alt-Del works. However, it is sometimes possible to avoid hitting the reset button. (And desirable as well: your users may get angry if you kill their Hack game by rebooting; you might also damage your file system.) Easy solutions involve logging in from another terminal or another machine and doing <tt>kbd_mode -a</tt>. The procedure below assumes that no X is running, that the display is in text mode, and that you are at your bash prompt, that you are using a US keyboard layout, and that your interrupt character is Ctrl-C. Step 1. Start X. As follows: press 2 (and don't release), press F12 (and don't release) and immediately afterwards press = . This starts X. (Explanation: if a key press produces keycode K, then the key release produces keycode K+128. Probably your shell does not like these high characters, so we avoid generating them by not releasing any key. However, we have to be quick, otherwise key repeat starts. The digit 2 produces a Ctrl-C that discards previous junk, the F12 produces an X and the = a Return.) Probably your screen will be grey now, since no <tt/.xinitrc/ was specified. However, Ctrl-Alt-Fn will work and you can go to another VT. (Ctrl-Alt-Backspace also works, but that exits X, and gets you back into the previous state, which is not what you want.) Step 2. Setup to change the keyboard mode. (For example, by <tt>sleep 5; kbd_mode -a</tt>.) Step 3. Leave X again. Alt-Fx (often Alt-F7) brings you back to X, and then Ctrl-Alt-Backspace exits X. Within 5 seconds your keyboard will be usable again. If you want to prepare for the occasion, then make <tt>\215A\301</tt> (3 symbols) an alias for <tt/kbd_mode -a/. Now just hitting = F7 = (3 symbols) will return you to sanity. <sect>The keyboard LEDs<p> <nidx>LEDs, keyboard</nidx> <nidx>keyboard!LEDs on</nidx> 1. There are per-tty keyboard flags: each VC has its own NumLock, CapsLock, ScrollLock. By default these keyboard flags are shown in the LEDs. The usual way to change them is by pressing the corresponding key. (Side remark: pressing the NumLock key when in application key mode will not change the NumLock status, but produce an escape sequence. If you want the NumLock key to always change the Numlock status, bind it to Bare_Num_Lock.) 2. Next, there are per-tty default keyboard flags, to initialize the keyboard flags when a reset occurs. Thus if you want NumLock on all the time, that is possible. The usual way to change them is by `<tt/setleds -D/ ...'. 3. There is the possibility that the leds do not reflect the keyboard flags, but something else. <p> 3A. This something else can be three bits somewhere in the kernel - which can be used if you want to monitor some hardware or software status bit(s). If you want this, edit the kernel source to call <tt/register_leds()/ somewhere. <p> 3B. This something else can also be whatever some user program wants to show in the LEDs. Thus, people who like such things can make nice patterns of lights. If you want this, use the KDSETLED ioctl. This latter use is not per-tty, but the choice between former and latter use is per-tty. Summarizing: Each tty has a flag <tt/kbd->ledmode/. If this has the value LED_SHOW_FLAGS then the keyboard flags (NumLock etc.) of that tty are shown. If this has the value LED_SHOW_MEM then three selected memory addresses are shown. If this has the value LED_SHOW_IOCTL then the leds show whatever value was last assigned to them using the KDSETLED ioctl. One may add that X uses ioctl's to set the LEDs, but fails to reset its VT when it exits, so after using X there may be one VT that is not in the default LED_SHOW_FLAGS state. This can be fixed by doing `<tt/setleds -L/' on that VT. See setleds(1). <sect>The TERM variable<p> <nidx>TERM environment variable</nidx> <nidx>environment variables!TERM</nidx> Many programs use the <tt/TERM/ variable and the database <tt>/etc/termcap</tt> or <tt>/usr/lib/terminfo/*</tt> to decide which strings to send for clear screen, move cursor, etc., and sometimes also to decide which string is sent by the users backspace key, function keys etc. This value is first set by the kernel (for the console). Usually, this variable is re-set by <tt/getty/, using <tt>/etc/ttytype</tt> or the argument specified in <tt>/etc/inittab</tt>. Sometimes, it is also set in <tt>/etc/profile</tt>. Older systems use <tt/TERM=console/ or <tt/TERM=con80x25/. Newer systems (with ncurses 1.8.6) use the more specific <tt/TERM=linux/ or <tt/TERM=linux-80x25/. However, old versions of <tt/setterm/ test for <tt/TERM=con*/ and hence fail to work with <tt/TERM=linux/. Since kernel version 1.3.2, the kernel default for the console is <tt/TERM=linux/. If you have a termcap without entry for linux, add the word linux to the entry for the console: <tscreen><verb> console|con80x25|linux:\ </verb></tscreen> and make <tt>/usr/lib/terminfo/l/linux</tt> a copy of or symbolic link to <tt>/usr/lib/terminfo/c/console</tt>. <sect1>Terminfo<p> <nidx>terminfo</nidx> The terminfo entry for the linux console from ncurses 1.8.6 misses the entry <tt>kich1=\E[2˜</tt>, needed by some programs. Edit the file and <tt/tic/ it. <sect>How to make other programs work with non-ASCII chars<p> <nidx>non-ASCII characters, using</nidx> In the bad old days this used to be quite a hassle. Every separate program had to be convinced individually to leave your bits alone. Not that all is easy now, but recently a lot of gnu utilities have learned to react to <tt/LC_CTYPE=iso_8859_1/ or <tt/LC_CTYPE=iso-8859-1/. Try this first, and if it doesn't help look at the hints below. Note that in recent versions of libc the routine setlocale() only works if you have installed the locale files (e.g. in <tt>/usr/lib/locale</tt>). First of all, the 8-th bit should survive the kernel input processing, so make sure to have <tt/stty cs8 -istrip -parenb/ set. A. For <tt/emacs/ the details strongly depend on the version. The information below is for version 19.34. Put lines <tscreen><verb> (set-input-mode nil nil 1) (standard-display-european t) (require 'iso-syntax) </verb></tscreen> into your <tt>$HOME/.emacs</tt>. The first line (to be precise: the final 1) tells <tt/emacs/ not to discard the 8-th bit from input characters. The second line tells <tt/emacs/ not to display non-ASCII characters as octal escapes. The third line specifies the syntactic properties and case conversion table for the Latin-1 character set These last two lines are superfluous if you have something like <tt/LC_CTYPE=ISO-8859-1/ in your environment. (The variable may also be <tt/LC_ALL/ or even <tt/LANG/. The value may be anything with a substring `88591' or `8859-1' or `8859_1'.) <p> This is a good start. On a terminal that cannot display non-ASCII ISO 8859-1 symbols, the command <tscreen><verb> (load-library "iso-ascii") </verb></tscreen> will cause accented characters to be displayed comme {,c}a. If your keymap does not make it easy to produce non-ASCII characters, then <tscreen><verb> (load-library "iso-transl") </verb></tscreen> will make the 2-character sequence Ctrl-X 8 a compose character, so that the 4-character sequence Ctrl-X 8 , c produces c-cedilla. Very inconvenient. <p> The command <tscreen><verb> (iso-accents-mode) </verb></tscreen> will toggle ISO-8859-1 accent mode, in which the six characters ', `, ", ˆ, ˜, / are dead keys modifying the following symbol. Special combinations: ˜c gives a c with cedilla, ˜d gives an Icelandic eth, ˜t gives an Icelandic thorn, "s gives German sharp s, /a gives a with ring, /e gives an a-e ligature, ˜< and ˜> give guillemots, ˜! gives an inverted exclamation mark, ˜? gives an inverted question mark, and '' gives an acute accent. This is the default mapping of accents. The variable <tt/iso-languages/ is a list of pairs (language name, accent mapping), and a non-default mapping can be selected using <tscreen><verb> (iso-accents-customize LANGUAGE) </verb></tscreen> Here LANGUAGE can be one of <tt/"portuguese"/, <tt/"irish"/, <tt/"french"/, <tt/"latin-2"/, <tt/"latin-1"/. Since the Linux default compose character is Ctrl-. it might be convenient to use that everywhere. Try <tscreen><verb> (load-library "iso-insert.el") (define-key global-map [?\C-.] 8859-1-map) </verb></tscreen> The latter line will not work under <tt/xterm/, if you use <tt/emacs -nw/, but in that case you can put <tscreen><verb> XTerm*VT100.Translations: #override\n\ Ctrl <KeyPress> . : string("\0308") </verb></tscreen> in your <tt/.Xresources/.) B. For <tt/less/, put <tt/LESSCHARSET=latin1/ in the environment. This is also what you need if you see <tt/\255/ or <tt/<AD>/ in <tt/man/ output: some versions of <tt/less/ will render the soft hyphen (octal 0255, hex 0xAD) this way when not given permission to output Latin-1. C. For <tt/ls/, give the option <tt/-N/. (Probably you want to make an alias.) D. For <tt/bash/ (version 1.13.*), put <tscreen><verb> set meta-flag on set convert-meta off set output-meta on </verb></tscreen> into your <tt>$HOME/.inputrc</tt>. E. For <tt/tcsh/, use <tscreen><verb> setenv LANG US_en setenv LC_CTYPE iso_8859_1 </verb></tscreen> If you have nls on your system, then the corresponding routines are used. Otherwise <tt/tcsh/ will assume iso_8859_1, regardless of the values given to LANG and LC_CTYPE. See the section NATIVE LANGUAGE SYSTEM in tcsh(1). (The Danish HOWTO says: <tt>setenv LC_CTYPE ISO-8859-1; stty pass8</tt>) F. For <tt/flex/, give the option <tt/-8/ if the parser it generates must be able to handle 8-bit input. (Of course it must.) G. For <tt/elm/, set <tt/displaycharset/ to <tt/ISO-8859-1/. (Danish HOWTO: <tt/LANG=C/ and <tt/LC_CTYPE=ISO-8859-1/) H. For programs using curses (such as <tt/lynx/) David Sibley reports: The regular curses package uses the high-order bit for reverse video mode (see flag _STANDOUT defined in <tt>/usr/include/curses.h</tt>). However, <tt/ncurses/ seems to be 8-bit clean and does display iso-latin-8859-1 correctly. I. For programs using <tt/groff/ (such as <tt/man/), make sure to use <tt/-Tlatin1/ instead of <tt/-Tascii/. Old versions of the program <tt/man/ also use <tt/col/, and the next point also applies. J. For <tt/col/, make sure 1) that it is fixed so as to do <tt>setlocale(LC_CTYPE,"");</tt> and 2) put <tt>LC_CTYPE=ISO-8859-1</tt> in the environment. K. For <tt/rlogin/, use option <tt/-8/. L. For <tt/joe/, <tt>metalab.unc.edu:/pub/Linux/apps/editors/joe-1.0.8-linux.tar.gz</tt> is said to work after editing the configuration file. Someone else said: <tt/joe/: Put the <tt/-asis/ option in <tt>/isr/lib/joerc</tt> in the first column. M. For LaTeX: <tt>\documentstyle[isolatin]{article}</tt>. For LaTeX2e: <tt>\documentclass{article}\usepackage{isolatin}</tt> where <tt>isolatin.sty</tt> is available from <htmlurl url="ftp://ftp.vlsivie.tuwien.ac.at/pub/8bit" name="ftp.vlsivie.tuwien.ac.at/pub/8bit">. A nice discussion on the topic of ISO-8859-1 and how to manage 8-bit characters is contained in the file <tt>grasp.insa-lyon.fr:/pub/faq/fr/accents</tt> (in French). Another fine discussion (in English) can be found in <htmlurl url="ftp://rtfm.mit.edu/pub/usenet-by-group/comp.answers/internationalization/iso-8859-1-charset" name="rtfm.mit.edu:pub/usenet-by-group/comp.answers/internationalization/iso-8859-1-charset">. If you need to fix a program that behaves badly with 8-bit characters, one thing to keep in mind is that if you have a signed char type then characters may be negative, and using them as an array index will fail. Several programs can be fixed by judiciously adding (unsigned char) casts. <sect>X<p> This FAQ/HOWTO is about the Linux keyboard and console, not about X, which substitutes its own handling. However, it seems useful to document some of the Linux keyboard and console related properties of X. First of all, when X is started (say using <tt/startx/ or <tt/xinit/) it opens the first unused console, unless the desired console has been indicated explicitly, as in <tt/xinit -- vt12/. Note that this will fail when there is no device file <tt>/dev/tty12</tt>, but that it will not fail when the indicated console was in use already. When X finishes, it will return to the original console. While it is running one can use Ctrl-Alt-Fn to switch to VTn. <p> The XFree86 keymap mechanism is much poorer than the Linux mechanism. For each keycode there are at most 4 symbols defined, namely for the 4 keymaps plain, shift, mod, mod+shift. What is the modifier mod? It is the one designated by the symbol <tt/Mode_switch/. For example, the command <tt/xmodmap keys.dk/, where the file <tt/keys.dk/ contains <tscreen><verb> keycode 64 = Mode_switch keycode 113 = Mode_switch keycode 38 = a A aring Aring keycode 26 = e E ae AE keycode 32 = o O oslash Ooblique </verb></tscreen> will make both Alt keys into mod keys, so that Alt+a gives å (a-ring), etc. (Note the illogical naming of oslash and Ooblique.) Such an <tt/xmodmap/ command can be placed in the <tt/.xinitrc/ shell script that is executed by default when X is started. <sect1>What precisely does XFree86-2.1 do when it initializes its keymap?<p> <nidx>keymap!initialization by XFree86</nidx> <nidx>XFree86!keymap initialization</nidx> Since version 2.1, XFree86 will initialize its keymap from the Linux keymap, as far as possible. However, Linux had 16 entries per key (one for each combination of the Shift, AltGr, Ctrl, Alt modifiers) and presently has 256 entries per key, while X has 4 entries per key (one for each combination of Shift, Mod), so some information is necessarily lost. First <tt/X/ reads the <tt/Xconfig/ file, where definitions of the LeftAlt, RightAlt, RightCtl, ScrollLock keys as Meta, ModeShift, Compose, ModeLock or ScrollLock might be found - see X386keybd(1), later XFree86kbd(1). For Mod the LeftAlt key is taken, unless RightCtl was defined as ModeShift or ModeLock, in which case RightCtl is taken, or RightAlt was so defined, in which case RightAlt is taken. This determines how the 4 XFree86 meanings of a key are selected from the 16 Linux meanings. Note that Linux today does not distinguish by default between the two Ctrl keys or between the two Shift keys. <tt/X/ does distinguish. Now the kernel keymap is read and the usually obvious corresponding X bindings are made. The bindings for the "action keys" Show_Memory, Show_State, Show_Registers, Last_Console, Console_n, Scroll_Backward, Scroll_Forward, Caps_On and Boot are ignored, as are the dead diacriticals, and the locks (except for ShiftLock), and the "ASCII-x" keys. Next, the definitions in the <tt/Xconfig/ file are used. (Thus, a definition of Compose in <tt/Xconfig/ will override its value as found in the Linux keymap.) What happens to the strings associated with the function keys? Nothing, X does not have such a concept. (But it is possible to define strings for function keys in <tt/xterm/ - note however that the window manager gets the keys first.) I don't know how to convince <tt/xterm/ that it should use the X keymap when Alt is pressed; it seems just to look at its resource <tt/eightBitInput/, and depending on whether that is true or false either set the high order bit of the character, or generate an additional Escape character (just like setmetamode(1) does for the console). <sect>Unusual keys and keyboards<p> <nidx>keyboard!unusual versions of</nidx> <nidx>keyboard!non-standard keys on</nidx> The two keys PrintScrn/SysRq and Pause/Break are special in that they have two keycodes: the former has keycode 84 when Alt is pressed simultaneously, and keycode 99 otherwise; the latter has keycode 101 when Ctrl is pressed simultaneously, and keycode 119 otherwise. (Thus, it makes no sense to bind functions to Alt keycode 99 or Ctrl keycode 119.) The Pause/Break key is also special in another way: it does not generate key-up scancodes, but generates the entire 6-scancode sequence on key-down. If you have strange keys, that do not generate any code under Linux (or generate messages like "unrecognized scancode"), and your kernel is 1.1.63 or later, then you can use setkeycodes(1) to tell the kernel about them. Once they have gotten a keycode from <tt/setkeycodes/, they can be assigned a function by <tt/loadkeys/. For example, using <tt/showkey -s/ one sees that Microsoft keyboards use the scancode sequences (in hexadecimal) e0 5b (left Windows key), e0 5c (right Windows key), e0 5d (Menu key). Microsoft Internet keyboard also uses e0 6a (Back), e0 69 (Forward), e0 68 (Stop), e0 6c (Mail), e0 65 (Search), e0 66 (Favorites), e0 32 (Web/Home), e0 6b (My Computer), e0 21 (Calculator), e0 5f (Sleep). Use <tt>dumpkeys</tt> to see what keycodes are still unused. Typically values like 89-95 and 112-118 and 120-127 are free. Now <tscreen><verb> % setkeycodes e05b 125 % setkeycodes e05c 126 % setkeycodes e05d 127 </verb></tscreen> assigns keycodes to these scancode sequences, and <tscreen><verb> % loadkeys keycode 125 = Decr_Console keycode 126 = Incr_Console keycode 127 = KeyboardSignal % </verb></tscreen> would make these Windows keys go to the previous or next virtual console, and let the Menu key create a fresh virtual console (in case you have something like <tt/spawn_console/ running). <sect1>Funkeys<p> Many modern keyboards have buttons or keys with labels like "Vol Up", "Eject" etc. that suggest actions rather than strings. Of course one can bind shell commands to them, but then they'll work only when you are at a shell prompt. Rick van Rein wrote a package funkey consisting of a kernel patch and a daemon. The kernel patch creates a new character device, and adds a new key type to indicate which keystrokes should be sent to this new character device. A daemon can now listen to the character device, somewhat like <tt>gpm</tt> listens to the mouse device, and perform the actions indicated in its config file. See <htmlurl url="http://rick.vanrein.org/linux/funkey" name="rick.vanrein.org/linux/funkey">. <sect>Examples of use of loadkeys and xmodmap<p> <nidx>loadkeys!example using</nidx> <nidx>xmodmap!example using</nidx> Switching Caps Lock and Control on the keyboard (assuming you use keymaps 0-15; check with <tt>dumpkeys | head -1</tt>) <tscreen><verb> % loadkeys keymaps 0-15 keycode 58 = Control keycode 29 = Caps_Lock % </verb></tscreen> Switching them under X only: <tscreen><verb> % xmodmap .xmodmaprc </verb></tscreen> where <tt/.xmodmaprc/ contains lines <tscreen><verb> remove Lock = Caps_Lock remove Control = Control_L keysym Control_L = Caps_Lock keysym Caps_Lock = Control_L add Lock = Caps_Lock add Control = Control_L </verb></tscreen> What is this about the key numbering? Backspace is 14 under Linux, 22 under X? Well, the numbering can best be regarded as arbitrary; the Linux number of a key can be found using showkey(1), and the X number using xev(1). Often the X number will be 8 more than the Linux number. Something else people like to change are the bindings of the function keys. Suppose that you want to make F12 produce the string "emacs ". Then <tscreen><verb> % loadkeys keycode 88 = F12 string F12 = "emacs " % </verb></tscreen> will do this. More explicitly, the procedure is like this: (i) find the keycodes of the keys to be remapped, using showkey(1). (ii) save the current keymap, make a copy and edit that: <tscreen><verb> % dumpkeys > my_keymap % cp my_keymap trial_keymap % emacs trial_keymap % loadkeys trial_keymap % </verb></tscreen> The format of the table can be guessed by looking at the output of <tt/dumpkeys/, and is documented in keymaps(5). When the new keymap functions as desired, you can put an invocation <tscreen><verb> loadkeys my_new_keymap </verb></tscreen> in <tt>/etc/rc.local</tt> or so, to execute it automatically at boot-up. Note that changing modifier keys is tricky, and a newbie can easily get into a situation only an expert can get out of. <p> The default directory for keymaps is <tt>/usr/lib/kbd/keymaps</tt>. The default extension for keymaps is <tt>.map</tt>. For example, <tt>loadkeys uk</tt> would probably load <tt>/usr/lib/kbd/keymaps/i386/qwerty/uk.map</tt>. (With kbd-0.95 and older this would be <tt>/usr/lib/kbd/keytables</tt> and <tt>/usr/lib/kbd/keytables/uk.map</tt>.) <p> (On my machine) <tt>/dev/console</tt> is a symbolic link to <tt>/dev/tty0</tt>, and the kernel regards <tt>/dev/tty0</tt> as a synonym for the current VT. XFree86 1.3 changes the owner of <tt>/dev/tty0</tt>, but does not reset this after finishing. Thus, <tt/loadkeys/ or <tt/dumpkeys/ might fail because someone else owns <tt>/dev/tty0</tt>; in such a case you might run X first. Note that you cannot change keyboard mappings when not at the console (and not superuser). <sect1>`I can use only one finger to type with'<p> <nidx>keyboard!making modifier keys toggle</nidx> "Can the Shift, Ctrl and Alt keys be made to behave as toggles?"<p> Yes, after saying <tscreen><verb> % loadkeys keymaps 0-15 keycode 29 = Control_Lock keycode 42 = Shift_Lock keycode 56 = Alt_Lock % </verb></tscreen> the left Control, Shift and Alt keys will act as toggles. The numbers involved are revealed by showkey (and usually are 29, 97, 42, 54, 56, 100 for left and right control, shift and alt, respectively), and the functions are Control_Lock, Shift_Lock, Alt_Lock, ALtGr_Lock. "What about `sticky' modifier keys?"<p> Since version 1.3.33, the kernel knows about `sticky' modifier keys. These act on the next key pressed. So, where one earlier needed the 3-symbol sequence Shift_Lock a Shift_Lock to type `A', one can now use the 2-symbol sequence SShift_Lock a. You can say <tscreen><verb> % loadkeys keymaps 0-15 keycode 54 = SShift keycode 97 = SCtrl keycode 100 = SAlt % </verb></tscreen> to make the right Shift, Ctrl, Alt sticky versions of the left ones. This will allow you to type Ctrl-Alt-Del in three keystrokes with one hand. The keymaps line in these examples should cover all keymaps you have in use. You find what keymaps you have in use by <tscreen><verb> % dumpkeys | head -1 </verb></tscreen> <sect1>Sticky keys under <tt/X/<p> The following text was contributed by Piotr Mitros. XFree86 supports an accessibility option which allows disabled users to type single-handed. With sticky keys enabled, the user can hit a modifier key (ctrl, alt, shift) followed by another key, rather than having to hold the modifier key while hitting the letter. To enable sticky keys, first make sure the xkb extension is enabled (this is done during initial <tt/X/ server configuration and is usually enabled by default). Next, run the <tt/X/ server with the <tt/+accessx/ option. If you use <tt/startx/, either run <tt/startx -- +accessx/ or add <tt/+accessx/ to the serverargs line in the <tt/startx/ script. If you use <tt/xdm/, add <tt/+accessx/ to the appropriate server line in <tt>/etc/X11/xdm/Xservers</tt>. It is also possible to enable <tt/X/ accessibility with some end-user utilities with a running <tt/X/ server. Once <tt/X/ accessibility is enabled, press the shift key five times in a row to enable sticky keys. To disable sticky keys, either press the shift key five times again, or press a key while holding a modifier key. XFree86 also supports Slow Keys, Repeat Keys, Bounce Keys and an audible bell. <tt/xkbcomp/ can be used to generate a <tt/.xkm/ file to enable these. The appropriate <tt/xkbcomp/ commands are listed in <tt>/usr/X11R6/lib/X11/xkb/compat/accessx</tt>. Unfortunately, the exact process is still undocumented. <sect>Changing the video mode<p> <nidx>console!changing video modes</nidx> <nidx>video modes, changing</nidx> <nidx>resolution, changing</nidx> As far as I know there are 6 ways to change resolution: 1. At compile time: change the line <tscreen><verb> SVGA_MODE= -DSVGA_MODE=NORMAL_VGA </verb></tscreen> in <tt>/usr/src/linux/Makefile</tt>. 1A. After compilation: use <tt>rdev -v</tt> - a terrible hack, but it exists. 2. At boot time: put <tt>vga=ask</tt> in the lilo config file, and lilo will ask you what video mode you want. Once you know, put <tt/vga=/mypreference. 3. At run time: A. Use the <tt/resizecons/ command. (This is a very primitive wrapper around the VT_RESIZE ioctl.) B. Use the <tt/SVGATextMode/ command. (This is a less primitive wrapper around the VT_RESIZE ioctl.) 4. Not "on the console": Under <tt/dosemu/, or with svgalib etc. you can change the hardware video mode without the console driver being aware of it. Sometimes this is useful in getting <tt/resizecons/ or <tt/SVGATextMode/ set up: use <tt/dosemu/ and some DOS program to get into the desired videomode, dump (say from another VT) the contents of all video hardware registers, and use that in the initialization that <tt/resizecons/ and <tt/SVGATextMode/ require. In some cases where the video mode has gotten into some unusable state, starting <tt/dosemu/, relying on the BIOS to set up the video mode, and then killing <tt/dosemu/ (with <tt/kill -9/), is the easiest way to get into shape again. <sect1>Instructions for the use of resizecons<p> <nidx>resizecons program</nidx> Get svgalib and compile the program <tt/restoretextmode/. Boot up your machine in all possible video modes (using <tt/vga=ask/ in the lilo config file), and write the video hardware register contents to files CxR (C=cols, R=rows), e.g., 80x25, 132x44, etc. Put these files in <tt>/usr/lib/kbd/videomodes</tt>. Now <tt>resizecons 132x44</tt> will change videomode for you (and send SIGWINCH to all processes that need to know about this, and load another font if necessary). At present, <tt/resizecons/ only succeeds when there is memory enough for both the old and the new consoles at the same time. <sect>Changing the keyboard repeat rate<p> <nidx>keyboard!repeat rate, setting</nidx> At startup, the Linux kernel sets the repeat rate to its maximal value. For most keyboards this is reasonable, but for some it means that you can hardly touch a key without getting three copies of the corresponding symbol. Use the program kbdrate(8) to change the repeat rate, or, if that doesn't help, edit or remove the section <code> ! set the keyboard repeat rate to the max mov ax,#0x0305 xor bx,bx ! clear bx int 0x16 </code> of <tt>/usr/src/linux/[arch/i386/]boot/setup.S</tt>. Scott Johnston (<tt/sj@zule.com/) reports: `To program the repeat rate of a Gateway AnyKey keyboard all one has to do is press the "Repeat Rate" key, then a function key F1-F8, then "Repeat Rate" again. F1 is the slowest possible repeat rate, and F8 is really fast. If you somehow manage to mess up your AnyKey keyboard doing this, simply press Ctrl-Alt-SuspndMacro to reset your keyboard to factory default settings.' <sect>Scrolling<p> <nidx>console!scrolling</nidx> <nidx>scrolling, console</nidx> There are two ways to get a screen to scroll. The first, called `hard scrolling', is to leave the text in video memory as it is, but change the viewing origin. This is very fast. The second, called `soft scrolling', involves moving all screen text up or down. This is much slower. The kernel console driver will write text starting at the top of the video memory, continuing to the bottom, then copy the bottom part to the top again, and continue, all the time using hard scrolling to show the right part on the screen. You can scroll back until the top op the video memory by using Shift-PageUp (the grey PageUp) and scroll down again using Shift-PageDown (the grey PageDown), assuming a default keymap. The amount of scrollback is thus limited to the amount of video memory you happen to have and you cannot increase this amount. If you need more scrollback, use some program that buffers the text, like <tt/less/ or <tt/screen/ - by using a buffer on disk you can go back to what you did last week. (One can set the amount of scrollback for <tt/xterm/ by adding a line like <tt/XTerm*saveLines: 2500/ in <tt/.Xresources/.) Upon changing virtual consoles, the screen content of the old VT is copied to kernel memory, and the screen content of the new VT is copied from kernel memory to video memory. Only the visible screen is copied, not all of video memory, so switching consoles means losing the scrollback information. Sometimes, hard scrolling is undesirable, for example when the hardware does not have the possibility to change viewing origin. The first example was a Braille machine that would render the top of video memory in Braille. There is a kernel boot-time option <tt/no-scroll/ to tell the console driver not to use hard scrolling. See bootparam(7). <sect>Screensaving<p> <nidx>screensaving!controlling</nidx> <nidx>screen blanking</nidx> <tt>setterm -blank</tt> <it/nn/ will tell the console driver to blank the screen after <it/nn/ minutes of inactivity. (With <it/nn/ = 0, screensaving is turned off. In some old kernels this first took effect after the next keyboard interrupt.) The <tt/s/ option of xset(1) will set the X screensaving parameters: <tt>xset s off</tt> turns off the screensaver, <tt>xset s 10</tt> blanks the screen after 10 minutes. The video hardware powersaving modes can be enabled/disabled using the <tt/setvesablank/ program given in the starting comment of <tt>/usr/src/linux/drivers/char/vesa_blank.c</tt>. <sect>Screen dumps<p> <nidx>console!screenshots, obtaining</nidx> <nidx>screenshots!obtaining from console</nidx> <tt>setterm -dump</tt> <it/N/ will dump the contents of the screen of <tt>/dev/tty</tt><it/N/ to a file <tt/screen.dump/ in the current directory. See setterm(1). The current contents of the screen of <tt>/dev/tty</tt><it/N/ can be accessed using the device <tt>/dev/vcs</tt><it/N/ (where `vcs' stands for `virtual console screen'). For example, you could have a clock program that displays the current time in the upper right hand corner of the console screen (see the program <tt/vcstime/ in <tt/kbd-1.04.tar.gz/). Just dumping the contents goes with <tt>cat /dev/vcs</tt><it/N/. These device files <tt>/dev/vcs</tt><it/N/ do not contain newlines, and do not contain attributes, like colors. From a program it is usually better to use <tt>/dev/vcsa</tt><it/N/ (`virtual console screen with attributes') instead - it starts with a header giving the number of rows and columns and the location of the cursor. See vcs(4). <sect>Some properties of the VT100 - application key mode<p> <nidx>keyboard!VT100 application key mode</nidx> <nidx>VT100 application key mode</nidx> : Sometimes my cursor keys or keypad keys produce strange codes? When the terminal is in application cursor key mode the cursor keys produce Esc O x and otherwise Esc [ x where x is one of A,B,C,D. Certain programs put the terminal in application cursor key mode; if you kill them with <tt/kill -9/, or if they crash, then the mode will not be reset. <verb> % echo -e '\033c' </verb> resets all properties of the current VC. Just changing the cursor application key mode is done by <verb> % echo -e '\033[?1h' </verb> (set) and <verb> % echo -e '\033[?1l' </verb> (clear). When the terminal is in application keypad key mode the keypad keys produce Esc O y and otherwise Esc [ z ˜ for certain y and z. Setting application keypad key mode is done by <verb> % echo -e '\033=' </verb> and <verb> % echo -e '\033>' </verb> clears it again. <sect>Hardware incompatibility<p> <nidx>keyboard!hardware incompatibilities</nidx> <nidx>incompatibility!keyboard-related</nidx> Several people have noticed that they lose typed characters when a floppy disk is active. It seems that this might be a problem with Uni-486WB motherboards. Tjalling Tjalkens (<tt/tjalling@ei.ele.tue.nl/) reports very similar problems with "a no-brand GMB-486 UNP Vesa motherboard with AMD 486DX2-66 CPU" - during floppy activity some keystrokes are lost, during floppy tape streamer (Conner C 250 MQ) activity many keystrokes are lost. Some people experience sporadic lockups - sometimes associated to hard disk activity or other I/O. Ulf Tietz (<tt/ulf@rio70.bln.sni.de/) wrote: `I have had the same problems, when I had my motherboard tuned too fast. So I reset all the timings ( CLK, wait statements etc ) to more conventional values, and the problems are gone.' Bill Hogan (<tt/bhogan@crl.com/) wrote: `If you have an AMI BIOS, you might try setting the Gate A20 emulation parameter to "chipset" (if you have that option). Whenever I have had that parameter set to any of the other options on my machine ("fast", "both", "disabled") I have had frequent keyboard lockups.' There may be a relation between keyboard problems and the video card in use. Shawn K. Quinn (<tt/skquinn@wt.net/) wrote: `I have a Zeos Pantera Pentium-90 that originally came with a Diamond Stealth 64 S3-based video card. Under X I frequently got q's inserted into my text (how annoying) especially if I typed very fast (during Netrek for instance, even more annoying because guess what that does :-( ). Switching to a Creative Labs Graphics Blaster MA202 solved the problem. I'm assuming the Stealth 64 did something funny with the timings.' <sect>Copyright<p> Copyright (c) 1993-2001 by Andries Brouwer. This document may be distributed under the terms set forth in the LDP license at <htmlurl url="http://metalab.unc.edu/LDP/COPYRIGHT.html" name="http://metalab.unc.edu/LDP/COPYRIGHT.html"> or <htmlurl url="ftp://www.win.tue.nl/pub/linux/LDP/COPYRIGHT.txt" name="ftp://www.win.tue.nl/pub/linux/LDP/COPYRIGHT.txt">. Additions and corrections are welcome. Andries Brouwer - <tt/aeb@cwi.nl/ </article>