fbio(7i) [opensolaris man page]
fbio(7I) Ioctl Requests fbio(7I) NAME
fbio - frame buffer control operations DESCRIPTION
The frame buffers provided with this release support the same general interface that is defined by <sys/fbio.h>. Each responds to an FBIOG- TYPE ioctl(2) request which returns information in a fbtype structure. Each device has an FBTYPE which is used by higher-level software to determine how to perform graphics functions. Each device is used by opening it, doing an FBIOGTYPE ioctl() to see which frame buffer type is present, and thereby selecting the appropriate device-management routines. FBIOGINFO returns information specific to the GS accelerator. FBIOSVIDEO and FBIOGVIDEO are general-purpose ioctl() requests for controlling possible video features of frame buffers. These ioctl() requests either set or return the value of a flags integer. At this point, only the FBVIDEO_ON option is available, controlled by FBIOSVIDEO. FBIOGVIDEO returns the current video state. The FBIOSATTR and FBIOGATTR ioctl() requests allow access to special features of newer frame buffers. They use the fbsattr and fbgattr structures. Some color frame buffers support the FBIOPUTCMAP and FBIOGETCMAP ioctl() requests, which provide access to the colormap. They use the fbcmap structure. Also, some framebuffers with multiple colormaps will either encode the colormap identifier in the high-order bits of the "index" field in the fbcmap structure, or use the FBIOPUTCMAPI and FBIOGETCMAPI ioctl() requests. FBIOVERTICAL is used to wait for the start of the next vertical retrace period. FBIOVRTOFFSET Returns the offset to a read-only vertical retrace page for those framebuffers that support it. This vertical retrace page may be mapped into user space with mmap(2). The first word of the vertical retrace page (type unsigned int) is a counter that is incre- mented every time there is a vertical retrace. The user process can use this counter in a variety of ways. FBIOMONINFO returns a mon_info structure which contains information about the monitor attached to the framebuffer, if available. FBIOSCURSOR, FBIOGCURSOR, FBIOSCURPOS and FBIOGCURPOS are used to control the hardware cursor for those framebuffers that have this fea- ture. FBIOGCURMAX returns the maximum sized cursor supported by the framebuffer. Attempts to create a cursor larger than this will fail. Finally FBIOSDEVINFO and FBIOGDEVINFO are used to transfer variable-length, device-specific information into and out of framebuffers. SEE ALSO
ioctl(2), mmap(2), cgsix(7D) BUGS
The FBIOSATTR and FBIOGATTR ioctl() requests are only supported by frame buffers which emulate older frame buffer types. If a frame buffer emulates another frame buffer, FBIOGTYPE returns the emulated type. To get the real type, use FBIOGATTR. The FBIOGCURPOS ioctl was incorrectly defined in previous operating systems, and older code running in binary compatibility mode may get incorrect results. SunOS 5.11 12 May 2003 fbio(7I)
Check Out this Related Man Page
nbuf(4) Kernel Interfaces Manual nbuf(4) Name nbuf - select multiple-buffer operation to a raw device Syntax #include <sys/ioctl.h> ioctl(d, FIONBUF, count) int d; int *count; status=ioctl(d, FIONBDONE, buffer) int d, status; char **buffer; Description The I/O operations to raw devices are usually performed through a single buffer. This means that the issuing process must wait for a buffer to complete before the process can do anything else. An N-buffered I/O operation allows a process to begin an I/O operation and continue doing something else until the operation has finished. Once N-buffered operation is enabled, and acts as before except that buffer comple- tion is not guaranteed when the call returns. If the operation starts without errors, and return as if the operation were successful. That is, the number of requested bytes have transferred and file pointers are updated. On read operations, the process must not use the contents of the started buffer until the buffer actually completes. On write operations, the process must not reuse the buffer until the operation actually completes. A second is used to check the status of previously issued N-buffered read/write requests to determine when the operation has really completed. N-buffered I/O is used through a set of calls. Setting the request argument in an call to FIONBUF enables count buffers to be used with the raw device associated with the file descriptor d. If count is zero, the N-buffered operation is terminated and any pending buffers are completed. A count less than zero is invalid. Any started I/O buffer's status is checked by the call with the request argument set to FIONBDONE, with the address of the buffer used as an argument. The status field returns the actual byte count transferred or any error encountered on the I/O operation. The FIONBDONE ioctl must be called before re-using a buffer. FIONBDONE blocks the process until the given buffer completes (unless FNDELAY has been specified with at which point EWOULDBLOCK is returned). In addition, a signal can be generated whenever a buffer completes, if FIOASYNC has been specified with The call is also useful in checking on the status of pending buffers. The call returns immediately if less than count operations have been started on an N-buffered channel. Otherwise, blocks the specified amount of time for a buffer to become done. At this point, FIONBDONE must be used to return actual status of the pending buffer. Diagnostics The call fails if one or more of the following are true: [EBADF] The d argument is not a valid descriptor. [ENOTTY] The d argument is not associated with a character special device. [ENOTTY] The specified request does not apply to the kind of object which the descriptor d references. [EINVAL] The request or argp argument is not valid. Returned for FIONBDONE, if requested buffer was never started. Also returned for FIONBUF, if this device does not support N-buffered I/O. See Also fcntl(2), ioctl(2), select(2) nbuf(4)