Lines Matching refs:and

12 with frame buffer devices. In-kernel APIs between device drivers and the frame
16 behaviours differ in subtle (and not so subtle) ways. This document describes
24 Device and driver capabilities are reported in the fixed screen information
34 expect from the device and driver.
43 2. Types and visuals
50 Formats are described by frame buffer types and visuals. Some visuals require
52 bits_per_pixel, grayscale, red, green, blue and transp fields.
54 Visuals describe how color information is encoded and assembled to create
56 types and visuals are supported.
64 Padding at end of lines may be present and is then reported through the fixed
93 Pixels are black or white and stored on a number of bits (typically one)
96 Black pixels are represented by all bits set to 1 and white pixels by all bits
104 Pixels are black or white and stored on a number of bits (typically one)
107 Black pixels are represented by all bits set to 0 and white pixels by all bits
115 Pixels are broken into red, green and blue components, and each component
117 are device-dependent, and provide linear or non-linear ramps.
120 information red, green, blue and transp fields.
122 - FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
124 Pixel values are encoded as indices into a colormap that stores red, green and
126 and read-write for FB_VISUAL_PSEUDOCOLOR.
133 Pixels are broken into red, green and blue components, and each component
137 information red, green, blue and transp fields.
141 Pixels are encoded and  interpreted as described by the format FOURCC
149 and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
150 fb_fix_screeninfo and fb_var_screeninfo structure respectively.
153 about the frame buffer device and the current format. Those information can't
179 about a frame buffer device, its current format and video mode, as well as
227 applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
235 legacy API and the FOURCC-based API.
239 long time and is thus widely used by application. It is the recommended API
240 for applications when using RGB and grayscale formats, as well as legacy
248   blue, green and transp fields must be set to 0 by applications and ignored by
249   drivers. Drivers must fill the red, blue and green offsets to 0 and lengths
253   red, blue, green and transp fields must be set to 0 by applications and
254   ignored by drivers. Drivers must fill the red, blue and green offsets to 0
255   and lengths to the bits_per_pixel value.
257 - For truecolor and directcolor formats, applications set the grayscale field
258   to zero, and the red, blue, green and transp fields to describe the layout of
268   Pixel values are bits_per_pixel wide and are split in non-overlapping red,
269   green, blue and alpha (transparency) components. Location and size of each
270   component in the pixel value are described by the fb_bitfield offset and
278 type, visual and line_length fields depending on the selected format.
285 and grayscale formats.
290 FOURCC definitions are located in the linux/videodev2.h header. However, and
292 and don't require usage of the V4L2 subsystem. FOURCC documentation is
297 the colorspace field to one of the colorspaces listed in linux/videodev2.h and
300 The red, green, blue and transp fields are not used with the FOURCC-based API.
301 For forward compatibility reasons applications must zero those fields, and
306 type, visual and line_length fields depending on the selected format. The type
307 and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.