for quite a while i’ve had the old 20″ monitor which i had been using previously sitting on my desktop along with an USB DisplayLink adapter — the idea being to hook the old monitor up as well as a third monitor¹. the displaylink driver provided by ubuntu lucid seemed to work properly — the monitor’s screen would turn green on connecting it and a framebuffer device (/dev/fb1) and so i tried various recipes floating around on ubuntu forums and elsewhere — all promising to achieve a grand unified desktop comprising all three monitors — and they either didn’t work or if they achieved the grand unified desktop it was unusable.

so, after another prolonged period during which the monitor and the displaylink adapter gathered even more dust, i tried a different approach: give up on the grand unified desktop goal and instead just try to make use of the monitor. the idea this time was to start up a VNC server, then use a VNC client to directly render the server into the framebuffer device (/dev/fb1) provided by linux’s displaylink driver. the vncserver bit is actually quite easy:

vncserver -name hidden -geometry 1600x1200 -depth 16 :42

which starts a VNC server for the :42 display.

the VNC client bit turned out to be a bit more difficult. ubuntu lucid does have directvnc client which is “a vnc client for the linux framebuffer device”². that client does seem to require keyboard and mouse access and in some configurations did not work at all or locked up my keyboard (not the mouse, though, funnily enough) or crashed the running X session, so no points on that one. further research luckily turned up vnc2dl by none other than quentin stafford-fraser one of the original VNC developers (and also the inventor of the webcam it seems). vnc2dl seemed a bit more promising and — after slightly modifying³ dldevice.c — did do the job:

sudo vnc2dl :42

next up was fusing display :42 to my main display :0 on a keyboard and mouse level so that i could just move the mouse pointer over to the left and end up on display :42 — here x2x (in the equally named ubuntu package) came into play:

x2x -west -to :42 >/dev/null 2>&1 &

and, hey, presto!, both displays are linked mouse and keyboard wise.

only thing still bothering me was that cut and paste was not working. to fix that required adding

vncconfig -nowin &

to my .vnc/xstartup file.

to have firefox run on display :42 required creation of a new firefox profile — i added that to .vnc/xstartup as well.⁴

the issue with suspend–resume is that the machine goes through the motions of suspending but then just comes back d’oh. googling around for “maverick suspend problem” i stumble over a post in the ubuntu forums citing the maverick release notes —

When the XHCI module is loaded for USB 3.0 operation the system cannot suspend. Manually unloading XHCI will allow suspend to complete normally. To avoid future suspend problems, the workaround is to add SUSPEND_MODULES=”xhci-hcd” to /etc/pm/config.d/unload_module then the system can suspend normally.

— hmph. following those instructions, suspend–resume are working.

while working on the dpkg support i also found out that debian/ubuntu has the very useful /etc/firefox-3.0, /etc/firefox-3.5, and /etc/thunderbird directories that allow me to provide package specific javascript to, for example, add a protocol handler for the rezzme: URI scheme. that along with gnome’s gconf tool gives us the same seamless rezzme user experience as on windows or mac OSX — unfortunately, it seems that nothing comparable exists for redhat/fedora based systems.¹

also the windows build code has been cleaned up and the no longer required dependency on setuptools removed.

what did bother me was that i couldn’t find an easy to use function for keyconfig to bind the page left and page right keys (aka F19 and F20) of my X200 keyboard to “previous tab” and “next tab”. after some digging i stumbled across the mozilla thunderbird 3 tabmail page which then allowed me to figure out how to create the code for keyconfig:

// next tab
var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1'].
    getService(Components.interfaces.nsIWindowMediator);
var winId = windowManager.getMostRecentWindow("mail:3pane");
var tabmail = winId.document.getElementById('tabmail')
tabmail.switchToTab((tabmail.tabContainer.selectedIndex + 1) % tabmail.tabInfo.length)

// previous tab
var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1'].
    getService(Components.interfaces.nsIWindowMediator);
var winId = windowManager.getMostRecentWindow("mail:3pane");
var tabmail = winId.document.getElementById('tabmail')
tabmail.switchToTab((tabmail.tabContainer.selectedIndex + tabmail.tabInfo.length - 1) % tabmail.tabInfo.length)

copy & paste the code snippets and use keyconfig’s “add key” feature to bind the code to whatever key you’d like to use.

after a lot of research i finally managed to track it down to the following:

1. firefox doesn’t seem to be really interested in what the user’s desktop settings say, the only guy it will listen to is fontconfig configured via /etc/fonts/conf.d!
2. to get rid of the blurry fonts i needed to drop the 10-hinting-{full,medium,slight}.conf from fontconfig’s /etc/fonts.conf.d directory

