> 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.
And it also doesn't touch any other subsystem.
> 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.
Much work as been done but their is still much more to go. I hope to
complete it for Linux World. The good news also is I have alot of support
from several people in the linux community. For me I see the need to
seperate the console system from the graphics system.
> He just has biases which cloud his reasoning in certain areas.
His strange and scary obession with X :-(
> 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 |->.
It isn't so much that X is obsolete. I used to think X really sucked. The
problem is XFree86. It really is poorly developed code. Not only do I
think this but many kernel develoeprs think this as well. It just their
is no rock solid "FREE and OPENSOURCE" alterivate to XFree86. X could be
pretty good. Take a look at Keith Packards X server for embedded
machines. The X server has a memory footprint of 1 meg and supports more
things than the standard XFree86 server.
> Linus would just say what he has always said:
>
> * Show me the code
Starting in January :-)
> * Direct Rendering is necessary for performance reasons
This is where people disagree the most on. One side states graphics should
be done completely in userland (Linus and XFree86). Some want everything
in the kernel, been tried with other UNIX systems. The best solution is to
virtualize the graphics pipeline. Here you have a solution that is a
balance of both.
> * X is not obsolete
X is alright for a windowing system. The real mess is XFree86. People know
it is a mess but don't have any other rock solid X solutions with the
above conditions. If another opensource free X server came out XFree86
would be finished. I have hinted at this before. In fact the desire for a
new graphics handling system with a new X server is so large that on my
mailing list for GFX I have more people subscribe than my console project
and their is no active coding going on. What is even scarier is the list
is still growing all the time.
> 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.
A RRM (Rendering Resource manager) is needed.
> > 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...).
Just as a side note. Fbdev was designed to deal with graphical console
systems. As for the fbdev interface it is meant for legacy compatiablity
with sparcs. In time this interface will go away and be replaced with
something better.
> 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.
I agree. This doesn't help. Going against the grain only destroys the
wood. What does help will be good code and a clear message. When I say
virtualize the graphics pipeline people responded better than the kernel
should manage the accel engine.
