Efficiency
==========
SVGAlib and X are just fine, especially with XFree86's DGA capabilities.
I say this as a commercial game developer myself. I'm using Linux to
develop, even though the final thing need only run under DOS and Windows
95. In fact, at the moment it runs about 20% faster with SVGAlib than
with DOS VESA drivers, because SVGAlib can page-flip on my Cirrus card,
which VESA doesn't support. (Though VBE == VESA 2.0 does).
One thing which can be slow is switching consoles. When I switch
between X (which I don't use all that often) and textmode, it is a bit
tedious watching the machine take 5 seconds to swap 2M of framebuffer.
I would hope a kernel video driver could track the console ownership of
individual VRAM pages, so switching from X only needs to save those few
pages required for textmode. You get the idea.
Features
========
I still think we need a VM-simulated framebuffer, just so we graphics
programmers can move on and forget about old PC video cards, but know
that the software will run, albeit not very fast, with everything from
VGA onwards. Microsoft DirectX does it (optionally), probably for a
similar reason. (So they don't have to write lots of bank-switching
rendering code -- they can concentrate on code that works well with
modern cards).
For now, my rule is simple: if the memory aperture (usually 64k) is
smaller than the screen area, just do everything in system memory and
copy it to video memory later. This is not really a bad strategy, but I
would prefer a VM framebuffer option.
Right now, you can't switch consoles when debugging an SVGAlib
application -- because the switching process is suspended by GDB. This
is an argument against SVGAlib, of course. Another problem with SVGAlib
is that it can only clean up on a crash if you're not trying to use the
signals for something else (as I am). Fortunately I have `rsh'...
Again this is really an argument against SVGAlib but not for anything
else particularly.
Suggestions
===========
Perhaps what we really need is XFree86/DGA to be able to take over other
VCs. The idea is you have an X server permanently running on another
console, even if you don't use X. When an application (SVGAlib or
whatever) wants to use the screen, it connects to the X server somewhere
and tells it to take over the application's console. The server already
knows everything it needs to know about the video hardware.
Perhaps it would be better to move the video-specific part of
XFree86 into a separate "video server", which will take over VCs on
demand. Much like GPM provides mouse services to every VC.
IMO, GGI sounds about right. I think it is best to get the following
features working for as many video cards as possible:
* Save/restore state when console switching.
* Screen start address/page flipping.
* Get/set palette.
* Wait for blit to complete; lock console until it is done.
* `mmap' framebuffer is moved to system memory when that console
is not displayed -- the application needn't be aware of the change.
* VM-simulated framebuffer for non-framebuffer video cards.
* Record ownership of used VRAM pages.
* Support for VESA BIOS, just so that more cards get supported for
free.
I/O port programming to set the video mode would be just fine in a
setuid program. Just as long as the kernel driver knows about all of
the state it has to restore. Preferably the program would sent the new
state through an `ioctl' to the kernel, just so the VC doesn't have to
be locked or even displayed while the program runs.
My view on X
============
Lots of people don't use X, because it uses lots of memory (only a
problem for small machines), and because some people don't like it. I
personally don't use X except when I have to, simply because, with my
low-quality monitor, it gives me eye strain and a headache. (Guaranteed,
after a couple of hours). Text mode is fine. Thus I would very much
dislike being forced to use the X GUI to spawn graphics programs.
Compiles take longer with X swapped in too, even on a 16Mb machine.
(Even `make' has been known to need 30Mb VM on my project 8-o).
I've nothing against using the X server to control the video hardware
though. Presumably with DGA, it wouldn't even need to page in many
parts of the X server. Just so long as all I see is text mode and the
full-screen graphics application, I'm happy.
There, that wasn't really worth reading now was it?
-- Jamie