[ ioctl's cannot manage all high-speed port access ]
[ driver itself handles locking ]
[ VC switches should be possible ]
> > Perhaps if somehow one could put minimal support for restoring textmode into
> > the kernel,
> 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.)
I think we could get around this 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 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 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.
> > 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).
I don't think so. Daemons get more and more numerous and induce paging and
process overhead.. not to mention having states that require proper shutdown.
The kernel is best suited to minor port-twiddling according to proper configs.
> 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...
I second that.
I think the main list of priorities we have is starting to look like this:
- kernel calls couldn't try to handle high speed gfx throughput
- a shared library could handle high speed gx manipulation
however
- a kernel call (via device) is centralized and secure and timing is precise
with reliable configuration locking and *sharing* (critical principle)
[dangerous operations could be setuid-root-limited, but most aren't
and SVGAlib can do enough damage itself!]
- a shared library would be possibly mis-located, misconfigured without
a possible boot-time check/probe of any sort, and can always
conflict with other processes under certain race conditions
In other words, a Windows-esque driver would bog down throughput and be bloated.
A maintenance of SVGAlib, nice as it is, is too decentralized, too specialized
in its approach and use and too difficult to be updated by lots of
vendors/people.
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.
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".
Then the customized function is mostly client-side code as if it
were a well-configured and yet state-sensitive SVGA lib.
Yet it has yet also a kernel level of central brains and reliable
boot-time and global-state-sensitive configuration.
(some cards should in fact be able to block VC operations or allow
them only when in certain modes.. and that is very kernelish).
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.
A device then could be "configured" (maybe by a near-card-specific
startup?) to have a client-formed dynamic "ioctl-API" that a
more generic program could inherit and run.
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.
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, or maybe via
semaphores? Or would spin-polling really be necessary for such precise
synchronization?
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 ?
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.
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.
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.
> --
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)