>
> The above has been one of the major problems with GGI from the very
> beginning. Instead of taking something that WORKS (like X11) and fixing a
> few small nagging problems, you now try to advocate a completely new
> subsystem.
Well, we could use some kind of abstraction layer between graphics
hardware an graphics programs. There is an abstraction layer between
almost any other piece of hardware in the system. It only should provide
an unified way of talking to the hardware to do the mode-changes and
maybe on a higher/intermediate library level could provide a way of
adding acceleration. This on the other hand should have no influence on
any other subsystem that we have at the moment. There is no reason for a
video abstraction layer to know about the keyboard abstraction layer
and...
The problem is that at the moment the GGI-project is in its infancy.
They haven't produced any code that anyone on this list not involved in
the project has had any success in testing. Well nobody who did
sucessfully test it spoke up. I looked at the available patches (running
2.0.88, not convinced that I'm ready for kmod) and I don't know what to
use, because the documentation is unclear.
I really am in favour of waiting for the GGI-project to produce the code
and prove their point by your and my standard (working, documented code
that really does the thing it's supposed to do).
On the other hand someone on the GGI project should stand up and clarify
the goals now. He/she should do this in a way every kernel guru (or at
least a majority of them) can understand and see why there should be a
change in the current 99.9% working code should be made. Especially
there should be clarification why/how the different parts of the whole
issue (GGI/KGI/EvSTack/libggi) interact. Without this clarification
nothing worth including in the kernel can be produced because none of
the majority of really good programmers who are working on kernel code
could adjust/adopt tho the maybe rightfully needed changes.
Too much uneducated guessing has been going on during the current
discussions that I am really getting annoyed by the thread. Even now I
feel that I don't understand the whole issue because I am not fully
informed.
>
> That is just STUPID. Let us review history a bit, and think about the
> saying "If I have seen further, it has been by standing on the shoulders
> of giants".
>
> Think about it for a few minutes. Really.
>
> THINK, DAMMIT! What the hell is the point of throwing away something that
> works 99.9% of the time for the extremely lame excuse that it fails 0.1%
> of the time? Instead, the GGI debate has always been how everything must
> be rewritten to use new and completely untested interfaces that currently
> work 0% of the time, as it if is easier to fix that..
>
> Yes, I'm frustrated about the whole discussion, because EVERY SINGLE
> TECHNICAL ARGUMENT that I've ever heard for GGI has been so fundamentally
> broken. GGI is throwing out the baby with the bathwater, and never even
> noticing.
Without playing the devils advocate: there might be one point missing
from this. There are things that the X-Server can't handle at the
moment, being an (priviledged) userland program. One such thing are the
interupts that some current chipsets (for example: Riva 128) generate
and which have to be handled to gain more than basic acceleration or
keep them from even locking up. There should be a driver for this inside
the kernel to provide for this (in my opinion). There should be a driver
for the different video cards available in the kernel to enhance overall
abstraction and safety.
There is no need for a rewrite in most aspects, although I think you
agree that having an optional kernel graphics interface (KGI) that could
be employed and with time and stability could even end up in the
mainstream kernel isn't a bad thing at all.
To the GGI-people out there I have to say that you should think more
before speaking. There has been too much senseless talking and flaming
going on. If someone volounteers to help you to support more hardware
you don't turn him away just because you don't like his hardware
(especially if your arguments are more than weak: go away your hardware
is crappy). We all have our limits and there are lot's of people that
don't have the resources to simply switch their hardware. That's one of
the great points of Linux: you either get support for your hardware or
you can do it yourself, if you feel to be up to it. No linux developer
should be that arrogant to turn down help in the way it seems to have
happened (see the other very lengthy GGI-thread going on).
As with the argument of XAA being around, why doesn't anyone look at
what it takes to make XAA (an acceleration abstraction used by the
current XFree86-Servers) even better by making it available as a user
level library on top of something like KGI.
For that matter: wouldn't it make sense to talk to the people at XFree
about integration of their userland drivers (or parts thereof) into KGI?
Why reinvent the wheel? The (privileged) userland drivers of XFree
aren't that bad. They only suffer on some broken/maldesigned hardware
and could gain by being inside the kernel and thereby having more
knowledge what is going on on this level.
To add my DM .02 to the discussion:
- GGI people: speak up and clarify (instead of mystifying) and IMPLEMENT
something the average bleeding edge Linux user can test. Don't, and I
really mean it, don't mix different abstraction layers. Don't talk
religion
and try to change everything, just because you think it's bad. First
try to
fix it, because for most people the current setup is WORKING!
Concentrate on
one of the projects or even better: split it up between different
projects:
- KGI
- libggi
- EvStack (whatever this may be)
and clearly keep them cleanly apart. I wouldn't like Linux to end up
like Win95/98 where every subsystem is so mixed up with another that
I can't print correctly
unless I have the right video diver installed.
- Linus: stay openminded and give them a chance to continue. Their
project may make
life easier in the long term (not next week, but if hardware designs
keep changing
with the same pace as they are doing right now, we might need it). If
it means
fixing things, this should be done (your suggestion). If their project
means
redesigning vital portions of Linux, thereby violating design
foundations of the
system itself, I'm right there with you: NO WAY!
Karl Günter Wünsch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu