Hiya Ben,

On Fri, Sep 13, 2002 at 11:50:15AM +0100, Ben Harris wrote:
> >> >  > Proposal for the implementation of a /dev/fb device under all NetBSD
> >> >
> >> > We already have such a thing -- it's called wscons.
> >> >
> >>does wscons support graphic modes and raw access to screen bitmap?
> >
> >When feasible, yes.  Of course if you read the wscons and/or wsdisplay
> >man pages you could have discovered that for yourself.
> 
> On the other hand, there are a _lot_ of holes in wscons.  For instance,
> there's no way to change screen mode, work out what screen modes are
> possible, query the cursor format, query the pixel format (for DirectColor
> and TrueColor displays), use DDC, use DPMS, install multiple cursors (to
> allow more rapid switching) or, I suspect, several other useful things.
> 
> Of course, all of these can be fixed, but stealing ideas from Linux's fbdev
> (where they'll have some idea of what doesn't work) mightn't be a bad idea.

Well that was my idea yes :) You sure could rename `/dev/fb' in my proposal
to `/dev/wsdisplay' but thats a non issue. The point i am trying to make is
that some arch's like i386 and alpha dont even have a wsdisplay device....  
graphics is only available trough X trough lots of jumbo-mumbo hacking in 
the X server to get the display and to try to program the chip itself.

One of the big benefits of splitting out the `fb' side from the `wsdisplay'
side is the splitting up of wscons as a sole `framebuffer' user
inderpendent of what arch and the `fb' as a MD driver for the graphics. It
doesnt need to be that difficult and sure one of the easiest ways would to
provide a near static one or one with just static entries known to work OK.

Lots of reverse engineering can be avoided by reading the Linux drivers and 
the X server code.

Cheers,
Reinoud