Chapter 14: A Brief Survey of the Linux Desktop and Printing
This chapter is a quick introduction to the components found in a typical Linux desktop system. Of all of the different kinds of software on Linux systems, the desktop arena is one of the wildest and most colorful, because there are so many environments and applications from which to choose, and most distributions make it relatively easy for you to try them out.
Unlike other parts of a Linux system, such as storage and networking, creating a desktop structure doesn’t involve an extensive hierarchy of layers. Instead, each component performs a specific task, communicating with other components as necessary. Some components do share common building blocks (in particular, libraries for graphical toolkits), and you can think of those as simple abstraction layers, but that’s about as deep as it goes.
This chapter offers a high-level discussion of desktop components in general, but we’ll look at two pieces in a little more detail: the core infrastructure behind most desktops, and D-Bus, an interprocess communication p. 348 service used in many parts of the system. We’ll limit the hands-on discussion and examples to a few diagnostic utilities that, although not terribly useful day to day (most GUIs don’t require you to enter shell commands in order to interact with them), will help you understand the underlying mechanics of the system and perhaps provide some entertainment along the way. We’ll also take a quick look at printing, as desktop workstations often share a common printer.
14.1 Desktop Components
Linux desktop configurations offer a great deal of flexibility. Most of what the Linux user experiences (the “look and feel” of the desktop) comes from applications or building blocks of applications. If you don’t like a particular application, you can usually find an alternative. And if what you’re looking for doesn’t exist, you can write it yourself. Linux developers tend to have a wide variety of preferences for how a desktop should act, which makes for a lot of choices.
In order to work together, all applications need to have something in common. At the time of this writing, the core of the Linux desktop is in a transitional state. From the beginning until recently, Linux desktops used X (X Window System, also known as Xorg, after its maintaining organization). However, this is now changing; many distributions have transitioned to a software set based on the Wayland protocol to build a windowing system.
To understand what’s driving this change in the underlying technology, let’s take a step back and look at a few graphics basics.
14.1.1 Framebuffers
At the bottom of any graphical display mechanism is the framebuffer, a chunk of memory that the graphics hardware reads and transmits to the screen for display. A few individual bytes in the framebuffer represent each pixel of the display, so the idea is that if you want to change the way something looks, you need to write new values to the framebuffer memory.
One problem that a windowing system must solve is how to manage writing to the framebuffer. On any contemporary system, windows (or sets of windows) belong to individual processes, doing all of their graphics updates independently. So if the user is allowed to move windows around and overlap some on top of others, how does an application know where to draw its graphics, and how do you make sure that one application isn’t allowed to overwrite the graphics of other windows?
14.1.2 The X Window System
The approach that the X Window System takes is to have a server (called the X server) that acts as a sort of “kernel” of the desktop to manage everything from rendering windows to configuring displays to handling input from devices, such as keyboards and mice. The X server doesn’t dictate the way anything should act or appear. Instead, X client programs handle the p. 349 user interface. Basic X client applications, such as terminal windows and web browsers, make connections to the X server and ask to draw windows. In response, the X server figures out where to place the windows and where to render client graphics, and it takes a certain amount of responsibility for rendering graphics to the framebuffer. The X server also channels input to a client when appropriate.
Because it acts as an intermediary for everything, the X server can be a significant bottleneck. In addition, it includes a lot of functionality that’s no longer used, and it’s also quite old, dating back to the 1980s. Somehow, it has been flexible enough to accommodate many new features that have extended its lifespan. We’ll describe the basics of how to interact with the X Window System later in this chapter.
14.1.3 Wayland
Unlike X, Wayland is significantly decentralized by design. There’s no large display server managing the framebuffer for a number of graphical clients, and there’s no centralized authority for rendering graphics. Instead, each client gets its own memory buffer (think of this as sort of a sub-framebuffer) for its own window, and a piece of software called a compositor combines all of the clients’ buffers into the necessary form for copying to the screen’s framebuffer. Because there is normally hardware support for this task, the compositor can be quite efficient.
In some ways, the graphics model in Wayland isn’t too different from the practice that most X clients have been performing for years. Instead of getting any assistance from the X server, most clients render all of their own data as a bitmap and then send the bitmap to the X server. To acknowledge this somewhat, X has a compositing extension that has been in use for several years now.
For the task of channeling input to the correct application, most Wayland setups and many X servers use a library called libinput to standardize events to clients. This library is not required by the Wayland protocol, but on desktop systems, it’s nearly universal. We’ll discuss libinput in Section 14.3.2.
14.1.4 Window Managers
A major difference between X and Wayland systems is in the window manager, the piece of software that determines how to arrange windows on the screen and is central to the user experience. In X, the window manager is a client that acts as a helper to the server; it draws the windows’ decorations (such as title bars and close buttons), handles input events to those decorations, and tells the server where to move windows.
However, in Wayland, the window manager is the server, more or less. It is responsible for compositing all of the client window buffers into the display framebuffer, and it handles the channeling of input device events. As a result, it is required to do more work than a window manager in X, but much of that code can be common between window manager implementations.
Many window manager implementations exist in both systems, but X has far more by virtue of its longevity. However, most of the popular window managers, such as Mutter (in GNOME) and Kwin (from KDE) have also been extended to include Wayland compositing support. Regardless of the underlying technology, it’s not likely that there will ever be a standard Linux window manager; because user tastes and requirements are diverse and constantly changing, new window managers appear all the time.
14.1.5 Toolkits
Desktop applications include certain common elements, such as buttons and menus, called widgets. To speed up development and provide a common look, programmers use graphical toolkits to provide those elements. On operating systems like Windows or macOS, the vendor provides a common toolkit, and most programmers use that. On Linux, the GTK+ toolkit is one of the most common, but you’ll also frequently see widgets built on the Qt framework and others.
Toolkits usually consist of shared libraries and support files, such as images and theme information.
14.1.6 Desktop Environments
Although toolkits provide the user with a uniform outward appearance, some details of a desktop require a degree of cooperation between different applications. For example, one application may wish to share data with another or update a common notification bar on a desktop. To provide for those needs, toolkits and other libraries are bundled into larger packages called desktop environments. GNOME, KDE, and Xfce are some common Linux desktop environments.
Toolkits are at the core of most desktop environments, but to create a unified desktop, environments must also include numerous support files, such as icons and configurations, that make up themes. All of this is bound together with documents that describe design conventions, such as how application menus and titles should appear and how applications should react to certain system events.
14.1.7 Applications
At the top of the desktop are applications, such as web browsers and the terminal window. X applications can range from crude (such as the ancient xclock program) to complex (such as the Chrome web browser and LibreOffice suite). These applications normally stand alone, but they often use interprocess communication to become aware of pertinent events. For example, an application can express interest when you attach a new storage device or when you receive new email or an instant message. This communication usually occurs over D-Bus, described in Section 14.5.
14.2 Are You Running Wayland or X?
As we start with our hands-on discussion, you need to determine which graphical system you have. Just open a shell and check the value of the $WAYLAND_DISPLAY environment variable. If the value is something like wayland-0, you’re running Wayland. If it’s not set, you’re running X (probably; there are exceptions, but you’re not likely to come across them with this test).
These two systems are not mutually exclusive. If your system uses Wayland, it is also probably running an X compatibility server. It’s also possible to start a Wayland compositor inside X, but that can get a little strange (more on this later).
14.3 A Closer Look at Wayland
We’ll start with Wayland because it’s the emerging standard, currently used by default on many distributions. Unfortunately, in part due to its design and young age, there aren’t as many tools for prodding into Wayland as there are for X. We’ll do what we can.
But first, let’s talk about what Wayland is and isn’t. The name Wayland refers to a communications protocol between a compositing window manager and graphical client program. If you go looking for a big Wayland core package, you won’t find one, but you will find the Wayland library that most clients use to speak to the protocol (at least for now).
There’s also a reference compositing window manager called Weston and a few associated clients and utilities. What reference means here is that Weston contains the necessary functionality of a compositor, but it’s not meant for use by the general public because it has a bare-bones interface. The idea is that developers of compositing window managers can look at the Weston source code to see how to implement critical functions correctly.
14.3.1 The Compositing Window Manager
Odd as it might sound, you might not know which Wayland compositing window manager you’re actually running. You might be able to find the name from an information option in the interface, but there’s no set place to look. However, you can nearly always find the running compositor process by tracking down the Unix domain socket that it uses to communicate with clients. The socket is the display name in the WAYLAND_DISPLAY environment variable, which is usually wayland-0 and typically found in /run/user/<uid>, where <uid> is your user ID (if not, check the $XDG_RUNTIME_DIR environment variable). Running as root, you can find the process listening on this socket with the ss command, but the output will look a little crazy:
# ss -xlp | grep wayland-
u_str LISTEN 0 128
/run/user/1000/wayland-0 755881
* 0 users:(("gnome-shell",pid=1522,fd=30),("gnome-
shell",pid=1522,fd=28))
However, you just need to pick through it; you can see here that the compositor process is gnome-shell, PID 1522. Unfortunately, yet another layer of indirection is going on here; the GNOME shell is a plug-in of Mutter, which is the compositing window manager used in the GNOME desktop environment. (Here, calling the GNOME shell a plug-in is just a fancy way of saying that it calls Mutter as a library.)
One of the more unusual aspects of Wayland systems is the mechanism for drawing window decorations, such as title bars. In X, the window manager did it all, but in the initial implementations of Wayland, this was left up to the client applications, which sometimes led to windows having many different kinds of decorations on the same screen. Now there’s a part of the protocol called XDG-Decoration that allows the client to negotiate with the window manager to see if the window manager is willing to draw decorations.
In the context of a Wayland compositor, you can think of the display as the viewable space, represented by the framebuffer. A display can span more than one monitor if more than one is connected to a computer.
Although it’s rare, you can run more than one compositor at once. One way to do this is to run compositors on separate virtual terminals. In this case, the first compositor would normally have the display name set to wayland-0, the second wayland-1, and so on.
You can gain a bit of insight into your compositor with the weston-info command, which shows a few characteristics of the interfaces that the compositor has available. However, you shouldn’t expect very much beyond information on your display and some input devices.
14.3.2 libinput
In order to get the input from devices, such as a keyboard, from the kernel to clients, a Wayland compositor needs to collect that input and direct it to an appropriate client in a standardized form. The libinput library includes the support necessary to collect the input from the various /dev/input kernel devices and massage them. In Wayland, the compositor doesn’t usually just pass an input event as is; it translates the event into the Wayland protocol before sending to a client.
Normally, something like libinput wouldn’t be terribly interesting to talk about, but it comes with a small utility, also called libinput, that allows you to inspect input devices and events as they are presented by the kernel.
Try the following to look at the available input devices (you’ll probably get a lot of output, so be prepared to page through it):
# libinput list-devices
--snip--
Device: Cypress USB Keyboard
Kernel: /dev/input/event3
Group: 6
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
--snip--
In this partial view, you can see the type of device (keyboard) and where the kernel evdev device is (/dev/input/event3). That device shows up when you listen for events like this:
# libinput debug-events --show-keycodes
-event2 DEVICE_ADDED Power Button seat0 default
group1 cap:k
--snip--
-event5 DEVICE_ADDED Logitech T400 seat0 default
group5 cap:kp left scroll-nat scroll-button
-event3 DEVICE_ADDED Cypress USB Keyboard seat0 default
group6 cap:k
--snip--
event3 KEYBOARD_KEY +1.04s KEY_H (35) pressed
event3 KEYBOARD_KEY +1.10s KEY_H (35) released
event3 KEYBOARD_KEY +3.06s KEY_I (23) pressed
event3 KEYBOARD_KEY +3.16s KEY_I (23) released
When you run this command, move the mouse pointer around and press some keys. You’ll get some output describing these events.
Remember that the libinput library is just a system for capturing kernel events. As such, it is used not only under Wayland, but also under the X Window System.
14.3.3 X Compatibility in Wayland
Before discussing the X Window System in general, let’s first explore its compatibility with Wayland. There are countless applications for X, and any effort to move from it to Wayland would be greatly hindered by a lack of X support. There are two simultaneous approaches to bridge the gap.
The first approach is to add Wayland support to the application, creating a native Wayland application. Most graphical applications that run on X already use toolkits such as the ones found in GNOME and KDE. Because the work of adding Wayland support to these toolkits has already been done, it’s not much of a stretch to make an X application into a native Wayland application. In addition to paying attention to support for window decorations and input device configuration, a developer need only deal with the rare stray X library dependencies in an application. For many major applications, this work is already complete.
The alternative is to run an X application through a compatibility layer in Wayland. This is accomplished with an entire X server running as a Wayland client. Called Xwayland, this server is really just another layer jammed underneath X clients, run by default by most compositor startup sequences. The Xwayland server needs to translate input events and maintain its window buffers separately. Introducing another middleman like this always slows things down slightly, but it’s mostly inconsequential.
Going in reverse doesn’t work as well. You can’t run Wayland clients on X in the same way (theoretically, it’s possible to write such a system, but there’s not much point). However, you can run a compositor inside an X window. For example, if you’re running X, you can just run weston on the command line to bring up a compositor. You can open a terminal window and any other Wayland app inside, and you can even run X clients inside the compositor if you’ve started Xwayland properly.
However, if you leave this compositor running and go back to your regular X session, you might find that certain utilities don’t work as you expected, and they might also show up in the compositor window when you expected them to show up as an X window. The reason for this is that many applications on systems such as GNOME and KDE are now built with both X and Wayland support. They will look for a Wayland compositor first, and by default, the code in libwayland that looks for a display defaults to wayland-0 if the WAYLAND_DISPLAY environment variable isn’t set. An application that finds a working compositor will use it if it can.
The best way to avoid this is simply not to run a compositor inside X or at the same time as an X server.
14.4 A Closer Look at the X Window System
In contrast with Wayland-based systems, the X Window System (http://www.x.org/) has historically been very large, with the base distribution including the X server, client support libraries, and clients. Due to the emergence of desktop environments such as GNOME and KDE, the role of X has changed over time, with the focus now more on the core server that manages rendering and input devices, as well as a simplified client library.
The X server is easy to identify on your system. It’s called X or Xorg. Check for it in a process listing; you’ll usually see it running with a number of options like this:
Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7
-novtswitch
The :0 shown here is called the X display, an identifier representing one or more monitors that you access with a common keyboard and/or mouse. Usually, the display just corresponds to the single monitor attached to your computer, but you can put multiple monitors under the same display. For processes running under an X session, the DISPLAY environment variable is set to the display identifier.
Displays can be further subdivided into screens, such as :0.0 and :0.1, but this is quite rare because X extensions like RandR can combine multiple monitors into one larger virtual screen.
On Linux, an X server runs on a virtual terminal. In this example, the vt7 argument shows that it’s been told to run on /dev/tty7 (normally, the p. 355 server starts on the first virtual terminal available). You can run more than one X server at a time on Linux by running them on separate virtual terminals, with each server having a unique display identifier. You can switch between the servers with the CTRL-ALT-FN keys or the chvt command.
14.4.1 Display Managers
You normally wouldn’t start the X server on the command line, because starting the server doesn’t define any clients that are supposed to run on it. If you start the server by itself, you’ll just get a blank screen. Instead, the most common way to start an X server is with a display manager, a program that starts the server and puts a login box on the screen. When you log in, the display manager starts a set of clients, such as a window manager and file manager, so that you can start to use the machine.
Many different display managers are available, such as gdm (for GNOME) and kdm (for KDE). The lightdm in the argument list for the preceding X server invocation is a cross-platform display manager meant to be able to start GNOME or KDE sessions.
If you insist on starting an X session from a virtual console instead of using a display manager, you can run the startx or xinit command. However, the session you get will likely be a very simple one that looks completely unlike that of a display manager, because the mechanics and startup files are different.
14.4.2 Network Transparency
One feature of X is network transparency. Because clients talk to the server using a protocol, it’s possible to run clients across a network to a server running on a different machine directly over the network, with the X server listening for TCP connections on port 6000. Clients connecting to that port could authenticate and then send windows to the server.
Unfortunately, this method doesn’t normally offer any encryption and is insecure as a result. To close this hole, most distributions now disable the X server’s network listener (with the -nolisten tcp option to the server). However, you can still run X clients from a remote machine with SSH tunneling, as described in Chapter 10, by connecting the X server’s Unix domain socket to a socket on the remote machine.
There is no simple way to run remotely with Wayland, because clients have their own screen memory that the compositor must access directly in order to display. However, many emerging systems, such as RDP (Remote Desktop Protocol), can work in conjunction with the compositor to provide remote functionality.
14.4.3 Ways of Exploring X Clients
Although one doesn’t normally think of working with a graphical user interface from the command line, several utilities allow you to explore the parts of the X Window System. In particular, you can inspect clients as they run.
One of the simplest tools is xwininfo. When run without any arguments, it asks you to click on a window:
$ xwininfo
xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
After you click, it prints a list of information about the window, such as its location and size:
xwininfo: Window id: 0x5400024 "xterm"
Absolute upper-left X: 1075
Absolute upper-left Y: 594
--snip--
Notice the window ID here. The X server and window managers use this identifier to keep track of windows. To get a list of all window IDs and clients, use the xlsclients -l command.
14.4.4 X Events
X clients get their input and other information about the state of the server through a system of events. X events work like other asynchronous interprocess communication events, such as udev events and D-Bus events. The X server receives information from a source, such as an input device, and then redistributes that input as an event to any interested X client.
You can experiment with events via the xev command. Running it opens a new window that you can mouse into, click, and type. As you do so, xev generates output describing the X events that it receives from the server. For example, here’s sample output for mouse movement:
$ xev
--snip--
MotionNotify event, serial 36, synthetic NO, window 0x6800001,
root 0xbb, subw 0x0, time 43937883, (47,174), root:(1692,486),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 36, synthetic NO, window 0x6800001,
root 0xbb, subw 0x0, time 43937891, (43,177), root:(1688,489),
state 0x0, is_hint 0, same_screen YES
Notice the coordinates in parentheses. The first pair represents the x- and y-coordinates of the mouse pointer inside the window, and the second (root:) is the location of the pointer on the entire display.
Other low-level events include keypresses and button clicks, but more advanced ones indicate whether the mouse has entered or exited the window, or whether the window has gained or lost focus from the window manager. For example, here are corresponding exit and unfocus events.
LeaveNotify event, serial 36, synthetic NO, window 0x6800001,
root 0xbb, subw 0x0, time 44348653, (55,185), root:(1679,420),
mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
focus YES, state 0
FocusOut event, serial 36, synthetic NO, window 0x6800001,
mode NotifyNormal, detail NotifyNonlinear
One common use of xev is to extract keycodes and key symbols for different keyboards when remapping the keyboard. Here’s the output from pressing the L key; the keycode here is 46:
KeyPress event, serial 32, synthetic NO, window 0x4c00001,
root 0xbb, subw 0x0, time 2084270084, (131,120), root:(197,172),
state 0x0, keycode 46 (keysym 0x6c, l), same_screen YES,
XLookupString gives 1 bytes: (6c) "l"
XmbLookupString gives 1 bytes: (6c) "l"
XFilterEvent returns: False
You can also attach xev to an existing window ID with the -id id option. Replace id with the ID you get from xwininfo (it will be a hexadecimal number starting with 0x).
14.4.5 X Input and Preference Settings
One of the most potentially baffling characteristics of X is that there’s often more than one way to set preferences, and some methods may not work. For example, one common keyboard preference on Linux systems is to remap the CAPS LOCK key to a CTRL key. There are a number of ways to do this, from making small adjustments with the old xmodmap command to providing an entirely new keyboard map with the setxkbmap utility. How do you know which one (if any) to use? It’s a matter of knowing which pieces of the system have responsibility, but determining this can be difficult. Keep in mind that a desktop environment may provide its own settings and overrides. With this said, here are a few pointers on the underlying infrastructure.
Input Devices (General)
The X server uses the X Input Extension to manage input from many different devices. There are two basic types of input device—keyboard and pointer (mouse)—and you can attach as many devices as you like. To handle more than one of the same type of device simultaneously, the X Input Extension creates a virtual core device that funnels device input to the X server.
To see the device configuration on your machine, run the xinput --list command:
$ xinput --list
∣ Virtual core pointer id=2 [master pointer (3)]
∣ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
∣ ↳ Logitech Unifying Device id=8 [slave pointer (2)]
⌊ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Cypress USB Keyboard id=9 [slave keyboard (3)]
Each device has an associated ID that you can use with xinput and other commands. In this output, IDs 2 and 3 are the core devices, and IDs 8 and 9 are the real devices. Notice that the power buttons on the machine are also treated as X input devices.
Most X clients listen for input from the core devices, because there’s no reason for them to be concerned about which particular device initiates an event. In fact, most clients know nothing about the X Input Extension. However, a client can use the extension to single out a particular device.
Each device has a set of associated properties. To view the properties, use xinput with the device number:
$ xinput --list-props 8
Device 'Logitech Unifying Device. Wireless PID:4026':
Device Enabled (126): 1
Coordinate Transformation Matrix (128): 1.000000, 0.000000, 0.000000,
0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (256): 0
Device Accel Constant Deceleration (257): 1.000000
Device Accel Adaptive Deceleration (258): 1.000000
Device Accel Velocity Scaling (259): 10.000000
--snip--
You can change a number of properties with the --set-prop option. See the xinput(1) manual page for more information.
Mouse
You can manipulate device-related settings with the xinput command, and many of the most useful options pertain to the mouse (pointer). You can change many settings directly as properties, but it’s usually easier with the specialized --set-ptr-feedback and --set-button-map options to xinput. For example, if you have a three-button mouse at dev on which you’d like to reverse the order of buttons (this is handy for left-handed users), try this:
$ xinput --set-button-map dev 3 2 1
Keyboard
The many different keyboard layouts available internationally present particular difficulties for integration into any windowing system. X has always had an internal keyboard-mapping capability in its core protocol that you can manipulate with the xmodmap command, but any halfway recent system uses XKB (the X keyboard extension) to gain finer control.
XKB is complicated, so much so that many people still use xmodmap when they need to make quick changes. The basic idea behind XKB is that you can define a keyboard map, compile it with the xkbcomp command, and then load and activate that map in the X server with the setxkbmap command. This system has two especially interesting features:
- You can define partial maps to supplement existing maps. This is particularly handy for tasks such as changing your CAPS LOCK key into a CTRL key, and it is used by many graphical keyboard preference utilities in desktop environments.
- You can define individual maps for each attached keyboard.
Desktop Background
The root window of your X server is the background of the display. The old X command xsetroot allows you to set the background color and other characteristics of the root window, but it has no effect on most machines because the root window is never visible. Instead, most desktop environments place a big window in the back of all of your other windows in order to enable features such as “active wallpaper” and desktop file browsing. There are ways to change the background from the command line (for example, with the gsettings command in some GNOME installations), but if you actually want to do this, you probably have too much time on your hands.
xset
Probably the oldest preference command is xset. It’s not used much anymore, but you can run a quick xset q to get the status of a few features. Perhaps the most useful are the screensaver and Display Power Management Signaling (DPMS) settings.
14.5 D-Bus
One of the most important developments to come out of the Linux desktop is the Desktop Bus (D-Bus), a message-passing system. D-Bus is important because it serves as an interprocess communication mechanism that allows desktop applications to talk to each other, and because most Linux systems use it to notify processes of system events, such as inserting a USB drive.
D-Bus itself consists of a library that standardizes interprocess communication with a protocol and supporting functions for any two processes to talk to each other. By itself, this library doesn’t offer much more than a fancy version of normal IPC facilities, such as Unix domain sockets. What makes D-Bus useful is a central “hub” called dbus-daemon. Processes that need to react to events can connect to dbus-daemon and register to receive certain kinds of events. Connecting processes also create the events. For example, the process udisks-daemon monitors udev for disk events and sends them to dbus-daemon, which then retransmits the events to applications interested in disk events.
14.5.1 System and Session Instances
D-Bus has become an integral part of the Linux system, and it now reaches beyond the desktop. For example, both systemd and Upstart have D-Bus channels of communication. However, adding dependencies to desktop tools inside the core system goes against a design rule of Linux.
To address this problem, there are actually two kinds of dbus-daemon instances (processes) that can run. The first is the system instance, which is started by init at boot time with the --system option. The system instance usually runs as a D-Bus user, and its configuration file is /etc/dbus-1/system.conf (though you probably shouldn’t change the configuration). Processes can connect to the system instance through the /var/run/dbus/system_bus_socket Unix domain socket.
Independent of the system D-Bus instance is an optional session instance that runs only when you start a desktop session. Desktop applications that you run connect to this instance.
14.5.2 D-Bus Message Monitoring
One of the best ways to see the difference between system and session dbus-daemon instances is to monitor the events that go over the bus. Try using the dbus-monitor utility in system mode like this:
# dbus-monitor --system
signal sender=org.freedesktop.DBus -> dest=:1.952 serial=2 path=/org/
freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.952"
The startup message here indicates that the monitor connected and acquired a name. You shouldn’t see much activity when you run it like this, because the system instance usually isn’t very busy. To see something happen, try plugging in a USB storage device.
By comparison, session instances have much more to do. Assuming you’ve logged in to a desktop session, try this:
$ dbus-monitor --session
Now try using a desktop application, such as a file manager; if your desktop is D-Bus–aware, you should get a flurry of messages indicating various changes. Keep in mind that not all applications will produce messages.
14.6 Printing
Printing a document on Linux is a multistage process:
- The program doing the printing usually converts the document into PostScript form. This step is optional.
- The program sends the document to a print server.
- The print server receives the document and places it on a print queue. p. 361
- When the document’s turn in the queue arrives, the print server sends the document to a print filter.
- If the document is not in PostScript form, a print filter might perform a conversion.
- If the destination printer does not understand PostScript, a printer driver converts the document to a printer-compatible format.
- The printer driver adds optional instructions to the document, such as paper tray and duplexing options.
- The print server uses a backend to send the document to the printer.
The most confusing part of this process is why so much revolves around PostScript. PostScript is actually a programming language, so when you print a file using it, you’re sending a program to the printer. PostScript serves as a standard for printing in Unix-like systems, much as the .tar format serves as an archiving standard. (Some applications now use PDF output, but this is relatively easy to convert.)
We’ll talk more about the print format shortly, but first let’s look at the queuing system.
14.6.1 CUPS
The standard printing system in Linux is CUPS (http://www.cups.org/), which is the same system used on macOS. The CUPS server daemon is called cupsd, and you can use the lpr command as a simple client to send files to the daemon.
One significant feature of CUPS is that it implements the Internet Print Protocol (IPP), a system that allows for HTTP-like transactions among clients and servers on TCP port 631. In fact, if you have CUPS running on your system, you can probably connect to http://localhost:631/ to see your current configuration and check on any printer jobs. Most network printers and print servers support IPP, as does Windows, which can make setting up remote printers a relatively simple task.
You probably won’t be able to administer the system from the web interface, because the default setup isn’t very secure. Instead, your distribution likely has a graphical settings interface to add and modify printers. These tools manipulate the configuration files, normally found in /etc/cups. It’s usually best to let those tools do the work for you, because configuration can be complicated. Even if you do run into a problem and need to configure manually, it’s usually best to create a printer using the graphical tools so that you have somewhere to start.
14.6.2 Format Conversion and Print Filters
Many printers, including nearly all low-end models, do not understand PostScript or PDF. To support one of these printers, a Linux printing system must convert documents to a format specific to the printer. CUPS sends the document to a Raster Image Processor (RIP) to produce a bitmap. The RIP almost always uses the Ghostscript (gs) program to do most of the real p. 362 work, but it’s somewhat complicated, because the bitmap must fit the format of the printer. Therefore, the printer drivers that CUPS uses consult the PostScript Printer Definition (PPD) file for the specific printer to figure out settings such as resolution and paper sizes.
14.7 Other Desktop Topics
One interesting characteristic of the Linux desktop environment is that you can generally choose which pieces you want to use and stop using the ones that you dislike. For a survey of the many various desktop projects, have a look at the mailing lists and project links at https://www.freedesktop.org/.
Another major development in the Linux desktop is the Chromium OS open source project and its Google Chrome OS counterpart found on Chromebook PCs. This is a Linux system that uses much of the desktop technology described in this chapter but is centered on the Chromium/Chrome web browsers. Much of what’s found on a traditional desktop has been stripped away in Chrome OS.
Though desktop environments can be fun to look at and experiment on, we’ll need to leave the discussion here. However, if this chapter piqued your interest and you think you might like to work on them, you’ll need to know how developer tools work, which is where we’re headed next.