Chapter 2: X Windows Configuration Details
Table of Contents
This chapter discusses several details concerning the configuration of X
hosts, colormaps, mouse, and keyboard.
The /etc/X0.hosts file is an ASCII text file containing the hostnames
of each remote host permitted to access your local server.
- If you are running as a stand-alone system, you must have your system's
name in this file.
- If you are part of a network, the other system names must be included.
The syntax is as follows:

host

host

host
For example, if you are hpaaaaa, and regularly ran clients on
hpccccc, and hpddddd, you would want the following lines.
hpaaaaa
hpccccc
hpddddd
Note that aliases work as well as hostnames, provided they are valid, that is,
commonly known across the network.
The default screen configuration file X0screens uses the default X11
remote host file X0.hosts.
Each custom X*screens file is associated with a special
X*.hosts file. The number represented by the "*" causes the
correct screen and host files to be used together. For example,
X3screens takes an X3.hosts file. Both are referenced by
the server when it is started with a /usr/bin/X11/X :3 command.
If you use a special X*screens file, you need to set your
DISPLAY variable appropriately. For the previous example, it would
be set to hostname:3.0.
Note: The number in an Xnscreens file does not
necessarily refer to a physical screen number; any meaning implied by the
number is for the user to define. There are no semantics applied to the
number except that the Xnscreens files are used when
X is started on display
name
:n.0. For example, an
X3screens file does not necessarily imply device file
/dev/crt3; an X3screens file can use whatever device file
the user specifies. The same applies to the
X*devices, X*.hosts, X*.pointerkeys, etc., files as
well.
This file need not be present if your system is configured to query a
nameserver.
The /etc/hosts file is an ASCII text file containing a list of all
the host names and internet addresses known to your system, including your own
system.
If your system is not connected to a network, use the loopback address
(127.0.0.1) and the hostname unknown:
127.0.0.1 unknown
For a local system to access a remote host:
- The address and hostname of the remote host must be listed in the
local system's /etc/hosts file.
- The user must have a valid login (username and password) and home
directory on the remote host.
Input devices are connected to Hewlett-Packard computers through several
different hardware interfaces. Among the interfaces supported are the
Hewlett-Packard Human Interface Link (HP-HIL) and the industry standard
RS-232C (serial) and DIN interfaces. Some Hewlett-Packard computers do not
support all of these interfaces.
The X server can access input devices through any of the above interfaces.
Devices that use the HP-HIL interface and devices that use the DIN interface
and are compatible with the HP DIN keyboard and mouse can be used by simply
plugging them into the computer. Devices that use the RS-232C interface
require the installation of input device driver software before they can be
used.
If no explicit input device configuration is done, the X server chooses the X
keyboard device and X pointer device from the input devices that are connected
to the computer (in most cases, the keyboard and a mouse). On computers that
support both HP-HIL and DIN interfaces, the DIN input devices are used if both
types of devices are connected.
HP-HIL input devices can plug into other HP-HIL devices, with up to seven
input devices connected together. If there are no DIN input devices
connected, and there are multile HP-HIL input devices, the following algorithm
is used to choose an X keyboard and pointer device.
- If no explicit specification is made through the X*devices file,
the last mouse (the one farthest from the computer on the HP-HIL line) is
used as the X pointer and the last keyboard is used as the X keyboard.
- If no mouse is available, the last pointing device (such as a dial box,
graphics tablet, or trackball) is used as the X pointer. If no keyboard
is available, the last key device (such as a buttonbox or barcode reader)
is used as the X keyboard.
- If either the pointer or keyboard are unavailable, the X server won't run
unless explicitly configured to run with no input devices.
The X server reads an input device file, X0devices in
/etc/X11, to find out what input devices it should open and attach to
the display.
Note: A sample X0devices file is loaded into
/etc/X11 unless one already exists. In that case, it is loaded into
/usr/newconfig/etc/X11.
The default X0devices file contains lines of text, but does not
specify any input configuration. Rather, it assumes the default input
configuration of one keyboard and one pointer.
If this is your configuration, you may not want to change the contents of the
file for three reasons:
- Clients can request and receive the services of an input device
regardless of whether the device is specified in a device configuration
file. Thus, you need not change the X0devices file, or create a
custom file, even though you have a custom input configuration.
- Even if you have other screen configurations, you can rely on the
default input device configuration without having to create an
X*devices file to match every X*screens file. For
example, if you had a custom X*screens file, you would not
necessarily need an X*devices file.
A custom X*devices file is required only when you want to tell the X
server about a custom input device configuration.
The X server can be explicitly configured to use a specific input device as
the X pointer or X keyboard, or merge the data from an input device with that
from the X pointer or keyboard. This configuration is done by adding
information to the X*devices file. There is one syntax to use for
HP-HIL devices, and another syntax for devices that require a device driver to
be loaded by the X server (such as RS-232 devices).
HP-HIL devices can be specified in either of two ways:
- Device type and position.
- Device file name.
Some RS-232C input devices can be used with the X server. A device driver
must exist for the desired serial input device, and it must reside in the
/usr/lib/X11/extensions directory. Input device drivers are usually
supplied by the input device vendor along with the input device. Sample input
device drivers and documentation describing how to write an input device
driver may be found in the /usr/contrib/X11drivers/input
directory.
To use an RS-232 input device, you must modify the X*devices file to
inform the X server which input device driver is to be loaded, the serial port
to which it is connected, and how it is to be used. This is done by adding an
entry to the X*devices file of the following form:
Begin_Device_Description
Name
device_driver_name
Path
device_file_path
Use
device_use
End_Device_Description
where:

