On Tuesday, May 11, 1999 12:19 PM, Luke (boo) Farrar
[SMTP:[EMAIL PROTECTED]] wrote:
>
>
>
> On Tue, 11 May 1999, Eric J. Korpela wrote:
>
> >
> > > 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.
> >
> > Eric
> >
> >
> >
> What are the major bonuses of Int10 over the device driver? (If any).
> Luke(Boo) Farrar.
The issue isn't really int10 over device driver, it's user mode vs kernel mode,
or OS vs application.
The framebuffer device driver idea for linux is a good one because it provides
an abstraction that allows user programs (applications) to not concern themselves
with the underlying graphics hardware architecture, and write a single binary
that runs on all linux systems (> v2.2, of course).
This would also be good for ELKS, except that at this point the
entire project is pre-strawman, and, not everybody is interested in a bigger ELKS
that has graphics stuff linked in.
With a later architecture and loadable kernel modules, code that
is currently written as nanogui drivers could be moved into the ELKS kernel, and
a single nanoX binary could be produced that would run on all ELKS systems.
In the pre-v1.0 nanoX design, we'll have to build nanoX engines that have linked-in
or dynamically-linked device drivers that run in user mode.
Finally, I am writing an int10 driver first, so that all you guys can play
with nanoX on your systems without having to write specialized hardware drivers.
This is purely to get it running quickly, to get more people interested in the project.
Afterwards, people can write native graphics drivers for specific cards if they want.
Greg
>
>
>
