It is not good if only one task can use video. We can switch VCs while
in text mode, and graphics mode should not be any different that way.
> As for cards with resources outside the "likely" address space: obviously
> this can't be guessed. So a program would have to open up /dev/ioports,
> play around with the card enough to figure out what resources are needed,
> and then tell the driver to allocate those resouces.
So I tell the driver "I want these really nice ports HERE." and it
gives me the IO ports to control the ICBM launch controller.
> As for multiple VC's, I don't think this would be a problem. Two programs
> cannot control the video card simulatenously. So to perform a cross-task
> VC switch, the first task would close /dev/ioports when it gets told to
> background itself, and the second task opens up /dev/ioports when it wakes
What if the task is stuck in for(;;)? What if it is malicious?
>> No need for this to be in the kernel; a simple daemon with
>> iopl() could do it as badly (and, with a different design,
>> could do it better).
The daemon won't work unless it knows the complete video state.
> Indeed, since this mini-video-driver approach wouldn't help the kernel
> shift back into textmode (and perform similar tricks) there isn't any
> need to have a kernel driver in the first place...
Wrong conclusion. The mini-video-driver is not adequate, so we need
full video support. Locked up consoles are OK for Linux 0.99.pl15,
not a modern Linux. There are enough Linux programmers now to make
a large video project possible. XFree86 is a temporary solution.