device_driver_name
- Specifies the name of the input device driver shared library.

device_file_path
- Specifies the name of the device file for the serial port being used.

device_use
- Specifies the desired use of the input device, such as
"keyboard", "pointer", "other", or
"extension".
The following example specifies a Spatial System Spaceball
connected to the serial port associated with
device file /dev/tty00 as the X pointer:
Begin_Device_Description
Name spaceball.sl
Path /dev/tty00
Use pointer
End_Device_Description
More examples of input device specifications for RS-232 input devices are in
the /usr/newconfig/etc/X11/X0devices file.
The device can be specified using its device type and position by adding an
entry to the X*devices file with the following form:
relative_position
device_type
use
#
comments
where:

relative_position
- Specifies the position of the device on the HP-HIL relative to the other
devices on the HP-HIL, for example, "first", "second",
and so on.

device_type
- Specifies the type of input device, such as "keyboard",
"mouse", or "tablet".

use
- Is "keyboard", "mouse", or "other".
#
comments
- Describes device. Comments are optional, but if present, must start with
a "#".
Separate the parts of your entry with tabs or spaces.
The position of an input device on the HP-HIL is relative to other devices of
the same type. For example if you have two keyboards, a graphics tablet, and
a mouse connected, they are referred to as "first keyboard",
"second keyboard", "first tablet", and "first
mouse".
This syntax is useful for computers on which a single X server is running, and
on which no other programs directly access input devices. With this syntax,
if you add a new input device to the HP-HIL, you don't have to edit the
X*devices file unless the device is of the same type as one already
named in the file and you add the device ahead of the existing device.
This syntax should not be used if more than one X server will be run
on the same computer, or if non-X programs will be directly accessing
input devices. The X server interprets "first" to mean "first accessible",
so you may not always get the first on the HP-HIL, just the first one
not already in use.
X*devices files use the following special names for positions,
devices, and uses:
Values for X*devices Files
Positions |
Device Type (Device Class) |
Uses |
first |
keyboard (keyboard) |
keyboard |
second |
mouse (pointer) |
pointer |
third |
tablet (pointer) |
other |
fourth |
buttonbox (keyboard) |
 |
fifth |
barcode (keyboard)1 |
 |
sixth |
one_knob (pointer) |
 |
seventh |
nine_knob (pointer)2 |
 |
 |
quadrature (pointer) |
 |
 |
touchscreen (pointer) |
 |
 |
trackball (pointer)3 |
 |
 |
null |
 |
- Note also that the HP barcode reader has two modes: keyboard and ASCII.
The modes are set via switches on the reader. If you set the barcode
reader to ASCII transmission mode, it appears to the server as a barcode
reader and the device name is therefore barcode. However, if you
set the barcode reader to emulate a keyboard, the barcode reader appears
as a keyboard and the device name should therefore be keyboard.
What distinguishes a barcode reader set to keyboard mode from a real
keyboard is the relative position or the device file name, depending on
which syntax you use.
- The nine-knob box appears to the X server as three separate input
devices. Each row of knobs is a separate device, and the first device
is the bottom row.
- Similar to the barcode reader, the trackball appears to the server, not
as a trackball, but as a mouse. Therefore, to specify a trackball, use
the mouse device name. Again, what specifies the trackball
instead of the real mouse is the relative position or the device filename,
depending on which syntax you use.
You can create a system on which the X server runs, but which does not have
any input devices. In this case, clients could be run from a remote terminal,
or from a remote host, and their output directed to the X server. To create a
system with no input, include the following lines in the X0devices
file:
first null keyboard
first null pointer
If you had a more complicated configuration, such as two graphics tablets, two
keyboards, and a barcode reader, your X*devices file could look like
this:
- first tablet pointer The pointer
- second tablet other Merged with the pointer
- first keyboard other Merged with the keyboard
- second keyboard keyboard The keyboard
- first barcode other Merged with the keyboard
In this example, the first tablet acts as the pointer, the second keyboard
acts as the keyboard, input from the second tablet is treated as if it came
from the X pointer, and input from the first keyboard and the barcode reader
is treated as if it came from the X keyboard.
Note that the barcode reader is in ASCII mode in this example. If the barcode
reader were in keyboard mode, the last line of the example would read as
follows:
third keyboard other
More examples can be found in the X0devices file in
/usr/newconfig/etc/X11.
The device can be specified using the name of the device to which it is
attached. This can be done by adding an entry to the X*devices file
with the form:
/
path
/device_file
use
#
comments
where:

