> On Sun, 2 Jun 1996, Linus Torvalds wrote:
>
> [ "priviledge dropping" SVGA server implementation in user space ]
>
> > Essentially, this already sets up the protection domains. The server is
> > protected, yet the fork() inheritance is able to give the graphics
> > program all the resources it needs, and nothing more.
>
> presuming that a user program is allowed to have all priviledges. What we
> are talking about is an interface to the graphics hardware. The direct
> method is the way X does it: it gets the whole resource, on "bare metal"
> level. On the other hand, the most indirect way is having everything that
> does a single outb() or similar operation, in the kernel.
Right. We don't need OpenGL in the kernel, but we need
*something*, and that something has to be card-specific.
> The problem is not the framebuffer. The problem is those zillion
> VGA/SVGA/XGA/CGA/EGA/S3/Mach32/64/etc registers that all need to be put
> straight. In userspace either we use iopl() to get >all< registers on the
> machine, or we use ioperm(), to get some registers (but we have to take
> the performance hit on a >per register basis<.
Which is why the SVGAserver idea is broken. We need individual
device drivers for individual graphics cards for the same reason that we
need individaul drivers for different sound cards - because each card does
different things and does the same things differently. It is too
dangerous and kludgey to allow userspace programs to have THAT much
control over the hardware.
> With a "partly in the kernel" approach, the performance hit is per
> operation. I dont know all GX cards that well that i could decide which
> performance hit is bigger.
It is bigger than iopl(), but it is worth it. Userspace programs
should not be doing end-runs around the kernel or we might as well go
back to DOS.
> But what if we dont even want to give register
> access to a user program. I'm not trying to be destructive or anything,
> just imagine that some cards are capable of damaging some older monitors
> with too high frequencies. Some cards burn if they get programmed to a too
> high clock rate. I think some cards cant be recovered to text-mode, if the
> access to the registers is not traced in a secure way. These problems
> can't be solved with the ioperm() call.
Another strong point of the GGI. We have separate drivers for
Chipset, RAMDAC, clockchip and Monitor. No part of the whole pagage
(most crucially the monitor) will be allowed to go beyond its limits in
the course of normal operations.
> the X way is a very good solution, once all clients are communicating
> through a high-level graphics protocol (read: X protocol). No problem
> taking the IPC hit, unix-domain sockets are fast as hell anyways. But the
> ususal SVGA programs have much lower level operations (changing the
> palette using some registers that btw. might be right next to the clock
> generator registers) to make an IPC viable.
Like I told Linus, I don't like the idea of being forced to use X
in order to use graphics. it seems to me to be a very IBMish concept.
> In this sense we can talk about X as the "X protocol kernel".
Now, X itself is *definitely* something that does NOT belong in
the kernel |->. However, if we had a good, standard kernel interface to
video cards, X (or any other GUI) could easily be built on top of it, and
only one server executable would be needed! Funny what's possible when
you have an API....
> I know the whole concept of PC graphics cards is broken beyond
> recognition, but at least we have to understand the problems before
> talking about the solution :) [i'm afraid that it is me who should start
> doing so]
Yes, PC graphics cards are a mess. That doesn't obviate the need
for the mess to get cleaned up properly. The way we are doing things now
is a monumental hack, one that should not be present in an OS the caliber
of Linux.
Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj>
------------------------------------------------------------------------------
"Everything in excess! To enjoy the flavor of life, take big bites.
Moderation is for monks." - Lazarus Long