Re: Mono monitor support?

becka@rz.uni-duesseldorf.de
Tue, 14 Oct 1997 13:51:23 +0100 (MET)


> >> Hi all. I'm using 2.0.30-pre10, and wondered if there is any support
> >> for adding a Hercules mono card, and mono monitor.

> > You can only redirect output to it (/dev/mono) but I'm working on a driver
> > which will allow you to use a PS/2 keyboard in the mouse port, to give the
> > mono
> > screen a matching keyboard. Any more than that and you're asking for GGI,
> > really.

> > I have had getty running on the mono screen, with tty1-3 on the VGA and 4-6
> > on the mono. If you want that, go for GGI.

> I had the mono monitor running X a few years back, in conjunction with my
> Trident 8900D, just as an exercise. Now I have a Matrox, and I understand it
> may be possible to run another SVGA card in conjunction with that.

Yes. However this is not too simple, as many cards are broken in the feature
needed for this (it is reported to work right for Matrox, IIRC):
As two VGAs in the system would want to sit on the same ports, you need to
put the card into MMIO-mode where you can relocate the address.

Plus your BIOS will only initialize _one card_. The second one must be
initialized from zero by hand and AFAIK the only drivers that allow this
for now are the GGI/KGI drivers.

We are running S3 964/968 combinations fine for dual- and triplehead (with
mono being the third) configurations.

> GGI isn't a finished product yet, correct?

Yes. I'd call it alpha. We hope to have another public beta by the end of the
year. We go like the Linux kernel with a "hacker's tree" and stable releases.

> Is it a user-level program, or does it require kernel patching?

This depends somewhat. GGI consists of several parts which are largely
independent. Our default graphics driver layer (which you would need to do
multihead) requires severe kernel patching.

This is basically because we replaced the entire console code with a system
that is more modular and allows us to change things like the terminal
emulation, keyboard translation, additional input devices (secondary keyboards,
joystick, ...), mouse-protocols,... by just swapping around modules.

We are currently working on an even more generalized system. This is very
alpha yet, but improving fast. We will try to get this system in the stock
kernel, when it is well tested and has been proven to work fine and doesn't
break too much anymore.

However if you are afraid of patching your kernel, but would like to develop
applications for libGGI (our default graphics library) anyway, we have built
dynamic bridge-libraries which allow you to redirect GGI output to an
X-window or probably soon to svgalib.

> I remember hearing that Linus will not apply it to the normal kernel tree,
> but don't remember why.

There are two main reasons :

1. Linus doesn't like the idea of putting graphics support into the kernel.
It is complex stuff and there are working and relatively safe usermode
programs out there for it (X and svgalib primarily).

2. GGI/KGI is not yet well tested by a large audience (though we are
improving) and the current patches break old graphics applications.

Our reasons for continueing anyway are :

1. Graphics cards are hardware-devices and thus we think access to them
should be arbitrated by the kernel. Newer graphics cards have features
like IRQ and DMA which cannot be handled right from usermode, too.
Moreover you can hang your system or even destroy hardware (Monitors
and RAMDACs) by programming graphics cards the wrong way.
Another point for controlling these "dangerous" operations by a trusted
entity.

To access graphics cards in the current system, the applications doing
so must be suid-root.
Thus either you have to use a client-server model with a trusted server
or rely on a suid-root application not to be malevolent.
This is inacceptable for things like professional games, where you don't
get the source and don't want to give a binary full control of your
system.

Thus we think that wrapping a relatively thin layer of kernel-code around
a graphics card to protect the system from wrong settings and exporting
that to normal user processes is the right thing to do.

2. This will improve. We are attracting more and more users (yes, we already
have users, not only developers) and we are working on a new very modular
scheme that will allow us to load "compatibility modules" which allow old
applications to run (though this is not recommended).
We hope the new system we are currently integrating into a current kernel
is as flexible as we are expecting from our tests in usermode and with
modules in a stock-kernel.

So anybody interested in some our project is invited to browse our webpages
and if (s)he feels interested, join our efforts.

CU, Andy

-- 
Andreas Beck              |  Email :  <becka@sunserver1.rz.uni-duesseldorf.de>
===  World-Wide-Web URL :  http://sunserver1.rz.uni-duesseldorf.de/~becka  ===
========  GGI - The Right Thing To Do : http://synergy.foo.net/~ggi/  ========