Graphics hardware and FOSS

From Wikipedia, the free encyclopedia

Using graphics hardware with free and open source software (FOSS) can be difficult, because some of the leading manufacturers of graphics cards do not provide technical documentation sufficient for independent developers to create accelerated 3D device drivers for their products. In some cases they prefer to provide closed source proprietary binary drivers. Some users, particularly games enthusiasts, are content to use these.^{[citation needed]} Others, however, consider this incompatible with the FOSS ethic, which regards source code as essential for security and quality.^[1] The problem is not exclusive to graphics cards, but is more serious because of the widespread deployment of graphics cards for which accelerated 3D FOSS drivers are not yet available. For some hardware which does not yet have accelerated 3D drivers, XFree86 and X.Org provide 2D drivers, and these are sufficient for many applications.

1 Opinions on binary drivers
2 FOSS support by manufacturer
3 See also
4 References
5 External links

[edit] Opinions on binary drivers

OpenBSD lead developer Theo de Raadt has explained the OpenBSD stance on binary drivers, pointing out that with binary drivers there is "no way to fix it when it breaks (and it will break)" and asserting that once a product which relies on binary drivers is end-of-lifed by the manufacturer, it is effectively "broken."^[2] In addition, de Raadt lists the primary reasons given by hardware vendors for not disclosing hardware details: potential intellectual property and patent lawsuits, disclosure of trade secrets and possible circumvention of FCC restrictions. As part of their wider campaign against binary blobs, the OpenBSD project maintains that binary drivers "hide bugs and workarounds for bugs."^[3] This comment has been somewhat vindicated by flaws found in binary drivers, including in October 2006 an exploitable bug in NVIDIA's 3D drivers.^[4] It is speculated that this bug has existed since 2004, although NVIDIA have denied this, asserting that the issue was only communicated to them in July 2006 and that the 2004 bug was a bug in X.org, not in NVIDIA's driver.^[5]

Most members of the Linux kernel development community dislike binary drivers and ignore people who develop and use them.^[6] They point out that binary kernel modules can only be expected to work with the particular version of the kernel for which they were compiled, whereas FOSS drivers are built into the mainstream kernel source code and thus get built as part of it, allowing users to take compatibility for granted. It may also be the case that binary-only kernel modules, because they do not comply with the GNU General Public License, are a violation of the kernel developers' copyright.^[7]

In a 2006 presentation,^[8] David M. Airlie identified a section of the FOSS community, jokingly referred to as "the conspiracy theorists among us," who blame Microsoft's anti-competitive practices for poor FOSS support by graphics manufacturers. This section has noted that NVIDIA stopped publishing hardware specifications for devices produced after they won the deal for the initial Xbox graphics cards. ATI also withdrew their documentation for graphics cards that support Microsoft DirectX 8.0 and newer, whose design was primarily a collaboration between ATI and Microsoft.^{[citation needed]}

The Digital Rights Management copy-protection scheme in Microsoft Windows Vista operating system relies on the internals of graphics cards to tell whether the hardware is trustworthy (permitted to play copy-protected content). This scheme assumes that an attacker does not know certain details about the hardware's operation, which could be disclosed by hardware documentation or open source drivers. This may have a chilling effect on manufacturers' cooperation with the FOSS community.^[9]

[edit] FOSS support by manufacturer

Manufacturers provide varying degrees of support for FOSS developers and projects. Some hardware has FOSS drivers with little or no help from the manufacturer.

[edit] ATI

ATI has provided documentation under a non-disclosure agreement to some X.Org developers for cards up to the Radeon 9200, but not for more recent chipsets.
X.Org fully supports the Radeon R100 and Radeon R200 cards. Radeon R300 cards are supported by a new reverse engineered driver under development.^[10]

[edit] Intel

Intel has a long history of producing or commissioning open source drivers for its graphics chips. The current version of the X.Org i810 driver supports the i810, i810-DC100, i810e, i815, i830M, 845G, 852GM, 855GM, 865G, 915G, 915GM, 945G, 945GM, 965G, 965Q and 946GZ chipsets.^[11] The driver development is outsourced to Tungsten Graphics. Before the i830 chipset, Intel used to reveal their specifications to the public.^[8]

[edit] NVIDIA

NVIDIA used to provide documentation for the older RIVA TNT series chipsets and supports the open source 2D-only "nv" driver for X.Org. However, it supports neither 3D acceleration nor motion compensation due to the lack of hardware documentation.^[8]^[12]
The nouveau project aims to reverse engineer NVIDIA's cards to produce 3D acceleration for X.Org, but is still at an early stage of development.^[13] It will be included in Fedora 7.^[14]
NVIDIA drivers supporting both 2D and 3D acceleration are available for the Haiku operating system.^[15]
The Plan 9 kernel provides modest 2D acceleration for NVIDIA chipsets, with less than 600 lines of code in the kernel.^[16]^[17]

[edit] Matrox

Matrox provides open source drivers for their chipsets older than the G550; newer chipsets are only supported by a closed source driver.^[8]

[edit] SiS and VIA

SiS and VIA have both shown limited interest and communication regarding open source drivers; however, both have released source code which has later been integrated into X.Org by FOSS developers.^[8]