BCOS Home » The BCOS Project » BCOS Specifications » BCOS File Format Specifications

BCOS Display Identification Data File Format Specification

Preliminary Draft

Project Map

Contents:

Tables:

Figures:

Chapter 1: Overview

This specification defines the file format used for storing information about video displays (monitors, VR headsets, etc). It is intended to be used by both boot code and video drivers.

Note 1: This file format is used in place of the raw EDID provided by monitors; because the raw EDID provided by monitors is excessively awkward (due to both space restrictions and repeated short-sightedness by VESA).

Note 2: The primary source of files using this file format is the OS's own Boot Abstraction Layer and native video drivers; which will convert the raw EDID obtained from monitors into this file format and store the results in the file system to avoid future conversions and allow the files to be used in situations where the raw EDID isn't available and/or needs to be overridden or modified.

Chapter 2: Specification Change Policy

Any changes made in future versions of this specification that breaks forward or backward compatiblity shall increase the major version number.

In general, the Boot Abstraction Layer, video drivers and other tools that use files in this format should check the version field in the native file format header. If the major version is known but the minor version is not, then backward and forward compatiblity is guaranteed but writing a new version of the file may cause information loss and should be avoided. If the major version number is not known then backward and forward compatiblity are not guaranteed and the contents of the file should not be relied on. Software may support multiple versions of this file format specification.

Chapter 3: File Naming

To allow software to find the file for a specific monitor quickly, it is expected that the file names used for Display Identification Data files are constructed from the vendor ID converted to ASCII characters (see Subsection 5.2.1. Vendor ID), followed by an underscore, followed by the product ID converted to ASCII characters (see Subsection 5.2.2. Product ID). For example, if the vendor ID is 0x1234 and product ID is 0xAB12; then the file name should be DQT_AB12.

If the temporary flag is set in the product ID, the file name should be prefixed by an underscore. For example, if the vendor ID field contains 0x9234 and product ID is 0xAB12; then the file name should be _DQT_AB12.

Chapter 4: General File Structure

The basic structure of the file is described in Figure 4-1. File Structure.

Figure 4-1. File Structure
  End of file 
(Optional) Metadata
(Optional) Raw EDID data
Pixel Mapping Mesh Data
Colour Data
Video Mode Timing Data
Extended Header 0x00000030
Generic Header 0x00000000
Note: Not to scale.

Chapter 5: File Format

5.1. Generic File Header

This is the native file format header defined in BCOS Native File Format Specification. For this specification, the "file type" field in the generic header (at offset 0x00000028) must be set to 0xE0000000.

5.2. Extended Header

The Extended Header follows the Generic File Header, and is described in Table 5-1. Extended Header Format.

Table 5-1. Extended Header Format
OffsetSizeDescription
0x000000302 bytesVendor ID (Subsection 5.2.1. Vendor ID)
0x000000322 bytesProduct ID (Subsection 5.2.2. Product ID)
0x000000342 bytesModel Year (Subsection 5.2.3. Model Year)
0x000000361 bytesUnused/reserved
0x000000371 bytesScaling method (Subsection 5.2.4. Scaling Method)
0x000000388 bytesSupported connection types Subsection 5.2.5. Supported Connection Types
0x000000404 bytesOffset of power management descriptors (Subsection 5.2.6. Power Management Descriptors)
0x000000444 bytesOffset of video mode timing information (Subsection 5.2.7. Video Mode Timing Data, Chapter 7: Video Mode Timing Data Entry Format)
0x000000484 bytesOffset of colour data information (Subsection 5.2.8. Colour Data, Chapter 8: Colour Data Entry Format)
0x0000004C4 bytesOffset of pixel mapping mesh data (Subsection 5.2.9. Pixel Mapping Mesh Data, Chapter 9: Pixel Mapping Mesh Entry Format)
0x000000504 bytesOffset of optional raw EDID data or byte after pixel mapping mesh data (Subsection 5.2.10. Optional raw EDID data)
0x000000544 bytesOffset of byte after optional raw EDID data or byte after pixel mapping mesh data

5.2.1. Vendor ID

The vendor ID is the same as it is for raw EDID, except that the bytes are in little endian order; where 3 ASCII characters are packed into 2 bytes as described by Table 5-2. Vendor ID Format. ASCII values between 0x5B and 0x5E (inclusive - [, \, ] and ^) are invalid and must not be used.

Table 5-2. Vendor ID Format
Bit/sDescription
15Temporary Flag (Subsubsection 5.2.1.1. Temporary Flag)
10 to 14Low 5 bits of ASCII value for first character (highest 3 bits assumed to be 010b)
5 to 9Low 5 bits of ASCII value for second character (highest 3 bits assumed to be 010b)
0 to 4Low 5 bits of ASCII value for third character (highest 3 bits assumed to be 010b)
5.2.1.1. Temporary Flag

The temporary flag indicates whether this file is a temporary file that was auto-generated from the display's EDID data, where some information may be ficticious or less precise due to missing or less precise information in EDID. It is expected that temporary files are checked and corrected manually if necessary (using a specially designed utility); and temporary files are only used by video drivers and boot code if no checked/corrected file exists for the display.

5.2.2. Product ID

The product ID is the same as it is for raw EDID, where the product ID is just 16 bits. For display purposes, the product ID is displayed in hexadecimal without any prefix or suffix.

5.2.3. Model Year

The model year field contains the year minus 1990. For example, the value 0x0000 indicates the model year is 1990, and the value 0x0019 indicates the model year is 2015. The value 0xFFFF is used if the model year is unknown.

5.2.4. Scaling Method

This field indicates the method that the display uses for scaling images if/when the video timing doesn't match the display's native resolution. It contains one of the values shown in Table 5-3. Scaling Method Values.

Table 5-3. Scaling Method Values
ValueDescription
0x00Unknown
0x01CRT (analogue, no scaling)
0x02Nearest neighbour
0x03Bilinear scaling
0x04Bicubic scaling

5.2.5. Supported Connection Types

A display may have multiple different types of connections (e.g. VGA, DisplayPort, HDMI). This field shows what types of connections are supported, and may be used by the video driver to ensure the best connection is used where possible. For example, if the display is connected via. an analogue/VGA connection but both the video card and the display support HDMI, then the video driver may suggest that the cable from the display adapter to the monitor be changed.

The meaning of each of these bits is described in Table 5-4. Display Connection Types.

Table 5-4. Display Connection Types
BitDescription
0Unknown
1Analogue, VGA
32DVI
33HDMI 1.0
34HDMI 1.1
35HDMI 1.2
36HDMI 1.3
37HDMI 1.4
38HDMI 2
48DisplayPort 1.0
49DisplayPort 1.2
50DisplayPort 1.3

