> 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.
well, it's not broken.
i see no conceptual difference between a trusted binary (and *only* the
trusted binary should access the IO ports), and a kernel device driver.
The problem is that some graphics activities cant take the IPC performance
hit. [but the overhead of a kernel trap would be worth it]. It's true that
most graphics activities deal with the framebuffer (or something alike
it), so this point has to be considered carefully.
Imagine, to do a palette change, we would have to switch to another
process and back. Or to do a hard scroll.
Another problem might be that you can't cli() from userspace. And if
someone ever gets IRQ9 going, then we need kernel support for that at
least. (and we want then to protect our code from IRQ9, which in turn
needs cli() ...)
but anyways, as Alan has said, get the code working and prove your
concept. This aint no ego-trip OS, experience is that if your code is
right, then it has fair chances to get into Linux :)
-- mingo