path
/
device_file
- Specifies the name of the device file associated with the input device.

use
- is "keyboard", "pointer", or "other".
#
comments
- Describes the device. Comments are optional, but if present, must be
preceded by a "#".
This syntax should be used if more than one X server will be running on the
computer, or if non-X programs will be accessing the input devices. It refers
to a specific position on the HP-HIL.
The X*devices file can be used to redefine the path searched for
HP-HIL devices. By default, the path searched is /dev/hil. The
device files are named by appending the numbers "1" through "7" to the
path.
The path is redefined by adding an entry to the X*devices file with
the following form:
path
hil_path
#
comment
where:

path
- Specifies the path to be searched for the HP-HIL input devices.
#
comments
- Describes the path. Comments are optional, but if present, must be
preceded by a "#".
The X server appends the numbers "1" through "7" to the specified path. For
example, specifying:
/tmp/fred hil_path
results in the device names /tmp/fred1, /tmp/fred2, and so
on.
After stopping all application programs, stop the window system by holding
down the
and
keys, and then pressing the
key. This stops the display
server, and with it the window system. (If you have a PC-style keyboard,
press
instead.)
The sequence of keys that stops the display server can be customized in the
X*pointerkeys file. Refer to the X0pointerkeys file in
/etc/X11.
The xinitcolormap client initializes the X colormap. Specific X
colormap entries (pixel values) are made to correspond to specified colors.
An initialized colormap is required by applications that assume a predefined
colormap (for example, many applications that use Starbase graphics).
xinitcolormap has the following syntax:
xinitcolormap [
options
]
where the
options
are:
- -f
colormapfile
- Specifies a file containing a colormap.
- -display
display
- Specifies the server to connect to.
- -c
count
- Only the first count colors from the colormap file will be used if
this parameter is specified.
- -k or -kill
- Deallocate any colormap entries that were allocated by a previous run of
xinitcolormap.
xinitcolormap choses a colormap file in the order shown below. Once
one is found, then the other sources aren't searched.
- The command line option [-f
colormapfile
].
- .Colormap default value.
- The xcolormap file in /usr/lib/X11.
- If no colormap file is found, this default colormap specification is
assumed
black (colormap entry 0),
white, red yellow, green, cyan, blue, magenta (colormap entry 7).
xinitcolormap should be the first client program run at the start of
a session in order to assure that colormap entries have the color associations
specified in the colormap file. Sometimes you may encounter this X toolkit
warning:
X Toolkit Warning: cannot allocate colormap entry for 94c4d0
where "94c4d0" is a color specified in the application running. If this
occurs, it means that you have probably reached the limit of colors for
your graphics card/display combination. Executing xinitcolormap may
solve the problem.
For more information about xinitcolormap, refer to its reference page.
This section describes the following customizations:
- Changing mouse button actions.
- The xmodmap client.
- Going mouseless.
- Customizing keyboard input.
Related information:
- Chapter 7 contains mwm mouse and keyboard bindings.
Normally, the mouse pointer buttons are mapped as follows:
Default Mouse Button Mapping
Button Number |
Button on a 2-button mouse |
Button on a 3-button Mouse |
Button 1 |
Left button |
Left button |
Button 2 |
Both buttons simultaneously |
Middle button |
Button 3 |
Right button |
Right button |
Button 4 |
 |
Left and middle buttons simultaneously |
Button 5 |
 |
Middle and right buttons simultaneously |
However, you can change these mappings. To generate buttons 4 and 5 on a
three-button mouse, you must enable button chording as described later in this
chapter.
Alternative Mouse Button Mappings
To press: |
Left-Handed Mapping |
OSF/Motif Mapping |
2-button mouse |
3-button mouse |
2-button mouse |
3-button mouse |
Button 1 |
Right button |
Right button |
Left button |
Left button |
Button 2 |
Both buttons simultaneously |
Middle button |
Right button |
Middle button |
Button 3 |
Left button |
Left button |
Both buttons simultaneously |
Right button |
Button 4 |
 |
Middle and right buttons simultaneously |
 |
Left and middle buttons simultaneously |
Button 5 |
 |