The "unknown" connection type is used as a placeholder when this information isn't available. If a file says "unknown, VGA and HDMI 1.0" then the monitor may only support VGA and HDMI and nothing else, or a monitor might support VGA, HDMI and something else.

5.2.6. Power Management Descriptors

The power management descriptors are a list of 1 or more entries describing power management features that the display supports. The format of descriptors is described in Chapter 6: Power Management Descriptor Format.

The end of the list of power management descriptors is determined by the offset for the start of the video mode timing data field in the extended header.

5.2.7. Video Mode Timing Data

The video mode timing data consists of one or more entries (one for each video mode timing that the display supports). This information is used to choose a video mode timing that both the display and the display adapter support. The format of each entry is described in Chapter 7: Video Mode Timing Data Entry Format.

The end of the list of video mode timing data entries is determined by the offset for the start of the colour data field in the extended header.

5.2.8. Colour Data

The colour data consists of one or more entries (one for each way pixel colour values are converted into colours). This information is used to ensure colours are displayed correctly when possible. The format of each entry is described in Chapter 8: Colour Data Entry Format.

The end of the list of colour data entries is determined by the offset for the start of the pixel mapping mesh data field in the extended header.

5.2.9. Pixel Mapping Mesh Data

The pixel mapping mesh data consists of one or more entries (one for each way that pixels are mapped to the physical screen). This information is used to support arbitrary shaped monitors and ensure video is generated to suit the display's shape. The format of each entry is described in Chapter 9: Pixel Mapping Mesh Entry Format.

The end of the list of pixel mapping mesh entries is determined by the offset of byte after pixel mapping mesh data field in the extended header.

5.2.10. Optional raw EDID data

This data is the raw EDID data from the display itself. If should be included if the DID file is "temporary" flag in the vendor ID is set (but may not be), and should not be included if the "temporary" flag in the vendor ID is clear (but may be).

Chapter 6: Power Management Descriptor Format

Each power management descriptor has the format shown in Table 6-1. Power Management Descriptor Fields.

Table 6-1. Power Management Descriptor Fields
OffsetSizeDescription
0x000000008 bytesSupported Connections (Section 6.1. Supported Connections)
0x000000082 bytesPower Management Method (Section 6.2. Power Management Method)
0x0000000A2 bytesUnused/reserved
0x0000000C2 bytesPower Consumption (Section 6.3. Power Consumption)
0x0000000E2 bytesWake Time

6.1. Supported Connections

A display may have multiple different types of connections (e.g. VGA, DisplayPort, HDMI) where some power management methods are only supported by the display for some of the connection types. This field contains a bit for each connection type and is used to determine if the power management methods is supported for each connection type. The meaning of each bit is identical to those described in Table 5-4. Display Connection Types.

6.2. Power Management Method

This field determines the method of power management being described. It contains one of the values shown in Table 6-2. Power Management Methods.

Table 6-2. Power Management Methods
ValueDescription
0x0000Normal operation
0x0001H-sync signal off
0x0002V-sync signal off
0x0003Both H-sync and V-sync signals off

6.3. Power Consumption

This field contains the power consumed by the display when using the associated power management method as an 8.8 fixed point value representing watts (or as a 16-bit value representing 1/256ths of a watt).

The value 0x0000 signifies that the power consumption is not known, and the value 0xFFFF signifies that the power consumption is 255.996 watts or more.

6.4. Wake Time

This field contains the amount of time it takes the display to return to normal operation after using this power management method, in 8.8 fixed point value representing seconds (or as a 16-bit value representing 1/256ths of a second).

The value 0x0000 signifies that the wake time is not known, and the value 0xFFFF signifies that the wake time is 255.996 seconds or more.

Note: For the "normal operation" power management method, this field must be set to 0x0000.

Chapter 7: Video Mode Timing Data Entry Format

Each entry begins with 6 standard fields described in Section 7.1. Video Mode Timing Data Entry Format Standard Fields, followed by other fields that are determined from the entry's type.

7.1. Video Mode Timing Data Entry Format Standard Fields

The standard fields used in all video mode timing data entry types are described in Table 7-1. Video Mode Timing Entry Standard Fields.

Table 7-1. Video Mode Timing Entry Standard Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 7.1.1. Video Mode Timing Entry Size)
0x000000022 bytesEntry Type (Subsection 7.1.2. Video Mode Timing Entry Type)
0x000000042 bytesColour Data Index (Subsection 7.1.4. Video Mode Timing Entry Colour Data Index)
0x000000062 bytesPixel Mapping Mesh Data Index (Subsection 7.1.5. Video Mode Timing Pixel Mapping Mesh Data Index)
0x000000088 bytesSupported Connections (Subsection 7.1.3. Supported Connections)
0x000000101 bytePreference (Subsection 7.1.6. Video Mode Timing Preference)
0x00000011VariesDepends on entry type

7.1.1. Video Mode Timing Entry Size

This field contains the total size of the entry (including any padding), and allows software to find all entries (even when software doesn't support the entry's type).

7.1.2. Video Mode Timing Entry Type

This field determines the type of the entry, and the format of all additional data for the entry. Entry types are described in Table 7-2. Video Mode Timing Entry Types.

Table 7-2. Video Mode Timing Entry Types
ValueDescription
0x00002D Fixed Analogue Timing (Section 7.2. Video Mode Timing Entry Type 0x0000, 2D Fixed Analogue Timing)
0x00012D Variable Analogue Timing (Section 7.3. Video Mode Timing Entry Type 0x0001, 2D Variable Analogue Timing)

7.1.3. Supported Connections

A display may have multiple different types of connections (e.g. VGA, DisplayPort, HDMI) where some video timings are only supported by the display for some of the connection types. This field contains a bit for each connection type and is used to determine if the video mode timing is supported for each connection type. The meaning of each bit is identical to those described in Table 5-4. Display Connection Types.

7.1.4. Video Mode Timing Entry Colour Data Index

This field is used to determine which entry in the colour data applies to this video mode timing entry; where 0x0000 is the first colour data entry, 0x0001 is the second, etc. See Subsection 5.2.8. Colour Data and Chapter 8: Colour Data Entry Format for information on colour data entries.

7.1.5. Video Mode Timing Pixel Mapping Mesh Data Index

This field is used to determine which entry in the pixel mapping mesh data applies to this video mode timing entry; where 0x0000 is the first pixel mapping mesh data entry, 0x0001 is the second, etc. See Subsection 5.2.9. Pixel Mapping Mesh Data and Chapter 9: Pixel Mapping Mesh Entry Format for information on pixel mapping mesh data entries.

7.1.6. Video Mode Timing Preference

This field indicates how well the display is able to handle the video mode timing described by this entry. The value 0x00 means that the video mode timing is supported very badly by the display and the value 0xFF indicates that it is the best possible video mode timing for the display.

