Provided by: libsvga1_1.4.3-31_i386 bug

NAME

       svgalib.faq - frequently asked questions about svgalib

INTRODUCTION

       I  (Matan  Ziv-Av),  added/changed some of the answers in this file, so
       some answers are mine, and some are Michael's.

       List of (recently) frequently asked questions about svgalib. Esp. about
       it's status and future. Please note that as of now all answers are just
       written by me, Michael Weller <eowmob@exp-math.uni-essen.de>. I'd  like
       this to change. So email your suggestion (best of all: question and the
       answer).

       Also, most questions deal with the status and future and my ideas about
       it.  Necessarily  they  contain my own private opinions on this. People
       may disagree and I'm sure I don't have the best ideas about it  or  may
       even  be  completely  wrong. I don't want to force anyone to agree with
       me.

       Also, I was asked about MY opinions, so I'm just presenting them here.

CONTENTS

       Q 1)   I  want  to  write  some  svgalib  application.  Where  is   the
              documentation?

       Q 2)   My board is not supported. What now?

       Q 3)   I get:

              You must be the owner of the current console to use svgalib.
              Not  running  in  a graphics capable console, and unable to find
              one.

              However, though logged in not directly from the linux console, I
              am the owner of the console.

       Q 4)   Is svgalib dead?

       Q 5)   There are so many Xfree drivers, why not just use them.

       Q 6)   Why not just use the VGA BIOS?.

       Q 7)   What about GGI?

       Q 8)   Why not just use X11?

       Q 9)   Now, again, what about the future of svgalib?

       Q 10)  Ok,  just  for  completeness,  what are your plans about svgalib
              anyway?

       Q 11)  Nice plan. But will it become true?

