At 1:56 PM -0500 12/4/99, Jason Thorpe wrote:
>On Sat, 4 Dec 1999 02:47:04 -0500
>You are obviously ill-informed about what wscons is, then.  wscons also
>provides the same graphics ioctls (cursor, colormap, etc.) and frame
>buffer mapping primitives that e.g. Sun's "fb" interface did (wscons is
>derived from it).

Well, wscons has changed a bit since I last saw it. However, while it
provides the cursor and colormap ioctls, this isn't where my greatest
concerns lie. All of the previous frame buffer devices NetBSD had could do
these sorts of things. What I don't see are mechanisms to adress problems
like screen size, refresh rate, interlace, h/v sync lines, how pixels are
written/read and organized (i.e. chunky or bitplanes?), memory
organization, etc. There doesn't seem to be much in the current wscons API
that addresses this (I could be wrong! If so please show me where I can
find that stuff).

I'm not given 100% to the linux fb model. I only find it convenient. If
NetBSD wants to use wscons, then I'll port my code to that API. It doesn't
matter that much to me.

>Also, there are at least a couple of people working on a command packet-based
>graphics acceleration interface for wscons.

This is neither the time nor the place for a command-packet syscall vs.
user-space acceleration flamewar :-)



____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________