> > I was thinking of the TC mfb, which is mono but uses byte addressing.
> > Only the lowest bit is significant (so depth of 1 and bpp of 8). Are
> > there other devices like that?

In this case (depth of 1 and bpp of N), I guess we should
handle mono flamebuffers which have something like "bit stride"
for each pixel, but

> Yes. Various HP framebuffers found in hp300 machines, like the CatsEye 
> - depth 6, bpp 8 ( or more? I'm not too sure... ). Tomcat uses depth 1 
> bpp 8 if I remember correctly.

Umm, in this case, actually topcat could have bpp of 8 but various
(from 1 to 8?) depth.

Maybe we should provide info about "the number of bits that are
actually significant" for FBs with bpp of 8 or less, right?
(I don't know if there are any FBs with bpp of 2 or 4, though)

Current rasops handles these N depth and 8bpp flamebuffers
by rasops8 and RI_FORCEMONO flag, but rasops2 and rasops4
are not implemented yet.

> > It may not be possible to drive certain types of display with the
> > usual code (as is the case with the PixelStamp, no direct FB access).
> > Rather than teaching the X server about each of the black sheep, why
> > not have a flag passed down by the kernel?
> This looks awfully like exposing a bunch of functions to userland and 
> let the driver decide which ones to accelerate by hardware... before we 
> know it we have half a GDI in the kernel. On the other hand - we 
> already do, there's just no abstraction layer to make it accessible 
> from outside.

I don't have any particular idea which type of info should be passed
from kernel to userland by the new WSDISPLAYIO_GINFO ioctl, but
I'll prepare one reserved member like "uint32_t flags" for now.

How about this one? (maybe some member names should be rethinked though)
---
struct wsdisplay_fbinfo {
	/* compat members with old structure */
	u_int height;	/* height of visible area in pixels (lines) */
	u_int width;	/* width of visible area in pixels */
	u_int depth;	/* bits per pixel */
	u_int cmsize;	/* color map size (entries) */

	/* extended members from here */
	u_int vramsize;	/* total VRAM size in bytes */
	u_int stride;	/* horizontal stride in bytes */
	u_int voff;	/* offset from the top of VRAM top to start of
			   visible area in bytes */
	u_int hoff;	/* offset from each stride to start of
			   visible area in horizontal pixels (or bytes) */
	off_t mmapoff;	/* offset to be passed to mmap() to map VRAM region */

	/* depth info for 2/4/8 bits per pexel displays */
	u_int bitnum;	/* number of bits actually significant in bpp */
	u_int bitpos;	/* which bit starts at */

	/* depth info for 15/16/24/32 bits per pexel displays */
	/* XXX should be u_char like struct raspos_info? */
	u_int rbitnum;	/* number of bits for red */
	u_int gbitnum;	/* number of bits for green */
	u_int bbitnum;	/* number of bits for blue */
	u_int rbitpos;	/* which bit red starts at */
	u_int gbitpos;	/* which bit green starts at */
	u_int bbitpos;	/* which bit blue starts at */

	uint32_t flags;	/* reserved; will be used to pass fb specific info */
};
---

We also have to decide which units (pixels or bytes) we should use
for hoff, but if we don't have FB drivers which require non-zero hoff,
we can change it later...
---
Izumi Tsutsui