text:
Direct Rendering Manager

The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards. DRM exposes an API that user-space programs can use to send commands and data to the GPU and perform operations such as configuring the mode setting of the display. DRM was first developed as the kernel-space component of the X Server Direct Rendering Infrastructure, but since then it has been used by other graphic stack alternatives such as Wayland and standalone applications and libraries such as SDL2 and  Kodi.

User-space programs can use the DRM API to command the GPU to do hardware-accelerated 3D rendering and video decoding, as well as GPGPU computing.

Overview
The Linux kernel already had an API called fbdev, used to manage the framebuffer of a graphics adapter, but it couldn't be used to handle the needs of modern 3D-accelerated GPU-based video hardware. These devices usually require setting and managing a command queue in their own memory to dispatch commands to the GPU and also require management of buffers and free space within that memory. Initially, user-space programs (such as the X Server) directly managed these resources, but they usually acted as if they were the only ones with access to them. When two or more programs tried to control the same hardware at the same time, and set its resources each one in its own way, most times they ended catastrophically.

The Direct Rendering Manager was created to allow multiple programs to use video hardware resources cooperatively. The DRM gets exclusive access to the GPU and is responsible for initializing and maintaining the command queue, memory, and any other hardware resource. Programs wishing to use the GPU send requests to DRM, which acts as an arbitrator and takes care to avoid possible conflicts.

The scope of DRM has been expanded over the years to cover more functionality previously handled by user-space programs, such as framebuffer managing and mode setting, memory-sharing objects and memory synchronization. Some of these expansions were given specific names, such as Graphics Execution Manager (GEM) or kernel mode-setting (KMS), and the terminology prevails when the functionality they provide is specifically alluded. But they are really parts of the whole kernel DRM subsystem.

The trend to include two GPUs in a computer—a discrete GPU and an integrated one—led to new problems such as GPU switching that also needed to be solved at the DRM layer. In order to match the Nvidia Optimus technology, DRM was provided with GPU offloading abilities, called PRIME.

Software architecture
The Direct Rendering Manager resides in kernel space, so user-space programs must use kernel system calls to request its services. However, DRM doesn't define its own customized system calls. Instead, it follows the Unix principle of "everything is a file" to expose the GPUs through the filesystem name space, using device files under the  hierarchy. Each GPU detected by DRM is referred to as a DRM device, and a device file  (where X is a sequential number) is created to interface with it. User-space programs that want to talk to the GPU must open this file and use ioctl calls to communicate with DRM. Different ioctls correspond to different functions of the DRM API.

A library called libdrm was created to facilitate the interface of user-space programs with the DRM subsystem. This library is merely a wrapper that provides a function written in C for every ioctl of the DRM API, as well as constants, structures and other helper elements. The use of libdrm not only avoids exposing the kernel interface directly to applications, but presents the usual advantages of reusing and sharing code between programs.

DRM consists of two parts: a generic "DRM core" and a specific one ("DRM driver") for each type of supported hardware. DRM core provides the basic framework where different DRM drivers can register and also provides to user space a minimal set of ioctls with common, hardware-independent functionality. A DRM driver, on the other hand, implements the hardware-dependent part of the API, specific to the type of GPU it supports; it should provide the implementation of the remaining ioctls not covered by DRM core, but it may also extend the API, offering additional ioctls with extra functionality only available on such hardware. When a specific DRM driver provides an enhanced API, user-space libdrm is also extended by an extra library libdrm-driver that can be used by user space to interface with the additional ioctls.

API
The DRM core exports several interfaces to user-space applications, generally intended to be used through corresponding  wrapper functions. In addition, drivers export device-specific interfaces for use by user-space drivers and device-aware applications through ioctls and sysfs files. External interfaces include: memory mapping, context management, DMA operations, AGP management, vblank control, fence management, memory management, and output management.

DRM-Master and DRM-Auth
There are several operations (ioctls) in the DRM API that either for security purposes or for concurrency issues must be restricted to be used by a single user-space process per device. To implement this restriction, DRM limits such ioctls to be only invoked by the process considered the "master" of a DRM device, usually called DRM-Master. Only one of all processes that have the device node  opened will have its file handle marked as master, specifically the first calling the SET_MASTER ioctl. Any attempt to use one of these restricted ioctls without being the DRM-Master will return an error. A process can also give up its master role—and let another process acquire it—by calling the DROP_MASTER ioctl.

The X Server—or any other display server—is commonly the process that acquires the DRM-Master status in every DRM device it manages, usually when it opens the corresponding device node during its startup, and keeps these privileges for the entire graphical session until it finishes or dies.

For the remaining user-space processes there is another way to gain the privilege to invoke some restricted operations on the DRM device called DRM-Auth. It is basically a method of authentication against the DRM device, in order to prove to it that the process has the DRM-Master's approval to get such privileges. The procedure consists of:
 * The client gets a unique token—a 32-bit integer—from the DRM device using the GET_MAGIC ioctl and passes it to the DRM-Master process by whatever means (normally some sort of IPC; for example, in DRI2 there is a DRI2Authenticate request that any X client can send to the X Server.)
 * The DRM-Master process, in turn, sends back the token to the DRM device by invoking the AUTH_MAGIC ioctl.
 * The device grants special rights to the process file handle whose auth token matches the received token from the DRM-Master.

Graphics Execution Manager
Due to the increasing size of video memory and the growing complexity of graphics APIs such as OpenGL, the strategy of reinitializing the graphics card state at each context switch was too expensive, performance-wise. Also, modern Linux desktops needed an optimal way to share off-screen buffers with the compositing manager. These requirements led to the development of new methods to manage graphics buffers inside the kernel. The Graphics Execution Manager (GEM) emerged as one of these methods.

GEM provides an API with explicit memory management primitives. Through GEM, a user-space program can create, handle and destroy memory objects living in the GPU video memory. These objects, called "GEM objects", are persistent from the user-space program's perspective and don't need to be reloaded every time the program regains control of the GPU. When a user-space program needs a chunk of video memory (to store a framebuffer, texture or any other data required by the GPU), it requests the allocation to the DRM driver using the GEM API. The DRM driver keeps track of the used video memory and is able to comply with the request if there is free memory available, returning a "handle" to user space to further refer the allocated memory in coming operations. GEM API also provides operations to populate the buffer and to release it when it is not needed anymore. Memory from unreleased GEM handles gets recovered when the user-space process closes the DRM device file descriptor—intentionally or because it terminates.

GEM also allows two or more user-space processes using the same DRM device (hence the same DRM driver) to share a GEM object. GEM handles are local 32-bit integers unique to a process but repeatable in other processes, therefore not suitable for sharing. What is needed is a global namespace, and GEM provides one through the use of global handles called GEM names. A GEM name refers to one, and only one, GEM object created within the same DRM device by the same DRM driver, by using a unique 32-bit integer. GEM provides an operation flink to obtain a GEM name from a GEM handle. The process can then pass this GEM name (32-bit integer) to another process using any IPC mechanism available. The GEM name can be used by the recipient process to obtain a local GEM handle pointing to the original GEM object.

