[lkml]   [1998]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [offtopic] dual vga?
    On Wed, 8 Jul 1998, Nathan Hand wrote:

    > On Tue, 7 Jul 1998 wrote:
    > > On Tue, 7 Jul 1998, Martin Mares wrote:
    > >
    > > > > This may or may not be a kernel issue, but is there a way to have a
    > > > > dual-head machine with two vga cards in it? (as opposed to vga+mda)
    > With fbcon going mainstream on x86 it has now become a kernel issue at
    > last. The support may already be present, for all I know, but it is an
    > issue that fbcon needs to address within the kernel.
    > > > With ISA cards it's impossible since the I/O and memory addresses
    > > > conflict with each other. With several PCI cards it's possible, but
    > > > I know no drivers supporting it (AFAIK, different cards do configuration
    > > > of addresses in different ways).
    > Accelerated X supports multi-head support with *some* video cards, for
    > the list see GGI supports multi-head via KGI, but you
    > may want to wait until GGI enters ALPHA before playing with it :-)

    <righteous indignation>

    Please do not make disparaging comments about GGI stuff if you
    have not even looked at it, since from your comment it is quite obvious
    that you have not. "GGI" (EvStack, KGI and LibGGI) has been alpha for
    quite some time now and is actually going beta for 1.0 within months.

    </righteous indignation>

    To return to to topic at hand, yes KGI does support multiheading.
    Let me update this list on exactly what KGI can do and where it is
    heading, since fbcon has brought kernel graphics to us at last. It has
    been decided that KGI will work with fbcon, and to that end I have
    recently committed the first version of "kgicon" to our CVS repository.
    kgicon is a KGI-fbcon bridge layer that allows KGI drivers to be used as
    fbcon drivers. All of the input device driver and console handling stuff
    that Linus didn't like in the old KGI have been removed and are going to
    be handled by EvStack, aka "The GGI Console" from now on - kgicon is a
    pure video card driver interface.

    Therefore, because KGI drivers are multihead capable (the ones
    that handle PCI cards anyway), fbcon will be multihead capable if used
    with kgicon. Just insert another multihead-capable PCI card, compile its
    kgicon driver as a module, insert the module, and use con2fbmap to migrate
    only certain VCs to the new driver. Presto! Instant multihead. Set the
    FRAMEBUFFER environment variable appropriately in the different VC's
    shells and run two instances of XF86_FBcon! And, because LibGGI has a
    very nice fbdev target, you can use LibbGGI's SVGALib bridge layer to run
    more than one SVGALib app at a time, too! Of course no root privs are
    needed for this.

    kgicon has drivers for the following chipsets:

    Chips & Technologies 655x
    Cirrus Logic 542x and 546x
    Cyrix MediaGX
    Matrox Millennium I, II and Mystique
    S3 928, 96x, Trio64V+ and ViRGE
    Tseng ET4000 and ET6000
    Western Digital PVGA wd90c00, c1x, c2x and c3x

    kgicon is not pristine yet, of course. Here's a list of the
    major outstanding issues:

    * Only a few drivers (VGA, Trio64V+, ET6000 and the Matrox drivers) have
    been ported from the old KGI to kgicon. This "porting" involves maybe
    five minutes' worth of modifications, mostly to reflect the fact that
    includes have moved and to avoid having the drivers complaining that they
    cannot allocate the VGA IO ports that the vgacon driver has already

    * The existing 4bpp texmode routines (fbcon-cfb4.c, written for Macs) have
    problems with VGA 4bpp mode because it is big-endian. Fonts are garbled.
    This rules out graphical textmodes with the VGA driver for now - you need
    8bpp+ modes at present.

    * The video mode is currently fixed at compile time and cannot be switched
    (resolution is always 640x400, depth is set with a #define). I need to
    figure out how to make KGI's infinitely variable PLL mode generation
    routines work with the mode tables that fbcon uses. Shouldn't be a big

    * Support for kgicon driver being compiled straight into the kernel - only
    modules are working right now. I have made this "work" in the sense that
    the kernel compile went through OK, but bootup crashed. I decided to
    shelve that until the remaining fbcon issues are resolved. It looks like
    Geert's and Martin Mares' latest patches may accomplish this, so work in
    this area should resume soon. The other issue WRT true kernel integration
    is in the kernel config system and how to bridge it to the kgicon config

    * The drivers are still fairly x86-centric. Some drivers are for cards
    that are ISA-only so this doesn't matter, but for the PCI cards the
    drivers really need to work with Mac, Alpha, etc. This shouldn't be too
    difficult, but it needs to be done. Zorro, sbus, etc. are currently not
    supported at all.

    * The bridge layer doesn't handle any ioctls yet. But, neither do most
    current fbcon drivers. This is how the non-fbcon acceleration support of
    the kgicon drivers will be accessed, too - the ioctl handler will filter
    out the non-fbcon ioctls and handle them separately. KGI-aware code (like
    LibGGI) will know about these extra ioctls and be able to use them, and
    other apps that only know about fbcon's ioctls will be able to totally
    ignore the KGI stuff.


    If anything above sounds interesting to you, come check out the
    kgicon/ directory in our Degas CVS tree. Remember, the more bug reports,
    patches and new code we get from YOU the sooner your favorite driver will
    be able to do all of the wonderful things described above!


    'Cloning and the reprogramming of DNA is the first serious step in
    becoming one with God.'
    - Scientist G. Richard Seed

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:43    [W:0.029 / U:6.040 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site