7.2. Video Mode Timing Entry Type 0x0000, 2D Fixed Analogue Timing

This timing entry type is used for devices that use analoque signals (e.g. VGA) and equipment emulating devices that use analoque signals; where the data is arranged as a 2D grid of pixels. For this entry type; the format for the video mode timing data entry is described in Table 7-3. 2D Fixed Analogue Timing Fields.

There may be none or more fixed analogue timing entries (in addition to none or one variable analogue timing entry).

Table 7-3. 2D Fixed Analogue Timing Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 7.1.1. Video Mode Timing Entry Size)
0x000000022 bytesEntry Type (Subsection 7.1.2. Video Mode Timing Entry Type, must be 0x0000)
0x000000042 bytesColour Data Index (Subsection 7.1.4. Video Mode Timing Entry Colour Data Index)
0x000000062 bytesPixel Mapping Mesh Data Index (Subsection 7.1.5. Video Mode Timing Pixel Mapping Mesh Data Index)
0x000000088 bytesSupported Connections (Subsection 7.1.3. Supported Connections)
0x000000101 bytePreference (Subsection 7.1.6. Video Mode Timing Preference)
0x000000113 byteUnused/reserved
0x000000144 bytesSignal Flags (Subsection 7.2.1. Signal Flags)
0x000000181 byteStereoscopy Type (Subsection 7.2.2. Stereoscopy Type)
0x000000191 byteUnused/reserved
0x0000001A2 bytesSupplementary Pixel Mapping Mesh Data Index (Subsection 7.2.3. Supplementary Pixel Mapping Mesh Data Index)
0x0000001C2 bytesUnused/reserved
0x0000001E2 bytesHorizontal Resolution (Subsection 7.2.4. Horizontal and Vertical Resolution)
0x000000202 bytesVertical Resolution (Subsection 7.2.4. Horizontal and Vertical Resolution)
0x000000222 bytesFrame Rate (Subsection 7.2.5. Frame Rate)
0x000000244 bytesPixel Clock Frequency (Subsection 7.2.6. Pixel Clock)
0x000000282 bytesHorizontal Margin in Pixels (Subsection 7.2.7. Horizontal Margin, Back Porch, Sync Width and Front Porch)
0x0000002A2 bytesHorizontal Back Porch in Pixels (Subsection 7.2.7. Horizontal Margin, Back Porch, Sync Width and Front Porch)
0x0000002C2 bytesHorizontal Sync Width in Pixels (Subsection 7.2.7. Horizontal Margin, Back Porch, Sync Width and Front Porch)
0x0000002E2 bytesHorizontal Front Porch in Pixels (Subsection 7.2.7. Horizontal Margin, Back Porch, Sync Width and Front Porch)
0x000000302 bytesVertical Margin in Lines (Subsection 7.2.8. Vertical Margin, Back Porch, Sync Width and Front Porch)
0x000000322 bytesVertical Back Porch in Lines (Subsection 7.2.8. Vertical Margin, Back Porch, Sync Width and Front Porch)
0x000000342 bytesVertical Sync Width in Lines (Subsection 7.2.8. Vertical Margin, Back Porch, Sync Width and Front Porch)
0x000000362 bytesVertical Front Porch in Lines (Subsection 7.2.8. Vertical Margin, Back Porch, Sync Width and Front Porch)

7.2.1. Signal Flags

The signal flags determine various characteristics of the signals used, and are described by Table 7-4. Signal Flag Meanings.

Table 7-4. Signal Flag Meanings
Bit/sDescription
0 to 7Horizontal and vertical sync method (Table 7-5. Horizontal and Vertical Sync Method Values)
8 to 30Unused/reserved
31Non-interlaced when clear, interlaced when set
Table 7-5. Horizontal and Vertical Sync Method Values
ValueDescription
0x00Analogue composite sync without serrations, sync on green signal only
0x01Analogue composite sync without serrations, sync on all video signals
0x02Analogue composite sync with serrations, sync on green signal only
0x03Analogue composite sync with serrations, sync on all video signals
0x40Bipolar analogue composite sync without serrations, sync on green signal only
0x41Bipolar analogue composite sync without serrations, sync on all video signals
0x42Bipolar analogue composite sync with serrations, sync on green signal only
0x43Bipolar analogue composite sync with serrations, sync on all video signals
0x80Digital composite sync without serrations, horizontal sync is negative
0x81Digital composite sync without serrations, horizontal sync is positive
0x82Digital composite sync with serrations, horizontal sync is negative
0x83Digital composite sync with serrations, horizontal sync is positive
0xC0Digital seperate sync, vertical sync is negative, horizontal sync is negative
0xC1Digital seperate sync, vertical sync is negative, horizontal sync is positive
0xC2Digital seperate sync, vertical sync is positive, horizontal sync is negative
0xC3Digital seperate sync, vertical sync is positive, horizontal sync is positive

7.2.2. Stereoscopy Type

For stereoscopy, this field determines how the "2D grid of pixels" is split into a separate "2D grid of pixels" for each eye. Values for this field are described by Table 7-6. Display Type Values.

Table 7-6. Display Type Values
ValueDescription
0x00Not Stereoscopic
0x02Frame by Frame (frame for left eye when stereo sync signal = 0, frame for right eye when stereo sync signal = 1)
0x03Frame by Frame Inverted (frame for left eye when stereo sync signal = 1, frame for right eye when stereo sync signal = 0)
0x04Side by Side (left half of frame to left eye, right half of frame to right eye)
0x05Side by Side Inverted (right half of frame to left eye, left half of frame to right eye)
0x06Vertical Side by Side (top half of frame to left eye, bottom half of frame to right eye)
0x07Vertical Side by Side Inverted (bottom half of frame to left eye, top half of frame to right eye)
0x08Alternating Rows (even rows to left eye, odd rows to right eye)
0x09Alternating Rows Inverted (odd rows to left eye, even rows to right eye)
0x0AAlternating Columns (even columns to left eye, odd columns to right eye)
0x0BAlternating Columns Inverted (odd columns to left eye, even columns to right eye)
0x0CCheckered (top left pixel to left eye)
0x0DCheckered Inverted (top left pixel to right eye)

7.2.3. Supplementary Pixel Mapping Mesh Data Index

When the Stereoscopy Type field (Subsection 7.2.2. Stereoscopy Type) indicates that any form of stereoscopy is involved, the Pixel Mapping Mesh Data Index field (Subsection 7.1.5. Video Mode Timing Pixel Mapping Mesh Data Index) is used for the left eye only, and this field is used for the right eye.

When the Stereoscopy Type field is set to 0x00 ("Not Stereoscopic") this field is ignored/unused.

7.2.4. Horizontal and Vertical Resolution

