Table of Contents
recursive toc v1.4

Linux hacks

The description of necessary setup processes to get things working. Some of them work right out of the box while other require some work and dedication. A small price to pay in return of an excelent operating system.

There could be blank spaces in this page. I am constantly working on it. Check it out often.

Contents

Frequency scaling

CPUs today are tipically much faster than necessary to do office work. Also, generic heatsinks may not be enough to dissipate all the heat generated by a fully throttled CPU for long periods of time.

It is a waste of energy and a heat problem to use some CPU only 10% of the time with it running at full throttle. Fortunately, most chips today allow some form of power saving, generally via frequency scaling (CMOS technology sucks power [only on] energy on level transitions, so higher frequency means higher power consumption).

This is well supported in Linux systems and can be used in kernel only, with no configuration and no userspace tools. Other more sophisticated methods are usually used in conjunction with userspace tools and take into account many factors like AC power plugged/not plugged, current temperature, battery power left, etc.

The frequency scaling driver available in the kernel is cpufreq and is composed roughly by two layers of code:

Drivers for both layers are, of course, necessary. For my Centrino chip I use the speedstep_centrino driver for the hardware interface and the conservative scaling governor. The following is a suggested kernel configuration that includes support for different hardware drivers and scaling governors (built as modules).

Frequency scaling can be seen in action in /sys/devices/system/cpu/cpu0/cpufreq (and/or cpu1, 2, etc):

archon ~ # lsmod | egrep "(speedstep|cpufreq)"
cpufreq_conservative     3360  1
speedstep_centrino      3920  1
processor              12396  2 thermal,speedstep_centrino
archon ~ # ls -1 /sys/devices/system/cpu/cpu0/cpufreq
affected_cpus
conservative/
cpuinfo_cur_freq
cpuinfo_max_freq
cpuinfo_min_freq
scaling_available_frequencies
scaling_available_governors
scaling_cur_freq
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
stats/
archon ~ #

The marked files are of particular use:

All but one of the scaling governors setup chip frequency from the kernel itself - thei're automatic.

Two are very simple: performance and powersave setup the cpu frequency respectively for highest and lowest possible.

Two other are more sophisticated and particular useful: ondemand and conservative. The purpose of both these governors is similar but the way they work is a little different. The selected frequency is dynamically assigned according to current CPU load - if the cpu is loaded, the frequency goes up; if the cpu lightly loaded, the frequency drops. These governors can use the full range of available frequencies.
Both ondemand and conservative do periodic polling and change frequency based on the CPU utilization. conservative, however, is optimised for battery powered environments, as it gradually changes frequency instead of quickly jumping from minimum to maximum. For laptops, use conservative; For desktops, use ondemand

Finally, the userspace governor doesn't calculate or set frequency by itself; It was designed and implemented to allow userspace software to determine desired frequency values and explicitly interact with the governor to change frequency. Userspace tools for frequency scaling are generally sophisticated daemons that can consider many different factors to determine the best suitable frequency to be used.
Some example of such toolkits are:

It is very simple to switch between available governors. Just write their name into the file scaling_governor and the governor is switched for you. One example of switching between conservative and performance is shown below.

See what governor is currently being used and what frequency is our CPU running at:

archon ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
conservative
archon ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
798000

Now let's see what governors are available for use:

archon ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative userspace

Oops, performance is not available. Let's load it and look again:

archon ~ # modprobe cpufreq_performance 
archon ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
performance conservative userspace

Replace conservative by performance and see what happens:

archon ~ # echo -n "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
archon ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
archon ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1862000

