viddev vs. rastop (LONG)

[Gil Kloepfer Jr.]

|>In article <138 at limbic.UUCP> I write:
|>>In article <2167 at rtech.UUCP> Dave writes:
|>>|>In article <4447 at killer.UUCP> loci at 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!" :-)
|>

In article <2180 at rtech.UUCP> daveb at llama.UUCP (Dave Brower) writes:
|>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.

This part is OK.  I probably agree with you (I know of the X window system,
not a lot about it .. and I know it IS the way to go)...  Read on...

|>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.

Problem right here.  You DO NOT understand the function of {w,s,ph}mgr.  These
are **NOT** the window drivers.  You can blow these away as I have and still
have windows.

The window DRIVER is "/dev/window" and the associated "/dev/w*" devices which
are the physical windows that /dev/window assigns on each open.  This is
very, very similar to (choke) VMS's WTAx: devices under VWS (VMS Workstation
Software).  wrastop uses /dev/window and the unix-pc window management
device functions -- so you probably want to scrap the driver altogether and
work with /dev/fb like you said.

When you migrate to X, you will want to probably dump /dev/window, but you
will lose the functionality of the rest of the UNIX-pc's canned software.
This may not bother you at all, but be prepared.  The only way you could
continue using it under X would be to simulate /dev/window by providing
kernel-level calls to X.

Also note that the window driver is a "required" driver (whatever this means),
and is also a permanent part of the UNIX-pc kernel.  This is a big problem...

|>The four problems porting X to the 7300 are:
|>	1.  Compiler (use gcc).

Oh, ok?!

|>	2.  Getting raw access to the display (use viddev or maybe a window)

See above.  Getting raw access to the display is fine, but part of X should
probably be done as a loadable device driver.  (yes or no?  I don't know).

|>	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.

No, it shouldn't.  The mouse is connected-in with the keyboard driver so you
would hack the keyboard driver to provide a /dev/mouse also.  Also note that
doing this would kill some more UNIX-pc canned-ware.

|>	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.

Sorry, I forgot my Berkeley sandals for this one.  I'll have to take your word
for it!

|>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.
                        ^^^^
This is what I was refering to before.  wmgr only handles program function
keys that let you bounce around from window to window.  More accurately would
be that you would like to trash /dev/window.

|>With X, the 7300 would be an absolutely bang-up personal workstation.

Probably.  I, personally, would trash tam and /dev/window and rewrite the
whold damn thing -- make all the current UNIX-pc software work under X.
Problem is getting the source to unix for this machine so I could make the
transition a bit easier for those with applications written under the old
system.

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

Dave -- this isn't a personal attack (BTW) at all...  I agree with you
wholeheartedly.  But it isn't the *mgr programs only that you are doing away
with -- its the device driver that does the windows -- which really isn't
married to those programs at all.  And my good luck was to try to get around
the current window driver.  That will be something that will make you climb
the walls!  Let me know how it all works out if you decide to take this on!

+------------------------------------+----------------------------------------+
| Gil Kloepfer, Jr.                  | Net-Address:                           |
| ICUS Software Systems              | {boulder,talcott}!icus!limbic!gil      |
| P.O. Box 1                         | Voice-net: (516) 968-6860              |
| Islip Terrace, New York  11752     | Othernet: gil at limbic.UUCP              |
+------------------------------------+----------------------------------------+