display-memory

Section: GGI (7)
Updated: 2004-10-14
Page Index

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.