Due to some hardware problems (related to frequency changing latencies), not all governors are available to be set as default scaling governor. At the moment, only performance, powersave and userspace can be selected as default governors (the default can't be compiled as a module).

One way to automatically use the conservative governor is to enable it explicitly on every boot. The following line in /etc/conf.d/local.start does just this:

echo -n "conservative" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

It is not elegant, but works well and spares you from having one more userspace daemon. The choice is yours though.

References

go back to top of document

Compiler support

Up to version 3.3, gcc didn't have support for the centrino cpu, so with gentoo, one had to use -march=pentium3 since that's what a centrino CPU is: a (very) modified pentium III. As of gcc 3.4, there is explicit support for the centrino cpu.

This section of the gcc manual shows some centrino-specific optimization flags:

Some more flags can optimize binary code resulting from gcc, which can be notorious when using a linux distribution like gentoo

go back to top of document

Wireless tools

go back to top of document

Small 802.1X authentication howto

The 802.1X is a standard defined to implement reliable security within wireless LANs. Its protocols provide an authentication framework for WLANs, and strong cryptography with dymanic key management for user privacy.

The authentication process takes place using the Extensible Authentication Protocol (EAP), which is used to encapsulate one of the already existing authentication protocols. EAP doesn't define the authentication protocol, so many can be used.

The general process of 802.1X authentication protocol is simple:

  1. Client (supplicant) requests access to the access point
  2. Access point (authenticator) forces the client into an unauthorized state. In this state, the client is only able to send EAP messages carrying identity information, through an encapsulated encryption protocol.
  3. The access point forwards the identity information encrypted by the client to an external authentication server
  4. The authentication server returns an accept or reject message, respectively allowing or disallowing the client from associating with the AP

The wpa_supplicant software is a WPA supplicant client program for Linux, BSD and Windows, supporting WPA and WPA2. It implements key negotiation with a WPA authenticator and controls the 802.11 roaming (authentication/association) of the wlan driver. (from the wpa_supplicant website)

Since version 0.3.8, there is hardware support for the ipw2100 and ipw2200 wireless cards. All that's needed is correct configuration of the wpa_supplicant.conf file and we're off! Gentoo linux's wpa_supplicant ebuild provides a convenient /etc/init.d/wpa_supplicant init script will be used to start and maintain the association/authentication process.

(to be continued...)

go back to top of document

IPW2200 monitor mode

go back to top of document

Encrypt swap space via device mapper

Swap is, in most cases, a partition reserved to be used as "extra" memory space when the real (real fast) RAM get's a little tight for all the stuff we want to put in there.

swap is not volatile - security concerns

One of the big differences between swap and RAM is that swap isn't volatile - when the computer is powered off, swap memory pages remain written on its media support. Recovering such information from a hard drive can reveal interesting bits of data that once were memory pages. These can be in-transit session data, encryption keys, hashed and/or plain text passwords and so on.

encrypted swap

Swap is used just like RAM, but this non-volatile behaviour raises some security concerns. It may not be practical or possible to make swap volatile, but we can easily do something else that has a similar effect.

If the swap partition is encrypted with some key stored in RAM, as soon as the computer powers off (and RAM memory erases itself due to lack of power), swap gets very difficult to read and recovering swapped memory pages requires a huge amount of time and effort. A compromise must be made, because strong cryptographic algorithms with big keys are expensive and in extreme situations the encrypt-swap-decrypt operations may use up more resources than those necessary for our applications, we need a good and quick algorithm :).

The practical solution with gentoo requires one kernel module, one configuration line in two different files and one userspace toolkit.

Basic kernel support:

My advice is to keep these kernel options as statically compiled.

The userspace toolkit we need is sys-fs/cryptsetup or sys-fs/cryptsetup-luks, so:

archon linux # emerge cryptsetup

Next, the configurations. The startup scripts are already prepared for this, so all that's necessary is choosing the swap partition in /etc/conf.d/cryptfs and then changing the swap point in /etc/fstab.

# /etc/conf.d/cryptfs
# ... (leave other stuff unchanged)

# look for these lines and change source= to your swap partition
swap=crypt-swap
source='/dev/hda6'

# ... (leave other stuff unchanged)
# /etc/fstab
# ... (leave other stuff unchanged)

# look for the swap line and change it to the following
/dev/mapper/crypt-swap	none	swap	sw	0 0

# ... (leave other stuff unchanged)

You're done! Now the swap partition is used via device mapper with a crypt target using an aes-sha1 encryption/hashing algorithm. Every time the computer boots up, a new key is retrieved from /dev/urandom. This key isn't stored anywhere but in RAM, so it goes away when the computer is powered off.

go back to top of document

Synaptics Touchpad configuration for X

Once I needed to use the touchpad, I realized how bad it was without the dedicated driver, the synaptics touchpad linux driver for X. It is a X11/X.org GPL'd driver that lives in http://web.telia.com/~u89404340/touchpad/index.html

Some of the goodies that come with the synaptics driver for the touchpad (taken from and adapted from the synaptics homepage):

Current kernels already support such pointing devices and event handles, so the X driver is enough.

Basic kernel support:

Assuming the event interface was chosen as a module, it must be loaded with modprobe or insmod evdev. Then emerge synaptics

archon linux # emerge synaptics

Next step is to configure X to use the synaptics driver. Just tell it to load the synaptics driver, configure the poiting device and change the server layout. All these changes will be done in xorg.conf

  1. Load the synaptics driver
    Look for the Section "Module" and add the following line: 
    Section "Module"
	...
	# load synaptics touchpad driver
	Load        "synaptics"
	...
EndSection
  2. Configure the pointing device
    Create a new "InputDevice" sectionwith the following code: 
    Section "InputDevice"
	Identifier	"Synaptics touchpad"
	Driver		"synaptics"
	Option		"Device"		"/dev/psaux"
 	Option		"Protocol"		"auto-dev"
	Option		"LeftEdge"		"1700"
	Option		"RightEdge"		"5300"
	Option		"TopEdge"		"1700"
	Option		"BottomEdge"		"4200"
	Option		"FingerLow"		"20"
	Option		"FingerHigh"		"35"
	# disable tapping by setting MaxTapTime to 0
	Option		"MaxTapTime"		"0"
	#Option		"MaxTapTime"		"180"
	Option		"MaxTapMove"		"220"
	Option		"VertScrollDelta"	"100"
	Option		"MinSpeed"		"0.09"
	Option		"MaxSpeed"		"0.18"
	Option		"AccelFactor"		"0.0015"
	Option		"SHMConfig"		"on"
	#Option		"Repeater"		"/dev/ps2mouse"
