[comp.windows.x] X and framebuffer depth

mce@EAST.SUN.COM (Mark Elgood - Sun BOS Software) (10/23/89)

	It is my understanding that in theory an X server, the X protocol,
	Xlib, XtIntrinsics, a toolkit and X applications should be able
	to operate regardless of the framebuffer depth (maybe a limit of
	24 or 32 bits?) and the types of visuals supported. 

	Thus a given application ought to be usable on a monochrome, grey
	scale, 8-bit psuedo color and 24-bit true color framebuffer without
	recompilation.

	Can anyone tell me what  reality is likely to be? Is it likely
	that  applications will be able to adapt to the number of colors 
	available?

	How easy would it be to port the sample server to a 4-bit 
	greyscale framebuffer?

	Is the path from an application to the server device-dependent code
	really clear of 1/8 bit dependencies.

	Is there a X server available for the NeXT machine since that has
	2 bit greyscale video?

	Please e-mail any thoughts regarding this subject to me any I will
	summarise on xpert.

	Mark Elgood

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/24/89)

	Thus a given application ought to be usable on a monochrome, grey
	scale, 8-bit psuedo color and 24-bit true color framebuffer without
	recompilation.

"Ought" is the operative word.  It is in theory possible, if you restrict
the application to specific kinds of graphics (e.g. stencil-and-paint).
It is certainly not true that all X applications are "naturally" constructed
this way, it's quite easy to use capabilities (e.g. writable color cells)
that don't exist on all displays.

	Can anyone tell me what  reality is likely to be? Is it likely
	that  applications will be able to adapt to the number of colors 
	available?

Some will, many won't.  A fair number of applications will fail if
given a static visual, for example, because they blindly try to allocate
writable cells.

	How easy would it be to port the sample server to a 4-bit 
	greyscale framebuffer?

Depends to a certain extent on what the layout of your frame buffer actually is.
If it isn't planar, the cfb code should be usable, possibly with some work.

	Is the path from an application to the server device-dependent code
	really clear of 1/8 bit dependencies.

There are existing servers out there that are 4-bit color.