> Date: Wed, 5 Jun 1996 21:38:35 -0700 (PDT)
> From: "Jon M. Taylor" <taylorj@gaia.ecs.csus.edu>
>
> First, it is GGI, not CGI. Second, why must this be set in
> stone? If things can change as much as they have in the /proc
> filesystem, a precedent is there for this sort of thing. Besides, there
> are undoubtedly ways of either ensuring complete backwards compatibility
> (i.e., IOCTLs only get added, never removed or modified) or implementing
> some srt of versioning scheme to ensure that older apps always use the
> IOCTL set they were compiled to use. I'm sure that there are other
> solutions as well.
>
> True, you can always add new ioctl's. However, this exposes the fallacy
> that says that GGI will avoid the requirement of new X servers to
> support new fancy accelerated boards. If each new accelerated board
> that has some new accleration feature will require new ioctl()'s, then
> we will need to compile a new X server to take advantage of the
> (constantly changing) GGI API. Otherwise, the old GGI X server, since
> it didn't have the old API calls, won't be able to take advantage of the
> new accelerated functions.
This is true, but there's really no way around it. One way to
mitigate the problem would be to have a layer of library code in between
the X server and the GGI, which would handle all the translation of X
graphics primitive calls into GGI ioctls (OK, I'll use lowercase |->).
This would still need to be updated in the event of an expansion of the
GGI primitive set, but the bulk of the X server code could remain
unchanged. Xlib would probably be this layer, actually.
There are probably going to be very few apps that talk to the GGI
directly - I'd imagine that some sort of library layer will almost always
be used, for the reason that you'd have to put the same sort of
functionality into the program anyway if you wanted to do anything other
than bang away at the raw framebuffer or use whatever ioctls happened to
be present.
Also, it isn't like there's gonna be a new ioctl every other week
or something, especially if we implement a fairly complete set to start
with. Work has already begin on a 'standard' userspace library, and
hopefully it will end up being comprehensive enough that significant
performance losses due to unsupported accelerations won't be a problem.
Especially if I have anything to do with it - I want to write GGI drivers
for all those new gamecards that are coming out.
> > Finally, please remember that in the grand scheme of things GCI will
> > double the amount of work required; when a vendor releases a new card,
> > someone will have to write a GCI Linux kernel module, and XFree86 will
> > have to put support into their servers directly. After all, remeber
> > that XFree86 runs on a large number of OS's, not just Linux, and so
> > regardless of what we do, XFree86 will still have to do all of this
> > work.
>
> Since both codebases are free, why duplicate the work? Either
> they develop it first and we use their code, or the reverse.
>
> You're right that it won't be exactly double, however, there will be
> some amount of new work required, if nothing else to confirm to the
> differing interfaces between the internals of the XFree6 server and the
> GGI API.
There's no way this can be reduced to zero, but I think that it
can be made trivial enough so as not to be a problem.
> I don't doubt that there are advantages in putting parts of the video
> board management inside the kernel. However, there are costs in doing
> so, and people should neither try to trivialize the cost nor
> overemphasize the benefit.
I'm not saying that the GGI will be the holy grail of graphics
programming or anything like that, but I honestly think that I will be a
great improvement.
Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj>
------------------------------------------------------------------------------
"Everything in excess! To enjoy the flavor of life, take big bites.
Moderation is for monks." - Lazarus Long