[Commit] papers/xserver_ols2004 packard-graphics.tex, 1.1.1.1, 1.2 packard-history.tex, 1.1.1.1, 1.2 packard-input.tex, 1.1.1.1, 1.2 packard-modes.tex, 1.1.1.1, 1.2 packard-sharing.tex, 1.1.1.1, 1.2 packard.tex, 1.1.1.1, 1.2

[Keith Packard]

Committed by: keithp

Update of /local/src/CVS/papers/xserver_ols2004
In directory home.keithp.com:/tmp/cvs-serv23602

Modified Files:
	packard-graphics.tex packard-history.tex packard-input.tex 
	packard-modes.tex packard-sharing.tex packard.tex 
Log Message:
Fix address, em-dashes, enumeration and some wording errors found by Eric

Index: packard-graphics.tex
===================================================================
RCS file: /local/src/CVS/papers/xserver_ols2004/packard-graphics.tex,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -d -r1.1.1.1 -r1.2
--- a/packard-graphics.tex	10 Jun 2004 07:17:23 -0000	1.1.1.1
+++ b/packard-graphics.tex	10 Jun 2004 15:51:50 -0000	1.2
@@ -45,7 +45,7 @@
 provide DRI-like kernel functionality to support DMA and interrupts to
 enable efficient implementation of whatever useful operations the card does
 support.  For 2D graphics, the operations needing acceleration are those
-limited by memory bandwidth -- large area fills and copies.  In particular
+limited by memory bandwidth---large area fills and copies.  In particular
 acceleration of image composition results in dramatic performance
 improvements with minimal amounts of code.  The spectacular amounts of code
 written in the past that provide modest acceleration for corner cases in the
@@ -60,10 +60,10 @@
 smaller kernel driver would suffice for a ground-up implementation.
 
 In summary, graphics cards should be supported in one of two ways:
-
-1)	With an OpenGL-based X server
-2)	With a 2D-only X server based on a simple loadable driver API.
-
+\begin{enumerate}
+\item With an OpenGL-based X server
+\item With a 2D-only X server based on a simple loadable driver API.
+\end{enumerate}
 \subsection{Implications for Applications}
 
 None of the architectural decisions about the internal X server architecture

Index: packard-history.tex
===================================================================
RCS file: /local/src/CVS/papers/xserver_ols2004/packard-history.tex,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -d -r1.1.1.1 -r1.2
--- a/packard-history.tex	10 Jun 2004 07:17:23 -0000	1.1.1.1
+++ b/packard-history.tex	10 Jun 2004 15:51:50 -0000	1.2
@@ -26,8 +26,7 @@
 
 Graphics commands to the processor were queued to a shared DMA buffer.  The
 X server would block in the kernel waiting for space in the buffer when
-full.  This is similar to the architecture used by the DRI project for
-accelerated 3D graphics today.
+full.
 
 Keyboard and mouse support were provided by another shared memory queue
 between the kernel and X server.  Abstract event structures were constructed
@@ -78,10 +77,10 @@
 To ameliorate the poor mouse tracking, the X server was modified to receive
 a signal when input was present on the file descriptors and immediately
 process the input.  When supported, the hardware sprite would also be moved
-at this time, leading to dramatically improved tracking performance.  Still,
-the fact that the X server itself was responsible for connecting the mouse
-motion to the sprite location meant that under high CPU load, the sprite
-would noticeably lag the mouse.
+at this time, leading to improved tracking performance.  Still, the fact
+that the X server itself was responsible for connecting the mouse motion to
+the sprite location meant that under high CPU load, the sprite would
+noticeably lag the mouse.
 
 Kernel support for the keyboard consisted of a special mode setting which
 would transform the keyboard from an ASCII input device to reporting raw key
@@ -91,10 +90,7 @@
 
 Placing the entire graphics driver in user mode eliminated the need to write
 a kernel driver, but marginalized overall system performance by forcing the
-CPU to busy-wait for the graphics engine.  Placing responsibility for
-manging the sprite led to poor tracking, while requiring the X server to
-always reset the keyboard mode frequently resulted in an unusable system
-when X terminated abnormally.
+CPU to busy-wait for the graphics engine.
 
 Fixing the kernel to address these problems was never even considered; the
 problems didn't prevent the system from functioning, they only made it less
@@ -109,7 +105,7 @@
 system vendors.
 
 That these users managed to get X running on the early 386 hardware was an
-impressive feat, but that they had to do everything without any kernel
+impressive feat.  That they had to do everything without any kernel
 support only increased the difficulty.
 
 Early PC graphics cards were simple frame buffers as far as graphics
@@ -118,7 +114,7 @@
 be programmed to generate many different video timings.  Incorrect timings
 could destroy the monitor.
 
-Keyboard support in these early 386-based Unix systems was very much like
+Keyboard support in these early 386-based Unix systems was much like
 the Sun operating system; the keyboard was essentially a serial device and
 could be placed in a mode which translated key transitions into ASCII or
 placed a mode which would report the raw bytes emitted from the keyboard.
@@ -127,11 +123,11 @@
 there was latency here as the X server would not process them except when
 polling for input across all X clients and input devices.  As with the Sun
 driver, if the X server terminated without switching the keyboard back to
-translated mode, it would not be usable by the console.  This particular
-problem was eventually fixed in some kernels by adding special key sequences
+translated mode, it would not be usable for the console.  This particular
+problem was eventually kludged in Linux by adding special key sequences
 to reset the keyboard to translated mode.
 