Unfortunately, the use of GEM names to share buffers is not secure. A malicious third-party process accessing the same DRM device could try to guess the GEM name of a buffer shared by two other processes, simply by probing 32-bit integers. Once a GEM name is found, its contents can be accessed and modified, violating the confidentiality and integrity of the information of the buffer. This drawback was overcome later by the introduction of DMA-BUF support into DRM, as DMA-BUF represents buffers in userspace as file descriptors, which may be shared securely.

Another important task for any video-memory management system besides managing the video-memory space is handling the memory synchronization between the GPU and the CPU. Current memory architectures are very complex and usually involve various levels of caches for the system memory and sometimes for the video memory too. Therefore, video-memory managers should also handle the cache coherence to ensure the data shared between CPU and GPU is consistent. This means that often video-memory management internals are highly dependent on hardware details of the GPU and memory architecture, and thus driver-specific.

GEM was initially developed by Intel engineers to provide a video-memory manager for its i915 driver. The Intel GMA 9xx family are integrated GPUs with a Uniform Memory Architecture (UMA), where the GPU and CPU share the physical memory, and there is not a dedicated VRAM. GEM defines "memory domains" for memory synchronization, and while these memory domains are GPU-independent, they are specifically designed with an UMA memory architecture in mind, making them less suitable for other memory architectures like those with a separate VRAM. For this reason, other DRM drivers have decided to expose to user-space programs the GEM API, but internally they implemented a different memory manager better suited for their particular hardware and memory architecture.

The GEM API also provides ioctls for control of the execution flow (command buffers), but they are Intel-specific, to be used with Intel i915 and later GPUs. No other DRM driver has attempted to implement any part of the GEM API beyond the memory-management specific ioctls.

Translation Table Maps
Translation Table Maps (TTM) is the name of the generic memory manager for GPUs that was developed before GEM. It was specifically designed to manage the different types of memory that a GPU might access, including dedicated Video RAM (commonly installed in the video card) and system memory accessible through an I/O memory management unit called the Graphics Address Remapping Table (GART). TTM should also handle the portions of the video RAM that are not directly addressable by the CPU and do it with the best possible performance, considering that user-space graphics applications typically work with large amounts of video data. Another important matter was to maintain the consistency between the different memories and caches involved.

The main concept of TTM are the "buffer objects", regions of video memory that at some point must be addressable by the GPU. When a user-space graphics application wants access to a certain buffer object (usually to fill it with content), TTM may require relocating it to a type of memory addressable by the CPU. Further relocations—or GART mapping operations—could happen when the GPU needs access to a buffer object but it isn't in the GPU's address space yet. Each of these relocation operations must handle any related data and cache-coherency issues.

Another important TTM concept is fences. Fences are essentially a mechanism to manage concurrency between the CPU and the GPU. A fence tracks when a buffer object is no longer used by the GPU, generally to notify any user-space process with access to it.

The fact that TTM tried to manage all kind of memory architectures, including those with and without a dedicated VRAM, in a suitable way, and to provide every conceivable feature in a memory manager for use with any type of hardware, led to an overly complex solution with an API far larger than needed. Some DRM developers thought that it wouldn't fit well with any specific driver, especially the API. When GEM emerged as a simpler memory manager, its API was preferred over the TTM one. But some driver developers considered that the approach taken by TTM was more suitable for discrete video cards with dedicated video memory and IOMMUs, so they decided to use TTM internally, while exposing their buffer objects as GEM objects and thus supporting the GEM API. Examples of current drivers using TTM as an internal memory manager but providing a GEM API are the radeon driver for AMD video cards and the nouveau driver for NVIDIA video cards.

DMA Buffer Sharing and PRIME
The DMA Buffer Sharing API (often abbreviated as DMA-BUF) is a Linux kernel internal API designed to provide a generic mechanism to share DMA buffers across multiple devices, possibly managed by different types of device drivers. For example, a Video4Linux device and a graphics adapter device could share buffers through DMA-BUF to achieve zero-copy of the data of a video stream produced by the first and consumed by the latter. Any Linux device driver can implement this API as exporter, as user (consumer) or both.

This feature was exploited for the first time in DRM to implement PRIME, a solution for GPU offloading that uses DMA-BUF to share the resulting framebuffers between the DRM drivers of the discrete and the integrated GPU. An important feature of DMA-BUF is that a shared buffer is presented to user space as a file descriptor. For the development of PRIME two new ioctls were added to the DRM API, one to convert a local GEM handle to a DMA-BUF file descriptor and another for the exact opposite operation.

These two new ioctls were later reused as a way to fix the inherent unsafety of GEM buffer sharing. Unlike GEM names, file descriptors can not be guessed (they are not a global namespace), and Unix operating systems provide a safe way to pass them through a Unix domain socket using the SCM_RIGHTS semantics. A process that wants to share a GEM object with another process can convert its local GEM handle to a DMA-BUF file descriptor and pass it to the recipient, which in turn can get its own GEM handle from the received file descriptor. This method is used by DRI3 to share buffers between the client and the X Server and also by Wayland.

Kernel Mode Setting

In order to work properly, a video card or graphics adapter must set a mode—a combination of screen resolution, color depth and refresh rate—that is within the range of values supported by itself and the attached display screen. This operation is called mode-setting, and it usually requires raw access to the graphics hardware—i.e. the ability to write to certain registers of the video card display controller. A mode-setting operation must be performed before starting to use the framebuffer, and also when the mode is required to change by an application or the user.

In early days, the user space programs that wanted to use the graphical framebuffer were also responsible for providing the mode-setting operations, and therefore they needed to run with privileged access to the video hardware. In Unix-type operating systems, the X Server was the most prominent example, and its mode-setting implementation lived in the DDX driver for each specific type of video card. This approach, later referred to as User space Mode-Setting or UMS, poses several issues. It not only breaks the isolation that operating systems should provide between programs and hardware, raising both stability and security concerns, but also could leave the graphics hardware in an inconsistent state if two or more user space programs try to do the mode-setting at the same time. To avoid these conflicts, the X Server became in practice the only user space program that performed mode-setting operations; the remainder user space programs relied on the X Server to set the appropriate mode and to handle any other operation involving mode-setting. Initially the mode-setting was performed exclusively during the X Server startup process, but later the X Server gained the ability to do it while running. The XFree86-VidModeExtension extension was introduced in XFree86 3.1.2 to let any X client request modeline (resolution) changes to the X Server. VidMode extension was later superseded by the more generic XRandR extension.

However, this was not the only code doing mode-setting in a Linux system. During the system booting process, the Linux kernel must set a minimal text mode for the virtual console (based on the standard modes defined by VESA BIOS extensions). Also the Linux kernel framebuffer driver contained mode-setting code to configure framebuffer devices. To avoid mode-setting conflicts, the XFree86 Server—and later the X.Org Server—handled the case when the user switched from the graphical environment to a text virtual console by saving its mode-setting state, and restoring it when the user switched back to X. This process caused an annoying flicker in the transition, and also can fail, leading to a corrupted or unusable output display.

