A method for converting HDMI2.1 high refresh rate EDID into HDMI2.0 EDID

CN122435902APending Publication Date: 2026-07-21SHENZHEN BAYUE SOFTWARE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHENZHEN BAYUE SOFTWARE CO LTD
Filing Date
2026-03-19
Publication Date
2026-07-21

Smart Images

  • Figure CN122435902A_ABST
    Figure CN122435902A_ABST
Patent Text Reader

Abstract

The application relates to the technical field of EDID conversion, in particular to a method for converting HDMI2.1 high refresh rate EDID into HDMI2.0 EDID, which analyzes HDMI2.1 EDID to generate a refresh rate list and backup a timing descriptor, evaluates EDID space capacity and releases space occupied by unnecessary information, processes super bandwidth video format through protocol degradation, adjusts data structure to 256 bytes, optimizes data structure and preferentially retains a high refresh rate mode, completes high refresh rate timing and outputs 256-byte EDID conforming to the HDMI2.0 standard, the method for converting HDMI2.1 high refresh rate EDID into HDMI2.0 EDID intelligently converts and reconstructs the extended display identification data of the HDMI2.1 device, realizes the target of compatible new generation high refresh rate display devices without changing the existing HDMI2.0 extender hardware architecture, forms a target list by analyzing all supported refresh rates in the original EDID, combines the protocol degradation and space optimization mechanism, dynamically adjusts the timing parameters exceeding the HDMI2.0 bandwidth and generates new timing descriptions conforming to the specifications.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of EDID conversion technology, specifically a method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID. Background Technology

[0002] With the iterative upgrade of the HDMI interface standard from version 2.0 to 2.1, the performance parameters of display devices have been significantly improved. The 48Gbps high bandwidth supported by the HDMI 2.1 protocol allows the transmission of higher resolution, higher refresh rates, and enhanced dynamic range video signals. Its accompanying EDID data structure has also been expanded from the traditional 256 bytes to 384 or 512 bytes to describe complex display modes. However, due to early hardware design limitations, the widely deployed HDMI 2.0 extenders on the market are only equipped with 256 bytes of EDID storage space, making it impossible to fully read the EDID information when interfacing with new-generation HDMI 2.1 devices. Existing technologies typically use direct truncation of the excessively long EDID, allowing the source device to only obtain the first 256 bytes of data, resulting in the loss of key display mode description information such as high refresh rates and high resolutions. This processing method not only fails to retain gaming-grade refresh rate parameters such as 144Hz and 165Hz, but also cannot parse the data block structures defined by new standards such as VESA DisplayID 2.0 due to outdated protocol stacks. When users are using high-end gaming consoles or high-performance graphics cards, the system is forced to downgrade to a low refresh rate mode because it cannot correctly recognize the monitor's true capabilities, severely limiting the full utilization of hardware performance. Furthermore, the traditional solution's simple omission of timing parameters may cause EDID verification errors, leading to decreased signal transmission stability or even display abnormalities. While hardware upgrades can fundamentally solve compatibility issues, they involve a large number of device replacements and costly investments, making it difficult to meet the needs of a smooth transition for existing infrastructure. Therefore, how to achieve compatible EDID conversion for the new protocol within the existing HDMI 2.0 extender hardware framework has become a pressing technical challenge for the industry.

[0003] To address this, a method is proposed to convert the EDID of HDMI 2.1 high refresh rate to HDMI 2.0 EDID. Summary of the Invention

[0004] One of the technical problems this application aims to solve is how to achieve compatibility conversion of the new protocol EDID within the existing HDMI 2.0 extender hardware framework, which has become a technical challenge that the industry urgently needs to overcome.

[0005] To address the aforementioned technical problems, this application provides a method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID, comprising the following steps: S1: Information Acquisition and Backup. Call the GetAllRefreshRate module, traverse the original HDMI2.1 EDID through the parsing module, record all supported refresh rates to form a target refresh rate list, and back up all detailed timing descriptors (DTDs). S2: Space assessment, calculates the structural capacity of the 256-byte HDMI 2.0 standard EDID, and assesses the additional space that can be freed up after removing unnecessary information; S3: Protocol downgrade and capability conversion, calls the Limits module, traverses all data blocks, converts or discards video formats that exceed the bandwidth and capability range of HDMI 2.0, and initially sets the EDID data structure size to 256 bytes; S4: Space optimization and intelligent reconstruction, performing deletion, redundancy removal, information simplification, format conversion and selective discarding operations according to preset priorities, retaining high-priority display modes; S5: High refresh rate completion and final verification. Compare the list of supported refresh rates and target refresh rates after reconstruction of EDID. For unsupported high refresh rates, generate timing through CVT1.2 module or find the corresponding VIC, re-execute the space judgment and optimization of S4, and finally output a 256-byte EDID that conforms to the HDMI2.0 standard.

[0006] In some embodiments, the parsing module in S1 includes the EDID1.3 & 1.4 module, the CTA-861-H module, and the DisplayID1.3 & 2.0 module; Traversing the original HDMI2.1 EDID includes: traversing the Establishing Timings, Standard Timings, Detailed Timings and CVT Timings fields in the EDID1.4 Block, traversing the Detailed Timings, Video Data Block, HDMI1.4b Vendor Specific DataBlock, YCbCr 4:2:0 Video Data Block, YCbCr 4:2:0 Capability Map in the CTA-861 ExtensionBlock. Data Block, DisplayID Type VII Video Timing Data Block, DisplayID Type VIII Video TimingData Block, DisplayID Type Data Block, TypeVII Detailed TimingData The Block, Type VIII Detailed Timing Data Block, and Type IX Detailed Timing Data Block are parsed and the supported frame rates are extracted.

[0007] In some embodiments, the non-essential information in S2 includes Display Color Management (DCM) Data, Color Point Data, Display Range Limits, Alphanumeric DataString (ASCII), and Display Product Serial Number in the EDID 1.4 Block.

[0008] In some embodiments, the processing procedure of the Limits module in S3 is as follows: traverse all timings, calculate the TMDS Clock corresponding to each timing, if the TMDS Clock exceeds 600MHz, first convert the Colorspace to YCbCr 4:2:0 or reduce the FrameRate to reduce the TMDS Clock, if it is still impossible to make the TMDS Clock ≤ 600MHz, then discard the timing; wherein, the TMDS Clock corresponding to DTD is calculated according to the formula TMDS Clock = Htotal × Btotal × FrameRate × BitsPerPixel, where Htotal is the total number of horizontal pixels, Btotal is the total number of vertical rows, FrameRate is the frame rate, BitsPerPixel is the pixel width, the TMDS Clock corresponding to VIC is obtained by looking up a table, and the TMDS Clock corresponding to CVT is calculated by the VESA CVT 1.2 standard algorithm.

[0009] In some embodiments, the preset priority order in S4 is as follows: first delete DTDs that cannot be supported by Block0 and Block1, then delete redundant DTDs with the same resolution, then delete unnecessary description fields, then perform format conversion, and finally discard low-priority display modes according to the high-priority display mode retention strategy.

[0010] In some embodiments, the format conversion in S4 converts the DTD, which occupies 18 bytes of storage space, into a 1-byte VIC format or a 6-byte TypeX (CVT description) format.

[0011] In some embodiments, the timing sequence generated in S5 by the CVT1.2 module is generated according to the algorithm principle in the VESA Coordinated Video Timings (CVT) Standard Version 1.2 document to generate the corresponding video format timing sequence.

[0012] In some embodiments, the EDID1.3 & 1.4 modules provide interfaces for parsing and modifying the EDID base block, the CTA-861-H module provides interfaces for parsing and modifying the CTA-861-H extension block, and the DisplayID1.3 & 2.0 modules provide interfaces for parsing and modifying the DisplayID extension block.

[0013] In some embodiments, the high-priority display mode retention strategy in S4 prioritizes high refresh rates and then high resolutions, prioritizing display modes corresponding to high refresh rates such as 144Hz and 165Hz.

[0014] In some embodiments, the non-essential description fields in S4 are fields in EDID that do not affect display mode recognition and signal transmission compatibility, including manufacturer redundancy information and non-core product identification information.

[0015] This invention has at least the following beneficial effects: 1. By intelligently converting and reconstructing the extended display identification data of HDMI 2.1 devices, the goal of being compatible with the next generation of high refresh rate display devices is achieved without changing the existing HDMI 2.0 extender hardware architecture. By parsing all supported refresh rates in the original EDID to form a target list, and combining protocol downgrading and space optimization mechanisms, timing parameters that exceed the HDMI 2.0 bandwidth are dynamically adjusted and new timing descriptions that conform to the specifications are generated.