that fixed the blurry fonts in firefox and emacs.

to get emacs menu’s back to a more sensible size i had to edit $HOME/.emacs.d/gtkrc — changing the default face via M-x customize-face only affected the buffer and modeline fonts but not the menu itself. i’m using the DejaVu Sans fonts, so my gktrc file looks like this:

style "user-font"
{
    font_name="DejaVu Sans 8"
}
widget_class "*" style "user-font"
gtk-font-name="DejaVu Sans 8"

style "default"
{
    font_name="DejaVu Sans 8"
    bg[NORMAL] = { 1.0, 1.0, 1.0 }
}

that one fixed emacs.

not good. even worse when it means lost leads. so i set out to investigate. since OpenSim is being used in japan, it was a fair assumption that we might have a font problem here. this was confirmed by a twitter from adamfrisby:

@DrScofield so it should load fine.Only issue you need to be aware of is fonts – you need to use a font with the correct charset availible.

so, first port of call: how are we specifying the font to use for text rendering? digging through the OpenSim source i ended up in the VectorRenderModule:

    private void GDIDraw(string data, Graphics graph, char dataDelim)
    {
        Point startPoint = new Point(0, 0);
        Point endPoint = new Point(0, 0);
        Pen drawPen = new Pen(Color.Black, 7);
        string fontName = "Arial";
        float fontSize = 14;
        Font myFont = new Font(fontName, fontSize);
        SolidBrush myBrush = new SolidBrush(Color.Black);
        ...

gulp: we’ve got it hard coded

so, next question: can we change it dynamically? looking through the code, it seems like we might:

    ...
    else if (nextLine.StartsWith("FontName"))
    {
        nextLine = nextLine.Remove(0, 8);
        fontName = nextLine.Trim();
        myFont = new Font(fontName, fontSize);
    }
    ...

except, hmph, there is no osSetFontName() OSSL function

a couple of SMOPs later, we had osSetFontName() and could also configure the default font name in OpenSim.ini, good. now to figure out which linux font would do the trick.

i tried:¹

• Arial — no good: doesn’t have japanese script support
• DejaVu Sans/Serif — again, no good, no japanese script support
• Kochi Mincho — works!

— the configuration for that one is:

[VectorRender]
    font_name = "Kochi Mincho"

my next quest was to see whether i could find a font that would support the whole range: european scripts as well as japanese and also chinese.

…unfortunately, while windows users have Arial Unicode MS there is no such complete beast available to linux users — yes, there are fonts such as bitstream cybit, but their license conditions either don’t allow commercial use or only for a single user. so, if you are running under linux you need to localize your OpenSim installation via OpenSim.ini.

but! at least we figured out how to get japanese character sets supported in OpenSim on linux and can now configure one of our sametime 3d servers to support japanese OpenSim users properly!

sometime over the course of the last 10–14 days opensim must have crossed some (invisible) line drawn in the sandy thread beaches of monomania, as all of a sudden we noticed that three-avatar-meetings were working fine (chat & movement work) but as soon as we were joined by the fourth avatar, things came to a grinding halt: no movement, no chat (voice was still working but that’s to be expected as SL voice is pretty much running independent most of the time from what’s going on inside the region).

after some nose cone polishing, some more befuddled staring at the log files, and not finding anything immediately obvious, i went and discussed this problem with fellow opensimers on our intranet IRC opensim channel — sean had the good idea of mentioning the MONO_THREADS_PER_CPU environment variable. checking our startup script (just to make sure) showed that we were not setting it — and, thus, it was at its default setting of 50…

…so we went ahead and added it, setting it to 500. why 500? good question. and a question to which there is no clear answer: ask two opensimers and you’ll likely get three different recommendations, i’ve heard 75, 500, 1000, and also 2000. ralf haifisch recently tried to obtain clarity on this issue but so far the exact value for MONO_THREADS_PER_CPU remains a bit of magic.

and, guess what? that did the trick, it seems. we got over the three-avatar-limit.

update: since posting this i’ve been experiencing intermittent (that is, non-deterministic) mono crashes when running OpenSim, and have reverted to mono 2.0.1 which runs much more stable.

repeated staring at the intel(4) man pages resulted in the hunch to try and switch from EXA acceleration to XAA acceleration

Section "Device"
Identifier      "intel"
Driver          "intel"

Option          "monitor-VGA" "VGA"
Option          "monitor-LVDS" "LVDS"

Option          "AccelMethod" "XAA"
EndSection

an X server restart later, and, voilá!, glxgears shows its gears on screen 2. problem solved.