Graphics: Difference between revisions
No edit summary |
|||
Line 16: | Line 16: | ||
===Xorg=== | ===Xorg=== | ||
[[File:fdx-logo-text.png|right|thumb|X.org Server 1.13 was released 2012-09-05.]] | [[File:fdx-logo-text.png|right|thumb|X.org Server 1.13 was released 2012-09-05.]] | ||
[[File: | [[File:Dri_logo.png|right|thumb|DRI is a combination of DRM, X.org, and Mesa.]] | ||
[[File:X-architecture.png|X architecture as of 2012]] | [[File:X-architecture.png|X architecture as of 2012]] | ||
===Wayland=== | ===Wayland=== | ||
[[File:Wayland.png|right|thumb|Wayland is not yet ready for general use.]] | |||
[[File:Wayland-architecture.png|Wayland architecture]] | [[File:Wayland-architecture.png|Wayland architecture]] | ||
Revision as of 09:09, 18 November 2012
Screen-based displays (primarily LEDs and CRTs) underpin most users' interactions with their desktops and mobile devices. Modern desktops regularly drive one or more large, colorful, high-resolution LEDs via one or sometimes multiple video cards. Graphics processing units commonly contain more transistors than the CPUs with which they are mated. Despite this, the basic process interface exposed by ANSI C and the UNIX kernel consists of two character streams.
To explain: Gallum, DRM, DRI, KMS, OpenGLES, OpenVG, X, Wayland, widgetsets, VESA. VBE, DDC, EDID, TMDS, DMI, HDMI, DisplayPort...
Displays
Character Output
Serial consoles
GRUB on VGA
Linux system console on VGA
Graphical Output
Graphical output will require some kernel module(s) driving the video device(s). Framebuffer drivers are independent of userspace programs; they create a /dev entry, and can support the system console and the X framebuffer server. Direct Rendering Manager (DRM) drivers are used as part of X11's Direct Rendering Infrastructure (DRI), and require their own X servers. Framebuffer drivers generally accelerate only 2D operations (blitting, rectangular tiling, etc), or none at all. DRM drivers expose a much richer API, and can be used with fully hardware-accelerated X servers. In addition, closed source drivers -- usually paired with their own X servers, and not typically supporting a framebuffer device -- can be used. Use of both the DRI and framebuffer drivers with a device can lead to errors, although sometimes it works fine.
Framebuffer
An abstraction of hardware, mapping memory to displayed pixels. If a framebuffer driver is active, /dev/fbX devices will exist, and the fbset tool can be used to display their statuses. It is generally not advised to use a framebuffer driver at the same time as X-based hardware control, though this sometimes works in practice. When a framebuffer is present and supported at kernel boot time, Linux will display a Tux logo (see right) for each processor in the machine.
Xorg
Wayland
APIs
OpenGL
OpenGL (the Open Graphics Library) is an API specification. On desktop Linux, there are three major implementations of OpenGL:
- NVIDIA's proprietary implementation, which supports most NVIDIA cards
- AMD's proprietary implementation, which supports most AMD cards
- Mesa, an open implementation mixing hardware acceleration with software fallback. It includes:
- Nouveau, an open implementation for NVIDIA cards
- Radeon, an open implementation for AMD cards
- An open implementation for Intel cards
Generally, the proprietary drivers tend to support newer OpenGL features and provide better performance, while the Mesa drivers are more smoothly integrated with the rest of the graphics stack (Kernel Mode Switching, Direct Rendering Infrastructure, XRandr, etc). Standard Linux tools might fail to work with the proprietary drivers, forcing use of proprietary tools to control the device.
EGL
EGL provides window manager-specific functionality for an OpenGL stack.
OpenGL ES
OpenGL for Embedded Systems. Mesa targets this with drivers for:
- OMAP (Texas Instruments)
- SGX (PowerVR)
OpenVG
Vector graphics acceleration targeting embedded systems (ie, often used in conjunction with OpenGL ES).
See Also
- VGA compatible text mode on Wikipedia