> > I tend to agree with the people who said a while back on this list that 
> > it's better to keep dt out of the kernel so maybe this could be handled 
> > by dt and require no system intervention. But then again I dont anything 
> > about dt internals.
> 
> I'm not sure how easy it would be.  At least under the current model, both
> dt and X like to grab /dev/grf0 and /dev/adb and hold them open, not
> letting anything else use them.  So, we'd probably have to change the
> semantics of these two devices if nothing else.

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.

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?

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.

The Xserver would attempt to mmap in the screen, and would be able to
access it when dt let it (I'm not sure how to do this, but pcvt does
the same thing now). All the adb stuff would go into dt, and then get
forwarded to X if X is up. All the graphics ioctl's would go from X
to dt, and then to the kernel (if the X screen is up).

The advantage of this approach is that we keep the kernel stuff minimal.
If pty's will forward unknown ioctl's to the controller, then we don't
need to change code. One disadvantage would be speed as all key clicks
have to go though dt. I'm not sure how slow that would be as the relevant
parts of dt would always be in memory. :-) As the graphics is done via
the mmap'd screen, the drawing won't be hideously slow.

Thoughts?

Take care,

Bill