> 
> On Wed, 16 Apr 1997 12:25:45 -0700 (PDT),
> wrstuden@loki.stanford.edu (Bill Studenmund) wrote:
> 
> > If the above's all, could we do something where dt fires up, and will
> > (optionally) create/open a padb0/adbs0 and pgrf0/grfs0 pair of pseudo
> > tty's. The only difference between these things and normal pty's would
> > be that specialized ioctl's get forwarded too. We then let X fire up
> > on these two devices.
> 
> Um, so which of the real devices and the pseudo devices should X
> server try to open when dt isn't running.... Oh, I get it.  X tries to
> open the real ones (adbX + grfX) first then to open the pseudo ones
> (adbsX + grfsX) when failed to open the real ones, right?  It sounds
> good to me, but I'm not sure how this can expand to MI (or m68k
> generic) paradigm.

Well, for this to go M.I., all the ports have to agree on mouse, keyboard,
and graphics IOCTL's. Until then, nothing's up.

> And I'm intentionally leaving out the discussion on the implementation
> of such pseudo devices which would allow direct mmap() of the real
> device's frame buffer... (this means pgrfs/grfs device pair isn't
> exactly like pty/tty pair since pgrfs/grfs driver has access to the
> real grf device.  How do we arbitrate simultaneous accesses to grf and
> grfs?)

However pcvt does it. :-)

> Ok, now that I think of it, it seems to me that use of a binary
> semaphore would be simpler in concept and easier to implement.
> 
> Scenario: Both dt and X server know they have to grab a semaphore S
> (shared between the two, of course) before grabbing adb and grf
> devices.  When the one which currently has access to the devices (i.e.
> owns S) thinks it should let the other guy run, it saves the device
> state, and releases the devices and then S.  It waits on the same S
> after releasing it, so if there was someone waiting on S, it'll wait
> 'til the other guy releases S.  If there isn't, it'll immediately get
> S back and start running again.

I'm basically thinking about hacking pcvt'ish functionality into our
X server. In pcvt, you have a ttyvX, one per virtual screen. You just
fire XFree86 up on one of those, and away you go. My pgrf/padb stuff was
a thought at a quick-and-dirty way of adding this ability.

One disadvantage of a semaphore is that when you hit a screen-switch
sequence, you want a particular screen. Thus with a semaphore, X and dt
both must know which screen(s) are theirs and the other's. My idea was
to just have dt know, and only feed to X what it needed.

> Well, though I think it should work with more than two such apps, I
> have to admit I'm not sure how this expands to MI, either.  Especially
> when virtual terminal is implemented in the kernel (e.g. i386).

This idea doesn't scale to M.I. The adb system would have to be kept
local, away from M.I. programs (as they expect mice and keyboards
seperate, and using different protocols).

Take care,

Bill