Anyhow, no math or programming in this post, I’m afraid, just good old-fashioned system debugging.

Background

If I run any of the provided servers for the ICFP contest without DRI, I get no output. This is an FAQ but I’m on Gentoo and the FAQ is no help. It is also discussed in this bug report. Since it seems people have more success with accelerated drivers (why?) and software GL is known to work on my system for other programs, I suspect it is a bug specialized to the libraries used in the provided server. The quickest way to solve this, I figured, was to try an accelerated DRI driver for the Intel i965 in my Lenovo R61.

Kernel

First, I check that the kernel knows about the card and has DRM (the kernel end of DRI) set up:

$ zcat /proc/config.gz  | grep DRM
...
CONFIG_DRM=y
...
CONFIG_DRM_I915=y
...

The i965 uses the same driver as the i915 so this is good. Next, dmesg:

$ dmesg | grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized i915 1.6.0 20060119 on minor 0

Good. The kernel is happy.

X.org

First, enable DRI in /etc/X11/xorg.conf

Section "Module"
   ...
   Load "dri"
   ...
EndSection

I should point out this other part of my xorg.conf:

Section "Device"
   ...
   Driver      "intel"
   ...
EndSection

Next, I start X and see what it says about DRI and DRM.

$ grep 'dri[^v]' /var/log/Xorg.0.log
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(II) intel(0): [dri] visual configs initialized
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(II) AIGLX: Loaded and initialized /usr/lib/dri/i965_dri.so

Now I run the provided server and it gives output! But the moment the rover’s viewing radius clips the edge of the world, my computer crashes! My /var/log/Xorg.0.log.old tells me this happened:

Fatal server error:
lockup

Well, yes. I noticed. After some googling, I read that it is a known bug with old version of the Mesa library. But Gentoo has newer versions (major number 7) marked unstable because of known bugs in their interface with the Native Posix Thread Library (i.e. USE=-nptl is mandatory).

Upgrading Mesa

I put this in /etc/portage/package.keywords:

media-libs/mesa ~x86

and the following in /etc/portage/package.use to avoid the nptl bug:

media-libs/mesa -nptl
x11-base/xorg-server -nptl

The latter is necessary because the setting of the flag must agree between xorg-server and mesa even though this dependency is beyond the capabilities of Portage to reason about. After re-installing, I go through the above checks again. The kernel checks out, but X does not:

$ grep 'dri[^v]' /var/log/Xorg.0.log.old 
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI.

$ grep drm /var/log/Xorg.0.log.old 
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) intel(0): [drm] DRM interface version 1.0
(II) intel(0): [drm] drmSetBusid failed (8, pci:0000:00:02.0), Permission denied

I really don’t know what this means, and neither does anyone else on the internet really. The troubleshooting page on the DRI wiki says this may be caused by your kernel being compiled with a different version of GCC than the DRI driver, but not certainly, and not always. I do fit this description, so I decided to give it a shot. A bit nerve-wracking, since I don’t have a rescue disk with me, but it worked.

End of story. I can watch my mars rover in beautifully accelerated 3D. Here’s the final “good” output of all the above greping

$ dmesg | grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized i915 1.6.0 20060119 on minor 0

 $ grep 'dri[^v]' /var/log/Xorg.0.log 
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(II) intel(0): [dri] visual configs initialized
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(II) AIGLX: Loaded and initialized /usr/lib/dri/i965_dri.so

