Path: utzoo!utgpu!water!watmath!uunet!lll-winken!lll-tis!pacbell!rtech!llama!daveb
From: daveb@llama.rtech.UUCP (Dave Brower)
Newsgroups: unix-pc.general
Subject: Re: viddev vs. rastop
Keywords: what are advantages?  Think X.
Message-ID: <2180@rtech.UUCP>
Date: 17 Jun 88 03:52:51 GMT
References: <4447@killer.UUCP> <2167@rtech.UUCP> <138@limbic.UUCP>
Sender: news@rtech.UUCP
Reply-To: daveb@llama.UUCP (Dave Brower)
Organization: Relational Technology, Inc. Alameda, CA
Lines: 45

In article <138@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes:
>In article <2167@rtech.UUCP> I write:
>|>In article <4447@killer.UUCP> loci@killer.UUCP (loci!clb) writes:
>|>>	300 frames per second. That seems pretty fast to me, so I'm
>|>>	wondering why rastop's wouldn't be prefered.
>|>
>|>Rastops only work inside a window.  If you want to write elsewhere on
>|>the  screen, you are in trouble.  Say, for example, you wanted a
>|>different window manager...
>
>This has nothing to do with window management.  If you want a new window
>manager, all you have to do is kill the current one and write your own.  You
>open a window icon in the corner of the display (a separate window), and you
>can do just what the current window manager does now (see the window driver
>manual pages).  I think what you mean is to write a new window DRIVER.  To
>that, I say, "Good luck!" :-)

Bzzt, disagreement on design philosophy ahead.  It's not at all clear
that a driver is the right way to do windows at all. If someone is ever
going to port X windows to the 3b1, it is NOT going to be on top of the
existing window drivers.  It is much more likely to be on top of /dev/fb
{framebuffer}, which is exactly what this driver provides.  If I'm
providing a whole new window system, I am not going to layer on top of
the existing brain damaged one, I'll want to get at the actual display
hardware.   The only question would be whether using one whole screen
window, and replacing {w,s,ph}mgr with an X server using wrastop would
be faster than having X use /dev/fb.

The four problems porting X to the 7300 are:

	1.  Compiler (use gcc).
	2.  Getting raw access to the display (use viddev or maybe a window)
	3.  Getting at the mouce the right way.  May need to hack a driver
	    to get at the raw mouse data.  This should not be too hard.
	4.  No select on non-existant sockets.  You can emulate sockets with
	    named pipes, though it will be ugly.  Faking a select is harder,
	    and it may be necessary to write a driver that fakes it.  This
	    is hard.

Why X instead of wmgr?  Because there are actually people writing new
applications that are effectively in the PD using X.  No one is writing
anything to run under wmgr.  With X, the 7300 would be an absolutely
bang-up personal workstation.

-dB
{amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!