EndSection
    Note that this is probably the third InputDevice configured. The other two are the keyboard and the mouse.
  3. Setup server layout
    Look for the "ServerLayout" section and there should be an entry like: 
    	InputDevice	"Mouse1"		"CorePointer"
    This is the CorePointer, the pointing device - the mouse in this case. There must be a CorePointer device or else X will complain. This line will be replaced by the new setup, which can be one of two: (I use the second, as I want to have both mouse and touchpad working)
    • The Synaptics Touchpad will be the only input device
      Simply replace the Corepointer device to the synaptics touchpad 
      	InputDevice	"Synaptics touchpad"		"CorePointer"
    • Both mouse and touchpad will be input devices
      Leave the mouse as default, but enable simultaneous event signaling from both devices 
      	InputDevice	"Mouse1"		"CorePointer"
	InputDevice	"Synaptics touchpad"	"SendCoreEvents"

The best thing about this is that each devices uses its own driver, so the synaptics will not interfere with the mouse and vice-versa.

go back to top of document

Wacom Graphire 4 tablet pen configuration

Basic kernel support:

These kernel options can be configured as modules and should be loaded before starting xorg. The modules are called wacom and evdev respectively for the usb tablet and event interface drivers.

Configure static symlinks for the device. Since more devices may be using the event interface, their /dev locations depend on the order in whith they were connected. Right now, /dev/input/event4 may be the link for my graphire4, but nothing keeps this device from being associated with, for example, /dev/input/event5. So, what locations can we use on xorg configuration?

This problem can be solved by adding a few udev rules that put each device on its /dev path according to their vendor and product codes. udev makes sure that, with these rules, every time the graphire4 or my optical mouse are connected, thei're assigned the same /dev device links. Vendor and product codes can be retrieved by using:

archon linux # lsusb
...
Bus 001 Device 003: ID 056a:0015 Wacom Co., Ltd
...
Bus 002 Device 002: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse
...

Vendor code is 046d and product code is c016 for my usb optical mouse. Every usb device has a pair of these codes that can be used to build rules for udev. The following rule creates fixed device links for the graphire4 and optical mouse devices. Create a file like this and name it with a relatively small number prefix like 20 (the prefix number is used to load udev rules from different files in a pre-determined order).

# /etc/udev/rules.d/20-input-device.rules
# wacom graphire 4 tablet pen
KERNEL=="event*", SYSFS{idVendor}=="056a", SYSFS{idProduct}=="0015", NAME="input/%k", SYMLINK="input/graphire4"
# logitech notebook optical mouse (usb)
KERNEL=="mouse*", SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c016", NAME="input
/%k", SYMLINK="input/ltnboptical"

At this point, you should reboot to see if the necessary modules are correctly loaded and to let udev do its magic. See if the necessary modules are loaded and look for the device links:

archon ~ # lsmod | egrep "(evdev|wacom)"
wacom                  12224  0
usbcore                91204  4 wacom,uhci_hcd,ehci_hcd
evdev                   5696  2
archon ~ # ls -l /dev/input/
total 0
drwxr-xr-x 2 root root    120 Jan  3 00:46 by-id/
drwxr-xr-x 2 root root    180 Jan  3 00:46 by-path/
crw------- 1 root root 13, 64 Jan  3 00:45 event0
crw------- 1 root root 13, 65 Jan  3 00:45 event1
crw-rw---- 1 root root 13, 66 Jan  3 00:46 event2
crw-rw---- 1 root root 13, 67 Jan  3 00:46 event3
lrwxrwxrwx 1 root root      6 Jan  3 00:46 graphire4 -> event2
lrwxrwxrwx 1 root root      6 Jan  3 00:46 ltnboptical -> mice
crw-r--r-- 1 root root 13, 63 Jan  3 00:45 mice
crw-r--r-- 1 root root 13, 32 Jan  3 00:45 mouse0
crw-r--r-- 1 root root 13, 33 Jan  3 00:46 mouse1
crw-r--r-- 1 root root 13, 34 Jan  3 00:46 mouse2
archon ~ #

The xorg wacom driver and userspace diagnostic and configuration tools are installed from the linuxwacom ebuild.

archon ~ # emerge linuxwacom

Some diagnostic checkups can be made from the linuxwacom userspace tools: 

archon ~ # xsetpointer -l
"LAPTOP Keyboard"       [XKeyboard]
"Synaptics touchpad"    [XExtensionDevice]
"USB Mouse"     [XPointer]
"stylus"        [XExtensionDevice]
"eraser"        [XExtensionDevice]
"cursor"        [XExtensionDevice]
"pad"   [XExtensionDevice]
archon ~ # xsetwacom list
Synaptics touchpad pad
stylus           stylus
eraser           eraser
cursor           cursor
pad              pad
archon ~ # xidump -l
LAPTOP Keyboard                keyboard
Synaptics touchpad             extension
USB Mouse                      disabled
stylus                         extension
eraser                         extension
cursor                         extension
pad                            extension

xorg needs to know about these new pointer devices. There are four pointer devices in a Graphire 4:

