Graphics: Difference between revisions
No edit summary |
|||
Line 4: | Line 4: | ||
'''To explain: Gallum, DRM, DRI, KMS, OpenGLES, OpenVG, X, Wayland, widgetsets, VESA. VBE, DDC, EDID, TMDS, DMI, HDMI, DisplayPort...''' | '''To explain: Gallum, DRM, DRI, KMS, OpenGLES, OpenVG, X, Wayland, widgetsets, VESA. VBE, DDC, EDID, TMDS, DMI, HDMI, DisplayPort...''' | ||
==Displays== | |||
==Character Output== | ==Character Output== | ||
===Serial consoles=== | ===Serial consoles=== | ||
===GRUB on VGA=== | ===GRUB on VGA=== | ||
===Linux system console on VGA=== | ===Linux system console on VGA=== | ||
==Graphical Output== | |||
==Framebuffer== | Graphical output will require some kernel module(s) driving the video device(s). Framebuffer drivers are independent of userspace programs; they create a <tt>/dev</tt> entry, and can support the system console and the X framebuffer server. DRI drivers are used as part of X11, and require their own X servers. Framebuffer drivers generally accelerate only 2D operations (blitting, rectangular tiling, etc), or none at all. DRI 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=== | |||
[[File:Tux.svg|right|thumb]] | [[File:Tux.svg|right|thumb]] | ||
An abstraction of hardware, mapping memory to displayed pixels. If a framebuffer driver is active, /dev/fbX devices will exist, and the <tt>fbset</tt> 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. | An abstraction of hardware, mapping memory to displayed pixels. If a framebuffer driver is active, /dev/fbX devices will exist, and the <tt>fbset</tt> 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=== | |||
==APIs== | |||
==OpenGL== | ==OpenGL== | ||
[[File:OpenGL logo.jpg|right|thumb]] | [[File:OpenGL logo.jpg|right|thumb]] |
Revision as of 08:41, 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. DRI drivers are used as part of X11, and require their own X servers. Framebuffer drivers generally accelerate only 2D operations (blitting, rectangular tiling, etc), or none at all. DRI 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
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
- Implementations for embedded devices
- OMAP (Texas Instruments)
- SGX (PowerVR)
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.
OpenGL ES
OpenGL for Embedded Systems.
OpenVG
Vector graphics acceleration targeting embedded systems (ie, often used in conjunction with OpenGL ES).
See Also
- VGA compatible text mode on Wikipedia