[0016] 2. In terms of data structure processing, strategies such as prioritizing the removal of redundant information, converting to a compact format descriptor, and dynamically supplementing key refresh rates are adopted to ensure that the generated 256-byte EDID retains the core parameters of high refresh rate and high resolution modes to the greatest extent. Through strict bandwidth compliance verification and data structure integrity verification, the loss of advanced display features caused by traditional truncation methods is effectively avoided. This method enables a large number of deployed HDMI 2.0 extenders to directly support high refresh rate scenarios of 144Hz and above, solving the mode degradation limitation caused by EDID mismatch between display devices and signal sources.

[0017] 3. Users can fully utilize the performance potential of high-end monitors without replacing existing hardware, significantly improving responsiveness to high frame rate display demands in fields such as esports and professional design. Furthermore, the EDID generated by this solution fully complies with the HDMI 2.0 standard, eliminating device compatibility risks caused by non-standard data formats and ensuring long-term stability of video signal transmission. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the method steps of the present invention; Figure 2 A schematic diagram illustrating the specific implementation steps of the strategy for reserving high-priority display modes in S4; Figure 3 This is a schematic diagram of the overall process of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Example 1, see Figures 1-2 This invention provides a technical solution: a method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID, comprising the following steps: S1: Information Acquisition and Backup. Call the GetAllRefreshRate module, traverse the original HDMI2.1 EDID through the parsing module, record all supported refresh rates to form a target refresh rate list, and back up all detailed timing descriptors (DTDs). S2: Space assessment, calculates the structural capacity of the 256-byte HDMI 2.0 standard EDID, and assesses the additional space that can be freed up after removing unnecessary information; S3: Protocol downgrade and capability conversion, calls the Limits module, traverses all data blocks, converts or discards video formats that exceed the bandwidth and capability range of HDMI 2.0, and initially sets the EDID data structure size to 256 bytes; S4: Space optimization and intelligent reconstruction, performing deletion, redundancy removal, information simplification, format conversion and selective discarding operations according to preset priorities, retaining high-priority display modes; S5: High refresh rate completion and final verification. Compare the list of supported refresh rates and target refresh rates after reconstruction of EDID. For unsupported high refresh rates, generate timing through CVT1.2 module or find the corresponding VIC, re-execute the space judgment and optimization of S4, and finally output a 256-byte EDID that conforms to the HDMI2.0 standard.

[0021] Specifically, the core principle is to maximize the retention of high-value display information in HDMI 2.1 EDID within the 256-byte EDID space limit of the HDMI 2.0 protocol through a closed-loop process of "comprehensive acquisition - precise screening - efficient adaptation - completion verification". HDMI 2.1 EDID uses a larger storage capacity because it supports more high-performance display modes, while existing HDMI 2.0 extenders only support 256-byte EDID read and write and cannot parse the new protocol descriptor. Therefore, the design must take into account protocol compatibility, space utilization, and performance retention, which is the common starting point for each step of the design.

[0022] The design principle of S1 information acquisition and backup is based on the multi-block structure of HDMI 2.1 EDID. Key information such as high refresh rates is scattered across different areas, including the EDID base block, CTA-861-H extension block, and DisplayID extension block. A dedicated parsing module is needed to traverse all relevant fields to capture this information completely. The goal is to comprehensively understand all refresh rates and detailed timing parameters supported by the original EDID, forming a complete "target refresh rate list" and DTD backup. This provides a clear reference benchmark for subsequent optimization, preventing the loss of high-value display modes due to information omissions. The benefit of this step is that it ensures a complete understanding of the display device's true performance from the source. All subsequent optimization operations can revolve around the user's core needs (high refresh rate, high resolution) rather than blindly filtering or deleting data.

[0023] The design principle of S2 space assessment is based on the fixed capacity limit of 256 bytes for HDMI 2.0 EDID, while simultaneously exploring the free space available for non-essential information within the EDID structure. EDID data includes fields such as manufacturer information, serial numbers, and some color management data that do not directly affect display mode recognition and signal transmission; deleting these fields will not affect the core functionality of the EDID. The goal is to accurately calculate the actual space available for storing critical display modes, clearly defining the "upper limit of usable capacity," and providing a quantitative basis for subsequent protocol downgrading, format conversion, and information selection. The advantage of this step is that it avoids blind operations in subsequent steps; it prevents the excessive deletion of useful information due to underestimating space, and also prevents the reconstructed EDID from exceeding the 256-byte limit due to overestimating space, ensuring more targeted space allocation.

[0024] The design principle of S3 protocol downgrade and capability conversion is based on the bandwidth difference between HDMI 2.0 and HDMI 2.1. HDMI 2.0 has a maximum bandwidth of 18Gbps, corresponding to a TMDS Clock limit of 600MHz. Video formats exceeding this range cannot be stably transmitted on HDMI 2.0 extenders. The Limits module iterates through all data blocks, filtering video formats according to the HDMI 2.0 bandwidth standard. For those exceeding this limit, it attempts to downgrade by converting the color space (e.g., YCbCr 4:2:0) or reducing the frame rate. Formats that cannot be downgraded are discarded. The purpose is to eliminate video formats in the converted EDID that may cause compatibility issues, ensuring that the initially reconstructed EDID data structure fully complies with the HDMI 2.0 protocol specifications, avoiding transmission anomalies such as black screens and flickering caused by bandwidth mismatch. The benefit of this step is that it guarantees the compatibility of the converted EDID at the protocol level, laying the foundation for subsequent space optimization and performance preservation, ensuring that the converted EDID can be stably recognized and parsed by the HDMI 2.0 extender.

[0025] The design principle of S4 space optimization and intelligent reconstruction is to maximize value within a limited 256-byte space through priority sorting. High refresh rate and high resolution modes have the greatest impact on user experience and should be retained first, while redundant, invalid, or low-value information can be appropriately discarded. Deleting unsupported DTDs, removing redundancy, and simplifying unnecessary fields frees up basic space. Converting an 18-byte DTD to 1-byte VIC or 6-byte TypeX format significantly improves space utilization, freeing up storage resources for core display modes. The goal is to retain the most valuable display modes for users while complying with the HDMI 2.0 protocol and the 256-byte space limit, avoiding wasted space that could lead to the loss of core performance information. The benefit of this step is that it achieves efficient allocation of space resources, without exceeding protocol and hardware limitations, and avoids blindly discarding high refresh rate and high resolution modes due to insufficient space, maximizing the effectiveness of limited space.

[0026] The design principle of S5's high refresh rate completion and final verification is based on the consideration that previous steps may have missed some high refresh rate modes due to space optimization or format conversion. The CVT1.2 module can dynamically generate compliant video timing according to the VESA standard, and the VIC format can supplement high refresh rate information in a compact way without occupying too much space. By comparing with the "target refresh rate list" generated by S1, the high refresh rate modes that are not retained can be accurately located. Then, by re-performing space judgment and optimization, they are added to the EDID, and finally, compliance verification is completed. The purpose is to fill in the gaps in the previous steps, ensuring that the high refresh rate modes in the target refresh rate list are retained as much as possible, while verifying that the final EDID fully complies with the HDMI 2.0 standard, without format errors or compatibility issues. The benefit of this step is that it further improves the performance of the converted EDID, minimizes the omission of high refresh rate modes, allows users to fully utilize the high performance of HDMI 2.1 devices, and ensures that the final output EDID is stable and reliable, without display problems caused by missing data or abnormal formats.

[0027] The parsing modules in S1 include the EDID 1.3 & 1.4 module, the CTA-861-H module, and the DisplayID 1.3 & 2.0 module; Traversing the original HDMI2.1 EDID includes: traversing the Establishing Timings, Standard Timings, Detailed Timings and CVT Timings fields in the EDID1.4 Block, traversing the Detailed Timings, Video Data Block, HDMI1.4b Vendor Specific DataBlock, YCbCr 4:2:0 Video Data Block, YCbCr 4:2:0 Capability Map in the CTA-861 ExtensionBlock. Data Block, DisplayID Type VII Video Timing Data Block, DisplayID Type VIII Video TimingData Block, DisplayID Type Data Block, TypeVII Detailed TimingData The Block, Type VIII Detailed Timing Data Block, and Type IX Detailed Timing Data Block are parsed and the supported frame rates are extracted.