The user space mode setting approach also caused other issues:
 * The suspend/resume process has to rely on user space tools to restore the previous mode. One single failure or crash of one of these programs could leave the system without a working display due to a modeset misconfiguration, and therefore unusable.
 * It was also impossible for the kernel to show error or debug messages when the screen was in a graphics mode—for example when X was running—since the only modes the kernel knew about were the VESA BIOS standard text modes.
 * A more pressing issue was the proliferation of graphical applications bypassing the X Server and the emergence of other graphics stack alternatives to X, extending the duplication of mode-setting code across the system even further.

To address these problems, the mode-setting code was moved to a single place inside the kernel, specifically to the existing DRM module. Then, every process—including the X Server—should be able to command the kernel to perform mode-setting operations, and the kernel would ensure that concurrent operations don't result in an inconsistent state. The new kernel API and code added to the DRM module to perform these mode-setting operations was called Kernel Mode-Setting (KMS).

Kernel Mode-Setting provides several benefits. The most immediate is of course the removal of duplicate mode-setting code, from both the kernel (Linux console, fbdev) and user space (X Server DDX drivers). KMS also makes it easier to write alternative graphics systems, which now don't need to implement their own mode-setting code. By providing centralized mode management, KMS solves the flickering issues while changing between console and X, and also between different instances of X (fast user switching). Since it is available in the kernel, it can also be used at the beginning of the boot process, saving flickering due to mode changes in these early stages.

The fact that KMS is part of the kernel allows it to use resources only available at kernel space such as interrupts. For example, the mode recovery after a suspend/resume process simplifies a lot by being managed by the kernel itself, and incidentally improves security (no more user space tools requiring root permissions). The kernel also allows the hotplug of new display devices easily, solving a longstanding problem. Mode-setting is also closely related to memory management—since framebuffers are basically memory buffers—so a tight integration with the graphics memory manager is highly recommended. That's the main reason why the kernel mode-setting code was incorporated into DRM and not as a separate subsystem.

To avoid breaking backwards compatibility of the DRM API, Kernel Mode-Setting is provided as an additional driver feature of certain DRM drivers. Any DRM driver can choose to provide the DRIVER_MODESET flag when it registers with the DRM core to indicate that supports the KMS API. Those drivers that implement Kernel Mode-Setting are often called KMS drivers as a way to differentiate them from the legacy—without KMS—DRM drivers.

