OK, me too then.
> The features that I believe most people would like to see in their
> graphics subsystem are (in no particular order):
> 1. High performance
> 2. Flexibility
> 3. Stability
What users want is more applications. That means you have to cater to
application programmers. And they want a single, fixed, easy to use
interface for all the platforms they work on. This (for free software, and
Unix look-alikes) means X11. They just might settle for a bunch of
non-portable interfaces if absolutely necesary for performance, but they'll
moan and groan all the way long.
The other thing users want is stability of the whole system; machine,
operating system, graphics, and application. And this you get by simple,
high-level, easy to use and widespread (and thus well-tested and superbly
documented) interfaces.
That's why Qt is useful: You can program and then compile on X11 or
Win32. Maybe no use for Doom or Quake, but does nicely for Nethack or
KDE. Highest performance is rather nice, but it costs _lots_ of work to get
it (Linux itself is a superb example: The interface itself (POSIX) was some
20 years in the making, the program (after some 6 years) is still being
worked over by dozens of hackers and thousands of hacker-wannabes). Its
normally a _lot_ cheaper just to buy the next larger size than to get the
utmost out of a particular model. And then you'll have to start over next
year for the current fad.
[X11 and SVGAlib]
> Currently, though, this is not possible, because the two efforts are
> indeed two separate ones, so the code and the work are essentially
> duplicated.
Yes, and SVGAlib is dead, for all purposes. XFree86 rules, and has got this
"nice interface" inside the server. You want to rip it out and put it in
the kernel. Why? As things stand, I can use the same kernel with different
graphics cards, what you propose would force me to rebuild my kernel for
each new card. Or at least load the card-specific module.
> benefit:
> 1. Less time and work would be spent on the developement of graphics
> drivers for new hardware, which would lead to
More time: Once for XFree86 (which runs not only on Linux) and once for
KGI. At least in the time before one of them takes over 100% (which might
just be "never").
> 2. More time could be dedicated to improving the performance and
> stability of the existing graphics drivers
This depends on lots of other factors. The development workforce in free
software is not a constant that you (or anybody else) can allocate at will.
> 3. X-Windows server developers could focus on developing a ONE single
> stable high performance X server (instead of n) based on the accepted
> low level interface
If (very big if) the "one lowlevel interface" is really simple enough, and
on the other hand efficient enough, to get there. For whatever weird
hardware you care to throw at the interface, to boot.
> [4. Windowing systems other than X-Windows could be built with instant
> support for a large number of graphics adapters]
No real need for them (see above).
> Besides the developers, the users would benefit also:
> 1. They can choose, which user interface suits their needs better (the
> extremely flexible X, the high performance SVGAlib, the not so flexible
> but faster than X but not so high performance but more flexible than
> SVGAlib not-yet-developed-windowing-interface)
They are screaming for a nice, easy to use desktop and applications,
applications, applications. Both _must_ be portable (applications at the
very least should be able to be recompiled without any tweaking and minimal
testing, if any, for as many platforms as possible).
> 2. More and faster support for new graphics devices
Not much faster than today, possibly slower, where it's part of XFree.
> 3. Better performance of the graphics devices
Rather irrelevant, except for niche applications.
> 4. A wider variety of graphics applications
How could it be larger than what X11 gives today?
[...]
> By implementing the support in the kernel, the users and the developers
> would thus also benefit in:
> 1. Improved security, and
As stated here before, a broken driver _inside_ the kernel can do as much
damage as a broken driver in userland. Nay, much more.
> 2. Improved stability
That remains to be seen. It depends on the number and nature of the bugs in
the software and its use, and the means taken to isolate their effects.
[...]
> The question is therefore not "Do we like GGI as it is now?" because GGI
> can be changed, but rather "Do (and if we do, why) we need a graphics
> adapter support in the kernel?". I believe I at least partly answered
> the last question: performance, flexibility and stability (again, in no
> particular order). Most of the stuff that the Linux kernel performs can
> be done in user space. The answer why they are NOT implemented in user
> space can in most cases be found in (at least one of, usually more) the
> above three words.
No. They could be done in userspace with much better performance, and more
flexibility: Look at why certain performance-hungry applications like
process control and some games are still being done on DOS, i.e.,
essentially the bare machine. The stability sucks, and the development cost
is astronomical. I use Linux because I'm willing to trade (some, not
all. For that I'd use something else :) performance and flexibility for
stability and ease of use.
> PS: The X people are aware of the performance problem of the X-Window
> system and are trying to address it with XAA. I think though that what
> XAA will provide would be provided by GGI as a side product.
XAA is an internal interface in XFree86 for the people that write
drivers. It's essentially what you are proposing to export from the kernel.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu