On Wed, 16 Apr 1997 12:25:45 -0700 (PDT),
wrstuden@loki.stanford.edu (Bill Studenmund) wrote:
> 
> Right now, there's some fuss on tech-kern about making some sort of
> generic mouse support, and an Xnetbsd server which would work on
> many ports. It's a long way off, but as part of those changes, I
> think that some sort of PCVT support (which lets i386 folks have multiple,
> hot-swappable screens w/ X) will go into the kernel. We might be able to
> pick things up at that point too.

I always thought it should have been considered a bug that all m68k
couldn't share a single X servre binary ;-)

> 
> Q: what does the X driver really do with the grfX device? Does it do
> anything more than mmap the screen into its address space and (eventually)
> fire off ioctl's to change the screen mode?

Scott's server (the official unofficial one) probably doesn't do
ioctl() at all.  Mine does that since it has knowledge of Taras' grf
driver API, or else it couldn't do the color.

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

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?)

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.

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

Cheers,

Ken