Index:
[thread]
[date]
[subject]
[author]
From: Jon M. Taylor <taylorj@ecs.csus.edu>
To : Emmanuel Marty <core@suntech.fr>
Date: Mon, 6 Jul 1998 13:39:12 -0700 (PDT)
Re: Last kgicon update before it goes in CVS
On Mon, 6 Jul 1998, Emmanuel Marty wrote:
Hm. This post didn't have a Reply-To: for some reason.
> Jon M. Taylor wrote:
>
> > Very well, degas/kgicon and degas/kgicon-include it is, unless
> > anyone has objections and I hear from them before tomorrow evening. I
> > guess it really doesn't matter what the directories are called - the stuff
> > is going to be isolated from the rest of degas as far as makefiles and
> > installation goes anyway. We can always rearrange things later when the
> > separation of EvStack and KGI in Degas is completed.
>
> No objection from me as to adding that to the repository; we needed to
> agree on something so that driver writers wouldn't spill efforts adapting
> them for 15 different APIs.
Huh? They would always write them for the KGI API. The bridge
layer is what connects the KGI API to another API, like fbcon. Maybe I
misunderstood you.
> About the include dir, can it be folded under
> kgicon or is it really a seperate entity? :)
Well, the logical place for it would be degas/include/kgi, but I
don't want to overwrite the existing KGI includes and possibly break
EvStack or the LibGGI KGI target. So I thought to keep them separate for
now. We do need to work out a good long-term solution in the near future,
however.
> I suppose that the whole set of drivers under kgicon/ and the wrapper
> itself, can be slightly modified when Steffen releases his new KGI
> specification; it's not like your changes are real work for driver
> programmers anyway, it's just some good sanity cleanup and
> renaming.
Yes. I imamgine that there will be quite some reorganization of
the whole tree when that happens anyway. In the meantime people will
have to manually copy the directories into the linux/ tree anyway, so one
directory renaming won't matter.
> > > > * Make sure that drivers work properly on non-x86 architectures.
> > >
> > > That's not going to be evident :)
> >
> > It may take quite a bit of work in some cases (Amiga S3-based
> > boards) and be quite painless in others (like the Open Firmware Mac PPC
> > drivers). Luckily that isn't my problem as I only have x86 |->.
>
> Yes, Geert mentioned that some Amiga display cards don't even provide
> direct access to the framebuffer. Those don't go through fbcon at all at
> the moment but use a special set of framebuffer ops, we'll have to fold
> them in sometime.. :)
Also, Amigas and Ataris don't have PCI, so at some point the card
detection routines (which are currently hardwired to detect either by ISA
I/O or PCI) will probably need to be broken out into separate modules,
just as the I/O port programming is now. Otherwise we will end up with a
hideous unreadable mess of #ifdefs like the XFree86 drivers have |-<.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Index:
[thread]
[date]
[subject]
[author]