> Using -install also fails (but interstingly, running xlockmore in a window does
> 'the right thing' colorwise, but with a private colormap)...

To, erm, follow myself up...

Grubbing around in the innards of xlockmore reveals the following nugget,

void
setColormap(Display * display, Window window, Colormap cmap, Bool inwindow)
{
        XSetWindowColormap(display, window, cmap);
        /* Now, here we have a problem.  When we are running full-screen, the
           window's override_redirect attribute is on.  So, the window manager
           never gets the ColormapNotify event that gets generated on the
           above XSetWindowColormap() call, and does not So, a quick solution
           is to install it ourselves.  The problem with this is that it
           violates the ICCCM convention that only window managers should
           install colormaps. Indeed, Fvwm _enforces_ this by immediately
           un-doing any XInstallColormap() performed by a client (which is why
           this does not work right under Fvwm). */

        if (!inwindow)
                XInstallColormap(display, cmap);
}

This is probably the reason why (under twm) the screen becomes white, then
flashes black (the correct colormap), then instantly returns to white again as
xlockmore starts up full screen, but works as expected in a window.

I suspect that (unless anyone's got this working properly on an 8-bit frame
buffer under twm) I either need 24 bits, to sidestep the problem entirely, or
a more 'relaxed' window manager.

Anyone have an xlockmore/*wm combination that works on a cgsix? (Or, anything
that blows away this hypothesis? ;-)

Dan.