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.

If your system doesn't run X-Windows, you
may miss the mouse support that makes interactive programs so easy
to use. gpm, the general purpose
mouse server, is designed with you in mind. Instead of having a
multitude of mouse drivers, several from each mouse vendor, some
that work well, others that don't, you can run gpm, which can talk
to all mice, and works quite well. This article explains how to set
up gpm to work with your mouse and programs, and also explains how
to set up your text console to work the best for you.

The gpm program is derived from the older
selection program, which was
solely for cut-and-paste on the Linux console. gpm acts like
selection until a client requests
mouse events. Because gpm manages each console as an independent
entity, you can use your multi-console text screen like a
multi-window graphic environment. This article refers to
gpm-1.0.

Configuring the Mouse Device

One major problem with Linux is hardware compatibility, and
the mouse is no exception. Companies are always releasing new mice,
and each of them provides a different mouse driver for DOS. Linux
users are left alone with their device and no driver. Fortunately,
companies tend to converge on a few “standard” protocols, which
are supported by both XFree86 and gpm. Moreover, the gpm package
includes gpm-test, which can help
in detecting your own mouse port and protocol, and which suggests
which command-line options you should use to invoke the
daemon.

You must provide the protocol name and options to gpm on the
command line, together with your own preferences. These will affect
all mouse response until the server dies. One preference allows
button reordering: left-handed people can reorder the buttons by
using the command line option -B 321, and owners
of two-button devices can use -B 132 to use the
right button as if it were the middle one, a useful way to paste
the cut-buffer in Emacs without modifying Emacs itself. The current
version of the gpm server duplicates the functionality of both
mconv2 and
MultiMouse, and can act as a
“repeater”. You can merge the events from two different devices
and pass them along to the X server. This is useful if you use a
laptop with both an internal pointer and an external mouse. If
you'd like to use one mouse in each hand but keep the internal
trackball active, however, gpm can't help you—no more than two
mouse devices can be read at a time.

The “repeater” option is automatically enabled if you read
two mice, but can be triggered independently; if you use gpm as a
repeater, the X server can be configured to read
/dev/gpmdata, a fifo named pipe, where gpm puts
mouse packets received while the console is in graphic mode. This
option is meant to be used by owners of busmice who want to
multiplex text-only and X operation without killing and restarting
the daemon. Owners of new dual-mode mice, which run the
three-button protocol only if the middle button is kept down at
mouse initialization, will enjoy it as well, because the device is
initialized only at boot time.

How Does gpm Work?

The core of the gpm daemon is currently built around the
select()system call and the process runs in the
user space of the systems memory. The main loop of the daemon
listens to a Unix-domain socket and to the mouse, and uses them in
conjunction to multiplex event retrieval and management of new
clients. The main loop of gpm can be (and has been) used to build a
concurrent daemon for network services by modifying just a few
details.

The choice of a user-space server for the mouse was
originally meant to help owners of low-end boxes—the process
could be swapped out when not in use and thus save a little
precious memory. Unfortunately, when you use Emacs, a perceptible
delay in delivery of mouse events can severely degrade performance,
and combined use of mouse and keyboard is completely unreasonable
on a slightly loaded machine.

The swap-in delay can be removed by locking the process in
memory, but in the case of Emacs two processes should be locked in
memory. The goal for gpm-2.0, which will
supersede the current version, is to provide the choice between a
user process and a kernel module. The advantage of running a kernel
module is mainly fewer context-switches (and no swap-in delay
whatsoever), while the main disadvantage is the waste of memory.
The module alternative will offer the same interface to client
applications, but will use a device node instead of a
socket.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.