-Mouse support really was just a kernel serial driver -- PS/2 mice didn't
+Mouse support really was just a kernel serial driver---PS/2 mice didn't
 exist, and so bus and serial mice were used.  The X server itself would open
 the device, configure the communication parameters and parse the stream of
 bytes.  As there was no hardware sprite support, the X server would also
@@ -144,9 +140,9 @@
 untranslated mode, so the user couldn't even operate the computer blind to
 reboot.
 
-This caused the X server to assume the same reliability requirements as the
-operating system kernel itself; bugs in the X server would render the system
-just as unusable as bugs in the kernel.
+The X server has assumed the same reliability requirements as the operating
+system kernel itself; bugs in the X server would render the system just as
+unusable as bugs in the kernel.
 
 \subsection{The Pit of Despair}
 
@@ -195,9 +191,14 @@
 device mappings, DMA and interrupt logic and even clean up the hardware when
 applications terminated abnormally.
 
-The result is a system which is stable in the face of broken applications,
-and provides high performance and low CPU overhead.
+All 3D commands are written to command buffers passed from the user
+application through the kernel to the device; the kernel can perform
+validation on the contents before queuing them for transfer to the
+graphics card.  In many ways, this system is similar to the old Dragon X
+server described above.
 
-However, the DRI environment remains reliant on the X server to manage video
-mode selection and basic device input.
+The result is a system which is stable in the face of broken applications,
+and provides high performance and low CPU overhead.  However, the DRI
+environment remains reliant on the X server to manage video mode selection
+and basic device input.
 

Index: packard-input.tex
===================================================================
RCS file: /local/src/CVS/papers/xserver_ols2004/packard-input.tex,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -d -r1.1.1.1 -r1.2
--- a/packard-input.tex	10 Jun 2004 07:17:23 -0000	1.1.1.1
+++ b/packard-input.tex	10 Jun 2004 15:51:50 -0000	1.2
@@ -22,7 +22,7 @@
 The first problem to attack is that of the current hodgepodge device support
 where the X server itself is responsible for parsing the raw bytestreams
 coming from the disparate input devices.  Fortunately, the kernel has
-already solved that problem--the new /dev/input based drivers provide a
+already solved that problem---the new /dev/input based drivers provide a
 uniform description of devices and standard interface to all.  Converting
 the X server over to those interfaces is straightforward.
 

Index: packard-modes.tex
===================================================================
RCS file: /local/src/CVS/papers/xserver_ols2004/packard-modes.tex,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -d -r1.1.1.1 -r1.2
--- a/packard-modes.tex	10 Jun 2004 07:17:23 -0000	1.1.1.1
+++ b/packard-modes.tex	10 Jun 2004 15:51:50 -0000	1.2
@@ -26,8 +26,8 @@
 Fast forward to 2004 when common video cards have two or more monitor
 connectors along with outputs for standard NTSC, SECAM or PAL video
 formats.  The desire to dynamically adjust the display environment to
-accommodate different use modes is well supported within the Macintosh
-and Microsoft environments, but the X window system has remained largely
+accommodate different use modes is well supported within the Apple OS X and
+Microsoft Windows environments, but the X window system has remained largely
 stuck with its 1984 legacy.
 
 \subsection{X Attempts to Fix Things}

Index: packard-sharing.tex
===================================================================
RCS file: /local/src/CVS/papers/xserver_ols2004/packard-sharing.tex,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -d -r1.1.1.1 -r1.2
--- a/packard-sharing.tex	10 Jun 2004 07:17:23 -0000	1.1.1.1
+++ b/packard-sharing.tex	10 Jun 2004 15:51:50 -0000	1.2
@@ -10,7 +10,7 @@
 
 \section{Migrating Devices}
 
-With X was developed, each display consisted of a single keyboard and mouse
+When X was developed, each display consisted of a single keyboard and mouse
 along with a fixed set of monitors.  That collection was used for a single
 login session, and the input devices never moved.  All of that has now
 changed; input devices come and go, computers get plugged into video
@@ -40,7 +40,7 @@
 \subsection{Hotplugging Video Hardware}
 
 While most systems have no ability to add or remove graphics cards, it's not
-unheard of--many handheld computers support CF video adapters.  On the other
+unheard of---many handheld computers support CF video adapters.  On the other
 hand, nearly all systems do support ``hotplugging'' of the actual display
 device or devices.  Many can even detect the presence or absence of a
 monitor enabling true auto-detection and automatic reconfiguration.

Index: packard.tex
===================================================================
RCS file: /local/src/CVS/papers/xserver_ols2004/packard.tex,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -d -r1.1.1.1 -r1.2
--- a/packard.tex	10 Jun 2004 07:17:23 -0000	1.1.1.1
+++ b/packard.tex	10 Jun 2004 15:51:50 -0000	1.2
@@ -43,15 +43,9 @@
 }
 
 \author{
-Keith Packard \\
-{\em Hewlett-Packard}\\
-{\em Cambridge Research Laboratory}\\
-{\tt\normalsize ~keithp at keithp.com}\\
-% \and
-% Second Author\\
-% {\em Second Institution}\\
-% {\tt\normalsize another at address.for.email.com}\\
-} % end author section
+Keith Packard\\
+\itshape{HP Cambridge Research Laboratory}\\
+\normalsize{\url{keithp at keithp.com}}}
 
 \maketitle