All these use the wacom xorg driver and must be configured individually in /etc/X11/xorg.conf. This driver has a big set of options that can be found here: wacom driver man page (also included on the linuxwacom software package). The following is a snippet of xorg.conf configured to use these pointer devices.

# /etc/X11/xorg.conf
# ... (leave other stuff unchanged)

# pen pointer
Section "InputDevice"
	Driver		"wacom"
	Identifier	"stylus"
	# This link exists due to the previously explained udev rule
	Option		"Device"	"/dev/input/graphire4"
	Option		"Type"		"stylus"
	Option		"USB"		"on"
	Option		"Mode"		"Absolute"
EndSection
# pen eraser
Section "InputDevice"
	Driver  "wacom"
	Identifier  "eraser"
	# This link exists due to the previously explained udev rule
	Option  "Device"  "/dev/input/graphire4"
	Option  "Type"  "eraser"
	Option  "USB" "on"
	Option  "Mode"  "Absolute"
EndSection
Section "InputDevice"
	Driver  "wacom"
	Identifier  "cursor"
	# This link exists due to the previously explained udev rule
	Option  "Device"  "/dev/input/graphire4"
	Option  "Type"  "cursor"
	Option  "USB" "on"
	Option  "Mode"  "Absolute"
EndSection
# graphire4 express keys
Section "InputDevice"
	Driver  "wacom"
	Identifier  "pad"
	# This link exists due to the previously explained udev rule
	Option  "Device"  "/dev/input/graphire4"
	Option  "Type"  "pad"
	Option  "USB" "on"
EndSection

# ... (leave other stuff unchanged)

Section "ServerLayout"
	# ... (leave other stuff unchanged)

	InputDevice "stylus"  "SendCoreEvents"
	InputDevice "eraser"  "SendCoreEvents"
	InputDevice "cursor"  "SendCoreEvents"
	InputDevice "pad"

	# ... (leave other stuff unchanged)
EndSection
...

Unfortunately (at least in my experience) the tablet pen needs to be plugged before xorg starts up. If xorg starts befure the tablet is plugged, there isn't any /dev/input link for the device and even if there were, xorg wouldn't be able to use it. It just gives up and ignores those pointers.

If xorg loaded up the drivers ok, the following output should be in /var/log/Xorg.0.log:

...

(II) LoadModule: "wacom"
(II) Loading /usr/lib/xorg/modules/input/wacom_drv.so
(II) Module wacom: vendor="X.Org Foundation"
    compiled for 4.3.99.902, module version = 1.0.0
    Module class: X.Org XInput Driver
    ABI class: X.Org XInput driver, version 0.6
(II) Wacom driver level: 47-0.7.4 $

...

(**) Option "SendCoreEvents"
(**) stylus: always reports core events
(**) stylus device is /dev/input/graphire4
(**) stylus is in absolute mode
(**) WACOM: suppress value is 2
(**) Option "USB" "on"
(**) stylus: reading USB link
(**) Option "BaudRate" "9600"
(**) stylus: serial speed 9600
(**) Option "SendCoreEvents"
(**) eraser: always reports core events
(**) eraser device is /dev/input/graphire4
(**) eraser is in absolute mode
(**) WACOM: suppress value is 2
(**) Option "USB" "on"
(**) eraser: reading USB link
(**) Option "BaudRate" "9600"
(**) eraser: serial speed 9600
(**) Option "SendCoreEvents"
(**) cursor: always reports core events
(**) cursor device is /dev/input/graphire4
(**) cursor is in absolute mode
(**) WACOM: suppress value is 2
(**) Option "USB" "on"
(**) cursor: reading USB link
(**) Option "BaudRate" "9600"
(**) cursor: serial speed 9600
(**) pad device is /dev/input/graphire4
(**) pad is in absolute mode
(**) WACOM: suppress value is 2
(**) Option "USB" "on"
(**) pad: reading USB link
(**) Option "BaudRate" "9600"
(**) pad: serial speed 9600

...

(II) XINPUT: Adding extended input device "pad" (type: Wacom Pad)
(II) XINPUT: Adding extended input device "cursor" (type: Wacom Cursor)
(II) XINPUT: Adding extended input device "eraser" (type: Wacom Eraser)
(II) XINPUT: Adding extended input device "stylus" (type: Wacom Stylus)
(II) XINPUT: Adding extended input device "Synaptics touchpad" (type: MOUSE)
(II) XINPUT: Adding extended input device "USB Mouse" (type: MOUSE)
Synaptics DeviceInit called
SynapticsCtrl called.
(**) Option "Device" "/dev/input/graphire4"
stylus Wacom X driver grabbed event device
(==) Wacom using pressure threshold of 30 for button 1
(==) Wacom USB Graphire4 tablet speed=9600 maxX=10208 maxY=7424 maxZ=511 resX=2032 resY=2032 suppress=2 tilt=disabled
(==) Wacom device "stylus" top X=0 top Y=0 bottom X=10208 bottom Y=7424
(==) Wacom device "eraser" top X=0 top Y=0 bottom X=10208 bottom Y=7424
(==) Wacom device "cursor" top X=0 top Y=0 bottom X=10208 bottom Y=7424
(==) Wacom device "pad" top X=0 top Y=0 bottom X=10208 bottom Y=7424
    xkb_keycodes             { include "xfree86+aliases(qwerty)" };
    xkb_types                { include "complete" };
    xkb_compatibility        { include "complete" };
    xkb_symbols              { include "pc(pc105)+pt" };
    xkb_geometry             { include "pc(pc105)" };

