> On Sun, 2 Jun 1996, Jon M. Taylor wrote:
>
> > 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.
No problem insofar as system stability is concerned. There are
lots of other issues that kernel graphics would resolve or mitigate.
> The problem is that some graphics activities cant take the IPC performance
> hit.
Video-card-programming activities are ill suited to this sort of
environment. They disable interrupts a lot, for one thing. Things like
vertical blank synchronization, blitting and smooth scrolling all need to
bang the hardware as fast as they can, and anything less than full kernel
integration in something like this just wouldn't work.
> [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.
Maybe sometime in the future when all video cards come with a huge
suite of built-in acceleration functions for everything from stroked fonts
to blitting to 3d+shading, there wont't be a lot of video-api functions
that need to do a lot of RAM -> videomem blasting. That time is not
now. This is why ioperm() won't work - the overhead would *kill*
performance.
> Imagine, to do a palette change, we would have to switch to another
> process and back. Or to do a hard scroll.
Exectly. It won't work.
> 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() ...)
You also need cli() to do a lot of mode switching stuff, at least
on my card (Mach32) and the S3.
> 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 :)
I actually don't think that we are quite ready yet for full kernel
integration, though we aren't *too* far away. The basic driver framework
is in place, but we don't have the mmap()ing stuff to patch together
linear framebuffers out of banked video memory working yet. We have a
skeleton VGA driver that does basic textmodes and fonts pretty nicely, and
a few graphics modes not so nicely but workably. The current driver-base
maintainer has also done quite a bit of S3 work, which is currently the
best-supported chipset we have. Some guy also mentioned that he had some
kind of cirrus driver, which is in the latest source tree but I have no
way of testing. Also, I have hacked up a crude driver out of Micael
Weller's SVGAlib Mach32 driver sources. It isn't much better than the VGA
code, but it wouldn't take a whole lot more work to polish it up pretty
nicely. We create a /dev/graphics that maps the video memory and can
accept IOCTLS fopr various ggraphics and text atomics. VC switching
works, although my driver and the VGA driver don't do backbuffering yet
(lose the graphics screen contents on a graphics->textmode VC switch).
Still, it is more than enough to show that the concept will work.
There's also some skaleton user-space library code available now. The
config menus are standard kernel config style, so it will be easy to
integrate into the current kernel menuconfig system.
The GGI may not be really usable for graphics yet, but textmode
stuff is decently close to being able to replace ALL the textmode stuff
we have now. I used to always have at least 4 VC open when I was
developing - two running jed with color, one compiling and one browsing
SVGAlib sources with less. Things used to screw up a lot, but that was
because I was developing and testing graphics stuff a lot, too. Whenever
I needed to read news, use Lynx, compile the kernel, or any other purely
textmode-oriented stuff, it usually worked just fine. X and SVGAlib
won't work, though. Because of this, I usually keep two kernel images
around that are the same except for the presence of the GGI in one. If I
ever need to use SVGALib or X, I just boot with the other kernel.
If we were in the kernel, a LOT more people would see the code
and more people would be available to help. It wouldn't affect anything
if it were't compiled in, and if it were clearly marked as being alpha
code and didn't show up when that don't-show-alpha-options switch is
turned on , what would be the harm? There's other alpha stuff in there
too. I think we deserve a shot. If we find out that it won't work
after all, if it dies on the vine (not likely), or if for some other
reason it doesn't work out, it can be pruned out at some later date. No
big deal. All I have to do is convince Linus....
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