Subject: Re: Creator3D device driver running Xsun24 on Ultra 1E
To: Sung-Won Chung <email@example.com>
From: Charles Carvalho <firstname.lastname@example.org>
Date: 08/19/2002 19:56:54
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
>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
>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.
>Join the world’s largest e-mail service with MSN Hotmail.