...

Using the tablet pen

Well, now that the tablet pen is working, it is just like a normal pointing device. Some software applications may have explicit support for some features, but that's not a requirement.

The GIMP has explicit support for such devices and it is practically zero-configuration.

References

go back to top of document

Making X rendered text pretty

I'll start describing this hack from the end: results first. Then I'm sure that if your text looks like the images on the left side of the examples (the bad ones), you'll really want to enable anti-aliasing for your X display. You're using Linux, right?

Ugly, non anti-aliased font render Anti-aliased font rendering glory
screenshot with standard font rendering screenshot with anti-aliased font rendering
Even these thumbnailed images show a quality improvement in the font rendering. Click for full image.
Detail 1 non anti-aliased Detail 1 anti-aliased
detail of absent font anti-aliasing detail of improved font rendering
See the menu bar and the address text? Looks great on the right side picture doesn't it?
Detail 2 non anti-aliased Detail 2 anti-aliased
detail of absent font anti-aliasing detail of improved font rendering
There's nothing to look for here. The difference is more than obvious.

This is a simple and safe hack that has a big impact, making X rendered text look much better and more enjoyable to look at. Only font rendering is affected with this procedure; pictures will not be anti-aliased/hinted.

The procedure to make fonts prettier involves different font rendering concepts like anti-aliasing, hinting and sub-pixel rendering. Although LCD and CRT monitors are based on very different technologies, their use is transparent to people: they serve the same purpose and are used in the same way. This case however makes a difference; font rendering looks different on CRT and LCD displays and this procedure needs to be slightly changed for CRT screens. All that's necessary is to install some true-type fonts, slightly tweak the X.org and FreeType's configurations (xorg.conf and /etc/fonts/local.conf).

  1. Install some (better) font packages:

    The standard X fonts (75dpi, 100dpi, etc) are not quite as desirable as more recent kinds of fonts. Furthermore, they are not TrueType fonts and thus don't support hinting. It is then necessary to install a couple of base TrueType fonts. I installed the following font packages on my laptop's Gentoo Linux:

    # --- necessary - TrueType fonts
# media-fonts/corefonts 
# media-fonts/freefonts 
# --- optional - more TrueType fonts
# media-fonts/sharefonts 
# media-fonts/terminus-font 
# media-fonts/ttf-bitstream-vera 
# media-fonts/unifont 
# media-fonts/artwiz-fonts 
# media-fonts/dejavu
emerge corefonts freefonts ttf-bitstream-vera artwiz-fonts sharefonts terminus-font unifont dejavu

    Some cool TrueType fonts should be installed by now if nothing went wrong. But X.org can't use them yet.

  2. Configure X.org to use the installed true type fonts:

    First of all, backup xorg.conf configuration file. Although the font changes aren't intrusive, it never hurts to keep the original.

    Make sure that FreeType is handling font rendering for X.org. Look in the Section "Module" for a directive like Load "freetype". Mine looks like this:

    # snip of /etc/X11/xorg.conf

Section "Module"
	# ... (leave other stuff unchanged)
	
	# This loads the Type1 and FreeType font modules
	Load		"type1"  # this is actually ignored by X.org
	Load		"speedo" # this is actually ignored by X.org
	Load		"freetype"
	# This loads the GLX module
	Load		"glx"
	# This loads the DRI module
	Load		"dri"
	# This loads synaptics touchpad driver
	Load		"synaptics"
EndSection

    Then look for the Section "Files", where some FontPath directives should already be in place:

    # snip of /etc/X11/xorg.conf

Section "Files"
	# ... (leave other stuff unchanged)
	
	FontPath   "/usr/share/fonts/misc:unscaled"
	FontPath   "/usr/share/fonts/Type1"
	# TTF is actually TrueType
	FontPath   "/usr/share/fonts/TTF"
	# Standard X fonts
	FontPath   "/usr/share/fonts/75dpi:unscaled"
	FontPath   "/usr/share/fonts/100dpi:unscaled"
	FontPath   "/usr/share/fonts/local"
	
	# ... (leave other stuff unchanged)
EndSection

    The installed font packages must be added to xorg.org configuration so X.org can use them. This is achieved by adding FontPath directives for each installed font package. The relevant part of Section "Files" should be like this:

    # snip of /etc/X11/xorg.conf

