Messages in this thread |  | 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.)
|  |