> The current implementation (in 1.6 and current) is less than optimal;
> the S24, at least, appears to have smarts we're not using, although I
> don't know how much improvement we'd see if we were able to take
> advantage of the extra hardware.

> Part of the problem is that documentation is sparse; we have register
> definitions, but don't know how to use them.

I've seen documentation for the S24 that I don't feel free to pass on
verbatim (I don't want my source to dry up), but I don't believe any
NDA violation or any such was involved in getting it to me, and I
certainly didn't go into any NDA covering it myself, so I will be happy
to answer questions and describe the hardware in my own words.

> Another part of the problem is that the X server isn't smart enough
> to use the parts we do know about; the S24 provides both an
> 8-bit-deep framebuffer and a 32-bit-deep (24 usable) framebuffer at
> different addresses, and in theory, the X server could use the
> 8-bit-deep version for any windows that didn't need the greater
> depth,

One of my "copious spare time" projects is an X server that supports
both 8bpp PseudoColor and 24bpp TrueColor/DirectColor windows on the
S24.  There's no reason it can't be done; it just isn't quite what the
sample server framework is designed to handle.  And documentation on
the relevant internal server interfaces is..sparse. :-)

I have an S24 and a machine to go with it, but the hardware is on a
different continent from me now, so that project is on hold until at
least January (and maybe later if I find myself lacking round tuits).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B