[0028] Specifically, this design is based on the data structure characteristics of HDMI 2.1 EDID and the requirement for protocol compatibility. The EDID of an HDMI 2.1 device is not a single-format data block, but a combination of multiple functional blocks that follow different protocol standards. The frame rate information carried by different functional blocks is stored in specific fields, and there are cases of compatibility between new and old protocol versions. As a core component of traditional EDID, the EDID 1.4 Block contains basic frame rate information in its Establishing Timings and Standard Timings fields, which require parsing by modules adapted to the EDID 1.3 & 1.4 protocols. The CTA-861 Extension Block follows the CTA-861 standard, and its Video Data Block and various DisplayID-related timing blocks are key storage areas for HDMI 2.1 devices to extend high frame rate information. These can only be read by relying on the protocol parsing capabilities of the CTA-861-H module. The DisplayID Extension Block uses the DisplayID standard defined by VESA, which supports richer high refresh rate descriptions. Its internal different types of timing data blocks store various frame rate parameters, requiring DisplayID 1.3 & 2.0 modules adapted to different versions of the DisplayID protocol to complete data extraction. Different protocol blocks have different field definitions and data encoding formats. A single parsing module cannot cover all frame rate storage areas. Therefore, three types of parsing modules need to be configured specifically, and all frame rate-related fields under each functional block are traversed to ensure that the parsing logic is completely matched with the data storage protocol specifications and field distribution.

[0029] The purpose of this design is to achieve full capture of all valid frame rate information in the original HDMI 2.1 EDID, without missing any potential high refresh rate data. High refresh rate information from HDMI 2.1 devices is not centrally stored in a single field or function block; it may be scattered across different fields in the traditional EDID base block, CTA extension block, or DisplayID extension block. Some high refresh rate modes may also be encapsulated in timing data blocks specific to certain protocols. By configuring a parsing module covering mainstream protocol versions, the parsing barriers caused by different protocol standards can be broken down, avoiding the "invisibility" of frame rate information due to protocol incompatibility. Furthermore, a comprehensive traversal of the key fields under each function block can accurately locate all areas that may store frame rate data. Whether it's the basic standard frame rate or the high refresh rate specific to HDMI 2.1 devices, it can be completely identified, ultimately forming a comprehensive frame rate list reflecting the true performance of the display device. This provides accurate and complete raw data support for subsequent priority filtering, space optimization, and other steps.

[0030] The advantages of this design are threefold. First, it ensures comprehensive data acquisition. The combination of three types of parsing modules and full field traversal completely avoids the loss of high refresh rate information due to incomplete protocol support or missing fields. This ensures that core high frame rate data from HDMI 2.1 devices, such as 144Hz and 165Hz, can be fully captured, laying the foundation for maximizing the preservation of high refresh rate performance in subsequent steps. Second, it ensures accurate parsing. Each parsing module is specifically adapted to the corresponding protocol standard, accurately identifying the encoding rules of each field and avoiding parsing errors caused by protocol mismatch. This ensures that the extracted frame rate data is consistent with the actual support capabilities of the display device, providing reliable data for subsequent steps. Third, it offers broad compatibility. The parsing modules cover different versions of the three major mainstream protocols: EDID, CTA-861, and DisplayID. The traversed fields include all key storage areas under each protocol block, making it compatible with HDMI 2.1 devices from different manufacturers and of different specifications. Regardless of the protocol combination or field configuration used in the EDID, effective extraction of frame rate information can be achieved, expanding the applicability of this method. Finally, full frame rate capture provides a clear benchmark for the subsequent high refresh rate priority retention strategy, enabling a clear determination of which core high frame rates need to be prioritized and avoiding errors in selection due to incomplete information. This ensures that the converted EDID can restore the high refresh rate performance advantage of HDMI 2.1 devices to the greatest extent possible.

[0031] The specific process for S1 information collection and backup is as follows: First, the GetAllRefreshRate module is activated. This module automatically calls the three pre-integrated parsing modules: EDID 1.3 & 1.4, CTA-861-H, and DisplayID 1.3 & 2.0. Each parsing module activates its parsing permissions for its corresponding data block, forming a comprehensive traversal capability over the entire data field of the original HDMI 2.1 EDID. Specifically, the EDID 1.3 & 1.4 module is responsible for interfacing with the EDID base block, the CTA-861-H module parses the CTA-861-H extension block, and the DisplayID 1.3 & 2.0 module focuses on reading data from the DisplayID extension block. All three operate synchronously and independently, ensuring no data blocks are missed during the traversal.

[0032] During the traversal of the EDID base block, the EDID 1.3 & 1.4 modules read the four core fields—Establishing Timings, Standard Timings, Detailed Timings, and CVT Timings—within the data block one by one. The timing parameters in each field are decoded. The preset standard refresh rate specification is identified from Establishing Timings, the frame rate information at the corresponding resolution is extracted from Standard Timings, the complete timing data containing the precise refresh rate is parsed from Detailed Timings, and the refresh rate parameters defined according to the VESA CVT standard are obtained from CVT Timings. All parsed frame rate data is transmitted in real-time to the GetAllRefreshRate module for temporary storage.

[0033] Simultaneously, the CTA-861-H module initiates a traversal of the CTA-861-H extension block, sequentially parsing the Detailed Timings, Video Data Block, HDMI 1.4b Vendor Specific Data Block, YCbCr 4:2:0 Video Data Block, YCbCr 4:2:0 Capability Map Data Block, DisplayID Type VII Video Timing Data Block, DisplayID Type VIII Video Timing Data Block, and DisplayID Type X Video Timing Data Block within the extension block. For different fields with varying protocol formats, corresponding decoding logic is employed. For example, the refresh rate corresponding to the encapsulated VIC is extracted from the Video Data Block, and hidden high refresh rate information is parsed from various DisplayID-associated timing data blocks. This ensures that all valid refresh rate-related data within the extension block is captured and synchronously uploaded to the GetAllRefreshRate module.

[0034] The DisplayID 1.3 & 2.0 modules simultaneously perform a deep traversal of the DisplayID extended blocks, processing each of the following types of data blocks: Type I Detailed Timing Data Block, Type II Detailed Timing Data Block, Type III Short Timing Data Block, Type IV Short Timing Data Block, Type V Short Timing Data Block, Type VI Detailed Timing Data Block, VESA Timings Standard Data Block, CEA Timing Standard Data Block, Type VII Detailed Timing Data Block, Type VIII Detailed Timing Data Block, and Type IX Detailed Timing Data Block. Based on the different specifications of the DisplayID 1.3 and 2.0 protocols, corresponding parsing algorithms are adapted to extract frame rate parameters from various timing data blocks. Whether it's the precise refresh rate described in the detailed timing description or the simplified refresh rate information in the short timing data block, all are fully decoded and transmitted to the GetAllRefreshRate module.

[0035] After receiving all refresh rate data from the three main parsing modules, the GetAllRefreshRate module performs deduplication, removing duplicate frame rate records to form a "target refresh rate list" containing all supported refresh rates of the original HDMI 2.1 EDID. The list is sorted by frame rate value for easy comparison and verification in subsequent steps.

[0036] While traversing and parsing, the system simultaneously initiates the backup process for Detailed Timing Descriptors (DTDs). When reading fields from each data block, the three parsing modules not only extract refresh rate information but also completely capture all timing parameters corresponding to each Detailed TimingDescriptor, including core data such as total horizontal pixels, total vertical lines, frame leading / falling edge parameters, and synchronization signal parameters. This data is then organized according to the storage order in the original EDID and backed up to a separate temporary storage area, establishing a complete DTD backup library. This ensures that the original timing data can be retrieved at any time during subsequent space optimization, format conversion, and other steps, avoiding any impact on conversion results due to data loss.

[0037] Throughout the process, the parsing module and the GetAllRefreshRate module maintain real-time communication. For abnormal data encountered during traversal (such as time series fields with non-standard formats), a fault-tolerance mechanism is used to skip invalid information, ensuring the stability of the collection and backup process. The final target refresh rate list and DTD backup library provide comprehensive and accurate raw data support for subsequent steps.

[0038] Non-essential information in S2 includes Display Color Management (DCM) Data, Color Point Data, Display Range Limits, Alphanumeric Data String (ASCII), and Display Product Serial Number in the EDID 1.4 Block.

[0039] Specifically, this design is based on the differences between the functional attributes of the fields in EDID 1.4 Block and the core requirements of HDMI 2.0 EDID. EDID 1.4 Block contains multiple functional fields, and different fields have fundamentally different impacts on video signal transmission and display mode recognition. Display Color Management Data mainly describes the color management parameters of the display device; Color Point Data focuses on the coordinate information of specific color points; and Display Range Limits records the brightness and contrast range of the display device. These fields serve color fine-tuning and display effect optimization, and are not essential conditions for the normal operation of the HDMI 2.0 protocol and display mode recognition. Alphanumeric Data String (ASCII) typically stores text information such as device model and manufacturer identification, while Display Product Serial Number is the device's unique serial number. Both are only used for auxiliary scenarios such as device management and traceability, and do not participate in the definition of core parameters such as video timing, frame rate, and resolution, nor do they affect the protocol negotiation between the source and display ends. The presence or absence of this information will not change the EDID's description of the display device's core display capabilities, nor will it affect the HDMI 2.0 extender's parsing and recognition of the EDID, therefore, it is feasible to delete them.

