[lkml]   [1996]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SVGA kernel chipset drivers. [interface idea]
On Fri, 7 Jun 1996, Christopher Hassell wrote:

> I think we could get around this [inability for the kernel to restore
> textmode] with loadable modules. There *HAS* to be some sort of
> driver-specific distribution that vendors could someday give out!
> We need to be able to download a .tar and then say "Great, I have a new
> driver" and then insert the module, and run a shell script. No
> recompile.

And that is what GGI is all about -- we're back to square one.

> The ability to manipulate a kernel API to do sequences of operations with
> kernel-internal timing and control structures is *really* untapped. It's like
> going from a single-command execl call to a scripting shell.

An interesting notion that might have uses inside something like GGI.

> [...]
> so logical comprimises for (1) the Lib and for (2) the Driver:
> 1) Make a centralized way to "activate" a billyun API services in *generic*
> ways. i.e. Standardization through the separation of core
> functionality from various nonstandard ops. Want Mode X? Better
> know you can handle it, but memory mapping could be laid out for it.
> This gets port-twiddling away from client concerns, just as SVGAlib,
> but allows more hardware-specific access that SVGAlib cannot keep up
> with.
> A device would show off the "palette" of available operations and
> memory maps and rendering ops and DMA ops. The client process could
> then pick/choose and activate what it can according to the
> most generic means possible, like SVGA lib.

Precisely. This is what GGI (or svgalib, for that matter) looks like to
the user.

> Those could even be a sort of object-oriented mishmash. That is,
> the SVGAlib could ask Mr. KernelDriver to hand it the recipe to do X
> Y Z and Q, given a big possible number of ways to do one operation.
> The kernel could say "This card does API #Q454 best by doing A9,E3,3F
> and then 04, after which you can submit to me ioctl #234".

Uh-uh. That would mean the video driver was telling the client how to do
things at a low level. We want to get away from that. Though, some way of
rating the speed of various ops would probably make sense.

> (some cards should in fact be able to block VC operations or allow
> them only when in certain modes.. and that is very kernelish).

I think you are missing something here: VC operations (that is to say,
display of text to the screen) _cannot_ occur when something else has
control of the display. Period. VC operations would work as they currently
do when the VC is not displayed (data stored in local buffer).

The VC layer would vie for use of the video card just like any other
program, user-mode or kernel. It couldn't use it until something else
releases it.

> 2) Use some "ioctl-scripting" (at first w/few params and maybe minor
> conditional/timing ops for single cmds, like the Copper) that one
> creates, manipulates, then "executes" via ioctl or something.
> That is in order to perform your own mishmash of card-manips
> and this and that reconfigure planes and rendering (or whatever
> other operations are reasonably kernelish). It could almost
> even emulate old-fashioned sprites! (this would be useful for
> Atari/Amiga compat, no?) Just vary the params for your minor DMA
> ioctl-script.

No, you can't emulate sprites. Real sprites are _hardware_ devices that PC
video cards are singularly unsuited to emulate. Don't worry about stuff
like this. Let's just get _simple_ memory access before we try the fancy

This ioctl-scripting stuff is neat, but at a much lower level then most
people want.

> The pattern remains the same, from hyperspecific and
> hardware-dependent kernel drivers to generic and graphics-reliant
> software, the "pre-configuration brains" can become dumber
> and dumber. From kernel to SVGA-APIlib, from SVGA-APIlib to
> Gfx-Config, and then from Gfx-Config to the Blow-Em-Up-Good
> main process. That's the way to use the Linux kernel well.

And that matches a rough diagram of GGI.

> Anyone know if screen-blanking or some sorts of device-to-client
> signals (DMA done, Z-buffer collisions) could be handled with adequate speed
> via a SIGIO or SIGUSR that came from the kernel,

No. Signals are very poorly suited for this sort of thing.

> or maybe via
> semaphores?

That seems more likely.

> Or would spin-polling really be necessary for such precise
> synchronization?

Quite possibly.

> In principle:
> - a daemon would be too slow to page, context-switch for every
> possible manipulation of a card. State information can be botched.
> - a library is too monolithic and can't get timing down to precise speeds
> - a full-blown SVGA device driver would be a bottleneck and bloat the kernel
> unnecessarily
> I've seen lots of "Not this" and "Not that". Any comments on these ideas ?

Skip the deamon and put something in the kernel. Put a _small_ something
in the kernel -- something somewhat similar to the VESA information.
Enough to figure out what the card is, what modes, clocks, DACs,
accelerations, etc., are available, how to use them, how to save the
card's current state, and how to switch into various modes. Perhaps not
much more then this.

This card-specific code is loaded into the kernel via insmod.

That gives the kernel the main piece of information it needs: how to
switch to a textmode.

Now, to actually _do_ something useful, you tie in user-level code. A
program like SVGATextMode would be very simple, as it's mostly just
prodding the video-driver in the kernel. Something like SVGAlib (or X)
would have more layers. And so it goes.

> Though I see Linus is not very hot to jump into this frying pan, I think
> that graphics-card manipulation is essential to support well in something that
> has a *real* kernel. It is the mark of a truly dazzling system, especially
> given the compatibility across for huge numbers of cheap or expensive machines.
> That could really appear to kill Win95, as game nuts might see it.

I don't know about that. I just know that the kernel doesn't know about
textmode as it stands, and this seems to be a large problem. I also know
that there isn't a standard for describing how to detect and program video
cards that allows for pre-compiled drivers. This is also a large problem.

And I hate to tell you this, but Win95 does _not_ have a *real* kernel.
Linux does.

> In fact, I cannot imagine game-developers turning down the level of
> compatibility a well thought out API could produce. Linux's signals,
> context-switching, caching are great. I cannot imagine many folks with aweseom
> graphics-boxes having to go no-games because all the graphics API is Intel-only.
> Cross-platform graphics must go beyond mouse-windowing, just as in W95.

I hate to tell you this, but Win95 enhances gaming by letting programs
drill through the cross-platform stuff and access the hardware directly.

_True_ cross-platform graphics is X.

> Given reasonably complete and easy support in the kernel for lots of
> vendors, made from easily-formed probes and module-choices... we could get out
> of Character-mode for dozens of wildly impressive, and highly efficient
> applications.

I don't want to get out of character-mode, thank you. It's impressive and
efficient enough already.

Kenneth Albanowski (, CIS: 70705,126)

 \ /
  Last update: 2005-03-22 13:37    [W:0.043 / U:1.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site