1ab42b818SMauro Carvalho Chehab=========================== 2ab42b818SMauro Carvalho ChehabThe Frame Buffer Device API 3ab42b818SMauro Carvalho Chehab=========================== 4ab42b818SMauro Carvalho Chehab 5ab42b818SMauro Carvalho ChehabLast revised: June 21, 2011 6ab42b818SMauro Carvalho Chehab 7ab42b818SMauro Carvalho Chehab 8ab42b818SMauro Carvalho Chehab0. Introduction 9ab42b818SMauro Carvalho Chehab--------------- 10ab42b818SMauro Carvalho Chehab 11ab42b818SMauro Carvalho ChehabThis document describes the frame buffer API used by applications to interact 12ab42b818SMauro Carvalho Chehabwith frame buffer devices. In-kernel APIs between device drivers and the frame 13ab42b818SMauro Carvalho Chehabbuffer core are not described. 14ab42b818SMauro Carvalho Chehab 15ab42b818SMauro Carvalho ChehabDue to a lack of documentation in the original frame buffer API, drivers 16ab42b818SMauro Carvalho Chehabbehaviours differ in subtle (and not so subtle) ways. This document describes 17ab42b818SMauro Carvalho Chehabthe recommended API implementation, but applications should be prepared to 18ab42b818SMauro Carvalho Chehabdeal with different behaviours. 19ab42b818SMauro Carvalho Chehab 20ab42b818SMauro Carvalho Chehab 21ab42b818SMauro Carvalho Chehab1. Capabilities 22ab42b818SMauro Carvalho Chehab--------------- 23ab42b818SMauro Carvalho Chehab 24ab42b818SMauro Carvalho ChehabDevice and driver capabilities are reported in the fixed screen information 25ab42b818SMauro Carvalho Chehabcapabilities field:: 26ab42b818SMauro Carvalho Chehab 27ab42b818SMauro Carvalho Chehab struct fb_fix_screeninfo { 28ab42b818SMauro Carvalho Chehab ... 29ab42b818SMauro Carvalho Chehab __u16 capabilities; /* see FB_CAP_* */ 30ab42b818SMauro Carvalho Chehab ... 31ab42b818SMauro Carvalho Chehab }; 32ab42b818SMauro Carvalho Chehab 33ab42b818SMauro Carvalho ChehabApplication should use those capabilities to find out what features they can 34ab42b818SMauro Carvalho Chehabexpect from the device and driver. 35ab42b818SMauro Carvalho Chehab 36ab42b818SMauro Carvalho Chehab- FB_CAP_FOURCC 37ab42b818SMauro Carvalho Chehab 38ab42b818SMauro Carvalho ChehabThe driver supports the four character code (FOURCC) based format setting API. 39ab42b818SMauro Carvalho ChehabWhen supported, formats are configured using a FOURCC instead of manually 40ab42b818SMauro Carvalho Chehabspecifying color components layout. 41ab42b818SMauro Carvalho Chehab 42ab42b818SMauro Carvalho Chehab 43ab42b818SMauro Carvalho Chehab2. Types and visuals 44ab42b818SMauro Carvalho Chehab-------------------- 45ab42b818SMauro Carvalho Chehab 46ab42b818SMauro Carvalho ChehabPixels are stored in memory in hardware-dependent formats. Applications need 47ab42b818SMauro Carvalho Chehabto be aware of the pixel storage format in order to write image data to the 48ab42b818SMauro Carvalho Chehabframe buffer memory in the format expected by the hardware. 49ab42b818SMauro Carvalho Chehab 50ab42b818SMauro Carvalho ChehabFormats are described by frame buffer types and visuals. Some visuals require 51ab42b818SMauro Carvalho Chehabadditional information, which are stored in the variable screen information 52ab42b818SMauro Carvalho Chehabbits_per_pixel, grayscale, red, green, blue and transp fields. 53ab42b818SMauro Carvalho Chehab 54ab42b818SMauro Carvalho ChehabVisuals describe how color information is encoded and assembled to create 55ab42b818SMauro Carvalho Chehabmacropixels. Types describe how macropixels are stored in memory. The following 56ab42b818SMauro Carvalho Chehabtypes and visuals are supported. 57ab42b818SMauro Carvalho Chehab 58ab42b818SMauro Carvalho Chehab- FB_TYPE_PACKED_PIXELS 59ab42b818SMauro Carvalho Chehab 60ab42b818SMauro Carvalho ChehabMacropixels are stored contiguously in a single plane. If the number of bits 61ab42b818SMauro Carvalho Chehabper macropixel is not a multiple of 8, whether macropixels are padded to the 62ab42b818SMauro Carvalho Chehabnext multiple of 8 bits or packed together into bytes depends on the visual. 63ab42b818SMauro Carvalho Chehab 64ab42b818SMauro Carvalho ChehabPadding at end of lines may be present and is then reported through the fixed 65ab42b818SMauro Carvalho Chehabscreen information line_length field. 66ab42b818SMauro Carvalho Chehab 67ab42b818SMauro Carvalho Chehab- FB_TYPE_PLANES 68ab42b818SMauro Carvalho Chehab 69ab42b818SMauro Carvalho ChehabMacropixels are split across multiple planes. The number of planes is equal to 70ab42b818SMauro Carvalho Chehabthe number of bits per macropixel, with plane i'th storing i'th bit from all 71ab42b818SMauro Carvalho Chehabmacropixels. 72ab42b818SMauro Carvalho Chehab 73ab42b818SMauro Carvalho ChehabPlanes are located contiguously in memory. 74ab42b818SMauro Carvalho Chehab 75ab42b818SMauro Carvalho Chehab- FB_TYPE_INTERLEAVED_PLANES 76ab42b818SMauro Carvalho Chehab 77ab42b818SMauro Carvalho ChehabMacropixels are split across multiple planes. The number of planes is equal to 78ab42b818SMauro Carvalho Chehabthe number of bits per macropixel, with plane i'th storing i'th bit from all 79ab42b818SMauro Carvalho Chehabmacropixels. 80ab42b818SMauro Carvalho Chehab 81ab42b818SMauro Carvalho ChehabPlanes are interleaved in memory. The interleave factor, defined as the 82ab42b818SMauro Carvalho Chehabdistance in bytes between the beginning of two consecutive interleaved blocks 83ab42b818SMauro Carvalho Chehabbelonging to different planes, is stored in the fixed screen information 84ab42b818SMauro Carvalho Chehabtype_aux field. 85ab42b818SMauro Carvalho Chehab 86ab42b818SMauro Carvalho Chehab- FB_TYPE_FOURCC 87ab42b818SMauro Carvalho Chehab 88ab42b818SMauro Carvalho ChehabMacropixels are stored in memory as described by the format FOURCC identifier 89ab42b818SMauro Carvalho Chehabstored in the variable screen information grayscale field. 90ab42b818SMauro Carvalho Chehab 91ab42b818SMauro Carvalho Chehab- FB_VISUAL_MONO01 92ab42b818SMauro Carvalho Chehab 93ab42b818SMauro Carvalho ChehabPixels are black or white and stored on a number of bits (typically one) 94ab42b818SMauro Carvalho Chehabspecified by the variable screen information bpp field. 95ab42b818SMauro Carvalho Chehab 96ab42b818SMauro Carvalho ChehabBlack pixels are represented by all bits set to 1 and white pixels by all bits 97ab42b818SMauro Carvalho Chehabset to 0. When the number of bits per pixel is smaller than 8, several pixels 98ab42b818SMauro Carvalho Chehabare packed together in a byte. 99ab42b818SMauro Carvalho Chehab 100ab42b818SMauro Carvalho ChehabFB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only. 101ab42b818SMauro Carvalho Chehab 102ab42b818SMauro Carvalho Chehab- FB_VISUAL_MONO10 103ab42b818SMauro Carvalho Chehab 104ab42b818SMauro Carvalho ChehabPixels are black or white and stored on a number of bits (typically one) 105ab42b818SMauro Carvalho Chehabspecified by the variable screen information bpp field. 106ab42b818SMauro Carvalho Chehab 107ab42b818SMauro Carvalho ChehabBlack pixels are represented by all bits set to 0 and white pixels by all bits 108ab42b818SMauro Carvalho Chehabset to 1. When the number of bits per pixel is smaller than 8, several pixels 109ab42b818SMauro Carvalho Chehabare packed together in a byte. 110ab42b818SMauro Carvalho Chehab 111ab42b818SMauro Carvalho ChehabFB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only. 112ab42b818SMauro Carvalho Chehab 113ab42b818SMauro Carvalho Chehab- FB_VISUAL_TRUECOLOR 114ab42b818SMauro Carvalho Chehab 115ab42b818SMauro Carvalho ChehabPixels are broken into red, green and blue components, and each component 116ab42b818SMauro Carvalho Chehabindexes a read-only lookup table for the corresponding value. Lookup tables 117ab42b818SMauro Carvalho Chehabare device-dependent, and provide linear or non-linear ramps. 118ab42b818SMauro Carvalho Chehab 119ab42b818SMauro Carvalho ChehabEach component is stored in a macropixel according to the variable screen 120ab42b818SMauro Carvalho Chehabinformation red, green, blue and transp fields. 121ab42b818SMauro Carvalho Chehab 122ab42b818SMauro Carvalho Chehab- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR 123ab42b818SMauro Carvalho Chehab 124ab42b818SMauro Carvalho ChehabPixel values are encoded as indices into a colormap that stores red, green and 125ab42b818SMauro Carvalho Chehabblue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR 126ab42b818SMauro Carvalho Chehaband read-write for FB_VISUAL_PSEUDOCOLOR. 127ab42b818SMauro Carvalho Chehab 128ab42b818SMauro Carvalho ChehabEach pixel value is stored in the number of bits reported by the variable 129ab42b818SMauro Carvalho Chehabscreen information bits_per_pixel field. 130ab42b818SMauro Carvalho Chehab 131ab42b818SMauro Carvalho Chehab- FB_VISUAL_DIRECTCOLOR 132ab42b818SMauro Carvalho Chehab 133ab42b818SMauro Carvalho ChehabPixels are broken into red, green and blue components, and each component 134ab42b818SMauro Carvalho Chehabindexes a programmable lookup table for the corresponding value. 135ab42b818SMauro Carvalho Chehab 136ab42b818SMauro Carvalho ChehabEach component is stored in a macropixel according to the variable screen 137ab42b818SMauro Carvalho Chehabinformation red, green, blue and transp fields. 138ab42b818SMauro Carvalho Chehab 139ab42b818SMauro Carvalho Chehab- FB_VISUAL_FOURCC 140ab42b818SMauro Carvalho Chehab 141ab42b818SMauro Carvalho ChehabPixels are encoded and interpreted as described by the format FOURCC 142ab42b818SMauro Carvalho Chehabidentifier stored in the variable screen information grayscale field. 143ab42b818SMauro Carvalho Chehab 144ab42b818SMauro Carvalho Chehab 145ab42b818SMauro Carvalho Chehab3. Screen information 146ab42b818SMauro Carvalho Chehab--------------------- 147ab42b818SMauro Carvalho Chehab 148ab42b818SMauro Carvalho ChehabScreen information are queried by applications using the FBIOGET_FSCREENINFO 149ab42b818SMauro Carvalho Chehaband FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a 150ab42b818SMauro Carvalho Chehabfb_fix_screeninfo and fb_var_screeninfo structure respectively. 151ab42b818SMauro Carvalho Chehab 152ab42b818SMauro Carvalho Chehabstruct fb_fix_screeninfo stores device independent unchangeable information 153ab42b818SMauro Carvalho Chehababout the frame buffer device and the current format. Those information can't 154ab42b818SMauro Carvalho Chehabbe directly modified by applications, but can be changed by the driver when an 155ab42b818SMauro Carvalho Chehabapplication modifies the format:: 156ab42b818SMauro Carvalho Chehab 157ab42b818SMauro Carvalho Chehab struct fb_fix_screeninfo { 158ab42b818SMauro Carvalho Chehab char id[16]; /* identification string eg "TT Builtin" */ 159ab42b818SMauro Carvalho Chehab unsigned long smem_start; /* Start of frame buffer mem */ 160ab42b818SMauro Carvalho Chehab /* (physical address) */ 161ab42b818SMauro Carvalho Chehab __u32 smem_len; /* Length of frame buffer mem */ 162ab42b818SMauro Carvalho Chehab __u32 type; /* see FB_TYPE_* */ 163ab42b818SMauro Carvalho Chehab __u32 type_aux; /* Interleave for interleaved Planes */ 164ab42b818SMauro Carvalho Chehab __u32 visual; /* see FB_VISUAL_* */ 165ab42b818SMauro Carvalho Chehab __u16 xpanstep; /* zero if no hardware panning */ 166ab42b818SMauro Carvalho Chehab __u16 ypanstep; /* zero if no hardware panning */ 167ab42b818SMauro Carvalho Chehab __u16 ywrapstep; /* zero if no hardware ywrap */ 168ab42b818SMauro Carvalho Chehab __u32 line_length; /* length of a line in bytes */ 169ab42b818SMauro Carvalho Chehab unsigned long mmio_start; /* Start of Memory Mapped I/O */ 170ab42b818SMauro Carvalho Chehab /* (physical address) */ 171ab42b818SMauro Carvalho Chehab __u32 mmio_len; /* Length of Memory Mapped I/O */ 172ab42b818SMauro Carvalho Chehab __u32 accel; /* Indicate to driver which */ 173ab42b818SMauro Carvalho Chehab /* specific chip/card we have */ 174ab42b818SMauro Carvalho Chehab __u16 capabilities; /* see FB_CAP_* */ 175ab42b818SMauro Carvalho Chehab __u16 reserved[2]; /* Reserved for future compatibility */ 176ab42b818SMauro Carvalho Chehab }; 177ab42b818SMauro Carvalho Chehab 178ab42b818SMauro Carvalho Chehabstruct fb_var_screeninfo stores device independent changeable information 179ab42b818SMauro Carvalho Chehababout a frame buffer device, its current format and video mode, as well as 180ab42b818SMauro Carvalho Chehabother miscellaneous parameters:: 181ab42b818SMauro Carvalho Chehab 182ab42b818SMauro Carvalho Chehab struct fb_var_screeninfo { 183ab42b818SMauro Carvalho Chehab __u32 xres; /* visible resolution */ 184ab42b818SMauro Carvalho Chehab __u32 yres; 185ab42b818SMauro Carvalho Chehab __u32 xres_virtual; /* virtual resolution */ 186ab42b818SMauro Carvalho Chehab __u32 yres_virtual; 187ab42b818SMauro Carvalho Chehab __u32 xoffset; /* offset from virtual to visible */ 188ab42b818SMauro Carvalho Chehab __u32 yoffset; /* resolution */ 189ab42b818SMauro Carvalho Chehab 190ab42b818SMauro Carvalho Chehab __u32 bits_per_pixel; /* guess what */ 191ab42b818SMauro Carvalho Chehab __u32 grayscale; /* 0 = color, 1 = grayscale, */ 192ab42b818SMauro Carvalho Chehab /* >1 = FOURCC */ 193ab42b818SMauro Carvalho Chehab struct fb_bitfield red; /* bitfield in fb mem if true color, */ 194ab42b818SMauro Carvalho Chehab struct fb_bitfield green; /* else only length is significant */ 195ab42b818SMauro Carvalho Chehab struct fb_bitfield blue; 196ab42b818SMauro Carvalho Chehab struct fb_bitfield transp; /* transparency */ 197ab42b818SMauro Carvalho Chehab 198ab42b818SMauro Carvalho Chehab __u32 nonstd; /* != 0 Non standard pixel format */ 199ab42b818SMauro Carvalho Chehab 200ab42b818SMauro Carvalho Chehab __u32 activate; /* see FB_ACTIVATE_* */ 201ab42b818SMauro Carvalho Chehab 202ab42b818SMauro Carvalho Chehab __u32 height; /* height of picture in mm */ 203ab42b818SMauro Carvalho Chehab __u32 width; /* width of picture in mm */ 204ab42b818SMauro Carvalho Chehab 205ab42b818SMauro Carvalho Chehab __u32 accel_flags; /* (OBSOLETE) see fb_info.flags */ 206ab42b818SMauro Carvalho Chehab 207ab42b818SMauro Carvalho Chehab /* Timing: All values in pixclocks, except pixclock (of course) */ 208ab42b818SMauro Carvalho Chehab __u32 pixclock; /* pixel clock in ps (pico seconds) */ 209ab42b818SMauro Carvalho Chehab __u32 left_margin; /* time from sync to picture */ 210ab42b818SMauro Carvalho Chehab __u32 right_margin; /* time from picture to sync */ 211ab42b818SMauro Carvalho Chehab __u32 upper_margin; /* time from sync to picture */ 212ab42b818SMauro Carvalho Chehab __u32 lower_margin; 213ab42b818SMauro Carvalho Chehab __u32 hsync_len; /* length of horizontal sync */ 214ab42b818SMauro Carvalho Chehab __u32 vsync_len; /* length of vertical sync */ 215ab42b818SMauro Carvalho Chehab __u32 sync; /* see FB_SYNC_* */ 216ab42b818SMauro Carvalho Chehab __u32 vmode; /* see FB_VMODE_* */ 217ab42b818SMauro Carvalho Chehab __u32 rotate; /* angle we rotate counter clockwise */ 218ab42b818SMauro Carvalho Chehab __u32 colorspace; /* colorspace for FOURCC-based modes */ 219ab42b818SMauro Carvalho Chehab __u32 reserved[4]; /* Reserved for future compatibility */ 220ab42b818SMauro Carvalho Chehab }; 221ab42b818SMauro Carvalho Chehab 222ab42b818SMauro Carvalho ChehabTo modify variable information, applications call the FBIOPUT_VSCREENINFO 223ab42b818SMauro Carvalho Chehabioctl with a pointer to a fb_var_screeninfo structure. If the call is 224ab42b818SMauro Carvalho Chehabsuccessful, the driver will update the fixed screen information accordingly. 225ab42b818SMauro Carvalho Chehab 226ab42b818SMauro Carvalho ChehabInstead of filling the complete fb_var_screeninfo structure manually, 227ab42b818SMauro Carvalho Chehabapplications should call the FBIOGET_VSCREENINFO ioctl and modify only the 228ab42b818SMauro Carvalho Chehabfields they care about. 229ab42b818SMauro Carvalho Chehab 230ab42b818SMauro Carvalho Chehab 231ab42b818SMauro Carvalho Chehab4. Format configuration 232ab42b818SMauro Carvalho Chehab----------------------- 233ab42b818SMauro Carvalho Chehab 234ab42b818SMauro Carvalho ChehabFrame buffer devices offer two ways to configure the frame buffer format: the 235ab42b818SMauro Carvalho Chehablegacy API and the FOURCC-based API. 236ab42b818SMauro Carvalho Chehab 237ab42b818SMauro Carvalho Chehab 238ab42b818SMauro Carvalho ChehabThe legacy API has been the only frame buffer format configuration API for a 239ab42b818SMauro Carvalho Chehablong time and is thus widely used by application. It is the recommended API 240ab42b818SMauro Carvalho Chehabfor applications when using RGB and grayscale formats, as well as legacy 241ab42b818SMauro Carvalho Chehabnon-standard formats. 242ab42b818SMauro Carvalho Chehab 243ab42b818SMauro Carvalho ChehabTo select a format, applications set the fb_var_screeninfo bits_per_pixel field 244ab42b818SMauro Carvalho Chehabto the desired frame buffer depth. Values up to 8 will usually map to 245ab42b818SMauro Carvalho Chehabmonochrome, grayscale or pseudocolor visuals, although this is not required. 246ab42b818SMauro Carvalho Chehab 247ab42b818SMauro Carvalho Chehab- For grayscale formats, applications set the grayscale field to one. The red, 248ab42b818SMauro Carvalho Chehab blue, green and transp fields must be set to 0 by applications and ignored by 249ab42b818SMauro Carvalho Chehab drivers. Drivers must fill the red, blue and green offsets to 0 and lengths 250ab42b818SMauro Carvalho Chehab to the bits_per_pixel value. 251ab42b818SMauro Carvalho Chehab 252ab42b818SMauro Carvalho Chehab- For pseudocolor formats, applications set the grayscale field to zero. The 253ab42b818SMauro Carvalho Chehab red, blue, green and transp fields must be set to 0 by applications and 254ab42b818SMauro Carvalho Chehab ignored by drivers. Drivers must fill the red, blue and green offsets to 0 255ab42b818SMauro Carvalho Chehab and lengths to the bits_per_pixel value. 256ab42b818SMauro Carvalho Chehab 257ab42b818SMauro Carvalho Chehab- For truecolor and directcolor formats, applications set the grayscale field 258ab42b818SMauro Carvalho Chehab to zero, and the red, blue, green and transp fields to describe the layout of 259ab42b818SMauro Carvalho Chehab color components in memory:: 260ab42b818SMauro Carvalho Chehab 261ab42b818SMauro Carvalho Chehab struct fb_bitfield { 262ab42b818SMauro Carvalho Chehab __u32 offset; /* beginning of bitfield */ 263ab42b818SMauro Carvalho Chehab __u32 length; /* length of bitfield */ 264ab42b818SMauro Carvalho Chehab __u32 msb_right; /* != 0 : Most significant bit is */ 265ab42b818SMauro Carvalho Chehab /* right */ 266ab42b818SMauro Carvalho Chehab }; 267ab42b818SMauro Carvalho Chehab 268ab42b818SMauro Carvalho Chehab Pixel values are bits_per_pixel wide and are split in non-overlapping red, 269ab42b818SMauro Carvalho Chehab green, blue and alpha (transparency) components. Location and size of each 270ab42b818SMauro Carvalho Chehab component in the pixel value are described by the fb_bitfield offset and 271ab42b818SMauro Carvalho Chehab length fields. Offset are computed from the right. 272ab42b818SMauro Carvalho Chehab 273ab42b818SMauro Carvalho Chehab Pixels are always stored in an integer number of bytes. If the number of 274ab42b818SMauro Carvalho Chehab bits per pixel is not a multiple of 8, pixel values are padded to the next 275ab42b818SMauro Carvalho Chehab multiple of 8 bits. 276ab42b818SMauro Carvalho Chehab 277ab42b818SMauro Carvalho ChehabUpon successful format configuration, drivers update the fb_fix_screeninfo 278ab42b818SMauro Carvalho Chehabtype, visual and line_length fields depending on the selected format. 279ab42b818SMauro Carvalho Chehab 280ab42b818SMauro Carvalho Chehab 281ab42b818SMauro Carvalho ChehabThe FOURCC-based API replaces format descriptions by four character codes 282ab42b818SMauro Carvalho Chehab(FOURCC). FOURCCs are abstract identifiers that uniquely define a format 283ab42b818SMauro Carvalho Chehabwithout explicitly describing it. This is the only API that supports YUV 284ab42b818SMauro Carvalho Chehabformats. Drivers are also encouraged to implement the FOURCC-based API for RGB 285ab42b818SMauro Carvalho Chehaband grayscale formats. 286ab42b818SMauro Carvalho Chehab 287ab42b818SMauro Carvalho ChehabDrivers that support the FOURCC-based API report this capability by setting 288ab42b818SMauro Carvalho Chehabthe FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field. 289ab42b818SMauro Carvalho Chehab 290ab42b818SMauro Carvalho ChehabFOURCC definitions are located in the linux/videodev2.h header. However, and 291ab42b818SMauro Carvalho Chehabdespite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2 292ab42b818SMauro Carvalho Chehaband don't require usage of the V4L2 subsystem. FOURCC documentation is 29354f38fcaSMauro Carvalho Chehabavailable in Documentation/userspace-api/media/v4l/pixfmt.rst. 294ab42b818SMauro Carvalho Chehab 295ab42b818SMauro Carvalho ChehabTo select a format, applications set the grayscale field to the desired FOURCC. 296ab42b818SMauro Carvalho ChehabFor YUV formats, they should also select the appropriate colorspace by setting 297ab42b818SMauro Carvalho Chehabthe colorspace field to one of the colorspaces listed in linux/videodev2.h and 29854f38fcaSMauro Carvalho Chehabdocumented in Documentation/userspace-api/media/v4l/colorspaces.rst. 299ab42b818SMauro Carvalho Chehab 300ab42b818SMauro Carvalho ChehabThe red, green, blue and transp fields are not used with the FOURCC-based API. 301ab42b818SMauro Carvalho ChehabFor forward compatibility reasons applications must zero those fields, and 302ab42b818SMauro Carvalho Chehabdrivers must ignore them. Values other than 0 may get a meaning in future 303ab42b818SMauro Carvalho Chehabextensions. 304ab42b818SMauro Carvalho Chehab 305ab42b818SMauro Carvalho ChehabUpon successful format configuration, drivers update the fb_fix_screeninfo 306ab42b818SMauro Carvalho Chehabtype, visual and line_length fields depending on the selected format. The type 307ab42b818SMauro Carvalho Chehaband visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively. 308