[lkml]   [1996]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SVGA kernel chipset drivers.
On Thu, 6 Jun 1996, Jonathan H. Pickard wrote:

> > I think you missed one think: the driver itself would perform locking.
> > Only one task could open "/dev/ioports" (or whatever) at a time. No
> > deamons, and no schmoes allowed, assuming that something has already
> > grabbed the driver.
> Ah. It does make for arbitration amongst consoles a little more
> interesting, but I do like the idea you've come up with below using STOP and
> CONT signals.

Or whatever signals/mechanisms are used to tell a graphics program that
"I'm putting you away and going somewhere else for a time".

> > 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
> > up. (This doesn't deal with allocating VRAM in a useful manner to save on
> > (or _for_!) swapping. That's only possible if the kernel knows all about
> > VRAM.)
> This means now that the VC code has to know all about suspending tasks on
> graphic consoles (but not necessarily on non-graphic consoles). It's also a
> bit harder to save other state as may be found necessary, or possibly even
> to let a blit finish.

I don't think that is what I meant: the kernel VC layer wouldn't ever
suspend the graphics task itself, as the VC layer doesn't have the power
to assert a switch to text mode. All switches out of graphics mode are
(currently) invoked by the graphics program itself, either on seeing
Ctrl-Alt-Fn, or on receiving SIGINT, SIGSTOP, or whatever.

Certainly, though, the VC layer (when it's using the screen) could count
as having locked the video port/memory driver, even if it's bypassing that

> > This is currently needed, but I don't see how it's feasible. And it
> > certainly wouldn't be portable. There are too many video cards with too
> > many weird registers to support some method of restoring textmode. (That's
> > one of those fundamental problems with the current VGA architecture.)
> Well, IMHO, if we replace the video mode setting stuff we have there now
> with something that _just_ restores textmode on the appropriate ioctl, it
> wouldn't grow by more than a few K. Or perhaps we could reuse it.

What video mode setting stuff? There isn't any. Do you mean the mode you
can select on boot-up? That's programmed via the video BIOS, before Linux
has switched over to protected mode. Quite useless (since it's
inaccessible) while Linux is running.

SVGATextMode can set text modes, but that's only because it includes a
large amount of code that works on a large number of video cards.

"_just_ restoring textmode" from the kernel is going to require something
on the order of SVGATextMode that is accessible from the kernel. There
isn't any real way around this. The only reason DOS has such an easy time
of selecting video modes (text & graphics) is because the card's BIOS is

> > > and pass lists of ioport accesses to ioctl (perhaps even
> > > imparting some intelligence for waiting on bits/values or skipping/jumping,
> > > a la the Amiga copper), it might be viable.
> >
> > What I'm wondering is whether a very generic driver could be designed
> > along these lines.
> The Amiga copper was very generic. [...]

Heh, sorry, I meant a driver with a middlin' bit of intelligence, not
something on the order of copper. Doing copper properly means hardware
tricks, not software. (Heck, as I've mentioned elsewhere, just getting an
interrupt on retrace is difficult enough.)

> In our case, we could jack the concept up to 64-bit instructions (instead of
> 32-bit for the Amiga): cmove now loads either a memory location (byte, word,
> doubleword) in a given physical 256Mo bank or any ioport (byte, word, dw);
> cwait may or may not be able to wait for beam position depending on the card
> facilities provided, or may only be able to busywait, but can busywait for a
> memory location (b,w) or an ioport (b,w) logical-anded with one 16-bit
> quantity to equal a second 16-bit quantity; cskip has the same conditionals
> as cwait. If we really needed 32-bit testing we could have an extension
> prefix that gives the AND mask value, tells us that the next cwait is for
> a doubleword, and informs us that the 32-bit parameter to the next cwait is
> the compare value.

Ah, I see what you mean, now. Use a copper-like instruction list to
perform sequenced I/O instructions. Interesting, but I think unnecessary.

> Problem here is that security could be almost nil in such a setup, depending
> on how it's done. If a root-only ioctl could set up the valid memory and
> port window that such a system could access, it would be a bit slower to run
> the list.

Security is irrelevant at this stage: any hardware access to the VGA is a
complete violation of security in the first place. Anything past that is
icing on the cake. That's why we want to have the code that actually
_uses_ the VGA (or this copper like thing, or some odd 3-D accelerator, or
whatever) all in one place, and then use a simpler library interface to
invoke it. All the nasty dangerous stuff gets wrapped into one executable.

And yes, I could be describing Xfree86 in that paragraph.

Kenneth Albanowski (, CIS: 70705,126)

 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean