Index:
[thread]
[date]
[subject]
[author]
From: Salvador Eduardo Tropea (SET) <salvador@inti.gov.ar>
To : James A Simmons , ggi-develop@eskimo.com
Date: Fri, 10 Jul 1998 12:28:22 +0000
Re: Out of the chaos
James A Simmons <jsimmons@acsu.buffalo.edu> wrote:
> IV. KGI.
>
> YAH HO !!!!. Its going into the kernel. We won the battle with the
> kernel guys now to win the war with the companies. I love the idea of a
> kgi core that is OS indepenent. All you need to do is link a wrapper for a
> particular OS. We need to remove pcibios_dword etc from KGI's core. This
> is linux specific. I like to thank the companies that are helping us out.
> Unfortunely their are alot of companies that are not like this. Please
> don't send me hate mail about this but we need to write windows 95, 98 and
> NT wrappers for kgi.
Avoid using these words directly, they have a big "negative power",
use Winblows or similars ;-)))
> If companies are every going to consider to use what
> we are doing we have to convert their current drivers to kgi. Unfortunely
> most companies make only windows drivers. Writing a driver for windows is
> essential like a module so for companies that don't want to give out their
> source could develope a kgicore.o and link to to various OS wrappers.
> Also this shouldn't conflict with the license. Correct me if I am wrong.
> We would also need wrappers for macOS. Alot of companies support these
> guys even though their are alot more linux users than macOS. Figure that
> one out. Then for linux drivers we could download the kgicore.o and link
> it with the fb-kgi.c wrapper and wha la or if the companies are nice they
> could ship the linux drivers. Some points to make about KGI:
>
> one:
> kgicore.o will be OS indepenent,
What do you mean with a .o OS independent? I don't understand it.
Isn't .o files object files? Then: how do you plan to link the same
.o with a Win32 linker and with ld? The companies must supply more
than one ... that's too much for the lazy people. I think plain
binaries are more suitable for that ... and that's make me remmember
the VBE/AF drivers (relocatable binaries).
> based only on the cards hardware
> right. Now take this from the companies perspective. Say I am a
> company that makes high end expensive graphics cards that can do
> amazing things. This is where my marketing is. Now I look at these
> kgi drivers and say. Their niece but I can't use the advance
> features of my card. Why should I use teh kgi driver if teh kgi
> driver makes my $500 card use the same features as a cheap $50
> card. Point is we need to add all the advance features of a card
> into kgi.
Hmmm ... I agree in some points but: To make a driver specification
for advanced features you must know a lot about these advanced
features and they are normally "secrets" the companies doesn't want
to release. I know about only two that can do such a thing: Micro$oft
(ugh!) and VESA. The first because the companies know that the market
is there, the second because they are the companies. I think you'll
never have a general specification without the help of the
company leaders (read without the help of the people that makes
Voodoo chips, etc) or not at least just-in-time. You'll be 1 or 2
steps behind and then will be very difficult to atract companies.
Just an opinion, not much.
> Make a OS indepenent interface to these features and let
> the OS wrapper take care of turing that OS indepenent feature into
> a OS API.
Yes.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft@usa.net set@computer.org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
Index:
[thread]
[date]
[subject]
[author]