I would suggest providing compatibility with stuff that's on other
platforms. That way you can get stuff like GGI or similar (svgalib) ported
relatively quickly. Done well, that would allow some Linux games to work in
Linux compatibility mode.

Saying that, if XFree86's broke, fix it. FreeBSD has a preliminary port of
DRI, against which most games that I'm aware of are being ported to (Loki is
busy making this work).

The problem is that the typical Unix mindset is dead against including stuff
in the kernel that traditionally hasn't been there. Therefore, a graphics
engine of some description (ggi, svgalib, even X) would be the same as
Windows NT 4.0 & 2000's inclusion of GDI in win32k.sys, but without the even
basic protection of NT's threading model (GDI in NT typically runs as the
user who is logged on; on Win2K, it runs as the user who owns the main frame
(first window, basically), and if you're printing, GDI runs as the user who
invoked the spooler - all with distinct address maps and threading/process
contexts*. As far as I am aware (and feel free to instruct me gently with
the clue stick), in Unix once you cross into the kernel, you are the
kernel).

Andrew

* very clever malicious code could change thread context and address maps.
Once in Ring 0, there's nothing to stop privileged instructions from
occuring. But in general, even in ring 0, limited protection is better than
a poke in the eye.

-----Original Message-----
From: tech-kern-owner@netbsd.org [mailto:tech-kern-owner@netbsd.org]On
Behalf Of Kevin P. Neal
Sent: Friday, 17 November 2000 11:57
To: Andrew Gillham
Cc: tech-kern@netbsd.org
Subject: Re: Any plans for wscons/rcons graphics library?


On Thu, Nov 16, 2000 at 02:46:53PM -0500, Andrew Gillham wrote:
> Hello,
>
> I was wondering if anyone is thinking about adding lowlevel graphics
> routines
> to wscons/rcons and perhaps a userland library?

Yes, FWIW.

Actually, what I want is the machine- and card-specific parts of the
X server in the kernel. That's a bit more ambitious perhaps. It seems
broken to me that we have a program (the X server) running as a user
that pokes the hardware almost directly. What happens when you switch
virtual consoles? An ugly exchange happens where the X server is
asked to give up the screen and so it does. This system breaks when
the machine is busy (the timeouts, uh, timeout). It also tends to be
fragile if multiple X servers are run (I tried it). Moving the hardware
manipulation-code into the kernel would solve these problems.

Moving the MD parts into the kernel would also have the side benefit
of allowing us to have a single X server for all platforms (cpus,
graphics chips, etc).

The problems that were pointed out to me include:
1) Doing a system call every time you want to draw a line or set a
   pixel or whatever would be very very slow.
2) It would be very hard to come up with an API that is general enough to
   not require special casing in applications but at the same time would
   allow for the use of special features of some video cards.

Last but not least...

3) That's nice. Where's the implementation? Who's going to maintain it?
   The Xfree86 people work on their system, who would maintain the
   NetBSD parts?

*sigh* Not me. *hangs head*


Ok, what you propose isn't quite so ambitious, but you would still have
to deal with the above issues.

> I would like to see wscons provide a generic API that works across all
> platforms
> that use wscons so a single driver can be implemented in MicroWindows.

I'd like to see wscons support the same base features on every system.
Do we have virtual consoles in wscons yet for graphics consoles?
Do we have the ability to do 132x43 text displays yet on those VGA
cards that support it? I don't think we can have text virtual
consoles if the hardware doesn't support it (hercules ISA cards).

Then again, I don't have the time to do the work myself, so I'm not
complaining. (Really.)

> At that
> point other programs could use the same interface.
> I could imagine a number of programs working directly on wscons:
> 	MicroWindows / Nano-X
> 	Qt/Embedded
> 	vncviewer
> 	mgl

It would be nifty, I admit.

> Considering that wscons provides wskbd, wsmouse, and wsdisplay (text),
> it seems
> reasonable to add basic framebuffer/graphics routines to it  as well.

Seems reasonable, yes.

> Does any of this sound reasonable?  Or should this be strictly in
> userland?

I'm of the opinion that userland program should never manipulate
the hardware directly, and they should never be able to get the
hardware into a state where the console is not usable.

"But..."
--
XCOMM Kevin P. Neal                  http://www.pobox.com/~kpn/
XCOMM
XCOMM "What is your fascination with Gunsmith Cats?" - me
XCOMM "They blow stuff up." - Ravi K. Swamy.   January 6, 1997