"Jon M. Taylor" wrote:
> On Fri, 24 Nov 2000, Antonio Campos wrote:
>
> > I've reading the superb interesting thread about KGI/GGI and the need
> > for a great change in the console (graphics console?) layer of the Linux
> > kernel to improve the graphical situation of the OS.
> > It looks like Linus Torvalds is the/a big obstacle in the progress of
> > the Linux Graphical Subsystem.
>
> Obstacles:
>
> * Linus (he doesn't like kernel graphics too much)
> * Linus' adherents (they agree with whatever he says)
>
I'm beginning to think that many people today are not afraid of facing Linus
ideas in a lot of aspects of the Kernel.
The question is: has anybody the power to convince Linus of the advantages of
a new graphics model? Has anybody sent any documentation or schema to the
Linux kernel lists/X or DRI teams explaining the way KGI works and why is it
better?
> * DRI people (Competing architecture)
> * XFree86 people (Competing architecture)
See above...
>
> * Inertia (Why change if the current system "works"?)
Because it works badly. Linux is NEVER going to succeed in the desktop arena
with the actual combinations of X+DGA+DRI.
The new MAC OS X can be a tremendously serious competitor for Linux/BSD,
etc... It can very probably take a lot of the Linux terrain if nothing is
done in respect to the graphics subsystem (and the sound subsystem, by the
way). Even the cumbersome DirectDraw/Direct3D of Windows platforms is now a
much better option in graphics than Linux is.
Although all of this is known by many people (the GGI list, X list, and even
kernel lists), believe me when I say that many more people believes X to be a
marvellous graphics subsystem and doesn't need improvement. And this is what
has to change. That's why I suggested the idea of promoting KGI in
publications like Linux Journal and the like. Just think: why did Linux
kernel triumphed over Mach or FreeBSD? Among other things because it created
an halo of being a rock-solid fast unix-like kernel. Much of this
triumphalism is due to the promotion of Linux in academic environments.
Why many good projects fail to connect with the people?. In my opinion, by a
lack of promotion.
An example (yes, I know I'm repetitive): I have a lot of friends that know
about and even use Linux, but neither of them know about the
GGI/KGI projects. But they all know about X, Gnome, etc. So, I consider this
to be a lack of promotion.
> * Developmental difficulties (It's _hard_ to do it right)
>
Sure? Itsn't easier to develop a X-like server over KGI once KGI is done?.
>
> > First of all (don't get me wrong), we all must give credit to Linus from
> > creating/initiating this wonderful operating system.
>
> Sure.
>
> > But, on the other
> > hand, Linux users can't stop from improving just because him (or
> > others?) think that the things are OK now.
>
> They don't, by all accounts. Linus' dislike for the fbcon/fbdev
> system is well-known. He doesn't mind DRI so much, probably because its
> maintenance is sponsored by a commerercial entity (VA Linux) which fixes
> bugs that pop up and enhances the API when needed. Now that James Simmons
> is being sponsored by SuSE Linux to fix up the console layer, things have
> gotten a lot better in that department recently. More improvements are on
> tap for 2.5.
So, we all should buy beer every month to keep Simmons happy. (And the same
goes to the GGI team too). ;-)
>
>
> Linus doesn't like complex (and thus race- and deadlock-prone)
> subsystems which have to deal with a lot of interrupts, critical sections
> and locks in the kernel. One big impediment to releasing 2.4 has been the
> debugging of the rawio and OOM killer subsystems. DRI stays out of the
> way of the scheduler, doesn't take kernel locks very often and its bugs
> get fixed. It might almost be easier to prove KGI out "in the field"
> using FreeBSD as the primary OS platform.
>
> > Admittedly, Linus isn't a
> > brainless person, but he isn't God,
>
> No, he's made his share of mistakes (other than KGI) over the
> years. But I doubt many other people could have done as well. _Most_ of
> his judgement calls are fairly on-target. He just has biases which cloud
> his reasoning in certain areas.
>
> > and many people (including me), see
> > the need for a crude improvement in the graphics subsystem if Linux is
> > going to have any success in the desktop arena sometime.
>
> Well, it is already quite sucessful, about as popular on the
> desktop as Macs are actually. And gaming, while confined to ports of the
> more successful Windows games and free stuff like Tuxracer or Angband, is
> growing rapidly as well.
>
Really? And is it so usable/useful in a typical desktop environment? I think
not...
>
> > So, where am I trying to end with all this talking?. I'm just trying to
> > say to all of you wonderful GGI/KGI/graphical kernel hackers that this
> > lack of a good subsystem must be told to all the Linux community and by
> > all means.
>
> We try |->. As you can see by subscribing to ggi-develop for a
> while, we actually have quite a few users these days.
>
I repeat: we need more promotion. This should be talked in the next
IRC meeting.
>
> > Why? Because it's the only way, normal Linux users see this
> > lack and start asking for it.
>
> Oh, I think the number of "X is obsolete" type articles have shown
> up on Slashdot over the past year is a sign that people see the lack |->.
>
Only a little portion of Linux users can really see this lack. They are just
happy because Linux is fast, reliable and doesn't crash so often as windows
does ( they say Linux like a typical server station). But not many see that
the situation (the multimedia situation: graphics: 2d+3d and sound) now
can't sustain Linux in a good position for the desktop arena.
>
> > So, please, does anybody have or could
> > have a good article to write in Linux Journal, Linux Today, Slashdorg,
> > etc... about converting Linux in a better OS through changing the Linus
> > way of thinking about kernel graphics hacking?
>
> Linus would just say what he has always said:
>
> * Show me the code
There IS code.
>
> * Direct Rendering is necessary for performance reasons
Doesn't allow KGI a lot of Direct Rendering if necessary or with the proper
graphics card?
>
> * Running X as a trusted userspace binary is OK
Not for me and many others: A lock in X just makes Linux crash, converting
Linux in a prone system to crashes when it handles graphics. Many of us have
come to Linux to avoid Windows crashes, so for many of us (and this is
something ALL Linux users should know) having a binary that can take all your
system down is a big pain...
>
> * X is not obsolete
Uff, not only is obsolete, but it is incredibly big and fat too.
>
> * Who will maintain KGI in the kernel?
Should KGI look for sponsorization with some company? How about Simmons?
>
> * The abstraction is unnecessarily complex
>
This is very questionable. After all, the complexity is going to fall into X
sooner or later. But with KGI I can construct other programs (servers) and
the complexity is handled in only one place: the KGI subsystem.
> * He doesn't like UDI
>
> The answers to these objections are (in order):
>
> * KGI 0.9 boots a kernel with mouse, keyboard and /dev/event integration.
> It is ported to 2.2 but a 2.4 patch is almost ready. Overall stability is
> good, example drivers exist illustrating all features of the API, and a
> well-working and modular kernel patchset is available. In terms of API
> weight, once you factor out the console, KII subsystem and mouse/keyboard
> drivers, the remaining core /dev/kgi code isn't that much bigger or more
> intricate than ALSA's code.
>
> * This argument has been demolished in the past:
>
> 1: Most modern video cards are so fast and complex, with so many
> interacting subsystems (AGP, DMA, 10+ different types of interrupts,
> hardware semaphores, FIFO watermarks, tokenized command pipes, etc etc)
> that signals from the video hardware to the OpenGL driver code which is
> feeding the hardware command FIFOs is always delayed. Not only is it
> delayed, but it is delayed by an unknown amount of time, due to the
> vagaries of scheduling. That often means that that signal is useless for
> its intended purpose, and you gotta use 'em correctly to get maximum (i.e.
> acceptable) performance out of the hardware. You _have_ to have more
> kernel-side code than DRI has, as well as more complex drivers.
>
> 2: Rendering latencies rarely exceed 100fps, which puts a huge upper bound
> on the rendering latency of the system as a whole. _That_ is what direct
> rendering improves, _NOT_ performance as a whole. Both DRI and KGI should
> be able to peg most modern hardware in any event.
>
So we have answers, and many...
>
> > Besides this, pressure must be made in the Kernel mailing lists and to
> > the DRI and X teams to encourage these changes (and changes focused in
> > just one direction, not a thousand directions like
> > fbdev+DRI+X+DGA+etc...).
>
> We have found over the years that we have to re-implement the
> legacy APIs we wish to emulate, not force them to change themselves.
>
> > Let's all begin a flamewar (but one with good
> > pretensions).
>
> Please let's don't. Go do some searches on the linux-kernel
> archives for GGI and KGI and you will find some bad flamewars, many of
> which I was involved in. That doesn't accomplish anything.
>
Maybe I just were over-excited. Instead of flamewar put the word
promotion/marketing...
>
> > I think it's completely necessary and needed.
>
> _I_ *know*, from long personal experience, that it is not. Our
> code is good enough to speak for itself now. If you want to help GGI to
> succeed, do it by helping us with some task.
>
If only I knew where to begin...
>
> > The people
> > must know why these changes are necessary.
>
> Enough people do now that we don't need to be obnoxious. Nor, we
> would certainly hope, anyone who supports us.
>
> > We want a better OS, that has
> > always been the idea behind Linux (if not why should we use it instead
> > of Windows?).
>
> Indeed.
>
> Jon
>
> ---
> 'Cloning and the reprogramming of DNA is the first serious step in
> becoming one with God.'
> - Scientist G. Richard Seed
Thank you very much for taking the time to answer my questions...
