Provided by: libggi2_2.2.2-5ubuntu2_amd64 bug

NAME

       display-memory - Display on buffer in main memory

SYNOPSIS

       display-memory: [-input] [-noblank]
                       [-layout=<fstride>[[plb<lstride>]|[plan<pstride>,<plstride>]]]
                       [-physz=<sizex>,<sizey>[dpi]] [-pixfmt=<format_string>]
                       [ [shmid:<sid> ] | [keyfile:<size>:<id>:<fname>] | pointer ]

DESCRIPTION

       Emulates  a  linear  framebuffer  in  main  memory. The framebuffer can be a shared memory
       segment, an area specified by the application, or  an  area  allocated  by  display-memory
       itself.

OPTIONS

       -input If  the -input option is set, an input buffer of INPBUFSIZE (default is 8192 bytes)
              as #define'd in ggi/display/memory.h is allocated at the  start  of  the  requested
              memory area.

              When  running  on  shared  memory,  this  option  enables  you to give input (using
              giiEventSend(3)) to  other  processes  sharing  that  segment.  This  technique  is
              demonstrated in cube3d(1) and can be used for things like GGI multiplexers.

       -noblank
              If  the -noblank option is set, the framebuffer will not be filled with solid black
              when the mode of the visual is set.  This is useful for preserving data from  other
              sources when using a preallocated area of memory as a framebuffer.

       -physz=<sizex>,<sizey>[dpi]
              This  option  will  provide  a  physical screen size for applications which wish to
              remain resolution independent.  sizex, sizey are the x,y  size  of  the  screen  in
              millimeters,  unless  the  optional  dpi  string  is  affixed,  in which case, they
              represent resolution in dots-per-inch.

       -pixfmt=<format_string>
              This option will provide a non-default  pixel  format  explicitly.   Currently  the
              accepted  format of format_string is something like "r5b5g5p1", which would specify
              a pixel where the low bit of the pixel is unused padding, followed  by  5  bits  of
              green, then 5 bits of blue and finally 5 bits of red, with the remaining high bits,
              if any, being unused pad. A more formal description of this format string  will  be
              provided (and more strings accepted) in future LibGGI releases.

       [-layout=<fstride>[[plb<lstride>]|[plan<pstride>,<plstride>]]]
              This  option will provide a non-default framebuffer layout explicitly.  The fstride
              parameter denotes the number of bytes between frames in the framebuffer,  and  will
              default  to  the  size  of  the  virtual screen in bytes if nonpresent or set to 0.
              Following fstride, the string plb denotes a linear packed-pixel framebuffer, or the
              string  plan  instead  denotes  a planar framebuffer.  The packed-pixel framebuffer
              layout is the default.  If the string plb is present, a horizontal  stride  lstride
              may  appear,  denoting the number of bytes that elapse between the beginning of one
              line and the next.  This will default to the size of a horizontal line in bytes  if
              nonpresent  or  set  to  zero.  If the string "plan" is present, up to two numbers,
              comma separated, may appear after the string.  The first  number,  pstride  denotes
              the  number  of bytes which elapse between the beginning of one plane and the next.
              This will default to the minimum integral number of  bytes  that  may  contain  one
              bitplane  of  the  virtual screen if nonpresent or set to zero.  The second number,
              plstride denotes the number of bytes that  elapse  between  the  beginning  of  one
              bitplane-line  and  the  next.  This will default to the minimum integral number of
              bytes which may contain one bitplane-line of the virtual screen  if  nonpresent  or
              set to zero.

              More strings and format parameters may accepted in future LibGGI releases.

       shmid:<sid>
              use existing shared memory ID sid

              On  win32,  sid  is  the  HANDLE returned by a call to CreateFileMapping in decimal
              form.

       keyfile:<size>:<id>:<fname>
              create a new shm segment with id ftok(fname,id) of size size (preferred method  !).
              See ftok(3).

              On win32, the newly created shared memory mapping has the object name: ggi-display-
              memory-shm:<fname>:<ascid>, where all backslashes have been  converted  to  forward
              slashes  in  fname  and  ascid  is  the ascii value of id in decimal form.  If this
              object does already exist (and is a file mapping) it will be used, so two apps  can
              share memory by using the same keyfile arguments on win32.

       pointer
              use  the  memory  pointed  to  by  argptr  (only  available to applications calling
              ggiOpen(3)).

              Important: If you specify a memory area to use - be sure  it's  big  enough  as  no
              checks can or will be made that a certain mode fits into it.

FEATURES

       ·   DirectBuffer support always available.

       ·   Unaccelerated.