Provided by: libsvga1-dev_1.4.3-31_i386 bug


       vga_setlinearaddressing - switch to linear addressing mode


       #include <vga.h>

       int vga_setlinearaddressing(void);


       Switch  to  linear addressing mode. This maps all (or most) of the SVGA
       memory at the  position  returned  by  vga_getgraphmem(3)  (which  will
       probably   change  by  the  call  to  vga_setlinearaddressing()).   The
       vga_set*page(3) calls are no  longer  required.  This  ensures  optimal
       performance,  however  the  drawing functions of svgalib do not support
       this memory layout and not all cards support it (and not in all modes).

       Use vga_modeinfo(3) to check for availability  of  the  function  in  a
       given mode.

       Furthermore,  some  cards  (Cirrus)  just enable this buffer at a fixed
       hardware address.  For Cirrus it is mapped at 14MB so you should  never
       used  it  if  you  have  more  than  14MB  of  memory  (But how does an
       application know?).  The Mach32 support for this is smarter.  It  makes
       this feature only available when it is safe to be used.

       To avoid all this problems you can use

              Inhibit use of a linear mmaped frame buffer.

       linear Allow (not enforce!) use of a linear mmaped frame buffer.

       in  the  /etc/vga/libvga.config file to disable the linear frame buffer
       if it cannot be used.

       Returns the size of the mapped framebuffer if successful (can  be  less
       than total video memory), -1 if not.

       The  testlinear(6)  demo shows the use of this feature (and if it works
       for you).


       svgalib(7), vgagl(7), libvga.config(5), testlinear(6), vga_modeinfo(3),
       vga_getgraphmem(3),         vga_setpage(3),         vga_setreadpage(3),
       vga_setwritepage(3), vga_setlinearaddressing(3)


       This manual page was edited  by  Michael  Weller  <eowmob@exp-math.uni->.  The  exact  source of the referenced function as well as of
       the original documentation is unknown.

       It is very likely that both are at least to some extent are due to Harm
       Hanemaayer <>.

       Occasionally  this  might be wrong. I hereby asked to be excused by the
       original author and will happily accept any additions or corrections to
       this first version of the svgalib manual.