These fields describe the width and heigh of the video mode's 2D grid of pixels (e.g. 1024 pixels by 768 pixels).

7.2.5. Frame Rate

This field contains an estimate of the video mode's frame rate in 256ths of a Hertz units (or Hertz in 8.8 fixed point format). For example, the value 0xFFFF represents 255.996 Hz and the value 0x3C00 represents 60.000 Hz. This value should be the exact frame rate rounded to the nearest representable value (in most cases the exact frame rate isn't representable).

In general the exact field rate can be calculated from other information in the video mode timing entry (pixel clock frequency, horizontal margin, etc). For progressive video modes the exact frame rate equals the exact field rate; and for interlaced video modes the exact frame rate is half of the exact field rate. The frame rate is stored to avoid these calculations when only an estimate is needed.

The formula/s for calculating the exact frame rate for normal/progressive video modes are:

The formula/s for calculating the exact frame rate for interlaced video modes are:

7.2.6. Pixel Clock

This is the video mode's pixel clock frequency in Hz.

7.2.7. Horizontal Margin, Back Porch, Sync Width and Front Porch

These fields (and the horizontal resolution field) determine the timing of various parts of the video signal used to construct a scan line, in units of "pixels" (derived from the pixel clock). For example, if the horizontal sync width is 100 pixels and the pixel clock is 1 MHz, then the horizontal sync width is 100/1000000 seconds long (100 us).

The horizontal timing signals look as shown in Figure 7-1. Horizontal Timing. Note that "horizontal margin" is used twice (it is assumed that the left margin size is equal to the right margin size).

Figure 7-1. Horizontal Timing
                       _____________________________________________________
                      |                                                     |                       ______
______________________|                                                     |______________________|      |
            :         :                                                     :                      |______|
            :         :                                                     :                      :      :
 Back Porch | Margin  |                    Active Pixels                    | Margin | Front Porch | Sync |

7.2.8. Vertical Margin, Back Porch, Sync Width and Front Porch

These fields (and the vertical resolution field) determine the timing of various parts of the video signal used to construct a field, in "lines". For example, if (based on the information in Subsection 7.2.7. Horizontal Margin, Back Porch, Sync Width and Front Porch) it takes 34 us for a scan line, and the vertical sync width is 100 lines, then the vertical sync width is 0.000034 * 100 = 34 ms long.

The vertical timing signals look as shown in Figure 7-2. Vertical Timing. Note that "vertical margin" is used twice (it is assumed that the top margin size is equal to the bottom margin size).

Figure 7-2. Vertical Timing
                       _____________________________________________________
                      |                                                     |                       ______
______________________|                                                     |______________________|      |
            :         :                                                     :                      |______|
            :         :                                                     :                      :      :
 Back Porch | Margin  |                    Active Lines                     | Margin | Front Porch | Sync |
7.2.8.1. Vertical Back Porch and Front Porch in Interlaced Modes

In interlaced video modes; the value stored in the vertical font porch field is for "even fields" only (and for "odd fields" the vertical front porch is 0.5 lines longer); and the value stored in the vertical back porch field is for "odd fields" only (and for "even fields" the vertical back porch is 0.5 lines longer).

Figure 7-3. Vertical Timing in Interlaced Modes
                             _____________________________________________________
                            |                                                     |                       ______
____________________________|                                                     |______________________|      |
                  :         :                                                     :                      |______|
                  :         :                     Even Field                      :                      :      :
 Back Porch + 0.5 | Margin  |                    Active Lines                     | Margin | Front Porch | Sync |
 
 
                       _____________________________________________________
                      |                                                     |                              ______
______________________|                                                     |_____________________________|      |
            :         :                                                     :                             |______|
            :         :                     Odd Field                       :                             :      :
 Back Porch | Margin  |                    Active Lines                     | Margin | Front Porch + 0.5  | Sync |

Warning: Of the information available online, a lot is partial and/or misleading. This includes information that assumes the "field number 0" is odd and information that assumes a field begins with active lines and not at the start or end of the vertical sync pulse. These differences cause a huge amount of confusion. For all information for the BCOS project a field begins at the end of a vertical sync pules, and the field containing screen lines 0, 2, 4, 8, ... is the even field, while the field containing lines 1, 3, 5, 7, ... is the odd field.

7.3. Video Mode Timing Entry Type 0x0001, 2D Variable Analogue Timing

This timing entry type is used for devices that use analoque signals (e.g. VGA) and equipment emulating devices that use analoque signals; where the data is arranged as a 2D grid of pixels. For this entry type; the format for the video mode timing data entry is described in Table 7-7. 2D Variable Analogue Timing Fields.

There may be none or one variable analogue timing entry (in addition to none or more fixed analogue timing entries).

Table 7-7. 2D Variable Analogue Timing Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 7.1.1. Video Mode Timing Entry Size)
0x000000022 bytesEntry Type (Subsection 7.1.2. Video Mode Timing Entry Type, must be 0x0001)
0x000000042 bytesColour Data Index (Subsection 7.1.4. Video Mode Timing Entry Colour Data Index)
0x000000062 bytesPixel Mapping Mesh Data Index (Subsection 7.1.5. Video Mode Timing Pixel Mapping Mesh Data Index)
0x000000088 bytesSupported Connections (Subsection 7.1.3. Supported Connections)
0x000000101 bytePreference (Subsection 7.1.6. Video Mode Timing Preference)
0x000000113 byteUnused/reserved
0x000000144 bytesSignal Flags (same as Subsection 7.2.1. Signal Flags)
0x000000181 byteStereoscopy Type (same as Subsection 7.2.2. Stereoscopy Type)
0x000000191 byteUnused/reserved
0x0000001A2 bytesSupplementary Pixel Mapping Mesh Data Index (same as Subsection 7.2.3. Supplementary Pixel Mapping Mesh Data Index)
0x0000001C2 bytesUnused/reserved
0x0000001E2 bytesVariable Frequency Flags (Subsection 7.3.1. 2D Variable Analogue Timing Flags)
0x000000204 bytesMinimum field rate (Subsection 7.3.2. 2D Variable Analogue Timing Minimum and Maximimum Field Rate)
0x000000244 bytesMaximum field rate (Subsection 7.3.2. 2D Variable Analogue Timing Minimum and Maximimum Field Rate)
0x000000284 bytesMinimum horizontal rate (Subsection 7.3.3. 2D Variable Analogue Timing Minimum and Maximimum Horizontal Rate)
0x0000002C4 bytesMaximum horizontal rate (Subsection 7.3.3. 2D Variable Analogue Timing Minimum and Maximimum Horizontal Rate)
0x000000304 bytesMaximum pixel clock (Subsection 7.3.4. 2D Variable Analogue Timing Maximimum Pixel Clock)
0x000000344 bytesMaximum active pixels per line (Subsection 7.3.5. 2D Variable Analogue Timing Maximimum Active Pixels Per Line.)
0x000000384 bytesMaximum active lines (Subsection 7.3.6. 2D Variable Analogue Timing Maximimum Active Lines)
0x0000003C4 bytesMinimum horizontal rate for secondary GTF (Subsection 7.3.7. 2D Variable Analogue Timing Minimum Horizontal Rate for Secondary GTF)
0x000000402 byteM for secondary GTF (Subsection 7.3.8. 2D Variable Analogue Timing Secondary GTF Constants (M, K, C, J))
0x000000421 byteK for secondary GTF (Subsection 7.3.8. 2D Variable Analogue Timing Secondary GTF Constants (M, K, C, J))
0x000000431 byteC for secondary GTF (Subsection 7.3.8. 2D Variable Analogue Timing Secondary GTF Constants (M, K, C, J))
0x000000441 byteJ for secondary GTF (Subsection 7.3.8. 2D Variable Analogue Timing Secondary GTF Constants (M, K, C, J))