KMS has been adopted to such an extent that certain drivers which lack 3D acceleration (or for which the hardware vendor doesn't want to expose or implement it) nevertheless implement the KMS API without the rest of the DRM API, allowing display servers (like Wayland) to run with ease.

KMS device model
KMS models and manages the output devices as a series of abstract hardware blocks commonly found on the display output pipeline of a display controller. These blocks are:

 * CRTCs: each CRTC (from CRT Controller) represents a scanout engine of the display controller, pointing to a scanout buffer (framebuffer). The purpose of a CRTC is to read the pixel data currently in the scanout buffer and generate from it the video mode timing signal with the help of a PLL circuit. The number of CRTCs available determines how many independent output devices the hardware can handle at the same time, so in order to use multi-head configurations at least one CRTC per display device is required. Two—or more—CRTCs can also work in clone mode if they scan out from the same framebuffer to send the same image to several output devices.
 * Connectors: a connector represents where the display controller sends the video signal from a scanout operation to be displayed. Usually, the KMS concept of a connector corresponds to a physical connector (VGA, DVI, FPD-Link, HDMI, DisplayPort, S-Video, ...) in the hardware where an output device (monitor, laptop panel, ...) is permanently or can temporarily be attached. Information related to the current physically attached output device—such as connection status, EDID data, DPMS status or supported video modes—is also stored within the connector.
 * Encoders: the display controller must encode the video mode timing signal from the CRTC using a format suitable for the intended connector. An encoder represents the hardware block able to do one of these encodings. Examples of encodings—for digital outputs—are TMDS and LVDS; for analog outputs such as VGA and TV out, specific DAC blocks are generally used. A connector can only receive the signal from one encoder at a time, and each type of connector only supports some encodings. There also might be additional physical restrictions by which not every CRTC is connected to every available encoder, limiting the possible combinations of CRTC-encoder-connector.
 * Planes: a plane is not a hardware block but a memory object containing a buffer from which a scanout engine (a CRTC) is fed. The plane that holds the framebuffer is called the primary plane, and each CRTC must have one associated, since it's the source for the CRTC to determine the video mode—display resolution (width and height), pixel size, pixel format, refresh rate, etc. A CRTC might have also cursor planes associated to it if the display controller supports hardware cursor overlays, or secondary planes if it's able to scan out from additional hardware overlays and compose or blend "on the fly" the final image sent to the output device.

Atomic Display
In recent years there has been an ongoing effort to bring atomicity to some regular operations pertaining the KMS API, specifically to the mode setting and page flipping operations. This enhanced KMS API is what is called Atomic Display (formerly known as atomic mode-setting and atomic or nuclear pageflip). The purpose of the atomic mode-setting is to ensure a correct change of mode in complex configurations with multiple restrictions, by avoiding intermediate steps which could lead to an inconsistent or invalid video state; it also avoids risky video states when a failed mode-setting process has to be undone ("rollback"). Atomic mode-setting allows one to know beforehand if certain specific mode configuration is appropriate, by providing mode testing capabilities. When an atomic mode is tested and its validity confirmed, it can be applied with a single indivisible (atomic) commit operation. Both test and commit operations are provided by the same new ioctl with different flags.

Atomic page flip on the other hand allows to update multiple planes on the same output (for instance the primary plane, the cursor plane and maybe some overlays or secondary planes) all synchronized within the same VBLANK interval, ensuring a proper display without tearing. This requirement is especially relevant to mobile and embedded display controllers, that tend to use multiple planes/overlays to save power.

The new atomic API is built upon the old KMS API. It uses the same model and objects (CRTCs, encoders, connectors, planes, ...), but with an increasing number of object properties that can be modified. The atomic procedure is based on changing the relevant properties to build the state that we want to test or commit. The properties we want to modify depend on whether we want to do a mode-setting (mostly CRTCs, encoders and connectors properties) or page flipping (usually planes properties). The ioctl is the same for both cases, the difference being the list of properties passed with each one.

Render nodes
In the original DRM API, the DRM device  is used for both privileged (modesetting, other display control) and non-privileged (rendering, GPGPU compute) operations. For security reasons, opening the associated DRM device file requires special privileges "equivalent to root-privileges". This leads to an architecture where only some reliable user space programs (the X server, a graphical compositor, ...) have full access to the DRM API, including the privileged parts like the modeset API. Other user space applications that want to render or make GPGPU computations should be granted by the owner of the DRM device ("DRM Master") through the use of a special authentication interface. Then the authenticated applications can render or make computations using a restricted version of the DRM API without privileged operations. This design imposes a severe constraint: there must always be a running graphics server (the X Server, a Wayland compositor, ...) acting as DRM-Master of a DRM device so that other user space programs can be granted the use of the device, even in cases not involving any graphics display like GPGPU computations.

The "render nodes" concept tries to solve these scenarios by splitting the DRM user space API into two interfaces – one privileged and one non-privileged – and using separate device files (or "nodes") for each one. For every GPU found, its corresponding DRM driver—if it supports the render nodes feature—creates a device file, called the render node, in addition to the primary node. Clients that use a direct rendering model and applications that want to take advantage of the computing facilities of a GPU, can do it without requiring additional privileges by simply opening any existing render node and dispatching GPU operations using the limited subset of the DRM API supported by those nodes—provided they have file system permissions to open the device file. Display servers, compositors and any other program that requires the modeset API or any other privileged operation must open the standard primary node that grants access to the full DRM API and use it as usual. Render nodes explicitly disallow the GEM flink operation to prevent buffer sharing using insecure GEM global names; only PRIME (DMA-BUF) file descriptors can be used to share buffers with another client, including the graphics server.

Hardware support

The Linux DRM subsystem includes free and open-source drivers to support hardware from the 3 main manufacturers of GPUs for desktop computers (AMD, NVIDIA and Intel), as well as from a growing number of mobile GPU and System on a chip (SoC) integrators. The quality of each driver varies highly, depending on the degree of cooperation by the manufacturer and other matters.

There is also a number of drivers for old, obsolete hardware detailed in the next table for historical purposes.

Development
The Direct Rendering Manager is developed within the Linux kernel, and its source code resides in the  directory of the Linux source code. The subsystem maintainer is Dave Airlie, with other maintainers taking care of specific drivers. As usual in the Linux kernel development, DRM submaintainers and contributors send their patches with new features and bug fixes to the main DRM maintainer which integrates them into its own Linux repository. The DRM maintainer in turn submits all of these patches that are ready to be mainlined to Linus Torvalds whenever a new Linux version is going to be released. Torvalds, as top maintainer of the whole kernel, holds the last word on whether a patch is suitable or not for inclusion in the kernel.

For historical reasons, the source code of the libdrm library is maintained under the umbrella of the Mesa project.

History
In 1999, while developing DRI for XFree86, Precision Insight created the first version of DRM for the 3dfx video cards, as a Linux kernel patch included within the Mesa source code. Later that year, the DRM code was mainlined in Linux kernel 2.3.18 under the  directory for character devices. During the following years the number of supported video cards grew. When Linux 2.4.0 was released in January 2001 there was already support for Creative Labs GMX 2000, Intel i810, Matrox G200/G400 and ATI Rage 128, in addition to 3dfx Voodoo3 cards, and that list expanded during the 2.4.x series, with drivers for ATI Radeon cards, some SiS video cards and Intel 830M and subsequent integrated GPUs.

The split of DRM into two components, DRM core and DRM driver, called DRM core/personality split was done during the second half of 2004, and merged into kernel version 2.6.11. This split allowed multiple DRM drivers for multiple devices to work simultaneously, opening the way to multi-GPU support.

The idea of putting all the video mode setting code in one place inside the kernel had been acknowledged for years, but the graphics card manufacturers had argued that the only way to do the mode-setting was to use the routines provided by themselves and contained in the Video BIOS of each graphics card. Such code had to be executed using x86 real mode, which prevented it from being invoked by a kernel running in protected mode. The situation changed when Luc Verhaegen and other developers found a way to do the mode-setting natively instead of BIOS-based, showing that it was possible to do it using normal kernel code and laying the groundwork for what would become Kernel Mode Setting. In May 2007 Jesse Barnes (Intel) published the first proposal for a drm-modesetting API and a working native implementation of mode-setting for Intel GPUs within the i915 DRM driver. In December 2007 Jerome Glisse started to add the native mode-setting code for ATI cards to the radeon DRM driver. Work on both the API and drivers continued during 2008, but got delayed by the necessity of a memory manager also in kernel space to handle the framebuffers.

In October 2008 the Linux kernel 2.6.27 brought a major source code reorganization, prior to some significant upcoming changes. The DRM source code tree was moved to its own source directory  and the different drivers were moved into their own subdirectories. Headers were also moved into a new  directory.

The increasing complexity of video memory management led to several approaches to solving this issue. The first attempt was the Translation Table Maps (TTM) memory manager, developed by Thomas Hellstrom (Tungsten Graphics) in collaboration with Emma Anholt (Intel) and Dave Airlie (Red Hat). TTM was proposed for inclusion into mainline kernel 2.6.25 in November 2007, and again in May 2008, but was ditched in favor of a new approach called Graphics Execution Manager (GEM). GEM was first developed by Keith Packard and Emma Anholt from Intel as a simpler solution for memory management for their i915 driver. GEM was well received and merged into the Linux kernel version 2.6.28 released in December 2008. Meanwhile, TTM had to wait until September 2009 to be finally merged into Linux 2.6.31 as a requirement of the new Radeon KMS DRM driver.

With memory management in place to handle buffer objects, DRM developers could finally add to the kernel the already finished API and code to do mode setting. This expanded API is what is called Kernel Mode-setting (KMS) and the drivers which implement it are often referred to as KMS drivers. In March 2009, KMS was merged into the Linux kernel version 2.6.29, along with KMS support for the i915 driver. The KMS API has been exposed to user space programs since libdrm 2.4.3. The userspace X.Org DDX driver for Intel graphics cards was also the first to use the new GEM and KMS APIs. KMS support for the radeon DRM driver was added to Linux 2.6.31 release of September 2009. The new radeon KMS driver used the TTM memory manager but exposed GEM-compatible interfaces and ioctls instead of TTM ones.

Since 2006 the nouveau project had been developing a free software DRM driver for NVIDIA GPUs outside of the official Linux kernel. In 2010 the nouveau source code was merged into Linux 2.6.33 as an experimental driver. At the time of merging, the driver had been already converted to KMS, and behind the GEM API it used TTM as its memory manager.

The new KMS API—including the GEM API—was a big milestone in the development of DRM, but it didn't stop the API from being enhanced in the following years. KMS gained support for page flips in conjunction with asynchronous VBLANK notifications in Linux 2.6.33—only for the i915 driver, radeon and nouveau added it later during Linux 2.6.38 release. The new page flip interface was added to libdrm 2.4.17. In early 2011, during the Linux 2.6.39 release cycle, the so-called dumb buffers—a hardware-independent non-accelerated way to handle simple buffers suitable for use as framebuffers—were added to the KMS API. The goal was to reduce the complexity of applications such as Plymouth that don't need to use special accelerated operations provided by driver-specific ioctls. The feature was exposed by libdrm from version 2.4.25 onwards. Later that year it also gained a new main type of objects, called planes. Planes were developed to represent hardware overlays supported by the scanout engine. Plane support was merged into Linux 3.3. and libdrm 2.4.30. Another concept added to the API—during Linux 3.5 and libdrm 2.4.36 releases—were generic object properties, a method to add generic values to any KMS object. Properties are specially useful to set special behaviour or features to objects such as CRTCs and planes.

An early proof of concept to provide GPU offloading between DRM drivers was developed by Dave Airlie in 2010. Since Airlie was trying to mimic the NVIDIA Optimus technology, he decided to name it "PRIME". Airlie resumed his work on PRIME in late 2011, but based on the new DMA-BUF buffer sharing mechanism introduced by Linux kernel 3.3. The basic DMA-BUF PRIME infrastructure was finished in March 2012 and merged into the Linux 3.4 release, as well as into libdrm 2.4.34. Later during the Linux 3.5 release, several DRM drivers implemented PRIME support, including i915 for Intel cards, radeon for AMD cards and nouveau for NVIDIA cards.

In recent years, the DRM API has incrementally expanded with new and improved features. In 2013, as part of GSoC, David Herrmann developed the multiple render nodes feature. His code was added to the Linux kernel version 3.12 as an experimental feature supported by i915, radeon and nouveau drivers, and enabled by default since Linux 3.17. In 2014 Matt Roper (Intel) developed the universal planes (or unified planes) concept by which framebuffers (primary planes), overlays (secondary planes) and cursors (cursor planes) are all treated as a single type of object with an unified API. Universal planes support provides a more consistent DRM API with fewer, more generic ioctls. In order to maintain the API backwards compatible, the feature is exposed by DRM core as an additional capability that a DRM driver can provide. Universal plane support debuted in Linux 3.15 and libdrm 2.4.55. Several drivers, such as the Intel i915, have already implemented it.

The most recent DRM API enhancement is the atomic mode-setting API, which brings atomicity to the mode-setting and page flipping operations on a DRM device. The idea of an atomic API for mode-setting was first proposed in early 2012. Ville Syrjälä (Intel) took over the task of designing and implementing such atomic API. Based on his work, Rob Clark (Texas Instruments) took a similar approach aiming to implement atomic page flips. Later in 2013 both proposed features were reunited in a single one using a single ioctl for both tasks. Since it was a requirement, the feature had to wait for the support of universal planes to be merged in mid-2014. During the second half of 2014 the atomic code was greatly enhanced by Daniel Vetter (Intel) and other DRM developers in order to facilitate the transition for the existing KMS drivers to the new atomic framework. All of this work was finally merged into Linux 3.19 and Linux 4.0 releases, and enabled by default since Linux 4.2. libdrm exposed the new atomic API since version 2.4.62. Multiple drivers have already been converted to the new atomic API. By 2018 ten new DRM drivers based on this new atomic model had been added to the Linux kernel.

Adoption
The Direct Rendering Manager kernel subsystem was initially developed to be used with the new Direct Rendering Infrastructure of the XFree86 4.0 display server, later inherited by its successor, the X.Org Server. Therefore, the main users of DRM were DRI clients that link to the hardware-accelerated OpenGL implementation that lives in the Mesa 3D library, as well as the X Server itself. Nowadays DRM is also used by several Wayland compositors, including Weston reference compositor. kmscon is a virtual console implementation that runs in user space using DRM KMS facilities.

In 2015, version 358.09 (beta) of the proprietary Nvidia GeForce driver received support for the DRM mode-setting interface implemented as a new kernel blob called. This new driver component works in conjunction with the  kernel module to program the display engine (i.e. display controller) of the GPU.

title: Direct Rendering Manager


text:
Talk:Collingwood School

History of School Site, part two
I have once again added some historical context for the site's original school, Glenmore, with a citation to the local newspaper. This has repeatedly been removed over the years, despite a discussion below in favour of keeping these details. Please discuss the removal of these facts here before deleting them again. — Preceding unsigned comment added by Dbarefoot (talk • contribs) 20:27, 31 October 2016 (UTC)

Listing on Votes for deletion
This article was proposed for deletion—the result was to keep the article. See Votes for deletion/Collingwood School for a record of the votes and discussion. Postdlf 23:04, 10 Feb 2005 (UTC)

16 Jun 05
Isn't Collingwood's mascot the Warrior and not the Cavalier? I thought they changed it to the Warrior? - Luckyluke 16 Jun 05

It's definitely the Cavaliers. Alliterations are the chode. - Tylersmiler 26 May 06

Time for some cleanup
Okay, someone please explain to me why Mrs. Clarke is there, while no other Heads of departments are present. And don't give me the whole "Collingwood debates well" spiel, cause that's no reason.

Secondly, I'm just not feeling a trivia section is entirely appropriate for this article. Especially considering there's only ONE piece of Trivia.

Then again, I like having length to my school's article. So I'll put this in discussion instead of directly fixing these problems.

Geoff 05:59, 5 September 2006 (UTC)

I say we take of Mrs. Clarke, unless someone wants to write profiles on everyone. Debate alreday has its own category. Mention her there.

And I agreee with Geoff, just remove the trivia all together. Tylersmiler 04:58, 6 September 2006 (UTC)

Can someone tell me why my piece on the school trying to rig the voting for campus expansion was taken out? Can we only provide pro-Collingwood views on this article? I attended the school for 12 years and felt the hostility towards myself from the school because of my parents opposition to the expansion. Please give me a reasonable response to this, because my piece was not false or hate-mongeringish.

Anon. 3.15pm April 28 2008 —Preceding unsigned comment added by 205.200.124.185 (talk) 20:15, 28 April 2008 (UTC)

History of School Site
Last year I added the following details to the history section, which have subsequently been removed: The school occupied the buildings that formerly made up Glenmore Elementary School, which was closed the previous year along with several other schools in West Vancouver. Parents, students and teachers protested the closure of Glenmore, but were unsuccessful in keeping the school open in the face of declining enrollment and a reduced education budget.

These events seem relevant to the school's history, and were reported in city newspapers (and are therefore verifiable). Does anybody have an opinion as to whether I should re-include these facts? —The preceding unsigned comment was added by Dbarefoot (talk • contribs) 20:54, 6 February 2007 (UTC).
 * I believe they should be included. It is my understanding that because of the Glenmore closure, Collingwood arose. Luke! 22:30, 6 February 2007 (UTC)
 * All rightee, I'll put it back in and see if it sticks. Dbarefoot 23:03, 6 February 2007 (UTC)

Assess
I came in to look at your pages. Compared to other schools they have length. If you can find the refereences for the interesting points (eg why former heads left) then you will have a near "Article". Maybe a photo? (member of schools project) Victuallers 23:23, 3 March 2007 (UTC)

I agree with this person's comment about telling us why the head masters left. This isn't a fucking murder mystery novel, it's wikipedia.

I googled around and discovered a source from the school that said the second headmaster was terminated because he "lied about his age." I don't want to add that at this point because I somehow doubt it is the entire story.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Talk:Collingwood School


text:
Marks Tey

Marks Tey is a large village and electoral ward in Essex, England; it is located six miles west of Colchester.

Facilities
Marks Tey is one of a group of villages called the Teys, also including Great Tey and Little Tey. Its main features include a village hall built in 1993 on the fields intersecting the A12 and A120, with an adjacent children's play park and a skateboard park. Next to that (between A12 & A120) is a suburban estate that was built in the mid-1970s. Near to the play park, there is a small parish hall, used for children's kindergarten and small exhibitions. The hall was almost doubled in size after the extension of the new Basketball hall. The hall and gardens also host a monthly artisan event called 'Marks Tey Market' on the 4th Saturday of the month (from March to October) during the day time.

The village has a parish church, St Andrew's. The church hall is central to the community, and hosts 1st Marks Tey Scouts Group with Beavers, Cubs and Scouts.

Following the demolition of the Prince of Wales public house, the Red Lion was the only pub serving the village but recently closed down during the Covid-19 pandemic. In 2001 The Food Company erected their first outlet on the site of the former Prince of Wales, selling speciality foods and drink - however the business closed in 2017. The premises were refurbished in 2021 and are now the Commercial Hub for regional solicitors, Holmes and Hills LLP. Also located on London Road are a post office, convenience store, fish and chip shop, Indian & Chinese take-aways, a butchers, bakers, hairdressers, a cycle shop, a car supplies shop, a petrol garage and Marks Tey Pharmacy.

Marks Tey Football Club was established in 1998. The home ground is Jubilee Playing Fields in Old London Road, alongside the skateboard park. They currently have one men's Saturday team, one men's Sunday team, one veterans' team, two youth teams, and two mini football teams.

Transport
Marks Tey railway station is on the Great Eastern Main Line between London Liverpool Street and Ipswich; it is also a junction and eastern terminus for the Sudbury Branch Line. Passenger trains are operated by Greater Anglia. Services run generally half-hourly in each way to Liverpool Street southbound and to Colchester and Ipswich northbound, with hourly services on the branch line to Sudbury.

Bus services are provided by the 370/371 First Bus service between Chelmsford and Colchester.

The village is located beside the A12 dual carriageway, which connects east London with Lowestoft.

title: Marks Tey


text:
ESRD

ESRD is a four-letter abbreviation that may refer to:

 * End-stage renal disease
 * Emergency Services Routing Digit for a wireless or mobile telephone emergency telephone number

title: ESRD


text:
User talk:JoelCurtis16

Test
Hi. Your test worked, and has been reverted. Please note that wikipedia has a sandbox which was made for these types of tests. It would be appreciated if you perform all tests there in the future. If you have any further questions, please feel free to leave a note on my talk page.

Vandalism warning
Greetings. I've noticed some vandalism coming from your IP address. Any further vandalism will be reverted. Please cease to continue your atrocious behavior, or your IP address will be recorded on the Vandalism in progress page. Website defacement is a crime in numerous countries, and you can rest assured that if you do not stop vandalizing pages after being warned, you will likely be blocked. Trying to evade this IP block to continue vandalising is useless, since somebody will report you to your internet service provider.

We've all worked hard to make Wikipedia what it is today. A study by IBM showed that the majority of vandalism on wikipedia is repaired within the next 5 minutes, so your actions are feckless, and only serve to put you at risk. If you have any questions, feel free to leave a note on my talk page.

If you decide to change your behavior, your contributions will be greatly appreciated- regardless of what your previous behavior was. -Frazzydee|✍ 01:36, 6 Feb 2005 (UTC)

title: User talk:JoelCurtis16


text:
USS Natchez

USS Natchez may refer to the following ships operated by the United States Navy:

 * USS Natchez (1827), a sloop-of-war launched in 1827.
 * USS Natchez (PG-85), the name and designation of USS Oceanographer (AGS-3) from April to May 1942
 * USS Natchez (PF-2), an Asheville-class frigate patrol frigate, launched in 1942, served in World War II; sold to Dominican Republic in 1948 and served as Juan Pablo Duarte (F–102) until she sank in 1957.

title: USS Natchez


text:
Jane Rule

Jane Vance Rule (28 March 1931 – 27 November 2007) was a Canadian-American writer of lesbian-themed works. Her first novel, Desert of the Heart, appeared in 1964, when gay activity was still a criminal offence. It turned Rule into a reluctant media celebrity, and brought her massive correspondence from women who had never dared explore lesbianism. Rule became an active anti-censorship campaigner, and served on the executive of the Writers' Union of Canada.

Early life
Born in Plainfield, New Jersey, Jane Vance Rule was the oldest daughter of Carlotta Jane Hink-Packer and Arthur Richards Rule. Both her parents were college educated and her father worked in the military. Rule described her mother as "a materially spoiled and emotionally depraved only child". Rule was also the middle of three children, with an older brother and a younger sister.

Because she grew up in a military family, Rule moved frequently—to Hinsdale, Illinois, and later to California and Missouri, and then back to California where her father served in the Pacific during World War II. She says she was a tomboy growing up and felt like an outsider for reaching six feet tall by age 12 and being dyslexic. When she was 15 she read The Well of Loneliness and wrote later that she, "suddenly discovered that [she] was a freak."

Rule graduated with a degree in English from Mills College in California in 1952. Almost immediately after graduation, she traveled on the ship "Queen Mary" to spend a year in London, following a female lover. There, she was an occasional student at University College, London, and began work on her first novel.

Rule returned to the U.S. to work at the writing department at Stanford University, but she quit after a few months because of "the competitive, commercial atmosphere of the school, the condescending attitude toward women students". She then lived at home with her parents until 1954.

Beginning in 1954, Rule taught at Concord Academy in Massachusetts where she met Helen Sonthoff (September 11, 1916 - January 3, 2000), a fellow creative writing and literature teacher. The two fell in love, but at the time of their meeting, Sonthoff was married.

Worried about politics and McCarthyism of the 50s in America, Rule moved with her friend and literary critic, John Hulcoop, to Vancouver, British Columbia in 1956. While there, she worked at the University of British Columbia, as well as wrote her first novel.

At some point while living together, Rule and Hulcoop's relationship turned romantic. However, that became complicated by the arrival of the woman Hulcoop would marry, as well as the arrival of Helen Sonthoff. Sonthoff was recently divorced and went to Vancouver for a vacation, which turned into a life-long relationship with Jane Rule.

Career
Although Rule had finished writing her first novel, Desert of the Heart, in 1961, it was not published until 1964, after 22 rejections from publishers. The book features two women who fall in love, and ends overall-positively for the two. It caused Rule to be inundated with letters from desperate women discovering their lesbianism, as well as fearful and chilly reviews surrounding the homosexual theme. It was, after all, published five years before the decriminalization of homosexuality in Canada. Therefore, Rule became the spokesperson of all issues surrounding homosexuality in Canada, and she later wrote "I became, for the media, the only lesbian in Canada. A role I gradually and very reluctantly accepted and used to educate people as I could."

Rule wrote 11 more novels in the 70s and 80s, including her book Lesbian Images, a study of lesbian writers. Her other works during this time included fiction novels, essays, and short stories. In all of her work, she has become known for her eloquence in describing human relationships, both hetero and homosexual. Rule's wish was to be remembered as a Canadian writer, more-so than a lesbian or woman writer.

Rule served on the executive of the Writers' Union of Canada. She was an outspoken advocate of both free speech and gay rights, included in the various controversies surrounding the gay magazine The Body Politic, which she wrote for regularly, along with The Ladder. She was also a prominent anti-censorship figure (specifically about the seizure of gay and lesbian books).

In 1989, Rule donated a collection of her writings to the University of British Columbia. The collection was updated with more writings in 2016, and Helen Sonthoff's papers now also belong to the University of British Columbia.

Rule was inducted into the Order of British Columbia in 1998, and into the Order of Canada in 2007, both award ceremonies taking place, at Rule's initiative, in her home community of Galiano Island. Rule remarked "I chose Canada over 50 years ago. So it is very nice to have Canada choose me", about receiving the latter honor.

Rule received the Bill Whitehead Award for Lifetime Achievement from Publishing Triangle in 2002.

Desert of the Heart was the inspiration for the now cult-classic lesbian 1985 film Desert Hearts, directed by Donna Deitch.

Rule was also the subject of Lynne Fernie and Aerlyn Weissman's 1995 documentary film Fiction and Other Truths: A Film About Jane Rule.

Personal life and death
Rule and Helen Sonthoff lived together from 1957 until Sonthoff's death in 2000. Sonthoff also taught at the University of British Columbia. The two became Canadian citizens in 1960.

Rule surprised some in the gay community by declaring herself against gay marriage, writing "To be forced back into the heterosexual cage of coupledom is not a step forward but a step back into state-imposed definitions of relationship. With all that we have learned, we should be helping our heterosexual brothers and sisters out of their state-defined prisons, not volunteering to join them there."

In 1976, Rule moved to Galiano Island along with Helen Sonthoff, and the two remained there until the end of both their lives. They were well-known and loved on the island, and purportedly Helen and Jane would give loans to the island's residents in need, as well as teach all the neighborhood children how to swim in their backyard pool.

By age 60, Rule was plagued with chronic arthritis, which ultimately dulled her desire to write. In 2007, she was diagnosed with liver cancer. She refused any radical treatment and instead continued swimming and living her life as usual. Prior to her death, Rule had already had two "living wakes" and felt that because of this, she would die elegantly. She died later that year, at the age of 76 on November 28, 2007, at home on Galiano Island. The ashes of Jane Vance Rule were interred in the Galiano Island Cemetery next to those of her beloved Helen Sonthoff.

The manuscript of Rule's memoir was found and published posthumously, Taking My Life, published in 2011. The manuscript was discovered by Linda M. Morra, who edited and annotated the book.

Works

 * Desert of the Heart (1964)
 * This Is Not for You (1970), Naiad Press
 * Against the Season (1971), Naiad Press
 * Lesbian Images (1975), The Crossing Press
 * Theme for Diverse Instruments (1975)
 * The Young in One Another's Arms (1977), Naiad Press
 * Contract with the World (1980)
 * Outlander, (1981) Naiad Press
 * Inland Passage and Other Stories (1985), Naiad Press
 * A Hot-Eyed Moderate (1985), Naiad Press
 * Memory Board (1987), Naiad Press
 * After the Fire (1989), Naiad Press
 * Loving the Difficult (2008), Hedgerow Press
 * Taking My Life (2011), Talonbooks
 * A Queer Love Story: The Letters of Jane Rule and Rick Bébout (2017), UBC Press

title: Jane Rule


text:
Crutch

A crutch is a mobility aid that transfers weight from the legs to the upper body. It is often used by people who cannot use their legs to support their weight, for reasons ranging from short-term injuries to lifelong disabilities.

History
Crutches were used in ancient Egypt. In 1917, Emile Schlick patented the first commercially produced crutch; the design consisted of a walking stick with an upper arm support. Later, A.R. Lofstrand Jr. developed the first crutches with a height-adjustable feature. Over time, the design of crutches has not changed much, and the classic design continues to be the most commonly used.

Types
There are several types of crutches:

Underarm or axillary
Axillary crutches are used by placing the pad against the ribcage beneath the armpit and holding the grip, which is below and parallel to the pad. They are usually used to provide support for patients who have temporary restriction on ambulation. With underarm crutches, sometimes a towel or some kind of soft cover is needed to prevent or reduce armpit injury. A condition known as crutch paralysis, or crutch palsy can arise from pressure on nerves in the armpit, or axilla. Specifically, "the brachial plexus in the axilla is often damaged from the pressure of a crutch...In these cases the radial is the nerve most frequently implicated; the ulnar nerve suffers next in frequency."

An uncommon type of axillary crutches is the spring-loaded crutch. The underarm pad is a curved design that is open in the front with the grips for the hands shaped for maximum comfort and to reduce the prevalence of overuse injuries. These crutches also contain a spring mechanism at the bottom. The idea behind this design is to allow the user to propel themselves further, resulting in quicker movement from place to place, though research has shown that the difference in speed is very small when comparing standard axillary crutches to spring-loaded crutches.

Forearm
A forearm crutch (also commonly known as an elbow crutch, Canadian crutch or "Lofstrand" crutch due to a brand by this name) has a cuff at the top that goes around the forearm. It is used by inserting the arm into the cuff and holding the grip. The hinged cuff, most frequently made of plastic or metal, can be a half-circle or a full circle with a V-type opening in the front allowing the forearm to slip out in case of a fall.

Forearm crutches are the dominant type used in Europe, whether for short or long term use. Outside of Europe forearm crutches are more likely to be used by users with long-term disabilities, with axillary crutches more common for short-term use.

Platform

These are less common and used by those with poor hand or grip strength due to arthritis, cerebral palsy, or other conditions. The forearm rests on a horizontal platform and is usually strapped in place with velcro-type straps that allow the platform or trough to release in case of a fall. The hand holds an angled grip which, in addition, should allow adjustment of length from trough to grip and side-to-side sway depending on the user's disability.

Leg support
These non-traditional crutches are useful for users with an injury or disability affecting one lower leg only. They function by strapping the affected leg into a support frame that simultaneously holds the lower leg clear of the ground while transferring the load from the ground to the user's knee or thigh. This style of crutch has the advantage of not using the hands or arms while walking. A claimed benefit is that upper thigh atrophy is also reduced because the affected leg remains in use. Unlike other crutch designs these designs are unusable for pelvic, hip or thigh injuries and in some cases for knee injuries also.

Walking sticks or canes serve an identical purpose to crutches, but are held only in the hand and have a limited load bearing capability because of this.

One crutch
When using one crutch, the crutch may be placed on the side of the unaffected leg or used to bear the load of the affected leg.

Four-point gait
Those who can tolerate partial weight bearing on both legs usually use the four point gait. The sequence is right crutch, left leg, left crutch, right leg. This is the slowest of all gaits but also the safest in that three of the four points are in contact with the ground at any given time.

Two-point gait
Those who can tolerate partial weight bearing on both legs but require less support than a four-point gait usually use the two-point gait. The sequence is right crutch with left leg and then left crutch with right leg.

Three-point gait
The three point gait is usually used by those who cannot bear weight on one leg. Both crutches are advanced while bearing weight on the unaffected leg. Then the unaffected leg is advanced while bearing weight on the crutches.

Swing-to gait
A person with a non-weight bearing injury generally performs a "swing-to" gait: lifting the affected leg, the user places both crutches in front of himself, and then swings his uninjured leg to meet the crutches. A similar "swing-through" gait is when both legs are advanced in front of the crutches rather than beside them.

Stairs
When climbing up stairs, the unaffected leg is advanced first, then the affected leg and the crutches are advanced. When descending stairs, the crutches are advanced first and then the affected leg and the unaffected leg.

Alternative devices
The knee scooter and the wheelchair are possible alternatives for patients who cannot use or do not like crutches. These wheeled devices introduce an additional limitation, however, since most cannot negotiate stairs.

Materials

 * Wood
 * Metal alloys (most often steel, aluminium alloys, titanium alloys)
 * Carbon or glass fiber reinforced composites
 * Thermoplastic
 * Carbon-fiber reinforced polymer

title: Crutch


text: User talk:70.178.83.187

title: User talk:70.178.83.187


text:
Ralph Boston

Ralph Harold Boston (May 9, 1939 – April 30, 2023) was an American track athlete who received three Olympic medals and became the first person to break the 27 ft barrier in the long jump.

Early years and education
Boston was born in Laurel, Mississippi. As a student at Tennessee State University, he won the 1960 National Collegiate Athletic Association title in the long jump. In August of the same year, he broke the world record in the event, held by Jesse Owens for 25 years, at the Mt. SAC Relays. Already the world record holder, he improved the mark past 27 ft, jumping 27 ft at the Modesto Relays on May 27, 1961.

Athletic career

Boston qualified for the Summer Olympics in Rome, where he won the gold medal in the long jump, setting the Olympic record at, while narrowly defeating American teammate Bo Roberson by a mere centimeter.

Boston won the Amateur Athletic Union (AAU) national championship in the long jump six times in a row from 1961 to 1966. He also had the longest triple jump for an American in 1963. He returned to the Tokyo Olympics as the world record holder after losing the record to Igor Ter-Ovanesyan, then regaining the record a couple of months before the games, first in Kingston, Jamaica and improving it at the 1964 Olympic Trials. In the Olympic final, Boston exchanged the lead with Ter-Ovanesyan. Going into the fifth round, Boston was leading but fouled while both Lynn Davies and Ter-Ovanesyan jumped past him. On his final jump, he was able to jump past Ter-Ovanesyan, but could not catch Davies and ended winning the silver medal.

Boston's final record improvement to 8.35 m was again at the 1965 Modesto Relays. It was tied at altitude by Ter-Ovanesyan in 1967. In 1967, he lost the national title to Jerry Proctor. When rival Bob Beamon was suspended from the University of Texas at El Paso, for refusing to compete against Brigham Young University, alleging it had racist policies, Boston began to coach him unofficially. Beamon took the 1968 National Championships. At the 1968 Olympics, Boston watched his pupil obliterate the tied world record by jumping. Boston was then 29 years old. He won a bronze medal behind Beamon and Klaus Beer and retired from competitions shortly thereafter. He moved to Knoxville, Tennessee, and worked for the University of Tennessee as Coordinator of Minority Affairs and Assistant Dean of Students from 1968 to 1975. He was the field event reporter for the CBS Sports Spectacular coverage of domestic track and field events. He was inducted into the USA Track and Field Hall of Fame in 1974 and into the U.S. Olympic & Paralympic Hall of Fame in 1985.

Later years
Boston participated in the raising of the Olympic flag for the 1996 Summer Olympics in Atlanta, and by 1997, Boston had moved into Peachtree City, Georgia.

A Los Angeles Times article on Boston from August 2, 2010, coinciding roughly with the 50th anniversary of his initial world record, described him as a divorced great-grandfather who was writing an autobiography. He split his time between Atlanta, Georgia and Knoxville.

Boston died of complications from a stroke at his home in Peachtree City on April 30, 2023, at the age of 83.

title: Ralph Boston


text:
Martin Bell (skier)

Martin Bell (born 6 December 1964, RAF Akrotiri, Cyprus) is a British former World Cup alpine ski racer.

Bell was educated at George Watson's College in Edinburgh and the Stams Schigymnasium in Austria. He competed in four Winter Olympics from 1984 to 1994, placing eighth in the downhill at the 1988 Games in Calgary, Canada – the best result for a male skier from the UK in Olympic history.

He also competed at five World Championships from 1985 to 1993. Martin Bell and his brother, Graham Bell were the two most successful British skiers in the 1980s and 1990s.

Bell now lives near Vail, Colorado, US. He is married to Laura Bell and has two daughters, Reece and Imogen.

title: Martin Bell (skier)


text:
Talk:Georges Auguste Escoffier

i cant finish this right now Cacophony 01:39, Feb 6, 2005 (UTC)

Georges Auguste Escoffier (1846 - 1935) was a French chef nicknamed The King of Chefs and the Chef of Kings. His innovations revolutinized the culinary industry.

His culinary career began at the age of 13 when he moved to Nice to work in the kichen of his uncle's restraunt. Six years later he was discovered by the owner of Le petit Moulin Rouge and was offered a job at what was then the most fashionable restraunt in Paris. He worked there until 1870 when the Franco-Prussian War called him to military duty, where he served as Chef de Cuisine. After the war he returned to the Moulin Rouge and was the chef there until 1878.

In 1890 he paired with Cesar Ritz to run the sucessful Savoy Hotel in London. They opened the Hôtel Ritz Paris in 1898 and the Carlton Hotel in London in 1899, where Escoffier was chef until 1919. In 1920 Escoffier became the first chef to be induceted into the Légion d'honneur.

His innovations include the reorginization of the kitchen from several small rooms into one fully integrated unit. Escoffier is crowned with his highlight achievement for creating the secret sauce on McDonalds "Big Mac", and it has been rumored that he was was a huge advocate for legalizing the medical use of marijuana in california where he ultimately finished his life, after opening the now successfull restaurant chain Taco Bell [edit] Death — Preceding unsigned comment added by 67.242.117.147 (talk) 18:00, 27 November 2012 (UTC)

title: Talk:Georges Auguste Escoffier


text:
MGH

MGH may refer to:

 * Bad Mergentheim (vehicle registration plate), Germany
 * Margate Airport (IATA code), South Africa
 * Massachusetts General Hospital, Boston, US
 * Charles/MGH station, near Massachusetts General Hospital
 * Montreal General Hospital, Canada
 * Michael Garron Hospital, Toronto, Canada
 * Monumenta Germaniae Historica, a series of primary sources pertaining to German and European history
 * Microglandular hyperplasia, a cervical lesion
 * A formulation for calculating gravitational energy near the Earth's surface

title: MGH