Banging on multiple heads

I spent a bit of time each of the past few weeks trying out different graphics cards to drive two displays—a multihead configuration. Presently, I'm using an older ATI Radeon 7000-based card to run two displays at 1600 × 1200 each. The radeon driver included with the X.org X server can knit these together into a single display with an effective resolution of 3200 × 1200.

Other folks are using nVidia drivers to get similar configurations.

Once I had this setup running, I started to see familiar applications fail with a pleasant message:

$ gvim
The program 'gvim' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 13 error_code 3 request_code 128 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Dave Powell helped me to use xscope to watch the X11 protocol requests. This, and a little code browsing allows us a diagnosis.

It turns out that Xsun and Xorg use different implementations of the Xinerama extension (but with similar names). As far as I can tell, the standard behaviour changed after Sun developed support for a draft proposal. Now, a few years later, the applications know how to deal with both versions. With Xorg though, you now have a Sun system which doesn't speak Sun's Xinerama variant--hence our error message. Alan knows how to fix this for real but, after looking at libgdk startup, it's pretty easy to work around this with a preloaded shared object.

All we do is pretend that our display can't do Sun's Xinerama. That means we need a function like

$ cat > xin_shim.c
int
XineramaGetState()
{
        return (0);
}
^D

We then compile it into a shared object

$ cc -o xin_shim.so -G -Kpic xin_shim.c

or we could freely compile it into a shared object

$ which gcc
/usr/sfw/bin/gcc
$ gcc -o xin_shim.so -G -fpic xin_shim.c

Then, to use your shim, you use LD_PRELOAD (with an absolute path)

$ LD_PRELOAD=`pwd`/xin_shim.so gvim
[happy editing...]

Because xin_shim.so isn't in /usr/lib/secure, you may see messages from setuid processes as the linker refuses to preload your potentially unsafe object. The message looks something like

ld.so.1: /usr/lib/utmp_update: warning:
/home/sch/src/preloads/xin_shim.so: open failed: illegal insecure pathname

(2005-04-27 15:06:25.0) Permalink Comments [1]

smf(5): Chairman's Award

The smf(5) project team was honoured with the Chairman's Award for Innovation today, along with 14 other teams or individuals at Sun. I had a camera with me, and snapped a few pictures but, since the award ceremony was televised, don't have any from that part of the day. Afterwards, we gathered in the Menlo Park campus's amphitheater [TerraServer] for some photos. I managed to capture

the smf(5) team;

our sister team in Predictive Self-Healing, the Fault Management Architecture team; and

the CDDL team (but after they started to move towards one end of the amphitheatre).

We had a short lunch afterwards, but longer conversations with the other award winners, the nominating committee members and other executives:

I borrowed our newer Canon PowerShot SD300 for the day, because it's so much smaller than the S30. I had a little trouble with gphoto2, but I put the SD card directly in the slot on my Acer Ferrari running S10—which mounted directly and seamlessly.

smf(5) was the product of many people's contributions. There are team members who could only participate for a limited period or who are no longer at Sun, and many forms of contribution from all parts of the company—the end result couldn't have been reached without all the shared and distributed lifting. My thanks.

A small and quiet thanks to Jonathan for gesturing me into the studio camera's field of view.

(2005-04-26 23:21:01.0) Permalink Comments [2]

Neck kerchiefs (or neckerchiefs)

So, while I wore the final symmetric/named knot at the OpenSolaris CAB dinner, I haven't stopped wearing ties to work. I'm tying a variety of knots for four-in-hand ties—Nickys and half-Windsors for the most part—plus the occasional bow-tie. As far as I can determine, it hasn't affected my work.

This is, of course, my wrap-up post on neckties.

(2005-04-26 01:06:07.0) Permalink Comments [0]

Adrian explores libexacct

Adrian Cockroft has been exploring the extended accounting streams available in Solaris. By blogging about his exploration, Adrian is sharing his cognitive process—highly valuable to, say, the designer looking to improve a software subsystem for developers. I was amused by the following frustration-induced comment

The design is so abstract that it seems that reading meaningful data out of the log file is some obscure side effect of the code. You can read the data, but there is no guarantee that any specific item of data will be present. The accounting system has various options to send more or less data to the file, so it needs to be flexible, but the important thing is the meaning of the data being logged. I care about the semantic and informational content of the data source. What I get from exacct is "there are some tagged typed objects in this file". I can't consume the data without making assumptions about it, and the API doesn't embody those assumptions.

because some of these drawbacks were design goals: exacct is a general purpose, variable-length, grouped binary record format affording traversal in either direction through the file. I think Adrian's criticism is valid (except that it was always meant for reading and writing data) if I read it as you haven't written the accounting data handling layer yet.

While I wait for some time to think about how we might do that, I've filed

6260320 *wracct* should have some form of "for all objects" support

so we can fix at least one annoyance.

(2005-04-22 15:30:32.0) Permalink Comments [0]

Cameras on Solaris

Dan noted a while ago the libusb/libgphoto2 stack works well on Solaris 10 (and newer Express releases, of course). I've been using the gphoto2 CLI to manipulate my beaten-up Canon over USB, and then gthumb as my image browser/cataloguer. There are a few bugs here and there and some obvious enhancements needed, but the trajectory in this space is impessive. Since I've now got a "for-work-only-toy-camera", I'll keep experimenting with related applications on Solaris, and make any observations here.

You can get all of the mentioned software prebuilt for Solaris at Blastwave. A working libusb is available in /usr/sfw/lib.

Tie knot: Knot 7 (Half-Windsor) [reprise].

(2005-04-06 11:12:18.0) Permalink Comments [0]

Dinner with the board

I was lucky enough to be invited to the OpenSolaris community advisory board dinner last night in San Francisco. The very gracious Al Hopper and the versatile Casper Dik represented the newly formed board at our table, which enjoyed a witty and wide-ranging conversation (at least as I remember it). I also managed to meet physically Rich Teer, who I had only exchanged email with previously.

Since I've been handed down the old family digicam—a Canon PowerShot S30 with a broken LCD—and am now carrying it around for snaps, I took a few shots of the event:

 

In honour of the occasion, I wore the largest and last symmetric tie knot in Fink and Mao, and a new spread collar shirt that could contain it.

Tie knot: Bow.

(2005-04-05 14:03:01.0) Permalink Comments [1]

For the record, 10

Tie knot: Knot 78 (Balthus).

(2005-04-04 09:00:00.0) Permalink Comments [0]