Middle and left buttons simultaneously |
 |
Right and middle buttons simultaneously |
The xmodmap utility can be used to change mouse button mappings. The
syntax for changing mouse button mappings with xmodmap is:
xmodmap
{-e "pointer =
{default | number [number...] }" |
-pp}
- -e
- Specifies a remapping expression. Valid expressions are covered in
"Customizing Keyboard Input".
- default
- Set mouse keys back to default bindings.
- number
- Specifies a list of button numbers to map the mouse keys to. The order of
the numbers refers to the original button mapping.
- pp
- Print the current pointer mapping.
For example, to reverse the positions of buttons 1 and 3 for left-handed
mapping:
xmodmap -e "pointer = 3 2 1" |
(2-button mouse) |
xmodmap -e "pointer = 3 2 1 5 4" |
(3-button mouse) |
To establish OSF/Motif-standard button mapping:
xmodmap -e "pointer = 1 3 2" |
2-button mouse |
xmodmap -e "pointer = 1 3 2 4 5" |
3-button mouse |
Your work situation may lack sufficient desk space to adequately use a mouse
pointer. You may, therefore, want to "go mouseless" by naming the keyboard
(or some other input device) as the pointer.
To go mouseless, you need to have the proper configuration specified in the
X*devices file and to have a special configuration file named
X*pointerkeys. The default X*pointerkeys file is
X0pointerkeys in /usr/lib/X11.
The X*pointerkeys file lets you specify:
- The keys that move the pointer.
- The keys that act as pointer buttons.
- The increments for movement of the pointer.
- The key sequence that resets X11.
- The pixel threshold that must be exceeded before the server switches
screens.
- That button chording is enabled or disabled.
- That button latching is enabled or disabled.
- Tablet subsetting.
- Screen switching behavior for multi-screen configurations.
If you modify a X*pointerkeys file, it does not take effect until you
restart the X server.
If you have only one keyboard and no pointer device, and you want the keyboard
to serve as both keyboard and pointer, you don't have to change the default
configuration of X0devices. The default input device configuration
automatically assigns the pointer to the keyboard if a pointer can't be opened
by the server.
If you have two or more input devices, you may need to explicitly specify
which device should be the keyboard and which the pointer.
By default, when you configure your keyboard as the pointer, the X server
chooses certain number pad keys and assigns them mouse operations. Some
number pad keys are assigned to pointer movement; other number pad keys are
assigned to button operations.
If you don't need to change the pointer keys from their default
specifications, you don't need to do anything else to use your keyboard as
both keyboard and pointer. However, if you need to change the default pointer
keys, you must edit the X0pointerkeys file or create a new
X*pointerkeys file. The X*pointerkeys file is the file that
specifies which keys are used to move the pointer when you use the keyboard as
the pointer.
The default key assignments are listed in the tables in the following section
on customizing the X*pointerkeys file.
You need to modify the existing X0pointerkeys file only if one or
more of the following statements are true:
- You want to use the keyboard for a pointer.
- You want to change the pointer keys from their default configuration.
- You use the X0screens file to configure your display.
You need to create a custom X*pointerkeys file only if the following
statements are true:
- You want to use the keyboard for a pointer.
- You want to change the pointer keys from their default configuration.
- You use a configuration file other than the X0screens file to
configure your display.
You assign a keyboard key to a mouse function (pointer movement or button
operation) by inserting a line in the X*pointerkeys file. Lines in
the X*pointerkeys file have the syntax:
function
keyname
[#
comment
]
You can assign any mouse function, either a pointer movement or a button
operation, to any keyboard key. However, make sure that the key you are
assigning doesn't already serve a vital function.
You can assign keyboard keys to pointer directions by specifying options in an
X*pointerkeys file. The following table lists the pointer movement
options, the X*pointerkeys functions that control them, and their
default values:
Pointer Movement Functions
Movement Option |
Function |
Default Key |
Move the pointer to the left. |
pointer_left_key |
keypad_1 |
Move the pointer to the right. |
pointer_right_key |
keypad_3 |
Move the pointer up. |
pointer_up_key |
keypad_5 |
Move the pointer down. |
pointer_down_key |
keypad_2 |
Add a modifier key to the pointer direction keys. |
pointer_key_mod1 |
(no default) |
Add a second modifier key to the pointer direction keys. |
pointer_key_mod2 |
(no default) |
Add a third modifier key to the pointer direction keys. |
pointer_key_mod3 |
(no default) |
Note that the pointer direction keys are the keypad number keys on the
right side of the keyboard, not the keyboard number keys above the text
character keys.
You can assign keyboard keys to pointer distances by specifying options in a
X0pointerkeys file. The following table lists the options that
determine the distance of pointer movements, the X*pointerkeys
functions that control them, and their default value:
Pointer Distance Functions
Movement |
Function |
Default |
Move the pointer a number of pixels |
pointer_move |
10 pixels |
Move the pointer using a modifier key |
pointer_mod1_amt |
40 pixels |
Move the pointer using a modifier key |
pointer_mod2_amt |
1 pixel |
Move the pointer using a modifier key |
pointer_mod3_amt |
5 pixels |
Add a modifier to the distance keys |
pointer_amt_mod1 |
no default |
Add a modifier to the distance keys |
pointer_amt_mod2 |
no default |
Add a modifier to the distance keys |
pointer_amt_mod3 |
no default |
You can assign keyboard keys to mouse button operations by specifying options
in a X*pointerkeys file. The following table lists the button
operations, the X*pointerkeys functions that control them, and their
default values:
Button Operation Functions
Button Operation |
Function |
Default Key |
Perform button 1 operations |
pointer_button1_key |
keypad_* |
Perform button 2 operations |
pointer_button2_key |
keypad_/ |
Perform button 3 operations |
pointer_button3_key |
keypad_+ |
Perform button 4 operations |
pointer_button4_key |
keypad_- |
Perform button 5 operations |
pointer_button5_key |
keypad_7 |
You can change the mapping of buttons on the pointer by using options in the
X*pointerkeys file. The following table lists the
X*pointerkeys functions that control button mapping and their default
values. Like xmodmap and xset, these functions affect only
the X pointer, not any extension input devices.
Button Mapping Functions
Button Mapping |
Function |
Default Key |
Set button 1 value |
button_1_value |
1 |
Set button 2 value |
button_2_value |
2 |
Set button 3 value |
button_3_value |
3 |
Set button 4 value |
button_4_value |
4 |
Set button 5 value |
button_5_value |
5 |
You can change the key sequence that exits the X Window System. Also, if you
use both image and overlay planes, you can change the distance you must move
the pointer before you switch planes. The following table lists these
options, the X*pointerkeys functions that control them, and their
default values:
Reset and Threshold Functions
Option |
Function |
Default Key |
Exit the X Window System |
reset |
break |
Add a modifier to the exit key |
reset_mod1 |
control |
Add a modifier to the exit key |
reset_mod2 |
left_shift |
Add a modifier to the exit key |
reset_mod3 |
no default |
Set the threshold for changing between screens |
screen_change_amt |
30 pixels (0 if a graphics tablet is used) |
screen_change_amt is used only if your system is configured for more
than one screen. screen_change_amt enables you to avoid switching
from one screen to another if you accidentally run the pointer off the edge of
the screen. screen_change_amt establishes a "distance threshold"
that the pointer must exceed before the server switches screens. As the
previous table shows, the default width of the threshold is 30 pixels, but
acceptable values range from 0 to 255.
When a graphics tablet is used as the X pointer, the
screen_change_amt defines an area at the left and right edges of the
tablet surface that will be used to control screen changes. Moving the puck
or stylus into the left or right area will cause the X server to switch to the
previous or next screen.
Button Chording
Option |
Function |
Default Action |
Turn button chording off or on |
button_chording |
On for devices with two buttons, off for devices with more than two
buttons |
Button chording refers to the generation of a button-press by pressing two
other buttons. If you have a two-button mouse, you can generate Button 3 by
pressing both buttons together. With a three-button mouse, you can generate
button 4 by pressing the left and middle buttons together and button 5 by
pressing the middle and right buttons together. See the button chording
examples in the X*pointerkeys file.
You can also use the X*pointerkeys file to configure pointer buttons
so they are latched. When this feature is enabled, a button you press stays
logically down until you press it again. See the example
X*pointerkeys file in /usr/lib/X11 for information on
configuring this functionality.
Note: The sample X*pointerkeys file is placed in
/usr/lib/X11 at install time. If you subsequently update your
system, the X*pointerkeys file in /usr/lib/X11 is not
overwritten, and the sample file is placed in /usr/newconfig.
Specifying a Portion of a Tablet
Option |
Function |
Default |
Use a subset of the tablet surface as the X pointer device |
tablet_subset_width
tablet_subset_height
tablet_subset_xorigin
tablet_subset_yorigin
| disabled |
If a tablet is used as the X pointer device, it may be desirable to use only a
portion of the tablet surface. A rectangular subset of the surface may be
specified with these functions. The units are in millimeters from the upper
left corner of the tablet surface. For example, if you want to use only an
"A" size portion of a larger "B" size tablet, the following lines could be
added to the X*pointerkeys file:
tablet_subset_xorigin 68
tablet_subset_yorigin 40
tablet_subset_width 296
tablet_subset_height 216
You can also use the X*pointerkeys file to control screen switching
behavior in multi-screen configurations. See the example
X*pointerkeys file in /usr/lib/X11 for an example of this
functionality.
Note: The sample X*pointerkeys file is placed in
/usr/lib/X11 at install time. If you subsequently update your
system, the X*pointerkeys file in /usr/lib/X11 is not
overwritten, and the sample file is placed in /usr/newconfig.
You can select up to three keys from among the two
keys, the two
keys, and the
key and use them each as modifier
keys. A modifier key is a key that, when you hold it down and press another
key, changes the meaning of that other key.
Modifier keys in the X*pointerkeys file have three functions:
- They specify that a certain operation can't take place until they are
pressed.
- They enable you to adjust the distance covered by the pointer during a
movement operation.
- They enable you to change the key sequence that exits you from X11.
For example, you can overcome the problem in the last example by assigning the
key as a modifier to
the pointer direction keys. Now, to move the hpterm cursor to the
right, you press
as usual. To
move the x server pointer to the right, you press
.
To find out what key names are valid for the keyboard you are using, enter
xmodmap -pk
You may also use the default X Keysymbol names assigned to these keys
by the X Server.
If you only have one keyboard and no mouse, and you can live with the default
pointer key assignations, you don't have to do anything else to configure your
system for mouseless operation. To move the pointer to the left 10 pixels,
you would press the
key on the keypad.
To press mouse button 1 you would press the
key on the keypad.
However, suppose you wanted to move only one pixel to the left. Although the
default value of pointer_mod2_amt is one pixel, no key is assigned to
the modifier for that amount. Thus, you would need to edit the
X0pointerkeys file (or create an X*pointerkeys) to include a
line assigning one of the modifier keys to pointer_amt_mod2. The
following line in X0pointerkeys assigns the
key to
pointer_amt_mod2:
###pointerfunction key
pointer_amt_mod2 left_shift
Or suppose you wanted to set up your X0pointerkeys file so that you
could move 1, 10, 25, and 100 pixels. The following lines show one way to
specify this:
###pointer function key
pointer_amt_mod1 left_extend
pointer_amt_mod2 left_shift
pointer_amt_mod3 control
pointer_move 1_pixels
pointer_mod1_amt 10_pixels
pointer_mod2_amt 25_pixels
pointer_mod3_amt 100_pixels
With these lines in effect, one press of the
key on the keypad moves the pointer 1 pixel to the left. Pressing
the left
and
moves the pointer 10 pixels to the left.
Pressing
moves the pointer 25 pixels to the left.
And pressing
moves the pointer 100 pixels to the left.
Or, take the case, previously mentioned, where you want to use the arrow keys
for both text cursor and mouse pointer. You could insert the following lines
in your X0pointerkeys file:
###pointer function key
pointer_key_mod1 left_shift
pointer_left_key cursor_left
pointer_right_key cursor_right
pointer_up_key cursor_up
pointer_down_key cursor_down
The above lines enable you to use the arrow keys for cursor movement, while
using the shifted arrow keys for pointer movement. Note that only the
key (and not the
) modifies the press of an
arrow key from cursor to pointer movement.
Now, suppose you want to use the arrow keys to operate the pointer, and you
also need the arrow keys to control the cursor in an hpterm window.
Furthermore, another application uses the shift-arrow key sequence to control
its cursor.
The easiest way to solve this dilemma is to call in another modifier. The
following lines illustrate this. Compare them to the previous example.
###pointer function key
pointer_key_mod1 left_shift
pointer_key_mod2 left_extend
pointer_left_key cursor_left
pointer_right_key cursor_right
pointer_up_key cursor_up
pointer_down_key cursor_down
In this example,
- Pressing the
key moves the
hpterm text cursor up.
- Pressing
moves the cursor up in the
program you frequently operate.
- Pressing
moves the pointer up.
Using a similar technique, you can also reassign the
sequence
that aborts a session. You can specify the press of a single key or a
combination of two, three, or four key presses. Just make sure that the key
sequence you select isn't something you're going to type by accident.
Besides remapping the mouse's pointer and buttons to your keyboard, you can
remap any key on the keyboard to any other key.
To change the meaning of a particular key for a particular X11 session, or to
initialize the X server with a completely different set of key mappings, use
the xmodmap client.
Note
There are now two keyboards available for Hewlett-Packard workstations, the
46021 keyboard, and the C1429 keyboard. See "Using the Keyboards" for more information on
using these keyboards and the differences between them.
The syntax for xmodmap is as follows:
xmodmap
options
[
filename
]
where
options
are:
- -display
host
:
display
- Specifies the host, display number, and screen to use.
- -help
- Displays a brief description of xmodmap options.
- -grammar
- Displays a brief description of the syntax for modification expressions.
- -verbose
- Prints log information as xmodmap executes.
- -quiet
- Turns off verbose logging. This is the default.
- -n
- Lists changes to key mappings without actually making those changes.
- -e
expression
- Specifies a remapping expression to be executed.
- -pm, -p
- Prints the current modifier map to the standard output. This is the
default.
- -pk
- Prints the current keymap table to the standard output.
- -pp
- Print the current pointer map to the standard output.
- -
- Specifies that the standard input should be used for the input file.
filename
- Specifies a particular key mapping file to be used.
Whether you remap a single key "on the fly" with a command-line entry or
install an entire new keyboard map file, you must use valid expressions in
your specification, one expression for each remapping.
A valid expression is any one of the following:
Valid xmodmap Expressions
To do this... |
Use this expression... |
Assign a key symbol to a keycode |
keycode keycode
= keysym |
Replace a key symbol expression with another. |
keysym keysym
= keysym |
Clear all keys associated with a modifier key. |
clear modifier |
Add a key symbol to a modifier. |
add modifier
= keysym |
Remove a key symbol from a modifier. |
remove modifier
= keysym |
- keycode
- Refers to the numerical value that uniquely identifies each key on a
keyboard. Values may be in decimal, octal, or hexadecimal.
- keysym
- Refers to the character symbol name associated with a keycode; for
example, KP_Add.
modifier
- Specifies one of the eight modifier names: Shift,
Control, Lock, Mod1, Mod2,
Mod3, Mod4, and Mod5.
On Hewlett-Packard keyboards, the lock modifier is set to the
key. However, any of the modifiers
can be associated with any valid key symbol. Additionally, you can associate
more than one key symbol with a modifier (such as Lock = Shift_R and
Lock = Shift_L), and you can associate more than one modifier with a
key symbol (for example, Control = Caps_Lock and Lock =
Caps_Lock).
For example, on a PC-style keyboard, you can press
to print a lower case "d", ![[Shift]](keycaps/ShiftKey.xbm)
to print a capital "D",
![[Alt]](keycaps/AltKey.xbm)
to print something else, and ![[Shift]](keycaps/ShiftKey.xbm)
![[Alt]](keycaps/AltKey.xbm)
to print still something else.
The xmodmap client gives you the power to change the meaning of any
key at any time or to install a whole new key map for your keyboard.
Suppose you frequently press the
key at the most inopportune moments. You could remove the
lock key from the lock modifier, swap
it for the
key, then map the
key to the lock modifier. Do this by
creating a little swapper file that contains the following lines:
!This file swaps the [Caps] key with the [F1] key.
remove Lock = Caps_Lock
keysym Caps_Lock = F1
keysym F1 = Caps_Lock
add Lock = Caps_Lock
Note the use of the ! in the file to start a comment line. To put
your "swapper" file into effect, enter the following on the command line:
xmodmap swapper
If you use such a swapper file, you should probably have an unswapper
file. The following file enables you to swap back to the original keyboard
mapping without having to exit X11:
!This file unswaps the [F1] key with the [Caps] key.
remove Lock = Caps_Lock
keycode 88 = F1
keycode 55 = Caps_Lock
add Lock = Caps_Lock
Note the use of the hexadecimal values to reinitialize the keycodes to the
proper key symbols. You put your "unswapper" file into effect by entering the
following command line:
xmodmap unswapper
On a larger scale, you can change your current keyboard to a Dvorak keyboard
by creating a file with the appropriate keyboard mappings.
xmodmap .keymap
The -pk option prints a list of the key mappings for the current
keyboard.
xmodmap -pk
The list contains the keycode and up to four 2-part columns. The first column
contains unmodified key values, the second column contains shifted key values,
the third column contains meta (
) key values, and the fourth column contains shifted meta
key values. Each column is in two parts: hexadecimal key symbol value, and
key symbol name.
There are now two keyboards available for Hewlett-Packard workstations. In
addition to the 46021 keyboard, a personal computer-style keyboard, C1429 is
also available. This new keyboard is also known as the "Enhanced Vectra"
keyboard.
If an application is reading input directly from the keyboard, it receives a
keycode when a key is pressed. Equivalent keys on the two keyboards
are those that generate the same keycode. If an equivalent key does not
exist, there is no way to generate the corresponding keycode.
In an X Window System environment, keycodes are mapped into key symbols
by the X library. The key symbols are stored in a keysym table.
Application programs then reference these key symbols when accessing keys.

