https://wiki.archlinux.org/api.php?action=feedcontributions&user=TryA&feedformat=atomArchWiki - User contributions [en]2024-03-28T19:42:35ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Mach64&diff=674317Mach642021-05-29T14:54:29Z<p>TryA: Merge kernel issue with DRM driver section</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[ja:Mach64]]<br />
[[wikipedia:ATI_Mach#Mach_64|The Mach 64 chip]] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
== Installing the basic features ==<br />
<br />
2D and Xv acceleration in X can be achieved by [[install]]ing {{AUR|xf86-video-mach64}}.<br />
<br />
Above driver needs root privileges to work properly, but latest Xorg servers start without root privileges. Thus, it may be needed to put the setuid bit on the Xorg server binary in order to use it as a regular user :<br />
<br />
# chmod u+s /usr/lib/Xorg<br />
<br />
{{Warning|This introduces a security breach that could allow a malicious program to obtain root privileges through an unknown vulnerability in Xorg. Use at your own risk.}}<br />
<br />
== 3D acceleration and direct rendering ==<br />
<br />
{{Warning|You may experience crashes if using the Mach 64 DRM driver. Direct rendering on Mach 64 is not very reliable because it never got much support. Also, this driver may have security issues and needs to run on a custom kernel with weakened safety. }}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in the official repositories, but the DRM driver is not included in the mainline kernel. As of at least [https://bbs.archlinux32.org/viewtopic.php?id=2776 June of 2019], the default kernel configuration will not allow the Mach64 driver to successfully load and this error will be reported in the Xorg log:<br />
<br />
$ MACH64(0): Unable to map linear aperture. Invalid argument<br />
<br />
So the driver has to be built separately as a module for [[Kernel/Arch_Build_System|a custom kernel]] for which configuration option {{ic|DRM_LEGACY}} is enabled and {{ic|IO_STRICT_DEVMEM}} is disabled. The [[AUR]] package {{AUR|mach64drm}} can build this driver.<br />
<br />
As soon as the DRM module is built and installed, make sure you installed the DRI part {{Pkg|mach64-dri}}.<br />
<br />
== Configuration ==<br />
<br />
Here is an example of X configuration for a Mach 64 chip (may not be mandatory in all cases):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
# Uncomment the following option if X segfaults as soon as anything using acceleration is called.<br />
# Option "ExaNoComposite" "true"<br />
# The following line will also prevent segmentation faults, but is not recommended since<br />
# it will disable all acceleration.<br />
# Option "NoAccel" "true"<br />
# The following enables the shadow framebuffer, which improves non-accelerated performance.<br />
# Use only with the "NoAccel" option.<br />
# Option "ShadowFB" "true"<br />
EndSection<br />
<br />
Details:<br />
* Driver: most important, allows you to use the mach64 driver.<br />
* DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
* ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
* AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
* AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
* BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
* LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it is not recommended to reduce the buffer size unless you are short on system RAM).<br />
* ExaNoComposite - Required to prevent segmentation faults in EXA handler.<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
Load "vgahw"<br />
Load "fb"<br />
Load "int10"<br />
Load "vbe"<br />
Load "shadowfb"<br />
Load "fbdevhw"<br />
Load "exa"<br />
Load "glamoregl"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
== Testing direct rendering ==<br />
<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=674316Mach642021-05-29T14:45:04Z<p>TryA: New instructions for (waning) support of this GPU on Arch</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[ja:Mach64]]<br />
[[wikipedia:ATI_Mach#Mach_64|The Mach 64 chip]] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
== Installing the basic features ==<br />
<br />
2D and Xv acceleration in X can be achieved by [[install]]ing {{AUR|xf86-video-mach64}}.<br />
<br />
Above driver needs root privileges to work properly, but latest Xorg servers start without root privileges. Thus, it may be needed to put the setuid bit on the Xorg server binary in order to use it as a regular user :<br />
<br />
# chmod u+s /usr/lib/Xorg<br />
<br />
{{Warning|This introduces a security breach that could allow a malicious program to obtain root privileges through an unknown vulnerability in Xorg. Use at your own risk.}}<br />
<br />
== 3D acceleration and direct rendering ==<br />
<br />
{{Warning|You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in the official repositories, but the DRM driver is not included in the mainline kernel. So we have to build it separately as a module for a custom kernel for which configuration option {{ic|DRM_LEGACY}} is enabled and {{ic|IO_STRICT_DEVMEM}} is disabled. The [[AUR]] package {{AUR|mach64drm}} can build this driver.<br />
<br />
As soon as the DRM module is built and installed, make sure you installed the DRI part {{Pkg|mach64-dri}}.<br />
<br />
== Configuration ==<br />
<br />
Here is an example of X configuration for a Mach 64 chip (may not be mandatory in all cases):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
# Uncomment the following option if X segfaults as soon as anything using acceleration is called.<br />
# Option "ExaNoComposite" "true"<br />
# The following line will also prevent segmentation faults, but is not recommended since<br />
# it will disable all acceleration.<br />
# Option "NoAccel" "true"<br />
# The following enables the shadow framebuffer, which improves non-accelerated performance.<br />
# Use only with the "NoAccel" option.<br />
# Option "ShadowFB" "true"<br />
EndSection<br />
<br />
Details:<br />
* Driver: most important, allows you to use the mach64 driver.<br />
* DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
* ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
* AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
* AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
* BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
* LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it is not recommended to reduce the buffer size unless you are short on system RAM).<br />
* ExaNoComposite - Required to prevent segmentation faults in EXA handler.<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
Load "vgahw"<br />
Load "fb"<br />
Load "int10"<br />
Load "vbe"<br />
Load "shadowfb"<br />
Load "fbdevhw"<br />
Load "exa"<br />
Load "glamoregl"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
== Testing direct rendering ==<br />
<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".<br />
<br />
== Kernel Issue ==<br />
<br />
As of at least [https://bbs.archlinux32.org/viewtopic.php?id=2776 June of 2019] the default kernel configuration will not allow the Mach64 driver to successfully load and this error will be reported in the Xorg log<br />
<br />
$ MACH64(0): Unable to map linear aperture. Invalid argument<br />
<br />
The Mach64 driver can still be used by [[Kernel/Arch_Build_System|compiling and installing]] a version of the kernel with the "CONFIG_IO_STRICT_DEVMEM" option disabled as noted in the linked forum post. This may have a negative impact on overall system security.</div>TryAhttps://wiki.archlinux.org/index.php?title=Polkit&diff=218024Polkit2012-08-15T17:27:40Z<p>TryA: </p>
<hr />
<div>[[Category:Security]]<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Action groups==<br />
The actions available to you via PolicyKit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.archlinux.pkexec.gparted.policy). The command{{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference. <br />
<br />
To get an idea of what PolicyKit can do, here are a few commonly used groups of actions:<br />
* '''[[ConsoleKit]]''' (''org.freedesktop.consolekit.policy'') actions regulated by PolicyKit include shutting down and restarting, including when other users may still be logged in.<br />
* '''[[Upower]]''' (''org.freedesktop.upower.policy'') actions regulated by PolicyKit include [[suspend_to_RAM|suspending]] and [[Pm-utils#Suspend.2FHibernate_as_regular_user|hibernating]].<br />
* '''[[udisks|Udisks2]]''' (''org.freedesktop.udisks2.policy'') actions regulated by PolicyKit include mounting file systems and unclocking encrypted devices.<br />
* '''[[NetworkManager]]''' (''org.freedesktop.NetworkManager.policy'') actions regulated by PolicyKit include turning on and off the network, wifi, or mobile broadband.<br />
<br />
==Limitations==<br />
PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the [[Sudo|sudoers file]] is still the way to go.<br />
<br />
==Examples==<br />
<br />
===Suspend and hibernate===<br />
<br />
To give the users in the group '''power''' the permission to suspend or hibernate using Upower, it is sufficient to create an authority file {{ic|/etc/polkit-1/localauthority/50-local.d/org.freedesktop.upower.pkla}} that allows group members the use of the two actions:<br />
<br />
[Suspend/hibernate permissions]<br />
Identity=unix-group:power<br />
Action=org.freedesktop.upower.hibernate;org.freedesktop.upower.suspend<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
<br />
Since the action groups change occasionally, it might be useful to check the documentation in {{ic|/usr/share/polkit-1/actions/org.freedesktop.upower.policy}} to make sure that the actions are correct.<br />
<br />
===Mounting USB drives===<br />
<br />
To grant users in the '''storage''' group the permission to mount/unmount/eject disks via Udisks2, the following lines can be written into a file {{ic|/etc/polkit-1/localauthority/50-local.d/org.freedesktop.udisks2.pkla}}:<br />
<br />
[Storage Permissions]<br />
Identity=unix-group:storage<br />
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.modify-device<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
<br />
==Documentation==<br />
<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>TryAhttps://wiki.archlinux.org/index.php?title=Polkit&diff=218023Polkit2012-08-15T17:26:20Z<p>TryA: /* Mounting USB drives */</p>
<hr />
<div>[[Category:Security]]<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Action groups==<br />
The actions available to you via PolicyKit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.archlinux.pkexec.gparted.policy). The command{{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference. <br />
<br />
To get an idea of what PolicyKit can do, here are a few commonly used groups of actions:<br />
* '''[[ConsoleKit]]''' (''org.freedesktop.consolekit.policy'') actions regulated by PolicyKit include shutting down and restarting, including when other users may still be logged in.<br />
* '''[[Upower]]''' (''org.freedesktop.upower.policy'') actions regulated by PolicyKit include [[suspend_to_RAM|suspending]] and [[Pm-utils#Suspend.2FHibernate_as_regular_user|hibernating]].<br />
* '''[[udisks|Udisks2]]''' (''org.freedesktop.udisks2.policy'') actions regulated by PolicyKit include mounting file systems and unclocking encrypted devices.<br />
* '''[[NetworkManager]]''' (''org.freedesktop.NetworkManager.policy'') actions regulated by PolicyKit include turning on and off the network, wifi, or mobile broadband.<br />
<br />
==Limitations==<br />
PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the [[Sudo|sudoers file]] is still the way to go.<br />
<br />
==Examples==<br />
<br />
===Suspend and hibernate===<br />
<br />
To give the users in the group '''power''' the permission to suspend or hibernate using Upower, it is sufficient to create an authority file {{ic|/etc/polkit-1/localauthority/50-local.d/org.freedesktop.upower.pkla}} that allows group members the use of the two actions:<br />
<br />
[Suspend/hibernate permissions]<br />
Identity=unix-group:power<br />
Action=org.freedesktop.upower.hibernate;org.freedesktop.upower.suspend<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
<br />
Since the action groups change occasionally, it might be useful to check the documentation in {{ic|/usr/share/polkit-1/actions/org.freedesktop.upower.policy}} to make sure that the actions are correct.<br />
<br />
===Mounting USB drives===<br />
<br />
To grant users in the '''storage''' group the permission to mount/unmount/eject disks via Udisks2, the following lines can be written into a file {{ic|/etc/polkit-1/localauthority/50-local.d/org.freedesktop.udisks2.pkla}}:<br />
<br />
[Storage Permissions]<br />
Identity=unix-group:storage<br />
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.modify-device<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
<br />
==Documentation==<br />
<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>TryAhttps://wiki.archlinux.org/index.php?title=Udev&diff=218019Udev2012-08-15T17:20:57Z<p>TryA: /* Mount drives as a normal user */</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting]]<br />
[[cs:Udev]]<br />
[[es:Udev]]<br />
[[it:Udev]]<br />
[[ru:Udev]]<br />
[[zh-CN:Udev]]<br />
[[zh-TW:Udev]]<br />
{{Lowercase title}}<br />
<br />
{{ic|udev}} replaces the functionality of both {{Ic|hotplug}} and {{Ic|hwdetect}}.<br />
<br />
''"udev is the device manager for the Linux kernel. Primarily, it manages device nodes in {{ic|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{ic|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [[Wikipedia:Udev|Wikipedia article]]<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, {{ic|/dev/sda}} may randomly become {{ic|/dev/sdb}}. See below for more info on this.<br />
<br />
{{Note|1=Systemd and udev have been merged upstream. Udev will now be part of a package called {{pkg|systemd-tools}}. This package contains several other standalone tools which can be used without systemd. See [http://www.archlinux.org/news/systemd-tools-replaces-udev/ the announcement].}}<br />
<br />
== About udev rules ==<br />
udev rules written by the administrator go in {{ic|/etc/udev/rules.d/}}, their file name has to end with {{ic|.rules}}. The udev rules shipped with various packages are found in {{ic|/usr/lib/udev/rules.d/}}. If there are two files by the same name under {{ic|/usr/lib}} and {{ic|/etc}}, the ones in {{ic|/etc}} take precedence.<br />
<br />
If you want to learn how to write udev rules, see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all of the attributes of a device you can use to write rules, run this command:<br />
# udevadm info -a -n [device name]<br />
<br />
Replace {{ic|[device name]}} with the device present in the system, such as {{ic|/dev/sda}} or {{ic|/dev/ttyUSB0}}.<br />
<br />
udev automatically detects changes to rules files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices, so hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
<br />
== UDisks ==<br />
Simply [[pacman|install]] the {{pkg|udisks}} package, and all of your media should be automatically mounted in [[GNOME]] and [[KDE]] SC 4.6. There is no need for any additional rules this way. Be aware that udisks2 is a compatibility-breaking rewrite of udisks and is the version currently [http://www.archlinux.org/packages/extra/x86_64/udisks2/ required] by GNOME, whereas XFCE and KDE seem to still [http://www.archlinux.org/packages/extra/x86_64/udisks/ require] udisks.<br />
<br />
As an extra bonus you can remove [[HAL]] if you were only using that for auto mounting purposes.<br />
<br />
=== Automounting UDisks Wrappers ===<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - {{AUR|devmon}} is a configuration-less Bash wrapper script for udisks which automatically mounts optical discs and removable drives. It can also selectively automatically start applications or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. A git version called {{AUR|devmon-git}} is also available.<br />
* {{AUR|ldm}} - A lightweight daemon that mounts usb drives, cds, dvds or floppys automagically. [https://bbs.archlinux.org/viewtopic.php?id=125918]<br />
* [[udiskie]] - Written in Python. Enables automatic mounting and unmounting by any user.<br />
* {{AUR|udisksevt}} - Written in Haskell. Enables automatic mounting by any user. Designed to be integrated with {{AUR|traydevice}}.<br />
* {{AUR|udisksvm}} - A GUI UDisks wrapper which uses the udisks2 dbus interface. It calls a 'traydvm' script, included in the package. The 'traydvm' GUI utility is a script which displays a systray icon for a plugged-in device, with a right-click menu to perform simple actions on the device. As the automount function can be disabled, this tool should work with other automounting tools, to show system tray icons. It is independent of any file manager.<br />
<br />
* You can easily automount and eject removable devices with the combination of {{pkg|pmount}}, {{pkg|udisks2}} and {{pkg|spacefm}}. Note you have to run spacefm in daemon mode with {{ic|spacefm -d &}} in your startup scripts, {{ic|~/.xinitrc}} or {{ic|~/.xsession}}, to get automounting. You can also mount internal disks by adding them to {{ic|/etc/pmount.allow}}.<br />
<br />
=== UDisks Shell Functions ===<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - {{AUR|bashmount}} is a menu-driven Bash script with a configuration file that makes it easy to configure and extend.<br />
<br />
==Tips and tricks==<br />
<br />
=== Accessing Firmware Programmers and USB Virtual Comm Devices ===<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter and the [http://www.atmel.com/tools/AVRDRAGON.aspx?tab=overview Atmel AVR Dragon] programmer. Adjust the permissions accordingly. Verified as of 22-06-2012.<br />
<br />
{{hc|/etc/udev/rules.d/50-embedded_devices.rules|2=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
# USBasp Programmer rules http://www.fischl.de/usbasp/<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
<br />
#Atmel AVR Dragon (dragon_isp) rules<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2107", GROUP="users", MODE="0666"<br />
<br />
#Atmel AVR JTAGICEMKII rules<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2103", GROUP="users", MODE="0666"<br />
<br />
</nowiki>}}<br />
<br />
=== Execute on USB Insert ===<br />
See the [[Execute on USB insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount drives as a normal user ===<br />
If you want to mount an internal drive in your Desktop Environments as a normal user (without the need to type your superuser password), you just have to create one of the following file in [[PolicyKit]] Local Authority depending on whether you use udisks (KDE, XFCE) or udisks2 (newer GNOME) (if in doubt run a {{ic|pacman -Qi udisks2}} to see). The setting extends the privilege to all members of the 'users' group but you can substitute {{ic|unix-user:USERNAME}} for the group setting for individual privileges. See [[PolicyKit]] for details.<br />
<br />
This example configuration allows any member of the {{ic|users}} group to mount and unmount disks with udisks or udisk2. If it doesn't already exist, create the file {{ic|/etc/polkit-1/localauthority/50-local.d/10-udisks.pkla}} with these contents:<br />
<br />
'''udisks'''<br />
[Local Users]<br />
Identity=unix-group:users<br />
Action=org.freedesktop.udisks.*<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
'''udisk2'''<br />
[Local Users]<br />
Identity=unix-group:users<br />
Action=org.freedesktop.udisks2.*<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
<br />
====Internal drives only====<br />
'''udisks'''<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla|2=<nowiki><br />
[Mount a system-internal device]<br />
Identity=unix-group:users<br />
Action=org.freedesktop.udisks.filesystem-mount-system-internal<br />
ResultActive=yes<br />
</nowiki>}}<br />
'''udisks2'''<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla|2=<nowiki><br />
[Mount a system-internal device]<br />
Identity=unix-group:users<br />
Action=org.freedesktop.udisks2.filesystem-mount-system<br />
ResultActive=yes <br />
</nowiki>}}<br />
<br />
=== Mark internal SATA-Ports as eSATA-Ports ===<br />
If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. Gnome and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal Gnome user can connect their eSATA drives to that port like a USB drive, without any root password and so on.<br />
<br />
{{hc|/etc/udev/rules.d/10-esata.rules|2=<nowiki><br />
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM_INTERNAL}="0"<br />
</nowiki>}}<br />
<br />
{{Note| The DEVPATH can be found after connection the eSata drive with the following command (replace sdb to your needs):<br />
<br />
# find /sys/devices/ -name sdb<br />
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb<br />
<br />
}}<br />
<br />
=== Setting static device names ===<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. A udev rule can be added to use static device names, but preferably names other than "ethX" and "wlanX".<br />
<br />
==== Network device ====<br />
For example, with two network cards, you may notice a switching of designations between {{Ic|eth0}} and {{Ic|eth1}} between reboots.<br />
<br />
One method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{hc|/etc/udev/rules.d/10-network.rules|2=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wifi0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Ic|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* When choosing the static names it should be avoided to use "ethX" and "wlanX", because this may lead to race conditions between the kernel und udev during boot. Instead better use interface names that are not used by the kernel as default, e.g. "net0, net1, wifi0, wifi1"<br />
<br />
Don't forget to update your {{ic|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
==== iscsi device ====<br />
Test the output from scsi_id:<br />
/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sdb<br />
3600601607db11e0013ab5a8e371ce111<br />
<br />
{{hc|/etc/udev/rules.d/75-iscsi.rules|<nowiki><br />
# the iscsi device rules<br />
# this will create an iscsi device for each of the targets<br />
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace /dev/$name", RESULT=="3600601607db11e0013ab5a8e371ce111",<br />
NAME="isda"<br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
=== Blacklisting Modules ===<br />
In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{ic|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
==== BusLogic devices can be broken and will cause a freeze during startup ====<br />
This is a kernel bug and no fix has been provided yet.<br />
<br />
==== Some devices, that should be treated as removable, are not ====<br />
Create a custom udev rule, setting {{ic|UDISKS_SYSTEM_INTERNAL<nowiki>=</nowiki>0}}. For more details, see the manpage of udisks.<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use [[CPU Frequency Scaling]], load the proper module explicitly in your {{Ic|MODULES}} array in {{ic|/etc/rc.conf}}. Further reading: [[rc.conf]].<br />
<br />
==== Sound Problems or Some Modules Not Loaded Automatically ====<br />
Some users have traced this problem to old entries in {{ic|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
{{Note|Since {{Ic|udev>&#61;171}}, the OSS emulation modules ({{Ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) are not automatically loaded by default.}}<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.32. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
=== IDE CD/DVD-drive support ===<br />
Starting with version 170, udev doesn't support CD-ROM/DVD-ROM drives, which are loaded as traditional IDE drives with the {{Ic|ide_cd_mod}} module and show up as {{ic|/dev/hd*}}. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.<br />
<br />
A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
=== Optical Drives Have Group ID Set To Disk ===<br />
If the group ID of your optical drive is set to ''disk'' and you want to have it set to ''optical'' you have to create a custom udev rule:<br />
{{hc|/etc/udev/rules.d|2=# permissions for IDE CD devices<br />
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"<br />
<br />
# permissions for SCSI CD devices<br />
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"}}<br />
<br />
==See also==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=217701Mach642012-08-13T20:10:04Z<p>TryA: </p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [community], but the DRM module is not included in the mainline kernel. So we have to build it separately. A package in the [[AUR]] simplifies this task: {{AUR|mach64drm}}.<br />
<br />
As soon as the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Tor&diff=160188Tor2011-09-16T20:10:41Z<p>TryA: Fixed dead links</p>
<hr />
<div>[[Category:Internet Applications (English)]]<br />
[[Category:Proxy servers (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
{{i18n|Tor}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article will explain how to install and configure Tor alongside HTTP proxies like Privoxy and Polipo.}}<br />
{{Article summary heading|Required software}}<br />
{{Article summary link|Tor|https://www.torproject.org/download/download.html.en}}<br />
{{Article summary link|Privoxy|http://www.privoxy.org/}}<br />
{{Article summary link|Polipo|http://www.pps.jussieu.fr/~jch/software/polipo/}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Privoxy}}<br />
{{Article summary wiki|Polipo}}<br />
{{Article summary end}}<br />
<br />
'''Tor''' is an open source implementation of 2nd generation [[Wikipedia:Onion routing|onion routing]] that provides free access to an anonymous proxy network. Its primary goal is to enable [[Wikipedia:internet anonymity|online anonymity]] by protecting against [[Wikipedia:Traffic analysis|traffic analysis]] attacks.<br />
<br />
==Introduction==<br />
{{Wikipedia|Tor (anonymity network)}}<br />
Users of the Tor network run an onion proxy on their machine. This software connects out to Tor, periodically negotiating a virtual circuit through the Tor network. Tor employs cryptography in a layered manner (hence the 'onion' analogy), ensuring perfect forward secrecy between routers. At the same time, the onion proxy software presents a SOCKS interface to its clients. SOCKS-aware applications may be pointed at Tor, which then multiplexes the traffic through a Tor virtual circuit.<br />
<br />
{{Warning|Tor by itself is ''not'' all you need to maintain your anonymity. There are several major pitfalls to watch out for (see: [https://www.torproject.org/download/download.html.en#warning Want Tor to really work?]).}}<br />
<br />
Through this process the onion proxy manages networking traffic for end-user anonymity. It keeps a user anonymous by encrypting traffic, sending it through other nodes of the Tor network, and decrypting it at the last node to receive your traffic before forwarding it to the server you specified. Although Tor is considerably safer than the commonly used direct DNS connections (i.e. without a proxy), it can be considerably slower due to the large amount of traffic re-routing. Additionally, although Tor provides protection against traffic analysis it cannot prevent traffic confirmation at the boundaries of the Tor network (i.e. the traffic entering and exiting the network).<br />
<br />
==Installation==<br />
Install the Tor package located in {{Codeline|[community]}} using [[Pacman]].<br />
# pacman -S tor<br />
<br />
==Configuration==<br />
To get a better understanding of Tor review the {{filename|/etc/tor/torrc}} configuration file. The configuration options are explained in {{Codeline|man tor}} and the [https://www.torproject.org/docs/tor-manual.html.en Tor website]. <br />
<br />
The default configuration should work fine for most Tor users, with the one notable exception being those using Vidalia, a Qt GUI frontend for Tor. There is a [https://aur.archlinux.org/packages.php?ID=9731 Vidalia package] available in the [[AUR]]. In addition to controlling the process Vidalia allows you to view the status of Tor; monitor bandwidth usage; view, filter, and search log messages; and configure some aspects of Tor.<br />
<br />
You can set custom file descriptor ulimits for Tor in {{filename|/etc/conf.d/tor}} using the {{Codeline|TOR_MAX_FD}} variable.<br />
<br />
===Logging===<br />
By default Tor logs to "stdout" at log-level notice. If you enable logs in your {{filename|torrc}} file, they default to {{Codeline|/usr/local/var/log/tor/}}.<br />
<br />
==Usage==<br />
To start Tor issue the following command as root to start the Tor service:<br />
# /etc/rc.d/tor start<br />
<br />
To start Tor at boot add {{Codeline|tor}} to the {{Codeline|DAEMONS}} array in {{Filename|/etc/rc.conf}}:<br />
DAEMONS=(... '''tor''' ...)<br />
<br />
To check if TOR is functioning properly visit the [https://check.torproject.org/ Tor], [http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1 Harvard] or [https://torcheck.xenobite.eu/ Xenobite.eu] websites.<br />
<br />
==Web browsing==<br />
Tor is supported primarily by Firefox, but can also be used with Chromium.<br />
<br />
===Firefox===<br />
If you use Firefox, you can install this plug-in: [https://www.torproject.org/torbutton/ TorButton].<br />
This will allow you to toggle very easily between tor navigation and normal navigation.<br />
If you're using multiple Proxies (for example if you want to use both TOR and "ssh -D") then there's also an addon called "[https://addons.mozilla.org/en-us/firefox/addon/foxyproxy-standard/ FoxyProxy]" for Firefox which allows you to specify multiple Proxies for different URLs or for all your browsing. Just point it to port 8118 (where polipo is running) on localhost.<br />
To test it, point your browser to [https://check.torproject.org/ this website] with and without tor enabled.<br />
<br />
Please read [https://www.torproject.org/docs/tor-doc-unix.html.en the official doc] for more infos.<br />
<br />
===Chromium===<br />
You do not need polipo to use TOR with Chromium. Simply start the TOR daemon, and run:<br />
$ chromium --proxy-server="socks://localhost:9050"<br />
<br />
==Irssi with Tor==<br />
Freenode does not recommend that you use Privoxy with [[Irssi]]. Instead they recommend using the {{Codeline|mapaddress}} approach and running {{Codeline|torify irssi}} to start it up. Therefore, add the following to {{Filename|/etc/tor/torrc}}:<br />
mapaddress 10.40.40.40 p4fsi4ockecnea7l.onion<br />
<br />
Freenode requires charybdis and ircd-seven's SASL mechanism for identifying to nickserv during<br />
connection. Download {{filename|cap_sasl.pl}}, which enables SASL, from the Freenode website (i.e. http://www.freenode.net/sasl/cap_sasl.pl) and save it to {{Codeline|~/.irssi/scripts/cap_sasl.pl}}<br />
<br />
Then install the following required perl modules with [[pacman]] and then [http://aur.archlinux.org/packages.php?ID=34386 Crypt::DH] from the [[AUR]].<br />
$ pacman -S perl-crypt-openssl-bignum perl-crypt-blowfish<br />
Alternatively, you can install the modules using perl:<br />
$ perl -MCPAN -e 'install Crypt::OpenSSL::Bignum Crypt::DH Crypt::Blowfish'<br />
<br />
Start irssi <br />
$ torify irssi<br />
<br />
Load the script that will employ the SASL mechanism.<br />
/script load cap_sasl.pl<br />
<br />
Set your identification to nickserv, which will be read when connecting. Supported mechanisms are PLAIN and DH-BLOWFISH. <br />
/sasl set <network> <username> <password> <mechanism><br />
<br />
Connect to Freenode:<br />
/connect -network <network> 10.40.40.40<br />
<br />
For more information check [http://freenode.net/irc_servers.shtml#tor Accessing freenode Via Tor] and the [http://freenode.net/sasl/README.txt SASL README] at freenode.net or the [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IrcSilc IRC/SILC Wiki article] at torproject.org.<br />
<br />
===Troubleshooting===<br />
If you are having errors check [https://bbs.archlinux.org/viewtopic.php?pid=956467 this thread].<br />
<br />
==Tor with an HTTP Proxy==<br />
If you need an HTTP proxy.<br />
<br />
{{note|Polipo is now recommended over Privoxy by the Tor dev team. <sup>[Source Needed]</sup>}}<br />
<br />
===Polipo===<br />
Polipo is a small and fast HTTP proxy. Install and configure according to the [[Polipo]] article. The Tor Project has created a custom [https://gitweb.torproject.org/torbrowser.git/blob_plain/HEAD:/build-scripts/config/polipo.conf Polipo configuration file] to prevent potential problems with Polipo as well to provide better anonymity.<br />
<br />
Keep in mind that polipo is not required if you can use a SOCKS 5 proxy, which TOR starts automatically on port 9050. Notably, if you want to use [[Chromium]] to use TOR, you do not need the polipo package. See [[#Chromium and tor|below]] on how to use TOR with [[Chromium]].<br />
<br />
===Privoxy===<br />
Privoxy is an HTTP proxy that speaks SOCKS4a and does html/cookie scrubbing. It can be installed and configured according to the [[Privoxy]] article.<br />
<br />
====Tor and Privoxy in Firefox====<br />
The easiest way to do this is to use the [https://www.torproject.org/torbutton Torbutton] extension.<br />
<br />
Alternatively, you can use [https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard Foxyproxy]. After restarting Firefox you will have a new toolbar. Click ''Add'', select ''Standard proxy type''. Choose whatever ''Proxy Label'' you want, e.g ''Tor''. Enter into both the ''HTTP Proxy'' and ''SSL Proxy'' fields:<br />
<br />
Hostname: 127.0.0.1 Port: 8118<br />
<br />
This will point Firefox at Privoxy. You can also add exceptions in the ''No Proxy for'' field.<br />
<br />
Now, return to http://whatsmyip.net/ and check so that your IP is diffrent from before.<br />
<br />
====Tor and Privoxy in other applications====<br />
You can also use this setup in other applications like instant messaging, Jabber, IRC, etc.<br />
<br />
Applications that support HTTP proxies you can point at Privoxy (127.0.0.1 port 8118).<br />
<br />
To use SOCKS proxy directly, you can point your application at Tor (127.0.0.1 port 9050). A problem with this method though is that applications doing DNS resolves by themselves may leak information. Consider using Socks4A (e.g. via privoxy) instead.<br />
<br />
==Running a Tor Server==<br />
===Configuration===<br />
You should at least share 20kb/s:<br />
Nickname <tornickname><br />
ORPort 9001<br />
BandwidthRate 20 KB # Throttle traffic to 20KB/s<br />
BandwidthBurst 50 KB # But allow bursts up to 50KB/s<br />
<br />
Allow irc ports 6660-6667 to exit from node:<br />
ExitPolicy accept *:6660-6667,reject *:* # Allow irc ports but no more<br />
<br />
Run Tor as an exit node:<br />
ExitPolicy accept *:119 # Accept nntp as well as default exit policy<br />
<br />
Run Tor as middleman:<br />
ExitPolicy reject *:*<br />
<br />
==TorDNS==<br />
The Tor 0.2.x series provides a built-in DNS forwarder. To enable it add the following lines to the Tor configuration file:<br />
{{file|/etc/tor/torrc|<br />
DNSPort 9053<br />
AutomapHostsOnResolve 1<br />
AutomapHostsSuffixes .exit,.onion<br />
}}<br />
And restart Tor to load the updated configuration file:<br />
/etc/rc.d/tor restart<br />
<br />
This will allow Tor to accept DNS requests (listening on port 9053 in this example) like a regular DNS server, and resolve the domain via the Tor network. A downside is that it's only able to resolve DNS queries for A-records; MX and NS queries are never answered. For more information see this [https://techstdout.boum.org/TorDns/ Debian-based introduction].<br />
<br />
DNS queries can also be performed through a command line interface by using {{Codeline|<nowiki>tor-resolve</nowiki>}}. For example:<br />
<pre><br />
$ tor-resolve archlinux.org<br />
66.211.214.131<br />
</pre><br />
<br />
==Torify==<br />
<br />
{{Codeline|<nowiki>torify</nowiki>}} will allow you use an application via the Tor network without the need to make configuration changes to the application involved. From the man page:<br />
<pre><br />
torify is a simple wrapper that calls tsocks with a tor specific configuration<br />
file.<br />
<br />
tsocks itself is a wrapper between the tsocks library and the application that<br />
you would like to run socksified<br />
</pre><br />
Usage example:<br />
<pre><br />
$ torify elinks checkip.dyndns.org<br />
$ torify wget -qO- https://check.torproject.org/ | grep -i congratulations<br />
</pre><br />
<br />
Torify ''will not'', however, perform DNS lookups through the Tor network. A workaround is to use it in conjunction with {{Codeline|<nowiki>tor-resolve</nowiki>}} (described above). In this case, the procedure for the first of the above examples would look like this:<br />
<pre><br />
$ tor-resolve checkip.dyndns.org<br />
208.78.69.70<br />
$ torify elinks 208.78.69.70<br />
</pre><br />
<br />
==Troubleshooting==<br />
<br />
===Problem with User value===<br />
<br />
If the ''tor'' daemon failed to start, then run the following command as root (or use sudo)<br />
<br />
# tor<br />
<br />
If you get the following error<br />
<br />
May 23 00:27:24.624 [warn] Error setting groups to gid 43: "Operation not permitted".<br />
May 23 00:27:24.624 [warn] If you set the "User" option, you must start Tor as root.<br />
May 23 00:27:24.624 [warn] Failed to parse/validate config: Problem with User value. See logs for details.<br />
May 23 00:27:24.624 [err] Reading config failed--see warnings above.<br />
<br />
Then it means that the problem is with the User value. So proceed with the following steps.<br />
<br />
Check the permissions of the directory {{Filename|/var/lib/tor}} by running<br />
<br />
# ls -l /var/lib/<br />
<br />
If the permission for {{Filename|/var/lib/tor}} is as shown below<br />
<br />
drwx------ 2 tor tor 4096 May 12 21:03 tor<br />
<br />
This means that the directory is owned by the user ''tor'' and the group ''tor''.<br />
Change the owner to the user ''root'', and the group ''root'' with the command:<br />
<br />
# chown -R root:root /var/lib/tor<br />
<br />
If you check the permissions again, it should now show<br />
<br />
drwx------ 2 root root 4096 May 12 21:03 tor<br />
<br />
Now open {{Filename|/etc/tor/torrc}} and find the following lines<br />
<br />
## Uncomment this to start the process in the background... or use<br />
## --runasdaemon 1 on the command line.<br />
RunAsDaemon 1<br />
User tor<br />
Group tor<br />
<br />
Comment out the lines ''User tor'' and ''Group tor'', so that the lines read as <br />
<br />
## Uncomment this to start the process in the background... or use<br />
## --runasdaemon 1 on the command line.<br />
RunAsDaemon 1<br />
#User tor<br />
#Group tor<br />
<br />
Save the changes and restart the ''tor'' daemon, it should now work.<br />
<br />
# /etc/rc.d/tor restart<br />
<br />
== External Links ==<br />
* [https://www.torproject.org/ Official Website]<br />
* [https://trac.torproject.org/projects/tor/wiki#Unixish Unix-based Tor Articles]<br />
* [https://trac.torproject.org/projects/tor/wiki/doc/SupportPrograms Software commonly integrated with Tor]<br />
* [https://www.torproject.org/docs/tor-hidden-service.html.en How to set up a Tor ''Hidden Service'']</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=126439Mach642010-12-31T05:50:23Z<p>TryA: </p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but the DRM module is not included in the mainline kernel. So we have to build it separately. A package in the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
<br />
As soon as the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=122121Mach642010-11-23T07:47:00Z<p>TryA: Undo revision 122120 by TryA (talk)</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with Arch's xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but the DRM module is not included in the mainline kernel. So we have to build it separately. A package in the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
<br />
As soon as the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=122120Mach642010-11-23T07:46:29Z<p>TryA: /* Installing the basic features */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with xf86-video-mach64 ([extra] repository):<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but the DRM module is not included in the mainline kernel. So we have to build it separately. A package in the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
<br />
As soon as the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=122119Mach642010-11-23T07:45:39Z<p>TryA: /* 3D acceleration and direct rendering */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with Arch's xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but the DRM module is not included in the mainline kernel. So we have to build it separately. A package in the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
<br />
As soon as the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=121787Mach642010-11-19T10:39:53Z<p>TryA: /* 3D acceleration and direct rendering */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with Arch's xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but the DRM module is not included in the mainline kernel. So we have to build it separately. A package in the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
<br />
As soon the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=121755Mach642010-11-18T23:36:13Z<p>TryA: /* Testing direct rendering */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with Arch's xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but a DRM module which is not included in the mainline kernel is also needed. So we have to build it separately. A package on the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
<br />
As soon the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
$ glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=121754Mach642010-11-18T23:34:53Z<p>TryA: /* 3D acceleration and direct rendering */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with Arch's xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but a DRM module which is not included in the mainline kernel is also needed. So we have to build it separately. A package on the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
<br />
As soon the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=121753Mach642010-11-18T23:34:26Z<p>TryA: </p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites. Its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with Arch's xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but a DRM module which is not included in the mainline kernel is also needed. So we have to build it separately. A package on the [[AUR]] simplifies this task: {{Package AUR|mach64drm}}.<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
<br />
As soon the DRM module is built and installed, make sure you installed the DRI part:<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=121752Mach642010-11-18T23:33:07Z<p>TryA: Cleanup and simplification (first glance)</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[http://en.wikipedia.org/wiki/ATI_Mach#Mach_64 The Mach 64 chip] is an old graphic accelerator developped by ATI. This board has basic 3D capabilites, but its support on Linux is poor but exists. This page is a walkthrough to setup Mach 64 graphics chipsets (including ATI Rage Pro) and obtain direct rendering on some of them.<br />
<br />
==Installing the basic features==<br />
2D and Xv acceleration in X can be achieved with Arch's xf86-video-mach64:<br />
# pacman -S xf86-video-mach64<br />
<br />
==3D acceleration and direct rendering==<br />
On Linux, the Mach 64 chip uses the DRI/DRM system for direct rendering. The DRI part is available in [extra], but a DRM module which is not included in the mainline kernel is also needed. So we have to build it separately. A package on the [[AUR]] simplifies this task : {{Package AUR|mach64drm}}.<br />
{{Warning | You may experience crashes if using the Mach 64 DRM module. Direct rendering on Mach 64 is not very reliable because it never got much support.}}<br />
<br />
As soon the DRM module is built and installed, make sure you installed the DRI part :<br />
# pacman -S mach64-dri<br />
<br />
==Configuration==<br />
Here is an example of X configuration for a Mach 64 chip (not mandatory):<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing direct rendering==<br />
Restart X. After you are in X, you can run the command:<br />
glxinfo | egrep "direct rendering|OpenGL renderer"<br />
This should return something like this:<br />
Direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer", DRI is not working, even if direct rendering says "yes".</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=120516Font configuration2010-11-02T11:18:33Z<p>TryA: /* Original LCD packages */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For [[fonts]] to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format:<br />
<br />
$ fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hint style ====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
==== LCD filter ====<br />
<br />
The {{Codeline|lcddefault}} filter will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
== LCD patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''-cleartype'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from the [[AUR]] to enable the lcddefault filter automatically or see [[#LCD filter]] if you want to set the LCD filter manually.<br />
<br />
In order to get filtering with apps using libXft for font drawing, you need to install [http://aur.archlinux.org/packages.php?ID=37044 libxft-lcd], which have been moved into the [[AUR]].<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
Install the patched packages from the [[AUR]]. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
{{Note|The -cleartype packages are out of date. Consider using the newer infinality patches instead.}}<br />
<br />
These packages attempt to emulate ClearType, a type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Install the patched packages from the [[AUR]]. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=38888 freetype2-infinality] from the [[AUR]].<br />
<br />
Additionally, if you are using lib32-freetype2 from [multilib], replace it with [http://aur.archlinux.org/packages.php?ID=40264 lib32-freetype-infinality].<br />
<br />
{{Note|The infinality package is designed to work with [http://www.infinality.net/files/local.conf this local.conf]. You will most likely want to make changes to the configuration before using it (it makes a lot of font replacements, etc.)}}<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, reinstall the originals:<br />
<br />
# pacman -S --asdeps freetype2 libxft cairo fontconfig<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# cd /etc/fonts/conf.d<br />
# rm 70-yes-bitmaps.conf<br />
# ln -s ../conf.avail/70-no-bitmaps.conf<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/29-replace-bitmap-fonts.conf<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Blurry fonts with Ubuntu patches ===<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display Size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=118974Font configuration2010-10-10T10:52:26Z<p>TryA: /* Original LCD packages */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For [[fonts]] to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format:<br />
<br />
$ fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hint style ====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
==== LCD filter ====<br />
<br />
The {{Codeline|lcddefault}} filter will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
== LCD filter patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''-cleartype'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from the [[AUR]] to enable the lcddefault filter or see [[#LCD filter]] if you want to set the LCD filter manually.<br />
<br />
In order to get filtering with apps using libXft for font drawing, you should also install libxft-lcd from [community]:<br />
# pacman -S --asdeps libxft-lcd<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
Install the patched packages from the [[AUR]]. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
Cleartype is a different type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Install the patched packages from the [[AUR]]. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=38888 freetype2-infinality] from the [[AUR]].<br />
<br />
Additionally, if you are using lib32-freetype2 from [multilib], replace it with [http://aur.archlinux.org/packages.php?ID=40264 lib32-freetype-infinality].<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, reinstall the originals:<br />
<br />
# pacman -S --asdeps freetype2 libxft cairo<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# cd /etc/fonts/conf.d<br />
# rm 70-yes-bitmaps.conf<br />
# ln -s ../conf.avail/70-no-bitmaps.conf<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/29-replace-bitmap-fonts.conf<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Blurry fonts with Ubuntu patches ===<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display Size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=118973Font configuration2010-10-10T10:51:44Z<p>TryA: /* Original LCD packages */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For [[fonts]] to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format:<br />
<br />
$ fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hint style ====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
==== LCD filter ====<br />
<br />
The {{Codeline|lcddefault}} filter will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
== LCD filter patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''-cleartype'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from the [[AUR]] to enable the lcddefault filter or see [[#LCD filter]] if you want to set the LCD filter manually.<br />
<br />
To get filtering with apps using libXft for font drawing, you should also install libxft-lcd from [community]:<br />
# pacman -S --asdeps libxft-lcd<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
Install the patched packages from the [[AUR]]. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
Cleartype is a different type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Install the patched packages from the [[AUR]]. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=38888 freetype2-infinality] from the [[AUR]].<br />
<br />
Additionally, if you are using lib32-freetype2 from [multilib], replace it with [http://aur.archlinux.org/packages.php?ID=40264 lib32-freetype-infinality].<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, reinstall the originals:<br />
<br />
# pacman -S --asdeps freetype2 libxft cairo<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# cd /etc/fonts/conf.d<br />
# rm 70-yes-bitmaps.conf<br />
# ln -s ../conf.avail/70-no-bitmaps.conf<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/29-replace-bitmap-fonts.conf<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Blurry fonts with Ubuntu patches ===<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display Size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=118555Font configuration2010-10-02T18:47:44Z<p>TryA: </p>
<hr />
<div>{{merge|Fonts}}<br />
[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For fonts to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format:<br />
<br />
$ fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
===== Hint style =====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
== LCD filter patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''ClearType'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from AUR to enable fonts filtering or see [[#LCD Type]] if you want to set the LCD filter manually.<br />
<br />
To get filtering with apps using libXft for font drawing, you should also install libxft-lcd from [community]:<br />
# pacman -S libxft-lcd --asdeps<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
First, the conflicting packages need to be removed:<br />
<br />
# pacman -Rd libxft cairo fontconfig freetype2<br />
<br />
Then install the patched packages from the [[AUR]] using an AUR helper of your choice. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
Cleartype is a different type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Remove the conflicting packages:<br />
<br />
# pacman -Rd cairo libxft freetype2<br />
<br />
And then install the patched packages from the AUR. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install the patched packages from the AUR. Package name:<br />
<br />
freetype2-infinality<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, first uninstall the patched versions then reinstall the originals:<br />
<br />
# pacman -S freetype2 libxft cairo --asdeps<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== LCD Type ===<br />
<br />
The fontconfig-lcd package by default uses the {{Codeline|lcddefault}} (very possible Ubuntu's does too) filter that will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# rm /etc/fonts/conf.d/70-yes-bitmaps.conf <br />
# ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# ln -s /etc/fonts/conf.avail/29-replace-bitmap-fonts.conf /etc/fonts/conf.d<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Ubuntu-patched fonts ===<br />
<br />
Edits to improve Ubuntu lcd-patched fonts.<br />
<br />
==== Blurry fonts after install ====<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf /etc/fonts/conf.d/<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]<br />
*[http://avi.alkalay.net/linux/docs/font-howto/Font.html Optimal Use of Fonts on Linux]</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=118554Font configuration2010-10-02T18:33:09Z<p>TryA: </p>
<hr />
<div>{{merge|Fonts}}<br />
[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For fonts to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format:<br />
<br />
$ fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
===== Hint style =====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
== LCD filter patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''ClearType'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from AUR to enable fonts filtering or see [[#LCD Type]] if you want to set the LCD filter manually.<br />
<br />
To get filtering with apps using libXft for font drawing, you should also install libxft-lcd from [community]:<br />
# pacman -S libxft-lcd --asdeps<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
First, the conflicting packages need to be removed:<br />
<br />
# pacman -Rd libxft cairo fontconfig freetype2<br />
<br />
Then install the patched packages from the [[AUR]] using an AUR helper of your choice. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
Cleartype is a different type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Remove the conflicting packages:<br />
<br />
# pacman -Rd cairo libxft freetype2<br />
<br />
And then install the patched packages from the AUR. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install the patched packages from the AUR. Package name:<br />
<br />
freetype2-infinality<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, first uninstall the patched versions then reinstall the originals:<br />
<br />
# pacman -S freetype2 libxft cairo --as-dep<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== LCD Type ===<br />
<br />
The fontconfig-lcd package by default uses the {{Codeline|lcddefault}} (very possible Ubuntu's does too) filter that will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# rm /etc/fonts/conf.d/70-yes-bitmaps.conf <br />
# ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# ln -s /etc/fonts/conf.avail/29-replace-bitmap-fonts.conf /etc/fonts/conf.d<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Ubuntu-patched fonts ===<br />
<br />
Edits to improve Ubuntu lcd-patched fonts.<br />
<br />
==== Blurry fonts after install ====<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf /etc/fonts/conf.d/<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]<br />
*[http://avi.alkalay.net/linux/docs/font-howto/Font.html Optimal Use of Fonts on Linux]</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=118530Font configuration2010-10-02T16:30:49Z<p>TryA: /* Original LCD packages */</p>
<hr />
<div>{{merge|Fonts}}<br />
[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For fonts to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format, type:<br />
<br />
fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
===== Hint style =====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
== LCD filter patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''ClearType'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from AUR to enable fonts filtering or see [[#LCD Type]] if you want to set the LCD filter manually.<br />
<br />
To get filtering with apps using libXft for font drawing, you should also install libxft-lcd from [community]:<br />
pacman -S libxft-lcd<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
First, the conflicting packages need to be removed:<br />
<br />
pacman -Rd libxft cairo fontconfig freetype2<br />
<br />
Then install the patched packages from the [[AUR]] using an AUR helper of your choice. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
Cleartype is a different type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Remove the conflicting packages:<br />
<br />
pacman -Rd cairo libxft freetype2<br />
<br />
And then install the patched packages from the AUR. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install the patched packages from the AUR. Package name:<br />
<br />
freetype2-infinality<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, first uninstall the patched versions then reinstall the originals:<br />
<br />
pacman -S freetype2 libxft cairo<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== LCD Type ===<br />
<br />
The fontconfig-lcd package by default uses the {{Codeline|lcddefault}} (very possible Ubuntu's does too) filter that will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# rm /etc/fonts/conf.d/70-yes-bitmaps.conf <br />
# ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# ln -s /etc/fonts/conf.avail/29-replace-bitmap-fonts.conf /etc/fonts/conf.d<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Ubuntu-patched fonts ===<br />
<br />
Edits to improve Ubuntu lcd-patched fonts.<br />
<br />
==== Blurry fonts after install ====<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf /etc/fonts/conf.d/<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]<br />
*[http://avi.alkalay.net/linux/docs/font-howto/Font.html Optimal Use of Fonts on Linux]<br />
*[http://www.linuxsir.org/bbs/showthread.php?t=266659 Advanced Font Configuration] Great resource but mostly in Simplified Chinese. Still has some good English examples.</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=118509Font configuration2010-10-02T06:29:43Z<p>TryA: /* Original LCD packages */</p>
<hr />
<div>{{merge|Fonts}}<br />
[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For fonts to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format, type:<br />
<br />
fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
===== Hint style =====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
== LCD filter patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''ClearType'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from AUR to enable fonts filtering or see [[#LCD_Type|LCD Type]] if you want to set the LCD filter manually.<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
First, the conflicting packages need to be removed:<br />
<br />
pacman -Rd libxft cairo fontconfig freetype2<br />
<br />
Then install the patched packages from the [[AUR]] using an AUR helper of your choice. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
Cleartype is a different type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Remove the conflicting packages:<br />
<br />
pacman -Rd cairo libxft freetype2<br />
<br />
And then install the patched packages from the AUR. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install the patched packages from the AUR. Package name:<br />
<br />
freetype2-infinality<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, first uninstall the patched versions then reinstall the originals:<br />
<br />
pacman -S freetype2 libxft cairo<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== LCD Type ===<br />
<br />
The fontconfig-lcd package by default uses the {{Codeline|lcddefault}} (very possible Ubuntu's does too) filter that will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# rm /etc/fonts/conf.d/70-yes-bitmaps.conf <br />
# ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# ln -s /etc/fonts/conf.avail/29-replace-bitmap-fonts.conf /etc/fonts/conf.d<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Ubuntu-patched fonts ===<br />
<br />
Edits to improve Ubuntu lcd-patched fonts.<br />
<br />
==== Blurry fonts after install ====<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf /etc/fonts/conf.d/<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]<br />
*[http://avi.alkalay.net/linux/docs/font-howto/Font.html Optimal Use of Fonts on Linux]<br />
*[http://www.linuxsir.org/bbs/showthread.php?t=266659 Advanced Font Configuration] Great resource but mostly in Simplified Chinese. Still has some good English examples.</div>TryAhttps://wiki.archlinux.org/index.php?title=Font_configuration&diff=118498Font configuration2010-10-01T21:27:45Z<p>TryA: /* Original LCD packages */</p>
<hr />
<div>{{merge|Fonts}}<br />
[[Category:X Server (English)]]<br />
[[Category:Fonts (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Font Configuration}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of font configuration options and various techniques for improving the readability of fonts}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Fonts}}: Information on adding fonts and font recommendations<br />
{{Article summary wiki|Java Fonts - Sun JRE}}: Fonts specific to Sun's Java machine<br />
{{Article summary wiki|MS Fonts}}: Adding Microsoft fonts and mimicking Windows' font settings<br />
{{Article summary end}}<br />
<br />
== Font paths ==<br />
<br />
For fonts to be known to applications, they must be cataloged for easy and quick access. [[Wikipedia:Fontconfig|Fontconfig]] is a library designed to provide a list of available fonts to applications, and also for configuration for how fonts get rendered. Though fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration file ({{Filename|/etc/X11/xorg.conf}}).<br />
<br />
=== Fontconfig ===<br />
<br />
Fontconfig gathers all it's configurations in a central file ({{Filename|/etc/fonts/fonts.conf}}). Fontconfig-aware applications source this file to know available fonts and how they get rendered. This file is a conglomeration of rules from the various fontconfig configurations (the global configuration ({{Filename|/etc/fonts/local.conf}}), the configured presets in {{Filename|/etc/fonts/conf.d/}}, and the user configuration file ({{Filename|~/.fonts.conf}}).<br />
<br />
The font paths initially known to fontconfig are: {{Filename|/usr/share/fonts/}} and {{Filename|~/.fonts/}} (of which fontconfig will scan recursively). For ease of organization and installation, it is recommended to use these font paths when [[Fonts|installing new fonts]].<br />
<br />
To see a list of known fontconfig fonts in an easy to read format, type:<br />
<br />
fc-list | sed 's,:.*,,' | sort -u<br />
<br />
=== Xorg ===<br />
<br />
Check for Xorg's known font paths by reviewing its log:<br />
<br />
$ grep /fonts /var/log/Xorg.0.log<br />
<br />
Keep in mind that Xorg does not search recursively through the {{Filename|/usr/share/fonts}} directory like fontconfig does. To add a path, the full path must be used:<br />
<br />
<pre><br />
Section "Files"<br />
FontPath "/usr/share/fonts/example-font-directory"<br />
EndSection<br />
</pre><br />
<br />
To see a list of known Xorg fonts use {{Codeline|xlsfonts}}.<br />
<br />
== Fontconfig configuration ==<br />
<br />
The font rendering packages on Arch Linux includes support for ''freetype2'' with the bytecode interpreter (BCI) enabled. However, defining your own font configuration may at times be necessary. If you have an LCD monitor, consider additionally using the [[#LCD_filter_patched_packages|LCD filter packages]] for better readability. <br />
<br />
Configuration can be done either per-user through {{Filename|~/.fonts.conf}}, or globally with {{Filename|/etc/fonts/local.conf}}. The settings in the per-user configuration have precedence over the global configuration. Both these files use the same syntax. Remember not to edit the {{filename|/etc/fonts/fonts.conf}} file; it is a temporary file and shouldn't be edited since it's replaced during fontconfig updates.<br />
<br />
There are already a number of configured presets in the directory {{Filename|/etc/fonts/conf.avail}}. These presets can be linked to both per-user and globally for quicker configuration. Take note that these presets will override matching settings in their respective configuration files.<br />
<br />
For example, to enable sub-pixel RGB rendering globally:<br />
<br />
# cd /etc/fonts/conf.d<br />
# ln -s ../conf.avail/10-sub-pixel-rgb.conf<br />
<br />
To do the same but instead for a per-user configuration:<br />
<br />
$ mkdir ~/.fonts.conf.d<br />
$ ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf ~/.fonts.conf.d<br />
<br />
{{Note|For some desktop environments (such as [[Gnome]] and [[KDE]]) using the ''Font Control Panel'' will automatically create or overwrite the user font configuration file. For these desktop environments, it is best to match your already defined font configurations to get the expected behavior.}}<br />
<br />
=== Basic settings ===<br />
<br />
The configuration files will need informational headers before settings can be entered:<br />
<br />
<pre><br />
<?xml version="1.0"?><br />
<!DOCTYPE fontconfig SYSTEM "fonts.dtd"><br />
<fontconfig><br />
<br />
... <br />
<br />
</fontconfig><br />
</pre><br />
<br />
To avoid repetition, the rest of the configuration examples in this article will omit these tags.<br />
<br />
==== Anti-aliasing ====<br />
<br />
[[Wikipedia:Antialiased font|Anti-aliasing]] (aka font rasterization) converts vectors fonts to bitmap for display purposes and in doing so provides a font smoothing effect. Without anti-aliasing (even at higher DPIs) fonts will appear jagged so anti-aliasing is enabled by default.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Hinting ====<br />
<br />
[[Wikipedia:Font hinting|Font hinting]] adjusts the spacing of fonts so that they line up with the pixel grid. Fonts will not line up correctly without hinting until displays have 300 [[Xorg#Display_size_and_DPI|DPI]] or greater. Two types of hinting are available:<br />
<br />
* {{Codeline|hinting}} - Normal, preset hinting, with several types available.<br />
* {{Codeline|autohint}} - Auto discovery for hinting.<br />
<br />
To enable normal hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hinting" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Auto-hinting ====<br />
<br />
To enable auto-hinting:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="autohint" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
</pre><br />
<br />
===== Hint style =====<br />
<br />
Hint style is the amount of influence the '''hinting''' mode has. Hinting can be set to: {{Codeline|hintfull}}, {{Codeline|hintmedium}}, {{Codeline|hintslight}} (recommended) and {{Codeline|hintnone}}.<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="hintstyle" mode="assign"><br />
<const>hintslight</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
==== Subpixel rendering ====<br />
<br />
''RGB, BGR, V-RGB (vertical), or V-BGR''<br />
<br />
Most monitors manufactured today use the Red, Green, Blue (RGB) specification. Fontconfig will need to know your monitor type to be able to display your fonts correctly. If you notice unusual colors around font's borders, discover you monitor type [http://www.lagom.nl/lcd-test/subpixel.php here] and define it in your font configuration:<br />
<br />
<pre><br />
<match target="font"><br />
<edit name="rgba" mode="assign"><br />
<const>rgb</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
Like the automatic settings most DE font control panels establish, it is recommended to disable subpixel rendering when using the auto hinter since the combination of the two may result in unsatisfactory rendering.<br />
<br />
== LCD filter patched packages ==<br />
<br />
Some distributions choose not to use the LCD filter patches for font rendering due to patent ambiguity. If you choose, you can add these patched packages on your own. These patched packages are available in the [[AUR]] and easily installable by using an [[AUR helper]]. A few considerations:<br />
<br />
* All of these methods are designed for LCD displays but some CRT users may see improvements using the ''ClearType'' packages.<br />
* Configuration is sometimes necessary.<br />
* The new font effects will not be displayed until the application restarts.<br />
<br />
=== Original LCD packages ===<br />
Cairo 1.10 adds support for the LCD filter. Install [http://aur.archlinux.org/packages.php?ID=16458 fontconfig-lcd] from AUR to enable fonts filtering.<br />
<br />
=== Ubuntu patched packages ===<br />
<br />
Ubuntu uses the original LCD patched packages and adds extra configurations, and occasionally patches.<br />
<br />
First, the conflicting packages need to be removed:<br />
<br />
pacman -Rd libxft cairo fontconfig freetype2<br />
<br />
Then install the patched packages from the [[AUR]] using an AUR helper of your choice. The package names are:<br />
<br />
freetype2-ubuntu fontconfig-ubuntu libxft-ubuntu cairo-ubuntu<br />
<br />
=== ClearType packages ===<br />
<br />
Cleartype is a different type of font rendering that is used in Windows systems and is designed to work on both LCD and CRT monitors.<br />
<br />
Remove the conflicting packages:<br />
<br />
pacman -Rd cairo libxft freetype2<br />
<br />
And then install the patched packages from the AUR. Package names:<br />
<br />
freetype2-cleartype libxft-cleartype cairo-cleartype<br />
<br />
=== Infinality patched package ===<br />
<br />
From [http://www.infinality.net/blog/?p=67 infinality.net],<br />
<br />
:This patch makes Freetype's (http://www.freetype.org) Truetype interpreter render fonts similarly to MS Cleartype. It is not perfect, and needs some work on certain fonts, however, in my opinion it renders much, much better than the bi-level Freetype hinting does when doing subpixel rendering. Anything previous to this that I've worked on is simply a hack. This is the ''real'' thing finally.<br />
<br />
Install the patched packages from the AUR. Package name:<br />
<br />
freetype2-infinality<br />
<br />
=== Reverting to original packages ===<br />
<br />
To restore the unpatched packages, first uninstall the patched versions then reinstall the originals:<br />
<br />
pacman -S freetype2 libxft cairo<br />
<br />
== Additional fontconfig configuration ==<br />
<br />
=== Disable auto-hinter for bold fonts ===<br />
<br />
The auto-hinter uses sophisticated methods for font rendering, but often makes bold fonts too wide. Fortunately, a solution can be turning off the auto-hinter for bold fonts while leaving it on for the rest:<br />
...<br />
<match target="font"><br />
<test name="weight" compare="more"><br />
<const>medium</const><br />
</test><br />
<edit name="autohint" mode="assign"><br />
<bool>false</bool><br />
</edit><br />
</match><br />
...<br />
<br />
=== Enable anti-aliasing only for bigger fonts ===<br />
<br />
''See also [http://sharpfonts.co.cc/ sharpfonts.co.cc] for related information''<br />
<br />
Some users prefer the sharper rendering that anti-aliasing doesn't offer:<br />
<br />
<pre><br />
...<br />
<match target="font"><br />
<edit name="antialias" mode="assign"><br />
<bool>false</bool><br />
</edit> <br />
</match><br />
<br />
<match target="font" ><br />
<test name="size" qual="any" compare="more"><br />
<double>12</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
<br />
<match target="font" ><br />
<test name="pixelsize" qual="any" compare="more"><br />
<double>17</double><br />
</test><br />
<edit name="antialias" mode="assign"><br />
<bool>true</bool><br />
</edit><br />
</match><br />
...<br />
</pre><br />
<br />
=== Replace fonts ===<br />
<br />
The most reliable way to do this is to add an XML fragment similar to the one below. This will cause Bitstream Vera Sans to be used in place of Helvetica:<br />
...<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>Helvetica</string><br />
</test><br />
<edit name="family" mode="assign"><br />
<string>Bitstream Vera Sans</string><br />
</edit><br />
</match><br />
...<br />
An alternate approach is to set the "preferred" font, but ''this only works if the original font is not on the system'', in which case the one specified will be substituted:<br />
...<br />
< !-- Replace Helvetica with Bitstream Vera Sans Mono --><br />
< !-- Note, an alias for Helvetica should already exist in default conf files --><br />
<alias><br />
<family>Helvetica</family><br />
<prefer><family>Bitstream Vera Sans Mono</family></prefer><br />
<default><family>fixed</family></default><br />
</alias><br />
...<br />
<br />
=== LCD Type ===<br />
<br />
The fontconfig-lcd package by default uses the {{Codeline|lcddefault}} (very possible Ubuntu's does too) filter that will work for most users. Other filters are available that can be used in special situations: {{Codeline|lcdlight}}; a lighter filter ideal for fonts that look too bold or fuzzy, {{Codeline|lcdlegacy}}, the original Cairo filter; and {{Codeline|lcdnone}} to disable it entirely.<br />
<br />
<pre><br />
<match target="font"><br />
<edit mode="assign" name="lcdfilter"><br />
<const>lcddefault</const><br />
</edit><br />
</match><br />
</pre><br />
<br />
=== Disable bitmap fonts ===<br />
<br />
To disable bitmap fonts in fontconfig, use {{filename|70-no-bitmaps.conf}} (which is not placed by fontconfig by default):<br />
<br />
# rm /etc/fonts/conf.d/70-yes-bitmaps.conf <br />
# ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d<br />
<br />
Depending on the type of fontconfig you are using (default, or -lcd patched) you can choose which fonts to replace bitmaps fonts with (Helvetica, Courier and Times bitmap mapts to TTF fonts) by:<br />
<br />
# ln -s /etc/fonts/conf.avail/29-replace-bitmap-fonts.conf /etc/fonts/conf.d<br />
<br />
=== Create bold and italic styles for incomplete fonts ===<br />
<br />
Freetype has the ability to automatically create ''italic'' and '''bold''' styles for fonts that do not have them, but only if explicitly required by the application. Given programs rarely send these requests, this section covers manually forcing generation of missing styles.<br />
<br />
Start by editing {{Filename|/usr/share/fonts/fonts.cache-1}} as explained below. Store a copy of the modifications on another file, because a font update with {{Codeline|fc-cache}} will overwrite {{Filename|/usr/share/fonts/fonts.cache-1}}.<br />
<br />
Assuming the Dupree font is installed:<br />
"dupree.ttf" 0 "Dupree:style=Regular:slant=0:weight=80:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Duplicate the line, change {{Codeline|<nowiki>style=Regular</nowiki>}} to {{Codeline|<nowiki>style=Bold</nowiki>}} or any other style. Also change {{Codeline|<nowiki>slant=0</nowiki>}} to {{Codeline|<nowiki>slant=100</nowiki>}} for italic, {{Codeline|<nowiki>weight=80</nowiki>}} to {{Codeline|<nowiki>weight=200</nowiki>}} for bold, or combine them for '''''bold italic''''':<br />
"dupree.ttf" 0 "Dupree:style=Bold Italic:slant=100:weight=200:width=100:foundry=unknown:index=0:outline=True:''etc...''<br />
<br />
Now add necessary modifications to {{Filename|~/.fonts.conf}}:<br />
<pre><br />
...<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="weight" compare="more_eq"><int>140</int></test><br />
<edit name="embolden" mode="assign"><bool>true</bool></edit><br />
</match><br />
<br />
<match target="font"><br />
<test name="family" qual="any"><br />
<string>Dupree</string><br />
&lt;!-- other fonts here .... --&gt;<br />
</test><br />
<test name="slant" compare="more_eq"><int>80</int></test><br />
<edit name="matrix" mode="assign"><br />
<times><br />
<name>matrix</name><br />
<matrix><br />
<double>1</double><double>0.2</double><br />
<double>0</double><double>1</double><br />
</matrix><br />
</times><br />
</edit><br />
</match><br />
...<br />
</pre><br />
{{Tip| Use the value 'embolden' for existing bold fonts in order to make them even bolder.}}<br />
<br />
===Change rule overriding===<br />
<br />
Fontconfig processes files in {{Filename|/etc/fonts/conf.d}} in reverse numerical order. This enables rules or files to override one another, but often confuses users about what file gets parsed last.<br />
<br />
To guarantee that personal settings take precedence over any other rules, change their ordering:<br />
# cd /etc/fonts/conf.d<br />
# mv 50-user.conf 00-user.conf<br />
<br />
This change seems however to be unnecessary for the most of the cases, because a user is given enough control by default to set up own font preferences, hinting and antialiasing properties, alias new fonts to generic font families, etc.<br />
<br />
=== Example fontconfig configurations ===<br />
<br />
Example fontconfig configurations can be found on this [[Font_Configuration/fontconfig_Examples|page]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Ubuntu-patched fonts ===<br />
<br />
Edits to improve Ubuntu lcd-patched fonts.<br />
<br />
==== Blurry fonts after install ====<br />
<br />
The Ubuntu fontconfig by default doesn't set sub-pixel rendering in it's global configuration. I'm not sure why exactly, I've noticed the same configurations in {{Filename|/etc/fonts/conf.d}} as when I've loaded and Ubuntu CD but my Ubuntu fonts have always looked blurry after the install. Perhaps it's because I'm using a different desktop environment than Gnome, but to fix this I've always had to set my sub-pixel rendering type on:<br />
<br />
ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf /etc/fonts/conf.d/<br />
<br />
Then logout and back in again.<br />
<br />
=== Distorted fonts ===<br />
''Main article: [[Xorg#Display size and DPI]]<br />
<br />
Fontconfig should be able to detect DPI parameters as discovered by the Xorg server and be able to display the fonts correctly. Those having problems can still fall back to setting it manually:<br />
<br />
...<br />
<!-- Setup for DPI=96 --><br />
<match target="pattern"><br />
<edit name="dpi" mode="assign"><double>96</double></edit><br />
</match><br />
...<br />
<br />
If fonts are still unexpectedly large or small, or are poorly proportioned, the Xorg server may be incorrectly detecting the DPI setting.<br />
<br />
=== Missing characters ===<br />
<br />
If using [[Emacs]], the {{Package Official|xorg-fonts-75dpi}} and {{Package Official|xorg-fonts-100dpi}} packages need to be installed.<br />
<br />
=== Older GTK and QT applications ===<br />
<br />
Modern GTK apps enable Xft by default but this was not the case before version 2.2. If it is not possible to update these applications, force Xft for old GNOME applications by adding to {{Filename|~/.bashrc}}:<br />
<br />
export GDK_USE_XFT=1<br />
<br />
For older QT applications:<br />
<br />
export QT_XFT=true<br />
<br />
== Resources ==<br />
<br />
*[http://www.x.org/X11R6.8.2/doc/fonts.html Fonts in X11R6.8.2] - Official Xorg font information<br />
*[http://freetype.sourceforge.net/freetype2/ FreeType 2 Overview]<br />
*[http://avi.alkalay.net/linux/docs/font-howto/Font.html Optimal Use of Fonts on Linux]<br />
*[http://www.linuxsir.org/bbs/showthread.php?t=266659 Advanced Font Configuration] Great resource but mostly in Simplified Chinese. Still has some good English examples.</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=113709Mach642010-08-10T19:33:38Z<p>TryA: </p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Out of date}}<br />
{{Box Note | AUR package mach64drm has been updated and works with newest kernels, so this article needs a serious cleanup.}}<br />
<br />
Update: The source is no longer maintained in freedesktop.org's libdrm git repo (git://anongit.freedesktop.org/git/mesa/drm). The people maintaining libdrm who own that repo have deleted the drm kernel modules (like the one this package packages), because these modules are being developed in the kernel's git tree (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git). However, because mach64 has security issues, it is not in the kernel git tree, however, TryA has uploaded a package by the name of kernel26-mach64 to AUR patched to include these sources.<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
==Building the patched Kernel 2.6.31.6 kernel26-mach64 from AUR==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm.<br />
<br />
The only way to solve this is using the kernel26-mach64 AUR package:<br />
<br />
http://aur.archlinux.org/packages.php?ID=32583<br />
<br />
This patched kernel has been made from kernel 2.6.31.6. Thanks to the mantainer TryA!!<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<strike>[http://www.retinalburn.net/linux/dri_status.html]</strike> (dead link)<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
"The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it."<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=113708Mach642010-08-10T19:32:05Z<p>TryA: </p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Out of date}}<br />
{{Box Note | AUR package [http://aur.archlinux.org/packages.php?ID=17939 mach64drm] has been updated and works with newest kernels, so this article needs a cleanup}}<br />
<br />
Update: The source is no longer maintained in freedesktop.org's libdrm git repo (git://anongit.freedesktop.org/git/mesa/drm). The people maintaining libdrm who own that repo have deleted the drm kernel modules (like the one this package packages), because these modules are being developed in the kernel's git tree (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git). However, because mach64 has security issues, it is not in the kernel git tree, however, TryA has uploaded a package by the name of kernel26-mach64 to AUR patched to include these sources.<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
==Building the patched Kernel 2.6.31.6 kernel26-mach64 from AUR==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm.<br />
<br />
The only way to solve this is using the kernel26-mach64 AUR package:<br />
<br />
http://aur.archlinux.org/packages.php?ID=32583<br />
<br />
This patched kernel has been made from kernel 2.6.31.6. Thanks to the mantainer TryA!!<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<strike>[http://www.retinalburn.net/linux/dri_status.html]</strike> (dead link)<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
"The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it."<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=86602Mach642009-12-06T12:26:30Z<p>TryA: </p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Box Note | This article needs to be rewritten because compiling mach64 modules from GIT repository is no longer possible.}}<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
==Building the Kernel Drm Module - with makepkg goodness==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm. The kernel '''must''' be compiled as follows:<br />
<br />
Device Drivers ---><br />
Graphics Support ---><br />
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> (CONFIG_DRM=n) Must be disabled.<br />
<br />
If you are using the standard Arch kernel, you must either recompile the kernel or obtain the AUR package [http://aur.archlinux.org/packages.php?ID=22785 kernel26-nodrm].<br />
<br />
After your kernel is properly configured, install the AUR package [http://aur.archlinux.org/packages.php?ID=17939 mach64drm], which will install the kernel modules compiled from out of tree DRI sources.<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<strike>[http://www.retinalburn.net/linux/dri_status.html]</strike> (dead link)<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
"The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it."<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=86601Mach642009-12-06T12:26:01Z<p>TryA: /* xorg.conf */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Box Note | This article needs to be rewritten because compiling mach64 modules from GIT repository is no longer possible.}}<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
<br />
==Building the Kernel Drm Module - with makepkg goodness==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm. The kernel '''must''' be compiled as follows:<br />
<br />
Device Drivers ---><br />
Graphics Support ---><br />
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> (CONFIG_DRM=n) Must be disabled.<br />
<br />
If you are using the standard Arch kernel, you must either recompile the kernel or obtain the AUR package [http://aur.archlinux.org/packages.php?ID=22785 kernel26-nodrm].<br />
<br />
After your kernel is properly configured, install the AUR package [http://aur.archlinux.org/packages.php?ID=17939 mach64drm], which will install the kernel modules compiled from out of tree DRI sources.<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<strike>[http://www.retinalburn.net/linux/dri_status.html]</strike> (dead link)<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
"The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it."<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=86600Mach642009-12-06T12:25:06Z<p>TryA: /* xorg.conf */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Box Note | This article needs to be rewritten because compiling mach64 modules from GIT repository is no longer possible.}}<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
<br />
==Building the Kernel Drm Module - with makepkg goodness==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm. The kernel '''must''' be compiled as follows:<br />
<br />
Device Drivers ---><br />
Graphics Support ---><br />
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> (CONFIG_DRM=n) Must be disabled.<br />
<br />
If you are using the standard Arch kernel, you must either recompile the kernel or obtain the AUR package [http://aur.archlinux.org/packages.php?ID=22785 kernel26-nodrm].<br />
<br />
After your kernel is properly configured, install the AUR package [http://aur.archlinux.org/packages.php?ID=17939 mach64drm], which will install the kernel modules compiled from out of tree DRI sources.<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64"<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async"<br />
Option "ForcePCIMode" "false"<br />
Option "AgpMode" "2"<br />
Option "AgpSize" "32"<br />
Option "BufferSize" "2"<br />
Option "LocalTextures" "true"<br />
EndSection<br />
<br />
Details:<br />
*Driver: most important, allows you to use the mach64 driver.<br />
*DMAMode: async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
*ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
*AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.<br />
*AgpSize: sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
*BufferSize: sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
*LocalTextures: boolean, by default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true.<br />
The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM).<br />
<strike>[http://www.retinalburn.net/linux/dri_status.html]</strike> (dead link)<br />
<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
"The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it."<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=86425Mach642009-12-05T18:22:12Z<p>TryA: /* Why Isn't the Mach64 DRM Included In the Kernel? */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Box Note | This article needs to be rewritten because compiling mach64 modules from GIT repository is no longer possible.}}<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
<br />
==Building the Kernel Drm Module - with makepkg goodness==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm. The kernel '''must''' be compiled as follows:<br />
<br />
Device Drivers ---><br />
Graphics Support ---><br />
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> (CONFIG_DRM=n) Must be disabled.<br />
<br />
If you are using the standard Arch kernel, you must either recompile the kernel or obtain the AUR package [http://aur.archlinux.org/packages.php?ID=22785 kernel26-nodrm].<br />
<br />
After your kernel is properly configured, install the AUR package [http://aur.archlinux.org/packages.php?ID=17939 mach64drm], which will install the kernel modules compiled from out of tree DRI sources.<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64" #most important, allows you to use the mach64 driver<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async" #async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
Option "ForcePCIMode" "false" #Boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
Option "AgpMode" "2" #(AGP 1x or 2x) valid options: 1 or 2. If not set, defaults to agpgart's mode<br />
Option "AgpSize" "32" #Sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
Option "BufferSize" "2" #Sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
Option "LocalTextures" "true" #By default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true. boolean.<br />
#The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers (BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM). http://www.retinalburn.net/linux/dri_status.html<br />
#see "Status and known issues for mach64 branch of DRI<br />
EndSection<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #Change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
"The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it."<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=86388Mach642009-12-05T13:20:51Z<p>TryA: </p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Box Note | This article needs to be rewritten because compiling mach64 modules from GIT repository is no longer possible.}}<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
<br />
==Building the Kernel Drm Module - with makepkg goodness==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm. The kernel '''must''' be compiled as follows:<br />
<br />
Device Drivers ---><br />
Graphics Support ---><br />
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> (CONFIG_DRM=n) Must be disabled.<br />
<br />
If you are using the standard Arch kernel, you must either recompile the kernel or obtain the AUR package [http://aur.archlinux.org/packages.php?ID=22785 kernel26-nodrm].<br />
<br />
After your kernel is properly configured, install the AUR package [http://aur.archlinux.org/packages.php?ID=17939 mach64drm], which will install the kernel modules compiled from out of tree DRI sources.<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64" #most important, allows you to use the mach64 driver<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async" #async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
Option "ForcePCIMode" "false" #Boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
Option "AgpMode" "2" #(AGP 1x or 2x) valid options: 1 or 2. If not set, defaults to agpgart's mode<br />
Option "AgpSize" "32" #Sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
Option "BufferSize" "2" #Sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
Option "LocalTextures" "true" #By default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true. boolean.<br />
#The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers (BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM). http://www.retinalburn.net/linux/dri_status.html<br />
#see "Status and known issues for mach64 branch of DRI<br />
EndSection<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #Change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it.<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryAhttps://wiki.archlinux.org/index.php?title=Mach64&diff=86387Mach642009-12-05T13:17:23Z<p>TryA: </p>
<hr />
<div>[[Category: Graphics (English)]]<br />
{{Box Note | This article needs to be rewritten because compiling mach64 modules from GIT repository is no longer possible.}}<br />
<br />
This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset.<br />
If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage<br />
Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.<br />
<br />
==The Mach 64 Board==<br />
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64.<br />
[http://en.wikipedia.org/wiki/ATI_Rage Wikipedia: Mach64/Rage Pro]<br />
This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. [[#Why Isn't the Mach64 DRM Included In the Kernel?|Why Isn't the Mach64 DRM Included In the Kernel?]]<br />
<br />
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.<br />
<br />
==Packages and References==<br />
[http://dri.freedesktop.org/wiki/Building Reference Building DRI - Check this for link updates.]<br />
*mesa - installs the mesa GL libs - Install this with pacman.<br />
*libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman<br />
*libdrm - installs the drm libs - install this with pacman<br />
*xf86-video-mach64 - installs the xorg driver<br />
*mach64-dri - installs the dri files for mach64<br />
<br />
Terminology<br />
*DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.<br />
*DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.<br />
<br />
<br />
==Building the Kernel Drm Module - with makepkg goodness==<br />
[[#Why Isn't the Mach64 DRM Included In the Kernel?|'''Before you start: Security Hole Warning''']]<br />
Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm. The kernel '''must''' be compiled as follows:<br />
<br />
Device Drivers ---><br />
Graphics Support ---><br />
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> (CONFIG_DRM=n) Must be disabled.<br />
<br />
If you are using the standard Arch kernel, you must either recompile the kernel or obtain the AUR package "kernel26-nodrm."<br />
<br />
After your kernel is properly configured, install the AUR package "mach64drm," which will install the kernel modules compiled from out of tree DRI sources.<br />
<br />
==Installing the other end: DRI==<br />
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).<br />
<br />
This has made the process of installing DRI much easier, entailing:<br />
<br />
pacman -S xf86-video-mach64<br />
<br />
==xorg.conf==<br />
This is what my the Device section in my xorg.conf looks like:<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "mach64" #most important, allows you to use the mach64 driver<br />
Card "ATI Rage Pro - Mach64"<br />
Option "DMAMode" "async" #async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers.<br />
Option "ForcePCIMode" "false" #Boolean, disables AGP aperture. Set to True if you have a PCI card.<br />
Option "AgpMode" "2" #(AGP 1x or 2x) valid options: 1 or 2. If not set, defaults to agpgart's mode<br />
Option "AgpSize" "32" #Sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here.<br />
Option "BufferSize" "2" #Sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2.<br />
Option "LocalTextures" "true" #By default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true. boolean.<br />
#The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers (BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM). http://www.retinalburn.net/linux/dri_status.html<br />
#see "Status and known issues for mach64 branch of DRI<br />
EndSection<br />
<br />
The Modules Section:<br />
Section "Module"<br />
<Your modules><br />
Load "glx"<br />
Load "dri"<br />
EndSection<br />
<br />
The DRI Section:<br />
<br />
Section "DRI"<br />
Mode 0666 #allows anybody to use DRI<br />
EndSection<br />
<br />
<br />
The DRI Section (For machines where security is a concern):<br />
<br />
Section "DRI"<br />
Group "video" #Change to any desired group to restrict access<br />
Mode 0660<br />
EndSection<br />
<br />
==Testing DRI==<br />
After you're in X, you can run the command <code>glxinfo | egrep "direct rendering|OpenGL renderer"</code><br />
This should return something like this:<br />
direct rendering: Yes<br />
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE<br />
<br />
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"<br />
<br />
==Why Isn't the Mach64 DRM Included In the Kernel?==<br />
The [http://dri.freedesktop.org/wiki/ATIMach64 official page] for the dri/drm driver for mach64 states:<br />
<br />
The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.<br />
<br />
Things that need to be done:<br />
*Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.<br />
*Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.<br />
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.<br />
<br />
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.<br />
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it.<br />
<br />
==Building the Kernel Drm Module - the Old Way without pacman==<br />
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own.<br />
Skip this section if you did the section above, with makepkg.<br />
<br />
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.<br />
<br />
*Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR<br />
*Now, obtain the drm source tree: <br />
git clone git://anongit.freedesktop.org/git/mesa/drm<br />
*Get the thing compiled: (the drm folder appeared out of git)<br />
cd $BUILDDIR/drm/linux-core/<br />
make DRM_MODULES="mach64"<br />
*Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.<br />
*When it's done compiling, there will be two files, <code>mach64.ko</code>, the device kernel module, and <code>drm.ko</code>, the DRM generic module.<br />
*Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).<br />
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/<br />
*Now get the modules registered and depedencies generated.<br />
sudo depmod -a `uname -r`</div>TryA