Now _this_ is a valid approach - if Linux can help Xfree86 in any real way to
make a better X server, things are different.
However, I don't think the XFree86 people want to lock themselves into a
Linux-centric world-view (the same way there exists other hardware than just
PC's, there also seems to exist some other OS's than Linux. Strange, I know,
but I have people I'd consider reliable (albeit strang) report such things to
me).
As such, the move to add functionality to Linux to help make XFree86 better is
not likely to be universally liked even by the XFree86 people. And rightly so.
There may be some specific feature we can add to the kernel to make it easier
for the XFree people to develop X, and then I'll do it. If that happens to help
other projects too I'm all the happier - the mark of a good design is that it
works for lots of different things.
> It makes user-level things a hell of a lot easier to program, and
> the easier it is to program in, the more programmers you're going to get
> doing it. Why do programmers still support MegaSucky "OS"'s (using that
> term loosly ;) ? Because they're easy to program in!
Umm.. The above doesn't follow.
Changing the kernel to support XFree86 more wouldn't change the _user_ program
interface in the least. The X protocol is a standard protocol, and that part
wouldn't change..
(There _are_ XFree86-specific features, like the direct frame buffer
extensions, and the people who worked on that contacted me about perhaps doing
kernel stuff for it. They seemed to have ended up it without any kernel changes
though)
> > When you argue for kernel support for graphics, you argue _against_ the
> > already existing, standard UNIX graphics API that does a hell of a lot
> > more than some stupid frame buffer.
>
> Not really.. I think the point is that the kernel drivers do all the
> low-level stuff that requires kernel/superuser privs, and any user-level
> program that wishes to perform these functions must call the kernel
> routines to do it for them. It's not meant to be a REPLACEMENT for X,
> after all, what CAN replace X? :) Think about it - there will be no
> need for a million & one setuid-0 X server binaries that are 2-3Mb in
> size! One generic server would be enough, which calls the kernel to do
> the card-specific routines, and hence doesn't need to be setuid-0.
Umm.. I fail to see the advantage.
On the machines I use, I _already_ have just one X server binary. Admittedly I
chose that one from a larger set of binaries, but what is the relevance of this
point? We need to have different drivers _anyway_, and having them as separate
X servers is a lot easier than having them as separate kernels..
XFree86 already _does_ the graphics stuff, and I see very little advantage to
moving any of that into the kernel. When _they_ approach me and tell me that
they'd like some more features, I'll take it into consideration, though.
Linus