At 11:11 AM +0900 8/20/02, Sung-Won Chung wrote:
>>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.

Oops... that test program ran on a sparc, not a sparc64...

>
>>>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.

The cfbScreenInit has separate values for "xsize" and "width", so I think
it can support the ffb layout; I'm not sure what the best way to do that
is, though.  I looked briefly into special handling for the tcx, which
provides separate address ranges for accessing the framebuffer with 8
and 24 (32) bits/pixel, but I didn't get very far with that.  A new
24-bit-only device shouldn't be as difficult, though.  (I only see one
width value in struct fbtype, but perhaps the rowBytes value could be
guessed from fb_size, the total size needed to map the framebuffer)

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

I don't think that would work, as I believe the resolution for mmap is
in physical pages (8Kbytes on the sparc64?)  Since the real cg8 doesn't
support 1280x1024, recognizing that as a special case would probably
work.

>
>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.

I (think I...) successfully rebuilt X last night, using the xsrc.tgz from
1.5.2, on an Ultra 10 running 1.6beta4 (20020719000000) (I manually added
<machine/fbio.h>).  I haven't actually tried to run it yet, though.

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

I'm not sure what kernel support Xfree needs to access the framebuffer;
but I think having a working, even if unaccelerated, framebuffer could
be useful.  Someone with more (i.e., any...) experience with Xfree should
feel free to correct me if I'm wrong about that.

Charles

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