[0040] The purpose of this design is to maximize the storage space of the EDID 1.4 Block, freeing up space for data related to core display modes such as high refresh rates and high resolutions. The total capacity of HDMI 2.0 EDID is limited to 256 bytes, while core display mode information in HDMI 2.1 EDID (such as high refresh rate timing data) requires a certain amount of storage resources. The number of bytes originally occupied by this non-essential information in the EDID 1.4 Block is considerable. Classifying it as non-essential and deletable allows for precise identification of the sources of freed space. By clearly defining the non-essentiality of these fields, the number of additional bytes that can be released can be accurately calculated during the space assessment phase. This provides a clear basis for space allocation in subsequent protocol downgrading, format conversion, and intelligent reconstruction, avoiding the forced discarding of critical, high-value display mode information due to insufficient space.

[0041] The benefits of this design are threefold. First, it ensures precise and efficient space allocation. The filtered non-essential information consists of fields that do not affect core functionality. Deleting these fields will not negatively impact the basic compatibility of the EDID or its core display capabilities. Simultaneously, it maximizes storage space, ensuring sufficient bytes are available for storing timing data and related descriptors for high refresh rates and high resolutions. Second, it prioritizes the fulfillment of core requirements. The freed-up space can be directly used to carry core performance information in the HDMI 2.1 EDID, preventing the loss of high refresh rate and high resolution modes due to unnecessary information. This allows the converted HDMI 2.0 EDID to focus on the display performance most important to users, fully leveraging the hardware potential of HDMI 2.1 devices. Third, it improves conversion stability and compatibility. Clearly defining the scope of non-essential information avoids accidental deletion of core fields (such as basic timing fields and protocol identifier fields) in the EDID 1.4 Block during space optimization. This ensures that the converted EDID still conforms to the HDMI 2.0 standard and can be stably recognized and parsed by various HDMI 2.0 source devices and extenders, preventing compatibility issues caused by accidental information deletion. Finally, this explicit field filtering method makes the spatial assessment process more operational, eliminating the need to judge all fields of the EDID 1.4 Block one by one, simplifying the logic of spatial assessment and improving the efficiency of the entire EDID conversion process.

[0042] The processing procedure of the Limits module in S3 is as follows: Iterate through all timings and calculate the TMDSClock corresponding to each timing. If the TMDS Clock exceeds 600MHz, first convert the Colorspace to YCbCr 4:2:0 or reduce the FrameRate to reduce the TMDS Clock. If it is still impossible to make the TMDS Clock ≤ 600MHz, then discard the timing. The TMDSClock corresponding to the DTD is calculated according to the formula TMDS Clock = Htotal × Btotal × FrameRate × BitsPerPixel, where Htotal is the total number of horizontal pixels, Btotal is the total number of vertical rows, FrameRate is the frame rate, and BitsPerPixel is the pixel width. The TMDS Clock corresponding to VIC is obtained by looking up a table, and the TMDS Clock corresponding to CVT is calculated by the VESA CVT 1.2 standard algorithm.

[0043] Specifically, this design is based on the physical bandwidth limitations of the HDMI 2.0 protocol and the parameter characteristics of different types of timing. The maximum transmission bandwidth of the HDMI 2.0 protocol is 18Gbps, and the corresponding TMDS Clock upper limit is 600MHz. This is the core threshold to ensure stable signal transmission. Video timings exceeding this threshold cannot be transmitted normally on the HDMI 2.0 extender, resulting in problems such as signal interruption and image distortion. The timings in HDMI 2.1 EDID include various types, each with different parameter storage formats and protocol definitions. The DTD, as a detailed timing descriptor, contains complete timing parameters such as the total number of horizontal pixels and the total number of vertical rows. The TMDS Clock can be derived from directly associated parameters, hence the formula Htotal × Btotal × FrameRate × BitsPerPixel is used for calculation. VIC is a standardized video identification code, and the bandwidth requirements for each VIC are clearly defined in industry standards. The corresponding TMDS Clock can be quickly and accurately obtained by looking up a table, without complex calculations. CVT follows the VESA CVT 1.2 standard, and its timing parameters are generated by a standardized algorithm. The corresponding TMDS Clock also needs to be derived using this standard algorithm to ensure the accuracy of the calculation results. Based on these characteristics, the Limits module first iterates through all timings and calculates the TMDS Clock in the corresponding way. Then, it attempts to reduce the bandwidth requirements of timings exceeding the threshold by color space conversion or frame rate adjustment. If adjustment is not possible, the timings are discarded, ensuring that all retained timings meet the transmission capabilities of HDMI 2.0.

[0044] The design aims to filter video timings that meet the bandwidth requirements of HDMI 2.0 at the protocol level, providing compliant foundational data for subsequent EDID reconstruction. Some timings in the HDMI 2.1 EDID are designed for the high bandwidth of HDMI 2.1 (48Gbps). Directly migrating them to the HDMI 2.0 EDID would cause compatibility issues due to bandwidth mismatch. Therefore, the Limits module is needed for filtering and adaptation. First, the TMDS Clock threshold of HDMI 2.0 is defined, and all timings are verified based on this standard. For timings exceeding the threshold, color space conversion (YCbCr 4:2:0 format reduces bandwidth usage compared to RGB format) or a moderate reduction in frame rate are prioritized to control their bandwidth requirements within the HDMI 2.0 range without significantly impacting user experience, preserving as many usable display modes as possible. Only when these adjustments still cannot meet the bandwidth requirements are the timings discarded, avoiding the overall EDID being unrecognizable by HDMI 2.0 devices or causing signal transmission abnormalities due to the retention of non-compliant timings.

[0045] The benefits of this design are threefold. First, it ensures the compatibility of the converted EDID. All processed timings comply with the bandwidth limits of HDMI 2.0, ensuring stable resolution and transmission by the HDMI 2.0 extender. This effectively avoids issues such as black screens, flickering, and stuttering caused by bandwidth mismatch, allowing for smooth protocol negotiation between the source and display devices. Second, it maximizes the preservation of display modes. Through color space conversion or frame rate reduction, it avoids the waste of modes caused by directly discarding timings exceeding the threshold. Even some high-bandwidth timings can continue to provide services to users through reasonable adjustments, reducing the loss of display functionality. Third, it ensures the accuracy and reliability of the calculation results. Corresponding TMDS Clock calculation methods are used for different types of timings, conforming to the protocol specifications and parameter storage characteristics of various timings. This avoids misjudgments caused by a single calculation method, ensuring that timings exceeding the threshold are accurately identified and compliant timings are not misprocessed. Finally, it has a wide range of compatibility, covering the three timing types commonly found in HDMI 2.1 EDID: DTD, VIC, and CVT. Regardless of the timing description method used in the original EDID, it can complete the verification and processing through the corresponding calculation logic, thus improving the adaptability of this method to HDMI 2.1 devices of different specifications.

[0046] The default priority order in S4 is as follows: first delete DTDs that are not supported by Block0 and Block1, then delete redundant DTDs with the same resolution, then delete unnecessary description fields, then perform format conversion, and finally discard low-priority display modes according to the high-priority display mode retention strategy.

[0047] In S4, format conversion converts an 18-byte DTD to a 1-byte VIC format or a 6-byte TypeX (CVT description) format.

[0048] Specifically, this design is based on the 256-byte space limitation of HDMI 2.0 EDID and the difference in practical value between display modes, while also leveraging the storage efficiency characteristics of different data formats. HDMI 2.0 EDID has limited storage capacity, so it's essential to prioritize removing meaningless data to free up space. DTDs that are not supported by Block 0 and Block 1 lack the capability to be recognized and used by the source device; retaining such data only wastes limited storage resources, thus making them the primary targets for deletion. Redundant DTDs with the same resolution, while recognizable, have duplicate core functions; multiple such DTDs coexisting only waste space and do not improve display quality. Therefore, after removing useless data, redundancy is prioritized. Unnecessary description fields only carry information unrelated to core display functions, such as device traceability and auxiliary identification; their deletion will not affect the source device's recognition of display modes and signal transmission, making it a reasonable choice for further freeing up space. While DTDs, as detailed timing descriptors, can accurately define display modes, each entry requires a significant 18 bytes of space. VIC format, through standardized encoding, can identify a video mode using only 1 byte, and TypeX (CVT description) format requires only 6 bytes. These three formats differ significantly in storage efficiency. Format conversion can greatly improve space utilization without sacrificing core display parameters. When space is still insufficient to accommodate critical display modes, lower-value modes are prioritized and discarded because high refresh rate and high resolution modes have a more critical impact on user experience and meet the core usage needs of most users. This prioritization follows the space optimization logic of "useless before useful, redundant before necessary, inefficient before efficient," and aligns with the value orientation of actual application scenarios.

