I see a lot of questions on debian-user, particularly about xdm, that are answered in the Debian X FAQ. Obviously there are lots of people that don't know this document exists.
It is in /usr/doc/xfree86-common/FAQ. I have MIME-attached the latest version (which answers more questions than the version in the slink X packages) for your reading pleasure. -- G. Branden Robinson | Debian GNU/Linux | Never attribute to malice that which can [EMAIL PROTECTED] | be adequately explained by stupidity. cartoon.ecn.purdue.edu/~branden/ |
Debian X Window System Frequently Asked Questions (FAQ) List Copyright 1998, 1999 Branden Robinson. This document is licensed under the GNU General Public License (see /usr/doc/copyright/GPL). This document isn't complete yet. If your question is not answered here, try /usr/doc/<packagename>/README.Debian (and other files in the package's doc directory), manual pages, and the debian-user mailing list. See http://www.debian.org/ for more information about the Debian mailing lists. Two other FAQ's of interest are available: *) The XFree86 FAQ, provided in the xfree86-common package; this FAQ focuses almost exclusively on configuration and hardware support problems with the X server. If you are having trouble getting the X server started, especially if you have newer video hardware, this FAQ often has an answer. *) The XTERM FAQ, provided in the xterm package; this FAQ addresses various issues with one of the most popular and important of X clients -- the terminal emulator that ships with the X Window System. Like all other documentation, these FAQ's are in /usr/doc/<packagename>/. Finally, for the latest news about Debian XFree86 packaging development, future plans, or to find out how you can help improve the quality of Debian's XFree86 packages, check out the X Strike Force: http://www.debian.org/~branden/ CONTENTS General Questions *) What is the X Window System? *) What is XFree86? *) What are X servers and X clients? *) Why is the X usage of "server" and "client" backwards from everyone else's? *) What is an X session? *) What is the root window? *) What is a window manager? *) What is a session manager? *) What is window focus? *) What are X resources? How-To Questions *) How do I customize my X session? *) How do I change what appears in the root window? *) How do I change the color depth of my X server? *) How do I run more than one local X server simultaneously? *) How do I set up the mouse buttons for left-handed use? *) How do I stop xdm from starting at boot? *) How do I tell xdm to start the X server on a different virtual console? *) How do I run an X client as root when the X session is run by a user? *) How do I change xterm's default terminal type or key bindings? *) How do I keep my mouse from going crazy (or going away) when switching between X and the Linux virtual console? GENERAL QUESTIONS *) What is the X Window System? In the words of its primary manual page, X(1), it is a "portable, network-transparent window system". Its primary distinction from other well-known window systems like Microsoft Windows and Apple's MacOS is that it was designed with the local area network in mind. You can run programs on one machine and display them on another. Historically, the X Window System was initially conceived in 1984, at the Massachusetts Institute of Technology as a joint project between their Laboratory for Computer Science and the Digital Equipment Corporation. This joint effort was called "Project Athena", and was headed by Bob Scheifler. The first version of the X Window System to be widely deployed was Version 10 (X10). It was shortly superseded by Version 11 (X11), however, in 1987. In 1988, a non-profit group called the (MIT) X Consortium was formed to direct future development of X standards in an atmosphere inclusive of many commercial and educational interests. The X Consortium produced several significant revisions to X11, concluding with Release 6 in 1994 (X11R6). The X Consortium dissolved at the end of 1996, producing a final, small revision to X11R6 called X11R6.3. Ownership of X then passed to the Open Group. In early 1998, the Open Group released a further revision to X11R6, called X11R6.4 -- a departure from the traditional licensing terms, however, prevented adoption of this version of the X Window System by many vendors, including the XFree86 Project, Inc. (see below). In late 1998, the Open Group relicensed X11R6.4 under terms identical with the traditional license. In May 1999, stewardship of the X Window System passed from the Open Group to X.Org, a non-profit organization focused exclusively on maintenance and further development of the X Window System. *) What is XFree86? Strictly speaking, the various groups that have developed the X Window System over the years have been standardization groups, not software developers. However, they have also developed a reference implementation of the standards, and this source code is what is popularly called the X Window System. The license on this source code freely permits modification and redistribution, and this what many software vendors have done. The XFree86 Project, Inc., is a not-for-profit group whose original, self-determined charter was to develop X servers that would work on the wide variety of video hardware available for Intel x86-based machines (hence the "86" in "XFree86"). They also decided to release their X servers under licensing terms identical to that of the freely available X sources, hence the "Free" in the "XFree86". By keeping with the licensing terms of the original X source distribution, XFree86 has enjoyed immense popularity, and they no longer confine their activities to merely producing X servers for IBM PC-compatible video hardware. XFree86 is thus the superset of the X Window System that is used by the Debian GNU/Linux system. *) What are X servers and X clients? This is the most important, and probably the first, concept a newcomer to the X Window System should learn. X achieves its success by separating the details of display and input hardware from the programs that use them. When a program that uses the X Window System needs to, for instance, draw on the screen, or know what keys on the keyboard have just been pressed, it does not communicate directly with the hardware. Instead, it communicates with a single program, called the X server, whose job it is to deal with a computer's video card (and thus monitor), keyboard, and mouse (or other pointing device). The programs, then, that wish to use the windowing system to interact with the user are thus called X clients. The program that actually "delivers the goods", both to the user in the form of displayed graphics, and to the program in the form of information about pressed keys or a moving mouse, is the X server. Commonly, an individual machine like a workstation or X terminal, only runs one X server, to which many X clients "connect" and perform their tasks. In fact, however, on a Linux machine, more than one X server can be running at one time. *) Why is the X usage of "server" and "client" backwards from everyone else's? People who have worked in LAN-type environments are easily confused by the X notions of client and server. In such a scenario, one might have dozens of "client" machines, each running an X server which uses the network to connect to X clients (application programs) running on the "server" in the machine room. However, X's client/server terminology makes perfect sense if one thinks about what resources are in demand, and what program's job it is to service requests. On the computer where a human being is actually sitting down and working, the resources in demand are the video display, keyboard, and mouse (or other pointing device). All of the running programs can't monopolize these resources at once, or we lose the benefits of multitasking that a windowing system gives us. Furthermore, why should each and every piece of software, like a mail reader, a clock application, and so forth, have to worry about things like how many buttons the mouse has, or how many colors the display can show at once? The X server centralizes this information and manages the hardware resources, which it serves to the X clients. *) What is an X session? An X session is the set of X clients running that correspond to a single server process, which typically corresponds to one user's login. In other words, when I start X from the command line with "startx", or if a display manager like xdm is running and presents me with a graphical login screen and I type my username and password, what happens next is my X session. People generally customize their X sessions to start a set of familiar, desirable applications, like a clock, a graphical "biff" program that tells them when they have new email, one or more terminal sessions on various other computers, and so forth. The X session is terminated by "killing" the X server. The X server may be killed by the <CTRL-ALT-BACKSPACE> key sequence, or by stopping a particular program (like the window manager), which is "tied" to the X server. When that particular program ends, the X server automatically exits. (The X server may also terminate if some abnormal condition happens, like one of its X clients causes it to coredump.) If no display manager is running, the system returns to the command line prompt. If a display manager is running, the X server is restarted with no one logged in -- a graphical prompt for a username and password is displayed instead. Like Unix shell login sessions, which are customized by a file like .login or .profile in the user's home directory, X sessions can be customized on a per-user basis as well. In the Debian GNU/Linux system, creating and editing the .xsession file in the user's home directory is the preferred method of customizing an X session. See /usr/doc/xfree86-common/examples/xsession for more information. *) What is the root window? Like the Unix filesystem, windows in X are laid out like a tree with a single "root". The root window is the window that is "behind" all others, and covers the entire screen from corner to corner (in fact, if the virtual desktop feature of the XFree86 X servers is used, the root window can actually be larger than the screen). People often place an image of some sort in the root window ("wallpaper"), or run a program which draws something interesting and/or pleasing in the root window. *) What is a window manager? In other window systems like Microsoft Windows or MacOS, the concept of "window manager" is not obviously distinct from the rest of the window system. X, however, was designed from the beginning to maximize customizability, and to impose as little on the user as possible. The window manager is what copes with the fact that in a windowing system, one generally has more than window on the screen (if this were not the case, one might wonder why a windowing system were being used at all). Fundamentally, the window manager is in charge of window placement (moving, resizing, stacking order, and so forth). In practice, X window managers over the years have acquired more and more features. The typical window manager in use today draws borders around the windows which can be used to move and resize the window by grabbing, determines the focus policy, and presents menus which permit the iconification ("minimizing") or easy killing of X clients. Some window managers go farther and do some tasks of session management as well. *) What is a session manager? Rather than having a static list of X clients to be launched each time the X Window System starts, as is often the case in a user's .xsession file, it is possible to have a special X client run whose job it is to keep track of the other X clients, and "remember" the state of these programs between X sessions. Needless to say, an X client has to support the saving of its state between sessions, because when the X server dies, the clients that are connected to it die as well. When a session manager is run with X clients that support session management, a user can end his X session, and when he next starts it, he will be greeted with a screen that looks just the one he had when he left -- windows in the same locations, applications with the same files open, etc. *) What is window focus? The keyboard can only be used to "type into" one X client at a time. The mouse is used to determine which client has "focus", or receives keyboard events. There are two major kinds of focus, "pointer" and "explicit". Pointer focus, also known as "focus-follows-mouse", means that wherever the mouse cursor is, that window has focus. Explicit focus, or "click-to-type", means that a mouse button (usually the first, or leftmost on a right-handed mouse) must be clicked on a window with the mouse pointer over it for focus to change to that window. The focus policies available are determined by the window manager. Traditionally, pointer focus, or something very similar, is used in the X Window System -- but there is no reason explicit focus cannot be used, and X clients work equally well with either focus policy. *) What are X resources? X clients are typically customizable in their appearance and behavior in a very large number of ways. It would be very cumbersome to require X clients to be called with command-line arguments specifying each of the configurable parameters. Therefore, the X server maintains a database of X resources. When an X client connects to an X server, it inherits a set of properties from the X server that correspond to it. The strength of X resources is at the same time what makes them intimidating; they are hierarchical and can be as general or as specific as is desired. Almost all X clients, for example, recognize resources called "foreground" and "background", and if the X server contains an appropriately general resource for these properties, every X client that recognizes them will use them. [much more remains to be written about this question] HOW-TO QUESTIONS *) How do I customize my X session? On a Debian GNU/Linux system, the file $HOME/.xsession is used (if present) to setup the user's X session. The file /usr/doc/xfree86-common/examples/xsession is an example file that may be used directly and contains a great deal of explicit instruction on customization. Note that the system administrator can configure the X Window System such that users' .xsession files in their $HOME directories are ignored. See the Xsession.options(5) manual page for more information. *) How do I change what appears in the root window? There are many X clients that can draw on the root window. xsetroot, which comes with the basic X distribution, is one. It is found in the xbase-clients package, and can be used to set the root window to a solid color, a plaid pattern in two colors, or tile it with a monochrome bitmap. *) How do I change the color depth of my X server? The best way to change the default color depth of the X server is to add a "DefaultColorDepth" line to the "Screen" section that corresponds to the X server you use. Here is one example: Section "Screen" Driver "Accel" Device "ATI [EMAIL PROTECTED]" Monitor "Sony 200sf" BlankTime 0 DefaultColorDepth 32 SubSection "Display" Depth 8 Modes "1152x864" "1024x768" "800x600" "640x480" "512x384" EndSubSection SubSection "Display" Depth 16 Modes "1152x864" "1024x768" "800x600" "640x480" "512x384" EndSubSection SubSection "Display" Depth 32 Modes "1152x864" "1024x768" "800x600" "640x480" "512x384" EndSubSection EndSection See XF86Config(5) for more information. To change the color depth on a per-invocation basis with startx, send the appropriate command line argument to the X server: startx -- -bpp 16 See Xserver(1), XFree86(1), and startx(1) for more information. With xdm, the /etc/X11/xdm/Xservers file must be edited; there is not a way to change the color depth on a per-session basis. One alternative is to have xdm manage more than one local X server, each with a different color depth (see below). *) How do I run more than one local X server simultaneously? This is not difficult if you understand that unless the X server is told otherwise, it attempts to be server number 0 for the local machine. To instruct the X server to use a different server number for itself, pass it the server number as an argument. Thus: startx -- :1 -bpp 16 Or, for xdm, edit the /etc/X11/xdm/Xservers file appropriately: :1 local /usr/X11R6/bin/X :1 vt8 -bpp 8 It is a good idea to explicitly tell the X server which virtual console to use (with the vt# argument) when writing the xdm Xservers file, because when xdm starts at boot time, getty may not have taken control of the virtual consoles it manages. XFree86 X servers automatically place themselves on the first available virtual console unless told otherwise. One may then get the distressing problem of getty attempting to respawn on a virtual console that xdm has claimed for itself; this usually results in a system that is unresponsive to the keyboard, and one must either connect to the system remotely to fix things, or take the system down via a hardware reset, which is not very nice. *) How do I set up the mouse buttons for left-handed use? (Thanks to "ulisses" for suggesting this question for the FAQ, and providing some of the information given.) This depends on how many buttons your mouse has. If it has two or three, I have an answer. If it has more than three, and/or a wheel, I'd appreciate submissions from lefties with such mice who have gotten them reconfigured. For a quick fix, you can execute the following while in an X session: xmodmap -e "pointer = 2 1" (for two-button mice) xmodmap -e "pointer = 3 2 1" (for three-button mice) To have the pointer buttons remapped for all of your X sessions, add the following line to your $HOME/.Xmodmap file (creating the file if necessary): pointer = 2 1 (for two-button mice) pointer = 3 2 1 (for three-button mice) Note, however, that the system administrator can configure the X Window System such that users' .xsession and/or .Xmodmap files in their $HOME directories are ignored. See the Xsession.options(5) manual page for more information. For more information about xmodmap, see xmodmap(1). *) How do I stop xdm from starting at boot? This is a very common question from people who have upgraded from Debian 2.0 or earlier, before the xdm program was separated out into its own package. Exactly how you deal with this depends on exactly what you want. Note that the following techniques all require root privileges. + I don't want xdm to run at all. In that case, simply remove or purge the xdm package with dpkg. If you have xbase installed, remove that before or simultaneously; xbase depends on xdm. See /usr/doc/xfree86-common/README.Debian-upgrade for more information. + I don't want xdm to manage any local servers. Edit /etc/X11/xdm/Xservers and remove any lines that correspond to the local host. This file ships with only one entry, for :0. If you comment that out, xdm will start but will not try to manage any X servers at all (unless you have added lines to the file). + I don't want xdm to manage any remote servers. Edit /etc/X11/xdm/Xservers appropriately. Note that as this file ships, it does not manage any remote servers, so unless you have already edited this file (or borrowed someone else's), no change is necessary from the package default to realize this state. + I want xdm installed on the system, but I don't want it to start at boot time. I just want to be able to become root and start it manually. Rename the /etc/init.d/xdm file (to, for instance, "xdm-manual"), then run the command "update-rc.d xdm remove". Because /etc/init.d/xdm is a conffile, dpkg will notice that it has been removed by the administrator and not attempt to re-create it when the xdm package is upgraded. You can then use /etc/init.d/xdm-manual (or whatever you renamed the xdm script to) normally with the "start", "stop" and other arguments. *) How do I tell xdm to start the X server on a different virtual console? People who have customized /etc/inittab to add virtual consoles beyond the six that is the default Debian configuration often find that xdm and their getty program "collide" and often leave the console in an unusable state. Debian's xdm program ships with a configuration that tells it to start one local X server on virtual console 7. This works fine with the default Debian /etc/inittab, but not so well for people who have changed the inittab to start a getty on VC 7. If you have increased your number of virtual consoles, or otherwise require VC 7 for some purpose, simply edit /etc/X11/xdm/Xservers and change the "vt7" argument on the ":0" server line to whatever VC is appropriate for your machine (vt8, vt12, etc.). Note that while the XFree86 manual page says that if the "vt" argument is not specified, the X server will use the first available virtual console, it is not a good idea to omit this parameter when starting local X servers with xdm. This is because even though xdm starts at the very end of the init sequence, well after the getty processes that manage the virtual consoles, some machines get through the init sequence so quickly that getty has not yet claimed its VC's before xdm starts. This leads to exactly the same kind of console lockup you get as if you deliberately tell getty (via /etc/inittab) and xdm (via /etc/X11/xdm/Xservers) to use the same virtual console for their respective tasks. *) How do I run an X client as root when the X session is run by a user? If a normal user is running an X session (from startx or xdm), and that user, for instance, uses the su command from within an xterm to become root and then runs a program that tries do so something with the X server, the following error messages (or something similar) are usually seen: Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server This happens because of an X security mechanism, which uses "magic cookies" stored in a file in the user's home directory (readable only by the user) called .Xauthority. If the environment variable XAUTHORITY is not set (see below), X clients attempt to authenticate themselves by using the .Xauthority file found in the directory specified by the HOME environment variable. Of course, if user "branden" is running the X session, and he then uses su to become root, $HOME will be "/root" instead of "/home/branden", and the correct .Xauthority file will not be found (even if there is an .Xauthority file in /root, it will not contain the correct magic cookies unless the root user has deliberately made it that way). There are therefore a number of ways to solve this problem. If only one user ever becomes root, and if root never starts an X session, there is a one-step, permanent solution (provided you don't rearrange your filesystem). Become root, then: cd ln -s /home/branden/.Xauthority .Xauthority Of course, you will want to replace "branden" in the above example with the name of whatever user has access to the root account. Alternatively, and more appropriate for more complex situations than the one described above, is simply issue commands while root that will tell the X clients where to look for the .Xauthority file. If you set the XAUTHORITY environment variable to the path to the appropriate user .Xauthority file. If the su command is used, all of the environment of the invoking user is inherited except for $PATH; therefore, each user who has access to the root account could set the XAUTHORITY variable in their shell startup files, and this variable will be passed to the root shell. Other alternatives include modifying the root shell startup files to sense the invoking user and setting XAUTHORITY, making command aliases that set that variable for the invocation of specific commands, or configuring the super or sudo programs with appropriate rules. The most straightforward method (but not the one that requires the least typing), is simply to set XAUTHORITY with each command you issue as root that needs to access the X server. For Bourne-type shells (sh, bash, ksh, zsh): XAUTHORITY=/home/branden/.Xauthority xeyes For C-shell-type shells (csh, tcsh): ( setenv XAUTHORITY /home/branden/.Xauthority; xeyes ) Finally, you should NEVER, EVER use the xhost command to manage X server access control unless you know exactly what you are doing (even then, there's hardly ever a good reason short of seeing just how many ways the security of your system can be compromised). Use the xauth command instead; the EXAMPLES section of its manual page is instructive for the most common tasks. *) How do I change xterm's default terminal type or key bindings? Most people ask this question because they are unhappy with the Debian default terminal type, "xterm-debian", and/or because they dislike the Debian default sequences generated by the backspace and/or delete keys. The short answer is that these changes are unfortunate necessities owing to changes in xterm's behavior since X11R6 was released. The long answers can be found at the X Strike Force page, with occasional reference to the XTERM FAQ (URL's for both are at the top of this document). If you have decided that you indeed want to change these defaults, even understanding why they were chosen in the first place, see /usr/doc/xterm/README.Debian. *) How do I keep my mouse from going crazy (or going away) when switching between X and the Linux virtual console? If your mouse behaves erratically (or the mouse cursor goes away entirely) after switching back to a virtual console after starting X, and/or the gpm program spews messages about errors in the mouse protocol to your system logs when you switch, you may need to set up gpm as a repeater, and instruct the X server (via the /etc/X11/XF86Config file) to use the /dev/gpmdata device file as its mouse device. The gpm program documentation has more information about this. Alternatively, if this does not work or if you do not feel you need the mouse in text mode, simply remove or disable the gpm program. (If you have package dependencies on your system that prevent removal of the gpm package itself, you can always prevent it from starting at boot by renaming its init script, as described above in the question about disabling xdm.) Branden Robinson, 13 June 1998
pgpjsl3etqzOg.pgp
Description: PGP signature
