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.