>
>
> On Tue, 7 Jul 1998 linker@nightshade.ml.org 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 www.xinside.com. 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
Hercules
IBM VGA
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
grabbed.
* 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
problem.
* 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
system.
* 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!
Jon
--- '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 majordomo@vger.rutgers.edu