Section "Files"
	# ... (leave other stuff unchanged)
	
	FontPath   "/usr/share/fonts/misc:unscaled"
	FontPath   "/usr/share/fonts/Type1"
	# TTF is actually TrueType
	FontPath   "/usr/share/fonts/TTF"
	# Third party TrueType fonts
	FontPath   "/usr/share/fonts/corefonts"
	FontPath   "/usr/share/fonts/freefont"
	FontPath   "/usr/share/fonts/sharefonts"
	FontPath   "/usr/share/fonts/terminus"
	FontPath   "/usr/share/fonts/ttf-bitstream-vera"
	FontPath   "/usr/share/fonts/unifont"
	# Standard X fonts
	FontPath   "/usr/share/fonts/75dpi:unscaled"
	FontPath   "/usr/share/fonts/100dpi:unscaled"
	FontPath   "/usr/share/fonts/local"
	# Another third party TrueType fonts
	FontPath   "/usr/share/fonts/artwiz"
	FontPath   "/usr/share/fonts/dejavu"
	
	# ... (leave other stuff unchanged)
EndSection

    Standard and third party font packages are mixed because the relative order that X.org picks them up matters.

  3. Configure the FreeType rendering engine to do anti-aliasing and sub-pixel hinting on TrueType fonts:

    Next step is to configure the FreeType enable anti-aliasing and sub-pixel hinting.

    These settings are controlled globally in /etc/fonts/local.conf or per-user on ~/.fonts/local.conf, so change what you prefer bearing in mind that ~/.fonts/local.conf takes precedence over (i.e. will override) the global configuration file.

    My advice is to make your changes and try them out in ~/.fonts/local.conf and when you're happy with the results, copy it into /etc/fonts/local.conf because if things go horribly wrong, you can just remove your ~/.fonts/local.conf and start over again without harming the system.

    My default /etc/fonts/local.conf looked like this:

    <?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">

<!-- /etc/fonts/local.conf file for local customization -->

<fontconfig>

