On Mon, 3 Jun 1996, Matty wrote:
> On Mon, 3 Jun 1996, Linus Torvalds wrote:
>
> > > Which is no good. Linux should be as cross-platform as possible,
> > > right? Then we need a uniform graphics API.
> >
> > Are you really that dense?
>
> Could be :)
>
> > We HAVE a uniform graphics API already. It's called X.
>
> True, however XFree86 (and any other brand running on linux) could be much
> improved by taking the low-level routines and placing them into the
> kernel. It makes user-level things a hell of a lot easier to program, and
Which kind of improvement?
Xservers access directly the frame buffer and drive directly the graphic
engine with normal IOs or MMIOs.
The improvement you want to get is IMHO the following.
- break the kernel rather that break some Xserver.
- break the portability of Xfree86.
What a valuable improvement, indeed.
The only necessary low-level routines allow to map the frame buffer,
to get access to IO register and to map the memory mapped IO registers.
(Sometimes, to map the VGA BIOS area)
> 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!
>
> > 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.
>
> >From my little understanding of operating systems, isn't the kernel
> supposed to be the "process" that interfaces between the hardware it's
> running on, and the software running on it? Any program that needs to be
> setuid-0 so it can BYPASS the kernel is an extremely dodgy way of doing
> things, IMHO. Every program that needs low-level access should request
> that access from the kernel - otherwise we might as well scrap the whole
> kernel idea and run an anarchist system like Messy-DOS.
If you intend to run a Xserver in a multi-user system, just do it and
try some commands like "x11perf -putimage500".
You system becomes a station and the other users become very nervous.
A Xserver must be used IMHO on personnal stations or a X stations.
You said dodgy. IMHO nothing is dodgy.
> Back onto the X point, the kernel routines are the low-level stuff
> specific to the graphics cards. Make them VESA compliant so that as many
If you think that VESA standard is a good way to drive
intelligently a graphic board, IMHO you have lots of things to learn about
graphic engines.
> cards as possible are supported, and the standard kernel API can be called
> by X to do whatever. X still keeps it's API, the only change is that it's
> calling the kernel to do low-level stuff instead of doing them itself.
> It's no different to including support for sound cards (as others have
> pointed out) or any other I/O device for that matter.
> If a particular graphics card becomes so obsolete as it is just taking up
> space in the kernel source tree, REMOVE it! Doesn't take too much effort
> to execute "rm", taking that driver out of the next kernel release.
>
> > THAT is why this discussion is so totally useless. You're just asking for the
> > kernel to support something that is _less_ capable than we already have. Do you
> > think I'm so stupid that I'd go for something as braindead as that?
>
> Nope, I'm asking the kernel to do what it's meant to do - be the hardware
> interface to user-level programs.
>
> -- Matt
Gerard.