[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 Thu, 6 Jun 1996, Jonathan H. Pickard wrote:

    [ 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


    - 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

    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

    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

    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

    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

    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

    > --
    > Kenneth Albanowski (, CIS: 70705,126)

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