This weekend I finally updated my LG X130 netbook to Slackware 13.37. This is one of my “stable” machines that I use all the time for day-to-day tasks, so I do not run -current on it, as I depend on it too much. Slackware-current is very interesting for research and testing all the new stuff, but it can break when you least expect it. And then you need a “stable” installation to at least access the internet, pay the bills, read e-mail, etc. So I left this netbook as one of the last machines to update to Slackware 13.37.

And it went quite smoothly. Except for one thing: the wireless adapter was not working…

Old problem returning?

I remembered that when I first installed Slackware on this netbook about a year ago, I also had a problem with this rt3090 card. The kernel confused it with the rt2800 and tried to load the rt2800pci module – which did not work with this adapter.
At the time, I found a simple solution by ‘Googling”: putting the rt2800pci module on the blacklist by creating a simple text file in /etc/modprobe.d/ with a single line:

blacklist rt2800pci

So I checked if that file was still there, and it was…
I did a “lsmod | grep rt2” and the result was:

rt2860sta 483303 1
crc_ccitt 1087 1 rt2860sta

So the correct module was loaded!

More investigation was needed

“ifconfig” did not show the wlan0 interface, but “ifconfig -a” did.
I tried “ifconfig wlan0 up” but it returned with:

SIOCSIFFLAGS: Operation not permitted

So what do we do when a kernel module has problems? Check the dmesg log…
I did a “dmesg | grep -i rt” and found this interesting line:

rt2860 0000:02:00.0: firmware file rt3090.bin request failed (-2)

So, the rt2860 module is looking for the rt3090.bin firmware and not finding it!

But isn’t the rt2860 driver used for the rt3090? I remembered reading (don’t know where, probably when I first installed Slackware 13.1 on this netbook) that the rt3090 adapter was handled 100% by the rt2860 driver.
I decided to check the /lib/firmware directory, where all the firmware files are installed in Slackware. There were several rt2xxx.bin files, but no rt3090.bin.

This is where I decided to get bold

I thought: It’s not working anyway, so what can I loose?
And I created a symlink rt3090.bin to rt2860.bin They are the same in the kernel anyway, right?
I rebooted, and… It worked!

My wireless adapter was working again and my netbook was fully operational as before the update.

But was this really the correct solution?

I decided to go straight to the source and browse around on kernel.org. And in their git repository I found this commit:

rt2860sta: Use latest firmware for RT3090

author Ben Hutchings
Sat, 30 Apr 2011 18:31:32 +0000 (19:31 +0100)
committer Ben Hutchings
Tue, 17 May 2011 04:22:12 +0000 (05:22 +0100)

Ralink’s original drivers for RT2800P/RT2800E-family chips used
multiple different versions of the firmware for different chips. The
rt2860sta driver in staging was briefly converted to load different
files for different chips. However, the current rt2860.bin is
supposed to work on all of them, so replace rt3090.bin with a symlink.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Well, well! So the official solution was to create a symlink as well!
I checked the tree in their git repository and there you can see they have the symlink “rt3090.bin” pointing to the rt2860.bin file, just as I did.
I also noticed a second symlink: rt3070.bin is pointing to rt2870.bin.

Report it back to “The Man”

Now that I was reassured that my solution was the correct one, I sent an e-mail to Pat Volkerding about my findings.
It would be nice to see the rt2860-firmware-26-fw-1 package create the symlink on installation, to prevent some headaches around the world

The user sent me a patch that worked, but hacking kernel modules is not to be taken lightly, so I wanted to understand what was going on…

Read the documentation!

It’s something most people don’t like, but it actually is a good idea to read the documentation once in a while
In /usr/src/linux/Documentation/scsi/scsi_mid_low_api.txt (if you have the 2.6.37.x kernel installed), I found this interesting comment:

Locks: up to and including 2.6.36, struct Scsi_Host::host_lock
held on entry (with “irqsave”) and is expected to be
held on return. From 2.6.37 onwards, queuecommand is
called without any locks held.

Well, that seems to be the culprit then… So now I headed for the kernel git repository and found this interesting commit:

Move the mid-layer’s ->queuecommand() invocation from being locked
with the host lock to being unlocked to facilitate speeding up the
critical path for drivers who don’t need this lock taken anyway.

