Provided by: libsvga1-dev_1.4.3-24_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.