Greg Haerr writes:
>
> On Tuesday, May 11, 1999 12:56 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
> > Eric J. Korpela writes:
> > >
> > >
> > > > o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes.
> > > >NanoX now runs on DOS! (OK, I did this only to see how portable nanoX
> > > >is, and the
> > > >mouse driver still isn't written) This still uses MSC graphics library.
> > > >I'll have the bios
> > > >int10 version driver done shortly, which will allow nanoX to run on
> > > >ELKS! We should
> > > >have an ELKS version shortly... BTW, the nanoX kernel is around 20k on DOS...
> > >
> > > Does anyone else agree with me that direct int 10 access is a mistake?
> > > Wouldn't access through a device driver be a bit more unixy? It would
> > > be able to prevent multiple processes from trying to access int 10 services.
> > >
> >
> > We could add another ioctl to the dircon driver that calls int 10 for us.
> > This would add minimal code to the kernel (no extra driver), and providing
> > everything can be done thorugh int 10 it would keep the user space code
> > hardware clean.
>
> I think that's a good idea to potentially solve the lock problem,
> but of course lock code would have to be executed. At this point, it's going
> to be *way* too slow for all the graphics primitives to go thru a kernel mode
> transition, however. With graphics, we want speed... Even on older systems!
>
> Overall, I don't think its a good idea to bring graphics stuff into the ELKS kernel,
>yet.
> Especially since the plan is there'll be only one graphics server running per
> ELKS system, ever.
>
Okay, we can rely on the ioctl made to initially request graphics access to
lock the graphics hardware, and keep the actual hardware access in user space.
Al