7.3.1. 2D Variable Analogue Timing Flags

These flags determine how variable timing is achieved, and are described by in Table 7-8. 2D Variable Analogue Timing Flag Meanings.

Table 7-8. 2D Variable Analogue Timing Flag Meanings
Bit/sMeaning
0Indicates the display supports VESA's default GTF (Generalised Timing Forumla) when set
1Indicates the display supports VESA's secondary GTF when set. Note: Display must support default GTF if it supports secondary GTF.
2 to 3Reserved
4Indicates the display supports VESA's CVT (Coordinated Video Timings) with standard blanking when set
5Indicates the display supports VESA's CVT with reduced blanking when set
6 to 15Reserved

7.3.2. 2D Variable Analogue Timing Minimum and Maximimum Field Rate

The minimum and maximum field rate is stored in 65536ths of a Hertz units (or Hertz in 16.16 fixed point format). For example, the value 0xFFFFFFFF represents approximately 65535.999985 Hz and the value 0x003C0000 represents 60.000 Hz. The minimum field rate must be lower than or equal to the maximum field rate.

7.3.3. 2D Variable Analogue Timing Minimum and Maximimum Horizontal Rate

The minimum and maximum horizontal rate is stored in Hertz.

7.3.4. 2D Variable Analogue Timing Maximimum Pixel Clock

The maximum pixel clock frequency is stored in Hertz.

7.3.5. 2D Variable Analogue Timing Maximimum Active Pixels Per Line.

The maximum active pixels per line is stored naturally. The value 0x00000000 signifies that the maximum active pixels per line is unknown. The value 0xFFFFFFFF signifies that the maximum active pixels per line is unlimited.

7.3.6. 2D Variable Analogue Timing Maximimum Active Lines

The maximum active lines is stored naturally. The value 0x00000000 signifies that the maximum active lines is unknown. The value 0xFFFFFFFF signifies that the maximum active lines is unlimited.

7.3.7. 2D Variable Analogue Timing Minimum Horizontal Rate for Secondary GTF

The minimum horizontal rate for secondary GTF is stored in Hertz; and must be within the range described by the minimum and maximum horizontal rate (see Subsection 7.3.3. 2D Variable Analogue Timing Minimum and Maximimum Horizontal Rate).

This field is unused/reserved if the corresponding flag indicates that secondary GTF is not supported (see Subsection 7.3.1. 2D Variable Analogue Timing Flags).

7.3.8. 2D Variable Analogue Timing Secondary GTF Constants (M, K, C, J)

These are the constants used by VESA's secondary GTF formulas. The constants M and K are stored naturally (with ranges from 0 to 65535 and from 0 to 255 respectively). The constants C and J are both halved, such that 0x80 represents 64, and both constants range from 0 to 127.5.

Chapter 8: Colour Data Entry Format

Each entry begins with 2 standard fields described in Section 8.1. Colour Data Entry Format Standard Fields followed by other fields that are determined from the entry's type.

8.1. Colour Data Entry Format Standard Fields

The standard fields used in all colour data entry types are described in Table 8-1. Colour Data Entry Standard Fields.

Table 8-1. Colour Data Entry Standard Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 8.1.1. Colour Data Entry Size)
0x000000022 bytesEntry Type (Subsection 8.1.2. Colour Data Entry Type)
0x000000044 bytesMax. Luminous Intensity (Subsection 8.1.3. Maximum Luminous Intensity)
0x000000084 bytesMin. Luminous Intensity (Subsection 8.1.4. Minimum Luminous Intensity)

8.1.1. Colour Data Entry Size

This field contains the total size of the entry (including any padding), and allows software to find all entries (even when software doesn't support the entry's type).

8.1.2. Colour Data Entry Type

This field determines the type of the entry, and the format of all additional data for the entry. Entry types are described in Table 8-2. Colour Data Entry Types.

Table 8-2. Colour Data Entry Types
ValueDescription
0x0000Multi-channel (Section 8.2. Colour Data Entry Type 0x0000, Multi-Channel)

8.1.3. Maximum Luminous Intensity

This field contains the maximum luminous intensity (light emitted per unit area for the brightest white the display can support), in 65536ths of a candela per square metre (cd/m2) units (or cd/m2 in 16.16 fixed point format). For example, the value 0xFFFFFFFF represents approximately 65535.999985 cd/m2 and the value 0x00500000 represents 80 cd/m2. The value 0x00000000 is used for "unknown".

8.1.4. Minimum Luminous Intensity

This field contains the minimum luminous intensity (light emitted per unit area for the brightest white the display can support), in 65536ths of a candela per square metre (cd/m2) units (or cd/m2 in 16.16 fixed point format). For example, the value 0xFFFFFFFF represents approximately 65535.999985 cd/m2 and the value 0x00500000 represents 80 cd/m2. The value 0x00000000 is used for "unknown".

The minimum luminous intensity should be measured by setting all pixels to "black" except for one pixel in the middle of the display that should be set to "brightest white", then measuring luminous intensity for the entire screen (including the white pixel) and subtracting "maximum luminous intensity / number of pixels" from the value measured. This method is intended to mitigate some of the error caused by monitors that do blacklight dimming (where if the minimum luminous intensity was measured when all pixels are black it'd be impossible to achieve that minimum in actual images).

8.2. Colour Data Entry Type 0x0000, Multi-Channel

This colour data entry type is used for generic "1 or more channels" where each channel is independent and can be described in a standard way. For this entry type; the format for the colour data entry is described in Table 8-3. Multi-Channel Fields.

Table 8-3. Multi-Channel Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 8.1.1. Colour Data Entry Size)
0x000000022 bytesEntry Type (Subsection 8.1.2. Colour Data Entry Type)
0x000000044 bytesMax. Luminous Intensity (Subsection 8.1.3. Maximum Luminous Intensity)
0x000000084 bytesMin. Luminous Intensity (Subsection 8.1.4. Minimum Luminous Intensity)
0x0000000C2 bytesGamma Value (Subsection 8.2.1. Gamma Value)
0x0000000E2 bytesNumber of Channels/Channel Descriptors (Subsection 8.2.2. Number of Channels/Channel Descriptors)
0x00000010VariesChannel Descriptors