The patch below presents a simple SCSI host lock push-down as an
equivalent transformation. No locking or other behavior should change
with this patch. All existing bugs and locking orders are preserved.

Additionally, add one parameter to queuecommand,
struct Scsi_Host *
and remove one parameter from queuecommand,
void (*done)(struct scsi_cmnd *)

Scsi_Host* is a convenient pointer that most host drivers need anyway,
and ‘done’ is redundant to struct scsi_cmnd->scsi_done.

Minimal code disturbance was attempted with this change. Most drivers
needed only two one-line modifications for their host lock push-down.

I checked some of the patches in the kernel tree and indeed they seemed quite simple. This is the patch for the aha1542 driver:

--- a/drivers/scsi/aha1542.c
+++ b/drivers/scsi/aha1542.c
@@ -558,7 +558,7 @@ static void aha1542_intr_handle(struct Scsi_Host *shost)
 };
 }
-static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
+static int aha1542_queuecommand_lck(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 {
 unchar ahacmd = CMD_START_SCSI;
 unchar direction;
@@ -718,6 +718,8 @@ static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 return 0;
 }
+static DEF_SCSI_QCMD(aha1542_queuecommand)
+
 /* Initialize mailboxes */
 static void setup_mailboxes(int bse, struct Scsi_Host *shpnt)
 {

Patching the VHBA module

In the SVN repository for VHBA I found this patch:

--- trunk/vhba-module/vhba.c 2010/08/15 20:11:18 691
+++ trunk/vhba-module/vhba.c 2011/02/27 15:56:27 730
@@ -363,7 +363,7 @@
 spin_unlock_irqrestore(&vhost->cmd_lock, flags);
 }
-static int vhba_queuecommand(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *))
+static int vhba_queuecommand_lck(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *))
 {
 struct vhba_device *vdev;
 int retval;
@@ -388,6 +388,12 @@
 return retval;
 }
+#ifdef DEF_SCSI_QCMD
+DEF_SCSI_QCMD(vhba_queuecommand)
+#else
+#define vhba_queuecommand vhba_queuecommand_lck
+#endif
+
 static int vhba_abort(struct scsi_cmnd *cmd)
 {
 struct vhba_device *vdev;

(there’s actually a bit more, but that’s just a cosmetic change…)

The #ifdef / #else / #endif structure was included so that it will work on “older” kernels as well.
It looked similar enough to the official kernel changes, so I included that patch in my SlackBuild script and the VHBA module started working again without crashing my system!

RocketRaid module with similar behavior…

And then yesterday I saw a post on LinuxQuestions about similar problems with the RocketRaid rr232x driver. Since it’s also a “SCSI” driver and it also crashed, I imagined it to have the same cause.

I created a patch based on my little research and posted it in the forum:

--- rr232x-linux-src-v1.10/osm/linux/osm_linux.c 2009-07-15 22:28:28.000000000 -0300
+++ rr232x-linux-src-v1.10_patched/osm/linux/osm_linux.c 2011-03-19 20:27:49.000000000 -0300
@@ -874,7 +874,7 @@
 }
 }
