Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: X and framebuffer depth
Message-ID: <8910231855.AA02359@expire.lcs.mit.edu>
Date: 23 Oct 89 18:55:38 GMT
References: <8910231635.AA00493@yorkshire.East.Sun.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 29


	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.