NCDware provides a mechanism for experienced system administrators to configure terminals to work with keyboards that are not explicitly supported in the NCD X server, such as some international keyboards.

This appendix describes how to use a keyboard description file downloaded from the host during terminal booting to support such keyboard usage. Keyboard description files may be available from the NCD FTP site or from other vendors.

To use an unsupported keyboard, you need to:

1. Find or prepare a keyboard description file describing the behavior of the keyboard. See the content and format descriptions later in this appendix. Make sure that the file is world-readable.
   

2. Make sure that the directory containing the keyboard description file is accessible through the file-service-table parameter (Setup -> Change Setup Parameters -> File Service -> File Service Table). For information about this parameter, see Chapter 5, Configuring Network Services.
   

3. Configure the terminal to read the keyboard description file during booting. In a remote configuration file, set the xserver-keyboard-description-file parameter to the name of the keyboard definition file (Setup -> Change Setup Parameters -> Input Devices -> Keyboard Description File).
   

4. Plug in the keyboard.
   

5. Reboot the terminal. The first time you boot the terminal after using a new keyboard description file, check the Messages hide box in the Console to make sure that the file was read without error.
   

This section describes how to manually create or edit a keyboard description file.

Note:

You can also create a keyboard description file for the keyboard attached to the terminal from Change Setup Parameters. In the Input hide box, click on Write Keyboard Description File. In the dialog box that appears, type the pathname of the file and click on OK.

A keyboard description file is an ASCII file containing statements defining keyboard behavior. The statements describe the following keyboard characteristics:

Scancode table	Used by the keyboard driver to map hardware scancodes of range [0..255] into X keycodes of range [8..254]. Also used to make one keyboard imitate another.
Keycode table	Used by applications to convert X keycodes into keysyms. Also used by the X server when internal dead-key processing is enabled. Keycodes are the codes assigned to the physical keys. Keysyms are the actions taken when keys are pressed. Dead-keys are keys pressed before other key presses (such as an accent and a vowel) to produce an accented vowel letter, as required in many European languages.
Dead-key sequences	Sequences of keys intercepted by the keyboard driver and replaced by another key.
Modifiers table	Keys that are treated as modifiers, such as Shift, Lock, Control, Mod1-5. Typical values are:
	Shift	Shift_L	Shift_R
	Lock	Caps_Lock	Control_R
	Control	Control_L
	The following values vary depending on the keyboard:
	Mod1	Alt_L	Alt_R	Meta_L	Meta_R
	Mod4	Num_Lock
	Mod5	Mode_switch
Clicking list	Keys that click through the base speaker when pressed.
Locking list	Keys that lock when pressed, requiring a second press to release, usually used with modifier keys. By default, all keysyms containing the name "lock" are locking keys.
Latching list	Keys that are treated as locking until the next key is released, usually used with modifier keys. By default, the Mode_switch keysym latches.
Repeating list	Keys that autorepeat.
LED actions table	Maps LED number to the state that causes that LED to light.

The format of a keyboard definition file is similar to an xmodmap file:

• Each line consists of a keyword and values.
  

• Blank lines are ignored. Use an exclamation point anywhere on a line to cause the remainder of the line to be ignored.
  

• Use a backslash (\) at the end of the line to continue a statement past the end of a line. The backslash, following carriage return, newline, and any leading white space are replaced with a single space.
  

Table 17-8 summarizes the statements permitted in a keyboard definition file. A statement consists of one or more keywords and values. The values permitted in the statements are defined in Table 17-9.

Table 17-8 Keyboard Description File Statements

Table 17-9 Permitted Values in Keyboard Description Files

Specifying Dead-Key Processing

The following keyboard description file statement specifies a sequence of keys to press to generate another key when local dead-key processing is enabled:

deadkey KEYSYM LISTofKEYSYM   =   KEYSYM

 

The range of LISTofKEYSYM is 1, 2. The resulting keysym must have been defined before this command so that the resulting table can be correctly populated.

In this mode, the keyboard driver looks at each key press as it is entered, intercepting keysyms for sequences of keys that match those specified in the dead-key statement. The first keysym on the left of the equals sign (=) is usually either the keysym Multi_key (for Digital-style triple-key compose sequences) or one of the dead-accent keysyms listed in Table 17-10.

Table 17-10 Dead-Key Accent Keysyms

The keysyms for accented vowels produced using dead-keys differ from those used when the accent is a standalone character (degree, asciicircum, cedilla, acute, grave, asciitilde, and dieresis).

When you type a dead keysym, the keyboard driver delays processing of the keyboard events until it either completes a dead-key sequence or encounters a non-modifier keysym that does not match a sequence containing the keys typed so far. If no match is found, the bell rings and the delayed keyboard events are processed separately. Otherwise, if a full sequence is recognized, the keyboard driver replaces the recognized sequence with events that generate the keysym specified on the right (except when the keysym isn't on the keyboard).

The Shift, Lock, and Mode_switch bits in the modifier mask of the replacement event are synthesized as necessary to obtain the desired keysym; all other bits in the modifier mask are the same as in the final event in the recognized sequence.

When conflicts arise over whether the keyboard driver should complete one sequence or continue to process for a longer superset, the driver completes the shorter set.