THE QUESTIONS

   Q 1)
       I want to write some svgalib application. Where is the documentation?

   A a)
       Well, did you really look at everything? The 0-README file in  the  top
       level  directory  contains  all function prototypes and explanations on
       how to call them.

       Yes, the documentation is short and/or confusing. Sorry, English is not
       my  native  tongue.  Many people complain and want to write some better
       documentation. You are welcome to do so! However,  up  to  now,  either
       people  found  the  documentation  sufficient  once  they looked at the
       correct files or they just gave up. At least, I never heard from  these
       people again.

       Also, svgalib comes with source. If in doubt: read it.

       Finally:  Linux  distributions  include svgalib, but not the source and
       README's (or hide them so good noone finds them). Well, no problem, get
       full svgalib source, demos, readme's from svgalib-*.tar.gz on any Linux
       FTP server in your vicinity. Even if  you  don't  dare  to  install  or
       compile it, it contains the readme's.

       Oh  yes,  there are some simple demos in the demos/ subdir. They should
       get you started.

       When someone writes man(1) manual  pages,  a  distribution  might  just
       install them. Please do not complain, write them, mail them to me.

   A b)
       Finally,  I,  Michael  Weller wrote the manpages. Looking at svgalib(7)
       should get you started. Additions and corrections are still welcome, of
       course.

   Q 2)
       My board is not supported. What now?

   A)
       Simple:

       a)     Contact  the  maintainers  (see other README's) and check out if
              someone is working on a driver.

       b)     If so, contact them if you like and announce you'd be willing to
              test things or even help coding.

       c)     If  not,  write  a  driver. Get as many docs on your card as you
              can, then read and understand the internals  of  svgalib  (again
              read the README's carefully!).

       Please  understand that this is a free project. I will not go and buy a
       similar card and write a driver for you. I already  wrote  support  for
       the  hardware  I  have!  I just do this as a hobby. Because I don't get
       paid for this I can not just buy card & docu and spend much  much  time
       supporting whatever graphics card on earth exists.

       Also read below on the future of svgalib.

       If you don't feel able to write a driver for whatever reason, please do
       not complain if other people don't do it for you (because you  are  not
       better than they are).

   Q 3)
       I get:

       You must be the owner of the current console to use svgalib.
       Not running in a graphics capable console, and unable to find one.

       However, though logged in not directly from the linux console, I am the
       owner of the console.

   A)
       Alas, some programs use their suid root privilege  and  become  a  full
       root  owned process. svgalib thinks they are run by root which does not
       own the current console.  Defining ROOT_VC_SHORTCUT in Makefile.cfg and
       recompiling  will  allow svgalib to allocate a new VC. However, it will
       allow any person which is able to exec that program to start  in  on  a
       new  console.  Even if not logged in from the console at all. Thus, for
       security, you need to explicitly enable that root feature.

   Q 4)
       Is svgalib dead?

   A)
       This question comes up frequently esp. in recent times.

       The answer is, of course, no.

   Q 5)
       There are so many Xfree drivers, why not just use them.

   A)
       Well, actually much of the code in there is actually  already  used  by
       svgalib.  Xfree  coders worked on svgalib and vice versa. But honestly,
       do not expect that a driver from Xfree can just be  used  for  svgalib.
       The  internal  structures  of  Xfree and svgalib (and GGI) are just too
       different.  As  a  source  of  knowledge  and  for  one  or  the  other
       subroutine, the Xfree sources are invaluable however.

   Q 6)
       Why not just use the VGA BIOS?.

   A)
       Actually,  we  do.  There  is  now,  thanks  to Josh Vanderhoof, a VESA
       driver.  The VESA driver does not work on all  cards,  even  though  it
       should.   It  does  not  even work on all cards where vbetest works. If
       vbetest does not work it means the bios writers assumed it would always
       run  in  DOS,  and  used tricks (for delay, etc.) that can't work under
       Linux. If vbetest works, but the VESA driver does not, I (Matan Ziv-Av)
       believe it is due to the following reason: The driver use VESA function
       4 (save/restore  video  state).  This  function  can't  be  used  in  a
       singletasking  environment  (DOS) and as such, some bios writers failed
       to implement it properly, and all the tests (which are run  under  DOS)
       failed to discover this.

       The VESA driver does work with many cards though.

   Q 7)
       What about GGI?

   A)
       Yes,  GGI.  Another long story. At first: Yes, I like the idea of an in
       kernel graphics driver. I like it very much. And, yes, this  is  a  bit
       weird  because  I am the svgalib maintainer and a working GGI will make
       svgalib obsolete. Again, I already said above: I did not invent svgalib
       nor  do I promote it as the solution (now compare this to GGI). It just
       does what it does and works for me and some other people.

       I liked this idea so much, I even started coding a frame buffer  device
       once.  After  a  short  time,  other people came out with the GGI idea.
       Right from their beginning they  claimed  to  be  the  only  source  of
       wisdom. I tried to join our efforts, but failed. In general we have the
       same goals (read the GGI project pages for that).

       Anyhow, at that time a flame war started. I don't really  know  why.  I
       don't  see  I  did  anything  else  than offering my opinions, work and
       experience. But that should be judged by others.

       Well, after some time I stopped bothering  them.  I  was  satisfied  to
       learn  later  though that they actually came up with some conclusions I
       proposed first but weeks or months later. But let  us  leave  the  past
       alone.

       When  intending  to  contribute to svgalib, you should think about what
       you really want. I don't see that GGI is becoming available  soon.  GGI
       people  told me the opposite again and again, ok, I still don't see it.
       Still out of a sudden, everything might be GGI infested, so  you  might
       consider contributing to GGI instead.

       With  svgalib  you might be able to use your fruits earlier. And anyone
       (with  supported  hardware)  can  just  use  it  right   away   without
       reinstalling  kernel/X11 what else (maybe being unable to use something
       he did before).

   Q 8)
       Why not just use X11?

       Yes, this is what many people say. This is the common Unix  way  to  do
       it.  X does it.

       But X has some drawbacks:

       i)     It  uses  many  resources. Admittedly this is becoming of lesser
              importance now, where you can run a sensible X11 Linux system on
              8MB  (16  MB  for heaven like performance) which is the absolute
              minimum to get a simple text editor running under M$ windows.

              Still, an advantage of Linux is the ability to use old  hardware
              for    mission    critical    background   jobs   on   the   net
              (servers/routers/firewalls)  on  low  price  or  otherwise  even
              unusable hardware.

       ii)    X  has  a  nice  API with draw commands for any kind of 'command
              oriented' screen output. I mean with that: Select a color,  draw
              a line, polygon, etc.

              This imposes a bunch of overhead. If you just want access to the
              screen memory, it slows things down as hell. If you want just to
              use above's draw commands, it is ok!

       iii)   One  can  now  circumvent the API restrictions by getting direct
              screen access using a special Xfree extension.  Basically  Xfree
              just setups the screen and gives you shared memory access to the
              screen memory. IMHO, this is not much different from the  shared
              memory  X11 extension by MIT (which is probably why it was added
              so easily).  Still it needs quite some overhead, at  least  when
              the card does not allow for a linear frame buffer.

              However,  you cannot change screen modes and rez as easily. This
              is IMHO THE drawback of X. For a picture viewer,  you  want  256
              color high/true color modes on a per picture basis (also, insert
              any other application you like: movie viewers, a special game, a
              drawing  program).  Also, you want a small picture use a low rez
              s.t. it does not appear as a thumbnail, maybe  use  a  high  rez
              mode  for  a  huge  picture  which  you  don't  want to use on a
              permanent basis because it flickers like  hell  (and  you  don't
              want  to  use  a  panning  virtual  desktop too, I hated them at
              best).

              This  latter  restriction  can  of  course  be  circumvented  by
              enlarging  the  picture.  But  this  will  need  much time for a
              picture viewer already and certainly too much for  smooth  video
              or game animations.

       iv)    Finally,  the  problem how X11 itself accesses the screen is not
              solved.  Security is usually no concern because X11 does it,  is
              a trusted executable and a firewall between applications and the
              hardware.

              Alas, there might be security  holes,  also  the  stability  and
              performance  issues  (IRQ  driven accelerator queue, CPU support
              for VGA memory paging) still exist, though  one  can  expect  an
              Xserver to be a generally well coded application.

   Q 9)
       Now, again, what about the future of svgalib?

       For  console  graphics,  svgalib  is  still  the only solution for most
       people, and as such it should go on for a while. Compared to  the  othe
       console  graphics  options  (kgi and kernel fb device), writing svgalib
       driver is the simplest (at least, this is my  experience),  and  so  it
       makes  sense to believe that svgalib will work on all cards where there
       is someone interested enough in that support.

   Q 10)
       Ok, just for completeness, what are your plans about svgalib anyway?

       First, make svgalib cooperate nicely with kernel fb device.  Then  (and
       it should be very similar) make svgalib work on a secondary vga card.

       A  rewrite of the code for memory handling and virtual console handling
       is necessary for the previous goals, but is also necessary  in  itself,
       and so will be done also.

       I  do  intend  to maintain complete binary compatibility, so that older
       programs will go on working.

       As internal changes are made, the drivers have to be changed  as  well.
       For  some  of  the  older drivers (ali, ark, ati, et3000, et4000, gvga,
       oak), I no longer get any reports, so I don't know if they still  work.
       Some  features  are also lost, for example, linear frame buffer on non-
       PCI cards. This should not be a very big problem, as  users  with  such
       cards  can  go  on  using 1.3.1, as most changes are not applicable for
       older machines.

SEE ALSO

       svgalib(7), libvga.config(5).

AUTHOR

       This file was written by Michael Weller <eowmob@exp-math.uni-essen.de>,
       And later changed by Matan Ziv-Av.