Before taking a look at various configuration mechanisms for X servers and clients, it should be noted that the advent of Desktop Environments like KDE have become popular in part because they can control much of the user interaction configuration themselves with nice, "user friendly" GUI controls. And in fact, the compliant applications that are part of the respective Desktops will be best configured through the Desktop's configuration tools, or the application's own GUI configuration methods. So, for instance, gtop, a GNOME client application, is best configured via GNOME or gtop's own menus. But this is not true of all X applications.
The X server can store various configuration values for client programs so they are readily available when needed. If the application supports this, it will use these as defaults whenever that program is invoked. These are known as "Resources", and are often used to define user preferences on a per application basis for fonts, colors, screen placement (geometry) and various other attributes. This makes it easy to customize applications.
Resources are specified as text strings (e.g. Netscape*blinkingEnabled: False) that can be read from disk in various places when X is starting, or even interactively defined on the command line. Program components are named in a hierarchical fashion, with each object in the hierarchy identified by a class as well as an instance name. At the top level of the hierarchy is the class and instance name of the application itself. Typically, the class name of the application is the same as the program name, but with the first letter capitalized (e.g. Vim or Emacs) although some programs that begin with the letter "X" also capitalize the second letter for historical reasons (e.g. XTerm). Each definition will specify a class (or instance), with corresponding resource and value. Below this in the hierarchy are the various attributes that make up the definable aspects of the application.
Traditionally, most X programs were configured this way. This is not as true today with the advent of Desktop Environments which often have their own configuration mechanisms.
As an example, say we prefer to run xterm with a blue background. So if we run it from the command line, we would run it as:
xterm -bg blue & |
If this is our preference, it would be easier to put this preference in a file somewhere, and have the system use our preference. That way whenever we started xterm, it would use our preferred value, and we wouldn't need the command line options (unless as an override).
The basic X resource syntax is expressed like:
<program><binding><widget><binding><widget><...><resource>:<value> |
Which, in real life, typically looks something like:
xterm*fontMenu*background: darkblue |
It should be obvious what this does. The use of "*" in the definition, is called a "loose binding" and acts as a wild-card. Meaning there may be gaps in the widget hierarchy. For instance:
xterm*background: darkblue |
This would also give a dark blue background for the xterm fontMenu, but also any other xterm properties that also have a "background" attribute (e.g. window background, etc), no matter where they may be in the widget hierarchy. Similarly:
*background: darkblue |
This would define the background for any and all programs that support it -- not just xterm. Using a "." in place of a "*" would be more precise, and will not allow for wild-card gaps in the hierarchy. Also, the application must support the particular widget attribute. "Background" is a fairly safe bet, but many applications will have more specialized resources that are not so obvious. It is best to check local documentation (man pages, etc), or see if an application has an included examples. For instance, Netscape generally comes with an Netscape.ad file that has an extensive set of resource definitions that can be customized.
X resources are typically stored in more than one place (see below) and are processed by the xrdb command (see man page).
One way of storing preferred application resources is via files named for the application in an "app-defaults" directory. For instance, on my system, these are in /usr/X11R6/lib/X11/app-defaults/, though this may vary according to options your vendor has chosen. This directory contains a number of files for such well known X applications as xterm, xclock, xcalc, xload, and so on. All in all, it is a relatively small number of applications in the overall scheme of things. So not all applications use this scheme. In fact, most do not.
Each file will contain resource definitions for that application. The X server loads these by itself during start up. A brief example from XTerm-color:
! $XFree86$ #include "XTerm" *VT100*colorMode: on *VT100*dynamicColors: on ! Uncomment this use color for underline attribute !*VT100*colorULMode: on !*VT100*underLine: off ! Uncomment this to use color for the bold attribute !*VT100*colorBDMode: on *VT100*color0: black *VT100*color1: red3 *VT100*color2: green3 *VT100*color3: yellow3 *VT100*color4: blue3 *VT100*color5: magenta3 *VT100*color6: cyan3 *VT100*color7: gray90 *VT100*color8: gray30 *VT100*color9: red *VT100*color10: green *VT100*color11: yellow *VT100*color12: blue *VT100*color13: magenta *VT100*color14: cyan *VT100*color15: white *VT100*colorUL: yellow *VT100*colorBD: white |
This is mostly various color definitions. The application classname is not explicitly stated, and is assumed from the filename. So think of each line as starting: XTerm-color*. Also, notice at the top, the #include "XTerm" line, which "includes" the resource definitions for XTerm, a much longer file with a more diverse set of definitions. (Not included due to length, but worth looking at.) These files provide system wide defaults, and generally speaking, would not normally be edited by the user.
Another common method of reading in resource preferences, is with an Xdefaults file. Or, sometimes the naming scheme may be Xresources instead. This may exist as a system wide file, such as /etc/X11/Xresources. Of course, the user is free to create a personal version in his home directory, e.g. ~/.Xdefaults. The user's version will over-ride any system wide settings, and will remain after system upgrades. Obviously, this is the place to put your own preferences.
Xresources files are read into the resource database with the xrdb command. Example:
xrdb -merge ~/.Xresources |
This can be done interactively at the command line, or placed in a script and run automatically as the X session is started. In the case of system wide files, this should be taken care of by the vendor supplied start up scripts. Generally, such scripts will also check the user's home directory as well (see the xinitrc example above). So probably all that need be done, is to create the file with a text editor.
Here's an example to illustrate a very few of the many things that might be done with an .Xdefaults file:
! This is a comment ;-)
#ifdef COLOR
*customization: -color
#endif
!! Let's cast a wide net, for any app supporting these
! Blink instead of beeping
*visualBell: True
*scrollTtyOutput: False
*scrollKey: True
! See Netscape.ad for many settable resources
Netscape*noAboutSplash: True
Netscape*documentFonts.sizeIncrement: 5
Netscape*documentFonts.xResolution*iso-8859-1: 120
Netscape*documentFonts.yResolution*iso-8859-1: 120
netscape-navigator*geometry: 960x820+240+140
emacs*Background: DarkBlue
emacs*Foreground: Wheat
emacs*pointerColor: Orchid
emacs*cursorColor: Orchid
emacs*bitmapIcon: on
emacs*font: 10x20
! GVim colors, etc
!! GTK versions of gvim will not use all these.
Vim*useSchemes: all
Vim*sgiMode: true
Vim*useEnhancedFSB: true
Vim.foreground: Black
!Vim.background: lightyellow2
Vim*background: white
! geometry: width x height
Vim.geometry: 88x40
Vim*font: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-15-*5
Vim*menuBackground: yellow
Vim*menuForeground: black
rxvt*backspacekey: ^?
rxvt*background: Black
rxvt*foreground: wheat
rxvt*cursorColor: Orchid
rxvt*geometry: 100x18+40+300
rxvt*title: Linux
rxvt*reverseVideo: false
!rxvt*backgroundPixmap: ~/penguinitis.xpm
rxvt*scrollBar: true
rxvt*reverseWrap: true
rxvt*font: -*-lucidatypewriter-medium-*-*-*-14-*-*-*-*-*-*-*
rxvt*fullCursor: true
rxvt*saveLines: 1500
rxvt*menu: ~/rxvt.menu
XTerm*saveLines: 1500
! Do not clear the screen after the program exits
XTerm*VT100*titeInhibit: true
! Fix up xterm's keybindings
xterm*VT100.translations: #override \
<Key>BackSpace: string(0x7F) \n\
<Key>Insert: string(0x1b) string("[2~")\n\
<Key>Delete: string(0x1b) string("[3~")\n\
<Key>Home: string(0x1b) string("[1~")\n\
<Key>End: string(0x1b) string("[4~")\n\
<Key>Page_Up: string(0x1b) string("[5~")\n\
<Key>Page_Down: string(0x1b) string("[6~")\n\
<KeyPress>Prior : scroll-back(1,page)\n\
<KeyPress>Next : scroll-forw(1,page)
! Ghostview
Ghostview*Font: *-helvetica-bold-r-normal--12-*-*-*-*-*-*
Ghostview*BorderColor: white
Ghostview*Text*Font: rk14
Ghostview*Background: #d9d9d9
!Ghostview*Foreground: white
ghostview.form.pageview.page.background: white
ghostview.form.pageview.page.foreground: black
.ghostview.zoom.form.page.background: white
.ghostview.zoom.form.page.foreground: black
! xscreensaver !
! Time out after 12 minutes, cycle mode after each 2
xscreensaver.timeout: 12
xscreensaver.cycle: 5
! Run low priority, and fade between modes
xscreensaver.nice: 12
xscreensaver.fadeSeconds: 2
XFontsel.menu.options.showUnselectable: False
|
Hopefully, these few examples will give you some ideas to build on. X does not need to be restarted if xrdb is used interactively from the command line after making changes. The effects are immediate.
Resources are sometimes available also as command line options. See below. Command line options will over-ride any existing resource definitions.
The keyboard and mouse, as well as other possible input devices, are defined in XF86Config (or XF86Config-4). There is a keyboard layout that is defined based on the preferred language:
Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "XkbLayout" "us" EndSection |
This gives us our default keyboard layout. Valid layout labels are listed in /usr/X11R6/lib/X11/xkb/symbols. Also, the setxkbmap utility can be used to change this interactively.
X is highly customizable, and we can modify the keyboard and mouse pointer mappings to suit our own preferences. The utility to do this is xmodmap (see man page). You don't like where the capslock key is? So move it ;-)
Like xrdb, xmodmap can be run from the command line. Or, preferred settings can be stored in a file. Typically this is ~/.Xmodmap, or similar. If your X start up files don't parse this, then edit as appropriate so that they do (probably from ~/.xinitrc or ~/.xsession).
You can view your current key and mouse mappings with: xmodmap -pk -pp |less. This will print out all active "keycode" values, with corresponding "keysym" values, and any keysym names that xmodmap knows about (e.g. "BackSpace"). And should also give you an idea of how xmodmap understands key and mouse events. There are two keysyms per keycode. The second is the shifted value. XFree86's xev utility can be used to dump a lot of information on key-presses and mouse events interactively. Pay attention to the "keycode" value. That is what you will need to know in order to re-map.
xmodmap is often used to make minor keyboard adjustments, like proper Backspace/Delete mapping. Or can be used make major adjustments such as for international mappings. You can only re-map keys and mouse events -- you cannot assign macros to key events (your Window Manager or Desktop might have some of this functionality).
A nice discussion of setting up international keyboards . Also, Google search will turn up many creative examples.
The man page has many brief examples of various usages. Here is what an one hypothetical ~/.Xmodmap might look like:
! /home/hal/.Xmodmap, last change 10/03/01 ! ! Force backspace to 22 and Delete to 111 keycode 22 = BackSpace keycode 111 = Delete ! ! My keyboard handles right and left Alt differently. Make the ! Right act like the Left to avoid digital gymnastics. keycode 63 = Alt_L keycode 113 = Meta_L ! ! Hard-code the keypad to numeric values as if numlock is always on ! since I never use it for anything else. keycode 79=7 keycode 80=8 keycode 81=9 keycode 83=4 keycode 84=5 keycode 85=6 keycode 87=1 keycode 88=2 keycode 89=3 keycode 90=0 keycode 91=period keycode 86 = plus ! deactivate Num_Lock key since we don't need it now. keycode 77 = ! ! My capslock is next to tab. I hit it by mistake sometimes, ! and don't use it anyway. So make capslock act like Tab. keycode 66 = Tab clear lock ! ! Reverse mouse buttons for left-handed people pointer = 3 2 1 |
As with many XFree86 files, the "!" represents a comment. Another possible use, is to redefine those annoying "Windows" keys to something useful. Hopefully this gives an idea of some things one might want to do to make the keyboard more agreeable to us.
Speaking of the Numlock key, X will typically disable this when it starts up. No matter how you have the BIOS set up, or Linux set up before X starts. So the trick above is one way. There is also a utility available as either numlockx, or setnumlock, that can be found on the ’Net, if your distribution does not include one or the other. This can be put in a start up file to turn Numlock on automatically if you would prefer.
Window Managers and Desktop Environments will also allow customization of the keyboard and mouse (as long as it is recognized correctly by X). This may be an easier way to configure certain customizations.
There are several special key mappings traditionally used in XFree86.
Will kill the X server process in an orderly fashion. This is a quick, easy, legitimate way to restart X. Note it does not restart the display manager (if used) — just X itself.
where n corresponds to a valid TTY number (typically 1–6). This is typically used to jump to a text console login, while X remains running. To get back to X, press Alt-Fn. In this case, n represents one plus the last TTY (e.g. Alt-F7 if there are six available TTY’s).
That is the plus and minus keys on the keypad. This will cycle through any existing valid screen resolution modes, e.g. 1024�768 → 600�800. Note the actual screen size is the same — just the view and resolution changes. Not all that useful for most purposes. You cannot permanently change the screen resolution without restarting X.
It's possible your Window Manager, Desktop Environment or other system component may trap these, and alter the standard behavior. In addition, the Ctrl-Alt-Delete may be trapped as well. This should shut X (and the system) down orderly, if it is available.
As mentioned, Linux and Unix make heavy use of three mouse buttons. If a mouse only has two buttons, then the third (i.e. the middle) button can be simulated by pressing both buttons simultaneously. This is a configuration option set in XF86Config as the "Emulate3Buttons" directive:
Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Device" "/dev/mouse" Option "Protocol" "PS/2" Option "Emulate3Buttons" "on" EndSection |
When all is said and done, a third button is quite handy and I would personally recommend having one. On wheeled mice, the "wheel" acts as the third button, if pressed. Many standard wheel mice seem to work with the "IMPS/2" protocol option.
Specifically, the third button (middle) is the "paste" button in virtually all Linux applications. Copy and paste works a little different in Linux. The left button is the copy button. Just hold it down, and drag over text. It is automatically copied to the X "clipboard". Then, the middle button will paste from there. A very simple process. A double-click should copy individual words, and a triple-click individual lines of text. If for some reason, this does not work, it is either a poorly implemented application, or a bug of some kind. Some older versions of Netscape were not consistent about this, for instance. To paste from the keyboard, this should be shift+insert.
"Drag and Drop" is not natively supported by X itself. But, is implemented by some toolkits and Desktop Environments. One should not expect this to work with non-compliant applications (i.e non-KDE aware applications in KDE for example).
xset is yet another XFree86 utility to set user preferences. xset is a bit of a catch-all and is used to change various, unrelated X server settings. Mostly this is a command line way of configuring some of the same things that are defined in XF86Config (but not everything!).
Common usages of xset are to set DPMS on or off and preferred intervals, to dynamically change the FontPath or re-read it, to control keyboard LEDs, to adjust mouse (or other pointer) movement speed, set keyboard "autorepeat" and "repeat" rates, and to control X's built in screen blanking. See the man page, of course, for detailed explanations, and other xset usages.
Again, xset can be used interactively from the command line. But most often preferred settings are stored in one of the start up configuration files, like .xinitrc or .xsession. A very brief example:
# Turn off screen blanking xset s off # Enable DPMS energy saving xset +dpms # Tweak the rodent xset m 30/10 4 # Speed up keyboard xset r rate 200 40 |
Your desktop may have a GUI front-end for xset.