>They open the framebuffer directly and scribble
>on it, whether or not X is running.

Since sizeof(unsigned long) = 8 on sparc64, I modified the
type of screenptr, screenstart to unsigned int. And the result
was the same as intended.

>>As a result, when I moves an xterm to the right end and it reaches
>>the border of screen, the hidden part of the xterm begins to appear
>>in the left border of screen.
>
>If the size of a row is actually 2K pixels, 8K bytes, then the xterm
>shouldn't wrap; it should disappear off to the right.

Yes, I misunderstood the Creator frame buffer mapping.
the pixel adjacent in vertical is 8192 bytes apart.
However, with some more test, I found that when the actual screen width
is 1280 * 4 bytes, the remaining 8192 - (1280 * 4) does not disappear,
but overlaps to the beginning of the same horizontal line.

I think, since Xsun24 assumes continuous frame buffer space,
to solve this problem, another function instead of sunInitCommon() called
by sunCG8Init would do. That means Creator should have its own FBTYPE and
relevant init function such as sunFFBInit() is needed.

Then the function can request sunMemoryMap() for each visible line
to obtain continuos mmaped memory corresponding to the discontinuos
Creator frame buffer space.

There is another queer things. The reason that local xterm is much slow was
that jump scroll of xterm doesn't work. However for an xterm running on
Creator over network, scroll speed was fast (comparable to cgsix),
since jump scroll works.

So I am building X libraries to recompile xterm with them. But as was Xun24,
compile on sparc64 fails with various compiler error (gcc, bfd, ar).
Especially, libXt can't be made even without -O option. So cross build seems 
to be necessary.

Considering, at near future, that accelearated XFree would run on 
NetBSD/sparc64,
is this work meaningful ?

Sung-Won


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com