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

It looks like the problem isn't specific to Xsun24, but rather is due to
FBIOGATTR not returning enough information about the framebuffer: it only
returns one width, which gets passed to miScreenInit as two values,
one of which is used to set the actual screen width and the other of which
sets the offset between rows in the pixmap.  So, internally, X can handle
this; it just isn't getting the correct information provided to it.

I changed cfbScreenInit() in xsrc/xc/programs/Xserver/cfb/cfbscrinit.c:
	if (xsize == 2048)
	    xsize = 1280;
(this is the screen size in pixels; the other parameter, width, is the
offset between rows, also in pixels), and the screen-and-a-half behavior
went away.  But this isn't a general solution, obviously.  The values
passed to cfbScreenInit (and, eventually, to miScreenInit) come from the
sunFbs array (also alphaFbs, amigaFbs, and macppcFbs, for other instances
of Xserver); I think the distinction between the two meanings of screen
width needs to be made in that structure (which includes the struct
fbtype).  I think there was some mention on port-macppc a while back
about similar problems (in particular, the skewed output from when the
screen width is used as the row offset), but I suspect current macppc
users are using the Xfree version, and won't run into this problem any
more; the remaining platforms may not have any framebuffers that use
dissimilar values for width and offset.

If the framebuffer attributes returned by FBIOGATTR report that the
device is a FBTYPE_FFB (in fb_type), but lists FBTYPE_MEMCOLOR in the
list of emulated devices (in fba->emu_types[]), I think Xsun24 would
be able to detect this, without having to duplicate the existing
cg8-specific support.  Whether the effor to do that is worthwhile
depends on how close we are to seeing a working Xfree driver.

Charles