-static int hpt_queuecommand (Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
+static int hpt_queuecommand_lck (Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 {
 struct Scsi_Host *phost = sc_host(SCpnt);
 PVBUS_EXT vbus_ext = get_vbus_ext(phost);
@@ -1408,6 +1408,12 @@
 return 0;
 }
+#ifdef DEF_SCSI_QCMD
+DEF_SCSI_QCMD(hpt_queuecommand)
+#else
+#define hpt_queuecommand hpt_queuecommand_lck
+#endif
+
 static int hpt_reset (Scsi_Cmnd *SCpnt)
 {
 PVBUS_EXT vbus_ext = get_vbus_ext(sc_host(SCpnt));

Today the original poster answered that it worked “like a charm”
This patch can be downloaded from my site.

This is a question that pops up once in a while on IRC and the forums, and the answer is yes, but there are some little details to take care of.
I made a step-by-step how-to once for myself, so I thought I might as well put it here on my blog

What is needed

• an image editor – I use the Gimp in this post, since it is included in Slackware
• an image file – basically anything readable by the Gimp can be used
• root access to edit lilo.conf and run lilo

Choosing an image

Like I wrote above, basically any image can be used, as long as you can open it with the Gimp, but results may vary.

At boot time, you have a screen with 640×480 pixels resolution, capable of showing 256 different colors. The bitmap format used for the logo file works with a 256-color index, so you can theoretically have an image with 256 shades of blue, with reasonable results.
If you use an image with many different colors to start with, the result can be quite ugly…

First I’ll show the basic steps, then the results with some different images.

Converting the image

I’ll start with a picture that uses mainly red and green colors:

The first thing we need to do is resize it to 640×480. Open it in the Gimp and choose: > Image > Scale Image... from the menu, and type 640 in the “width” box:

As this picture was taken with a digital camera, it already comes in the right width:height ratio of 4:3. In the second example I’ll show how to deal with pictures with different ratios.
Click on “Scale” and the first step is done.

The next step is to create the 256 color index, as that is the maximum number of color we can display at boot time. Choose: > Image > Mode > Indexed... from the menu.
Select “Generate optimum palette” with a maximum of 255 colors:

Click on “Convert” to create the index and convert the picture.

This is a good time to take a close look at the result. Use the zoom to enlarge the result, as this picture will be shown full-screen on your monitor at boot time. You will only have 255 different colors at this time.
Here is a sample of the picture I used:

As you can see, the shades of green and red are limited now, but the result is acceptable.

Now save the image in the bitmap format with: > File > Save As...
Do not close the Gimp yet, as we will need to get some information from the image in a while.

Preparing lilo

The following steps need to be run as root. As always, be careful here…

First of all, copy the bitmap file to the /boot directory.
Second, edit /etc/lilo.conf with your favorite editor. There s a section that defines the filename of the boot logo we need to edit. I called mine “flower.bmp”, so the result looks like this:

...
# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
 bitmap = /boot/flower.bmp
...

That was the easy part

Now we need to change the positions and colors of the menu and the timer.

First, let’s think about the positions. This usually takes some “trial-and-error” to get nice results, but there are some general ideas:

• Positions are in “columns” (1-80) and “lines” (1-30) normally (pixels are possible for finer positioning)
• Try to choose a more neutral part of the picture, like a darker spot, or a part where there is only blue sky visible

For the first run, just try to make an educated guess (experience helps), and change after booting if you don’t like the result.

Second, we need to select the colors for the menu.
Remember, we now have these 255 colors to choose from after indexing the picture. But the trick is to know the number of the color…
Luckily, this is easy to find out in the Gimp. Choose: > Colors > Map > Rearrange Colormap... from the menu:

From this list, I’ll choose a pair of light and dark colors for the menu and the timer.
This is the combination I selected:

...
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
 bmp-colors = 188,253,188,13,253,188
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
 bmp-table = 62,5,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
 bmp-timer = 65,27,188,253,188
...

Save your lilo.conf and run lilo to recreate the boot loader with the new settings.
If you get an error running lilo about an invalid image format, recheck your image with the Gimp.

Now reboot and see the result:

(I was able to take a “screenshot” while booting because I did this in a virtual machine…)

Advanced tips & tricks 1 – Different width:height ratio

My example was based on a picture that already had the 4:3 width:height ratio, but what if you have a different picture?
As an example, I’ll use this picture that comes in the “FullHD” format of 1920×1080 pixels (ratio 16:9):

(This is the train station of Cabangu, where the great aviator Santos-Dumont was born)

In this case, in the > Image > Scale Image... dialog, we’ll choose “480″ for the height:

Now the width is too large for the 640×480 standard we need, so we’ll choose: > Image > Canvas Size... from the menu, and:

1. Click on the “chain” to break the link between the width and height
2. Enter “640″ as the width
3. Change the X Offset by value or by moving the image with the mouse

This is my example:

For the rest, just click on “Resize” and follow the steps as in the first example. This should be the result:

Advanced tips & tricks 2 – Widescreen monitors

This all looks nice, but if you have a modern wide-screen monitor, your boot logo will probably look distorted when shown full-screen, something like this:

We can “trick” this to look a bit better by distorting the bitmap image the opposite way, a technique commonly used in movies to record widescreen images on standard 4:3 film (see this explanation about anamorphic recording).

Let’s get back to the original Cabangu picture. Instead of scaling it to 853×480, we’ll break that chain again and scale it to 640×480:

After color-indexing this horizontally “compressed” or “anamorphic” picture should be the result:

But the result should show up nicely on a wide-screen monitor:

Conclusion

This post just showed some basic examples of creating your own boot-logo screens. Use your imagination to create our own!
If you think you created something nice, feel free to post a link to the image in a comment.

For more advanced lilo options, do read the manual (# man lilo.conf)

The system

Recently I upgraded a system that was still running Slackware 13.0. It’s a not-so-new system, but should be good enough to serve as a desktop for some more time: 2.6GHz P4, 1GB of memory, 160GB hard drive. Video, sound, network are all on-board, using a cheap Via chipset.
This box has had some stability problems before, like freezing with several tabs open in Firefox, but I thought it was simply because that browser was getting more and more “obese”

Youtube or not Youtube?

After upgrading it to Slackware 13.1, it showed very “consistent” behavior: All videos from Youtube were without sound or stuttering sound. I checked the usual suspects: flashplayer-plugin, alsaconf, etc., but without success. All I found on the internet about Youtube videos without sound was old information from years ago that did not apply.
I tried to save some videos locally, and found that they played well in mplayer, but also with stuttering sound in gxine. So the problem was not related to Youtube…

Comparing with another system

Next step was comparing the configuration with a similar box, with the same sound chip (at least I thought…). On this second system I had no problems at all with sound, although the configuration is quite similar – it’s just a bit newer and has some better specs (memory, processor, etc.)
But… there was a small difference between the two HDA Intel chips…

This is the one that stutters:

02:01.0 Audio device: VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller)
 Subsystem: ASUSTeK Computer Inc. Device 818f
 Flags: bus master, fast devsel, latency 0, IRQ 17
 Memory at fbefc000 (32-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 2
 Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit-
 Capabilities: [70] Express Legacy Endpoint, MSI 00
 Capabilities: [100] Virtual Channel 
 Capabilities: [130] Root Complex Link 
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

and this is the one that works fine:

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
 Subsystem: ASUSTeK Computer Inc. P5KPL-CM Motherboard
 Flags: bus master, fast devsel, latency 0, IRQ 44
 Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 2
 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
 Capabilities: [100] Virtual Channel 
 Capabilities: [130] Root Complex Link 
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

Google is our friend again

So, back to Google, and after some browsing I found an interesting article about nvidia chips that had the same problem here.

I edited the /etc/modprobe.d/sound.conf file and added this line:

options snd-hda-intel enable_msi=0

And, after a reboot, the system played videos in Youtube and locally without any stuttering

The kernel patch that is suggested in the article is already included in the kernel that comes with Slackware 13.1, but it only checks for the nvidia chip.
If this box continues to work fine, I might patch the source for the HDA Intel driver (hda_intel.c) and compile a custom kernel. If that works fine, I’ll send the patch to the maintainer of this module.

Installation of Slackware 13.1 went smoothly, as always, except for one thing: the maximum resolution with the NVIDIA driver (built with the script from SlackBuilds.org) was 1280×1024. This annoyed me and intrigued me at the same time, as the Debian spin-off worked flawlessly at 1600×900.

In the /var/log/Xorg.0.log (the first place to look when X does not work the way you expect) I noticed the following strange error message:

Failed to allocate primary buffer: out of memory

The /etc/X11/xorg.conf created by the nvidia-settings program was almost the same on both Linux flavors, so that was not the problem.

Then I started to check the differences between the two installations…
I noticed that the Debian spin-off used an older kernel and an older version of the NVIDIA driver, but I never had problems with the newer versions on other systems.

Next step: Google.

I found several reports of the same problem, and the “solution” (more like a work-around) was adding the “nopat” parameter to the kernel.
I checked the configuration of the kernel used by Slackware 13.1 (/boot/config) against the configuration used to build the kernel that came with the Debian spin-off and they were different indeed:

in Slackware it is:

CONFIG_X86_PAT=y

While the other has:

# CONFIG_X86_PAT is not set

I added the “nopat” parameter in /etc/lilo.conf:

...
append=" vt.default_utf8=0 nopat"
...

After running lilo and rebooting, the resolution went to 1600×900 without problems!

Now it’s just a lot of irony that I have to set “nopat” to use Slackware, but I hope he forgives me until I compile my own kernel for this box

I have configured several other USB modems on my Slackware systems, so I was sure I could get this one to work as well. I did it in about 20 minutes and here are the basic steps:

1) Switching from “drive” to modem
Many of these USB modems first present themselves as “media”, so that Windows users can install the built-in software from them. Then the installed driver “ejects” the media and the modem presents its real identity as a modem.
On Linux, we have to “eject” the media as well by software, and for this we can use a udev rule.
When plugged in the first time, we can check the ID of the media / modem in a terminal window with lsusb. The result included the following line:

Bus 001 Device 005: ID 0421:060c Nokia Mobile Phones

So this is the ID of the modem presenting itself as removable media.

Now we need a udev rule to “eject” the media. This is what I wrote, based on some previous experience and this guide on writing udev rules:

SUBSYSTEMS=="usb", SYSFS{idVendor}=="0421", SYSFS{idProduct}=="060c", ACTION=="add", RUN+="/usr/bin/eject -s %k", OPTIONS+="last_rule"

Now let’s analyze this rule:

• SUBSYSTEMS=="usb" – speaks for itself: we are handling a USB device
• SYSFS{idVendor}=="0421", SYSFS{idProduct}=="060c" – this identifies our Nokia modem
• ACTION=="add" – means that this rule is only for when the device is added
• RUN+="/usr/bin/eject -s %k" – calls the “eject” program with the parameters -s (a “SCSI” device, like /dev/s??) and %k (the device name the kernel gave it, like /dev/sdb0 or whatever the “media” is named)
• OPTIONS+="last_rule" – make sure that later rules for this device have no effect

Save this rule as 91-nokiacs10.rules in /etc/udev/rules.d/
This is the directory where we save all our “custom” rules, as opposed to the standard rules that stay in /lib/udev/rules.d where we should not mess around (as they will be overwritten with the next update of udev).

So now, pull out the modem and plug it in again. If everything is fine, after a short time you can check your usb devices again with lsusb and now the line should be:

Bus 001 Device 005: ID 0421:060e Nokia Mobile Phones

Check that the Product ID has changed from 060c to 060e

2) Check your modem device
Now check your devices with ls /dev/tty* and you should see in the list ttyACM0 and ttyACM1.
Use ttyACM0 in your favorite dialer to connect to your internet provider. I use pppd, but it should work with kpppd or whatever you prefer!

3) Next steps
I actually use a second script that automatically “dials” my provider and connects me to the internet. This is done by creating a second rule in the same file, but this time for the 060e device, starting a small shell script.
This script checks if the ttyACM0 device is available, calls pppd, checks ifconfig if the ppp0 device is up and creates an entry in the routing table.
Since my script is very ugly, I won’t put it here, but it was not that difficult to write, so I’ll leave this as an exercise!

Something went wrong when I canceled the “CNAME” entry in the DNS server that pointed “underpop.online.fr/n/nielshorn” to the old blogspot site. When I created the new “underpop.online.fr/n/nielshorn” subdomain I couldn’t get it to point at my own server. :-/

But with a little help from my hosting provider everything is OK now.

Feel free to look around and to comment on any errors or broken links!

Since I compile most programs that are not available on a standard Slackware installation from source, I didn’t have too much trouble switching completely from 32-bits to 64-bits when the official release came out.
But for some programs the source code is not available. The original author / site may have disappeared, or it might simply be “closed” software.
I had this problem with some older programs I still used and they simply would not run on Slackware64. The error they normally return is:

<program_name>: No such file or directory

This error actually means that the binary file is looking for some (32-bits) library it cannot find, simply because they do not exist on pure 64-bits Linux installations.

One option was to go “multi-lib” – install the 32-bits libraries on my Slackware64 box. But I did not want to go that way, as I preferred to keep my installation as “pure” as possible.

So I started looking for another solution, and on the LinuxQuestions.org forum someone pointed me to statifier.

Statifier simply combines the binary executable with all the libraries it needs into one (big!) executable “semi-static” file. I won’t go into the details how it does that (because I also do not understand all the details…), so if you want to know more, check out the site of the author.

The only problem is that you will need a 32-bits machine where your binary works fine, to “statify” it. I still had my 32-bits Slackware partition, so no problem for me here.

Statifier is open source software, so you can build it yourself, or get my package for Slackware on my site.

After installing or building Statifier on your 32-bits machine, you can use it to “statify” your 32-bits binary like this:

$ statifier <binary> <new_binary>

Remember that the result will be a lot bigger than the original, as it includes all the libraries that are normally loaded dynamically. As an example, I used it on “l3p”, a small program to convert LDraw files to POV-Ray files, only available in a 32-bits version.
The original file was 140K, the statified version is 2.7M
But it solved my problem and I can use l3p on my 64-bits Slackware64 installation!

If you want to use l3p on Slackware64 as well but this is all too technical for you, you can get the statified version of l3p as a Slackware package from my site.

What will you need:

1. LeoCAD – to “build” your constrution
2. (optional) a viewer program, like LDView or ldglite
3. l3p – to convert the .ldr (LDRaw) file to .pov (POV-Ray)
4. (optional) The “lgeo” parts collection
5. POV-Ray – the “Ray-Tracer program”

If you use Slackware, you can find packages for all of these on my site and SlackBuilds for all except 3 on www.slackbuilds.org. For many other Linux distributions packages are available in their repositories.

First step – Build something!

If you do not have any LDraw file yet with a Lego creation, then now is the time to make one.
As an example for this tutorial, I built a little penguin, based on the instructions here, with LeoCAD:

Save your creation with LeoCAD as a “.ldr” file (”File” – “Save as” from the menu). The resulting file in my case was:

0 Model exported from LeoCAD
0 Original name: Penguin.lcd
 1 14 -50.00 -0.00 -60.00 -0.00 0.00 1.00 -0.00 1.00 -0.00 -1.00 -0.00 -0.00 3002.DAT
 1 15 -50.00 -24.00 -60.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 15 -50.00 -48.00 -60.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -50.00 -24.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -70.00 -48.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -30.00 -48.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 0 -50.00 -72.00 -40.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3004.DAT
 1 14 -50.00 -72.00 -70.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3003.DAT
 1 0 -50.00 -96.00 -50.00 -1.00 0.00 -0.00 0.00 1.00 -0.00 0.00 -0.00 -1.00 3003.DAT
0

The file can be downloaded from my site as well.

Second step – View your model with ldglite or LDView

This step can be skipped, but it is a nice test to check if the programs can find all the LDRAW parts on your computer. LeoCAD uses its own parts library, so being able to view it there does not necessarily mean that the LDRAW library is accessible.

This is how the penguin looks like in ldglite, a simple but very fast program to visualize your creations:

A second option is to use LDView, a very nice and very complete program to visualize your creations. It creates a more realistic view of the model, with some shading effects:

Third step – Ray-Tracing

So the images created by LDView are nice. But we want something even better! Enter POV-Ray, a very professional Ray-Tracing program that is completely free.
It “traces” light-rays, by tracing paths of “light particles” from one or more light sources, bouncing off surfaces and reflecting into the lens of a camera.

So we define the position and colors of the light sources, the position and angle of the camera, the types of surfaces (smooth, reflective, rough, etc.), etc.

Sounds complicated? Well, there is a very nice utility called l3p that tries to do most if it automatically to help us get started. l3p reads an “ldr” file, guesses the best position and angle for the camera so that the whole creation will fit in the image, and sets up three light sources around the model. Then it creates a .pov file that can be read by POV-Ray.

l3p needs to know where the LDRAW library is stored on your computer. This can be set by the LDRAWDIR environment variable like:
$ export LDRAWDIR=/usr/share/LDRAW

Put this in your start-up script like ~/.bash_profile (if you use bash for a shell).

Enough theory, let’s create our first .pov file:
$ l3p -o Penguin.ldr

This reads the “Penguin.ldr” file we created and writes a “Penguin.pov” file in the current directory.
I used just one option – “-o” – which instructs l3p to overwrite Penguin.pov if it already exists, since we’ll perform various tests before we get the final result.

Now let’s run POV-Ray to transform the .pov file into an image:
$ povray +OPenguin.png +FN +P Penguin.pov

The options here mean:

• +OPenguin.png – Output will be Penguin.png
• +FN – Format will be a PNG file
• +P – Pause after creating the image, showing the result on the screen

The result should look like this:

For a first test, it’s just about “OK”… But we can do better than this!

Since in most tests we’ll run l3p and povray as a sequence, we’ll put both commands on one line like this:
$ l3p <options> && povray <options>

The “&&” means that the next command is only executed if the previous terminated without error.

So let’s try:
$ l3p -b -o Penguin.ldr && povray +OPenguin.png +FN +W640 +H480 +P Penguin.pov

What did we add:

• -b – add a standard blue background to replace the black void
• +W640 – Create the image with a width of 640 pixels instead of the standard 320
• +H480 – and a height of 480 pixels instead of 240

The result should look like this:

Let’s improve the image a bit more:
$ l3p -b -q4 -bu -o Penguin.ldr && povray +OPenguin.png +FN +W640 +H480 +A +P Penguin.pov

The new options are:

• -q4 – Quality level 4, this includes the “Lego” name on the studs
• -bu – Create “bumps”, this makes the surfaces more “uneven”, or more realistic
• +A – Anti-aliasing, this prevents those “jagged edges”

This should be the result:

Advanced options

As I wrote in the beginning, l3p automatically guesses the best position and angle for the camera and light sources. But we can change them as we please.
Let’s try something:
$ l3p -b -q4 -bu -cg40,45 -cpct10 -f -o Penguin.ldr && povray +OPenguin.png +FN +W640 +H480 +A +P Penguin.pov

I included two new options:

• -cg40,45 – Put the camera at “globe” positions 40° latitude and 45° longitude (the default is 30,45 so we put it a bit “higher”)
• -cpct10 – move the camera back 10%, so that the object is not so close to the edges of the image
• -f – put a “floor” under the penguin instead of letting it float in the sky, so that we can see the shadows of the light sources

Here is the result:

You can play around with the position of the light sources using the “-lg” option. I’ll leave this as an exercise!

There are many more advanced options to try. Type “l3p” without any options to see the complete list! If you have a good tip, feel free to post a comment so that I can learn something new.

Using the lgeo library

The images we created with the standard l3p + povray combination look quite good, but when we enlarge the images, the pieces look a bit unrealistic, with edges that are too sharp, etc.

Enter the “lgeo” library of pieces…

The lgeo pieces are specially designed for use with POV-Ray, with more realistic edges, surfaces, etc. l3p can automatically replace all LDRAW pieces with lgeo pieces if a substitute is available (any many are available, at least for the more “standard” pieces).

We just need to include the “-lgeo” parameter (and have the lgeo library installed and “readable” by povray – this needs some configuration…).
This created a nice image of our Penguin at a larger size:
$ l3p -b -q4 -bu -cg40,45 -cpct10 -f -lgeo -o Penguin.ldr && povray +OPenguin.png +FN +W1280 +H960 +A +P Penguin.pov

And this is the result (click on the image to see the full-scale picture):

As you can see, the studs and the edges look more realistic in this picture.

Have fun!

All of these are free & open software. For nagios and cacti you can download SlackBuild scripts from slackbuilds.org maintained by me. For cacti, if you prefer a complete package, you can download one for Slackware here.

For ntop, I adapted a SlackBuild originally written by Michiel van Wessem to install the newer 3.3.10 version. The ntop authors decided to automatically download & install some dependencies (Lua + GeoIP), even if you already have those installed. Since this is a very bad idea (they install it the way they like, while with Slackware YOU are supposed to be in control), I adapted their ‘configure.in’ and ‘Makefile.am’ scripts to simply check if those programs are installed and exit if they are not.
Then you can install them the way you like (and following the normal standards) and install ntop afterwards.

With Michiel’s permission, I submitted a new SlackBuild script for ntop so SlackBuilds.org that is currently in the pending queue.

Over the next few days / weeks I hope to have some time to elaborate on these three packages and write some hints on how to install and configure them.