$ grep drm /var/log/Xorg.0.log 
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) intel(0): [drm] DRM interface version 1.3
(II) intel(0): [drm] created "i915" driver at busid "pci:0000:00:02.0"
(II) intel(0): [drm] added 8192 byte SAREA at 0xf885d000
(II) intel(0): [drm] mapped SAREA 0xf885d000 to 0xb7fb0000
(II) intel(0): [drm] framebuffer handle = 0xe0050000
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): [drm] Registers = 0xf8100000
(II) intel(0): [drm] ring buffer = 0xe0000000
(II) intel(0): [drm] init sarea width,height = 1280 x 1280 (pitch 1280)
(II) intel(0): [drm] Back Buffer = 0xe2158000
(II) intel(0): [drm] Depth Buffer = 0xe2798000
(II) intel(0): [drm] textures = 0xe2dd8000
(II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
(II) intel(0): [drm] installed DRM signal handler
(II) intel(0): [drm] dma control initialized, using IRQ 20
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: drmOpenMinor returns 9
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0

As usual, this post is a literate Haskell file, so you can try it out by saving it to Inkscape.lhs, compiling with ghc --make Inkscape, grabbing the source file for the images above, and running ./Inkscape < demo.svg. The output will appear in Slides.pdf (and your directory will be polluted with temp files, so be aware).

For the record, multi-page documents have been on the Inkscape feature request tracker for many versions, so I presume it is a significant change. I do grok C and C++, thanks to the legacy-oriented education system, but take little enough pleasure from them that I would rather hack around the issue in Haskell.

> import Text.XML.HaXml
> import Text.XML.HaXml.Pretty
> import Text.XML.HaXml.Posn
> import Text.PrettyPrint.HughesPJ
> import Text.Printf
> import Data.List
> import System.IO
> import System.Cmd

HaXml is based on a combinator library for CFilters to filter, search, output, etc XML content. It is a little crufty in some ways — many datatypes are transpararent, and you have to do a lot of your own set up and tear down. The expected way to use it seems to be via processXmlWith :: CFilter -> IO () which is not sufficient for today’s task. The Hackage documentation pointed to an old version of the API, so I used the current version of the source code for documentation. I’d love any criticism like “you didn’t have to do X” or “here is an easier, safer way to do Y”.

I couldn’t think of a better way to narrate this code, so I’ll start with main for a high-level read, and then later fill in all the helper functions. Naturally we start with a call to xmlParse; the "-" is a required filename for error reporting.

> main = do input <- getContents
>           let xml = xmlParse "-" input

Then I grab the names of all the layer objects in the order they appear in the file, except for the special layer “Background” which I’ll include behind every slide. The call to verbatim spits them out as Strings instead of XML Content, and the "-" is yet another required filename for error reporting.

>           let names = delete "Background" 
>                       $ map verbatim 
>                       $ filterElem "-" getLayerNames
>                       $ xmlElem 
>                       $ xml
>           putStrLn $ "Making slides from layers:" 
>                        ++ concatMap ("\n\t"++) names ++ "\n"

Then for each layer, make a new version of the file with just that layer visible.

>           let outXmls = map (flip selectLayer xml) names
>               usedSlides = take (length names) slideNames
>           mapM_ (uncurry writeFile) 
>                 (zip (map (++".svg") slideNames) 
>                      (map (renderStyle xmlStyle . document) outXmls))

And some shell scripting done in Haskell. I didn’t even try to find a scripting library or anything to e.g. prevent me from building a malformed command.

>           mapM_ (\slide -> do 
>                    system $ "inkscape --export-text-to-path --export-pdf='" 
>                             ++ slide ++ ".pdf' '" ++ slide ++ ".svg'")
>                 usedSlides
>           
>           system $ "pdftk " 
>                      ++ concat (intersperse " " (map (++".pdf") usedSlides)) 
>                      ++ " cat output Slides.pdf"

So now to the little details:

Grabbing the layer names

Here is the first helper I wrote, wrapping HaXml’s attrval for a common case. This filter returns every tag whose attr attribute has the string value val.

> matchAttrString :: String -> String -> CFilter i
> matchAttrString attr val = attrval (attr, AttValue [Left val])

The next helper is one that maps a tag to its attribute value, otherwise discards anything else it sees. The HaXml function iffind will pass the attr attribute value of a tag to literal which just returns it. If the attribute isn’t found, or the XML data isn’t a tag, then none will discard it.

> showAttr :: String -> CFilter i
> showAttr attr = iffind attr literal none

The Inkscape layers are contained in <g inkscape:groupmode='layer' ...> tags. The name of the layer is in the inkscape:label attribute. I imagine this will change as Inkscape evolves. The o is the composition operator for CFilters.

> isLayer = matchAttrString "inkscape:groupmode" "layer"
> getLayerNames = showAttr "inkscape:label" `o` isLayer `o` children

Isolating the layers

Again proceeding from the outside of my program inwards, a layer is isolated with this helper, using iffind to match either the layer name or the layer “Background” which I’m going to leave in all the output files. The final keep argument to iffind says to keep parts of the XML that don’t have the "inkscape:label" attribute.

> selectLayer :: String -> Document Posn -> Document Posn
> selectLayer layer doc = onContent "-" (chip (visible `o` onlyLayer)) doc
>     where onlyLayer = iffind "inkscape:label" layerOrBG keep
>           layerOrBG l = if l == layer || l == "Background" then keep else none

In writing visible I was surprised that there was a combinator to set all attributes for a tag, but none to set a single attribute.

> visible = setAttr "style" "display:inline"
> setAttr key val (CElem (Elem tag attrs cs) i) = [CElem (Elem tag newattrs cs) i]
>     where newattrs = (key, AttValue [Left val]) : filter ((/= key) . fst) attrs
> setAttr key val other = [other] -- Hackish?

As I mentioned before, there is no way that I see to directly apply this filter to an XML file using HaXml. The type CFilter = Content -> [Content] needs wrapping to apply to an XML Element directly. Notice how I have to pass in a file for error reporting; it feels like I’m doing things I’m not supposed to.

> filterElem :: FilePath -> CFilter Posn -> Element Posn -> [Content Posn]
> filterElem file f e = f (CElem e (posInNewCxt file Nothing))

> xmlElem (Document _ _ e _) = e

And now the function to actually apply a filter to an XML document. This is straight from the body of processXmlWith in the HaXml source, with filterElem pulled out.

> onContent :: FilePath -> (CFilter Posn) -> Document Posn -> Document Posn
> onContent file filter (Document p s e m) =
>     case filterElem file filter e of
>              [CElem e' _] -> Document p s e' m
>              []           -> error "produced no output"
>              _            -> error "produced more than one output"

Bits and pieces

I also used a modified style for the HughesPJ pretty printer

> xmlStyle = style { mode = LeftMode }

And a big list of slide names with three digits, for this one-off job. Better would be to use an API for generating fresh temporary files.

> slideNumbers = map (printf "%03d") ([1..999] :: [Int])
> slideNames = map ("Slide"++) slideNumbers

This is the fix I used with LiveCD 2005.0

1. insert the liveCD into your external cdrom
2. type “gentoo doscsi [enter]”
3. shell (when it gives you an error)
4. type “udevstart [enter]” and exit
5. type “/dev/ram0 [enter]“

• See also: http://bugs.gentoo.org/show_bug.cgi?id=83276 and http://gentoo-wiki.com/TIP_Installing_Gentoo_using_USB-CDROM
• Aha, there is a page just for this laptop: http://gentoo-wiki.com/HARDWARE_Dell_Latitude_D410

• WhizzyTeX – realtime preview of TeX in a separate window. This synergizes the idea of GUI word processing (the important part of WYSIWYG is realtime visualization) and markup languages (which beat all GUI’s hands-down in terms of ease of editing complex documents).
• preview-latex – has an “edit” mode where you hack latex, then when you leave edit mode it renders a little preview. I haven’t tried it in depth yet.
• AucTex – A nice LaTeX major mode (or so I hear)

L 99 99 99 99 99 99 99 99 ...

Another issue I then faced was the lack of devfs, and I don’t have udev set up (I have no idea what this even involves) and my static dev directory was all permissioned wrong and I wasn’t sure what permissions are ‘’supposed” to be on PTYs and TTYs, or even the real difference between them. Once I have time to do more than a naive chmodding, I may or may not have a useful udev entry.

$ lspci
00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP
00:10.0 VGA compatible controller: ATI Technologies Inc M9+ 5C63 [Radeon Mobility 9200 (AGP)] (rev 01)
0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI
0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
0001:10:17.0 Class ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O
0001:10:18.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0001:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0001:10:1b.0 USB Controller: NEC Corporation USB (rev 43)
0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43)
0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
0002:20:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI
0002:20:0d.0 Class ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100
0002:20:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire (rev 81)
0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev 80)

