Hi,

> - depth in bits

The X server calls this bits per pixel if I remember correctly, and depth is
the number of bits that are actually significant. I would be good to have
the two.

> - stride in bytes

Also the offset to the visible area of the frame buffer, and the total
height of the framebuffer (non-visible portion included) would be nice to
have.

> and more?

- a flag to indicate whether the frame buffer is simple and can be handled
  by mfb/cfb or is something a bit different, like a VGA or PixelStamp?

- a flag to indicate whether or not colormap changes are accepted? Not
  entirely necessary, but nice to have.

> Some wscons drivers already have {copy,erase}{cols,rows}()
> functions for wscons/rasopos with hardware support, so
> I just guess they could be easily used with the same API by dumb wsfb.

Would that really provide a lot of benefit? It would be complicated to hand
commands to the board to execute while you are off dealing with clipping or
whatnot. You would also have system call overhead, and miss out on other
stuff that it's worthwhile accelerating. I could see a benefit if there were
likely to be significant users of the interface other than the X server, but
I don't know of any.

For accelerated devices it wouldn't be difficult to have other modules that
use the majority of the wsfb code and then just install their own ChangeGC()
and other functions. I'm not sure what the best way to split it would be
(table driven or some arrangement of loadable modules).

Andrew