Subject: Re: RFC: framebuffer device support in NetBSD
To: Ben Harris <firstname.lastname@example.org>
From: Reinoud Zandijk <email@example.com>
Date: 09/13/2002 15:07:29
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.