[0049] The purpose of this design is to maximize the preservation of valuable display modes for users within the strict 256-byte limit through orderly space optimization operations, especially the high refresh rate and high resolution modes unique to HDMI 2.1 EDID. First, useless and redundant data is removed to quickly free up basic space, preventing such data from occupying critical resources and causing useful modes to be mistakenly deleted. Removing unnecessary description fields further optimizes space utilization, creating conditions for retaining more core display data later. The core goal of format conversion is to improve space utilization, allowing limited bytes to carry more display mode information, solving the pain point of excessive storage in traditional DTDs. Finally, prioritizing and discarding low-value modes is a fallback strategy when space is exhausted, ensuring that core high-value modes are not sacrificed and preventing unmet user needs due to disordered deletion. The combination of this prioritization design and format conversion essentially seeks the optimal balance between "space constraints" and "functionality preservation," ensuring that the converted EDID conforms to the HDMI 2.0 standard while restoring the high-performance advantages of HDMI 2.1 devices as much as possible.

[0050] The benefits of this design are twofold. First, the orderly priority deletion process avoids blind space optimization. Completely useless DTDs and redundant data are removed first, followed by the cleanup of unnecessary fields, ensuring that each space release does not affect core display functions, laying the foundation for retaining high-value modes later. Second, format conversion brings significant space gains. Storage compression from 18 bytes to 1 byte or 6 bytes allows the originally limited 256 bytes of space to accommodate more display modes, greatly improving space utilization and solving the problem of high refresh rate modes being unable to be retained due to insufficient space in traditional methods. Third, the final step of priority sorting ensures the priority retention of core modes such as high refresh rates and high resolutions, meeting the core needs of users in e-sports, high-end audio-visual scenarios, and avoiding the waste of high-end hardware performance. Simultaneously, the entire process revolves around the HDMI 2.0 standard. The VIC and TypeX (CVT description) formats used for format conversion both conform to the standard specifications, ensuring that the converted EDID can be stably recognized by HDMI 2.0 source devices and extenders, preventing display abnormalities caused by format incompatibility. Furthermore, this design is compatible with different display mode description methods. Regardless of whether the display mode in the original HDMI 2.1 EDID is stored in DTD, VIC, or CVT format, it can be efficiently integrated through corresponding optimization operations, thereby improving the versatility and adaptability of the method.

[0051] The specific application scenarios for the preset priority order in S4 are as follows: In scenarios where esports users connect an Xbox Series X (HDMI 2.1 source) to a 165Hz high refresh rate gaming monitor (HDMI 2.1 display device) using an HDMI 2.0 extender, the application logic of priority order is particularly clear. The original monitor EDID is 512 bytes and contains various display modes that exceed the capabilities of the HDMI 2.0 protocol. The first step, "removing DTDs that are not supported by Block 0 and Block 1," takes effect first—if the monitor EDID contains a 4K@120Hz DTD, while the HDMI 2.0 protocol's Block 0 and Block 1 only support up to 4K@60Hz, these DTDs that cannot be recognized by the HDMI 2.0 extender will be prioritized for removal to avoid consuming valuable storage space. At this point, there are still several redundant DTDs with the same resolution remaining in the EDID, such as 2K@60Hz (RGB format) and 2K@60Hz (YCbCr4:4:4 format). The core resolution of the two is the same, and there are only slight differences in color space. They have minimal impact on the core experience of e-sports scenarios. Therefore, we proceed to the second step, "delete redundant DTDs with the same resolution", and keep one of them to free up 18 bytes of space.

[0052] With the initial space freed up, if it's still insufficient to accommodate key data for high refresh rates such as 165Hz and 144Hz, the third step, "removing unnecessary description fields," takes effect. Block 1.4 of the monitor's EDID stores ASCII text information such as manufacturer promotional material, product batch number, and detailed manufacturing date, as well as color fine-tuning parameters like Display Color Management Data. This information doesn't affect the source device's recognition of high refresh timing and signal transmission; deleting it frees up approximately 20-30 bytes of space. Even so, if the storage requirements for the 165Hz and 144Hz DTDs (each occupying 18 bytes) and other necessary display modes still exceed the remaining space, the fourth step, "format conversion," is initiated—converting the DTDs of these two high refresh rates to the 1-byte VIC format. The original 36 bytes of space are instantly compressed to 2 bytes, significantly saving storage resources while fully preserving the core parameters of the high refresh rate modes.

[0053] If, after the first four optimization steps, there is still a gap in performance (for example, if additional high refresh rate modes such as 2K@100Hz and 1080P@120Hz still need to be retained), the fifth step, "retaining high-priority display modes while discarding low-priority display modes," will ultimately provide a safety net. At this point, the 165Hz and 144Hz modes, crucial for the gaming experience, will be prioritized, while lower refresh rate modes such as 1080P@60Hz and 720P@60Hz will be discarded. These low refresh rate modes can be automatically downgraded in most devices through protocol negotiation, while high refresh rate modes are a core requirement for users purchasing high-end monitors. Discarding low-priority modes minimizes the waste of high-end hardware performance.

[0054] In S5, the timing sequence is generated through the CVT1.2 module, which generates the corresponding video format timing sequence according to the algorithm principle in the VESA Coordinated Video Timings (CVT) Standard Version 1.2 document.

[0055] The EDID 1.3 & 1.4 modules provide interfaces for parsing and modifying the EDID basic block, the CTA-861-H module provides interfaces for parsing and modifying the CTA-861-H extension block, and the DisplayID 1.3 & 2.0 modules provide interfaces for parsing and modifying the DisplayID extension block.

[0056] Specifically, this design is based on the universality of industry standards and the protocol differences of EDID data blocks. VESA Coordinated Video Timings (CVT) Standard Version 1.2 is an industry-recognized timing generation standard. Its algorithm has been widely validated and can generate compliant video timing data based on core parameters, ensuring compatibility with the HDMI 2.0 protocol and various display devices, and avoiding display anomalies caused by non-compliant timing. In contrast, HDMI 2.1 EDID consists of multiple data blocks following different protocol standards. The EDID base block follows the EDID 1.3 or 1.4 protocol, the CTA-861-H extension block is based on the CTA-861-H standard, and the DisplayID extension block uses the DisplayID 1.3 or 2.0 protocol. The data structures, field definitions, and encoding rules under different protocols differ significantly, and a single module cannot simultaneously adapt to the parsing and modification needs of multiple protocols. Therefore, three dedicated modules are specifically designed, each focusing on its corresponding protocol standard, accurately matching the protocol characteristics of the data blocks to ensure accurate parsing and compliant modification.

[0057] The purpose of this design is to provide standardized timing supplementation capabilities and precise protocol operation support for the EDID conversion process. Generating timing through the CVT1.2 module provides a reliable timing generation method for high refresh rate modes not retained in the target refresh rate list after S4 space optimization. It supplements standard high refresh rate timing without relying on the DTD data in the original EDID, ensuring maximum retention of high refresh rate modes. The design of the three parsing and modification interface modules is primarily to meet the operational needs of different EDID data blocks throughout the conversion process. From the full information collection in S1 to the protocol downgrade in S3 and the intelligent reconstruction in S4, each data block's content needs to be accurately parsed before targeted modifications are made. The interfaces provide clear execution paths for these operations, ensuring that each step accurately affects the corresponding EDID data area, avoiding operational confusion or accidental data modification.

[0058] The timing sequence is generated in accordance with the VESA CVT 1.2 standard, ensuring broad device compatibility for the supplementary high refresh rate timing. Regardless of the brand or model of the display device, it can be recognized and supported, avoiding compatibility issues that may arise with custom timing. Simultaneously, the standardized algorithm guarantees the accuracy of the timing parameters, allowing for stable high refresh rate display. The setup of three dedicated modules ensures that the parsing and modification of each EDID data block accurately matches the corresponding protocol, avoiding parsing errors or modification failures caused by protocol incompatibility. This ensures that all types of information in the EDID can be accurately read and reasonably adjusted, providing a reliable data foundation for subsequent space optimization, protocol downgrading, and other steps.

[0059] The provided interfaces make the entire conversion process more targeted. The parsing module can directly access the corresponding data blocks to extract key information, and the modification interface can precisely target the desired area without indiscriminately processing the entire EDID, thus improving operational efficiency and data processing accuracy. Simultaneously, the timing generation capability of the CVT1.2 module compensates for any missing high refresh rate timings in the original EDID. Even high refresh rate modes that cannot be retained due to space limitations or insufficient original data can be supplemented through standardized algorithms, further reinforcing the core objective of "maximizing the retention of high refresh rate performance." The coverage of different protocol versions by the three modules allows this method to adapt to different specifications of HDMI 2.1 EDIDs, regardless of whether they use older or newer protocol versions, enabling effective parsing and modification, thus improving the applicability and versatility of the entire method. Furthermore, the industry-standard design makes the converted EDID more easily recognized by various HDMI 2.0 source devices and extenders, reducing compatibility issues caused by non-standard data formats and ensuring the stability and consistency of display effects.

