By Jeremy Chatfield – Xi Graphics
Contents
PC displays using Linux and UNIX Systems
- Text
- SVGAlib
- X Window System
X Window System Capabilities
- Windows
- Graphics
- Text
- Sharing Information
Window Managers
- Where to place a new window?
- How to show the active window?
- Cut and Paste
- Look and Feel
Session Managers
- What are you running now?
- Would you like to see it again?
Input
- Keyboard
- Pointing device
- Other devices
Security
- Access
- Authentication
- Encryption
- Usurpation
X Server Summary
- Graphical device driver
- Input device handler
- Font handler
- Resource manager
- Property manager
- Authentication handler
- Access controller
PC displays using Linux and UNIX Systems
The display on a PC is capable of showing many things. In its’
most basic operation, you can use the display to show simple text.
At its’ most advanced, you can show multiple concurrent applications,
running from many machines connected by the Internet.
Text:
This is the default mode for current graphics boards. When the system
is powered up, the graphics board BIOS initializes the board to a mode
in which 80 column, 25 line text displays should be visible. The Video
BIOS also provides other modes, such as alternative text modes and
graphical modes. Text mode is often used for systems that need high
reliability and simple operation, such as Web Servers, Print Servers
and so on.
SVGAlib:
SVGAlib is a primarily Linux mechanism to allow a single application
to use graphical modes of the display adapter. There is no inherent
mechanism to permit two programs to concurrently share the display,
nor is there any inherent mechanism to accept network connections.
SVGAlib is most frequently used to offer full screen games.
Despite the direct access, and lack of competing programs, SVGAlib
is usually slower than a properly designed X Server. SVGAlib does not
offer “standard” windowing features such as back buffering, font-,Usurpation
pixel-, tile- and stipple-caches, and so on. Although these can be
added by the games programmer, it requires separate effort by each
development group and also needs significant investment in learning
about each chip, or the use of the simple Video operations provided
by the VESA BIOS.
X Window System:
Many computer users expressed a need for viewing concurrent
graphical output from several applications. Some of these
applications were only capable of running on supercomputers,
perhaps distributed around the world. These needs found their
expression in the work of a research group at MIT, partially
funded by DEC and later by other workstation vendors such as
Sun, IBM, HP and Silicon Graphics.
X is defined as a series of specifications and standards.
Testing kits are available, some freely, to ensure that components
of X conform to the specs and standards. There are also non-standard
contributed parts, which have no formal part of X, but which may be
used. The X developers have also made sample implementations available.
These samples are not reference code, and are not guaranteed to be
optimal, but they are freely available.
X was developed as a windowing system, with each application being
able to open one or more display windows across a network or using a
local connection. No specific hardware would be required, other than
some kind of graphics adapter, a keyboard and a pointing device.
Wherever possible, logically separable parts of graphical operations
were put into the care of separate programs. The Window Manager
handled window placement, and a Display Server offered controlled
use of graphical display services to client applications running
locally or remotely (on the same machine, or far across the network).
The X Window System was developed on and for workstations, and
for many years it was thought that PC’s would never be able to
offer a usable implementation of an X Display, though they might
be a home for simple client applications. Thomas Roell released
X386 in 1990 using the simple PC graphics boards that were
available. This work was enhanced for a few years, using
increasingly complex PC graphics boards and eventually X386
Display Servers were able to offer resolutions and speed that
matched those of the workstation vendors. X386 was a research
project, however, and while matching the speed of workstations,
it was quite unable to match total performance.
Thomas eventually relinquished the X386 research server, which
was taken up as the XFree86 project. Unfortunately the research
role of X386 has been lost, and little original research is
conducted with XFree86 Servers. Most of the advances in PC
UNIX X Server Technology are still being made by Thomas Roell
for Xi Graphics.
X Window System Capabilities
Many of the features of a modern PC were pioneered at the
Xerox Palo Alto Research Center (Xerox PARC). The Ethernet was
borne of PARC, as was the idea of using a mouse, windows, icons
and pop up menus.
Windows:
A Window is a region of the screen that is accessible to a
defined set of cooperating processes. Usually, only a single
program has access to the window, and may request precalculated
graphical objects (images), text or drawing operations to be
performed on the window, in a device independent manner.
Modern windowing systems usually offer non-rectangular (shaped)
windows, and may allow several processes or threads to affect the
contents of a single window.
A normal application window is really comprised of dozens or
even hundreds of windows. A push button is usually its’ own
window. A scroll bar may be implemented by a containing
window, a window for the elevator thumb and separate windows
for the scroll buttons at each end of the window. Additional
windows may be used within the scroll bar to provide 3D effects.
In X, all windows are children of a parent window. This mirrors
the hierarchical file system that you are probably familiar with.
Just like the file system, there is a parent of all parent windows,
known as the root window. An application has to create at least one
window that is a child of this root window, in order to be valid,
and can then create its’ own windows inside this.
Graphics:
A Windowing System handles two major categories of graphics.
An application can chew away at some data and produce an image
that the graphical system displays. No additional processing of the
image is possible or desirable. Examples of this include the popular
image viewer “xv” and many MPEG video players, which precalculate an
image, and then simply request that the prepared image is displayed.
The other major category are applications that request
graphical primitives, such as lines, boxes, arcs and fills for
points and regions of the window. These operations do nor result
in an image held within the application, but are a series of operations
that should show the same picture on every display, nonetheless. There
is considerable scope for improving the speed of these images by using
hardware acceleration, but there is also plenty of room to entirely
mess up the whole screen.
Text:
Curiously, text can be regarded as a special case of graphical
operations, with one additional feature. You have to select a font.
Most Windowing systems permit an extensible set of fonts to be
offered to applications, and any font component can be selected.
Some fonts are offered for a fixed size, and others may provide
“hints” that should allow them to be scaled.
As with graphical drawing, many speed improvements can be made.
Sharing Information:
Applications may need to share information, such as when something is
being marked for a cut and paste operation. Applications also need to
inform the Window Manager about their color preferences, and where
they’d like to be put on the screen. The windowing system has a set
of data that applications programmers should find useful, provided
the by the X Resource Database.
Windowing Systems usually offer mechanisms for applications
to share screen data, or other information. “Properties” are
accessible by other applications, and offer a slow method for
exchanging information between applications. These channels are
usually quite low bandwidth, and while they can be abused for
interprocess communication, it is usually better to use these
mechanisms for liaison, and to create an application specific
protocol for high bandwidth needs. Don’t use windowing system
message handling via properties for backups, for example.
Window Managers
Although confused with other elements in some implementations, the
placement of windows and their decoration has nothing to do with the
graphical device driver. In X, the Window Manager (WM) is just another
client of the X Display Server. It has two unusual properties. You can
only run one of them on each screen of a display, and other applications
must respect the decisions of this special client about window placement.
Where to place a new window?
When an application opens its first top level window, it must tell
the WM where it would like to be, and how big, and what colors it wants,
and so on. The conversation between the WM and the client is defined by
the ICCCM standard (Inter Client Control and Communication Manual).
This document does not currently extend to cover topics such as
Drag and Drop protocols.
How to show the active window?:
The WM decides how to show which window is active and accepting
keyboard input. Usually, the WM changes the color of the border frame
around the active window. The WM also decides whether to bring the
active window to the top of the stack when the pointer is over it,
or when the user activates the window by selecting it.
Cut and Paste:
The WM is often a part of cut and paste protocols, defining the
mouse buttons to be used, and sometimes in coordinating a liaison
between two applications.
Look and Feel:
The WM provides the first impression of the graphical environment,
and together with an associated widget set, is the source of “look
and feel”.
Session Managers
When you log in, it is nice to have your previously running
applications restarted, at the same place where you left off. X
provides a session manager specification, which can be integrated
with authentication and access control, so that you see the same
environment each time you login.
What are you running now?:
Interaction with the WM allows the Session Manager (SM) to identify
what programs are running and their screen placement. These snapshots
can be taken at any time.
Would you like to see it again?:
When you terminate a session, the WM can inform all clients,
which can then go into a mode where they record their current
activities. When the SM is restarted, it can restart the applications
with their save state data, so that they start up where you left off.
This mechanism usually also offers a fail safe mode, in case you saved
the state of something you’d prefer not to have saved…
Input
It makes little sense to assume that input devices will be remote
from the graphical display hardware, and all applications running on
that hardware should be given the opportunity to use it. X requires
a keyboard and pointing device, but permits additional devices to
be supported, such as joysticks and button boxes.
Keyboard:
Keyboards come in a wide variety of national language styles.
Mechanisms are available to map keyboard values to an appropriate
standardized representation. This permits a French “AZERTY” keyboard
user to successfully type at a program written by a “QWERTY” using
English speaker… so long as the English programmer has used
international character handling conventions.
Pointing device:
X usually assumes that you have a three button pointing device.
If you haven’t, the X Server can simulate the pressing of the middle
button, if you press both left and right buttons. This reduces you
ability to handle some applications that demand chorded buttons,
such as “control-middle-and-right”. Fortunately, these are quite
rare.
Other devices:
Digitizer tablets, touchscreens, joysticks and so on, can all
be used with the X Window System. There are standards to cover
their use, but each new device requires integration work, and
applications must be modified to select and use them.
Security
An issue of increasing importance in commercial computing,
security has been improved in X over the years. The two key
aspects of security are access control and authentication. Beyond
that, one may wish to conduct sessions that prevent eavesdropping
and that prevent someone else from usurping access.
Having been developed in an academic environment, and having
a primary role in enabling access to graphical services, the core
model of X is that all clients have equal access to the screen,
once authenticated. The access includes the ability to attach an
input only window to the screen (totally invisible), which captures
a copy of every keystroke, or to grab the contents of any displayed
window. This is obviously not very safe when confidential information
may be on screen, such as credit card information for an on-line
order.
Access:
Access control is centralized in the Display Server. Recent
standards now allow two predefined and site defined security levels.
Applications that connect to the Server are allocated to one of the
security groups, and may be restricted so that they can not learn the
contents of other windows. This permits untrustworthy applications to
use display services, while denying access to other screen contents,
or to the keyboard and other devices unless focused on that window.
Authentication:
The X Server permits extensible authentication mechanisms. Most
easily available authentication services are trivially simple.
The first level is offered by host based authentication. Using
this, connections are normally denied, unless that specific machine
is allow to form connections. This is obviously a problem if the
permitted machine accepts multiple users. Any of those users can
obtain access to keyboard output and screen contents, simply because
they use the same machine.
The next commonly offered mechanism is to provide a token,
exchanged between the client and Server. The Server compares this
with a local token for a match. The token is normally derived from
a copy kept in a file on the client system, so it is subject to any
file reading attacks, and it is transmitted in clear form during
initial connection dialogue with the client. This is, of course,
subject to net-snooping attacks.
More complex schemes, including card readers and various
forms of encrypted authentication information have been implemented
by various X developers, but none are in common use.
Encryption:
The TCP/IP connection between clients and Server are in plain
form. The X standards do not offer any encryption, but they do not
prevent encapsulating TCP/IP streams. There are several methods
offering authenticated and encrypted channels over the Internet,
probably the best known and most easily accessible being “ssh”.
Usurpation:
Security violations by obtaining someone elses’ access is common.
TCP/IP connections are subject to normal network attacks. X libraries
can be used to create attacks on superuser privileged clients, and
there are attacks based on using superuser privileged X Servers.
Correct design can reduce the risk, but the best defence is usually
to avoid the risk. This remains an area ripe for research!
X Server Summary
The X Server is core to operating the X Window System effectively.
It provides a wide range of functions, and must do so quickly, to
provide a usable user interface to graphical hardware and applications.
- Graphical device driver
- Input device handler
- Font handler
- Resource manager
- Property manager
- Authentication handler
- Access controller