Keycap, Keycode, and Keysym Relationships
Equivalent keys are those keys that are mapped to the same key symbol. One
advantage of this mapping is that if a key does not physically exist on a
keyboard, its equivalent key symbol can be mapped to some other key through
the corresponding keycode.
The default keyboard mapping supplied with the X Window environment maps the
C1429 keyboard to the same key symbols that are used for the 46021 keyboard.
This allows existing X client programs that expect to receive input from a
46021 keyboard to be used with either keyboard. However, the result is that
some keys on the C1429 keyboard are mapped to key symbols that do not match
the engravings on their keycaps.
Some applications may expect to use keys that exist on one of the keyboards
but not the other. In most cases, if a key does not exist on the keyboard in
use, it is still possible to use some other key that is equivalent. To do
this, it is necessary to know which keys are equivalent on the two
keyboards.
There are 14 keys on the C1429 keyboard that generate keycodes equivalent to
keys on the 46021 keyboard, but have different engravings on the keycaps.
Some have the same key symbol on both keyboards, while others do not. These
C1429 keys, their 46021 equivalents, and the corresponding symbol names are
shown in the following table.
C1429 Keycap |
46021 Keycap |
Default Key Symbol |
XPCmodmap Symbol |
![[F9]](keycaps/f9Key.xbm) |
blank1 |
F9 |
F9 |
![[F10]](keycaps/f10Key.xbm) |
blank2 |
F10 |
F10 |
![[F11]](keycaps/f11Key.xbm) |
blank3 |
F11 |
F11 |
![[F12]](keycaps/f12Key.xbm) |
blank4 |
F12 |
F12 |
![[PrintScreen/sysRq]](keycaps/PrScrKey.xbm) |
![[Menu]](keycaps/MenuKey.xbm) |
Menu |
Print |
![[Scroll Lock]](keycaps/ScrLockKey.xbm) |
![[Stop]](keycaps/StopKey.xbm) |
Cancel |
Scroll_Lock |
![[Pause/Break]](keycaps/PseBrkKey.xbm) |
![[Break/Reset]](keycaps/BrkRsetKey.xbm) |
Break/Reset |
Pause/Break |
![[Page Up]](keycaps/PageUpKey.xbm) |
![[Prev]](keycaps/PrevKey.xbm) |
Prior |
Prior |
![[Num Lock]](keycaps/NumLockKey.xbm) |
![[System/User]](keycaps/SysUserKey.xbm) |
System/User |
Num_Lock |
![[End]](keycaps/EndKey.xbm) |
![[Select]](keycaps/SelectKey.xbm) |
Select |
End |
![[Page Down]](keycaps/PageDnKey.xbm) |
![[Next]](keycaps/NextKey.xbm) |
Next |
Next |
![[Enter]](keycaps/EnterKey.xbm) |
![[Return]](keycaps/ReturnKey.xbm) |
Return |
Return |
(left) |
(left) |
Meta_L |
Alt_L |
(right) |
(right) |
Meta_R |
Alt_R |
X provides the means to change the key mapping, if you so desire. One way to
accomplish this is by running the xmodmap client program.
Hewlett-Packard provides two files in the directory /usr/lib/X11 to
use with xmodmap. One, XPCmodmap, causes xmodmap
to change the key mapping to match the keycap engravings on the C1429
keyboard. The other, XHPmodmap, causes xmodmap to change
the key mapping to match the keycap engravings on the 46021 keyboard, which
are the defaults. This allows either keyboard to be used with applications
that expect the other keyboard, although only one mapping can be used at any
given time. When the mapping is changed, the X Server notifies all clients
that are executing at that time. Some clients may load the new mapping from
the server right away, but others may have to be restarted in order to
recognize the new mapping. For more information about using the
xmodmap client, see the xmodmap man page.
Execute the following command to change the mapping of the keys shown above to
match the engravings on the C1429 keycaps.
/usr/bin/X11/xmodmap /usr/lib/X11/XPCmodmap
Execute the following command to change the mapping to match the 46021
keyboard.
/usr/bin/X11/xmodmap /usr/lib/X11/XHPmodmap
The 46021 keyboard has 107 keys, while the C1429 keyboard has 101 keys. There
are 7 keys on the 46021 keyboard whose keycodes cannot be generated by any key
on the C1429 keyboard, and whose key symbols cannot be generated when using
the default keymap for the C1429 keyboard. The missing keys are:
(on number pad)
(on number pad)
and
exist elsewhere on the C1429 keyboard, and the others are not
needed by most applications. Applications that do need one or more of them
must assign their key symbols to the keycodes of existing keys. The
xmodmap client can be used to determine the keycode-to-key symbol
mapping of existing keys, and it can also be used to assign the key symbol to
the desired keycode. These keys use HP specific key symbol names whose
correct spelling can be found in the file /usr/lib/X11/XKeysymDB.
The right
key on the C1429
keyboard generates a keycode that has no equivalent on the 46021 keyboard.
This key has the same effect as the left
key by default.
Keys not mentioned above exist on both keyboards, and have the same key
symbols.