</fontconfig>

    Let's copy it into ~/.fonts/local.conf with 'cp /etc/fonts/local.conf ~/.fonts/local.conf' and change it there. Let's add some xml configuration directives between <fontconfig> and <fontconfig>.

    Note: To spare you from typing all this, in the end of this tutorial there's a link to a complete local.conf configuration file. Be sure to take a look at the file and/or at this tutorial before actually using it.

    	<!-- Setup pixel order. This is set to 'none' because X
	     already knows about LCD pixel order. If it doesn't work, 
	     try changing 'none' to 'rgb' (standard for LCDs -->
	<match target="font">
		<edit mode="assign" name="rgba">
			<const>none</const>
		</edit>
	</match>

	<!-- Enable sub-pixel hinting. This is the real deal -->
	<match target="font">
		<edit mode="assign" name="hinting">
			<bool>true</bool>
		</edit>
	</match>
	
	<!-- Set hinting amount. 'hintfull' is probably ok, but
	     'none', 'hintslight', 'hintmedium' and 'hintfull' are
	     also accepted and should be fairly self explanatory -->
	<match target="font">
		<edit mode="assign" name="hintstyle">
			<const>hintfull</const>
		</edit>
	</match>

	<!-- Enable anti-aliasing. We'll enable the non-patented
	     FreeType autohinter and antialiasing algorithms. The alternative
	     is the patented bytecode interpreter, which is said to look
	     better, but it is not detailed here. -->
	<match target="font">
		<edit mode="assign" name="antialias">
			<bool>true</bool>
		</edit>
	</match>
	<match target="pattern">
		<edit mode="assign" name="autohint">
			<bool>true</bool>
		</edit>
	</match>

  4. Disable autohinting for bold fonts:

    Bold face autohinted fonts may become pretty ugly, so we selectively disable autohinting for them. Just add this piece of xml before </fontconfig>

    	<!-- Disable hinting for bold fonts -->
	<match target="font" name="family" >
		<test name="weight" compare="more" >
			<const>medium</const>
		</test>
		<edit mode="assign" name="autohint" >
			<bool>false</bool>
		</edit>
	</match>
  5. Configure the FreeType rendering engine to replace non TrueType fonts by TrueType equivalents (and hint them):

    You see, hinting only works well with TrueType fonts because of the way that they're rendered. Other fonts may become even uglier than without anti-aliasing and hinting, so we replace them by TrueType equivalents. This shows the added configurations in ~/.fonts/local.conf, before </fontconfig>.

    	<!-- Change the non TrueType font Helvetica into
	        a TrueType sans-serif font. This is easily reusable
		with other fonts. -->
	<match target="pattern" name="family" >
		<test name="family" qual="any" >
			<string>Helvetica</string>
		</test>
		<edit mode="assign" name="family" >
			<string>sans-serif</string>
		</edit>
	</match>

    Here's a full freetype-local.conf file already written with the above configurations. Just copy it into ~/.fonts/local.conf.

  6. Restart X.org and showoff your new pretty fonts
  7. Make changes global:

    If everything went well, you may now replace the global configuration file with a simple 'cp ~/.fonts/local.conf /etc/fonts/local.conf'.

MS Windows XP can display a simillar effect through the ClearType setting. Enable it via Desktop Properties - Appearence - Effects and select ClearType in the "Use the following method to smooth edges of screen fonts" drop down box.

Much better, isn't it?

References

go back to top of document

Speeding up gentoo ebuild searches: eix

Frequently I search for packages in portage and more often than not, it takes forever, especially if it is the first search after a bootup (before things get cached). Fortunately there are (not very elegant) solutions for this. According to the Gentoo wiki, "searches for ebuilds take about 1-2 seconds on a modest machine (Athlon 1.4GHz)".

An existing solution is the esearch package, but another even faster is the EbuildIndeX or eix. Usage is just like emerge search or emerge -s:

archon ~ # emerge -s amarok
Searching...   
[ Results for search key : amarok ]
[ Applications found : 1 ]
 
 *  media-sound/amarok
       Latest version available: 1.3.8
       Latest version installed: 1.3.8
       Size of downloaded files: 8,523 kB
       Homepage:    http://amarok.kde.org/
       Description: amaroK - the audio player for KDE.
       License:     GPL-2


archon ~ # eix -s amarok
* media-sound/amarok 
     Available versions:  1.3.6 1.3.8 [M]1.4_beta1
     Installed:           1.3.8
     Homepage:            http://amarok.kde.org/
     Description:         amaroK - the audio player for KDE.


Found 1 matches
archon ~ #

Although eix -s and emerge -s are functionally equivalent, the latter takes much more time to complete:

Tool first run later runs
emerge -s real 0m47.609s
user 0m1.505s
sys 0m0.658s
 real 0m3.048s
user 0m1.818s
sys 0m0.216s
eix -s real 0m0.288s
user 0m0.056s
sys 0m0.011s
 real 0m0.074s
user 0m0.054s
sys 0m0.010s

Convinced? I was. The behind the scenes info about eix is that it works not by searching the portage tree, but by using its own index. Of course that index needs to be re-built after each portage sync (emerge sync). Doesn't sound so good... but the eix guys supplied a very useful tool that does just that: the portage sync and index rebuild. The package comprises the following 3 tools:

So get to work and install eix (either stable of ~' version) right away if you search for ebuilds a lot like I do. It will save you a lot of time:

# emerge eix package 
archon ~ # emerge eix
...
# create your first eix index (necessary step)
archon ~ # eix-update
...
# stop using 'emerge sync' and start using 'eix-sync'
archon ~ # eix-sync
...
# stop using 'emerge -s' and start using 'eix -s'
archon ~ # eix -s amarok
...

References

go back to top of document

Associate static names with network interfaces

My laptop has 2 network cards that I use regularly; An ethernet and a wireless interface. Back in the pre-udev days, by tweaking the order of the modules in /etc/modules.autoload.d/kernel-2.6, the interface name could be chosen - ethernet: eth0, wireless: eth1.
Knowing what device corresponds to what interface name is generally a good thing (TM) for configuring wpa_supplicant or other interface bound devices. On my servers, it is fairly tipical to have more than one network card but I can't use the same method because generally some NICs have the same chip and thus use the same driver.
It is also a good thing (TM) to be able to switch NICs between PCI slots and keep NIC names and configurations unchanged (think of 6 NIC server that needs one replaced... a PCI slot failure...).

Now, in the recent udev days, ethernet isn't always eth0 and wireless isn't always eth1. Sometimes ethernet is eth2 and/or wireless is eth0. Due to the way that udev interacts with the kernel, interface setup ordering isn't always the same.

The old way - nameif

There's a way to deal with these issues and forget them once and for all! It is a fairly old tool called nameif that associates NICs to interface names by their MAC addresses.
For this example, let's assume we have 2 NICs, with the following MAC addresses: ethernet - aa:aa:aa:aa:aa:aa, wireless - bb:bb:bb:bb:bb:bb. These NICs will be called ethLAN and ethRN. nameif requires /etc/mactab - a configuration file to associate MAC addresses to interface names.

# example of /etc/mactab
#
# ethernet NIC: mac aa:aa:aa:aa:aa:aa
aa:aa:aa:aa:aa:aa        ethLAN
# wireless NIC: mac bb:bb:bb:bb:bb:bb
bb:bb:bb:bb:bb:bb        ethRN

After setting up /etc/mactab, all that's left is to run nameif before bringing the interfaces up. It is possible to have a small init script that just runs nameif, but you must make sure it runs before network interfaces are brought up.

NOTE: interface names as configured by the kernel are reserved! In this example, at least eth0 and eth1 are reserved and cannot be used as names for interfaces. That's why I use names like eth{NAME} instead of eth{NUMBER}.

The new way - udev

Modern systems use udev for device detection and module loading. udev can also associate NICs to interface names by their MAC addresses. On these systems, it is much easier and more elegant to use udev instead of nameif.

All udev enabled distributions run the udev userland programs early in the boot process, so all that's needed is to tweak some udev rules to have it create the interfaces with the intended names.

# example rule /etc/udev/rules.d/10-nic.rules
#
# ethernet NIC: mac aa:aa:aa:aa:aa:aa
KERNEL=="eth*",SYSFS{address}=="aa:aa:aa:aa:aa:aa",NAME="ethLAN"
# wireless NIC: mac bb:bb:bb:bb:bb:bb
KERNEL=="eth*",SYSFS{address}=="bb:bb:bb:bb:bb:bb",NAME="ethRN"

Next time udev runs it will create the network interfaces accordingly to the rules above. When it finds the NIC with MAC address aa:aa:aa:aa:aa:aa, it will associate the name ethLAN to it.

go back to top of document

Detect network cable state and set interface up/down automatically

When there are multiple network interfaces available, sometimes one of them is preferred and sometimes it is not. For example, if both ethernet and wireless networks are available, I prefer the ethernet link, but if I need to take the laptop somewhere and the link goes down, the wireless network should take over and change routing so that I can keep using the network almost transparently. Currently, this can be done with two different tools: ifplugd and netplug.

ifplugd

ifplugd was written by Lennart Poettering and released with an opensource license sometime in 2002. It is a daemon that monitors ethernet devices and automatically configures them when the cable is plugged. If the cable is unplugged, ifplugd unconfigures it and continues to monitor the cable state. The end result is that the interface is only configured and eventually routed through when the cable is really connected.

The Gentoo way of using ifplugd is very very easy. All that's needed is sys-apps/ifplugd and >=sys-apps/baselayout-1.12.0._pre14. You may need to ACCEPT_KEYWORDS="~x86" to be able to install baselayout-1.12.0* or above, because it is still not marked stable.

No configuration is needed to use ifplugd. The net.eth* init scripts (generally on default runlevel) automatically detect and use it by default.
Alternatively, /etc/init.d/ifplugd can be run from the default runlevel while leaving net.eth* disabled - ifplugd will start them if cables are connected. Advanced configuration can be tweaked in /etc/conf.d/ifplugd if necessary. The end result is as follows:

Boot messages

 * Starting ethLAN
 *   Starting ifplugd on ethLAN ...                                       [ ok ]
 *     Backgrounding ...

Cable plugged in

archon ~ # ifplugstatus 
lo: link beat detected
ethRN: unplugged 
ethLAN: link beat detected
eth0: unplugged

archon ~ # ifconfig ethLAN
ethLAN    Link encap:Ethernet  HWaddr aa:aa:aa:aa:aa:aa  
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:773 errors:0 dropped:0 overruns:0 frame:0
          TX packets:618 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:548101 (535.2 Kb)  TX bytes:91673 (89.5 Kb)
          Interrupt:18 Memory:feafc000-0 

archon ~ # ip route list
192.168.0.0/24 dev ethLAN  proto kernel  scope link  src 192.168.0.3
127.0.0.0/8 dev lo  scope link 
default via 192.168.0.254 dev ethLAN
archon ~ #

Cable unplugged

archon ~ # ifplugstatus 
lo: link beat detected
ethRN: unplugged
ethLAN: unplugged
eth0: unplugged

archon ~ # ifconfig ethLAN
ethLAN    Link encap:Ethernet  HWaddr aa:aa:aa:aa:aa:aa  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:773 errors:0 dropped:0 overruns:0 frame:0
          TX packets:618 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:548101 (535.2 Kb)  TX bytes:91673 (89.5 Kb)
          Interrupt:18 Memory:feafc000-0 

archon ~ # ip route list
127.0.0.0/8 dev lo  scope link

netplug

netplug is a daemon functionally similar to ifplugd. It was written and released with an opensource license by Brian O'Sullivan sometime in 2003.

netplug manages network interfaces according to cable state: plugged in or out. It brings up an interface and runs a dhcp client when a cable is plugged and brings the interface down when the cable is unplugged. It is smaller than ifplugd and has less features, but those are not relevant for most people.

The Gentoo way of using netplug is very very easy too. It is necessary to have sys-apps/netplug and >=sys-apps/baselayout-1.12.0._pre14.

No configuration is needed, but advanced settings can be tweaked in /etc/netplug/netplug.conf. If both netplug and ifplugd are present, netplug is used, unless you tweak /etc/conf.d/net. The end result is as follows:

Boot messages

 * Starting ethLAN
 *   Starting netplug on ethLAN ...                                       [ ok ]
 *     Backgrounding ...

Cable plugged in

archon ~ # ifconfig ethLAN
ethLAN    Link encap:Ethernet  HWaddr aa:aa:aa:aa:aa:aa
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2768 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2002537 (1.9 Mb)  TX bytes:2444 (2.3 Kb)
          Interrupt:18 Memory:feafc000-0 

archon ~ # ip route list
192.168.0.0/24 dev ethLAN  proto kernel  scope link  src 192.168.0.3
127.0.0.0/8 dev lo  scope link 
default via 192.168.0.254 dev ethLAN
archon ~ #

Cable unplugged

archon ~ # ifconfig ethLAN
ethLAN    Link encap:Ethernet  HWaddr aa:aa:aa:aa:aa:aa  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:2741 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2011884 (1.9 Mb)  TX bytes:5719 (5.5 Kb)
          Interrupt:18 Memory:feafc000-0 

archon ~ # ip route list
127.0.0.0/8 dev lo  scope link

Me? I use netplug.

References

go back to top of document