[0060] The specific algorithm principle for timing generation in the CVT1.2 module is as follows: The algorithm's startup is based on explicit input parameters, all derived from the "target refresh rate list" generated by S1 and the HDMI 2.0 protocol requirements. Core inputs include target horizontal effective pixels (H_active, the horizontal dimension value of the resolution, e.g., 2560 corresponds to 2K resolution), target vertical effective pixels (V_active, the vertical dimension value of the resolution, e.g., 1440 corresponds to 2K resolution), target frame rate (FrameRate, the required high refresh rate, e.g., 144Hz, 165Hz), and constraints (TMDS Clock ≤ 600MHz, progressive scan mode, compliant with HDMI 2.0 display specifications). The explicitness of these input parameters ensures that the generation timing matches the user's core needs and hardware capabilities, avoiding aimless derivations.

[0061] The algorithm first selects the CVT mode, prioritizing CVT-R (Reduced Blanking) mode for high refresh rate scenarios. This is a key design feature to ensure high refresh rate timings are compatible with HDMI 2.0 bandwidth. The traditional CVT-N (Normal Blanking) mode has a longer blanking period, leading to a larger total horizontal (H_total) and vertical (V_total) pixel count, causing the pixel clock (TMDS Clock related) to exceed the 600MHz limit. CVT-R mode, by optimizing the blanking period ratio, minimizes the proportion of invalid pixels without affecting display stability, reducing the total pixel transmission and providing a foundation for bandwidth compliance in high frame rate timings. Mode selection requires no manual intervention; the algorithm automatically determines the mode based on the target frame rate—CVT-R is enabled by default when the frame rate is ≥100Hz, and CVT-N is compatible below this threshold, ensuring timing appropriateness in different scenarios.

[0062] Next, we proceed with the calculation of horizontal timing parameters. First, using the input H_active as a baseline, we derive the horizontal blanking period (H_blank) according to the fixed ratio of the CVT1.2 standard: In CVT-R mode, the minimum value of H_blank is 8% of H_active (and no less than 160 pixels to ensure scan synchronization stability), calculated as H_blank = max(H_active × 0.08, 160); in CVT-N mode, H_blank is 20% of H_active (and no less than 240 pixels). Then, we calculate the horizontal synchronization signal width (H_sync_width). The CVT1.2 standard specifies its minimum value as 3% of H_total (and no less than 12 pixels), where H_total = H_active + H_blank. Therefore, H_sync_width = max(H_total × 0.03, 12). The horizontal sync signal polarity (H_sync_polarity) is set to negative by default. This is a common requirement for HDMI protocol compatibility and can prevent scanning misalignment in the display device. By deriving these parameters, the horizontal scanning cycle is fully determined: from the effective pixel display stage to the blanking period (including the sync signal), and then to the cycle of the next line, ensuring that the transmission rhythm of each line of pixels matches the scanning rhythm of the display device.

[0063] The calculation of vertical timing parameters is consistent with the horizontal timing logic, deriving relevant parameters based on V_active. In CVT-R mode, the minimum value of the vertical blanking period (V_blank) is 2% of V_active (and no less than 40 lines to avoid inter-frame overlap), calculated as V_blank = max (V_active × 0.02, 40). In CVT-N mode, V_blank is 5% of V_active (and no less than 60 lines). The vertical synchronization signal width (V_sync_width) is set to 3 lines by default, which is the minimum effective value defined by the CVT1.2 standard, ensuring accurate frame synchronization without consuming excessive transmission resources. The vertical synchronization polarity (V_sync_polarity) is also set to negative polarity, consistent with the horizontal synchronization polarity, ensuring coordinated line and frame scanning of the display device. The final total vertical pixel count V_total = V_active + V_blank, combined with the total horizontal pixel count H_total, constitutes the total pixel scale of a single frame image.

[0064] The calculation and verification of the pixel clock (f_pixel) is a crucial step in ensuring that the timing meets the bandwidth requirements of HDMI 2.0. According to the CVT 1.2 standard, the formula for calculating the pixel clock is f_pixel = H_total × V_total × FrameRate, which directly corresponds to the TMDS Clock (in HDMI transmission, the TMDS Clock and the pixel clock are fixedly correlated). The algorithm automatically verifies whether the calculated f_pixel is ≤ 600MHz (the maximum clock limit for a single channel in HDMI 2.0). If it exceeds the threshold, the algorithm fine-tunes the blanking period parameter (appropriately increasing the blanking period ratio within the range allowed by the CVT standard to reduce the actual effective transmission rate of the frame rate) or adjusts the effective number of pixels at the resolution (e.g., fine-tuning H_active for 2K resolution from 2560 to 2496 to reduce the total number of pixels without affecting the visual experience), and iterates to recalculate the horizontal and vertical timing parameters until f_pixel meets the constraints, ensuring that the generated timing will not cause transmission anomalies due to bandwidth exceeding the limit.

[0065] Finally, the algorithm encapsulates all derived timing parameters (H_active, V_active, H_total, V_total, H_blank, V_blank, H_sync_width, V_sync_width, synchronization polarity, pixel clock) in an EDID-compatible format. For S5 application scenarios, the generated data will be adapted to either TypeX (CVT descriptor) or DTD format: if used to supplement the TypeX field of the EDID, the core parameters are extracted and compressed into 6 bytes of data (conforming to the CVT TypeX encoding specification, including key information such as resolution, frame rate, and blanking period ratio); if it needs to be converted to DTD format, the 18-byte timing descriptor field is fully filled to ensure parameter integrity. The encapsulated timing data can be directly recognized by the S4's spatial optimization logic and integrated into the 256-byte HDMI 2.0 EDID without additional conversion, achieving high refresh rate mode completion.

[0066] In S4, the high-priority display mode retention strategy prioritizes high refresh rates, followed by high resolutions, and prioritizes display modes corresponding to high refresh rates such as 144Hz and 165Hz.

[0067] Non-essential description fields in S4 are those in EDID that do not affect display mode recognition and signal transmission compatibility, including redundant manufacturer information and non-core product identification information.

[0068] Specifically, this design is based on the core demands of user display experience, the functional positioning of EDID, and the hardware and space constraints of HDMI 2.0. The principle behind the high-priority display mode retention strategy stems from the critical impact of high refresh rates on the display experience. High refresh rates directly determine the smoothness of the image. In scenarios such as e-sports and high-speed dynamic image playback, the improvement in smoothness brought by high refresh rates such as 144Hz and 165Hz far outweighs the perceived slight increase in resolution at the same refresh rate. The core performance advantage of HDMI 2.1 devices is also concentrated on high refresh rates. At the same time, the bandwidth limitations of HDMI 2.0 and the space limitations of 256 bytes for EDID mean that not all display modes can be retained. It is necessary to prioritize and select modes based on their impact on the user experience, prioritizing the high refresh rate modes that have the strongest impact on the user experience, while also considering high resolution, ensuring that limited resources are invested in the aspects that best enhance the experience. The principle behind the non-essential description fields is closely related to the core function of EDID. The core function of EDID is to achieve matching of display capabilities and signal transmission compatibility between the source and display ends. Redundant manufacturer information and non-core product identification information are only used for auxiliary scenarios such as equipment traceability and brand labeling. They do not participate in key processes such as display mode negotiation and timing parameter transmission. Their existence or absence will not affect the realization of the core function of EDID, nor will it cause abnormal signal transmission or display compatibility issues. Therefore, they are reasonable to be deleted.

[0069] The purpose of this design is to maximize the core value of HDMI 2.1 devices and optimize EDID space utilization efficiency within limited resource constraints. The high-priority strategy aims to prevent the loss of the core advantage of HDMI 2.1 devices—high refresh rate—due to insufficient space or disordered selection, ensuring that users' core demand for high-end devices is met. Simultaneously, while maintaining high refresh rates, it aims to retain high resolution as much as possible, achieving a balance between smoothness and image clarity, and preventing hardware performance from being wasted due to format conversion. The purpose of removing unnecessary description fields is to precisely free up EDID storage space by eliminating auxiliary information that does not affect core functions. This frees up bytes of resources for timing description data corresponding to high refresh rates and high resolutions, preventing space from being occupied by useless information that would prevent the storage of critical display modes. It also provides sufficient space support for subsequent space optimization and timing completion steps, ensuring the integrity of core display functions.