Once the system was running, here’s what lsmod has to say; some stuff is in the kernel permanently, but I think I tried to make a lot of modules just for the purposes of you being able to see what I did

$ lsmod
Module                  Size  Used by
snd_pcm_oss            65024  0 
snd_mixer_oss          21984  1 snd_pcm_oss
snd_powermac           51612  0 
snd_pcm               104324  2 snd_pcm_oss,snd_powermac
snd_timer              28164  1 snd_pcm
snd                    69748  5 snd_pcm_oss,snd_mixer_oss,snd_powermac,snd_pcm,snd_timer
soundcore              11396  1 snd
snd_page_alloc         11880  1 snd_pcm
i2c_powermac            6080  0 
i2c_dev                10948  0 
radeon                123976  2
drm                    84120  3 radeon
uninorth_agp           11048  1
agpgart                38428  2 drm,uninorth_agp
bcm43xx               117104  0 
ieee80211softmac       30944  1 bcm43xx
ieee80211              36488  2 bcm43xx,ieee80211softmac
ieee80211_crypt         7072  1 ieee80211
sungem                 36772  0 
sungem_phy             10048  1 sungem
therm_adt746x          14028  0 
hfs                    56804  0 

And here are some key files on the system; you’ll have to do some of your own digging, or read a bit below, to have a clue what they all mean.