8.2.1. Gamma Value

This field stores the gamma value that is used (by channel descriptors that use gamma encoding) in 4096ths (or in 4.12 fixed point format). For example, the value 0xFFFF represents a gamma of 15.999755859375 and the value 0x2333 represents a gamma of 2.199951171875.

The value 0x0000 is treated specially to represent the gamma ramp defined by the sRGB specification.

8.2.2. Number of Channels/Channel Descriptors

This field just determines the number of channels (and the number of channel descriptors) present.

8.2.3. Channel Descriptors

Each channel descriptor has the format described in Table 8-4. Channel Descriptor Format.

Table 8-4. Channel Descriptor Format
OffsetSizeDescription
0x000000002 byteDescrete Levels (see Subsubsection 8.2.3.1. Channel Descriptor Descrete Levels)
0x000000022 bytesUnused/reserved
0x000000044 bytesX multiplier (see Subsubsection 8.2.3.2. Channel Descriptor X, Y and Z Multipliers)
0x000000084 bytesY multiplier (see Subsubsection 8.2.3.2. Channel Descriptor X, Y and Z Multipliers)
0x0000000C4 bytesZ multiplier (see Subsubsection 8.2.3.2. Channel Descriptor X, Y and Z Multipliers)
8.2.3.1. Channel Descriptor Descrete Levels

This field describes how many levels of data values the channel actually supports, minus 1. For example, if the channel is used for "Green" and the display can only show 10 levels of green, then this field would be set to 9 in the corresponding channel descriptor. The value 0xFFFF means "greater than 65535 levels" (e.g. a true analogue display with no effective limit).

Note: Often a display will only handle (e.g.) 6 bits of data per primary channel, and if the OS and/or video driver knows this it can choose a more efficient video mode (e.g. a video mode with 6 bits of data per primary channel instead of a video mode with 8 bits of data per primary channel), and may also use techniques (dithering) to artificially increase the range of representable colours beyond the video mode and monitor's limits.

8.2.3.2. Channel Descriptor X, Y and Z Multipliers

Each of these multipliers is a signed 32-bit integer in 16777216ths (or 7.24 fixed point format where the highest bit is the sign)

Note that graphics are generated for a device independent CIE_XYZ colour space, where X, Y and Z is normalised to the range 0 to 1. This is converted to the device dependent colour space by using the following formula for each channel:

The raw value is then gamma encoded (see Subsection 8.2.1. Gamma Value) to get the actual value sent to the display.

For information on how to calculate the multipliers used in channel descriptors, see Section 8.3. Calculating Multiplier Values for Channel Descriptors.

8.3. Calculating Multiplier Values for Channel Descriptors

In general, the conversion from one colour space to another involves 2 steps. The first step is changing the primary colours, and the second is "chromatic adaptation" (changing the white point). Both of these steps typically use conversion matrices, and both of these conversion matrices can be pre-multiplied to obtain a single matrix that does both steps.

The values used in channel descriptors are just the values from this "matrix that does both steps".

More specifically; graphics are generated for a device independent CIE_XYZ colour space that uses a D65 white point; and the values used in channel descriptors are values taken from a matrix that would convert "XYZ with D65 white point" into the device's colour space. For both colour spaces the values are linear values (gamma encoding is applied after conversion to the device's colour space).

Note that while there are multiple different chromatic adaptations (XYZ Scaling, Von Kries, Bradford, etc) only the Bradford method should be used.

Chapter 9: Pixel Mapping Mesh Entry Format

If graphics are generated for a flat rectangle and then displayed on a surface that isn't a flat rectangle, the result is a distorted image. A pixel mapping mesh describes how pixels (arranged as a 2 dimensional array) are mapped to locations in a physical 3 dimensional space (the real world); so that graphics can be generated taking the size and shape of the display into account and prevent distortion.

Note that even when the display is a flat rectangle, it's possible (in theory) that the pixels aren't regularly spaced (e.g. smaller pixels in the center of the display and larger pixels near the edges; possibly to improve resolution near the center of the user's field of vision where it matters the most).

A single display device may need multiple pixel mapping meshes for a variety of reasons. For example, a display with a 4:3 aspect ratio might use "letter boxing" for 16:10 and 16:9 video modes where the pixels mapping mesh depends on the video mode. In addition, for stereoscopic displays there may need to be a different pixel mapping mesh for the left and right eyes. For this reason a list of entries are used (where each entry describes one pixel mapping mesh) and a specific pixel mapping mesh is selected via. an index.

Each entry begins with 2 standard fields described in Section 9.1. Pixel Mapping Mesh Entry Format Standard Fields followed by other fields that are determined from the entry's type.

9.1. Pixel Mapping Mesh Entry Format Standard Fields

The standard fields used in all pixel mappping mesh entry types are described in Table 9-1. Pixel Mapping Mesh Entry Standard Fields.

Table 9-1. Pixel Mapping Mesh Entry Standard Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 9.1.1. Pixel Mapping Mesh Entry Size)
0x000000022 bytesEntry Type (Subsection 9.1.2. Pixel Mapping Mesh Entry Type)

9.1.1. Pixel Mapping Mesh Entry Size

This field contains the total size of the entry (including any padding), and allows software to find all entries (even when software doesn't support the entry's type).

9.1.2. Pixel Mapping Mesh Entry Type

This field determines the type of the entry, and the format of all additional data for the entry. Entry types are described in Table 9-2. Pixel Mapping Mesh Entry Types.

Table 9-2. Pixel Mapping Mesh Entry Types
ValueDescription
0x0000Regular Flat Rectangular (Section 9.2. Pixel Mapping Mesh Type 0x0000, Regular Flat Rectangular)
0x0001Linear Mesh (Section 9.3. Pixel Mapping Mesh Type 0x0001, Linear Mesh)
0x0002Quadratic Bezier Mesh (Section 9.4. Pixel Mapping Mesh Type 0x0002, Quadratic Bezier Mesh)

9.2. Pixel Mapping Mesh Type 0x0000, Regular Flat Rectangular

Rectangular flat displays with regularly spaced pixels are very common, and far simpler to describe than other monitor shapes - the only values needed are the width and height of the active display surface. The entry format is described in Table 9-3. Regular Flat Rectangular Fields.