[0070] The advantage of this design is that the high-priority strategy can accurately match the core experience needs of users, especially e-sports players, professional video creators and other groups that rely heavily on high refresh rates. They can continuously enjoy the smooth experience brought by high refresh rates such as 144Hz and 165Hz, and avoid being forced to use low refresh rates and wasting the performance potential of high-end hardware. The clear trade-off logic makes the space optimization process more targeted, and high-value modes will not be lost due to disordered deletion. Even if low-priority low refresh or low resolution modes are abandoned, they will not significantly affect the use of basic scenarios such as daily office work and video playback, because most source devices can automatically adapt to the basic display mode. The benefits of eliminating unnecessary descriptive fields lie in the efficient release of storage space. The bytes occupied by these fields can be directly used to store timing data or descriptors for the core display mode, significantly improving the space utilization of EDID. Clearly defining the scope of unnecessary fields can effectively prevent the accidental deletion of core fields in EDID (such as timing parameters, protocol identifiers, etc.), ensuring that the converted EDID can still be accurately parsed by the source device, guaranteeing the compatibility and stability of signal transmission. At the same time, eliminating redundant information allows EDID data to focus more on core functions, reducing invalid data processing steps when the source device parses the EDID, indirectly improving the negotiation efficiency between devices, and making display mode switching smoother.

[0071] The specific implementation steps of the high-priority display mode retention strategy in S4 are as follows: S41: Display Mode Data Preprocessing and Parameter Extraction First, the compliant display modes (TMDS Clock ≤ 600MHz) filtered by the Limits module are processed, and key attributes of each mode are extracted to form a structured candidate list. The extracted core parameters include: the refresh rate corresponding to the mode (accurate to 1Hz, such as 165Hz, 144Hz, 120Hz, etc.), resolution (identified by "horizontal effective pixels × vertical effective pixels," such as 3840×2160 corresponding to 4K, 2560×1440 corresponding to 2K), storage format type (DTD / VIC / TypeX), single-mode storage space (18 bytes for DTD, 1 byte for VIC, 6 bytes for TypeX), and timing integrity identifier (whether it contains complete synchronization signal parameters to ensure display stability). Simultaneously, the "target refresh rate list" generated by S1 is linked to mark whether each candidate mode belongs to the high refresh rate mode (144Hz and above) required by the user's core needs, providing a basis for subsequent sorting.

[0072] S42: Implementation and Sequencing of Priority Hierarchy Rules Based on the strategy of "high refresh rate first, high resolution second", a clear hierarchical sorting rule is formulated and the sorting is executed: (1) First level: sorted by refresh rate, the candidate modes are divided into four levels - 165Hz and above is the highest priority level, 144Hz is the second highest priority level, 120Hz is the medium priority level, and 60Hz and below is the low priority level. The priority decreases from high to low, and the highest level mode is retained first.

[0073] (2) Second level: within the same refresh rate range, sort by resolution. Within the same range, sort in the order of "4K (3840×2160) > 2K (2560×1440) > 1080P (1920×1080) > 720P (1280×720) > Standard Definition (below 720P)" to ensure that high resolution mode is reserved first.

[0074] (3) Third level: sorted by storage efficiency under the same refresh rate and resolution, and priority is given to retaining the format with smaller space (VIC > TypeX > DTD). Without losing display performance, storage space is saved to the maximum extent, freeing up space for more high priority modes.

[0075] After sorting, an ordered candidate queue is formed: "highest priority, high refresh rate, high resolution (small storage format) → highest priority, high refresh rate, low resolution → second highest priority, high refresh rate, high resolution → ... → low priority".

[0076] S43: Verification of complete retention of the highest priority level based on available space First, calculate the remaining available space of the EDID (denoted as S_remaining) after the preceding operations (deleting DTDs not supported by Block0 / Block1, deleting redundant DTDs, and deleting unnecessary description fields), in bytes.

[0077] Iterate through all modes of the highest priority level (165Hz and above) and calculate the total space required to store all modes of this level in the current storage format (denoted as S_high1).

[0078] If S_high1≤S_remaining: All patterns in this file are completely retained and directly included in the pattern list of EDIDs to be integrated. At the same time, the remaining available space is updated to S_remaining=S_remaining-S_high1.

[0079] If S_high1 > S_remaining: Select modes one by one in the order of "resolution from high to low" within this file, and calculate the total space of the selected modes until the total space is close to but does not exceed S_remaining. The remaining unselected low-resolution modes in this file are temporarily stored in the candidate list (which can be added later if there is any remaining space). Update the remaining available space to S_remaining = S_remaining - total space of selected modes.

[0080] S44: Progressive reservation of the second highest and lower priority levels Process the second highest priority level (144Hz), medium priority level (120Hz), and low priority level (60Hz and below) in descending order of priority. The processing logic for each level is the same as in step three. (1) Calculate the total storage space S_current for all modes in the current gear.

[0081] (2) If S_remaining≥S_current: retain all modes of the file and update the remaining space.

[0082] (3) If S_remaining < S_current: filter modes in the order of "resolution from high to low + storage efficiency from high to low", the cumulative space does not exceed S_remaining, and the unselected modes are stored in the candidate list.

[0083] Specifically for the 144Hz second highest priority level (the core requirement mode for e-sports), if space is tight, the DTD format mode in this level can be converted to VIC or TypeX format first (e.g., converting 144Hz 2K DTD to VIC reduces the space occupied from 18 bytes to 1 byte). The total space is then recalculated before the retention judgment is made to ensure that as many 144Hz modes as possible are retained.

[0084] S45: Format Conversion Optimization and Space Re-release If, after processing high-priority modes (165Hz, 144Hz, 120Hz), the remaining available space is still insufficient to retain all high-value modes in that mode, or if you wish to add high-priority modes to the alternative list, initiate format conversion optimization: (1) Traverse the reserved high priority patterns. If there is a DTD format pattern, convert it to the corresponding VIC (if the pattern has a corresponding VIC encoding in the CEA-861 standard) or TypeX format (if it conforms to the CVT specification).

[0085] (2) Calculate the space released for each conversion (e.g., 17 bytes are released for DTD to VIC, and 12 bytes are released for TypeX), and update S_remaining after accumulating the released space.

[0086] (3) Use the freed-up space to add high-value modes (such as 165Hz low resolution and 144Hz low resolution modes) from the candidate list in order of priority until the space is exhausted or there are no higher-value modes in the candidate list.

[0087] S46: Redundancy Removal and Final Verification (1) Redundancy elimination: Iterate through all the retained modes. If there are redundant modes with the same refresh rate and resolution (such as the same 144Hz 2K mode with both VIC mode and the converted TypeX mode), only retain the mode with the smallest space (VIC preferred), delete other redundant items, and further free up space.

[0088] (2) Compliance verification: Confirm that all retained modes comply with the HDMI 2.0 protocol specifications (TMDS Clock ≤ 600MHz, timing parameters compliant) and there are no modes that exceed the bandwidth limit.

[0089] (3) Space verification: The total space occupied by all reserved modes is ≤256 bytes of total HDMI2.0 EDID capacity, ensuring that the storage limit is not exceeded.

[0090] S47: Preservation Mode Integration and EDID Data Population All high-priority patterns that are ultimately selected and retained are integrated into the EDID data structure in the order of "VIC format → TypeX format → DTD format": (1) In VIC mode, fill in the Video Data Block field of the CTA-861-H extension block.

[0091] (2) Enter the DisplayID Type X Video TimingData Block field of the CTA-861-H extension block in the TypeX format mode.

[0092] (3) Fill the remaining necessary DTD patterns into the Detailed Timings field of EDID 1.4 Block.

[0093] Ensure that the storage location of each mode conforms to the HDMI 2.0 EDID standard specification, and that the field encoding is correct, so that the source device can easily parse and identify it.

[0094] Example 2, see Figures 1-3 The operation process of this method is as follows: The system first enters the information acquisition and backup phase. The GetAllRefreshRate module is activated, which calls three parsing modules: EDID 1.3 & 1.4, CTA-861-H, and DisplayID 1.3 & 2.0, to perform a full data block traversal of the raw HDMI 2.1 EDID. The EDID 1.3 & 1.4 module parses fields such as Establishing Timings and Standard Timings in the EDID base block. The CTA-861-H module processes the Video Data Block and various DisplayID-related timing blocks within the CTA-861 extension block. The DisplayID 1.3 & 2.0 module performs in-depth parsing of the Type I to Type IX timing data blocks in the DisplayID extension block. These three modules work together to extract all supported refresh rate information, which, after deduplication, forms a "target refresh rate list." Simultaneously, the core parameters of all detailed timing descriptors (DTDs) are fully backed up, including the total number of horizontal pixels, the total number of vertical lines, and sync signal parameters, providing complete raw data support for subsequent steps.

