Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
svgalib.faq(7)		      Svgalib User Manual		svgalib.faq(7)

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  documen-
	      tation?

       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 cor-
       rect 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  com-
       pile 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  in-
       stall 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  subrou-
       tine, 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  single-
       tasking	environment (DOS) and as such, some bios writers failed	to im-
       plement 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  wis-
       dom.  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 expe-
       rience. 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	 rein-
       stalling	 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 unus-
	      able 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	perma-
	      nent 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 enlarg-
	      ing 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 per-
	      formance 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  peo-
       ple, and	as such	it should go on	for a while. Compared to the othe con-
       sole 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.

Svgalib	1.4.1			  10 Jun 1999			svgalib.faq(7)

NAME | INTRODUCTION | CONTENTS | THE QUESTIONS | SEE ALSO | AUTHOR

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=svgalib.faq&sektion=7&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help