[469] in linux-announce channel archive
New approach for a general graphics interface
daemon@ATHENA.MIT.EDU (Lars Wirzenius)
Mon Apr 17 12:40:38 1995
Date: Mon, 17 Apr 1995 17:19:12 +0300
From: Lars Wirzenius <wirzeniu@cc.helsinki.fi>
To: linux-activists@niksula.hut.fi, linux-announce@vger.rutgers.edu
X-Mn-Key: announce
Subject: New approach for a general graphics interface
From: becka@hp817S.rz.uni-duesseldorf.de
Newsgroups: comp.os.linux.announce
Keywords: graphics, X11, svgalib, kernel, driver
Organization: ?
Approved: linux-announce@news.ornl.gov (Lars Wirzenius)
Followup-to: comp.os.linux.development.system
Hello Folks !
-------------
This is a new approach to create something like a GDI (General Display
Interface) for Linux.
We all know that it is a real mess to work with lots of different graphics
and textmode systems all on the same Linux console :
There is XFree with its own (complicated) config and Svgalib with another
one and SVGATextMode with yet another.(Not to mention DOSEMU using the
cards BIOS).And there are several "special" applications (like vgamp) out
there that use their own approach ...
They all bring along their own drivers (though source is quite the same, as
one adapts it from the other ...) and they do not interact nicely at all
times ...
This is the reason, why I wanted to create a new interface that all systems
could depend on and request all the graphics services they need from.
There were some major flaws in the existing systems that I really wanted to
have corrected:
1. All graphics programs needed to be suid-root, as they needed to used the
iopl()-call which is super-user only.I deem this to be a major security
risk,as I personally would not like to install such a program from a
binary-only distribution,while binary-only is necessary for commercial
purposes (e.g. DOOM, ...).
2. Ease of configuration <=> optimal usage of system ressources
While svgalib is easy to configure,it does not use the system at the
edge of its capabilities - most modes run with quite low refresh-rates.
On the other hand XFree allows you to configure the system according
to its limits,but the config-file is VERY hard to setup for the beginning
user.
3. No "central" control over the graphics,resulting in problems when
switching between vts with different graphics-packages running.
4. Special servers for accelerated cards (XFree) or only limited
acceleration support (svgalib)
(NOTE: ALL THE MENTIONED PROGRAMS/SYSTEMS ARE GREAT AND I DO NOT WANT TO
FLAME ANYONE WITH THE ABOVE STATEMENTS !)
My approach tries to overcome these limitations/problems by the following
concepts:
1. The graphics-subsystem is installed as several KLMs (kernel loadable module)
what results in :
a) no need for suid-programs,access permissions for the graphics-device
will be sufficient,thus allowing control over who has access to
graphics-mode applications.
b) all graphics/text-modes on all VTs will be controlled from a central
authority,thus guaranteeing perfect interaction.
c) easy configuration by choosing the right modules (one for the monitor,
one or more for the graphics-card) while still using the hardware
at its limits (thus the monitor-driver !).
2. An open interface to the driver via the graphics library:
The library will first ask the driver to do a requested task (like
drawing a filled box) on its own.If the driver is capable of doing
so (i.e. it has an optimized function for that,maybe the hardware can
do it all by itself) it will service the request and everything is done.
If it cannot it will an error return to the library, stating that it is
not capable to do a DrawBox either in this mode (thus the library will
retry when modes have changed) or in any case (so the library will never
retry).
In these cases the driver will try to emulate the function by reverting
to more primitive functions - in this case e.g. to draw lots of horizontal
lines.This function will then be handled as above - either by the driver
or the library will use even more primitive functions (like SetDot) to
fulfill the request.
As a consequence from this architecture, the driver will not need to
support hundreds of "standard" algorithms (such as e.g. Bresenham for
line-drawing),if there is no need to do so,as the library would use
it anyway,when the driver says "DrawLine-unsupported".
On the other hand one can implement any standard drawing-function in
the driver,if it seems a good idea,because there is special support
for the function by the chipset.
The drawback is a slight loss of speed, as every call to a graphics-
function will include a "switch()"-statement that chooses whether to
check the function for availability (once only,the function will be
performed,if successful), or tho use the driver-funtion or to emulate
it. I consider this to be quite unimportant as a calculated jump does
not need that much time.
3. A really COMPLETE graphics library that will be put together from the
XFree and Svgalib sources (and anything else we find useful) so that
EVERY application will find what it needs in this library.
I do NOT want the old mess of everybody doing its own job to turn up
again - the new interface should be easy to integrate into all major
graphics packages - in the best case only a small "compatibility-
library" should be needed to fuse the worlds together.
So now let's come to the point of it - why all this talk ?
=====================================
I NEED YOUR HELP !
==================
The package that I just uploaded to tsx.mit.edu (scrdrv.tgz - it will
probably soon be found in /pub/linux/ALPHA/??? ) is FAR from completeness.
I am NO graphics-wizard - in fact most of the code in this package is stolen
from other packages (see CREDITS).
So I need volunteers for the following tasks:
1. Creating/improving drivers for all major graphics-cards. For most
unaccelerated cards this should be quite easy and maybe I do one for
the TVGA8900 Chipset myself, as I have such a card in my secondary
system.
2. Creating drivers or config-files (if someone builds a configurable driver)
for the lots of monitors out there.
3. Writing code for the graphics-library (especially emulation-code for
graphics-primitives like drawing circles,filling polygons,...)
4. Helping me to improve the interface and (URGENTLY NEEDED !) make it
faster !
5. Creating interface-libraries that will make the driver usable for
svgalib-applications.
6. Building an X-Server using the driver.
7. Creating a utility that will autodetect the hardware (if possible) and
lets you choose undetectable HW (like the monitor) from a menu or
configure new values for generic drivers.
8. Suggesting a better way to transmit commands to the driver - I suppose
ioctl() is far too slow.
9. dunno now - but I am sure I will get lots of suggestions ... :-)
So - if you feel like joining my effort - send me EMail - I will try to
coordinate the work, inform you about others that want to work on the same
task and put the results together to a useful package.
BTW: Can anybody provide a mailing list that will help to coordinate our
efforts and keep everybody "up-to-date" ?
I am sorry,but I cannot do this myself, as my machine is only on the net
via a dialup SLIP connection and thus not always available.
Thanks in advance to all who want to help !
Andy
--
==============================================================================
Andreas Beck | Email : <becka@hp.rz.uni-duesseldorf.de>
Zur Goetscher Muehle 25 | Phone : +49 2173 72916
D-40764 Langenfeld | Fax : +49 2173 83563
==============================================================================
--
Send submissions for comp.os.linux.announce to: linux-announce@news.ornl.gov
PLEASE remember Keywords: and a short description of the software.