Table 9-3. Regular Flat Rectangular Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 9.1.1. Pixel Mapping Mesh Entry Size)
0x000000022 bytesEntry Type (Subsection 9.1.2. Pixel Mapping Mesh Entry Type, must be 0x0000)
0x000000044 bytesDisplay Width (Subsection 9.2.1. Regular Flat Rectangular Display Width and Height)
0x000000084 bytesDisplay Height (Subsection 9.2.1. Regular Flat Rectangular Display Width and Height)

9.2.1. Regular Flat Rectangular Display Width and Height

These values are the actual size in meters, stored in 16.16 fixed point format. The value 0x00000001 represents 1/65536th of a meter (approximately 15.26 micrometers), and the value 0xFFFFFFFF represents almost (1/65536th of a meter less than) 65536 meters. The value 0x00000000 is used for "unknown".

9.3. Pixel Mapping Mesh Type 0x0001, Linear Mesh

For linear meshes; the 2D grid of pixels is split into 1 or more arbitrary height rows and one or more arbitrary width columns; and control points are placed at each point where the edge of a row crosses the edge of a column. For example, with 3 columns and 3 rows you'd have the 4*4 grid of control points shown in Figure 9-1. Linear Mesh Control Points Example.

Figure 9-1. Linear Mesh Control Points Example
 
 P00--------P01---P02--------P03
  |          |     |          |
  |          |     |          |
  |          |     |          |
  |          |     |          |
  |          |     |          |
 P10--------P11---P12--------P13
  |          |     |          |
  |          |     |          |
 P20--------P21---P22--------P23
  |          |     |          |
  |          |     |          |
  |          |     |          |
  |          |     |          |
  |          |     |          |
 P30--------P31---P32--------P33
 

Each of these control points determine where a point in the 2D grid of pixels is mapped to a location in the physical 3 dimensional space (the real world). A video driver uses interpolation between control points to determine where any point in the 2D grid of pixels is mapped to a location in the physical 3 dimensional space.

The pixel mapping mesh entry format for linear meshes is shown in Table 9-4. Linear Mesh Fields.

Table 9-4. Linear Mesh Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 9.1.1. Pixel Mapping Mesh Entry Size)
0x000000022 bytesEntry Type (Subsection 9.1.2. Pixel Mapping Mesh Entry Type, must be 0x0001)
0x000000042 bytesNumber of Columns (Subsection 9.3.1. Linear Mesh Number of Columns and Number of Rows)
0x000000062 bytesNumber of Rows (Subsection 9.3.1. Linear Mesh Number of Columns and Number of Rows)
0x00000008VariesColumn Width Array (Subsection 9.3.2. Linear Mesh Column Width Array)
VariesVariesRow Height Array (Subsection 9.3.3. Linear Mesh Row Height Array)
VariesVariesControl Point Location Grid (Subsection 9.3.4. Linear Mesh Control Point Location Grid)

9.3.1. Linear Mesh Number of Columns and Number of Rows

These fields contain the number of columns and the number of rows. The value 0x0000 is not valid (there must be at least one column and at least one row).

9.3.2. Linear Mesh Column Width Array

This field contains an array of column widths, where each column width is a 32-bit unsigned integer. The widths of all columns must add up to 0x0000000100000000 (where 0x0000000100000000 represents the full width of the 2D grid of pixels); and the width of the last column is inferred. This means that the total size of the array is "(columns - 1) * 4" bytes.

For example, if there is only one column then the column width array consumes zero bytes, and that column is assumed to be 0x0000000100000000 units wide. If there are 2 equal size columns then the column width array consumes 4 bytes, the first/only entry in the array would be the value 0x80000000, and the second columns width would be calculated as "0x0000000100000000 - 0x80000000 = 0x80000000" units. If there are 3 columns of different sizes the column width array consumes 8 bytes, and if the first entry (for the first/left-most column's width) is 0x10000000 and the second entry (for the second/middle column's width) is 0x20000000 then the width of the last/right-most column is 0xD0000000 units (e.g. 0x0000000100000000 - 0x10000000 - 0x20000000 = 0xD0000000).

If the sum of the columns widths in the array is greater than or equal to 0x0000000100000000 the data is invalid. For example, if there are 4 columns where the widths of the first 3 columns are 0x50000000, 0x60000000 and 0x70000000, then the width of the last/implied column is less than zero and therefore the column width array is invalid; and if there are 4 columns where the widths of the first 3 columns are 0x40000000, 0x40000000 and 0x80000000, then the width of the last/implied column is zero and therefore the column width array is invalid.

9.3.3. Linear Mesh Row Height Array

This field contains an array of row heights, where each row height is a 32-bit unsigned integer. The heights of all rows must add up to 0x0000000100000000 (where 0x0000000100000000 represents the full height of the 2D grid of pixels); and the height of the last row is inferred. This means that the total size of the array is "(rows - 1) * 4" bytes. If the sum of the row heights in the array is greater than or equal to 0x0000000100000000 the data is invalid. Note: This is identical to the column width array described in Subsection 9.3.2. Linear Mesh Column Width Array, except that it describes rows and not columns.

9.3.4. Linear Mesh Control Point Location Grid

This field contains an array of control points (as described in Figure 9-1. Linear Mesh Control Points Example), in order of left to right then top to bottom. The total size of the array is "(columns + 1) * (rows + 1) * 16" bytes.

Each entry in the array/grid has the format described in Table 9-5. Linear Mesh Control Point Format.

Table 9-5. Linear Mesh Control Point Format
OffsetSizeDescription
0x000000004 bytesX Position (Subsubsection 9.3.4.1. Linear Mesh Control Point X, Y and Z Positions)
0x000000024 bytesY Position (Subsubsection 9.3.4.1. Linear Mesh Control Point X, Y and Z Positions)
0x000000044 bytesZ Position (Subsubsection 9.3.4.1. Linear Mesh Control Point X, Y and Z Positions)
9.3.4.1. Linear Mesh Control Point X, Y and Z Positions

These fields describe the position of a control point in the physical 3 dimensional space (the real world), and are relative to the center of the display.

The values are the actual size in meters, stored in signed 16.16 fixed point format. For the X position, negative values represent "left of center" and positive values represent "right of center" (from the perspective of a user looking at the center point); for the Y position negative values represent "below the center" and positive values represent "above the center"; and for the Z position negative values represent "closer than the center" while positive values represent "further that the center".

The value 0x00000001 represents 1/65536th of a meter (approximately 15.26 micrometers), the value 0x7FFFFFFF represents almost (1/65536th of a meter less than) 32768 meters, and the value 0x80000000 represents 32768 meters (in the negative direction).

For example, if X is -0x00000100, Y is 0x00000300 and Z is 0x00000080, then the point is 3.90625 mm to the left of center, 11.71875 mm above the center and 1.953125 mm further away than the center.