[0095] After data collection is completed, the system enters the space assessment phase. First, it calculates the 256-byte fixed structure capacity of the HDMI 2.0 standard EDID, clarifies the minimum space required for basic fields (such as protocol identifiers and core timing fields), and then evaluates the non-essential information that can be discarded in the EDID 1.4 Block one by one - including Display Color Management Data, Color Point Data, device serial number, ASCII text identifier, etc. It accurately calculates the number of extra bytes that can be released after deleting this information, and forms a space assessment report of "basic minimum space + extra space that can be released", clarifying the actual upper limit of the capacity that can be used to store the core display mode.

[0096] The system then enters the protocol downgrade and capability conversion phase. The Limits module is activated, iterating through and filtering all collected display mode timing data. This module uses corresponding TMDS Clock calculation methods for three different timing types: DTD, VIC, and CVT. DTD is calculated using the formula Htotal × Btotal × FrameRate × BitsPerPixel; VIC is obtained through table lookup; and CVT is derived based on the VESA CVT 1.2 standard algorithm. If the calculated TMDS Clock exceeds the 600MHz limit of HDMI 2.0, the system first attempts to convert the color space to YCbCr 4:2:0 or appropriately reduce the frame rate. If the adjustment still fails to meet the bandwidth requirements, the timing data is discarded. Finally, all compliant display modes that meet the bandwidth constraints of the HDMI 2.0 protocol are selected, and the EDID data structure size is initially locked at 256 bytes.

[0097] The next stage is space optimization and intelligent reconstruction, where the system performs operations according to a preset priority order. The first step is to delete DTDs that are not supported by Block 0 and Block 1, eliminating data with no practical value. The second step is to clean up redundant DTDs with the same resolution to avoid wasting space. The third step is to delete unnecessary description fields identified in the previous assessment, further freeing up space. The fourth step is to convert the timing of 18-byte DTD formats, converting them to 1-byte VIC format or 6-byte TypeX (CVT description) format as needed, significantly improving space utilization. The fifth step is to activate a high-priority display mode retention strategy. First, compliant display modes are divided into refresh rate tiers according to "165Hz and above > 144Hz > 120Hz > 60Hz and below". Within each tier, they are sorted according to "4K > 2K > 1080P > 720P > SD". For the same refresh rate and resolution, formats with higher storage efficiency are prioritized. Then, combined with the available capacity in the space assessment report, modes are selected one by one from high to low priority until the space limit is approached. Unselected low-priority modes are temporarily stored in a candidate list. If there is still space available, further space can be freed up through format conversion, high-value patterns can be added from the alternative list, and finally redundant items can be removed and compliance verified to complete the initial reconstruction of EDID.

[0098] Finally, in the high refresh rate completion and final verification stage, the system compares the refresh rates supported by the initially reconstructed EDID with the "target refresh rate list" generated by S1, identifying any missing high refresh rate modes. For these missing high refresh rate modes, the system calls the CVT1.2 module, and based on the VESA CVT 1.2 standard algorithm, inputs the target resolution, refresh rate, and HDMI 2.0 bandwidth constraints. Through steps such as selecting the CVT-R reduced blanking period mode, calculating horizontal and vertical timing parameters, and verifying pixel clocks, it generates compliant timing data or searches for the corresponding VIC code. The generated timing data is then encapsulated in TypeX or VIC format, and the space optimization steps are re-executed to determine if it can be integrated into the existing EDID structure, ensuring that the high refresh rate modes in the list are completed as much as possible. After completion, the system performs a comprehensive verification of the final EDID, confirming that its total capacity does not exceed 256 bytes, all timing conforms to the HDMI 2.0 protocol specification, and field encoding and storage location are compliant. Finally, the EDID is provided to the TX end of the HDMI 2.0 extender, which then transmits it to the source device, completing the entire conversion process.

[0099] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0100] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 The EDID method is characterized by comprising the following steps: S1: Information Acquisition and Backup. Call the GetAllRefreshRate module, traverse the original HDMI2.1EDID through the parsing module, record all supported refresh rates to form a target refresh rate list, and back up all detailed timing descriptors (DTDs). S2: Space assessment, calculates the structural capacity of the 256-byte HDMI 2.0 standard EDID, and assesses the additional space that can be freed up after removing unnecessary information; S3: Protocol downgrade and capability conversion, calls the Limits module, traverses all data blocks, converts or discards video formats that exceed the bandwidth and capability range of HDMI 2.0, and initially sets the EDID data structure size to 256 bytes; S4: Space optimization and intelligent reconstruction, performing deletion, redundancy removal, information simplification, format conversion and selective discarding operations according to preset priorities, retaining high-priority display modes; S5: High refresh rate completion and final verification. Compare the list of supported refresh rates and target refresh rates after reconstruction of EDID. For unsupported high refresh rates, generate timing through CVT1.2 module or find the corresponding VIC, re-execute the space judgment and optimization of S4, and finally output a 256-byte EDID that conforms to the HDMI2.0 standard.

2. The method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 1, characterized in that: The parsing module in S1 includes the EDID1.3 & 1.4 module, the CTA-861-H module, and the DisplayID1.3 & 2.0 module; The traversal of the original HDMI2.1 EDID includes: traversing the Establishing Timings, Standard Timings, Detailed Timings and CVT Timings fields in the EDID1.4 Block, traversing the Detailed Timings, Video Data Block, HDMI1.4b Vendor Specific DataBlock, YCbCr 4:2:0 Video Data Block, YCbCr 4:2:0 Capability in the CTA-861 ExtensionBlock. Map Data Block, DisplayID Type VII Video Timing Data Block, DisplayID Type VIII Video TimingData Block, DisplayID Type Standard Data Block, TypeVII Detailed TimingData The Block, Type VIII Detailed Timing Data Block, and Type IX Detailed Timing Data Block are parsed and the supported frame rates are extracted.

3. The method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 1, characterized in that: The non-essential information in S2 includes Display Color Management (DCM) Data, Color Point Data, Display Range Limits, Alphanumeric DataString (ASCII), and Display Product Serial Number in the EDID 1.4 Block.

4. The method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 1, characterized in that: The processing procedure of the Limits module in S3 is as follows: traverse all timings, calculate the TMDS Clock corresponding to each timing, and if the TMDS Clock exceeds 600MHz, first convert the Colorspace to YCbCr 4:2:0 or reduce the FrameRate to reduce the TMDS Clock. If it is still impossible to make the TMDS Clock ≤ 600MHz, then discard the timing. Among them, the TMDS Clock corresponding to DTD is calculated according to the formula TMDS Clock = Htotal × Btotal × FrameRate × BitsPerPixel, where Htotal is the total number of horizontal pixels, Btotal is the total number of vertical rows, FrameRate is the frame rate, BitsPerPixel is the pixel width, the TMDS Clock corresponding to VIC is obtained by looking up a table, and the TMDS Clock corresponding to CVT is calculated by the VESA CVT 1.2 standard algorithm.

5. The method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 1, characterized in that: The preset priority order in S4 is as follows: first delete DTDs that cannot be supported by Block0 and Block1, then delete redundant DTDs with the same resolution, then delete unnecessary description fields, then perform format conversion, and finally discard low-priority display modes according to the high-priority display mode retention strategy.

6. A method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 5, characterized in that: The format conversion in S4 converts the DTD, which occupies 18 bytes of storage space, into a 1-byte VIC format or a 6-byte TypeX (CVT description) format.

7. A method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 1, characterized in that: The timing sequence generated by the CVT1.2 module in S5 is generated according to the algorithm principle in the VESA Coordinated VideoTimings (CVT) Standard Version 1.2 document to generate the corresponding video format timing sequence.

8. A method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 2, characterized in that: The EDID 1.3 & 1.4 modules provide interfaces for parsing and modifying the EDID basic block, the CTA-861-H module provides interfaces for parsing and modifying the CTA-861-H extension block, and the DisplayID 1.3 & 2.0 modules provide interfaces for parsing and modifying the DisplayID extension block.

9. A method for converting HDMI 2.1 high refresh rate EDID to HDMI 2.0 EDID according to claim 5, characterized in that: The high-priority display mode retention strategy in S4 prioritizes high refresh rates, followed by high resolutions, and prioritizes retaining display modes corresponding to high refresh rates such as 144Hz and 165Hz.

10. A method for converting HDMI 2.1 high refresh rate EDID to HDMI according to claim 5. 2.0 The EDID method is characterized by: The non-essential description fields mentioned in S4 are fields in EDID that do not affect display mode recognition and signal transmission compatibility, including manufacturer redundancy information and non-core product identification information.