The Best Without X

Small computers, especially those with little memory, don't run the X Window System—or any other graphic environment—very smoothly. An intelligent keyboard configuration and use of the gpm mouse server will help you exploit your small Linux box to its fullest.
What's the Difference?

The first proposed approach requires no intervention on your side—you should invoke the gpm server and the gpm-root client only at bootup, which you're already supposed to do. The gpm-root client then takes care of it all. Actually, a console is created only by opening it, so little more than fork() and exec() is required. Cleaning up is performed when the child process dies.

The other approaches are explained in the documentation for kbd-0.90, and are slightly more difficult only in that you need to change your keyboard configuration again, run an extra daemon program, or retrieve an extra package—open isn't part of the kbd package. The extra effort is small, because all of the hard work is implemented in the kernel.

Changing the Text Mode

Older versions of Linux couldn't allow console resizing, and a single video mode should be used for the console from boot to shutdown, and it usually was the bare 80x25. Linux-95 (Linux-1.2) allows console resizing. The user program SVGATextMode, despite its cumbersome name, is a nice utility to change the appearance of your text console on-the-fly.

The tool makes use of the ioctl(VT_RESIZE) system call to change the way the video buffer is managed in the kernel, and modifies the internal registers in your video board in order to send the right signals to your monitor. The program must run with root permissions because both tasks are privileged. SVGATextMode isn't alone in the field of console resizing, but it currently is the most flexible choice.

Installing the program is easy—just make && make install. Then configure the file /etc/TextConfig—you need to tell SVGATextMode which chipset is in your video board. The TextConfig file is full of helpful comments.

The single tricky task is resequencing running applications to the new tty size. The configuration file provides a ResetProg line, where you can put a pathname of an executable file that will handle this; it will generally consist of sending SIGWINCH to applications, as outlined in the sample ResetProg.

The definitions for the specific modes are modeled on the XF86Config lines. The X-Windows configuration documentation and any previous experience with with X-Windows configuration can help in playing with text modes. If you're going to fine-tune your X-Windows screen, you can easily run your tests with SVGATextMode. Its fast cycle time makes trial-and-error better because you needn't restart the X server for each trial. Fine-tuning screen timings for text modes can lead to a good configuration to be pasted in your XF86Config file. Alternately, if you have set up X-Windows already, you can use that knowledge to set up SVGATextMode.

Other facilities offered by SVGATextMode are automatic font loading and cursor reshaping. This last feature alone is a good reason to run SVGATextMode on your laptop—no more kernel patch to have a block cursor.

Problems Related to Console Resizing

If you use SVGATextMode, especially on small machines, you'll notice that sometimes console resizing will fail, even if you have plenty of swap available, and sometimes even with plenty of RAM. The problem is related to the kind of memory needed; the kernel needs to complete the system call (an ioctl()) atomically, and it needs to get a contiguous chunk of memory for each active console. There's no time to swap out some process or to shrink the buffer cache, and the kernel keeps only 1/64 of the available RAM for these “urgent” issues. As a result, the smaller the box, the more consoles you use, the more you're prone to fail resizing. Resizing to a smaller estate won't always help, because the kernel must be sure to have place for all the active consoles before it starts copying video data to the new area, and only at the end can the old buffer be released. If it fails, simply try again; it will probably succeed the second time.

Another issue is the role of the ResetProg. Why do some applications do resize well (like jed), others become completely stuck (like selection) and still others need to be sent the SIGWINCH signal? Because a resizing of the surrounding window is an asynchronous event, which doesn't fit the normal environment of the application.

Applications belong to three types: over-attentive ones look at the window size often, and perceive the new situation right when it happens; more conventional applications wait for an asynchronous notification of the event (a signal, namely SIGWINCH, for WINdow CHange), and respond to the notification in the right way; and some applications simply don't respond to changes in window size, and ignore SIGWINCH---the current version of selection was written before console resizing was available. Thus, while a resizing xterm sends SIGWINCH by itself, a resizing console doesn't send anything, and an external ResetProg is needed to fill the gap.