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.