• xorg.conf
• yaboot.conf
• /proc/config.gz

Wired Ethernet – The wired ethernet card return device class ffff on the PCI bus, blatantly violating spec, so you can’t inspect what it is. Well, I’ll tell you: it is a Sun Gem card, and uses the sungem.ko module. Once the module is inserted, then lspci can identify it properly, so the module knows about the spec violation or something

Wireless Ethernet – The broadcom Airport Extreme has drivers now, which is a huge victory for open source I’d say. The project is at http://bcm43xx.berlios.de/. It works perfectly, as far as I can tell.

Keyboard – The keyboard uses the ADB bus so you need to go into the mac driver section and be sure to have that included or you’ll have a hell of a time, like I did, since a lot of sites claim it is a USB keyboard or some such. I didn’t remap any of the crazy apple keys, but xmodmap can almost certain do a bang-up job of that. SCIM with scim-anthy works beautifully for Japanese input, by the way.

Touchpad – I didn’t really do anything to get it to work… I think I enabled some mac touchpad driver, which is pretty obvious. There is a kernel module to map keys to second and third mouse buttons, and you then configure it in /etc/sysctl.conf

Sound – The ALSA driver snd-powermac.ko depends on i2c stuff (I forget which submodule) but that dependency is not known to modprobe. Be sure to insert all your i2c drivers before snd-powermac. When I failed to do this, I got a kernel panic.

Video – The Radeon works perfectly, with acceleration. I used the radeon.ko kernel module and, if I recall correctly, the radeon X.org driver (as opposed to the ati driver)

Booting – Booting is not too bad, and if you haven’t done much reading, you won’t know that you want to use a tool called yaboot. Other useful things are that you hold option key combo to get the mac boot selector, or shift-C to boot from CDROM. You may need to get into the Open Firmware, for which you hold option-apple-O-F.

Microphone – As far as I know, the snd-powermac driver doesn’t support the built-in mic. So I got a Logitch USB mic, and used the snd-usb or something to that effect. The problem is that the mic device won’t open unless you specify single channel recording, which most apps don’t do. So what I did was use the great /etc/asound.conf to create a pseudo-device that just drives the mic single channel as a slave:

pcm.mic {
  type plug
  slave {
    pcm "hw:1,0"
    channels 1
    rate 44100
  }
}

It is possible I did this file wrong, but I think it is correct. BUT most GUI apps (linphone in particular) don’t seem to see the virtual mic even though any commandline ALSA app can use it. Probably the GUI apps are using some less-than-ideal way to get a listing of the devices which doesn’t go through the ALSA configuration layer.

Power Management – A lot of people said this “just works” including whatever “suspend” it uses, but I didn’t have time to test it. My wife says it is fine each night as she closes the lid.

Goofy Stuff – There is a kernel module to turn the breathing light into an HDD activity indicator. I think that is sweet so other mac users will think your computer is hyperventilating. Also, I believe you can control the backlight on the screen and thus make your apple logo flicker or something.

A while ago, I installed Scim pretty painlessly for Gtk and Qt apps with the following commands:

scim -d
export GTKIMMODULE=scim
export QTIMMODULE=scim

export XMODIFIERS='@im=SCIM'

Now, I can see japanese text in vim in the console, I can echo it and redirect to a file, I can name files with japanese chars. But the funny thing is I still don’t have japanese chars or input in gvim or emacs, where you’d think it might be easier. Well, I don’t care about gvim but I certainly intend to get it working in emacs.

Another cool thing I did (and the reason for a lot of this) was to write some UTF-8 xml parsing code with PXP and O’Caml. It was a wonderful experience.

To summarize, here is the process which I believe will get Gentoo japanized, if not totally internationalized:

Hopefully, you have USE="nls cjk"

Also, some japanese fonts

emerge uim scim scim-uim scim-qtimm
gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules
scim -d
export GTKIMMODULE=scim
export QTIMMODULE=scim
export XMODIFIERS='@im=SCIM'
export LCALL="enUS.UTF-8"

I run them before X