Messages in this thread |  | | Date | Mon, 3 Jun 1996 01:59:18 -0700 (PDT) | From | "Jon M. Taylor" <> | Subject | Re: SVGA kernel chipset drivers. |
| |
On Mon, 3 Jun 1996, Ingo Molnar wrote:
> 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
|  |