Lines Matching refs:and

11 with frame buffer devices. In-kernel APIs between device drivers and the frame
15 behaviours differ in subtle (and not so subtle) ways. This document describes
23 Device and driver capabilities are reported in the fixed screen information
33 expect from the device and driver.
42 2. Types and visuals
49 Formats are described by frame buffer types and visuals. Some visuals require
51 bits_per_pixel, grayscale, red, green, blue and transp fields.
53 Visuals describe how color information is encoded and assembled to create
55 types and visuals are supported.
63 Padding at end of lines may be present and is then reported through the fixed
92 Pixels are black or white and stored on a number of bits (typically one)
95 Black pixels are represented by all bits set to 1 and white pixels by all bits
103 Pixels are black or white and stored on a number of bits (typically one)
106 Black pixels are represented by all bits set to 0 and white pixels by all bits
114 Pixels are broken into red, green and blue components, and each component
116 are device-dependent, and provide linear or non-linear ramps.
119 information red, green, blue and transp fields.
121 - FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
123 Pixel values are encoded as indices into a colormap that stores red, green and
125 and read-write for FB_VISUAL_PSEUDOCOLOR.
132 Pixels are broken into red, green and blue components, and each component
136 information red, green, blue and transp fields.
140 Pixels are encoded and  interpreted as described by the format FOURCC
148 and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
149 fb_fix_screeninfo and fb_var_screeninfo structure respectively.
152 about the frame buffer device and the current format. Those information can't
178 about a frame buffer device, its current format and video mode, as well as
226 applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
234 legacy API and the FOURCC-based API.
238 long time and is thus widely used by application. It is the recommended API
239 for applications when using RGB and grayscale formats, as well as legacy
247   blue, green and transp fields must be set to 0 by applications and ignored by
248   drivers. Drivers must fill the red, blue and green offsets to 0 and lengths
252   red, blue, green and transp fields must be set to 0 by applications and
253   ignored by drivers. Drivers must fill the red, blue and green offsets to 0
254   and lengths to the bits_per_pixel value.
256 - For truecolor and directcolor formats, applications set the grayscale field
257   to zero, and the red, blue, green and transp fields to describe the layout of
267   Pixel values are bits_per_pixel wide and are split in non-overlapping red,
268   green, blue and alpha (transparency) components. Location and size of each
269   component in the pixel value are described by the fb_bitfield offset and
277 type, visual and line_length fields depending on the selected format.
284 and grayscale formats.
289 FOURCC definitions are located in the linux/videodev2.h header. However, and
291 and don't require usage of the V4L2 subsystem. FOURCC documentation is
296 the colorspace field to one of the colorspaces listed in linux/videodev2.h and
299 The red, green, blue and transp fields are not used with the FOURCC-based API.
300 For forward compatibility reasons applications must zero those fields, and
305 type, visual and line_length fields depending on the selected format. The type
306 and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.