Name one. (yes, VGA _does_ have a frame buffer)
> I/O port access is critical. The "frame buffer" of most cards
> is actually a window of 64K onto a mapped space.
That is good enough because the virtual memory hardware can be
used to make it appear to be linear. The process does not need
port IO to move the window.
> Its critical enough the X servers do iopl() rather than ioperm
> to save a few clocks (2 or 3) for each out/in they do.
They do this because modern video cards spread IO ports all over
the IO space. They have a reasonable footprint in the 10 bits
or so decoded by old cards because they decode the upper bits too.
It's as if a large contiguous set of IO ports had the address bits
rotated to the right 4 to 6 bits.
>> The real reasons for such a driver are reliability and security.
>
> Which only need kernel support for "restore to text mode".
Nope, because "restore to text mode" is impossible without knowing
the complete hardware state. (many cards have write-only memory)
You _must_ have kernel support to avoid the suid bit, which is
a Good Thing. With kernel video, paranoid sites could even disable
ioperm() and iopl(). Kernel video lets users have config files for
video modes but keeps them from flatlining your monitor.
Kernel video is the _only_ complete solution. If you'd like to
discuss this further, please join the Linux GGI mailing list.
It's not even 10% as busy as the linux-kernel list, and it is
the proper place to discuss video issues. The list server is at
listserv@eskimo.com and the maintainer is irish@eskimo.com.
(Irish will be gone for a week or two, so be patient.)