9.4. Pixel Mapping Mesh Type 0x0002, Quadratic Bezier Mesh

A quadratic Bezier meshes is similar to the linear mesh described in Section 9.3. Pixel Mapping Mesh Type 0x0001, Linear Mesh; except that there are additional intermediate points "between" each pair of adjacent control points to control curvature. For example, with 3 columns and 3 rows you'd have the 7*7 grid of points shown in Figure 9-2. Quadratic Bezier Mesh Control Points Example.

Figure 9-2. Quadratic Bezier Mesh Control Points Example
 
  P00----I0001----P01--I0102--P02----I0203----P03
   |               |           |               |
   |               |           |               |
   |               |           |               |
 I0010    I00    I0111  I01  I0212    I02    I0313
   |               |           |               |
   |               |           |               |
   |               |           |               |
  P10----I1011----P11--I1112--P12----I1213----P13
   |               |           |               |
   |               |           |               |
 I1020    I10    I1121  I11  I1222    I12    I1323
   |               |           |               |
   |               |           |               |
  P20----I2021----P21--I2122--P22----I2223----P23
   |               |           |               |
   |               |           |               |
   |               |           |               |
 I2030    I20    I2131  I21  I2232    I22    I2333
   |               |           |               |
   |               |           |               |
   |               |           |               |
  P30----I3031----P31--I3132--P32----I3233----P33
 

The pixel mapping mesh entry format for quadratic bezier meshes is shown in Table 9-6. Quadratic Bezier Mesh Fields.

Table 9-6. Quadratic Bezier Mesh Fields
OffsetSizeDescription
0x000000002 bytesEntry Size (Subsection 9.1.1. Pixel Mapping Mesh Entry Size)
0x000000022 bytesEntry Type (Subsection 9.1.2. Pixel Mapping Mesh Entry Type, must be 0x0001)
0x000000042 bytesNumber of Columns (Subsection 9.4.1. Quadratic Bezier Mesh Number of Columns and Number of Rows)
0x000000062 bytesNumber of Rows (Subsection 9.4.1. Quadratic Bezier Mesh Number of Columns and Number of Rows)
0x00000008VariesColumn Width Array (Subsection 9.4.2. Quadratic Bezier Mesh Column Width Array)
VariesVariesRow Height Array (Subsection 9.4.3. Quadratic Bezier Mesh Row Height Array)
VariesVariesControl Point Location Grid (Subsection 9.4.4. Quadratic Bezier Mesh Control Point Location Grid)

9.4.1. Quadratic Bezier Mesh Number of Columns and Number of Rows

These fields contain the number of columns and the number of rows. The value 0x0000 is not valid (there must be at least one column and at least one row).

9.4.2. Quadratic Bezier Mesh Column Width Array

This field contains an array of column widths, where each column width is a 32-bit unsigned integer. The widths of all columns must add up to 0x0000000100000000 (where 0x0000000100000000 represents the full width of the 2D grid of pixels); and the width of the last column is inferred. This means that the total size of the array is "(columns - 1) * 4" bytes.

For example, if there is only one column then the column width array consumes zero bytes, and that column is assumed to be 0x0000000100000000 units wide. If there are 2 equal size columns then the column width array consumes 4 bytes, the first/only entry in the array would be the value 0x80000000, and the second columns width would be calculated as "0x0000000100000000 - 0x80000000 = 0x80000000" units. If there are 3 columns of different sizes the column width array consumes 8 bytes, and if the first entry (for the first/left-most column's width) is 0x10000000 and the second entry (for the second/middle column's width) is 0x20000000 then the width of the last/right-most column is 0xD0000000 units (e.g. 0x0000000100000000 - 0x10000000 - 0x20000000 = 0xD0000000).

If the sum of the columns widths in the array is greater than or equal to 0x0000000100000000 the data is invalid. For example, if there are 4 columns where the widths of the first 3 columns are 0x50000000, 0x60000000 and 0x70000000, then the width of the last/implied column is less than zero and therefore the column width array is invalid; and if there are 4 columns where the widths of the first 3 columns are 0x40000000, 0x40000000 and 0x80000000, then the width of the last/implied column is zero and therefore the column width array is invalid.

9.4.3. Quadratic Bezier Mesh Row Height Array

This field contains an array of row heights, where each row height is a 32-bit unsigned integer. The heights of all rows must add up to 0x0000000100000000 (where 0x0000000100000000 represents the full height of the 2D grid of pixels); and the height of the last row is inferred. This means that the total size of the array is "(rows - 1) * 4" bytes. If the sum of the row heights in the array is greater than or equal to 0x0000000100000000 the data is invalid. Note: This is identical to the column width array described in Subsection 9.3.2. Linear Mesh Column Width Array, except that it describes rows and not columns.

9.4.4. Quadratic Bezier Mesh Control Point Location Grid

This field contains an array of control points (as described in Figure 9-2. Quadratic Bezier Mesh Control Points Example), in order of left to right then top to bottom. The total size of the array is "(columns*2 + 1) * (rows*2 + 1) * 16" bytes.

Each entry in the array/grid has the format described in Table 9-7. Quadradic Bezier Mesh Control Point Format.

Table 9-7. Quadradic Bezier Mesh Control Point Format
OffsetSizeDescription
0x000000004 bytesX Position (Subsubsection 9.4.4.1. Quadradic Bezier Mesh Control Point X, Y and Z Positions)
0x000000024 bytesY Position (Subsubsection 9.4.4.1. Quadradic Bezier Mesh Control Point X, Y and Z Positions)
0x000000044 bytesZ Position (Subsubsection 9.4.4.1. Quadradic Bezier Mesh Control Point X, Y and Z Positions)
9.4.4.1. Quadradic Bezier Mesh Control Point X, Y and Z Positions

These fields describe the position of a control point or intermediate point in the physical 3 dimensional space (the real world), and are relative to the center of the display. Note that the display's surface passes through control points but not intermediate points, and the intermediate points only define the curve of the surface between control points.

The values are the actual size in meters, stored in signed 16.16 fixed point format. For the X position, negative values represent "left of center" and positive values represent "right of center" (from the perspective of a user looking at the center point); for the Y position negative values represent "below the center" and positive values represent "above the center"; and for the Z position negative values represent "closer than the center" while positive values represent "further that the center".

The value 0x00000001 represents 1/65536th of a meter (approximately 15.26 micrometers), the value 0x7FFFFFFF represents almost (1/65536th of a meter less than) 32768 meters, and the value 0x80000000 represents 32768 meters (in the negative direction).

For example, if X is -0x00000100, Y is 0x00000300 and Z is 0x00000080, then the point is 3.90625 mm to the left of center, 11.71875 mm above the center and 1.953125 mm further away than the center.

Generated at 03:38:34 on the 19th of June, 2017 (UTC)