HP-UX Reference (11i v2 07/12) - 7 Device (Special) Files, 9 General Information, Index (vol 10)

f
framebuf(7) framebuf(7)
GCUNLOCK request is made will not have any effect on these blocked signals. The
signals are not blocked until the lock is actually acquired, and might be received while
still awaiting the lock.
The signal SIGTSTP is also blocked whether or not it is being caught. The signals
SIGTTIN and SIGTTOU are also blocked on frame-buffer devices where the ITE does
not output to the device while it is locked. See DEPENDENCIES below.
Except for the three signals mentioned above, this call does not block signals that the
process did not expect to catch, nor does it block signals that cannot be caught or
ignored. This command does not prevent other non-cooperating processes from writ-
ing to the frame buffer.
GCLOCK_BLOCKSIG_NOWAIT
Provide for exclusive use of the frame-buffer device by cooperating processes, while
blocking all incoming signals for the calling process that otherwise would have been
caught. This request has the same effect on the frame-buffer device as does the
GCLOCK_BLOCKSIG
request. However, this call does not wait for the frame buffer
to be released by other processes. If the frame-buffer device is locked, the process is
not blocked, but the system call returns an error and causes
errno to be set to
[EAGAIN]. The parameter arg is ignored and should be set to 0.
GCUNLOCK Relinquish exclusive use of the frame-buffer device. If the device is locked with a
GCLOCK_BLOCKSIG or GCLOCK_BLOCKSIG_NOWAIT ioctl()
request, the sig-
nal mask of the calling process is restored to its state prior to the locking request.
GCRESET Reset the graphic hardware associated with the frame-buffer device to a defined initial
state. The call enables the frame-buffer device to respond to the ioctl requests defined
here.
GCDMA_OUTPUT Send DMA output to the frame-buffer device. This system call is used to transfer data
from a user’s array to a rectangular area of the graphics frame-buffer, or optionally, to
the device’s graphics control space.
The parameters for the DMA are passed in a crt_dma_ctrl_t
data structure,
which includes the following fields:
char *mem_addr; /* Starting address of data
being transferred */
char *fb_addr; /* Address of framebuffer
destination */
int length; /* Number of bytes to transfer,
including those "skipped" */
int linelength; /* Number of bytes written
on each framebuffer row */
int skipcount; /* Number of source bytes to
ignore after each "linelength" */
unsigned int flags; /* Specified options to the driver */
To write to the graphics frame-buffer, set
fb_addr to the address of the upper-left
corner of the rectangle to be drawn. The DMA will write linelength bytes on
each frame-buffer row, ignore the next skipcount bytes of memory data, then
resume writing at the same starting position on each succeeding frame-buffer row.
This is continued until length bytes are either written or ignored.
To write to the graphics control space, set fb_addr to the address of the first
graphics control register to write. In this case, linelength and skipcount are
ignored.
The flags parameter specifies options for the DMA. Currently, there are no sup-
ported flags and this parameter should be set to zero, otherwise the system call will
fail and errno is set to [EINVAL].
The DMA has the same effect on the frame-buffer device as using store instructions to
write the data. Thus, various graphics control registers may affect the results of the
DMA. It is the responsibility of the user program to perform any necessary set-up of
the frame-buffer device so that the DMA has the desired results.
50 Hewlett-Packard Company − 3 − HP-UX 11i Version 2: December 2007 Update