The Best Without X
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.
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.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- Tech Tip: Really Simple HTTP Server with Python
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Returning Values from Bash Functions
- SuperTuxKart 0.9.2 Released
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide