High data rate interface

High data rate interface

In this disclosure, specific embodiments of the present invention are related to a digital signal protocol and procedure for transmitting or transmitting signals at a high data rate between a host device and a client device. More specifically, the present disclosure relates to a low-power high-data-rate transmission mechanism with internal and external device applications to transmit multimedia and other types of digital signals from the host or controller device to the client device for presentation or display to the terminal. User's technology.

In the past few years, computer, electronic game-related products and various video technologies (such as DVD and high-definition VCR) have been greatly improved, which can provide end users of such equipment with higher and higher resolution still, video, and video. Choose the presentation of video and graphic images, and even include certain types of text. These advancements in turn require the use of higher-resolution electronic viewing devices, such as high-quality video monitors, HDTV monitors, or dedicated image projection components. Combining such visual images with high-quality or high-quality audio data, such as when using CD-type audio reproduction, DVD, surround sound, and other devices that also have related audio signal output, is used to create changes for end users. Realistic, rich or authentic multimedia experience. In addition, highly mobile, high-quality sound systems and music transmission mechanisms for presenting audio only to end users have been developed, such as MP3 players. This has raised the expectations of typical users of commercial electronic devices from computers to televisions and even telephones, and they are now accustomed to and expect high-quality or high-quality output.

In a typical presentation scheme including electronic products, video data is usually transmitted using current technology at a rate best known as slow or medium, about one to tens of thousands of bits per second. This data is then buffered or stored in a transient or long-term memory device for delayed (later) playback on the desired viewing device. For example, images can be transmitted "through" or using the Internet as a program that resides on a computer (with modems or other types of Internet-connected devices) in order to receive or send data that can be used to present the image digitally. The same transmission can occur using a wireless device, such as a portable computer equipped with a wireless modem or a wireless Personal Data Assistant (PDA) or a wireless phone.

After receiving the data, the data is stored in the local memory components, circuits or devices, such as RAM or flash memory, including internal or external storage devices for playback, such as small hard drives. Depending on the amount of data and the resolution of the image, playback can start faster or be presented with a longer-term delay. That is, in some instances, the image is rendered as a very small or low-resolution image that does not require a lot of data or uses a certain type of buffer to provide a certain degree of real-time playback, so that after a small delay, some materials are presented while more materials are transmitted. If the transmission link is uninterrupted, or other systems or users related to the transmission channel used will not cause interference, once the presentation starts, the transmission is appropriately transparent to the end user of the viewing device. Naturally, if multiple users share a single communication path, such as a wired Internet connection, the transmission may be interrupted or slower than required.

The data used to create still images or motion videos is usually compressed using one of several well-known techniques, such as the Joint Photographic Experts Group (Joint Photographic Experts Group). Photographic Experts Group; JPEG), Motion Picture Experts Group (MPEG), and other well-known standards organizations or companies in the media, computer, and communications industries to develop technologies to speed up data transmission on communication links. This makes it possible to use a smaller number of bits to transmit a given amount of information to transmit images or data faster.

Once the data is transmitted to the "local (local)" device, such as a computer or other receiving device with a storage mechanism such as memory or magnetic or optical storage components, it will be decompressed according to the corresponding available presentation resolution and control components ( Or use a special decoding player to play), decode (if necessary) and prepare the final information for proper presentation. For example, according to the screen resolution of X by Y pixels, the typical computer video resolution is usually as low as 480×640 pixels, medium is 600×800, and as high as 1024×1024. However, there are generally many others depending on needs or circumstances. Resolution.

The image content, the ability of a given video controller to process the image according to certain predetermined color levels or color depths (bits used to produce colors per pixel) and intensity, and any additional management information bits used will also affect Image presentation. For example, normal computer rendering is expected to represent various colors (shadows and chroma) with approximately 8 to 32 or more bits per pixel, although other values may also be encountered.

It can be seen from the above values that in the range from the lowest to the highest typical resolution and depth, a given screen image will need to transmit 2.45 megabits (Mb) to approximately 33.55 Mb of data, respectively. When viewing video or motion images at a rate of 30 frames per second, the amount of data required is approximately 73.7 to 1,006 megabits of data (Mbps) per second, or approximately 9.21 to 125.75 hundred per second. Ten thousand bytes (MBps). In addition, it may be necessary to present audio data combined with images, such as for multimedia presentation, or as separate high-resolution audio presentation, such as CD-quality music. Additional signals for processing interactive commands, controls or signals can also be used. Each of these options adds more data to be transmitted. In addition, newer transmission technologies involving high-definition (HD) television and movie recording may add even more data and control information. In any situation, when high-quality or high-resolution image data and high-quality audio information or data signals need to be transmitted to end users to create a rich experience, the presentation components and configuration are the source or host device that provides this type of data Requires high data transfer rate between time.

Some modern serial interfaces can routinely handle data rates of approximately 115 kilobytes (KBps) or 920 kilobits (Kbps) per second. Other interfaces (such as the USB serial interface) can handle data transmissions up to 12 MBps, while dedicated high-speed transmission (such as those configured by the Institute of Electrical and Electronics Engineers (IEEE) 1394 standard) can be 100 Data is transmitted at a rate of 400 MBps level. Unfortunately, these rates cannot solve the above-mentioned expected high data rates. It is expected that they will be used in future wireless data devices and provide high-resolution, rich content, and output signals for driving portable video displays or audio devices. other service. This includes computers used for business and other presentations, gaming devices, etc. In addition, these interfaces require the use of a large number of hosts or systems and client software to operate. Its software protocol stack also creates an undesirable amount of management information, especially when using mobile wireless devices or phone applications. Such devices have strict limits on memory and power consumption, as well as reduced computing power. In addition, one These interfaces use huge cables, which are too bulky and do not meet the needs of highly aesthetically oriented mobile applications, and complex connectors, which increase cost or simply consume too much power.

There are other known interfaces, such as an analog video graphics adapter (VGA), a digital video interactive (DVI) or a gigabit video interface (GVIF) interface. Before these interfaces, the two were side-by-side interfaces, which processed data at a higher transmission rate, but also used bulky cables and consumed a large amount of power in the order of several watts. These features are not suitable for use with portable consumer electronic devices. Even the third interface consumes too much power and uses expensive or bulky connectors.

For some of the aforementioned interfaces, as well as other extremely high-speed data systems/protocols or transmission mechanisms associated with data transmission of fixedly installed computer equipment, there is another major disadvantage. Coping with the desired data transmission rate also requires a large amount of power and/or high current level operation. This greatly reduces the effectiveness of such technologies for highly mobile consumer-oriented products.

Usually, in order to use alternative solutions (such as optical fiber-type connections and transmission components) to cope with such data transmission rates, many additional converters and components are also required, which will increase complexity and cost, which is unsuitable for actual commercial consumer-oriented products. . In addition to the generally more expensive nature of optical systems, its power requirements and complexity also hinder the widespread use of lightweight, low-power, and portable applications.

What is missing in portable, wireless, or mobile applications is a high-quality presentation experience for highly mobile end users, which can be based on audio, video, or multimedia. That is, when using portable computers, wireless phones, PDAs, or other highly mobile communication devices or equipment, the currently used video and audio presentation systems or devices cannot deliver output at the desired high-quality level. Generally, the lack of perceptual quality is the result of the unobtainable high data rate required to transmit high-quality presentation data. This can include transmission to more efficient, advanced, or feature-rich external devices for presentation to end users, or on the internal client side of portable devices such as hosts and computers, game consoles, and mobile phones. Between transfers.

In the latter case, the internal video screens with higher and higher resolution and other professional input and/or output devices and connections are added to wireless devices like the so-called third-generation phones and to the so-called Significant progress has been made when it comes to laptops. However, internal data buses and connections can include bridging across rotating or sliding hinges or hinge-like structures that install or connect the video screen or other components to the mainframe and/or the main where various other control components and output components are located. shell. It is difficult to use previous technologies to construct high-output data transmission interfaces. These previous technologies may require up to 90 or more conductors on, for example, telephone lines to achieve the required output. This situation causes many manufacturing issues, costly issues, and reliability issues that need to be overcome.

Such problems and requirements will also be encountered in fixed-location installations, for example, adding communication or computing devices to appliances and other consumer devices to provide advanced data capabilities, Internet and data transmission connections Or built-in entertainment. Another example would be airplanes and buses, where individual video and audio display screens are installed in the seat backs. However, in this case Next, it is usually more convenient, efficient and easier to service that the main storage, processing or communication control components and the visual screen or audio output used for presenting information are separated by an interconnection link or channel. This link will need to handle a large amount of data to achieve the required output, as described above.

Therefore, a new transmission mechanism is needed to increase the amount of data output between a host device that provides data and a display device or component on the client side that presents output to end users.

The applicant has proposed such new transmission mechanisms in U.S. Patent Application Nos. 10/020,520 and 10/236,657. The titles of these two patents are both "Generate and implement communication protocols and "Interface" has now been patented, and these patents have been assigned to the assignee of the present invention and incorporated herein by reference. Also, application No. 10/860,116 entitled "Generation and Implementation of Signal Protocols and Interfaces for Higher Data Rates". The technologies described in these applications can greatly improve the transmission rate of large amounts of data in high-speed data signals. However, the demand for ever-increasing data rates (especially related to video presentation) continues to grow. Even if there are other data signal technologies under development, efforts are still needed to pursue faster transmission rates, improved communication link efficiency, and stronger communication links. Therefore, there is a continuous need to develop new or improved transmission mechanisms required to increase the data output between host and client devices.

The above-mentioned and other shortcomings in the present technology are solved by specific embodiments of the present invention. In these specific embodiments, new protocols and data transmission components, methods and mechanisms have been developed for the host computer at a high data rate. Transfer data between the device and the receiving client device.

The specific embodiment of the present invention relates to a mobile data digital interface (MDDI) for transmitting digital data between a host device and a client device at a high rate via a communication path, the communication path adopts a plurality of or a series of links together The packet structure is used to form a communication protocol for transmitting a set of pre-selected digital control and presentation data between the host and the client device. The physical layer of the host or user-side link controller uses the signal communication protocol or the link layer. At least one link controller residing in the host device is coupled to the client device through a communication path or link, and is configured to generate, send, and receive packets forming a communication protocol and form one or more digital presentation data Data packets of three types. This interface provides two-way transmission of information between the host and the client, which can reside in a common integral housing or supporting structure.

This implementation is generally all-digital in nature (except for the differential driver and receiver that can be easily implemented on a digital CMOS chip), requires several signals, such as six, and facilitates almost any data rate for the system designer Operation. This simple entity and link layer protocol makes it easy to integrate, and this simplicity combined with the sleep state makes the portable system have very low system power consumption.

To assist in use and acceptance, the interface will add very little device cost, will allow little power consumption, and can use standard battery voltage to power the display through the interface, and it can cope with pocket-sized devices. The interface can be expanded to resolutions other than HDTV, supports simultaneous stereo video and 7.1 audio for display devices, performs conditional updates of any screen area, and supports bidirectional multiple data types.

In another aspect of the specific embodiment of the present invention, at least one user The end link controller or the user end receiver is placed in the user end device and is coupled to the host device through a communication path or link. The client link controller is also configured to generate, send, and receive data packets that form a communication protocol and form one or more types of data packets with the digital presentation data. Generally, the host or link controller uses a state machine to process data packets for commands or certain types of signal preparation and query processing, but slower general-purpose processors can be used to process data and some are used in communication protocols. It is a less complicated packet. The host controller includes one or more differential line drivers, and the user-side receiver includes one or more differential line receivers coupled to the communication path.

The packets are grouped in a media frame. The media frames are communicated between the host and the client and have a predefined fixed length and a predetermined number of packets. The packets have Different lengths of change. Each packet includes a packet length field, one or more packet data fields, and a cyclic redundancy check field. Transmit or locate the sub-frame header packet at the beginning of other packet transmission from the host link controller. The communication protocol uses one or more video data stream type packets and audio data stream type packets to respectively transmit video type data and audio type data from the host to the client via the forward link for presentation to the user of the client device. The communication protocol uses one or more reverse link encapsulation type packets to transmit data from the client device to the host link controller. In some embodiments, these transfers include transferring data from an internal controller with at least one MDDI device to an internal video screen. Other specific embodiments may include transmission to the internal sound system and transmission from various input devices including joysticks and composite keyboards to the internal host device.

The host link controller generates a filler type packet to occupy the un-data Forward link transmission period. The communication protocol uses multiple other packets to transmit video information. Such packets include color mapping, bit block transmission, bit-mapped area filling, bit-mapped pattern filling, and transparent color actuation type packets. The communication protocol uses user-defined stream type packets to transmit interface-user-defined data. The communication protocol uses keyboard data and pointer device data type packets to transmit data that arrives or comes from a user input device associated with the client device. The communication protocol uses a link close type packet to terminate data transmission in either direction of the communication path.

The communication path usually includes or uses a cable with a series of four or more conductors and a shield. In addition, if necessary, printed wires or conductors can be used, some of which reside on the flexible substrate.

The host link controller requests the client device to send display capability information so as to determine the data type and data rate that the client can handle through the interface. The client link controller uses at least one display capability type packet to convey the display or presentation capability to the host link controller. The communication protocol uses multiple transmission modes. Each mode allows a different maximum number of data bits to be transmitted in parallel during a given time period. Each mode can be selected by negotiation between the host and the client link controller. These transmission modes can be dynamically adjusted during data transmission, and the same modes need not be used on the reverse link as they are used on the forward link.

In other aspects of some embodiments of the present invention, the host device includes a wireless communication device, such as a wireless phone, a wireless PDA, or a portable computer in which a wireless modem is placed. Typical client devices include portable video displays, such as micro display devices and/or portable audio presentation systems. Other In addition, the host can use storage components or components to store presentation data or multimedia data to be transmitted to the user of the client device for presentation.

In other aspects of some embodiments, the host device includes a controller or a communication link control device having a portable electronic device, such as a wireless communication device, such as a wireless phone, a wireless PDA, or a portable electronic device as described below. Drives in portable computers. A typical client device in this configuration includes a client circuit or integrated circuit or module, which is coupled to the host and resides in the same device, and coupled to the internal video display, such as the high resolution of a mobile phone Screen and/or portable audio presentation system, or in an alternative type of input system or device.

I. Overview

The general purpose of the present invention is to provide a mobile display digital interface (MDDI), as described below, which obtains or provides a transmission mechanism with high cost efficiency and low power consumption, which can use a "serial" type data link Or a channel, which realizes high-speed or extremely high-speed data transmission between a host device and a user-end device, such as a display element, via a short-range communication link. The mechanism itself is suitable for implementations with small connectors and flexible thin cables. These connectors and cables are particularly helpful in connecting the internal display element (of the housing or supporting frame) or the input device of the central controller, or the external The display element or device, such as a wearable microdisplay (goggles or projector), is connected to a portable computer, a wireless communication device or an entertainment device.

Although the terms "action" and "display" are related to the naming of the agreement, it should be understood that this is only for the convenience of having a standard name to familiarize yourself with the interface It is easy to understand with the agreement technicians. However, after reviewing the following specific embodiments, it is easy to understand that many non-related actions and non-related display applications will benefit from the application of this agreement and the resulting interface structure, and the MDDI mark is not intended to affect the invention or its specifics. Any limitations are imposed on the nature or usefulness of the examples.

One advantage of the specific embodiments of the present invention is that the technology provided for data transmission is low in complexity, low in cost, highly reliable, adaptable to the use environment, and very stable, while maintaining considerable flexibility.

The specific embodiments of the present invention can be used in various situations where a large amount of data (generally used in audio, video, or multimedia applications) is communicated or transmitted from a host or source device that generates or stores the data to a user display or presentation device at a high rate. A typical application (described below) is to transmit data from a portable computer or wireless phone or modem to a visual display device, such as a small video screen or a wearable micro-display appliance, such as goggles that include a small projection lens and a screen Or the form of a helmet, etc., or transfer from the host in this type of component to the client device. That is, from the processor to the internal screen or other presentation elements, and from various internal or external input devices using the user terminal to the internal (co-located in the same device housing or supporting structure) host.

The characteristics or attributes of MDDI make it independent of specific display or presentation technology. This is a highly flexible mechanism used to transmit data at a high rate, regardless of the internal structure of the data or the functional aspects implemented by the data or commands. This allows the timing of transmitting data packets to be adjusted to suit the peculiarities of a specific client device, such as a unique display that requires a specific device, or to meet the requirements of a combination of audio and video in some AV systems, or suitable for a specific input Devices, such as joysticks, touch pads, etc. This interface is extremely tolerant to display components or client devices, as long as the selected protocol is followed. In addition, the total serial link data or data rate can be varied within several levels, which allows the communication system or host device designer to optimize cost, power requirements, client device complexity and client device Update rate.

The data interface is mainly used to transmit large amounts of high-speed data over "wired" signal links or small cables. However, some applications can also use wireless links, including optical-based links, provided that they are configured to use the same packet and data structure developed for the interface protocol, and can maintain expectations with sufficiently low power consumption or complexity The transmission level in order to maintain practicality.

II. Environment

A typical application can be seen in FIGS. 1A and 1B. As shown in the figure, a portable or laptop computer 100 and a wireless phone or PDA device 102 are associated with display devices 104 and 106 and audio reproduction systems 108 and 112, respectively. Communication. In addition, FIG. 1A illustrates a potential connection to a larger display or screen 114 or video projector 116, which is only shown in one drawing for clarity, but it can also be connected to the wireless device 102. The wireless device can receive data now or have previously stored a certain amount of multimedia type data in a memory element or device for later presentation, so that the end user of the wireless device can view and/or listen to it. Since a typical wireless device is used for voice and simple text communication most of the time, it has a small display screen and a simple audio system (speaker) for conveying information to the user of the device 102.

The computer 100 has a much larger screen, but the external sound system is still insufficient, and it still lacks other multimedia presentation devices, such as high-definition televisions or movie screens. screen. The computer 100 is used for illustrative purposes, and the present invention can also be used in conjunction with other types of processors, interactive video games or consumer electronic devices. The computer 100 may adopt (but is not limited or limited to) a wireless modem or other built-in devices for wireless communication, or may be connected to such devices using cables or wireless links as needed.

This reduces the usefulness or experience pleasure of the presentation of more complex or "rich" data. Therefore, the industry is developing other mechanisms and devices to present information to end users and provide a minimum level of desired pleasant or positive experience.

As mentioned above, several types of display devices have been developed or are currently being developed for presenting information to end users of the device 100. For example, one or more companies have developed several sets of wearable goggles, which are used to project an image in front of the eyes of the device user to present a visual display. When correctly positioned, this type of device effectively "projects" the visual image, which, as observed by the user's eyes, is much larger than the component that provides visual output. In other words, the extremely small projection element allows the user's eyes to "see" an image that is much larger than what is possible with a typical LCD screen or the like. The use of larger visual screen images also allows the use of high resolution, which is much higher than the resolution possible with more limited LCD screen displays. Other display devices may include, but are not limited to, small LCD screens or various flat panel display elements, projection lenses, and display drivers for projecting images on the surface.

There may also be additional components connected to or associated with the wireless device 102 or computer 100 for presenting output to another user, or connected to another device, which transmits the signal elsewhere or stores it. For example, you can The data is stored in flash memory in optical form, such as a writable CD medium, or stored on a magnetic medium, such as a tape recorder or similar device, for later use.

In addition, many wireless devices and computers now have built-in MP3 music decoding capabilities, as well as other advanced sound decoders and systems. Generally speaking, portable computers use CD and DVD playback capabilities, and some of them have small dedicated flash memory readers to receive pre-recorded audio files. The problem with such capabilities is that the prospect of music files is highly increased and the experience of rich functions, but the decoding and playback procedures must be compatible. The same is true for digital video files.

To assist in sound reproduction, an external speaker 114 is shown in FIG. 1A, which may have additional components, such as subwoofer or "surround sound" speakers for front and rear sound projection. At the same time, the speaker or earphone 108 is indicated as being built into the supporting frame or mechanism of the micro display device 106 of FIG. 1B. As is well known, other audio or sound reproduction components can be used, including power amplification or sound shaping devices.

In any case, as described above, when high-quality or high-resolution image data and high-quality audio information or data signals need to be transmitted from data sources to end users via one or more communication links 110, a high data rate is required. That is, the transmission link 110 is obviously a potential bottleneck in the data communication described earlier, and will limit the system performance, because the current transmission mechanism cannot achieve the generally expected high data rate. For example, as mentioned above, for higher image resolution, such as 1024 by 1024 pixels, which has a color depth of 24 to 32 bits per pixel and a data rate of 30 fps, the data rate can approach more than 755 Mbps Or higher rate. In addition, such images can be presented as part of a multimedia presentation, which includes audio data and potentially additional signals for processing interactive games or communications, or various commands, controls, or signals, which further improve quality or data and data rates.

It is also obvious that the establishment of a data link requires almost no cables or interconnections, which means that the mobile device associated with the display is easy to use and is likely to be adopted by a larger user base. This is especially true when multiple devices are used together to create a complete audio-video experience, especially when the quality levels of displays and audio output devices increase.

In Figures 1C and 1D, we can see another typical application of many of the above and other improvements in video screens and other output or input devices. As shown in the figure, a portable or laptop computer 130 and a wireless phone Or the PDA device 140 communicates with the "internal" display devices 134 and 144 and the audio reproduction system 136 and 146, respectively.

In Figures 1C and 1D, the small cross-section of the overall electronic device or product is used to show the position of one or more internal hosts and controllers in a part of the device, and there is a universal communication link (here, 138 and 138, respectively). 148), across a well-known type of rotary joint used in the electronics industry today, and connect it to a video display element or screen with a corresponding user terminal. It can be seen that the amount of data involved in these transmissions requires a large number of conductors to form links 138 and 148. It is estimated that this type of communication link is close to 90 or more conductors in order to meet the growing demand for advanced color and graphics interfaces and display components on such devices because these types of parallel or other well-known interface technologies are available. To transfer such data.

Unfortunately, the higher data rate exceeds the currently available data transmission technology. This is based on the amount of original data that needs to be transmitted per unit time and based on the manufacturing of a reliable and cost-effective physical transmission mechanism.

A technology that needs to transmit data at a higher rate used to present the data transmission link or communication path between the component and the data source, which provides always (lower) power, light weight, and a simple and economical cable structure as much as possible . Applicants have developed new technologies or methods and equipment to achieve these and other purposes, enabling a large number of mobile, portable or even fixed-location devices to transmit data to desired displays, microdisplays or audio transmission components at extremely high data rates, and at the same time Keep the required low power consumption and complexity.

III. High-speed digital data interface system architecture

In order to establish and effectively utilize new device interfaces, signal protocols and system architectures have been developed that use low-power signals to provide extremely high data transmission rates. The protocol is based on a packet and a common frame structure, or linked together to form a structure of a communication protocol, the communication protocol is used to convey a set of preselected data or data types and a command or operation applied to the interface structure.

<b>A. Overview</b>

The devices connected by the MDDI link or communicating through the MDDI link are called the host and the client. The client is usually a certain type of display device, but other output and input devices may also be covered. The data from the host to the display travels in the forward direction (referred to as forward flow or link), and the data from the client to the host travels in the reverse direction (referred to as reverse flow or link), as actuated by the host. This is illustrated in the basic configuration shown in Figure 2. In FIG. 2, a two-way communication channel 206 is used to connect the host 202 to the user end 204, and the two-way communication channel 206 is Illustrated as a forward link 208 and a reverse link 210. However, these channels are formed by a common set of conductors, and the data transmission of this set of conductors can be effectively switched between forward or reverse link operation. This allows a significant reduction in the number of conductors, which instantly solves one of the many problems faced by current methods, namely high-speed data transmission in low-power environments, such as in mobile electronic devices.

As described elsewhere, the host includes one of several types of devices that can benefit from the use of the present invention. For example, the host 202 may be a handheld computer, a laptop portable computer, or a similar mobile computing device. It can be a personal data assistant (PDA), a paging device, or one of many wireless phones or modems. Alternatively, the host 202 may be a portable entertainment or presentation device, such as a portable DVD or CD player or game device.

In addition, the host can be used as a host device or control element to reside in a variety of other widely used or planned commercial products, and it is desirable to have a high-speed communication link between these products and the user end. For example, a host can be used to transmit data from a video recording device to a storage-based client at a high rate for improved response or to transmit data to a high-resolution large screen for presentation. An appliance, such as a refrigerator containing an on-board inventory or computing system and/or a Bluetooth connection with other household devices, has an improved display capability or a reduction when operating in an Internet or Bluetooth connection mode The demand for indoor display (user side) and keyboard or scanner (user side), while making the electronic computer or control system (host) reside elsewhere in the chassis. Generally speaking, those skilled in the art should understand that many modern electronic devices and appliances can benefit from the use of this interface and the ability to update older devices to use new or existing conductors or the limited number of conductors available in the cable At a higher data rate To transmit information.

At the same time, the client 204 may include a variety of devices that can be used to present information to the end user or present information from the user to the host. For example, micro-displays incorporated into goggles or glasses, projection devices built in hats or helmets, small screens or even full-information components built in vehicles (such as in the windows or windshields), or various speakers, earphones Or a sound system used to present high-quality sound or music. Other presentation devices include projectors or projection devices for presenting conference information or presenting movie and television influence information. Another example would be the use of touch pads or sensing devices, voice recognition input devices, security scanners, etc. These devices may be required to transmit large amounts of information from the device or system user, except for the user's touch or voice. In addition, only a small amount of actual "input" is used. In addition, computer docking stations, car kits or desktop kits, and wireless phone holders can serve as interface devices with end users or other devices and equipment, and use user terminals (output or input devices, such as sliding Mouse) or host to assist in data transmission, especially when high-speed networks are involved.

However, those skilled in the art will easily realize that the present invention is not limited to these devices. There are many other suggested devices on the market that aim to provide end users with high-quality images and sounds (in terms of storage and transmission or In terms of playback presentation). The present invention helps to increase the amount of data output between various components or devices to cope with the high data rate required to achieve the desired user experience.

The invented MDD interface and communication signal protocol can be used to simplify the interconnection (referred to as internal mode) between a host processor, controller or circuit component (for example) and a device or device housing or structure, in order to reduce cost or complexity Sex and These connections are related to power and control requirements or constraints, and improve reliability, not just for connections with external components, devices, or equipment (referred to as external modes).

The total serial link data rate on each signal pair used by this interface structure can vary within many orders of magnitude, so that a system or device designer can easily optimize for a given application or purpose. Cost, power, implementation complexity, and display update rate. The attributes of MDDI are independent of display or other presentation device (target client) technology. The timing of data packets transmitted through this interface can be easily adjusted to suit the particularity of specific clients (such as display devices, sound systems, memory and control components) or the combined timing requirements of audio-video systems. Although this makes the power consumption of the system very low, it does not require various users to have frame buffers in order to use the MDDI protocol at least at a certain level.

<b>B. Interface type</b>

The MDD interface is used to handle at least four or possibly more slightly different entity types in the communications and computer industries. These types are simply marked as Type 1, Type 2, Type 3, and Type 4, although according to the specific application or related industry, those familiar with the technology can use other marks or names. For example, simple audio systems use fewer connections than more complex multimedia systems, and can refer to features such as "channels" differently, and so on.

Type 1 interface is configured as a 6-wire or other type of conductor or conductive element interface, which makes it suitable for mobile or wireless phones, PDAs, electronic games and portable media players, such as CD players or MP3 players And similar Devices or similar types of devices used in consumer electronics technology. In a specific embodiment, an interface is configured as an 8-wire (conductor) interface, which is more suitable for laptops, notebooks, desktop personal computers and does not require fast data updates and does not have a built-in MDDI link Similar devices or applications of road controllers. This interface type can also be distinguished by an additional dual-wire Universal Serial Bus (USB) interface, which is very useful for dealing with existing operating systems or software support on most personal computers.

Type 2, Type 3, and Type 4 interfaces are suitable for high-performance clients or devices, and use larger and more complex cables with additional twisted-pair conductors to provide proper shielding and low-loss transmission of data signals.

The type 1 interface transmits signals that can include display, audio, control, and limited signaling information, and is generally used for mobile clients or client devices that do not require high-resolution full-rate video data. Type 1 interface can easily support 30 fps and SVGA resolution of 5.1 channel audio, and in the smallest configuration, only three wire pairs may be used in total, of which two wire pairs are used for data transmission and one wire pair is used For power transmission. This type of interface is mainly used for devices such as mobile wireless devices, and USB hosts are usually used for signal connection and transmission in such devices. In this configuration, the mobile wireless device is an MDDI host device and acts as a "master controller" to control the communication link from the host. The host usually sends data to the client (forward flow or link) for use For presentation, display or playback.

In this interface, the host activates the host by sending special commands or packet types to the client (so that it can control the bus (link) within a specific duration and send data to the host as a reverse packet) Receive from the client (anti Communication data to traffic or link). Figure 3 illustrates this situation, in which a type of packet called an encapsulated packet (described below) is used to cope with the transmission of reverse packets on the transmission link, thereby establishing a reverse link. The time interval allocated for the host to poll the client for information is determined in advance by the host and is based on the requirements of each designated application. If the USB port cannot be used for the transmission of information or data from the client, this type of half-duplex two-way data transmission is particularly advantageous.

A high-performance display capable of reaching HDTV type or similar high-resolution requires a data stream at a rate of approximately 1.5 Gbps in order to support full-motion video. The type 2 interface supports high data rates by sending 2 bits in parallel, the type 3 interface sends 4 bits in parallel, and the type 4 interface sends 8 bits in parallel. Type 2 and Type 3 interfaces use the same cables and connectors as Type 1, but can operate at twice and four times the data rate to support higher performance video applications on portable devices. The Type 4 interface is suitable for very high-performance clients or displays, and requires larger cables to contain additional twisted-pair data signals.

The protocol used by MDDI allows each type 1, type 2, type 3, or type 4 host to generally negotiate with any type 1, type 2, type 3, or type 4 host by negotiating the highest possible data rate that can be used. Type 4 client communication. The capabilities or available functions that can be referred to as the least capable devices are used to set link performance. As a result, even for systems in which both the host and the client can use the Type 2, Type 3, or Type 4 interface, both of them start to operate as the Type 1 interface. The host then determines the capabilities of the target client, and according to the specific application, negotiates a handover or reconfiguration operation to switch to the type 2, type 3, or type 4 mode.

The host can generally use the appropriate link layer protocol (as discussed further below), and degrade or reconfigure the operation again at substantially any time to Switch to a slower mode to save power, or upgrade to a faster mode to support higher-speed transmission, such as for higher-resolution display content. For example, when the system is switched from battery power to AC power, or when the display media source is switched to a lower or higher resolution format, the host can change the interface type, or it can be affected by this or other conditions or events. Combination is regarded as the basis for changing the interface type or transmission mode.

The system can also use one mode to convey data in one direction, and use another mode to convey data in the other direction. For example, the type 4 interface mode can be used to transmit data for high-speed display, while the type 1 mode is used when transmitting data from a peripheral device (such as a keyboard or pointing device) to a host device. Those skilled in the art should understand that the host and the client can communicate output data at different rates.

Generally, users of the MDDI protocol can distinguish between the "external" mode and the "internal" mode. An external mode describes the use of protocols and interfaces to connect a host in a device to a client that is at most about 2 meters away from the host outside the device. In this case, the host can also transmit power to the external client, so that the two devices can easily operate in a mobile environment. An internal mode describes connecting the host to the client contained in the same device, such as a common housing or supporting structure or the same kind of structure. An example is an application in a wireless phone or other wireless device, or a portable computer or game device, where the client is a monitor or display driver, or an input device, such as a keyboard or touch pad or a sound system, and the host It is the central controller, graphics engine or CPU component. Because the user terminal in the internal mode application is closer to the host than the external mode application, there is generally no power connection in this type of configuration. Connect to the requirements stated on the user side.

<b>C. Physical interface structure</b>

Figures 4 and 5 illustrate the general deployment of a device or link controller for establishing communication between a host and a client device. In FIGS. 4 and 5, the MDDI link controllers 402 and 502 shown are installed in the host device 202, and the MDDI link controllers 404 and 504 shown are installed in the client device 204. As described above, the host 202 is connected to the user terminal 204 using a bidirectional communication channel 406 including a series of conductors. As described below, a single circuit design can be used to manufacture both the host and the client link controller as an integrated circuit, which can be set, adjusted or programmed to act as a host controller (driver) or a client controller (receiver) ) Response. Due to the large-scale manufacturing of a single circuit device, the manufacturing cost of this solution is lower.

In FIG. 5, the MDDI link controller 502 is shown installed in the host device 202', and the MDDI link controller 504 is shown installed in the client device 204'. As described above, the host 202' is connected to the client 204' using a bidirectional communication channel 506 including a series of conductors. As mentioned above, a single circuit design can be used to manufacture the host and client link controllers.

Figures 4 and 5 also illustrate the signals transmitted between the host and the user end (such as a display device) through the MDDI link or the physical conductor used. As shown in Figures 4 and 5, the main path or mechanism for data transmission through MDDI uses data signals marked MDDI_Data0+/- and MDDI_Stb+/-. Each of these signals is a low-voltage data signal transmitted on the differential conductor pair of the cable. For each bit transmitted on the interface, there is only one transition on the MDDI_Data0 pair or the MDDI_Stb pair. This is a transmission mechanism based on voltage rather than current, so static The state current consumption is close to zero. The host drives the MDDI_Stb signal to the user-side display.

Although data can flow in the forward and reverse directions through the MDDI_Data pair, that is, it is a two-way transmission path, the host is the master or controller of the data link. The MDDI_Data0 and MDDI_Stb signal paths operate in a differential mode to maximize noise immunity. The clock rate transmitted by the host determines the data rate of the signals on these lines, which can vary from about 1 kbps to a maximum of 400 Mbps or higher.

The type 2 interface contains an additional data pair or conductor or path other than the type 1, called MDDI_Data11+/-. The Type 3 interface contains two additional data pairs or signal paths in addition to the Type 2 interface, called MDDI_Data2+/- and MDDI_Data3+/-. The Type 4 interface contains four additional data pairs or signal paths other than the Type 3 interface, called MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/-, and MDDI_Data7+/-. In each of the above-mentioned interface configurations, the host can use wire pairs or signals designated as HOST_Pwr and HOST_Gnd to transmit power to the client or display. As described further below, if necessary, when the interface "type" uses less conductors than other devices can use or provide for other devices, some configurations can be used in MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/- Or MDDI_Data7 +/- conductor to deal with power transmission. The external mode generally uses this power transmission, while the internal mode generally does not require this, although some applications may be different.

The following table I describes the summary of the signals transmitted between the host and the client (display) through the MDDI link for various modes according to the interface type.

<tables><img file="TWI345404B_D0001.tif" /></tables>

It should also be noted that the HOST_Pwr/Gnd connection for transmission from the host is generally provided for external mode. Internal applications or operating modes generally have user terminals that directly obtain power from other internal resources, and do not use MDDI to control power allocation. Those skilled in the art should understand this type of power allocation, so it will not be discussed in further detail here. However, it is of course possible to allocate power through the MDDI interface to provide, for example, specific types of power control, synchronization or interconnection convenience, as those skilled in the art understand.

The nominal length of the cables commonly used to implement the above structures and operations is about 1.5 meters, generally 2 meters or less, and contains three twisted pair conductors, each twisted pair is in turn a multi-strand 30 AWG wire. The foil shielding is wrapped around or otherwise formed over the three twisted pairs as an additional drain wire. The twisted pair and the shielded drain conductor are terminated in the display connector, and the shield is connected to the It is shielded and has an insulating layer covering the entire cable, as is well known in this technology. The wires are paired as follows: HOST_Gnd and HOST_Pwr; MDDI_Stb+ and MDDI_Stb-; MDDI_Data0+ and MDDI_Data0-; MDDI_Data1+ and MDDI_Data1-; and so on.

<b>D. Data type and rate</b>

In order to achieve a useful interface for a full range of user experiences and applications, the Mobile Digital Data Interface (MDDI) can support a variety of clients and display information, audio transceivers, keyboards, pointing devices and many other devices that can be integrated into or integrated with mobile displays The input or output device that the device cooperates with, and the control information and its combination. The MDD interface is designed to be able to use the minimum number of cables or conductors to cope with various possible types of data flows between the host and the client in the forward or reverse link direction. Support synchronous data stream and asynchronous data stream (update). Many combinations of data types are possible, as long as the total data rate is less than or equal to the maximum required MDDI link rate, which is limited by the maximum serial rate and the number of data pairs used. Such combinations may include (but are not limited to) the items listed in Tables II and III below.

<tables><img file="TWI345404B_D0002.tif" /></tables>

<tables><img file="TWI345404B_D0003.tif" /></tables>

The interface is not fixed, but extensible, so that it can support the transmission of various information "types", including user-defined data for future system flexibility. Examples of specific data to be dealt with are: full or partial screen bit-mapped fields or full-action video in the form of compressed video; low-rate static bit-mapped to save power and reduce implementation costs; PCM or compressed audio at various resolutions or rates Data; pointer device location and selection, and user-definable data for capabilities that need to be defined. Such data can also be transmitted with control or status information to detect device capabilities or set operating parameters.

The specific embodiments of the present invention promote the use of technology for data transmission, including but not limited to: watching movies (video display and audio); using personal computers with limited personal viewing (graphic display, sometimes combined with video and audio) ); playing video games (dynamic graphic display, or composite video and audio) on PC, console or personal device; using video phone (two-way low-rate video and audio), camera for taking still digital photos, or camera for capturing digital video images A device in the form of a camera for Internet "surfing"; using a phone, computer or PDA, which is connected to a projector for presentation or a desktop docking station connected to a video monitor, keyboard and mouse; Honeycomb Productivity enhancement or entertainment use of phones, smart phones or PDAs, including wireless pointing devices and keyboard data.

The following high-speed data interfaces are used to provide a large amount of AV-type data through communication or transmission links, and these links are generally configured as wired lines or cable-type links. However, it can be easily understood that the signal structure, protocol, timing, or transmission mechanism can be adjusted to provide a link in the form of optical or wireless media, as long as it can maintain the desired data transmission level.

The MDD interface signal uses a concept known as Common Frame Rate (CFR) for the basic signal protocol or structure. The idea of using a common frame rate is to provide synchronization pulses for simultaneous synchronization of data streams. The client device can use this common frame rate as a time reference. The low CF rate increases the channel efficiency by reducing the management information used to send the sub-frame header. On the other hand, a high CF rate reduces latency and provides a smaller flexible data buffer for audio samples. The CF rate of the interface of the present invention can be dynamically programmed, and can be set to one of many values suitable for the synchronous data stream used in a specific application. That is, if necessary, the CF value can be selected to best adapt to the provided client and host configuration.

Table IV shows the number of bytes generally required for each sub-frame, which can be adjusted or programmable for the most likely synchronous data stream used by an application, such as video or micro-display.

<tables><img file="TWI345404B_D0004.tif" /></tables>

Use a simple programmable M/N counter structure to easily obtain the score count of the byte of each sub-frame. For example, the counting of 26-2/3 bytes per CF is implemented by transmitting 27 bytes of 2 frames each following 26 bytes of a subframe. A smaller CF rate can be selected to generate an integer number of bytes per sub-frame. However, generally speaking, a simple M/N counter implemented by hardware should make the area required for implementing some or all of the specific embodiments of the present invention in the integrated circuit chip or electronic module less than a larger audio sampling The area required for the FIFO buffer.

An exemplary application that illustrates the influence of different data transmission rates and data types is the Karaoke system. Karaoke is a system where one end user or several users sing along with a music video program. The lyrics are displayed somewhere on the screen, usually at the bottom of the screen, so that the user can understand the text being sung and the approximate timing of the song. This application requires the video display to perform infrequent graphic display and to mix the user's voice with the stereo audio stream.

If it is assumed that the common frame rate is 300 Hz, each sub-frame will consist of the 92,160-byte video content and the 588 bytes of audio content (based on 147 16-bit stereo samples), and an average of 26.67 (26-2/3) bytes of voice is sent back from the microphone to the mobile Karaoke machine. Send asynchronous packets between the host and the display (possibly head-mounted). This includes graphics data of up to 768 bytes (a quarter of the screen height), and miscellaneous control and status commands less than about 200 bytes (several) bytes.

Table V shows how to allocate data in the subframe used for the Karaoke example. The total rate used was chosen to be approximately 279 Mbps. The slightly higher rate of 280 Mbps can transmit about 400 bytes of another data per sub-frame, which makes it possible to use occasional control and status messages.

<tables><img file="TWI345404B_D0005.tif" /></tables>III. (Continued) High-speed digital data interface system architecture

<b>E. Link layer</b>

The data transmitted by the high-speed serial data signal using the MDD interface consists of successively linked time multiplexed packet streams. Even if the sending device has no data to transmit, the MDDI link controller will generally automatically transmit the filler packet to maintain the packet flow. The use of a simple packet structure ensures reliable synchronization timing for video and audio signals or data streams.

The packet group is included in a signal element or structure called a sub-frame, and the sub-frame group is included in a signal element or structure called a media frame. The sub-frame includes one or more packets, depending on its individual size and data transmission usage, while the media frame includes one or more sub-frames. The maximum sub-frame provided by the protocol adopted by the specific embodiment disclosed here is 2³²-1 or 4,294,967,295 byte level, and the maximum media frame size becomes 2¹⁶-1 or 65,535 sub-frame level.

The special sub-frame header packet contains a unique identifier, which appears at the beginning of each sub-frame, as described below. The identifier is also used to obtain the frame timing at the client device when the communication between the host and the client is initiated. The link timing acquisition will be described in detail below.

Generally, when a full-motion video is displayed, the display screen is updated once for each media frame. The display frame rate is the same as the media frame rate. The link protocol supports full-motion video on the entire display, or only full-motion video content in a small area surrounded by static images, depending on the desired application. In some low-power mobile applications, such as viewing web pages or emails, the display screen may only need to be updated occasionally. In these situations, it is advantageous to send a single sub-frame and then close or disable the link in order to minimize power consumption. The interface also supports effects such as stereo vision and handles graphics primitives.

The sub-frame enables the system to periodically transmit high-priority packets. This allows simultaneous simultaneous data streams to coexist with a minimum number of data buffers. This embodiment provides an advantage for the display program, allowing multiple data streams (high-speed communication of video, voice, control, status, and pointing device data) to substantially share a common channel. It uses relatively few signals to transmit information. It also enables display-technology-specific actions, such as horizontal synchronization pulses and blank intervals for CRT monitors, or other client-technology-specific actions.

<b>F. Link Controller</b>

The MDDI link controller shown in Figures 4 and 5 is manufactured or assembled into a fully digital implementation, except for the differential line receiver for receiving MDDI data and strobe signals. However, even the differential line driver and receiver can be implemented in the same digital integrated circuit with the link controller, for example when manufacturing CMOS type ICs. There is no need for analog functions or phase-locked loop (PLL) hardware for bit recovery or implementation of the link controller. The host and client link controllers contain very similar functions, except for the client interface that includes a state machine for link synchronization. Therefore, the specific embodiments of the present invention can provide a practical advantage, that is, a single controller design or circuit that can be configured as a host or a client can be established, thereby reducing the overall manufacturing cost of the link controller.

IV. Interface link protocol

<b>A. Frame structure</b>

Figure 6 illustrates the signal protocol or frame structure used to implement forward link communication for packet transmission. As shown in Figure 6, information or digital data is grouped into components called packets. Multiple packets are then grouped together to form the so-called "sub Frame", and multiple sub-frames are grouped together to form a "media" frame. In order to control the formation of the frame and the transmission of the sub-frames, each sub-frame starts with a special predefined packet called a Sub-frame Header Packet (SHP).

The host device selects the data rate needed for a given transmission. The host device can dynamically change the data rate according to the maximum transmission capacity of the host or the data being retrieved by the host from the data source, and the maximum capacity of the client or other devices to which the data is transmitted.

The receiving client device designed or capable of working with MDDI or the signal protocol of the present invention can be queried by the host to determine the maximum or current maximum data transmission rate that can be used, or can use a preset slower rate and available data Types and supported functions. This information can be transmitted using the Display Capability Packet (DCP) described further below. This client display device can use the preselected minimum data rate or an interface within the minimum data rate range to transmit data or communicate with other devices, and the host will use the data rate within this range to perform queries to determine the full capabilities of the client device .

Other status information that defines the nature of the bit mapping and the rate capability of the client video frame can be transmitted to the host in the status packet so that the host can configure the interface to be as efficient or optimal as possible, or to meet any system constraints.

When there are no (more) data packets to be transmitted in the current subframe, or when the host cannot transmit at a rate sufficient to match the data transmission rate selected for the forward link, the host sends a filler packet. Because each sub-frame starts with a sub-frame header packet, the end of the previous sub-frame contains a just before padding A packet of a subframe (most likely a filler packet). In the case where the data carrying packet itself lacks space, the filler packet is most likely to be the last packet in the subframe, or before the end of the next previous subframe and before a subframe header packet. The task of controlling operations in the host device is to ensure that for each packet to be sent in a sub-frame, there is enough free space in the sub-frame. At the same time, once the host device starts the transmission of the data packet, the host must be able to successfully complete the data packet of that size in the frame without causing a data underload condition.

In one aspect of the present invention, the sub-frame transmission has two modes. One mode is a periodic sub-frame mode, or periodic period, for transmitting real-time video and audio streams. In this mode, the sub-frame length is defined as non-zero. The second mode is an asynchronous or aperiodic mode in which only when new information is available, a frame is used to provide bit-mapped data to the client. This mode is defined by setting the sub-frame length to zero in the sub-frame header packet. When using the periodic mode, the sub-frame packet reception can start when the client has synchronized to the forward link frame structure. This corresponds to the "synchronizing" state defined according to the state diagrams discussed below in relation to FIGS. 49 to 63. In the asynchronous aperiodic sub-frame mode, the repetition starts after receiving the first sub-frame header packet.

<b>B. Overall packet structure</b>

The following disclosure is used to describe the packet format or structure of the signaling protocol implemented by the specific embodiment. Please remember that the interface can be expanded and additional packet structures can be added as needed. According to the function of the packet in the interface, that is, the command or data transmitted by it, the packet is marked or divided into different "packet types". therefore, Each packet type represents a predefined packet structure for a given packet (which is used to process the transmitted packet and data). It can be easily understood that the packet can have a preselected length or a variable or dynamically changeable length depending on its individual function. Communication packages can also have different names, although they still perform the same function, as happens when the protocol is changed in the process of acceptance as a standard. The byte or byte value used in various packets is configured as a multi-bit (8 or 16-bit) unsigned integer. Tables VI-1 to VI-4 illustrate the summary of the packet used with its "type" designation, listed in order of type.

For ease of explanation and understanding, each table represents a common "type" of the packet in the overall packet structure. These groupings do not constitute a limitation or other implicit or explicit influence on the present invention, and the information packets can be organized in many other ways as needed. It also records the direction in which the packet transmission is considered valid.

<tables><img file="TWI345404B_D0006.tif" /></tables><tables><img file="TWI345404B_D0007.tif" /></tables>

<tables><img file="TWI345404B_D0008.tif" /></tables>

<tables><img file="TWI345404B_D0009.tif" /></tables><tables><img file="TWI345404B_D0010.tif" /></tables>

<tables><img file="TWI345404B_D0011.tif" /></tables><tables><img file="TWI345404B_D0012.tif" /></tables>

It can be clearly seen from the other contents of this article that although the reverse encapsulation packet, the client capability packet, and the client request and status packet are considered to be very important or required for external mode operation, they are not relevant for internal mode operation. In other words, it can be considered optional. This establishes another type of MDD interface protocol, which can communicate data at a very high speed with a reduced set of communication packets, and correspondingly simplify control and timing.

The packet has a common basic structure or a whole set of minimum fields, including a packet length field, a packet type field, a data byte field, and a CRC field, as shown in Figure 7. As shown in FIG. 7, the packet length field contains information in the form of multiple bits or byte values, which specifies the total number of bits in the packet or the length between the packet length field and the CRC field. In a specific embodiment, the packet length field contains an unsigned integer with a width of 16 bits or 2 bytes, which specifies the length of the packet. The packet type field is another multi-bit field that specifies the type of information contained in the packet. In an exemplary embodiment, this is a 16-bit or 2-byte wide value, in the form of a 16-bit unsigned integer, and specifies features such as display capability, handover, video or audio streaming, Data types such as status.

The third field is a data byte field, which is included in the host and client installations Interleaved bits or data transmitted or transmitted as part of the packet. The data format is clearly defined for each packet type according to the specific type of the transmitted data, which can be divided into a series of additional fields, each field having its own format requirements. That is, each packet type will have a format defined for this part or field. The last field is the CRC field, which contains the results of the 16-bit cyclic redundancy check calculated on the data byte, packet type and packet length fields to confirm the integrity of the information in the packet. In other words, the calculation is performed on the entire packet except for the CRC field itself. The client generally keeps the total count of detected CRC errors, and reports this count back to the host using client request and status packets (see below for details).

Generally speaking, the width and organization of these fields are designed to maintain 2-byte fields aligned on an even-byte boundary, and 4-byte fields aligned on a 4-byte boundary. . This enables the packet structure to be easily established in the main memory space of the host or the main memory space related to the host without violating the data-type alignment rules encountered by most or commonly used processors or control circuits.

During the transmission of the message packet, the field sent first starts with the least significant bit (Least Significant Bit; LSB) and ends with the most significant bit (Most Significant Bit; MSB) sent last. Parameters with a length greater than one byte are sent first using the least significant byte. The resulting bit transfer pattern is used for parameters longer than 8 bits and the shorter parameter with LSB first. It's the same. The data fields of each packet are generally sent in the order defined in the following paragraphs. The first field listed is sent first, and the last field is sent last. MDDI_Data0 The data on the signal path is aligned with the bit "0" of the byte sent on the interface in any mode (Type 1, Type 2, Type 3, or Type 4).

When processing the data for the display, the data for the pixel array is first sent in columns and then in rows, as in the traditional implementation in electronic technology. In other words, all pixels appearing in the same column of the bitmap are sent in the order that the leftmost pixel is sent first and the rightmost pixel is sent last. After sending the rightmost pixel in the column, the next pixel in the sequence is the leftmost pixel in the next column. For most displays, the pixel columns are generally sent in order from top to bottom, although other configurations can be adapted as needed. In addition, in processing bit mapping, the traditional method (described below) defines the reference point by marking the upper left corner of the bit mapping as a position or offset "0,0". The X and Y coordinates used to define or determine the position in the bitmap increase in value as they approach the right and bottom of the bitmap, respectively. The first column and the first row (upper left corner of the image) start at index value zero. As seen by the user of the display, the size of the X coordinate increases toward the right side of the image, and the size of the Y coordinate increases toward the bottom of the image.

The display window is the visible part of the bitmap, that is, the pixel part of the bitmap that can be seen by the user on the physical display medium. The size of the display window and the bitmap are usually the same. The upper left corner of the display window always displays the bitmap pixel position 0,0. The width of the display window corresponds to the X axis of the bitmap, and the width of the display window should be less than or equal to the width of the corresponding bitmap. The height of the window corresponds to the Y-axis of the bitmap, and the height of the display window should be less than or equal to the height of the corresponding bitmap. The display window itself cannot be addressed in the protocol, because it is only defined as the visible part of the bitmap.

The relationship between bit mapping and display window is in the computer, electronic technology, network The Department of Internet communications and other electronics-related technologies is well known. Therefore, these principles are not further discussed or explained here.

<b>C. Information package definition</b>

<b><i>1. Sub-frame header packet</i></b>

The sub-frame header packet is the first packet of each sub-frame, and has a basic structure as shown in FIG. 8. The sub-frame header packet is used to synchronize the host and the client. Each host should be able to generate this packet, and each client should be able to receive and interpret this packet. As shown in a specific embodiment of FIG. 8, this packet type is structured to have packet length, packet type, unique characters, reserved 1, sub-frame length, protocol version, sub-frame count, and media information. The frame count field is generally in this order. In a specific embodiment, this type of packet is generally recognized as a 15359 (hexadecimal 0x3bff) type packet, and uses a preselected fixed length of 20 bytes, excluding the packet length field.

The packet type field and the unique character field each use a 2-byte value (16-bit unsigned integer). The 4-byte groups of these two fields are combined to form a 32-bit unique character with good autocorrelation. In a specific embodiment, the actual unique character is 0x005a3bff, and the lower 16 bits are first transmitted as the packet type, and then the most significant 16 bits are transmitted.

The reserved 1 field contains 2 bytes of reserved space for future use, and is generally configured to set all bits to zero at this time. The purpose of this field is to align the subsequent 2-byte field with a 16-bit character address, and align the 4-byte field with a 32-bit character address. The least significant byte is reserved to indicate that the host can address multiple client devices. A value of zero is reserved to indicate that the host can operate using only a single client device.

The sub-frame length field contains 4 bytes of information or value to specify the number of bytes of each sub-frame. In a specific embodiment, the length of this field is set to zero to indicate that the host sends only one sub-frame before closing the link to the idle state. The value in this field can be dynamically changed "on the fly" when changing from one sub-frame to the next. This capability can be used to make minor timing adjustments in the synchronization pulse used to cope with the synchronization data stream. If the CRC of the sub-frame header packet is invalid, the link controller should use the sub-frame length of the previously known good sub-frame header packet to estimate the length of the current sub-frame.

The protocol version field contains 2 bytes, which specifies the protocol version used by the host. Set the protocol version field to "0" to specify the first or current version of the protocol used. Over time, this value will change when a new version is created.

The sub-frame count field contains 2 bytes, which specifies a serial number indicating the number of sub-frames that have been sent since the start of the media frame. The first subframe of the media frame has a zero subframe count. The last sub-frame of the media frame has a value of n-1, where n is the number of sub-frames of each media frame. It should be noted that if the length of the sub-frame is set equal to zero (indicating an aperiodic sub-frame), the sub-frame count must also be set equal to zero.

The media frame count field contains 4 bytes (32-bit unsigned integer) to specify a serial number, which indicates the number of media frames that have been transmitted since the current media item or data was transmitted. The first media frame of the media item has a zero media frame count. The media frame count only increases before the first sub-frame of each media frame, and the largest media frame count is used (for example, the number of media frames 2³²-1=4,294,967,295) and then return to zero. The media frame count value can generally be reset by the host at any time To meet the needs of terminal applications.

<b><i>2. Filler symbol packet</i></b>

The filler packet is a packet that has no other information available for transmission to or from the client device when it is transmitted on the forward or reverse link. It is recommended that the filler packet has a minimum length to provide maximum flexibility when other packets need to be transmitted. At the end of the sub-frame or reverse link encapsulated packet (see below), the link controller sets the size of the filler packet to fill the remaining space and maintain the integrity of the packet. When the host or client does not have the information to be transmitted or exchanged, the filler packet helps to maintain the timing on the link. Each host and client needs to be able to transmit and receive this packet to effectively use this interface.

Figure 9 shows the format and content of the filler packet. As shown in Figure 9, this type of packet is structured to have packet length, packet type, filler byte and CRC field. In a specific embodiment, this type of packet is generally identified as type 0, which is indicated in the 2-byte type field. The bit or byte in the filler byte field includes a variable number of all-zero bit values, so that the filler packet is at a desired length. The minimum filler packet does not contain bytes in this field. That is, the packet is only composed of packet length, packet type, and CRC, and in a specific embodiment, a 6-byte preselected fixed length or packet length value of 4 is used. Determine the CRC value of all bytes in the packet including the packet length, and the packet length may be excluded in some other packet types.

<b><i>3. Video streaming package</i></b>

Video streaming packets carry video data in order to update the area of the display device, which is usually rectangular. The size of this area can be as small as a single pixel or as large as the entire display Device. An almost unlimited number of data streams can be displayed at the same time, which is limited by system resources, because all the content needed to display the data stream is contained in the video stream packet. FIG. 10 shows the format (video data format descriptor) of a specific embodiment of a video streaming packet. As shown in FIG. 10, in a specific embodiment, this type of packet is structured to have packet length (2 bytes), packet type, bClient ID, video data descriptor, pixel display attributes, X left edge, Y top edge, X right edge, Y bottom edge, X and Y start, pixel count, parameter CRC, pixel data and pixel data CRC fields. This type of packet is generally recognized as type 16, which is indicated in the 2-byte type field. In a specific embodiment, the client uses the RGB, monochrome, and Y Cr Cb capability fields of the client capability packet to indicate the capability of receiving the video stream packet.

In a specific embodiment, the bClient ID field contains 2 bytes of information, which is reserved for a client ID. Because this is a newly developed communication protocol, the actual client ID is not yet known or fully communicated. Therefore, the bit in this field is generally set to be equal to zero until such ID value is known, at which time the ID value is inserted or used, as understood by those skilled in the art. The same procedure generally applies to the following client IDs.

The above-mentioned common frame concept is an effective way to minimize the size of the audio buffer and reduce the latency. However, for video data, it may be necessary to extend the pixels of one video frame to multiple video stream packets in the media frame. It is also very possible that the pixels in a single video stream packet will not accurately correspond to the perfect rectangular window on the display. For an exemplary video frame rate of 30 frames per second, there are 300 subframes per second, which results in each media frame With 10 sub-frames. If there are 480 columns of pixels in each frame, each video stream packet in each sub-frame will contain 48 columns of pixels. In other cases, the video stream packet may not contain an integer number of pixel rows. This is true for other video frame sizes, where the number of sub-frames of each media frame is not evenly divided into the number of rows of each video frame (also known as video lines). Each video stream packet generally must contain an integer number of pixels, even though it may not contain an integer number of pixel rows. This becomes important if each pixel has more than one byte, or if it is in the packaging format shown in Figure 12.

11A to 11E show the format and content for implementing the operation of the exemplary video data descriptor field described above. In FIGS. 11A to 11E, the video data format descriptor field contains 2 bytes in the form of a 16-bit unsigned integer, which specifies the format of each pixel in the pixel data of the current data stream in the current packet. Different video stream packets may use different pixel data formats, that is, use different values in the video data format descriptor. Similarly, the data stream (display area) can change its data format during operation. The pixel data format should conform to at least one valid format of the client defined in the client capability packet. The video data format descriptor defines the pixel format used for this packet, but it does not mean that the constant format will continue to be used for the entire lifetime of a particular video stream.

Figures 11A to 11D illustrate how to encode video data format descriptors. As used in these drawings and this specific embodiment, when the bit [15:13] is equal to "000", as shown in FIG. 11A, the video data is composed of a monochrome pixel array, and the video data format descriptor Bits 3 to 0 of the character define the number of bits per pixel. Bits 11 to 4 are generally reserved for future use or application, and in this case are set to zero. When bit [15:13] is equal to "001", As shown in FIG. 11B, the video data is composed of an array of color pixels, and each color pixel is assigned a color through color mapping (palette). In such situations, bits 5 to 0 of the video data format descriptor character will define the number of bits per pixel, and bits 11 to 6 are generally reserved for future use or application and are set equal to zero. When the bit [15:13] is equal to "010", as shown in Figure 11C, the video data consists of a color pixel array, where the number of bits of each red pixel is defined by bits 11 to 8, each green The number of pixels of a pixel is defined by bits 7 to 4, and the number of bits of each blue pixel is defined by bits 3 to 0. In this case, the total number of bits in each pixel is used for the sum of the number of red, green, and blue bits.

However, when the bit [15:13] is equal to "011", as shown in Figure 11D, the video data consists of a 4:2:2 YCbCr format video data array with luminance and chrominance information, each of which The number of bits of the luminance pixel (Y) is defined by bits 11 to 8, the number of bits of the Cb component is defined by bits 7 to 4, and the number of bits of the Cr component is defined by bits 3 to 0. The total number of bits in each pixel is the sum of the number of bits used for red, green, and blue. The transfer rate of the Cb and Cr components is half of Y. In addition, the video samples in the pixel data part of this packet are organized as follows: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,..., Among them, Cbn and Crn are related to Yn and Yn+1, and Cbn+2 and Crn+2 are related to Yn+2 and Yn+3, and so on.

Yn, Yn+1, Yn+2, and Yn+3 are the brightness values of four consecutive pixels from left to right in a single column. If there is an odd number of pixels in one row of the window (X right edge-X left edge + 1) involved in the video stream packet, it corresponds to each row The Y value of the last pixel will be followed by the Cb value of the first pixel in the next column, and the Cr value of the last pixel in the column will not be transmitted. It is recommended that the width of the window in Y Cb Cr format is an even number of pixels. The pixel data in the packet should contain an even number of pixels. If the last pixel of the pixel data corresponds to the last pixel of a row in the window specified in the video stream packet header (that is, when the X position of the last pixel in the pixel data is equal to the right edge of X), then Equal pixel data contains odd or even pixels.

When the bit [15:13] is equal to "100", the video data is composed of a Bayer pixel array, and the number of bits of each pixel is defined by the bit 3 to 0 of the video data format descriptor character. The pixel group pattern is defined by bits 5 and 4 shown in FIG. 11E. The order of the pixel data can be horizontal or vertical, and the pixels in the column or row can be transmitted in the forward or reverse order, and are defined by bits 8 to 6. Bits 11 to 9 should be set to zero. The group of four pixels in the pixel group of the Bayer format is similar to what is called a single pixel in some display technologies. However, a pixel in the Bayer format is only one of the four colored pixels of the pixel group mosaic pattern.

For all five formats shown in the figure, bit 12 designated as "P" specifies whether to pack a sample or byte of pixel data to align the pixel data. The "0" value in this field indicates that each pixel in the pixel data field is aligned with the MDD interface byte boundary. A value of "1" indicates that each pixel in the pixel data and each color in each pixel are packed according to the previous pixels or colors in the pixels that have not left unused bits. Figure 12 shows in detail the difference between the byte alignment and the format of the packaged pixel data. In the figure, it can be clearly seen that the byte alignment can leave the unused part of the data sub-frame, which is different from that. Mutually On the contrary, the packaging pixel format is not left.

The first pixel in the first video stream packet of the media frame for the specific display window will enter the upper left corner of the data stream window defined by the X left edge and the Y top edge, and the next pixel received is placed in the same row The next pixel position of, and so on. In this first packet of the media frame, the X start value is usually equal to the left edge of X, and the Y start value is usually equal to the top edge of Y. In subsequent packets corresponding to the same screen window, the X and Y start values are usually set at the pixel positions in the screen window, which usually follow the last pixel transmitted in the video stream packet sent in the previous subframe.

<b><i>4. Audio streaming package</i></b>

The audio stream packet carries audio data that is played through the audio system of the client or used in an independent audio presentation device. Different audio data can be allocated to separate audio channels in a sound system, such as: front left, front right, center, rear left, and rear right, depending on the type of audio system used. Provides a complete complement of sound channels for headphones that include enhanced spatial-sound signal processing. A client uses the audio channel capability of the client capability packet and the audio sample rate field to indicate the ability to receive the audio stream packet. Figure 13 illustrates the format of an audio streaming packet.

As shown in Figure 13, in a specific embodiment, this type of packet is structured to have packet length, packet type, bClient ID, audio channel ID, reserved 1, audio sample count, bit per sample Yuan and packaging, audio sample rate, parameter CRC, digital audio data and audio data CRC fields. In a specific embodiment, this type of packet is generally identified as a type 32 packet.

The bClient ID field contains 2 bytes of information, which is reserved for Client ID, as used previously. The reserved 1 field contains 2 reserved bytes for future use, and is generally configured to set all bits to zero at this time.

The bit and packing field of each sample contains 1 byte in the form of an 8-bit unsigned integer, which specifies the packing format of the audio data. The format generally used is that bits 4 to 0 define the number of bits per PCM audio sample. Then bit 5 specifies whether the digital audio data sample is packaged. Figure 14 illustrates the difference between packaging and byte alignment audio samples (10-bit samples are used here). The "0" value indicates that each PCM audio sample in the digital audio data field is aligned with the MDDI interface byte boundary system byte, and the "1" value indicates that each consecutive PCM audio sample is aligned with the previous audio sample Pack it up. This bit is generally valid only when the value defined in bits 4 to 0 (the number of bits in each PCM audio sample) is a multiple of eight. Bits 7 to 6 are reserved for future use and are generally set to a value of zero.

<b><i>5. Keep data streaming package</i></b>

In a specific embodiment, packet types 1 to 15, 18 to 31, and 33 to 55 are reserved for data streaming packets that are to be defined for future versions or changes in the packet protocol, as encountered Required for various applications. Similarly, compared with other technologies, this part makes the MDD interface more flexible and more useful for constantly changing technologies and system designs.

<b><i>6. User-defined data streaming package</i></b>

The eight data stream types known as types 56 to 63 are reserved for dedicated applications, which can be defined by the equipment manufacturer for use in conjunction with the MDDI link. It is known as a user-defined data stream packet. This type of packet can be used for any purpose, but the host and client only use the results, which are very easy to understand or public. This type of packet is used in well-known situations. The specific definitions of the data stream parameters and data of these packet types are left to be determined by the specific equipment manufacturers implementing such packet types or seeking their use. Some exemplary uses of user-defined data stream packets are to convey test parameters and test results, factory calibration data, and dedicated special data. Figure 15 illustrates the format of a user-defined data stream packet used in a specific embodiment. As shown in Figure 15, this type of packet is structured to have packet length (2 bytes), packet type, bClient ID number, stream parameters, parameter CRC, stream data and stream data CRC fields.

<b><i>7. Color mapping information package</i></b>

The color mapping information package specifies the content of the color mapping lookup table used to present colors for the client. Some applications may require color mapping that is larger than the amount of data that can be sent in a single packet. In these situations, multiple color-mapped packets can be transmitted, and each packet has a different color-mapped subset by using the following offset and length fields. Figure 16 illustrates the format of a color mapping signal packet in a specific embodiment. As shown in Figure 16, this type of packet is structured to have packet length, packet type, hClient ID, color mapping item count, color mapping offset, parameter CRC, color mapping data, and data CRC fields. In a specific embodiment, this type of packet is generally recognized as a type 64 packet (video data format and color mapping packet) specified in the packet type field (2 bytes). The client uses the color mapping size and color mapping width fields of the client capability packet to indicate the ability to receive the color mapping packet.

<b><i>8. Reverse link encapsulation packet</i></b>

In an exemplary embodiment, the reverse link is used to encapsulate the packet in the reverse direction Transfer data in the direction. Transmit the forward link packet and change or turn to MDDI link operation (transmission direction) in the middle of the packet, so that the packet can be transmitted in the reverse direction. Figure 17 illustrates the format of a reverse link encapsulated packet in a specific embodiment. As shown in Figure 17, this type of packet is structured to have packet length, packet type, hClient ID, reverse link flag, reverse rate divisor, turn 1 length, turn 2 length, and parameter CRC , All Zero 1, Turn 1, Reverse Data Packet, Turn 2, All Zero 2 fields. In a specific embodiment, this type of packet is generally identified as a type 65 packet. For the external mode, each host must be able to generate this packet and receive data, and each client must be able to receive and send data to the host. The implementation of this message package is optional for the internal mode.

The MDDI link controller acts in a special way when transmitting reverse link encapsulation packets. The MDD interface has a strobe signal, which is generally always driven by the host as the link controller. For each bit of the reverse link encapsulated packet and the reverse data packet portion, the host behaves as if it is sending zeros. In the two-turn time and the time allocated for the reverse data packet, the host toggles the MDDI_Strobe signal on each bit boundary. (This system seems to be the same as sending all zero data.)

During the time period specified by the turn 1, the host disables its MDDI data signal line driver, and after the time period specified by the turn 2 field, the user terminal re-activates its line driver during the drive re-activation field after the time period specified by the turn 2 field. The client reads the steering length parameter and immediately drives the data signal to the host after steering the last bit in the 1 field. That is, the client will time the new data in the link as specified in the MDDI strobe specified in the following packet content. Some rising sides are green on the top and elsewhere. The client uses the packet length and turn-around length parameters to understand the length of time it can use to transmit the packet to the host. When the client has no data to send to the host, it can send a filler packet or drive the data line to a zero state. If the data line is driven to zero, the host interprets this as a zero-length (invalid length) packet, and the host no longer accepts packets from the client during the current reverse link encapsulation packet duration.

During the all zero 1 field, the host drives the MDDI_Data signal to the logic zero level, and during at least one reverse link clock cycle before the start of the turn 2 field, that is, during the all zero 2 field period, the MDDI The data line is driven to a logic zero level. This keeps the data line in a certain state during the turn 1 and turn 2 field time periods. If the client does not have more packets to transmit, it will even disable the data line after driving the data line to the logic zero level, because during the remaining part of the reverse data packet field, or at about 16 During the duration of or more forward link bytes, the sleep bias resistor (discussed elsewhere) maintains the data line at the logic zero level.

In a specific embodiment, the reverse link request field of the client request and status packet can be used to notify the number of bytes that the client needs to send data back to the host in the reverse link encapsulation packet Host. The host attempts to grant the request by allocating at least this number of bytes in the reverse link encapsulation packet. The host can transmit multiple reverse link encapsulation packets in the sub-frame. The client can transmit client requests and status packets at almost any time, and the host interprets the reverse link request parameters as the total number of bytes requested in a subframe.

<b><i>9. Client Capability Information Package</i></b>

The host needs to understand the capabilities of the client (display) with which it communicates in order to configure the host-to-client link in a generally optimal or desired manner. It is recommended that the display send the client capability packet to the host after obtaining the forward link synchronization. When the host uses the reverse link to encapsulate the reverse link flag request in the packet, the transmission of this packet is deemed necessary. Use the client capability information packet to notify the host of the client's capability. For external mode, each host must be able to receive this packet, and each client must be able to transmit this packet to make full use of this interface and protocol. The implementation of this message package is optional for the internal mode, because when manufacturing or assembling a certain type of single component or unit, the capabilities of the client (such as the display) should be well-defined and the host in this case Well known.

Figure 18 illustrates the format of a client capability packet in a specific embodiment. As shown in Figure 18, this type of packet is structured to have packet length, packet type, cClient ID, protocol version, minimum protocol version, data rate capability, number of alternate displays, reserved 1, bit mapping width , Bit mapping height, color mapping size, color mapping RGB width, RGB capability, monochrome capability, retention 2, Y Cr Cb capability, α-cursor image plane, retention 3, display feature capability, maximum video frame rate, minimum Video frame rate, minimum sub frame rate, audio buffer depth, audio channel capacity, audio sample rate capacity, audio sample resolution, microphone sample resolution, microphone sample rate capacity, keyboard data format, indicator device data format, content Protection type, manufacturer name, product code, reserved 4, serial number, manufacturing week, manufacturing year, and CRC fields. In an exemplary embodiment, this type of packet is generally identified as a type 66 packet.

<b><i>10. Keyboard data packet</i></b>

The keyboard data packet is used to send keyboard data from the client device to the host. The wireless (or wired) keyboard can be used in combination with various displays or audio devices, including (but not limited to) head-mounted video displays/audio presentation devices. The keyboard data packet transfers the keyboard data received from several known keyboard devices to the host. This packet can also be used to send data to the keyboard on the forward link. The client uses the keyboard data field in the client capability packet to indicate the ability to send and receive keyboard data packets.

Figure 19 shows the format of a keyboard data packet containing variable number of bytes of information from or used in the keyboard. As shown in Figure 19, this type of packet is structured to have packet length, packet type, bClient ID, keyboard data format, keyboard data and CRC fields. Here, this type of packet is generally recognized as a type 67 packet.

As mentioned above, bClient ID is a reserved field and performs CRC on all bytes of the packet. The keyboard data format field contains a 2-byte value that describes the keyboard data format. Bits 6 to 0 should be the same as the keyboard data format field in the client capability packet. This value is not equal to 127. Bits 15 to 7 are reserved for future use, and therefore are currently set to zero.

<b><i>11. Pointer device data packet</i></b>

The pointing device data packet is used to send the location information from the wireless mouse or other pointing devices from the client to the host. You can also use this packet to send data to the pointing device on the forward link. Figure 20 shows an exemplary format of a pointing device data packet, which contains variable number of bytes of information from or for the pointing device. As shown in Figure 20, this type of packet structure has Packet length, packet type, indicator device data and CRC field. In an exemplary embodiment, this type of packet is generally recognized as a type 68 packet in the 1-byte type field.

<b><i>12. Link closed packet</i></b>

The link closing packet is sent from the host to the client to indicate that the MDDI data and strobe will be closed and enter a low power consumption "sleep" state. After the static bitmap is transmitted from the mobile communication device to the display, or when there is no additional information to be transmitted from the host to the client, this packet can be used to close the link and save power. When the host transmits the packet again, normal operation resumes. The first packet sent after sleep is the sub-frame header packet. Figure 21 shows the format of the client status packet. As shown in Figure 21, this type of packet is structured to have packet length, packet type, and CRC fields. In a specific embodiment, this type of packet is generally recognized as a type 69 packet in the 1-byte type field, and uses a preselected fixed length of 3 bytes.

In the low-power sleep state, the MDDI_Data driver is disabled to the high-impedance state, and a high-impedance bias network (which can be over-driven by the user terminal) is used to pull the MDDI_Data signal to a logic zero state. In the sleep state, the strobe signal used by the interface is set to a logic zero level to minimize power consumption. Either the host or the client can make the MDDI link "wake up" from the dormant state. As explained elsewhere in this document, this is a key advancement and advantage of the present invention.

<b><i>13. Client request and status packet</i></b>

The host needs a small amount of information from the client so that the host-to-client link can be configured in the generally best way. It is recommended that each sub-frame client send a user port request and status packet to the host. The client should use this packet as The first packet in the packet is encapsulated for the reverse link for transmission, so as to ensure that it is reliably delivered to the host. When the host uses the reverse link to encapsulate the reverse link flag request in the packet, it also completes the forwarding of the packet. Use client and status packets to report errors and status to the host. Each host should be able to receive this packet, and each client should be able to transmit this packet in order to correctly or optimally adopt the MDD interface protocol.

Figure 22 shows the format of the client request and status packet. As shown in Figure 22, this type of packet is structured to have packet length, packet type, reverse link request, CRC error count, and CRC fields. This type of packet is generally recognized as a type 70 packet in the 1-byte type field, and usually uses a preselected fixed length of 12 bytes.

The reverse link request field can be used to notify the host of the number of bytes required by the client to send data back to the host in the reverse link encapsulation packet. The host should attempt to grant the request by allocating at least this number of bytes in the reverse link encapsulation packet. The host can transmit multiple reverse link encapsulation packets in the sub-frame to accommodate data. The client can transmit client request and status packets at any time, and the host interprets the reverse link request parameter as the total number of bytes requested in a subframe. The following will show additional detailed instructions and specific examples of how reverse link data is sent back to the host.

<b><i>14. Bit block transmission packet</i></b>

The bit block transmission packet provides a way to scroll the display area in any direction. Displays with this capability will report the capability in bit 0 of the display capability indicator in the client capability packet. Figure 23 shows the format of a bit block transmission packet. As shown in Figure 23, this type of packet is structured into a There are packet length, packet type, upper left X value, upper left Y value, window width, window height, window X movement, window Y movement and CRC fields. This type of packet is generally recognized as a type 71 packet, and uses a preselected fixed length of 15 bytes.

These fields are used to specify the coordinate X and Y values of the upper left corner of the window to be moved, the width and height of the window to be moved, and the number of pixels that the window needs to move in the horizontal and vertical directions, respectively. The positive values used for the last two fields move the window to the right and down, and negative values cause it to move to the left and up, respectively.

<b><i>15. Bit-mapped area filling packet</i></b>

The bit-mapped area fill packet provides a way to easily initialize the display area to a single color. Displays with this capability will report the capability in bit 1 of the display capability indicator in the client capability packet. Figure 24 shows the format of the bitmap area padding packet. As shown in Figure 24, this type of packet is structured to have packet length, packet type, upper left X value, upper left Y value, window width, window height, data format descriptor, pixel area filling value, and CRC column Bit. This type of packet is generally recognized as a type 72 packet in the 1-byte type field, and uses a preselected fixed length of 17 bytes.

<b><i>16. Bit-mapped pattern filling packet</i></b>

The bit-mapped pattern padding packet provides a way to easily initialize the display area to a pre-selected pattern. Displays with this capability will report the capability in bit 2 of the display capability indicator in the client capability packet. The upper left corner of the filling pattern is aligned with the upper left corner of the window to be filled. If the window to be filled is wider or higher than the filling pattern, the pattern can be repeated many times horizontally or vertically to fill the window. If necessary, the last repeat pattern can be cut off To the right or bottom. If the window is smaller than the filling pattern, the right or bottom of the filling pattern can be cut off to fit the window.

Figure 25 shows the format of the bit-mapped pattern padding packet. As shown in Figure 25, this type of packet is structured to have packet length, packet type, upper left X value, upper left Y value, window width, window height, pattern width, pattern height, and data format descriptor , Parameter CRC, pattern pixel data and pixel data CRC fields. This type of packet is generally recognized as a type 73 packet in the 1-byte type field.

<b><i>17. Communication link data channel packet</i></b>

The communication link data channel packet provides a method for users with high-end computing capabilities (such as PDA) to communicate with wireless transceivers (such as mobile phones or wireless data port devices). In this case, the MDDI link is used as a traditional high-speed interface between a communication device and a computing device with a mobile display, where this packet transmits data at the data link layer of the operating system of the device. For example, if a web browser, e-mail client or the entire PDA is built in a mobile display, you can use this packet. Displays with this capability will report the capability in bit 3 of the display capability indicator of the client capability packet.

Figure 26 shows the format of the communication link data channel packet. As shown in Figure 26, this type of packet is structured to have fields of packet length, packet type, parameter CRC, communication link data and communication data CRC. This type of packet is generally recognized as a type 74 packet in the type field.

<b><i>18. Interface type handover request packet</i></b>

The interface type handover request packet enables the host to request the client or display to transfer from the existing or current mode to the first type (serial), the second type (2-bit parallel), and the third type. Type (4-bit parallel) or Type 4 (8-bit parallel) mode. Before the host requests a specific mode, it should check bits 6 and 7 of the display function capability indicator field of the client capability packet to confirm that the client can operate in the desired mode. Figure 27 shows the format of the interface type handover request packet. As shown in Figure 27, this type of packet structure has packet length, packet type, interface type and CRC fields. This type of packet is generally recognized as a type 75 packet, and uses a preselected fixed length of 4 bytes.

<b><i>19. Interface type confirmation package</i></b>

The client sends the interface type confirmation packet to confirm the receipt of the interface type handover packet. The requested mode, namely Type 1 (serial), Type 2 (2-bit parallel), Type 3 (4-bit parallel) or Type 4 (8-bit parallel) mode, is used as this packet The parameters in are sent back to the host. Figure 28 shows the format of the interface type confirmation packet. As shown in Figure 28, this type of packet is structured to have packet length, packet type, interface type, and CRC fields. This type of packet is generally recognized as a type 76 packet, and uses a preselected fixed length of 4 bytes.

<b><i>20. Execution type handover packet</i></b>

The execution type handover packet is a method used by the host to command the client to handover to the mode specified by this packet. This is the same mode as the request and confirmer of the previous interface type handover request packet and interface type confirmation packet. After sending this packet, the host and client should switch to a consensus mode. The user end may lose and regain link synchronization during the mode change. Figure 29 shows the format of the execution type handover packet. As shown in Figure 29, this type of packet structure has packet length, packet type, interface type and CRC fields. This type of packet is generally recognized as type 77 in the 1-byte type field Message packet, and uses a pre-selected fixed length of 4 bytes.

<b><i>21. Forward audio channel activation packet</i></b>

This packet enables the host to activate or deactivate the audio channel in the client. This ability is very useful. It allows the user end (such as the display) to turn off the audio amplifier or similar circuit components when the host is silent, in order to save power. This is obviously more difficult to implement if it only implies the presence or absence of the audio data stream as an indicator. The default state when the client system is turned on is that all audio channels are activated. Figure 30 shows the format of the forward audio channel activation packet. As shown in Figure 30, this type of packet is structured to have packet length, packet type, audio channel activation mask and CRC fields. This type of packet is generally recognized as a type 78 packet in the 1-byte type field, and uses a preselected fixed length of 4 bytes.

<b><i>22. Reverse audio sample rate packet</i></b>

This packet enables the host to activate or deactivate the reverse link audio channel and set the audio data sample rate of this data stream. The host selects the effective sample rate defined in the client capability packet. If the host selects an invalid sample rate, the client will not send an audio stream to the host, and an appropriate error can be sent to the host in the client error report packet. The host can disable the reverse link audio stream by setting the sample rate to a value of 255. The default state assumed when the client system is first started or connected is that the reverse link audio stream is disabled. Figure 31 shows the format of the reverse audio sample rate packet. As shown in Figure 31, this type of packet is structured to have packet length, packet type, audio sample rate, and CRC fields. This type of packet is generally recognized as a type 79 packet, and uses a preselected fixed length of 4 bytes.

<b><i>23. Digital content protection management information package</i></b>

This packet allows the host and client to exchange messages related to the digital content protection method used. Currently, two types of content protection are considered, namely Digital Transmission Content Protection (DTCP) or High-bandwidth Digital Content Protection System (HDCP), and they are reserved for future alternative protection schemes. Space. The method used is specified by the content protection type parameter in this packet. Figure 32 shows the format of the digital content protection management information packet. As shown in Figure 32, this type of packet is structured to have packet length, packet type, content protection type, content protection management information, and CRC fields. This type of packet is generally recognized as a type 80 packet.

<b><i>24. Transparent color actuation packet</i></b>

The transparent color activation packet is used to specify which colors are transparent in the display and activate or deactivate the use of transparent colors for displaying images. The display with this capability will report the capability in bit 4 of the display function capability indicator field of the client capability information packet. When a pixel with a value for transparent color is written into the bitmap, the color will not change from the previous value. The format of the transparent color activation packet is shown in FIG. 33. As shown in Figure 33, this type of packet is structured to have packet length, packet type, transparent color activation, data format descriptor, transparent pixel value, and CRC field. This type of packet is generally recognized as a type 81 packet in the 1-byte type field, and uses a preselected fixed length of 10 bytes.

<b><i>25. Back and forth delay measurement packet</i></b>

The round-trip delay measurement packet is used to measure the distance from the host to the client (display) The propagation delay plus the delay from the client (display) to the host. This measurement inherently includes the delay and interconnect subsystems that exist within the line driver and receiver. This measurement is used to set the steering delay and reverse link rate divisor parameters in the reverse link encapsulated packet outlined above. This packet is most useful when the MDDI link is running at the maximum speed expected by a particular application. The MDDI_Stb signal acts like transmitting all zero data during the following fields: two guard times, all zeros and measurement period. This causes MDDI_Stb to toggle at half the data rate so that it can be used as a periodic clock in the client during the measurement period.

In a specific embodiment, the client usually uses bit 18 of the client feature capability indicator of the client capability packet to indicate the ability to support the round-trip delay measurement packet. It is recommended that all clients support round-trip delay measurement, but the host may know the worst-case round-trip delay based on the maximum cable delay and the maximum driver and receiver delay. The host can also know in advance the round-trip delay of the MDDI link used in the internal mode, because this is an aspect of the known design elements (conductor length, circuit type and characteristics, etc.) of the device using the interface.

Figure 34 illustrates the format of the round-trip delay measurement packet. As shown in FIG. 34, in a specific embodiment, this type of packet is structured to have packet length, packet type, parameter CRC, all zeros, guard time 1, measurement period, and guard time 2. This type of packet is generally recognized as a type 82 packet, and uses a preselected fixed length of 533 bits.

Figure 35 illustrates the timing of events that occur during the round-trip delay measurement packet. In Figure 35, the host sends a round-trip delay measurement packet, as shown in the parameter CRC and strobe alignment fields followed by all zeros and guard time 1 fields. The delay 3502 occurs before the packet reaches the display device or processing circuit on the user side. Client receiving When sending a packet, the user end sends 0xff, 0xff, and 30-byte 0x0 patterns as accurately as possible at the beginning of the measurement period determined by it. From the perspective of the host, the actual time at which the client starts to send this sequence is delayed from the beginning of the measurement period. This amount of delay is essentially the time it takes for the signal packet to propagate through the line driver and receiver and interconnection subsystems (cables, conductors). Propagation of the pattern from the client back to the host causes the same amount of delay 3504.

In order to accurately determine the round-trip delay time of the signal passing through the user terminal, the host counts the number of forward link bit time periods that occur after the measurement period begins, until the start of the 0xff, 0xff, 30-byte 0x0 sequence is detected when it arrives So far. This information is used to determine the amount of time for the round-trip signal to pass from the host to the client and back again. Therefore, about half of this delay is due to the delay established by a path of the signal arriving at the user end.

During the two guard periods, both the host and the client drive the line to a logic zero level to keep the MDDI_DATA line in a defined state. The dormant pull-up and pull-down resistors (see Figure 42) ensure that the MDDI_Data signal remains at a valid low level during the interval when the line driver is disabled on both the host and the user side.

<b><i>26. Forward link skew calibration packet</i></b>

The forward link skew calibration packet allows the user terminal or the display itself to calibrate the difference in the propagation delay of the MDDI_Data signal with respect to the MDDI_Stb signal. Without delayed skew compensation, the maximum data rate is generally limited to solving the worst possible case of such delays. Generally speaking, this packet is only sent when the forward link data rate is configured to be about 50 Mbps or lower. After sending this packet to calibrate the display, the data rate can be gradually increased to more than 50 Mbps. If the data rate is set too high in the skew calibration procedure High, the display may be synchronized with the replacement command of the bit cycle, which can turn off the delayed skew compensation setting in multiple bit times, resulting in incorrect data clocks. The interface of the highest data rate type or the largest possible interface type is selected before sending the forward link skew calibration packet to calibrate all existing data bits.

Figure 56 shows the format of the forward link skew calibration packet. As shown in Figure 56, this type of packet is structured to have packet length (2 bytes), packet type, parameter CRC, calibration data sequence and CRC field. This type of packet is generally recognized as a type 83 packet in the type field, and uses 515 to preselect a fixed length.

<b>Virtual control panel</b>

The use of virtual control panel (VCP) enables the host to set specific user controls on the client side. By enabling the host to adjust these parameters, the user interface in the client can be simplified, because the host software can be used to generate the volume or display brightness by the host software instead of one or more microprocessors in the client. Screen with parameters such as. The host can read the parameter settings in the client and determine the effective value range of each control. The client can report to the host which control parameters can be adjusted.

Use the control code (VCP code) and generally designated related data values to specify the control and settings in the client. Expand the VCP code in the MDDI specification to 16 bits to preserve the correct data field alignment in the packet definition, and support the only supplementary value or future enhancements of this interface in the future.

<b><i>27. Request VCP feature packet</i></b>

Request the VCP feature packet to provide a component, mechanism or method for the host to request Seek the current setting of a specific control parameter or all effective control parameters. Generally speaking, the client responds to the VCP packet with appropriate information in the VCP feature reply packet. In a specific embodiment, the client uses bit 20 of the client feature capability indicator field of the client capability packet to indicate the ability to support the request for the VCP feature packet.

Figure 69 shows the format of a request for a VCP feature packet in a specific embodiment. As shown in Figure 69, this type of packet is structured to have packet length, packet type, hClient ID, MCCS VCP code and CRC fields. In a specific embodiment, this type of packet is generally identified as type 128, which is indicated in the 2-byte type field. The packet length specifies the total number of bytes in the packet except for the packet length field. For this type of packet, the packet length is usually fixed at 8 bytes.

The hClient ID field contains a 16-bit unsigned integer, which is reserved for the client ID. This field is reserved for future use and is usually set to zero. The MCCS VCP code field contains 2-byte information specifying the MCCS VCP control code parameter. A value ranging from 0 to 255 makes the VCP feature response packet and a single item corresponding to the specified MCCS code in the VCP feature response list returned together. The MCCS VCP code of 65535 (0xffff) requests a VCP feature response packet with the VCP feature response list. The VCP feature response list includes a feature response list item for each control supported by the client. The values 256 to 65534 in this field are reserved for future use and are not currently used.

<b><i>28. VCP feature reply packet</i></b>

The VCP feature response packet provides a component, mechanism, or method for the client to request the host with specific control parameters or the current settings of all effective control parameters. Ask for a response. Generally speaking, the client sends a VCP feature response packet in response to a request for a VCP feature packet. This packet helps to determine the current setting of a specific parameter, determine the effective range of a specific control, determine whether the client supports a specific control, or determine the control set supported by the client. If the sent request VCP feature relates to a specific control that is not implemented in the client, the VCP feature response packet is returned with a single VCP feature response list item, and the VCP feature response list item corresponds to the unimplemented containing the appropriate error code control. In a specific embodiment, the client uses bit 20 of the display feature capability indicator field of the client capability packet to indicate the capability of supporting the VCP feature response packet.

Figure 70 shows the format of a VCP feature response packet in a specific embodiment. As shown in Figure 70, this type of packet is structured to have packet length, packet type, cClient ID, MCCS version, reply sequence number, VCP feature reply list, and CRC fields. In a specific embodiment, this type of packet is generally identified as type 129, as indicated in the 2-byte type field.

The cClient ID field contains information reserved for Client ID. This field is reserved for future use and is usually set to zero. The MCCS version field contains 2-byte information of the VESA MCCS specification version implemented by the specified client.

The 2-byte reply serial number field contains information or data of the serial number of the VCP feature reply packet returned by the designated client. In response to the request VCP feature packet with the MCCS control code value 65535, the client returns one or more VCP feature response packets. The client can reply to messages in multiple VCP features Expand the feature response list on the package. In this case, the client assigns a sequence number to each consecutive packet, and the sequence number of the VCP feature reply packet sent in response to a single request VCP feature packet starts at zero and increments by one. The last VCP feature list item in the last VCP feature response packet should contain the MCCS VCP control code value equal to 0xffff to identify that the packet is the last packet and contains the highest sequence number of the group of the returned packet. If only one VCP feature reply packet is sent in response to the request for the VCP feature packet, the reply sequence number in the single packet is zero, and the VCP feature reply list includes a record with an MCCS VCP control code equal to 0xffff.

The number of features in the list field contains 2 bytes, which specify the number of VCP feature list items in the VCP feature response list in this packet, and the VCP feature response list field contains one or more The byte group of a VCP feature reply list item. Figure 71 shows the format of a single VCP feature response list item in a specific embodiment.

As shown in Figure 71, the length of each VCP feature response list item is exactly 12 bytes, and contains the MCCS VCP code, result code, maximum value, and current value fields. The 2-byte MCCS VCP code field contains data or information specifying the MCCS VCP control code parameters related to this list item. Only the control code values defined in the VESA MCCS specification version 2 and later are considered valid. The 2-byte result code field contains information specifying an error code that is related to the specified MCCS VCP control related information request. A value of "0" in this field means no error, and a value of "1" means that the specified control is not implemented on the client side. The other values in this field from 2 to 65535 are currently reserved for future use and used in other applications covered by this technology The implementation plan, but not now.

The 4-byte maximum value field contains a 32-bit unsigned integer that specifies the maximum possible value that can be set by the designated MCCS control. If the requested control system is not implemented in the client, this value can be set to zero. If the length of the returned value is less than 32 bits (4 bytes), then the value is made up into a 32-bit integer and the most significant (unused) byte is set to zero. The 4-byte current value field contains information specifying the current value of the specified MCCS VCP continuous (C) or non-continuous (NC) control. If the requested control is not implemented in the client, or if the control is implemented but the control is a table (T) data type, then this value is set to zero. According to the VESA MCCS specification, if the length of the returned value is less than 32 bits (4 bytes), the value is made up into a 32-bit integer and the most significant (unused) byte is set to zero.

<b><i>29. Set VCP feature packet</i></b>

The setting VCP characteristic information package provides a component, mechanism or method for the host to set the VCP control value of continuous and discontinuous control in the client. In a specific embodiment, the client uses bit 20 of the display feature capability indicator field of the client capability packet to indicate the ability to support the setting of the VCP feature packet.

Fig. 72 shows the format of setting the VCP feature packet in a specific embodiment. As shown in Figure 72, this type of packet is structured to have packet length, packet type, hClient ID, MCCS VCP code, number of values in the list, control value list, and CRC fields. Generally, this type of packet is identified as type 130. As indicated in the 2-byte type field, its length is 20 bytes except for the packet length field.

The hClient ID field uses a 2-byte value again to specify or use as a Client ID. This field is reserved for future use and is currently set to zero. The MCCS VCP code field uses 2-byte information or value to specify the MCCS VCP control code parameter to be adjusted. The 2-byte value in the list field contains the information or value of the 16-bit value in the specified control value list. The control value list will usually contain one item unless the MCCS control code is related to the table in the user terminal. In the case that the control is not related to the table, the control value list will contain a value that specifies the new value that will be written to the control parameter specified by the MCCS VCP code field. For the control related to the table, the data format in the control value list is specified by the parameter description of the specified MCCS VCP code. If the list contains a value greater than one byte, the least significant byte is sent first, which is consistent with the method defined elsewhere. Finally, the 2-byte CRC field contains a 16-bit CRC of all the bytes in the packet (including the packet length).

<b><i>30. Request a valid parameter packet</i></b>

The request valid parameter packet is used as a component or mechanism to request the client to return a valid parameter response packet, which contains a list of parameters supported by the specified non-continuous (NC) or table (T) control. This packet should only specify non-continuous control or control related to a table in the client, and not specify an MCCS VCP code value of 65535 (0xffff) to specify all controls. If a non-supported or invalid MCCS VCP code is specified, an appropriate error value will be returned in the valid parameter response packet. In a specific embodiment, the client uses bit 20 of the display feature capability indicator field of the display capability packet to indicate the ability to support the request for valid parameter packet.

Fig. 73 shows the format of a request valid parameter packet in a specific embodiment. As shown in Figure 73, this type of packet is structured to have a packet length, Packet type, hClient ID, MCCS VCP code and CRC fields. In a specific embodiment, this type of packet is generally identified as type 131, as indicated in the 2-byte type field.

The packet length, as indicated in the 2-byte packet length field, is generally set to have the total number of bytes in the packet, excluding the 8 packet length field. hClient ID specifies the client ID again, but it is currently reserved for future use, as understood by those skilled in the art, and is set to zero. The 2-byte MCCS VCP code column contains a value that specifies the non-continuous MCCS VCP control code parameter to be queried. The value in this field should correspond to the discontinuous control implemented by the client. Values of 256 to 65535 (0xffff) are usually reserved or considered invalid, and are considered as unimplemented controls in the error response.

<b><i>31. Valid parameter response packet</i></b>

In response to a request for a valid parameter packet, a valid parameter reply packet is sent. It is used as a component, method, or mechanism to identify the effective setting of non-continuous MCCS VCP control or control of return table content. If the control is related to the table in the client, the VCP parameter response list only contains a specific list of the requested order table values. If the table content is not suitable for a single valid parameter reply packet, the client can send multiple packets with sequential reply sequence numbers. In a specific embodiment, the client uses bit 20 of the display feature capability indicator field of the display capability packet to indicate the ability to support the effective parameter response packet.

The host can request the contents of the table in the following ways: the host sends a set VCP feature packet containing necessary or required parameters (such as read/write parameters, LUT offset and RGB selection); then the host sends a request to specify the required control Valid parameter packet; then the client returns one or more valid data containing table data Parameter reply packet. This operation sequence performs a function similar to the table reading function described in the MCCS operation model.

If the client does not support a specific client parameter, in a specific embodiment, the corresponding field of the packet will contain a value of 255. For the parameters used by the client, the corresponding field should contain the parameter value of the client.

Figure 74 shows the format of a valid parameter response packet in a specific embodiment. As shown in Figure 74, this type of packet is structured to have packet length, packet type, cClient ID, MCCS VCP code, response code, response sequence number, number of values in the list, VCP parameter response list and CRC Field. In a specific embodiment, this type of packet is generally identified as type 132, as indicated in the 2-byte type field.

The cClient ID field is reserved for future use, which can be understood from the above discussion, and the 3-byte MCCS VCP code packet contains the value of the continuous MCCS VCP control code parameter described in the specified packet. If the invalid MCCS VCP control code is specified by the request valid parameter packet, the same invalid parameter value will be specified in this field using the appropriate value in the response code field. If the MCCS control code is invalid, the VCP parameter response list will have a length of zero.

The response code field contains 2 bytes of information or value to specify the nature of the response, which is related to the related information request controlled by the specified MCCS VCP. If the value in this field is equal to 0, it is considered that there is no error in this data type, and the last valid parameter response packet in the sequence is sent, which has the highest response sequence number. If the value in this field is equal to 1, it is considered that there is no error, and other valid parameter response packets with higher serial numbers are sent. If the value in this field is equal to 2, the specified control is considered not to be implemented in the client. If the value in this field is equal to 3, the specified control is not a discontinuous control (it is a continuous control, and always has a set of valid values from zero to its maximum value). Values equal to 4 to 65535 in this field are reserved for future use and are generally not used.

The 2-byte response sequence number field specifies the sequence number of the valid parameter response packet returned by the client. In response to the request for a valid parameter packet, the client returns one or more valid parameter response packets. The client can expand the VCP parameter reply list on multiple valid parameter reply packets. In the latter case, the client assigns a sequence number to each successive packet, and sets the response code to 1 in packets other than the last packet in the sequence. The last valid parameter response packet in the sequence will have the highest response sequence number, and the response code will contain a value of 0.

The number of 2-byte values in the list field specifies the number of 16-bit values that exist in the VCP parameter response list. If the response code is not equal to zero, the number of values in the list parameter is zero. The VCP parameter response list field contains a row of 2-byte values from 0 to 32760, which indicates the effective value group of the non-continuous control specified by the MCCS control code field. The definition of the discontinuous control code is specified in the VESA MCCS specification. Finally, in this specific embodiment, the CRC field contains a 16-bit CRC of all the bytes in the packet (including the packet length).

<b>Alpha-Cursor image</b>

The MDD interface and related invention protocols and mechanisms for communicating data through communication links provide support for multiple image planes that overlap each other and have different transparency. Overlay images with variable XY offset can be used to implement hardware cursors. The following provides α-cursor functionality and related agreements An overview of fixed support. The ability to support the α-cursor image packet is defined in the α-cursor image ability packet, which is sent in response to a request for a specific status packet.

<b><i>32. α-Cursor Image Capability Information Package</i></b>

The α-cursor image capability packet is used to define the characteristics of the α-cursor image and related transparency mapping in the client. In a specific embodiment, the client uses the parameter value 133 in the valid parameter response list in the valid status response list packet to indicate the ability to support the α-cursor image capability packet. In a specific embodiment, the packet length specified in the packet length field is set to a fixed value of 20, excluding the packet length field.

Fig. 75 shows the format of an α-cursor image capability packet in a specific embodiment. As shown in Figure 75, this type of packet is structured to have packet length, packet type, cClient ID, α-cursor identifier, α-cursor bit mapping width, α-cursor bit mapping height, RGB Capability, monochrome capability, retention 1, Y Cr Cb capability, transparency mapping resolution, capability bit and CRC field. The cClient ID field is usually reserved for future Client ID use, and is currently set to zero.

The alpha-cursor identifier field (2 bytes) contains a value for identifying a specific alpha-cursor plane. If the client supports n α-cursor image planes, the α-cursor identifier has an effective range of 0 to n-1. In a specific embodiment, the value n is specified by the α-cursor image plane field of the display capability packet. The client returns a unique α-cursor image capability packet for each α-cursor image plane.

2-byte α-cursor bit mapping width field value specifies the α-cursor bit The width of the mapped image is expressed in the number of pixels, and the 2-byte α-cursor bit mapping height field specifies the height of the α-cursor bit mapping image, expressed in the number of pixels.

The RGB capability field uses 2 bytes to specify the number of bits of the displayable resolution in the RGB format. If the client cannot use the RGB format, this value is zero. The RGB capability character is composed of three separate values. In a specific embodiment, these values are implemented as: bits 3 to 0 define the maximum number of blue bits (blue intensity) in each pixel; Elements 7 to 4 define the maximum number of green bits (green intensity) in each pixel; bits 11 to 8 define the maximum number of red bits (red intensity) in each pixel; and bits 15 to 12 are reserved for future It is used to display RGB capability information, so it is usually set to zero now.

The 1-byte monochrome capability field is used to specify the number of bits of the resolution that can be displayed in the monochrome format. If the client cannot use the monochrome format, set this value to zero. Bits 7 to 4 are reserved for future use, so they are generally set to zero. Bits 3 to 0 define the maximum number of grayscale bits that may exist in each pixel. These four bits make it possible to specify that each pixel consists of 1 to 15 bits. If the value is zero, the client does not support the monochrome format.

1 byte reserved 1 field contains a value that is generally reserved for future use, so all bits in this field are set to zero. This aligns the subsequent 2-byte field with a 16-bit character address, and aligns the 4-byte field with a 32-bit character address.

The 2-byte Y Cb Cr capability field contains a value or information that specifies the number of bits of the resolution that can be displayed in the Y Cb Cr format. If the user terminal cannot use the Y Cr Cb format, this value is zero. Generally speaking, in a specific embodiment, The Y Cb Cr capability character is composed of three separate values, among which bits 3 to 0 define the maximum number of bits for the specified Cr sample; bits 7 to 4 define the maximum number of bits for the specified Cb sample; bit 11 Up to 8 defines the maximum number of bits for the designated Y sample; and bits 15 to 12 are reserved for future use in presenting Y Cb Cr capability information or values, but are currently set to zero.

The 1-byte transparency mapping resolution field contains a value or information specifying the number of bits (depth) in each pixel position of the alpha-cursor image transparency mapping. The value can range from 1 to 8. If the value is zero, the alpha-cursor image buffer (the buffer specified by the alpha-cursor identifier field) does not support transparency mapping.

The 1-byte capability bit field provides a value or information including a set of flags that specify the capability related to the α-cursor image buffer. In a specific embodiment, the flag is defined as: bit 0 is used to select the pixel data in the alpha-cursor video stream packet as the packaging format. Bit 1 is used to display the packaging format of the transparency mapping data in the alpha-cursor transparency packet. Figure 76 shows the byte alignment and packaging transparency mapping data. Bit 2 is used to display the α-cursor image plane. The α-cursor image offset packet is used to support the image offset capability. Bit 3 is used to display the α-cursor image plane and can support the color mapping data format. The α-cursor image plane uses the same color mapping table as the main image buffer and zoomed video stream. Use the color mapping information package described elsewhere to configure the color mapping.

Bits 7 to 4 are reserved for future use, so they are generally set to zero or logic levels.

<b><i>33. α-Cursor Transparency Mapping Packet</i></b>

The α-cursor transparency mapping packet defines the content of the image transparency mapping of the specified α-cursor image plane. Some applications require transparency mapping greater than The amount of data that can be sent in a single packet. In these situations, multiple alpha-cursor transparency mapping packets can be sent. By using the following transparency mapping X and Y start fields, each alpha-cursor transparency mapping packet has a different transparency mapping subset. These fields can be operated similarly to the X start and Y start fields of the video stream packet. In a specific embodiment, the client uses the transparency mapping resolution field of each specific α-cursor plane specified by the α-cursor identifier field of the α-cursor image capability packet. To indicate the ability to support alpha-cursor transparency mapping packets. The packet length and Client ID fields of the other packets mentioned above operate as before. In a specific embodiment, the value 134 in the packet type field is used to identify the packet as an alpha-cursor transparency mapping packet.

Fig. 76 shows the format of the alpha-cursor transparency mapping packet in a specific embodiment. As shown in Figure 76, this type is structured to have packet length, packet type, hClient ID, α-cursor identifier, transparency mapping X start, transparency mapping Y start, transparency mapping resolution, retention 1, parameters CRC, transparency mapping media and transparency mapping data CRC field.

The 2-byte alpha-cursor identifier field has a value for identifying a specific alpha-cursor plane. If the client supports n α-cursor image planes, the α-cursor identifier has an effective range of 0 to n-1.

The 2-byte transparency map X and Y start fields each specify absolute X and Y coordinates, and the point (transparency map X start, transparency map Y start) is the first pixel in the following transparency map data field.

The transparency mapping resolution field (1 byte) contains a value that specifies the resolution of the transparency mapping and whether to package data. A specific implementation in this field In the example, bits 3 to 0 define the number of resolution bits present in all transparency map entries. The valid value specifies the width from 1 to 8 bits. The values 0 and 9 to 15 are considered invalid. This value should match the value returned by the client in the Transparency Mapping Resolution field of the α-Cursor Image Capability Packet. Bits 6 to 4 are reserved for future use, so they should generally be set to logic zero at this time. Bit 7 of this byte specifies whether the transparency mapping data is in the form of packaging or byte alignment. If bit 7 is equal to "1", the transparency mapping data is in the form of packaging, and if it is equal to "0", the data is byte aligned. Examples of packaging and byte alignment transparency mapping data are shown elsewhere. The value of this bit must match the value of bit 1 in the capability bit field of the α-cursor image capability packet.

1 byte is reserved and 1 field is reserved for future use. Therefore, all bits in this field are generally set to be equal to the logic zero level. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit character address, and align the 4-byte field with a 32-bit character address.

The parameter CRC field contains a 16-bit CRC of all the bytes from the packet length to the reserved 1 field. If the CRC check is incorrect, the entire packet is discarded.

For the transparency mapping data field, the width of each transparency mapping position is 1 to 8 bits. If a single transparency mapping is not suitable for an alpha and cursor transparency mapping packet, the entire transparency mapping is specified by transmitting multiple packets and making each packet have different transparency mapping data and transparency mapping X and Y starting values.

The 2-byte transparency mapping data CRC field contains a 16-bit CRC value of only the transparency mapping data. If the CRC check is incorrect, it can still be used Transparency maps the data, but the CRC error count should be incremented.

<b><i>34. α-Cursor image offset packet</i></b>

α-Cursor image offset packet specifies the X and Y offset of the cursor relative to the upper left corner of the main display image. Figure 77 shows the format of the α-Cursor image offset packet. As shown in FIG. 77, in a specific embodiment, the α-cursor image offset packet is structured to have packet length, packet type, hClient ID, α-cursor X offset, and α-cursor Y offset. And CRC field. In a specific embodiment, the client uses the capability bit field of the α-cursor image capability packet of each specific α-cursor plane specified by the α-cursor identifier field of the α-cursor image capability packet The bit 2 indicates the ability to support the α-cursor image offset packet. In a specific embodiment, the packet length is fixed to 10, as shown in the 2-byte packet length field. In a specific embodiment, the packet type 135 identifies the packet as an α-cursor image offset packet.

The values contained in the 2-byte α-cursor X and Y offset fields can specify the horizontal and vertical offsets of the leftmost row and top row of pixels of the cursor image relative to the left and top of the main image, respectively. The 2-byte hClient ID reserved for Client ID contains a 16-bit unsigned integer. This field is reserved for future use and can be set to zero.

<b><i>35. α-Cursor video streaming package</i></b>

The α-cursor video stream packet carries video data to update the rectangular area of the α-cursor image plane. The size of this area can be as small as a single pixel or as large as the entire display. FIG. 78 illustrates the format of the α-cursor video streaming packet. As shown in FIG. 78, in a specific embodiment, the α-cursor video streaming packet is structured to have packet length, packet type, bClient ID, and video Data format attributes, X left edge, Y top edge, X right edge, Y bottom edge, X start, Y start, pixel count, parameter CRC, pixel data and pixel data CRC fields. In a specific embodiment, the client uses the α-cursor image capability packet of each specific α-cursor plane specified by the α-cursor identifier field of the α-cursor image capability packet to indicate that the α-cursor image capability packet is supported. The capability of cursor video streaming packets and related parameters, and the value 17 in the packet type field indicates or identifies a packet as an alpha-cursor video streaming packet. The hClient ID field (2 bytes) is reserved for future use as a Client ID, and is generally set to zero at the same time, as is well known in this technology.

The 2-byte video data format descriptor field contains information or values that specify the format of each pixel in the pixel data of the current stream in the current packet. The pixel data format must conform to at least one of the valid formats of the α-cursor image plane defined in the α-cursor image capability packet. The video data format descriptor field only contains the pixel format that defines the current packet, which does not mean that a constant format will continue to be used for the lifetime of a particular video stream. Figure 11 above illustrates how to encode the video data format descriptor. The format is as follows:

In a specific embodiment, when the bit [15:13] is equal to "000", the video data is composed of a monochrome pixel array, and the bit number of each pixel is determined by the bit number of the video data format descriptor character. Yuan 3 to 0 to define. Then set bits 11 to 4 to zero. When the bit [15:13] is "001", the video data is composed of an array of color pixels, and each color pixel is assigned a color through color mapping (palette). Bits 5 to 0 of the character definition of the video data format descriptor define the number of bits of each pixel, and bits 11 to 6 are set to zero. When the bit [15:13] is "010", the video data is converted from an original RGB format The color pixel array of each red pixel is defined by bits 11 to 8, the bit number of each green pixel is defined by bits 7 to 4, and the bit number of each blue pixel is defined by Bits 3 to 0 are defined. The total number of bits in each pixel is the sum of the number of bits used for red, green, and blue.

When [15:13] is "011", the video data is composed of 4:2:2 Y Cb Cr format video data format with luminance and chrominance information. Use bits 11 to 8 to define the number of bits per pixel of brightness (Y), use bits 7 to 4 to define the number of bits of the Cb component, and use bits 3 to 0 to define the number of bits of the Cr component Number of bits. The transfer rate of the Cb and Cr components is half of Y. The video samples in the pixel data part of this packet will be organized as follows: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3,..., where Cbn and Cm are It is related to Yn and Yn+1, and Cbn+2 and Crn+2 are related to Yn+2 and Yn+3, and so on. Yn, Yn+1, Yn+2, and Yn+3 are the brightness values of four consecutive pixels from left to right in a single column. The order of these color components is the same as the Microsoft UYVY FOURCC format. If there are an odd number of pixels in one of the rows (X right edge-X left edge + 1) of the window involved in the video stream packet, the Cb value corresponding to the last pixel in each row will be followed by the first pixel in the next row Y value.

It is recommended that the width of the window in Y Cb Cr format is an even number of pixels. The pixel data in a packet should contain an even number of pixels. If the last pixel of the pixel data corresponds to the last pixel of a row in the window specified in the video stream packet header (that is, when the X position of the last pixel in the pixel data is equal to the right edge of X), then Equal pixel data contains odd or even pixels.

For all five formats, bit 12 (designated as "P" in the figure) specifies whether Sample package pixel data. When the value of bit 12 is "0", each pixel in the pixel data field and each color in each pixel are aligned with the boundary byte of the MDDI interface byte. When the value of bit 12 is "1", each pixel in the pixel data and each color in each pixel are packed with the previous pixel or color in the pixel, leaving no unused bits.

In a specific embodiment, the pixel data attribute field (2 bytes) has a series of bit values, which is explained as follows. Bits 1 and 0 select how to send display pixel data. For the bit value "11", the data is displayed to both eyes, for the bit value "10", the data is only sent to the left eye, and for the bit value "01", the data is only sent to the right eye.

Bit 2 indicates whether to present the pixel data in an interlaced format, where the value "0" indicates that the pixel data is in the standard progressive format, and when it advances from one row to the next, the row number (pixel Y coordinate) is incremented by 1. If this bit has the value "1", the pixel data is in the interlaced format, and when advancing from one row to the next, the row number is incremented by 2. Bit 3 indicates that the pixel data is in alternate pixel format. This is similar to the standard interlace mode activated by bit 2, but the interlace is vertical rather than horizontal. When bit 3 is "0", the pixel data is in the standard progressive format, and the row number (pixel X coordinate) is incremented by 1 when each continuous pixel is received. When bit 3 is "1", the pixel data is in alternate pixel format, and the row number is incremented by 2 when each pixel is received.

Bit 4 indicates whether the pixel data is related to a display or a camera, because the data is transmitted to or from the internal display of a wireless phone or similar device or even a portable computer or other such devices mentioned above, or the data is transmitted from the internal display. Transfer data to or from a camera built into the device or directly coupled to the device. When bit 4 is "0", the Pixel data is transferred to or from the display frame buffer. When bit 4 is "1", the pixel data is transmitted to or from a camera or a certain type of video device, and such devices are widely known in the art.

Bit 5 is reserved for future use or MDD interface applications, so it is generally set to zero or "0".

Bits 7 and 6 are display update bits, which specify the frame buffer that needs to write pixel data. Discuss more specific effects elsewhere. For the bit value "01", the pixel data is written into the offline image buffer. For the bit value "00", the pixel data is written into the image buffer used to refresh the display. For the bit value "11", the pixel data is written into all image buffers. The bit value or combination "10" is regarded as an invalid value or specified, and the pixel data is ignored and not written to any image buffer. This value can be used in future interface applications.

Bits 8 to 15 are reserved for future use, so they are generally set to zero.

In a specific embodiment, the 2-byte X start and Y start fields specify the absolute X and Y coordinates of the first pixel point (X start, Y start) in the pixel data field. The 2-byte X left edge and Y top edge fields specify the alpha-cursor image window's left edge X coordinate and the top edge Y coordinate filled by the pixel data field, and the X right edge and Y bottom edge fields specify The X coordinate of the right edge, and the Y coordinate of the bottom edge of the α-cursor image window is updated.

The pixel count field (2 bytes) specifies the number of pixels in the following pixel data field.

The 2-byte parameter CRC field contains a CRC of all the bytes from the packet length to the pixel count. If the CRC check is incorrect, the entire message is discarded Bag.

The pixel data field includes the original video information to be displayed, and it is formatted in the manner described in the video data format descriptor field. As described elsewhere, the data is sent one "row" at a time.

The pixel data CRC field (2 bytes) only includes the 16-bit CRC of the pixel data. If the CRC verification of this value fails, the pixel data can still be used, but the CRC error count will increase.

<b>Zoom video stream image</b>

The MDD interface or protocol mechanism or method provides support for zooming the video stream image, so that the host can send an image that is enlarged or reduced relative to the original image to the client, and copy the zoomed image to a main image buffer. Provides an overview of zoom video streaming functionality and related protocol support elsewhere. A zoomed video stream capability packet sent in response to a request for a specific status packet, or the capability of supporting zoomed video streams is defined in the zoomed video stream capability packet.

<b><i>36. Zoom video streaming capability package</i></b>

The zoom video stream capability package defines the characteristics of the zoomed video stream source image in or used by the client. Figure 79 generally shows the format of the zoom video streaming capability packet. As shown in Figure 79, in a specific embodiment, the zoom video streaming capability packet is structured to have packet length, packet type, cClient ID, maximum number of streams, source maximum X size, and source maximum Y size. , RGB capability, monochrome capability, reserved 1, Y Cr Cb capability, reserved 2 and CRC fields. In a specific embodiment, the packet length is selected as a fixed 20-byte group, as shown in the length field, including the 2-byte cClient ID field (it is reserved for Client ID, and is set to zero when not in use. ) And CRC fields. In a specific In the embodiment, the client uses the parameter value 143 in the valid parameter response list of the valid status response list packet to indicate the ability to support the scaling video stream capability packet.

The 2-byte maximum number of streams field contains a value for identifying the maximum number of simultaneous zoom video streams that can be allocated at one time. In a specific embodiment, if the maximum number of zoomed video streams has been allocated, the client should reject the request for allocating zoomed video streams. If less than the maximum number of zoomed video streams are allocated, the client can also reject an allocation request based on other resource restrictions in the client.

The source maximum X size and Y size fields (2 bytes) respectively specify the maximum width and height of the source image of the zoomed video stream, expressed in the number of pixels.

The RGB capability field uses a value to specify the number of bits of resolution that can be displayed in the RGB format. If the zoomed video stream cannot use the RGB format, set this value equal to zero. The RGB capability character is composed of three separate unsigned values, where bits 3 to 0 define the maximum number of blue bits (blue intensity) in each pixel; bits 7 to 4 define the maximum green value in each pixel Number of bits (green intensity); bits 11 to 8 define the maximum number of red bits (red intensity) in each pixel; and bits 15 to 12 are reserved for future use in future capability definitions, generally set to zero .

The 1-byte monochrome capability field contains a value that specifies the number of bits of resolution that can be displayed in the monochrome format. If the zoomed video stream cannot use the monochrome format, set this value to zero. Bits 7 to 4 are reserved for future use, so for current applications, it should be set to zero ("0"), but this can change over time, as those skilled in the art understand. Bits 3 to 0 define each pixel The maximum number of possible grayscale bits. These four bits make it possible to specify that each pixel consists of 1 to 15 bits. If the value is zero, the zoomed video stream does not support the monochrome format.

The reserved 1 field (here 1 byte) is reserved for future use to provide values related to zoomed video stream packet information or data. Therefore, all bits in this field should be set to logic "0" at present. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit character address, and align the 4-byte field with a 32-bit character address.

The 2-byte Y Cb Cr Capability field contains a value that specifies the number of bits of the displayable resolution in the Y Cb Cr format. If the zoomed video stream cannot use the Y Cb Cr format, this value is zero. The Y Cb Cr capability character is composed of three separate unsigned values, where bits 3 to 0 define the maximum number of bits for the specified Cr sample; bits 7 to 4 define the maximum number of bits for the specified Cb sample; bits Elements 11 to 8 define the maximum number of bits for the designated Y sample; bits 15 to 12 are reserved for future use and are generally set to zero.

The 1-byte capability bit field contains a set of flags that specify the capability related to zooming the video stream. The flag system is defined as follows: Bit 0 means that the pixel data in the zoomed video stream packet can be in the packet format. An example of packaging and byte alignment pixel data is shown in Figure 12 above. Bit 1 is reserved for future use and should be set to zero; bit 2 is reserved for future use and should be set to zero; bit 3 covers the zoomed video stream that can be specified in the color-mapped data format. The zoomed video stream uses the same color map as the main image buffer and the α-cursor image plane. Use the color mapping information package described elsewhere to configure the color mapping; and bits 7 to 4 are reserved for future use, and are generally set Is zero.

The reserved 2 fields (here 1 byte) are reserved for future use to provide values related to the zoomed video stream packet information or data. Therefore, all bits in this field should be set to logic "0" at present. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit character address, and align the 4-byte field with a 32-bit character address.

<b><i>37. Zoom video stream setting package</i></b>

The zoom video stream setting packet is used to define the parameters of the zoom video stream, and the client uses the information to allocate internal storage for image buffering and zooming. A video stream can be deallocated by sending this packet so that the X image size and Y image size fields are equal to zero. The unallocated zoomed video stream can be redistributed later by using the same or different video stream parameters. In a specific embodiment, a client uses a parameter value of 143 in the valid parameter reply list of the valid state reply list packet and uses one of the maximum number of streams field of the zoom video stream capability packet A non-zero value indicates the ability to support the zoomed video stream configuration packet.

Figure 80 generally shows the format of the zoomed video stream setting packet. As shown in FIG. 80, in a specific embodiment, the zoomed video stream setting packet is structured to have packet length, packet type, hClient, stream ID, visual data format descriptor, pixel data attribute, X left Edge, Y top edge, X right edge, Y bottom edge, X image size, Y image size, and CRC fields.

The 2-byte packet length field specifies the total number of bytes in the packet that does not include the packet length field. In a specific embodiment, the length of this packet is fixed to 24. The 2-byte packet type field uses a value of 136 packet Identified as a zoom video stream setting package. The 2-byte hClient ID field is reserved for future use as a Client ID, and is usually set to an all-zero value at present, or until a protocol user decides which ID value to use, this is well known.

The Stream ID field uses 2 bytes to specify the unique identifier of the stream ID. This value is specified by the host and should be from zero to the maximum flow ID value specified in the display capability packet. The host must carefully use the flow ID value to ensure that a unique value is assigned to each active stream, and unassign or reassign a stream that is no longer active.

In a specific embodiment, the video data format descriptor field uses 2 bytes to specify the format information or value of each pixel in the pixel data of the current stream in the current packet. The pixel data format should conform to at least one of the valid formats of the α-cursor image plane defined in the α-cursor image capability packet. The video data format descriptor only defines the pixel format of the current packet and does not mean that a constant format will continue to be used for the lifetime of a particular video stream. Figure 11 illustrates a specific embodiment of how to encode a video data format descriptor, as described for other packets.

The value of the 2-byte pixel data attribute field can be interpreted as follows:

Bits 1 and 0 select the display that should send the pixel data.

Bit [1:0]=11 or 00-display data to both eyes.

Bit [1:0]=10-Only send data to the left eye.

Bit [1:0]=01-Send data to the right eye only.

Bit 2 indicates whether the pixel data is in interlaced format. When bit 2 is 0, the pixel data is in the standard progressive format. When advancing from one column to the next When, the column number (pixel Y coordinate) should be incremented by 1. When bit 2 is 1, the pixel data is in interlaced format. When advancing from one column to the next, the column number (pixel Y coordinate) should be incremented by 2.

Bit 3 indicates whether the pixel data is in alternate pixel format. This is similar to the standard interlace mode activated by bit 2, but the interlace is vertical rather than horizontal. When bit 3 is 0, the pixel data is in the standard progressive format. When receiving each successive pixel, the row number (pixel X coordinate) should be incremented by 1. When bit 3 is 1, the pixel data is in alternate pixel format. When receiving each pixel, the row number (pixel X coordinate) should be incremented by 2.

Bit 4 indicates whether the pixel data is related to the display or the camera. When bit 4 is 0, the pixel data is sent to or from the display frame buffer. When bit 4 is 1, the pixel data is sent to or from the camera.

Bit 5 is reserved for future use, and therefore is usually set to zero.

Bits 7 and 6 designate the display update bits of the frame buffer where the pixel data should be written. The effect of the frame update bit is explained in detail elsewhere. When bit [7:6] = "01", write the pixel data into the offline image buffer. When bit [7:6] = "00", write pixel data into the image buffer used to refresh the display. When bit [7:6] = "11", the pixel data is written into all image buffers. If the bit [7:6] is "10", it will be regarded as an invalid value. These bits are currently reserved for future use. In this case, the pixel data will be ignored and not written to any of the image buffers.

Bits 8 to 15 are reserved for future use and should be set to zero.

The 2-byte X left edge, Y top edge, X right edge, and Y bottom edge fields respectively specify the X coordinate of the left edge, the Y coordinate of the top edge, the coordinate of the right edge, and the bottom edge of the destination image. The 2-byte X image size and Y image size fields respectively specify the width and height of the source image. The CRC field also contains the CRC of all the bytes in the packet including the packet length.

<b><i>38. Zoom video stream confirmation packet</i></b>

The zoomed video stream confirmation packet allows a client to confirm receipt of a zoomed video stream setting packet. The client should reply to a parameter value of 143 in the valid parameter list of the valid state reply list packet and indicate that the scaling is supported by using a non-zero value in the maximum number of streams field of the zoom video streaming capability packet. The ability of the video stream to confirm the packet.

Fig. 81 generally shows the format of the zoomed video stream confirmation packet. As shown in FIG. 81, in a specific embodiment, a zoomed video stream confirmation packet is structured to have packet length, packet type, cClient, stream ID, ACK code, and CRC fields. The 2-byte packet length field is used to specify the total number of bytes (not including the packet length field), where the value 10 is used for this packet type, and the packet type 137 identifies the packet as a zoomed video Stream confirmation packet.

The 2-byte cClient ID field is reserved for future use in the client ID, and the field is generally set to zero. The 2-byte stream ID field specifies a unique identifier of one of the stream IDs. This is the same value specified by the host in the zoom video stream setting packet.

The 2-bit Ack code field provides a value containing a code indicating the result of an attempt to update the specified zoomed video stream. In a specific embodiment, the code It is defined as follows:

0-The stream allocation attempt was successful.

1- This stream has a successful deallocation attempt.

2- An invalid attempt to allocate a stream ID that has already been allocated.

3- An invalid attempt to unassign a stream ID that has been unassigned.

4- The client does not support zoom video streaming.

5- The flow parameters are inconsistent with the capabilities of the client.

6- A stream ID value larger than the maximum value allowed by the client.

7-Insufficient resources available for allocating designated streams in the client.

The 2-byte CRC field contains the CRC of all the bytes in the packet (including the packet length).

<b><i>39. Zoom video streaming package</i></b>

The zoomed video stream packet is used to send pixel data related to a specific zoomed video stream. The size of the area referenced by the packet is defined by the packet of the zoomed video stream. The client should use one of the parameter values 143 in the valid parameter reply list of the valid status reply list packet and use one of the zoomed video stream confirmation packet's Ack code fields to indicate the successful scaled video stream allocation response. Support the ability of the zoom video streaming package.

Fig. 82 generally shows the format of a zoomed video stream packet of a specific embodiment. As shown in Figure 82, the zoomed video stream packet is structured to have fields of packet length, packet type, hClient ID, stream ID, parameter CRC, pixel count, pixel data and pixel data CRC. The 2-byte packet type field uses a value of 18 to identify the packet as a zoomed video stream packet. The hClient ID field is reserved for the client ID, and is generally set to zero. As mentioned above, the 2 The byte stream ID field specifies a unique identifier of one of the stream IDs. This value is specified by the host in the zoomed video stream setting packet and confirmed in the zoomed video stream confirmation packet.

The 2-byte pixel count field specifies the number of pixels in the following pixel data field. The 2-byte parameter CRC field has the CRC of all the bytes from the packet length to the pixel count. If the CRC check is incorrect, the entire packet should be discarded. The 2-byte pixel data field contains the original video information to be zoomed and displayed. Format the data in the manner described in the video data format descriptor field. As previously defined, one row of data is sent at a time.

The 2-byte pixel data CRC field only includes the CRC of the pixel data. If the CRC check is incorrect, the pixel data should still be used but the CRC error count should be incremented.

<b><i>40. Request a specific status packet</i></b>

The request-specific status packet provides a component, mechanism, or method for the host to request the client to send a capability or status packet back to the host, as specified in the packet. The user terminal returns a packet of the specified type in the next reverse link encapsulated packet. If the client has the ability to respond to the request for a specific status packet, the client will set bit 17 in the client feature capability field of the client capability packet. The client should use bit 21 of the client feature capability field of the client capability packet to indicate its ability to support the request specific status packet.

FIG. 83 generally shows the format of the request specific status packet of a specific embodiment. As shown in Figure 83, the request specific status packet is structured to have the packet length, packet type, hClient ID, status packet ID, and CRC fields.

The packet length field specifies the total number of bytes in the packet that does not include the packet length field, and for this packet type, it is generally fixed at a value of 10. A packet type 138 identifies the packet as a request specific status packet.

The hClient ID field (2 bytes) is reserved for future client ID use, and the field is currently set to zero.

The 2-byte status packet ID field specifies the capability or type of status packet that the client will send to the host as follows:

66-The client capability information packet should be sent by the client.

133-The α-cursor image capability packet should be sent by the client.

139-Should send a valid status response list packet, which identifies the ability of the client to send and the exact type of status packet.

140-Should be sent by the client to deal with the delay parameter packet.

141-The personal display capability information packet should be sent by the client.

142-The client should send a display error report packet.

143-Scalable video streaming capability packet should be sent by the client.

144-The display identification packet should be sent by the client.

56 to 63-can be used for manufacturer specific capabilities and status identifiers.

The CRC field also contains the CRC of all the bytes in the packet including the packet length.

<b><i>41. Valid status reply list packet</i></b>

The valid status response list packet provides the host with a status and capability packet list that the client is capable of responding to. The client can use bit 21 of the client feature capability field of the client capability packet to indicate the capability of supporting the valid status reply list packet.

FIG. 84 generally shows the format of a valid status reply list packet in a specific embodiment. As shown in Figure 84, the valid status reply list packet is structured to have packet length, packet type, cClient ID, number of values in the list, valid parameter reply list, and CRC fields. The packet length of this type of packet is generally fixed at a value of 10, and a type value of 139 identifies the packet as a valid state reply packet. The cClient ID field is reserved for future use as the client ID, and the field is generally set to zero. The 2-byte value in the list field specifies the number of items in the following valid parameter response list.

The valid parameter response list field contains a 2-byte parameter list that specifies the capability or status packet type that the client can send to the host. If the client has instructed it to respond to the request for a specific status packet (using bit 21 of the client feature capability field in the client capability packet), then it can at least send the client capability packet (information) Packet type=66) and the valid status reply list packet (packet type=139). The types of packets sent by the client and included in this list, together with their individual designations used in this specific embodiment, are:

66-Client capability information package.

133-α-Cursor image capability information package.

139-Valid status reply list packet, which identifies the ability of the client to transmit and the exact type of status packet.

140-Information packet processing delay parameter information packet.

141-Personal display capability information package.

142-Client Error Report Packet

143-Zoom Video Streaming Capability Packet

144-Client identification packet.

56 to 63-can be used for manufacturer specific capabilities and status identifiers.

The CRC field contains the CRC of all the bytes in the packet including the packet length.

<b><i>42. Packet processing delay parameter packet</i></b>

The packet processing delay parameter The packet provides a set of parameters to allow the host to calculate the time required to complete the processing related to receiving a specific packet type. Some commands sent by the host cannot be completed by the client in zero time. The host can poll the display request and status bits in the status packet to determine whether the client has completed a specific function, or the host can use the packet to process the parameters returned by the client in the delay parameter packet. Calculate the completion time. The client can use a parameter value 140 in the valid parameter response list of the valid status response list packet to indicate its ability to support the processing delay parameter packet of the packet.

FIG. 85A generally shows the format of a packet processing delay parameter packet of a specific embodiment. As shown in FIG. 85A, the packet processing delay parameter packet is structured to have packet length, packet type, cClient ID, number of list items, delay parameter list, and CRC field. The packet length of this type of packet is generally fixed at a value of 10, and a type value of 140 identifies the packet as a packet processing delay parameter packet. The cClient ID field is reserved for future use as the client ID, and the field is generally set to zero. The 2-byte list item number field specifies the number of items in the following valid parameter response list.

The delay parameter list field is a list containing one or more delay parameter list items. FIG. 85B shows a single delay parameter list item of a specific embodiment The format, which displays the delayed packet type, pixel delay, horizontal pixel delay, vertical pixel delay, and fixed delay fields.

Generally, the length of each delay parameter list item is limited to exactly 6 bytes, and each item is further defined as follows: The 2-byte delayed packet type field specifies the packet type to which the following delay parameters apply.

The pixel delay field (1 byte) contains the index of the delay finger. Multiply the value read from the table by the total number of pixels in the destination field of the packet. The total number of pixels is the width multiplied by the height of the destination area of the bitmap referenced by the packet.

The 1-byte horizontal pixel delay field contains a value, which is the index of the delay value table (the same table as DPVL). Multiply the value read from the table by the width of the destination field of the packet (in pixels).

The 1-byte vertical pixel delay field contains a value, which is the index of the delay value table (the same table as DPVL). Multiply the value read from the table by the height of the destination field of the packet (in pixels).

The fixed delay field uses 1 byte as the index of the delay value table (the same table as DPVL). The value read from the table is a fixed delay parameter, which represents the time required to process a packet that has nothing to do with any parameter value specified in the packet. Determine the total delay or the time delay of packet processing completion according to the following relationship: delay = (packet processing delay (pixel delay) total pixels) + (packet processing delay (horizontal pixel delay) × width) + (packet processing delay) (Vertical pixel delay) × height) + packet processing delay (fixed delay)

For some packets, total pixels, width, or height are not applicable, so these parameters are not referenced in the corresponding packets. In such cases, the corresponding pixel delay parameter is generally set to zero.

<b><i>43. Personal Display Capability Information Package</i></b>

The personal display capability information package provides a set of parameters describing the capability of a person's display device, for example, a head-mounted display or display glasses. This allows the host to customize the display information according to the specific capabilities of a client. On the other hand, a client indicates the ability to transmit the individual display capability packet by using one of the corresponding parameters in the effective parameter reply list of the effective status reply list packet.

FIG. 86 generally shows the format of the personal display capability information packet of a specific embodiment. As shown in Figure 86, the personal display capability packet is structured to have packet length, packet type, cClient ID, sub-pixel layout, pixel shape, horizontal field of view, vertical field of view, intersection of visual axes, and left/right images. Overlap, perspective, maximum brightness, optical power, minimum IPD, maximum IPD, field curvature list and CRC fields. In a specific embodiment, the value of the packet length field is fixed to 68. A packet type value 141 identifies the packet as a human display ability packet. The cClient ID field is reserved for future use, and is generally set to zero at present.

This sub-pixel layout field uses the following values to specify the physical layout of a pixel from top to bottom and from left to right: 0 indicates that the pixel layout is not defined once; 1 indicates red, green, and blue bars; 2 indicates blue, green , Red bar; 3 indicates a four-element group of pixels, the four groups of pixels have a 2-by-2 sub-pixel configuration, the red sub-pixel is on the upper left, the blue sub-pixel is on the lower right, and two There are two green sub-pixels, one at the bottom left and the other at the top right; 4 indicates a quadruple of pixels, the four groups of pixels have a 2-by-2 sub-pixel configuration, the red sub-pixel is at the bottom left, and the blue sub-pixel is at The upper right and two green sub-pixels, one on the upper left and the other on the lower right; 5 indicates a triangular layout (triple); 6 indicates a mosaic pattern of red, green and blue overlapping (for example, with Field continuous color LCOS display); and values 7 to 255 are generally reserved for future use.

The pixel shape field uses the following values to specify the shape of each pixel composed of sub-pixels of a specific configuration: 0 indicates that the pixel shape is not defined once; 1 indicates a circle; 2 indicates a square; 3 indicates a rectangle; 4 indicates an oval ; 5 indicates an ellipse; and the values 6 to 255 are reserved for future use to indicate the desired shape, which can be understood by those familiar with the art.

The 1-byte horizontal field of view (HFOV) field specifies a horizontal field of view with an increment of 0.5 degrees (for example, if the HFOV is 30 degrees, the value is 60). If this value is zero, the HFOV is not specified.

The 1-byte vertical field of view (VFOV) field specifies a vertical field of view with an increment of 0.5 degrees (for example, if the VFOV is 30 degrees, the value is 60). If this value is zero, the VFOV is not specified.

The 1-byte visual axis intersection field specifies the visual axis intersection point with an increment of 0.01 (1/m) diopter (for example, if the visual axis intersection point is 2.22 meters, the value is 45). If this value is zero, the intersection of the boresight is not specified. (It should be noted whether the specification of this parameter is suitable for the required range in most applications?)

The 1-byte left/right image overlap field specifies the percentage of left and right image overlap. The allowable range of the image overlap percentage is 1-100. Value 101 to 255 Is an invalid value and should not be used. If this value is zero, the image overlap is not specified.

The 1-byte perspective field specifies the perspective percentage of the image. The allowable range of the perspective percentage is 0-100. The values 101 to 254 are invalid values and should not be used. If the value is 255, the perspective percentage is not specified.

The 1-byte maximum brightness field specifies the maximum brightness in increments of 20 nits (for example, if the maximum brightness is 100 nits, this value is 5). If this value is zero, the maximum brightness is not specified.

The 2-byte optical capability flag field contains various fields that specify the optical capability of the display. These bit values are generally designated as follows:

Bits 15 to 5 are reserved for future use and should be set to zero.

Bit 4 selects lens focus adjustment, where a value of "0" means that the display does not have lens focus adjustment, and a value of "1" means that the display has lens focus adjustment.

Select the binocular function from 3 to 2 as follows: a value of 0 means that the monitor is a binocular and can only display 2D images; a value of 1 means that the monitor is a binocular and can display 3D images; 2 Indicates that the display is a monocular, and the 3 series is reserved for future use.

Bits 1 to 0 select left and right field curvature symmetry, where a value of 0 means field curvature is undefined. If this field is zero, all field curvature values from A1 to E5 should be set to zero. Except for point C3, point C3 should specify the focal length of the display, otherwise it should be set to zero to indicate that the focal length is not specified . A value of 1 means that the left and right displays have the same symmetry; a value of 2 means that the left and right displays are mirrored on the vertical axis (row C); and a value of 3 is reserved for future use.

The 1-byte minimum interpupillary distance (IPD) field specifies the smallest in millimeters (mm) Interpupillary distance. If this value is zero, the minimum interpupillary distance is not specified. The 1-byte Maximum Interpupillary Distance (IPD) field specifies the maximum interpupillary distance in millimeters (mm). If this value is zero, the maximum interpupillary distance is not specified.

The field curvature point list field contains a list of 25 2-byte parameters that specify thousands of diopters in the range of 1 to 65535 (for example, 1 is 0.001 diopter, and 65535 is 65.535 diopter) ( 1/m) focal length. As shown below, the 25 elements in the field curvature point list are identified as A1 to E5. The points should be evenly distributed on the active area of the display. Row C corresponds to the vertical axis of the display, and column 3 corresponds to the horizontal axis of the display. Rows A and E correspond to the left and right edges of the display, respectively. Rows 1 and 5 correspond to the top and bottom edges of the display, respectively. The order of these 25 points in the list is: A1, B1, C1, D1, E1, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5.

<img file="TWI345404B_D0013.tif" />

The CRC field contains the CRC of all the bytes in the packet including the packet length.

<b><i>44. Client error report packet</i></b>

The client error report packet serves as a mechanism or component that allows a client to provide an operation error list to the host. The client is from the master The machine receives specific commands and can detect a wide range of errors during its normal operation. Examples of these errors include: the client may have been instructed to operate in a mode that it does not support, the client may have received a packet containing specific parameters that are out of range or beyond the capabilities of the client, the user may have been commanded The terminal enters a mode in an incorrect order. The client error report packet can be used to detect errors during normal operation, but it is extremely useful for system designers and integrators to diagnose problems in the development and integration of host and client systems. The client uses a parameter value 142 in the valid parameter response list in the valid status response list packet to indicate its ability to transmit the client error report packet.

FIG. 87A generally shows the format of a client error report packet in a specific embodiment. As shown in FIG. 87A, the client error report packet is structured to have the packet length, packet type, cClient ID, number of list items, error code list, and CRC fields. A packet type value 142 identifies the packet as a client error report packet. The cClient ID field is reserved for future use, and is generally set to zero at present. The number of list items field (2 bytes) specifies the number of items in the following error code list. The error code list field (8 bytes here) is a list containing one or more error report list items. Figure 87B shows the format of a single error report list item.

As shown in FIG. 87B, in a specific embodiment, the length of each error report list item is exactly 4 bytes. In a specific embodiment, there is a structure that includes the following items: a 2-byte group Display the error code field, which specifies the type of error reported, a 2-byte error subcode field, which specifies a greater degree of detail about the error defined by the client error code packet. The manufacturer of the client defines the specific definition of each client error code. It is not necessary to define an error sub-code for each displayed error code, and if the error sub-code is not defined, the value is set to zero. The manufacturer of the client defines the specific definition of each error subcode.

<b><i>45. Client identification packet</i></b>

The client identification packet allows a client to return identification data in response to a request for a specific status packet. In a specific implementation, a client uses a parameter value 144 in the valid parameter response list of the valid status response list packet to indicate the ability to transmit the display identification packet. It is very useful for the host to determine the manufacturer's name and model of the client device by reading this data from the client. The information can be used to determine whether the client has special capabilities that cannot be described in the client capability packet. There may be two methods, components, or mechanisms for reading identification information from the client. One is by using the client capability packet, which contains fields similar to those in the basic EDID structure. Another method is to use the client identification packet, which contains a richer set of information than similar fields in the client capability packet. This allows a host to identify a manufacturer that has not assigned a 3-character EISA code, and allows the serial number to contain alphanumeric characters.

Fig. 88 generally shows the format of the client identification packet of a specific embodiment. As shown in Figure 88, the client identification packet is structured as a string with packet length, packet type, cClient ID, manufacturing week, manufacturing year, manufacturer name length, product name length, serial number length, and manufacturer name string , Product name string, serial number string and CRC field.

The 2-byte packet type field contains the identification of the packet as a display identification The value of the information package. In a specific embodiment, this value is selected as 144. The cClient ID field (2 bytes) is reserved again for future use in the client ID, and the field is generally set to zero. The CRC field (2 bytes) contains a 16-bit CRC of all the bytes in the packet including the length of the packet.

A 1-byte manufacturing week field contains a value that defines the manufacturing week of the display. In at least one specific embodiment, if the client supports this field, the value is in the range of 1 to 53. If the client does not support this field, it is generally set to zero. The 1-byte manufacturing year field contains a value that defines the manufacturing year of the client (display). Although other basic years may be used, this value is an offset from the starting year 1990. You can use this field to indicate the year in the range of 1991 to 2245. Example: 2003 corresponds to a manufacturing year value of 13. If the client does not support this field, it should be set to a zero value.

The manufacturer name length, product name length, and serial number length fields each contain a 2-byte value specifying the length of the following fields: the length of the manufacturer name string field including any zero terminator or zero padding characters, including any zeros The length of the product name string field of the terminator or zero-padding sub-characters, and the length of the serial number string field including any zero-terminator or zero-padding sub-characters.

The manufacturer name string, product name string, and serial number string fields each contain a variable number of bytes specified by the manufacturer name, product name, and serial number fields, and these fields respectively contain designated The display manufacturer, product name, and an ASCII string of letters and numbers. Terminate each of these strings with at least one zero character.

<b><i>46. Alternate display capability information package</i></b>

The alternate display capability packet indicates the capability of the alternate display attached to the MDDI client controller. Send this packet in response to a request for a specific status packet. When prompted, a client device sends an alternate display capability packet for each alternate display supported. The client should indicate its ability to transmit the alternate display capability packet via a parameter value 145 in the effective parameter reply list of the effective status reply list packet.

For MDDI systems operating in internal mode, generally multiple displays can be connected to an MDDI client controller. An example application is a mobile phone with a large display inside the flip and a smaller display outside . The number of alternate display fields of the client capability information package is used to report the attachment of multiple displays, and the alternate display capability information package reports the capabilities of each alternate display. The video stream packet includes 4 bits in the pixel data attribute field to address each alternate display in the client device.

FIG. 89 generally shows the format of the alternate display capability information packet of a specific embodiment. As shown in Figure 89, the alternate display capability packet is structured to have packet length, packet type, cClient ID, alternate display number, reserved 1, bit mapping width, bit mapping height, display window width, display window Height, color mapping RGB width, RGB capability, monochrome capability, reserved 2, Y Cb Cr capability, display feature capability, reserved 3 and CRC fields. A packet type value of 145 identifies the packet as an alternate display capability packet. The cClient ID field is reserved for future use as client ID, and is generally set to zero.

The alternate display number field uses 1 byte, and uses an integer from 0 to 15 to indicate the alternate display number. The first alternate display should be number 0, and the unique alternate display number value is used to identify the other alternate displays, and the used The maximum value is the total number of alternating displays minus one. A value greater than the total number of alternate displays minus 1 should not be used. Example: A mobile phone with a primary display and a caller ID display connected to an MDDI client has an alternate display, so the alternate display number of the caller ID display is zero, and the alternate display of the display capability packet The value of the field number is 1.

The reserved 1 field (1 byte) is reserved for future use. Set all bits in this field to zero. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit character address, and align the 4-byte field with a 32-bit character address.

The bitmap width field uses 2 bytes to specify the width of the bitmap, expressed in the number of pixels. The bitmap height field uses 2 bytes to specify the height of the bitmap, expressed in the number of pixels. The display window width field uses 2 bytes to specify the width of the display window, expressed in pixels. The display window height field uses 2 bytes to specify the height of the display window, expressed in pixels.

The color map RGB width field uses 2 bytes to specify the number of red, green, and blue component bits that can be displayed in the color map (palette) display mode. For each color component (red, green, and blue), a maximum of 8 bits can be used. Although 8 bits of each color component are transmitted in the color mapping packet, only the number of least significant bits of each color component defined in this field is used. If the display client cannot use the color mapping (palette) format, this value is zero. The color map RGB width character consists of three separate unsigned values: bits 3 to 0 use valid values 0 to 8 to define the blue bits in each pixel Maximum number. Bits 7 to 4 use valid values of 0 to 8 to define the maximum number of green bits in each pixel. Bits 11 to 8 use valid values of 0 to 8 to define the maximum number of red bits in each pixel. Bits 14 to 12 are reserved for future use and are generally set to zero. Bit 15 is used to indicate the client's ability to accept color-mapped pixel data in packaged or unpackaged format. Set bit 15 to a logical bit on time, which indicates that the client can accept color-mapped pixel data in packaged or unpackaged formats. If bit 15 is set to logic zero, this indicates that the client can only accept color-mapped pixel data in an unpackaged format.

The RGB capability field uses 2 bytes to specify the number of bits of the displayable resolution in the RGB format. In a specific embodiment, if the user terminal cannot use the RGB format, this value is set equal to zero. The RGB capability character consists of three separate unsigned values: bits 3 to 0 define the maximum number of blue bits (blue intensity) in each pixel, and bits 7 to 4 define the green bits in each pixel The maximum number of cells (green intensity), and bits 11 to 8 define the maximum number of red bits (red intensity) in each pixel. Bits 14 to 12 are reserved for future use and are set to zero. Use bit 15 to indicate the client's ability to accept RGB pixel data in packaged or unpackaged formats. Set bit 15 to a logical bit on time, which indicates that the client can accept RGB pixel data in packaged or unpackaged formats. If bit 15 is set to logic zero, this indicates that the client can only accept RGB pixel data in unpackaged format.

The 1-byte monochrome capability field contains a value or information that specifies the number of bits of the resolution that can be displayed in the monochrome format. If the client cannot use the monochrome format, then this value is set equal to zero. Bits 6 to 4 are reserved for future use and are generally set to zero. Bits 3 to 0 define the possible storage of each pixel The maximum number of bits in the current grayscale. These four bits make it possible to specify that each pixel consists of 1 to 15 bits. If the value is zero, the client does not support the monochrome format. When bit 7 is set to one, it indicates that the client can accept monochromatic pixel data in packaged or unpackaged format. If bit 7 is set to zero, this indicates that the client can only accept monochrome pixel data in unpackaged format.

The reserved 2 fields are 1-byte wide fields, reserved for future use, and generally all bits in this field are set to logical zero levels. In a specific embodiment, the purpose of this field is to align all subsequent 2-byte fields with a 16-bit character address, and to align the 4-byte field with a 32-bit character address. Meta address alignment.

The 2-byte Y Cb Cr Capability field specifies the number of bits of resolution that can be displayed in the Y Cb Cr format. If the client cannot use the Y Cb Cr format, this value is zero. The Y Cb Cr capability character consists of three separate unsigned values: bits 3 to 0 define the maximum number of bits for the specified Cb sample, bits 7 to 4 define the maximum number of bits for the specified Cr sample, bit 11 The definition to 8 specifies the maximum number of bits for the Y sample, while bits 14 to 12 are reserved for future use and are set to zero. When bit 15 is set to one, it indicates that the client can accept Y Cb Cr pixel data in packaged or unpackaged format. If bit 15 is set to zero, this indicates that the client can only accept Y Cb Cr pixel data in unpackaged format.

The 1-byte Bayer capability field specifies the maximum number of resolution bits, pixel groups, and pixel order that can be transmitted in Bayer format. If the client cannot use the Bayer format, set this value to zero. The Bayer ability field is composed of the following values: Bits 3 to 0 define the maximum intensity present in each pixel The number of bits, bits 5 to 4 define the pixel group pattern that may be required, bits 8 to 6 define the required pixel order, and bits 14 to 9 are reserved for future use and are set to zero. When bit 15 is set to one, it indicates that the client can accept Bayer pixel data in packaged or unpackaged format. If bit 15 is set to zero, this indicates that the client can only accept Bayer pixel data in unpackaged format.

The 2-byte CRC field contains a 16-bit CRC of all the bytes in the packet (including the packet length).

<b><i>47. Register access packet</i></b>

The register access packet provides access to a component, mechanism or method of the configuration and status register in the opposite end of the MDDI link to a host or a client. For each display or device controller, these registers may be unique. These registers already exist in many displays that need to set the configuration, operating mode, and other useful and necessary settings. The register access packet allows the MDDI host or client to both write a register and request to use the MDDI link to read a register. When the host or user machine requests to read a register, the opposite end should indicate that it is from a register by sending the register data of the same packet type and by using the read/write information field. Respond to the data read by a specific register. The register access packet can be used to read or write multiple registers by specifying a register count greater than 1. A client uses bit 22 of the client feature capability field of the client capability packet to indicate the ability to support the register to access the packet.

FIG. 90 generally shows the format of the register access packet of a specific embodiment. As shown in Figure 90, the register access packet is structured to have a packet length Degree, packet type, bClient ID, read/write flag, register address, parameter CRC, register data list and register data CRC field. A packet type value 146 identifies the packet as a register access packet. The bClient ID field is reserved for future use, and is generally set to zero at present.

The 2-byte read/write flag field specifies a specific packet as a write or read or a response to a read, and provides a count of data values.

Bits 15 to 14 are used as read/write flags. If bit [15:14] is "00", then this packet contains a register to be written to by the register address field data of. The data to be written into the designated registers is included in the register data list field. If the bit [15:14] is "10", this is a request for data from one or more registers addressed by the register address field. If the bit [15:14] is "11", the packet contains the data requested in response to a register access packet, where the register access packet read/write flag Bit 15: 14 is set to "10". The register address field contains the register address corresponding to the first register data list item, and the register data list field should include the data read from the address(es). If bit [15:14] is "01", treat it as an invalid value, and this value is reserved for future use and is not used now.

Bit 13:0 uses a 14-bit unsigned integer to specify the number of 32-bit register data items to be transmitted in the register data list field. If bit 15:14 is equal to "00", bit 13:0 specifies the register included in the register data list field to be written to the register from the register specified by the register address field The number of data items in the 32-bit register of the device. If bit 15:14 is equal to "10", bit 13:0 designates the receiving device to send to a request to read temporary The number of 32-bit register data items of the device of the register. The register data list field in this news package does not contain items, and the length is zero. If bit 15:14 is equal to "11", bit 13:0 specifies the number of 32-bit register data items that have been read from the register included in the register data list field. Currently, 15:14 is not set to be equal to "01". It is an invalid value and is additionally reserved for future designation or use.

The register address field uses 4 bytes to indicate the register address to be written or read. For the address register whose address is less than 32 bits, the upper position element is set to zero.

The 2-byte parameter CRC field contains a CRC of all the bytes from the packet length to the register address. If the CRC check is incorrect, the entire packet is discarded.

The register data list field contains a list of 4-byte register data values to be written into the client register or one of the values read from the client device register.

The 2-byte register data CRC field includes only one CRC of the register data list. If the CRC check is incorrect, the register data can still be used, but the CRC error count will increase.

<b>D. Packet CRC</b>

These CRC fields appear at the end of the packet, sometimes after some more critical parameters in the packet with a relatively large data field, so the possibility of errors during transmission increases. In a packet with two CRC fields, when only one CRC field is used, the CRC generator is reinitialized after the first CRC so that the CRC calculation after a long data field is not affected by the packet Parameter influence at the beginning.

In an exemplary embodiment, the polynomial used in the CRC calculation is known as CRC-16 or X16+X15+X2+X0. An exemplary implementation of a CRC generator and checker 3600 useful for implementing the present invention is shown in FIG. 36. In Figure 36, only before the first bit of a packet input on the Tx_MDDI_Data_Before_CRC line is transmitted, a CRC register 3602 is initialized to a value of 0x0001, and then the byte of the packet is offset from the LSB. Move into the register. It should be noted that the number of register bits in this diagram corresponds to the order of the polynomial used, not the bit positions used by MDDI. It is more effective to transfer the CRC register in a single direction, which results in CRC bit 15 appearing in bit position 0 of the MDDI CRC field, and CRC register bit 14 appearing in bit position 1 of the MDDI CRC field, and so on. , Until it reaches MDDI bit position 14.

As an example, the content of the display request and status packet is as follows: 0x07, 0x46, 0x00400, 0x00 (or expressed as a byte sequence like 0x07, 0x00, 0x46, 0x00, 0x46, 0x00, 0x00) , And use the input of multiplexers 3604 and 3606 and NAND gate 3608 to submit the sequence. The CRC output generated on the Tx_MDDI_Data_With_CRC line is 0x0ea1 (or expressed as a sequence like 0xa1,0x0e).

When the CRC generator and checker 3600 are configured as a CRC checker, the CRC received on the Rx_MDDI_Data line is input to the multiplexer 3604 and NAND gate 3608, and NOR gate 3610 and exclusive OR (XOR) are used. The gate 3612 and the AND gate 3614 are compared with the value in the CRC register bit by bit. If there is any error (as output by AND gate 3614), correct For each packet containing a CRC error, the CRC is incremented once by connecting the output of the gate 3614 to the input of the register 3602. It should be noted that the example circuit shown in the diagram of FIG. 36 can output multiple CRC error signals in a given CHECK_CRC_NOW window (see FIG. 37B). Therefore, the CRC error counter generally only counts the first CRC error instance in each interval of the CHECK_CRC_NOW activity. If configured as a CRC generator, the CRC will be clocked outside the CRC register at the same time as the end of the packet.

Figures 37A and 37B graphically illustrate the timing and actuation signals for input and output signals. As shown in FIG. 37A, a CRC is generated and a data packet is transmitted under the state (0 or 1) of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals together with the Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC signals. FIG. 37B shows that in the state of Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals together with Rx_MDDI_Data and CRC error signals, a data packet is received and the CRC value is checked.

<b>E. Overload of error codes used for packet CRC</b>

As long as the data packet and CRC are only transmitted between the host and the client, the error code will not be accommodated. The only error was the loss of synchronization. In addition, it is necessary to wait for the link to time out from the lack of a good data transmission path or pipeline, and then reset the link and continue. Unfortunately, this is time consuming and inefficient.

For use in a specific embodiment, a new technology has been developed in which the CRC part of the packet is used to transmit error code information. This situation is generally shown in Figure 65. That is, one or more errors are generated by the processor or device that handles the data transmission Error code, the error code(s) indicates a predefined specific error or defect that may occur in the communication process or link. When an error is encountered, the bit used for the CRC of the packet is used to generate and transmit an appropriate error code. That is, the CRC value is overloaded or overwritten with the expected error code, which can be detected by the error monitor or checker that monitors the value of the CRC field at the receiving end. For the case where the error code matches the CRC value for a certain reason, the complement of the error is transmitted to prevent confusion.

In a specific embodiment, in order to provide a robust error warning and detection system, the error code can be transmitted several times, using a series of packets, generally all the packets transmitted or transmitted after the error has been detected. This happens until the point where the system clears the establishment of the error condition, which transmits the regular CRC bits, but will not be overloaded by another value.

This technology of overloading the CRC value provides a faster response to system errors while using a minimum number of extra bits or fields.

As shown in Figure 66, a CRC overwrite mechanism or device 6600 uses an error detector or detection component 6602. The error code detector or detection component 6602 can form a combination of other circuits previously described or known. Part of it is to detect the occurrence or existence of errors in the communication link or program. An error code generator or component 6604 can be formed as part of other circuits, or it can use techniques such as look-up tables to store preselected error messages, which generate one or more error codes to indicate that it has been detected Pre-defined specific errors or defects that have occurred. It is easy to understand that the devices 6602 and 6604 can be formed as a single circuit or device as needed, or as part of a sequence of programmed steps used in other known processors and components.

Display a CRC value comparator or comparison component 6606 for inspection and selection Whether the error code of is the same as the transmitted CRC value. If this is the case, use a complement generator or generating component or device to provide the complement of the error codes so as not to mistake the error codes as the original CRC pattern or value and to confuse or confuse the detection scheme complication. Then, an error code selector or selection component or device 6610 appropriately selects the error code or value to be inserted or overwritten, or its individual complement. An error code CRC overwrite device or overwrite mechanism or component 6612 is to transmit the required error code to a receiving device to receive the data stream, the packet and the required code to be inserted and overwrite the corresponding or appropriate A device for CRC value.

As mentioned above, a series of packets can be used to transmit the error code several times, so that the overwrite device 6612 can use a memory storage element to keep a copy of the code during processing or can be used according to the situation or view. The previous component or other known storage location that needs to store or save the value of the code recalls the code.

The general processing performed by the overwrite mechanism of FIG. 66 is additionally shown in detail in FIGS. 67A and 67B. In 67A, one or more errors in the communication data or program are detected in step 6702, and an error code is selected in step 6704 to indicate this condition. At the same time, or at an appropriate point, the CRC value to be replaced is checked in step 6706, and the value is compared with the required error code in step 6708. The result of this comparison, as previously discussed, is a decision on whether the required code or other representative value will be the same as the CRC value that appears. If this is the case, the process proceeds to step 6712, where the complement in this step or another representative value in some cases is selected as the insert code as needed. Once you have decided which error codes or values you want to insert in steps 6710 and 6714, choose to use Insert the appropriate code. These steps are explained separately for reasons of brevity, but these steps generally represent a single choice based on the decision output of step 6708. Finally, in step 6716, an appropriate value is overwritten in the CRC location for the target packet of the program to be transmitted.

At the receiving end of the packet, as shown in FIG. 67B, in step 6722, the CRC values of the packets are monitored. Generally, one or more programs are used in the system to monitor the CRC values to determine whether an error has occurred during data transmission and whether to request the retransmission of the packet(s), or stop further operations, etc. Some of these procedures have been discussed in the article. As part of this type of monitoring, this information can also be used to compare values with known or preselected error codes or representative values and detect the occurrence of errors. Alternatively, a separate error detection procedure and monitoring can be implemented. If it seems that a code appears, the code is retrieved or additional attention is paid in step 6724 for further processing. In step 6726, a decision can be made whether the code is an actual code or a complement. In this case, an additional step 6728 is used to convert the value to the required code value. In either case, the generated capture code, complement, or other recovered value is then used in step 6730 to detect what error occurred from the transmitted code.

V. Link restarts from hibernation

When the host restarts the forward link from the dormant state, it drives MDDI_Data to a logic one state for about 150 MDDI_Stb cycles, and then drives MDDI_Data0 to a logic zero state for 50 MDDI_Stb cycles, and then transmits sub-frame header packets Start forward link traffic. This generally allows bus contention to be resolved before sending the sub-frame header packet by providing sufficient settling time between signals. When the host drives MDDI_Data0 to a logic one state At the same time, it also activates MDI_Stb to provide a clock pulse for the wake-up logic in the user terminal.

When the user terminal (here, the display) needs data or communication or service from the host, it drives the MDDI_Data0 line to a logic one state for about 70 to 1000 μsec, and after MDDI_Stb becomes active, MDDI_Stb is inactive for another 70 MDDI_Stb Cycle, although other cycles can be used as needed, then disable the driver by putting it in a high impedance state. If MDDI_Stb is active during sleep (although it is unlikely), the client may only drive MDDI_Data0 to logic one state for 70 MDDI_Stb cycles. This action causes the host to start or restart the data flow on the forward link (208), and poll the status of the client. The host must detect the existence of request pulses in 50 MDDI_Stb cycles, and then start to drive 50 MDDI_Data0 to logic one 150 MDDI_Stb cycles and logic zero MDDI_Stb cycles to start the sequence. If MDDI_Data0 is longer than 50 μsec in the logic one state, the display should not send service request pulses. The following describes the time selection properties and time interval tolerances related to the sleep processing and the startup sequence. (See 68A-C below)

FIG. 38 illustrates an example of processing steps for a typical user-side service request event 3800 without contention, in which the letters A, B, C, D, E, F, and G are used to mark events for ease of explanation. When the host sends a link close packet to the client device to notify it that the link will transition to a low-power sleep state, the procedure starts at point A. In the next step, the host enters the low-power sleep state by disabling the MDDI_Data0 driver and setting the MDDI_Stb driver to logic zero, as shown in point B. Drive MDDI_Data0 to zero through a high-impedance bias network allow. After a period of time, the client sends a service request to the host by driving MDDI_Data0 to a logical bit as shown in point C. The host still uses the high-impedance bias network to determine the logic zero level, but the driver in the user terminal forces the line to the logic level. Within 50 μsec, the host recognizes the service request pulse, and determines the logical level on MDDI_Data0 by activating its driver, as shown in point D. Then the client stops trying to determine the service request pulse, and the client puts its driver in a high impedance state, as shown in point E. The host drives MDDI_Data0 to the logic zero level for 50 μsec, as shown by point F, and starts to generate MDD_Stb in a manner consistent with the logic zero level on MDDI_Data0. After MDDI_Data0 is judged to the logic zero level and MDDI_Stb is driven for 50 μsec, the host starts to send data on the forward link by transmitting sub-frame header packets, as shown by point G.

Figure 39 illustrates a similar example, where the service request is determined after the link restart sequence is started, and the letters A, B, C, D, E, F, and G are used to mark the event again. This represents the worst case, where the request pulse or signal from the client is most likely to damage the sub-frame header packet. At point A, the process starts when the host sends a link-closing packet to the client device again to notify it that the link will transition to a low-power sleep state. In the next step, the host enters the low-power sleep state by disabling the MDDI_Data0 driver and setting the MDDI_Stb driver to a logic zero level, as shown in point B. As before, MDDI_Data0 is driven to the logic zero level by the high impedance bias network. After a period of time, the host starts the link restart sequence by driving MDDI_Data0 to the logic level shown at point C for 150 μsec. Before the 50 μsec transmission after the start of the link restart sequence, the display also judges that MDDI_Data0 is valid for 70 μsec. Continue time, as shown in point D. This occurs because the display needs to request service from the host and does not recognize that the host has started the link restart sequence. Then the client stops trying to determine the service request pulse, and the client puts its driver in a high impedance state, as shown in point E. The host continues to drive MDDI_Datao to a logical level. The host drives MDDI_Data0 to the logic zero level for 50 μsec, as shown by point F, and starts to generate MDD_Stb in a manner consistent with the logic zero level on MDDI_Data0. After MDDI_Data0 is judged to the logic zero level and MDDI_Stb is driven for 50 μsec, the host starts to send data on the forward link by transmitting the sub-frame header packet, as shown by point G.

From the above description, it can be seen that the previous solution included passing the host through two states as part of the wake-up sequence. For the first state, the host drives the MDDI_Data0 signal high by 150<i>μ</i>s, then drive the MDDI_Data0 signal low by 50<i>μ</i>s, start the MDDI_Stb line at the same time, and then start sending MDDI packets. This procedure can effectively advance the technology based on the data rate achievable using MDDI equipment and methods. However, as mentioned earlier, the higher speed in terms of reducing the response time to the situation or being able to select the next step or procedure more quickly simplifies the processing or component capabilities, and there is always a need.

The applicant has discovered a new creative method for wake-up processing and timing, in which the host uses a timing based on the clock cycle for signal switching. In this configuration, after the host drives the MDDI_Data0 signal high at the beginning of the wake-up sequence, the host starts to switch MDDI_Stb from 0 to 10 μsec, and does not wait until the signal is driven low. During the wake-up sequence, the host toggles MDDI_Stb, as if the MDDI_Data0 signal is always at the same logic zero level. This effectively removes the concept of time on the user side, and the host is used in the first two states from the previous The period of 150 μs and 50 μs of the frequency is changed to the 150 clock period and 50 clock period for these periods.

Now the host is responsible for driving the data line high and starting to send strobe signals within 10 clock cycles, treating the data line as zero. After the host has driven the data line higher by 150 clock cycles, the host drives the data line lower by 50 clock cycles while continuing to send strobe signals. After completing these two procedures, the host can start sending the first sub-frame header packet.

On the user side, the user side implementation can now use the generated clock to calculate the number of clock cycles of the data line from high to low. The number of clock cycles that need to occur in the two drive-up state data lines is 150, and the drive-down state data line is 50. This means that for the correct wake-up sequence, the client should be able to count at least 150 continuous clock cycles of the high data line, followed by at least 50 continuous clock cycles of the low data line. Once these two conditions are met, the client can start searching for the unique character of the first subframe. The interrupt in this type is used as the basis for returning the counter to the initial state, in which the client again looks for 150 consecutive clock cycles of the high data line.

The client implementation of the present invention for host-based sleep wakeup is very similar to the initial startup situation, except that the clock rate does not have to start at 1 Mbps, as described above. Conversely, the clock rate can be set to resume when the communication link goes to sleep, regardless of the previous rate used. If the host starts the transmission of the above strobe signal, the client should be able to count again at least 150 continuous clock cycles of the high data line, followed by at least 50 continuous clock cycles of the low data line. Once these two conditions are met, the client can start searching for unique characters.

The client implementation scheme of the present invention for the client-side wake-up based on sleep It is similar to host-based wakeup, except that it is activated by the client driving the data line. The client can asynchronously drive the clockless data line to wake up the host device. Once the host recognizes that the data line is driven high by the client, it can start the wake-up sequence. The client can count the number of clock cycles generated by the host that is starting the wake-up procedure or is in the process of the wake-up procedure. Once the client counts 70 consecutive clock cycles of the high data line, it can stop driving the high data line. At this time, the host should also have driven the data line high. The user terminal can then count another 80 high data line continuous clock cycles in order to reach 150 high data line clock cycles, and then can search for 50 low data line clock cycles. Once these three conditions are met, the client can start looking for unique characters.

The advantage of this new wake-up processing implementation is that it does not require time measurement devices. Regardless of whether it is an oscillator or a capacitor discharge circuit or other such well-known devices, the user terminal no longer needs such external devices to determine the starting conditions. When the controller, counter, etc. are implemented on the user-end device board, this can save cost and circuit area. Although this is not equally beneficial to the client, for the host, this technology should also potentially simplify the host according to the very high density logic (VHDL) used in the core circuit. The power consumption of using data and strobe lines as wake-up notification and measurement sources is also lower, because the core components wait for host-based wake-up without running external circuits.

The number of cycles or clock cycles used is exemplary, and those skilled in the art should understand that other cycles can be used.

The advantage of this new wake-up processing implementation is that it does not require time measurement devices. Regardless of whether it is an oscillator or a capacitor discharge circuit or other such well-known devices, the user terminal no longer needs such external devices to determine the starting conditions. On the user side When the controller, counter, etc. are implemented on the device board, this can save cost and circuit area. Although this is not equally beneficial to the client, for the host, this technology should also potentially simplify the host according to the very high density logic (VHDL) used in the core circuit. The power consumption of using data and strobe lines as wake-up notification and measurement sources is also lower, because the core components wait for host-based wake-up without running external circuits.

To illustrate and explain the operation of this new technology, FIGS. 68A, 68B, and 68C show the timing of MDDI_Data0, MDDI_Stb and various operations relative to the clock cycle.

Figure 68A illustrates an example of the processing steps used for a typical host without contention to initiate a wake-up, in which the letters A, B, C, D, E, F, and G are again used to mark events for ease of illustration. When the host sends a link close packet to the client device to notify it that the link will transition to a low-power sleep state, the procedure starts at point A. In the next step, at point B, the host toggles MDDI_Stb for approximately 64 cycles (or as required by the system design), so that the user can stop the MDDI_Stb toggle (which stops the recovery clock in the client device) Complete processing. Initially, the host also sets MDDI_Data0 to a logic zero level, and then disables MDDI_Data0 output within the range of 16 to 48 cycles (usually including output disable propagation delay) after CRC. After 48 cycles after the CRC and some time before the next stage (C), it may be necessary to put the high-speed receivers used for MDDI_Data0 and MDDI_Stb in the user terminal into a low power state.

By disabling the MDDI_Data0 and MDDI_Stb drivers and placing the host controller in a low-power sleep state, the host enters sleep at point or step C. You can also set the MDDI_Stb driver to the logic zero level (using a high impedance bias network Road) or continue bi-state triggering during sleep as needed. The user end is also in a low-power level sleep state.

After a period of time, at point D, the host starts the link restart sequence by activating the MDDI_Data0 and MDDI_Stb driver outputs. The host drives MDDI_Data0 to a logic level and MDDI_Stb to a logic zero level. The time should allow the driver to fully activate its individual outputs. After the outputs reach the desired logic level, the host usually waits about 200 nanoseconds before driving the pulse on MDDI_Stb. This can provide the user with time to prepare to receive.

After the host driver is activated and MDDI_Data0 is driven to a logic level, the host starts to toggle MDDI_Stb with a duration of 150 MDDI_Stb cycles, as shown by point E. The host drives MDDI_Data0 to the logic zero level for 50 cycles. As shown in point F, after MDDI_Data0 is at the logic zero level for 40 MDDI_Stb cycles, the client starts to search for the sub-frame header packet. The host starts to send data on the forward link by sending sub-frame header packets, as shown by point G.

Figure 68B illustrates an example of the processing steps used for a typical host without contention to initiate a wake-up, where the letters A, B, C, D, E, F, G, H, and I are again used to mark events for ease of illustration. As before, when the host transmits a link closure packet to notify the user that the link will transition to a low power state, the procedure starts at point A.

At point B, the host toggles MDDI_Stb for approximately 64 cycles (or as required by the system design), so that the client completes the processing before stopping the dual toggle of MDDI_Stb (which stops the recovery clock in the client device). Initially, the host also sets MDDI_Data0 to logic zero level, and then disables 16 to 48 after CRC MDDI_Data0 output within the period (usually including output disable propagation delay). After 48 cycles after the CRC and some time before the next stage (C), it may be necessary to put the high-speed receivers used for MDDI_Data0 and MDDI_Stb in the user terminal into a low power state.

By disabling the MDDI_Data0 and MDDI_Stb drivers and placing the host controller in a low-power sleep state, the host enters sleep at point or step C. It is also possible to set the MDDI_Stb driver to the logic zero level (using a high-impedance bias network) or continue bi-state triggering during sleep as needed. The user end is also in a low-power level sleep state.

After a period of time, by activating the MDDI_Stb receiver and the offset in the MDDI_Stb receiver at the same time to ensure that the state of the received version of MDDI_Stb before the host activates its MDDI_Stb driver is at the logic zero level in the user terminal, the user End at point D to start the link restart sequence. The user end may need to activate the offset slightly before activating the receiver to ensure the reception of a valid differential signal and disable error signals as needed. The user terminal activates the MDDI_Data0 driver on time when driving the MDDI_Data0 line to a logic bit.

In about 1 msec, at point E, the host recognizes the service request pulse from the client, and the host starts the link restart sequence by activating the MDDI_Data0 and MDDI_Stb driver outputs. The host drives MDDI_Data0 to a logic level and MDDI_Stb to a logic zero level. The time should allow the driver to fully activate its individual outputs. After the outputs reach the desired logic level, the host usually waits about 200 nanoseconds before driving the pulse on MDDI_Stb. This can provide the user with time to prepare to receive.

After the host driver is activated and MDDI_Data0 is driven to a logical level, the host starts to output the pulse on MDDI_Stb, the duration is 150 MDDI_Stb cycles, as shown by point F. When the UE recognizes the first pulse on MDDI_Stb, it disables the offset in its MDDI_Stb receiver. The user side continues to drive MDDI_Data0 to a logical level of 70 MDDI_Stb cycles, and disables its MDDI_Data0 driver at point G.

As shown by points G and H, the host drives MDDI_Data0 to the logic zero level for 50 cycles. After MDDI_Data0 is at the logic zero level for 40 MDDI_Stb cycles, the client starts to search for the sub-frame header packet. The host starts to send data on the forward link by sending sub-frame header packets, as shown in point I.

FIG. 68C illustrates an example of the processing steps of a typical host that competes with the client to initiate wake-up, that is, the client also wants to wake up the link. For ease of illustration, the letters A, B, C, D, E, F, G, H, and I are used again to mark events. As before, when the host sends a link closure packet to notify the user that the link will transition to a low power state, the program starts at point A and enters point B, where the dual-state trigger MDDI_Stb is about 64 cycles (or according to system design requirements) ) So that the client completes the processing, and then enters point C, where the host enters the low-power sleep state by disabling the MDDI_Data0 and MDDI_Stb drivers and placing the host controller in the low-power sleep state. After a period of time, at point D, the host starts the link restart sequence by activating the MDDI_Data0 and MDDI_Stb driver outputs, and starts to toggle MDDI_Stb with a duration of 150 MDDI_Stb cycles, as shown at point E.

At most 70 MDDI_Stb cycles after point E, that is, at point F, the user side has not yet realized that the host has driven MDDI_Data0 to a logical level, so the user side is also Drive MDDI_Data0 to a logic level. This situation occurs because the client needs to request service but does not realize that the host it is trying to communicate with has started the link restart sequence. At point G, the user terminal stops driving MDDI_Data0, and puts its driver in a high impedance state by disabling the output. The host continues to drive MDDI_Data0 to the logic level for 80 additional cycles.

The host drives MDDI_Data0 to the logic zero level for 50 cycles. As shown by point H, after MDDI_Data0 is at the logic zero level for 40 MDDI_Stb cycles, the client starts to search for the sub-frame header packet. The host starts to send data on the forward link by sending sub-frame header packets, as shown in point I.

VI. Interface electrical specifications

In an exemplary embodiment, a data strobe signal or DATA-STB format is used to encode data in a non-return-to-zero (NRZ) format, which makes it possible to embed clock information in the data and strobe signals middle. The clock can be restored without a complicated phase-locked loop circuit. The data is carried on a two-way differential link, which is generally implemented using wired cables, but it can also be implemented using other conductors, printed wires or transmission components, as previously explained. The strobe signal (STB) is carried on a unidirectional link driven only by the host. Whenever there is a back-to-back state 0 or 1, which remains the same on the data line or signal, the strobe signal will toggle the value (0 or 1).

Figure 40 shows an example of how to use DATA-STB encoding to send a data sequence (for example, the bit "1110001011") in graphical form. In FIG. 40, the DATA signal 4002 is displayed on the top line of the signal timing diagram, and the STB signal 4004 is displayed on the second line, each time being properly aligned (common starting point). As time goes by, when the state of the DATA line 4002 (signal) changes, the STB line 4004 (signal) The previous state is maintained, therefore, the first "1" state of the DATA signal is related to the first "0" state of the STB signal (its starting value). However, if or when the state and level of the DATA signal do not change, the STB signal toggles to the opposite state or "1" in this example, as shown in Figure 40, where DATA provides another "1" value . That is, there is one and only one transition per bit period between DATA and STB. Therefore, the STB signal changes again, this time to "0", because the DATA signal is still at "1", and when the DATA signal changes to "0", the STB signal maintains this level or value. When the DATA signal is still at "1", the STB signal toggles to the opposite state or "1" in this example, and so on, as the DATA signal changes or maintains the level or value.

After receiving these signals, a mutually exclusive OR (XOR) operation is performed on the DATA and STB signals to generate a clock signal 4006, which is shown at the bottom of the timing diagram for comparison with ideal data and strobe signals. Figure 41 shows an example of a circuit for generating DATA and STB output OR signals from the input data at the host, and then recovering or retrieving the data from the DATA and STB signals at the user end.

In FIG. 41, the transmitting part 4100 is used to generate and send the original DATA and STB signals on the intermediate signal path 4102, and the receiving part 4120 is used to receive these signals and recover the data. As shown in Figure 41, in order to transmit data from the host to the user, the DATA signal is combined with the clock signal used for the trigger circuit to input two D-type flip-flop circuit elements 4104 and 4106. Then two differential line drivers 4108 and 4110 (voltage mode) are used to separate the outputs (Q) of the two flip-flop circuits into differential signal pairs MDDI_Data0+, MDDI_Data0- and MDDI_Stb+, MDDI_Stb-, respectively. Connect a three-input mutual Reject NOR (XNOR) gate, circuit or logic element 4112 to receive the DATA and output of the two flip-flops, and generate an output to provide the data input of the second flip-flop, the second flip-flop in turn Generate MDDI_Stb+, MDDI_Stb- signals. For convenience, the XNOR gate has a reversing magnetic bubble to indicate that it is effectively reversing the Q output of the flip-flop that generates the strobe signal.

In the receiving part 4120 of FIG. 41, two differential line receivers 4122 and 4124 each receive MDDI_Data0+, MDDI_Data0-, MDDI_Stb+, MDDI_Stb- signals, and generate signal outputs from these differential signals. The output of these amplifiers is then input to each input of a two-input mutually exclusive OR (XOR) gate, circuit or logic element 4126, and the XOR gate 4126 generates a clock signal. The clock signal is used to trigger each of the two D-type flip-flop circuits 4128 and 4130, which receive a delayed form of DATA signal through the delay element 4132, and a flip-flop circuit (4128) generates the data "0" value , And another flip-flop circuit (4130) generates the data "1" value. The clock also has an independent output from the XOR logic. Since the clock information is distributed between the DATA and STB lines, the state transition of any signal will not be faster than half of the clock rate. Since the clock is reproduced by processing the DATA and STB signals using mutually exclusive OR, the system can effectively tolerate twice the input signal compared with the case where the clock signal is directly transmitted via a single dedicated data line. The amount of skew from the clock.

The MDDI_Data pair, MDDI_Stb+ and MDDI_Stb- signals are operated in differential mode to minimize the negative influence of noise. Each part of the differential signal path is terminated at the source, and the characteristics of the cable or conductor One half of the impedance is used to transmit the signal. The MDDI_Data pair ends at the source and ends at the host and the client. Since only one of the two drivers is active at a given time, the terminal continues to exist at the source of the transmission link. The MDDI_Stb+ and MDDI_Stb- signals are only driven by the host.

Figure 42 shows an exemplary component configuration, which can be used to transmit signal drivers, receivers and terminals as part of the creative MDD interface, and the corresponding MDDI_Data and MDDI_Stb direct current (DC) electrical specifications are shown in Table VII middle. This exemplary interface uses low voltage sensing, here 200 mV, where the power swing is less than 1 volt and the power consumption is very low.

<tables><img file="TWI345404B_D0014.tif" /></tables>

Table VIII illustrates the electrical parameters and characteristics of the differential line driver and line receiver. In terms of function, the driver transfers the logic level on the input directly to a positive output, and transfers the inverse of the input to a negative output. The delay from input to output just matches the differential line of the differential drive. In most implementations, the voltage swing on the output is smaller than the voltage swing on the input, thereby minimizing power consumption and electromagnetic emissions. Table VIII shows that the minimum voltage swing is about 0.5V. However, those skilled in the art should understand that other values can be used, and the inventor considers smaller values in some specific embodiments, which depend on design constraints.

The differential line receiver has the same characteristics as the high-speed voltage comparator. In Figure 41, the input without magnetic bubbles is a positive input, and the input with magnetic bubbles is a negative input. If (Vinput+)-(Vinput-) is greater than zero, the output is logic one. Another description method is that a differential amplifier has a very large (almost infinite) gain, and its output is clamped between logic 0 and 1 voltage levels.

The delay skew between different pairs should be minimized in order to operate the differential transmission system at the highest potential speed.

In FIG. 42, the host controller 4202 and the client or display controller 4204 are shown transmitting packets on the communication link 4206. The host controller uses a series of three drivers 4210, 4212, and 4214 to receive the host DATA and STB signals that need to be transmitted, and receive the client Data signals that need to be transmitted. The driver responsible for the path of the host DATA uses an actuation signal input to allow the communication link to be initiated only when transmission from the host to the user terminal is generally required. Since the STB signal is formed as part of the data transmission, no additional actuation signal is required for the driver (4212). Output points of each DATA and STB driver Do not connect to terminal impedance or resistors 4216a, 4216b, 4216c, and 4216d.

The terminating resistors 4216a and 4216b are also used as the impedance on the input of the client receiver 4220 for STB signal processing, and the additional terminating resistors 4216e and 4216f are placed in series with the resistors 4216c and 4216d on the client data processing receiver 4222. Enter it. The sixth driver 4226 in the client controller is used to prepare the data signal transmitted from the client to the host, and the driver 4214 processes the data transmitted to the host for processing through the terminating resistors 4216c and 4216d at the input.

Two additional resistors 4218a and 4218b are respectively placed between the terminating resistor and ground and voltage source 4220 as part of the sleep control discussed elsewhere. The voltage source is used to drive the transmission line to the aforementioned high or low level to manage the data flow.

The above drivers and impedances can be formed as discrete components or as part of a circuit module, or application specific integrated circuit (ASIC), which serves as a more cost-effective encoder or decoder solution.

It can be easily seen that the power supply uses signals marked HOST_Pwr and HOST_Gnd to be transmitted from the host device to the client device or display via a pair of conductors. The HOST_Gnd part of the signal serves as a reference ground and power supply return path or a signal for the display device. The HOST_Pwr signal serves as a power supply for the display device, which is driven by the host device. In an exemplary configuration, for low power applications, the display device is allowed to draw up to 500 mA. The HOST_Pwr signal can be provided from a portable power source, such as (but not limited to) resident in the host device The HOST_Pwr signal can be in the range from 3.2 to 4.3 volts relative to HOST_Gnd.

VII. Timing characteristics

<b>A. Overview</b>

Figure 43 illustrates the steps and signal levels used by the client to ensure the service from the host and the host to provide this service. In FIG. 43, the first part of the signal shows a link close packet transmitted from the host, and then a high-impedance bias circuit is used to drive the data line to a logic zero state. The client display or host whose drive has been disabled is not sending any data. A series of strobe pulses for the MDDI_Stb signal line can be seen at the bottom, because MDDI_Stb is active during the link closure packet. Once the host drives the bias circuit and logic to zero, the packet ends and the logic level changes to zero, and the MDDI_Stb signal line also changes to the logic zero level. This represents the last signal transmission from the host or the termination of the service, and may have occurred at any time in the past, including the status of the signal to show the previous stop of the service and the signal before the start of the service. If necessary, for example, a signal can be sent to reset the communication link to the correct state without the "known" previous communication that has been adopted by the host device.

As shown in Figure 43, the signal output from the user terminal is initially set at the logic zero level. In other words, the user terminal output is at high impedance and the driver is disabled. When a service is requested, the client activates its driver and transmits a service request to the host, which drives the line to a logical level for a period of time (assigned to the service). A certain amount of time elapsed or may take a certain amount of time before the host detects the request, called t_host-detectAfter that, the host responds with a link activation sequence by driving the signal to a logic level. At this time, the client resolves the request and disables it The service request driver makes the output line from the user end enter the logic zero level again. During this time, the MDDI_Stb signal is at a logic zero level.

The host drives the host data output to the "1" level for one cycle (called t_restart-high), then the host drives the logic level to zero and starts MDDI_Stb for one cycle (called t_restart-low), then the first forward traffic starts from the sub-frame header packet, and then forward traffic packets are transmitted. MDDI_Stb signal at t_restart-lowThe cycle and subsequent sub-frame header packets are active.

Table VIII shows the representative time for the length of the various periods mentioned above, and the relationship between the exemplary minimum and maximum data rates, where:<maths><img file="TWI345404B_D0015.tif" /></maths>

<tables><img file="TWI345404B_D0016.tif" /></tables><tables><img file="TWI345404B_D0017.tif" /></tables>

Those skilled in the art should easily understand that the functions of the individual components illustrated in FIGS. 41 and 42 are well known, and the functions of the components in FIG. 42 are confirmed by the timing diagram of FIG. 43. Figure 41 omits the details of the serial terminal and sleep resistor shown in Figure 42 because the information is not necessary to explain how to perform data strobe coding and recover the clock from it.

<b>B. Data strobe timing forward link</b>

Table IX shows the switching characteristics of the data on the forward link from the host driver. Table IX shows in tabular form the minimum and maximum time required for certain signal transitions versus the typical time. For example, the typical length of time (called t_{tdd-(host-output)}) Is t_tbit, And the minimum time is about t_tbit-0.5 nsec., the maximum time is about t_tbit+0.5 nsec.. Figure 44 illustrates the relative interval between transitions on Data0, other data lines (DataX), and strobe lines (Stb), which shows Data0 to strobe, strobe to strobe, strobe to Data0, Data0 to non-Data0, non Data0 to non-Data0, non-Data0 to strobed, and strobed to non-Data0 transitions, which are respectively referred to as t_{tds-(host-output)}, T_{tss-(host-output)}, T_{tsd-(host-output)}, T_{tddx-(host-output)}, T_{tdxdx-(host-output)}, T_tdxs-_{(host-output)}And t_{tsdx-(host-output)}。

<tables><img file="TWI345404B_D0018.tif" /></tables>

Table X shows the typical MDDI timing requirements of the client receiver input for the same signal used to transmit data on the forward link. Since the discussion is about the same signal but with a time delay, there is no need for a new diagram to explain the signal characteristics or the meaning of individual marks, and those skilled in the art will understand it.

<tables><img file="TWI345404B_D0019.tif" /></tables><tables><img file="TWI345404B_D0020.tif" /></tables>

Figures 45 and 46 show the delay in response, which can occur when the host disables or activates the host driver, respectively. In the case that the host transmits certain packets (such as reverse link encapsulation packets or round-trip delay measurement packets, etc.), the host is transmitting the required packets (such as the transmitted parameter CRC and strobe pair shown in Figure 45). Disable the line driver after standard and all-zero packet, etc.). However, as shown in Figure 45, the line state does not need to be switched from "0" to a higher value in real time. Although this real-time switching can be achieved by using some control or existing circuit components, the cost is called host driver deactivation. Delay (Driver Disable Delay) period of time to respond. Although it can actually happen immediately, so that the length of the time period is 0 nanoseconds (nsec.), it can be easily extended to a certain longer period, where 10 nsec. is the ideal maximum period length, which appears in protection Time 1 or turn to 1 during the packet cycle.

Please refer to FIG. 46. When the host driver is activated to transmit a packet such as a reverse link encapsulation packet or a round-trip delay measurement packet, the signal level undergoes a change. Here, after guard time 2 or turn to 2 packet period, the host driver is activated and starts to drive one level (here "0"), which is close to or within a time period called the host driver activation delay period When this value is reached, the time period occurs during the re-activation period of the driver that precedes the transmission of the first packet.

A similar process occurs in the driver and signal transmission of the client device (here, the display). Table XI below shows the general guidelines for the length of these periods and their individual relationships.

<tables><img file="TWI345404B_D0021.tif" /></tables>

<b>C. Data-strobe timing reverse link</b>

Figures 47 and 48 show the switching characteristics and timing relationships of the data and strobe signals used to output the transmission data from the client driver on the reverse link. The following describes the typical time for a particular signal transition. Figure 47 illustrates the relationship between the data transmission timing and the host receiver input between the front and back edges of the strobe pulse. That is, it is called tsu-sr for the setting time of the rising or leading edge of the strobe signal, and tsu-sf is called the setting time for the trailing or falling edge of the strobe signal. The typical time length of the set period is about 8 nanoseconds minimum.

Figure 48 illustrates the corresponding user-side output delay formed by the switching characteristics and reverse data timing. As can be seen in Figure 48, the relationship between the timing of the transmitted data and the front and back edges of the strobe explains the delay caused. That is, tpd-sr is called the propagation delay between the rising or leading edge of the strobe signal and the data (effective), and tPd-sf is called the propagation delay between the data and the trailing or falling edge of the strobe signal. The typical maximum time length of these propagation delay periods is on the order of about 8 nanoseconds.

VIII. Link control implementation plan (link controller operation)

<b>A. State machine packet processor</b>

Packets transmitted via the MDDI link are dispatched very quickly, at a rate Usually at the level of about 300 Mbps or higher, such as 400 Mbps, but it can of course cope with lower speeds as needed. For current commercial (economical) general-purpose microprocessors or the like, the speed of this type of bus or transmission link is too large to be controlled. Therefore, an actual implementation of this type of signal transmission is to use a programmable state machine to analyze the input packet stream to generate a packet, and then transmit or redirect it to the desired appropriate audio-video subsystem. Such devices are well known and use circuits generally dedicated to a limited number of operations, functions, or states to achieve the desired high-speed or extremely high-speed operation.

General-purpose controllers, processors, or processing elements can be used to more appropriately act on or manipulate certain information, such as control or status packets, which have lower speed requirements. After receiving these packets (control, status, or other predefined packets), the state machine should pass them to the general-purpose processor through a data buffer or similar processing components, so that they can act on these packets to provide all The result (effect) is needed, and the audio and video packets are transmitted to their corresponding destinations. If future microprocessors or other general-purpose controllers, processors, or processing components can achieve higher data rate processing capabilities, software control of such devices is usually used as a program stored on storage components or media. Implement the state or state machine discussed below.

In some specific embodiments, by using the processing power or available excess cycles of a microprocessor (CPU) in computer applications, or controllers, processors, digital signal processors (DSP), and dedicated circuits Or the ASIC used in wireless devices can realize general-purpose processor functions, which is very similar to the way that certain modems or graphics processors use the processing power of the CPU used in computers to perform certain functions and reduce hardware complexity and cost. like. However, this period sharing or use can negatively affect the processing speed, timing, or the overall operation of such components. Therefore, in many applications, it is better to use dedicated circuits or components for this general processing.

In order to view the image data on the display (microdisplay), or to reliably receive all the data packets sent by the host device, the display signal processing is synchronized with the timing of the forward link channel. That is, in order to perform correct signal processing, the signals arriving at the display and the display circuit need to be substantially synchronized in time. The illustration of FIG. 49 provides a high-level diagram of the state achieved by the signal processing step or the method that can implement this synchronization. In Figure 49, the possible forward link synchronization "states" shown for the state machine 4900 are classified into an asynchronous frame state 4904, two acquisition synchronization states 4902 and 4906, and three synchronization states 4908, 4910, and 4912.

As shown in the start step or state 4902, the display or client (such as a presentation device, etc.) starts in the preselected "out of sync" state, and searches for a unique word in the detected first subframe header packet Yuan. It should be noted that this unsynchronized state represents the lowest communication setting or "back drop" setting, in which the first type interface is selected. If the unique character is found during the search, the display will save the subframe length field. For the processing on this first frame, no CRC bit check is performed or until synchronization is obtained. If the length of the sub-frame is zero, the synchronization state processing accordingly proceeds to a state 4904, where it is marked as the "asynchronous frame" state, indicating that synchronization has not been achieved. In Figure 49, this step in the process is marked as having cond 3 or condition 3 encountered. In addition, if the frame length is greater than zero, the synchronization state processing enters state 4906, where the interface state is set to "find a synchronization frame". This step will be processed in Figure 49 The step is marked as cond 5 or condition 5 encountered. In addition, if the state machine finds a frame header packet with a frame length greater than zero and a good CRC decision, the processing enters the "find a synchronization frame" state. In Figure 49, this line is marked as cond 6 or condition 6 encountered.

In every situation except the "no synchronization" state, when a unique character is detected and a good CRC result is determined for the sub-frame header packet, and the sub-frame length is greater than zero, the interface state changes to " Synchronizing" status 4908. In Figure 49, this step in the process is marked as having cond 1 or condition 1 encountered. On the other hand, if the unique character or the CRC in the sub-frame header packet is incorrect, the synchronization state processing enters or returns to the interface state 4902 of the "no synchronization frame" state. In the state diagram of Figure 49, this part of the process is marked as cond 2 or condition 2 encountered.

<b>B. Get time for synchronization</b>

The interface can be configured to tolerate a certain number of "synchronization errors" before deciding that the synchronization has been lost and returning to the "no synchronization frame" state. In Figure 49, once the state machine has reached the "synchronizing state" and no errors are found, it will continue to encounter the cond 1 result and remain in the "synchronizing" state. However, once a cond 2 result is detected, the process changes the state to the "a synchronization error" state 4910. At this point, if the processing results in detecting another cond 1 result, the state machine returns to the "synchronizing" state, otherwise it encounters another cond 2 result and moves to the "second synchronization error" state 4912. In addition, if cond 1 appears, the process returns the state machine to the "synchronizing" state. Otherwise, if another cond 2 is encountered, the state machine will return to the "out of sync" state. It can also be understood that if the interface encounters a "link shutdown packet", this will cause link termination data. The material is transmitted and returns to the "no sync frame" state because there is no frame synchronized with it; in the state machine of Figure 49, this situation is called cond 4 or condition 4 encountered.

It should be understood that there may be repeated "miscopy" of the unique character, which may appear in a fixed position in the sub-frame. In this case, the state machine is unlikely to be synchronized with the sub-frame, because to make the MDD interface processing enter the "synchronizing" state, the CRC on the header packet of the sub-frame must also be valid during processing.

The length of the sub-frame in the sub-frame header packet can be set to zero to instruct the host to send only one sub-frame before closing the link, and the MDD interface is placed or configured in an idle sleep state. In this case, the display must receive the packet via the forward link immediately after detecting the sub-frame header packet, because only a single sub-frame is transmitted before the link transitions to the idle state. In a normal or typical operation, the sub-frame length is non-zero and the display only processes forward link packets, and the interface system is in the states shown in FIG. 49 as the "synchronizing" state.

The time required for the display to synchronize with the forward link signal varies according to the size of the sub-frame and the forward link data rate. When the size of the sub-frame is large, it is more likely to detect the "erroneous copy" of the unique character that is part of the randomized (or more randomized) data in the forward link. At the same time, the ability to recover from error detection is low, and if the forward link data rate is slow, it takes longer to recover.

<b>C. Initialization</b>

As mentioned earlier, at the time of "startup", the host configures the forward link to the required Or the ideal minimum data rate is 1 Mbps or below, and the sub-frame length and media frame rate are appropriately configured for a given application. That is, both the forward link and the reverse link use the Type 1 interface to start operation. Generally, these parameters are only used temporarily, and the host determines the capabilities or desired configuration used by the client display (or other types of client devices). The host first sends or transmits a sub-frame header packet via the forward link, and then sends a reverse link encapsulation packet. The request flag bit "0" is set to the value one (1), thereby requesting The display or client responds to display the capability packet. Once the display is synchronized on the forward link (or using the forward link), it transmits display capability packets and display request and status packets via the reverse link or channel.

The host detects the content of the display capability packet to determine how to reconfigure the link to achieve the best or desired level of performance. The host detects the protocol version and minimum protocol version fields to confirm that the protocol versions used by the host and the display are compatible with each other. The protocol version is generally maintained as the first two parameters of the display capability packet, so that even when other elements of the protocol may be incompatible or cannot be fully understood as compatible, the compatibility can still be determined.

<b>D. CRC processing</b>

For all packet types, the packet processor state machine will ensure that the CRC checker is properly or correctly controlled. When the CRC comparison results in the detection of one or more errors, it will also increment the CRC error counter, and it will reset the CRC counter when each sub-frame starts processing.

<b>E. Alternative synchronization loss check</b>

Although the above steps or state series can produce higher data rates or throughput speeds, applicants have found that the client is used to declare synchronization with the host There is an alternative configuration or condition change that can be used to effectively achieve higher data rates or throughput. This new inventive specific embodiment has the same basic structure, but the conditions for changing the state have changed. A new counter is additionally implemented to help check the synchronization of the sub-frames. The steps and conditions are based on the procedure shown in Figure 63, which illustrates a series of states and conditions used to establish the operation of the method or state machine. For clarity, only the "Get Sync Status" and "Syncing Status" sections are shown. In addition, since the result state (that is, the state machine itself) is substantially the same, the same numbers are used for these states. However, the conditions used to change the state (and state machine operation) are slightly changed, so for the sake of clarity between the two figures, the conditions are renumbered (1, 2, 3, 4, 5 and 6 to 61, 62, 63, 64 and 65) to facilitate the identification of differences. Since asynchronous frames are not considered in this discussion, a state (4904) and condition (6) are no longer used in this figure.

In FIG. 63, the system or client (for display or presentation) is started together with the state machine 5000 in the preselected "no synchronization" state 4902, as shown in FIG. 49. The first state change from the no-synchronization state 4902 change state is the condition 64, which is the discovery of the synchronization pattern. Assuming that the CRC of the sub-frame header is also transmitted on this packet (condition 61 is satisfied), the state of the packet processor state machine can be changed to the state 4908 in synchronization. A synchronization error, condition 62, will cause the state machine to transition to state 4910, and the second synchronization error will transition to state 4912. However, it has been found that any CRC failure of the MDDI packet will cause the state machine to move out of the synchronization state 4908 to a synchronization error state 4910. Another CRC failure of any MDDI packet will result in moving to two synchronization failure states 4912. Using the correct CRC value to decode the packet will cause the state machine to return to the synchronization state 4908.

The changed system uses the CRC value or decision for "each" packet. That is, for each packet, let the state machine check the CRC value to determine the synchronization loss, instead of just observing the sub-frame header packet. In this configuration or processing, the synchronization loss is not determined by using unique characters and only the sub-frame header CRC value.

This new interface implementation allows the MDD interface link to identify synchronization failures more quickly, and thus recover from failures more quickly.

To make this system more robust, the client should also increase or use the sub-frame counter. Then when the unique character is expected to arrive or appear in the signal, the user terminal checks whether the unique character exists. If the unique character does not appear at the correct time, the client can recognize that a synchronization failure has occurred more quickly, without having to wait for several (here, three) packet times or cycles that are greater than the length of the subframe. If the test of the unique character indicates that it does not exist, in other words, the timing is incorrect, the user terminal can immediately declare the link synchronization loss and move to the asynchronous state. The process of checking whether the correct unique character exists or not adds a condition 65 (cond 5) to the state machine, saying that the unique character is incorrect. If a sub-frame packet is expected to be received on the client and the packet does not match, the client can immediately enter the unsynchronized state 4902, thereby saving waiting for multiple synchronization errors (condition 62; generally in the cross state 4910 and 4912 Time encountered).

This change uses an additional counter or the counting function in the client core to count the length of the sub-frame. In a specific embodiment, the countdown function is used, and if the counter has expired, the transmission of any packet currently being processed is interrupted to check the unique character of the subframe. Alternatively, the counter can count up and compare the count with the required maximum value or a specific required value. Check the current packet at this point. This process protects the client from using an abnormally long packet length to decode incorrectly received packets on the client. If the sub-frame length counter needs to interrupt some other packet being decoded, it can determine a synchronization loss, because any packet should not cross the sub-frame boundary.

IX. Packet processing

For each type of packet received by the state machine, it performs specific processing steps or series of steps to implement the interface operation. The forward link packet is generally processed according to the exemplary processing listed in Table XII below.

<tables><img file="TWI345404B_D0022.tif" /></tables><tables><img file="TWI345404B_D0023.tif" /></tables><tables><img file="TWI345404B_D0024.tif" /></tables>

X. Reduce reverse link data rate

The inventor has observed that certain parameters for the host link controller can be adjusted or configured in a certain way to achieve the maximum or better (proportional) reverse link data rate, which is very desirable. For example, during the time period used to transmit the reverse data packet field of the reverse link encapsulation packet, the MDDI_Stb signal pair toggles to establish a periodic data clock, which is the forward link data Half the rate. This happens because the MDDI_Stb signal generated by the host link controller corresponds to the MDDI_Data0 signal, which seems to be transmitting all zeros. The MDDI_Stb signal is transmitted from the host to the client, and the MDDI_Stb signal at the client is used to generate a clock signal for transmitting reverse link data from the display, and the reverse data combined with the clock signal is sent back to the host. Figure 50 illustrates the typical amount of delay encountered in signal transmission and processing on the forward and reverse paths in a system using MDDI. In Figure 50, a series of delay values are displayed near the processing part of Stb+/- generation, cable transmission to display, display receiver, clock generation, signal clock, Data0+/- generation, cable transmission to host and host receiver level. 1.5 nsec., 8.0 nsec., 2.5 nsec., 2.0 nsec., 1.0 nsec., 1.5 nsec., 8.0 nsec. and 2.5 nsec.

Depending on the forward link data rate and signal processing delay encountered, the completion of this "back and forth" effect or this set of events may require multiple cycles on the MDDI_Stb signal, which results in consuming an undesirable amount of time or cycles. To overcome this problem, a reverse rate divisor (Reverse Rate Divisor) can enable the bit time on the reverse link to span multiple periods of the MDDI_Stb signal. This means that the reverse link data rate is less than the forward link data rate.

It should be noted that it depends on each specific host-client system or In hardware, the actual length of the signal delay through the interface can be different. Although it is not necessary, by using the round-trip delay measurement packet to measure the actual delay in the system, the reverse rate divisor can be set to an optimal value, and generally the performance of each system can be better.

By allowing the host to send a round-trip delay measurement packet to the display, the round-trip delay can be measured. In response to this packet, the display sends back a sequence to the host within or during a preselected measurement window (called the measurement period field) in the packet. The detailed timing of this measurement has been explained previously. The round-trip delay is used to determine the sampling rate at which reverse link data can be safely sampled.

Round-trip delay measurement includes determining, detecting, or counting forward link data between the beginning of the measurement period (Measurement Period) field and the beginning of the time period when the host receives the 0xff, 0xff, and 0x00 response sequence from the client. The number of clock intervals. Please note that the measurement count may only start to increment after a small segment of the forward link clock cycle has passed since the response was received from the user end. If this unmodified value is used to calculate the reverse rate divisor, it may cause bit errors on the reverse link due to unreliable data sampling. An example of this situation is illustrated in FIG. 51, in which the signals representing MDDI_Data located in the host, MDDI_Stb located in the host, the clock of the forward link data inside the host, and the delay count are illustrated graphically. In Figure 51, a small portion of the forward link clock cycle before the delay count is incremented from 6 to 7 receives the response sequence from the display. If the delay is assumed to be 6, the host will sample the reverse data after a bit transition or possibly in the middle of a bit transition. This may cause incorrect sampling at the host. For this reason, the measurement delay should usually be incremented by one before it is used to calculate the reverse rate divisor.

The reverse rate divisor is the number of MDDI_Stb cycles that the host should wait before sampling reverse link data. Since the cycle rate of MDDI_Stb is half of the forward link rate, the corrected round-trip delay measurement needs to be divided by 2, and then rounded to the next integer. Express this relationship as a system of equations:<maths><img file="TWI345404B_D0025.tif" /></maths>

For the given example, this becomes:<maths><img file="TWI345404B_D0026.tif" /></maths>

If the round-trip delay used in this example is measured as 7 instead of 6, the reverse rate divisor will also be equal to 4.

The host samples the reverse link data on the rising edge of the reverse link clock (Reverse Link Clock). Both the host and the client (display) have counters or similar well-known circuits or devices to generate the reverse link clock. The counters are initialized so that the first rising edge of the reverse link clock appears at the beginning of the first bit in the reverse link packet field of the reverse link encapsulated packet. Figure 52 uses the example given below to illustrate this situation. The counter is incremented at each rising edge of the MDDI_Stb signal, and the count number that occurs until the count wraps around is set by the reverse rate divisor parameter in the reverse link encapsulation packet. Since the MDDI_Stb signal toggles at half of the forward link rate, the reverse link rate is half of the forward link rate divided by the reverse rate divisor. For example, if the forward link rate is 200 Mbps and the reverse rate divisor is 4, the reverse link data rate is expressed as:<maths><img file="TWI345404B_D0027.tif" /></maths>

Figure 52 shows an example showing the timing of the MDDI_Data0 and MDDI_Stb signal lines in the reverse link encapsulation packet, which is used for illustration The packet parameters have the following values: packet length=1024(0x0400) turn 1 length=1 packet type=65(0x41) turn 2 length=1 reverse link flag=0 reverse rate divisor=2 parameter CRC =0xdb43 All zeros are 0x00

The packet data between the packet length and the parameter CRC field are: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00,...

The first reverse link packet returned from the display is a display request and status packet with a packet length of 7 and a packet type of 70. This packet starts with the byte value 0x07, 0x00, 0x46,... and so on. However, only the first byte (0x07) can be seen in Figure 52. In the figure, the time offset of the first reverse link packet is about one reverse link clock cycle to illustrate the actual reverse link delay. The dashed trace shows an ideal waveform in which the round-trip delay from the host to the display is zero.

The MS byte of the CRC field of the transmission parameter, the front is the packet type, and the back is the all-zero field. When the data from the host changes the level, the strobe from the host switches from one to zero, and then back to one, thereby forming a wider pulse. When the data enters zero, the strobe switches at a higher rate, and only data changes on the data line cause changes near the end of the alignment field. For the rest of the figure, since the data signal is at a fixed 0 or 1 level for an extended period of time, the strobe switches at the higher rate, and the transitions fall on the pulse pattern (edge )superior.

When the reverse link clock for the host starts to adapt to the reverse link packet, This clock is at zero until the end of the turnaround 1 cycle. The arrow in the lower part of the figure indicates when the data was sampled, as will be understood from the rest of this manual. The figure shows that the first byte of the transmission packet field (here, 11000000) starts after turning 1, and the line level has been stabilized from the deactivation of the host driver. The delay in the path of the first bit can be seen in the dashed line of the data signal, as seen in bit three.

In Figure 53, you can observe the typical value of the reverse rate divisor based on the forward link data rate. The actual reverse rate divisor is determined as the result of the round-trip link measurement to ensure correct reverse link operation. The first area 5302 corresponds to a safe operation area, the second area 5304 corresponds to the marginal performance area, and the third area 5306 indicates settings that are unlikely to operate correctly.

Using any interface type setting operation on the forward or reverse link, the round-trip delay measurement is the same as the reverse rate divisor setting because it is expressed in units of the actual clock cycle rather than the number of bits sent or received And operation.

XI. Steering and protection time

As mentioned earlier, the turnaround 1 field in the reverse link encapsulation packet and the guard time 1 field in the round-trip delay measurement packet specify the time length value, which allows the host interface driver to be disabled before the display interface driver is activated . The Steering 2 and Guard Time 2 fields provide time values that allow the display driver to be deactivated before the host driver is activated. The guard time 1 and guard time 2 fields are generally filled with preset or pre-selected length values, and it is not desirable to adjust these values. Depending on the interface hardware used, empirical data can be used to form these values, and in some cases, these values can be adjusted to improve operation.

Several factors jointly determine the length of the turn to 1. These factors are the forward link data rate and the maximum deactivation time of the MDDI_Data driver in the host. The maximum host driver deactivation time is specified in Table XI, which shows that the drivers take a maximum of about 10 nanoseconds to deactivate and about 2 nanoseconds to activate. The maximum number of forward link clocks required to disable the host driver is expressed according to the following relationship:<maths><img file="TWI345404B_D0028.tif" /></maths>

The allowable value range of Turn 1 is expressed according to the following relationship:<maths><img file="TWI345404B_D0029.tif" /></maths>The interface type factor is 1 for the first type, 2 for the second type, 4 for the third type, and 8 for the fourth type.

Combining the above two equations, it can be seen that the interface type factor term disappears, and the transition to the 1 system is defined as:<maths><img file="TWI345404B_D0030.tif" /></maths>For example, the 1500 Mbps type 3 forward link will use the turnaround 1 delay as:<maths><img file="TWI345404B_D0031.tif" /></maths>

As the round-trip delay increases, the timing from when the host is disabled to when the display is activated improves marginally.

The factors that determine the length of time generally used for turn 2 are the forward link data rate, the maximum deactivation time of the MDDI_Data driver in the display, and the round-trip delay of the communication link. The calculation of the time required to disable the display driver is essentially the same as the calculation for the host driver described above, and is defined according to the following relationship:<maths><img file="TWI345404B_D0032.tif" /></maths>

And the allowable value range for turn 2 is expressed as:<maths><img file="TWI345404B_D0033.tif" /></maths>For example, a 1500 Mbps type 3 forward link with a round-trip delay of 10 forward link clocks usually uses turnaround 2 delays at the following levels:<maths><img file="TWI345404B_D0034.tif" /></maths>

XII. Alternative reverse link timing

Although the use of the above timing and guard bands can achieve a high data transmission rate interface, the inventor has discovered a technique by changing the reverse timing to find that the technique allows the reverse rate length to be shorter than the round-trip time.

As explained above, the previous method for reverse link timing is configured to count the number of clock cycles from the last bit of the guard time 1 of the reverse timing packet until sampling on the rising edge of an IO clock Until the first bit. It is used to time the input and output clock signals of the MDD interface. Therefore, the calculation system used for the reverse rate divisor is given as:<maths><img file="TWI345404B_D0035.tif" /></maths>

This provides a bit width equal to the round-trip delay, and a very reliable reverse link can be obtained. However, it has been shown that the reverse link can run faster, or run at a higher data transfer rate, and the inventor hopes to take advantage of this. New creation The creative technology allows the use of the additional capabilities of the interface to achieve higher speeds.

This is achieved by allowing the host to count the number of clock cycles until one is sampled, and the host samples the data lines on the rising and falling edges during the reverse timing packet. This allows the host to select the most useful or even the best sampling point in the reverse bit to ensure bit stability. That is, to find the most useful or best rising edge of the sampled data for the reverse flow reverse encapsulation of the packet. The best sampling point depends on the reverse link divisor and whether the first one is detected on the rising or falling edge. The new timing method allows the host to only look for the first edge of the 0xFF 0xFF 0x00 pattern sent by the client to determine where to sample the reverse encapsulation packet.

Figure 64 illustrates the arrival of the reverse bit and an example of how the bit finds various reverse rate divisors, as well as the many clock cycles that have occurred since the last bit of guard time 1. In Figure 64, it can be seen that if the first edge appears between the rising and falling edges (marked as rising/falling), for the best sampling point where the reverse rate divisor is one, the best sampling point is marked as "b" The edge of the clock period, because it is the only rising edge that occurs in the reverse bit period. For the reverse rate divisor of two, the best sampling point may still be the front edge "b" of the clock cycle, because the cycle edge "c" is closer to the bit edge than "b". For the reverse rate divisor of four, the best sampling point may be the front edge "d" of the clock cycle because it is closer to the back edge of the reverse bit whose value may have stabilized.

Referring again to Figure 64, if the first edge occurs between a falling and rising edge (marked as falling/rising), then the best sampling point for the reverse rate divisor is the sampling point clock period edge "a ", because it is the only rising edge that appears in the reverse bit time period. The divisor for the reverse rate is 2. The best sampling point is the edge "b", the divisor for the reverse rate is four, and the best sampling point is the edge "c".

It can be seen that as the reverse rate divisor becomes larger and larger, the determination or selection of the best sampling point becomes easier because it should be the rising edge closest to the middle.

The host can use this technique to find the number of rising clock edges before the rising data edge of the timing packet data is observed on the data line. Then according to whether the edge occurs between a rising and falling edge or a falling and rising edge, and what the reverse rate divisor is, it can be determined how many extra clock cycles need to be added to a number counter, so as to reasonably Make sure to sample the bit at the edge as close as possible to the middle.

Once the host has selected or determined the number of clock cycles, it can "explore" various reverse rate divisors together with the client to determine whether the specific reverse rate divisor can work. The host (and the client) can check the CRC of the reverse status packet received from the client at the beginning of the divisor to determine whether the reverse rate can operate properly to transmit data. If the CRC is corrupted, there may be a sampling error, and the host can increase the reverse rate divisor and try to request the status packet again. If the message packet of the second request is destroyed, the divisor can be increased again and the request can be made again. If the packet is decoded correctly, the reverse rate divisor can be used for all future reverse packets.

This method is effective and useful because the reverse timing should not deviate from the initial round-trip timing estimate. If the forward link is stable, the user end should continue to decode the forward link packets, even if there is a reverse link failure. Of course, the host is still responsible for setting the reverse link divisor for the link, because this method does not guarantee a perfect reverse link. To the link. In addition, the divisor will mainly depend on the quality of the clock used to generate the IO clock. If the clock has a significant amount of jitter, there is a greater probability of sampling errors. This error probability increases as the amount of clock cycles in the round-trip delay increases.

This implementation is best for type 1 reverse data, but it may cause problems for type 2 to type 4 reverse data, because the skew between the data lines may be very large, and the link cannot be Run at the best data rate for only one data pair. However, even if type 2 to type 4 are used for operation, the data rate may not need to be reduced to the level of the previous method. If this method is used on each data line to select the ideal or optimal clock sample position, this method can also work best. If it is at the same sample time for each data line, this method will continue to operate. If it is in a different sample period, two different methods can be used. The first method is to select an ideal or better sample location for each data point, even if it is different for each data pair. The host can then reconstruct the data stream after sampling all the bits from the data pair set: two bits for type 2, four bits for type 3, and eight bits for type 4. Another option is to let the host increase the reverse rate divisor so that the data bits of each data pair can be sampled at the same clock edge.

XIII. The influence of link delay and skew

The delay skew between the MDDI_Data pair and MDDI_Stb on the forward link can limit the maximum possible data rate, unless delay skew compensation is used. The delay differences that cause timing skew are due to the controller logic, line drivers and receivers, and the cables and connectors described below.

<b>A. Link timing analysis restricted by skew (MDDI Type 1)</b>

<b><i>1. Delay and skew example of Type 1 link</i></b>

Figure 57 shows a typical interface circuit similar to that shown in Figure 41, which is used to cope with the Type 1 interface link. Fig. 57 shows exemplary or typical values of propagation delay and skew at several processing or interface stages of MDDI type 1 forward link. The delay skew between MDDI_Stb and MDDI_Data0 causes distortion of the duty cycle of the output clock. The data at the D input of the receiver flip-flop (RXFF) stage using flip-flops 5728, 5132 must be slightly changed after the clock edge in order to be reliably sampled. The figure shows two-stage delay lines 5732a and 5732b, which are used to solve two different problems related to establishing this timing relationship. In actual implementation, the delay lines can be incorporated into a single delay element.

Figure 58 illustrates the data, strobe and clock recovery timing for exemplary signal processing through the interface on the Type 1 link.

The important total delay skew usually results from or comes from the sum of the skews in the following stages: transmitter flip-flop (TXFF) with flip-flops 5704 and 5706; transmitter driver (TXDRVR) with drivers 5708 and 5710; cable 5702; Receiver line receiver (RXRCVR) with receiver 5722, 5724; and Receiver XOR logic (RXXOR). The delay 1 5732a should match or exceed the delay of the XOR gate 5736 in the RXXOR level, which is determined by the following relationship:<maths><img file="TWI345404B_D0036.tif" /></maths>

This requirement needs to be met so that the D input of the receiver flip-flops 5728 and 5732 will not change before the clock input. If the hold time of RXFF is zero, this efficient.

The purpose or function of delay 2 is to compensate the holding time of the RXFF flip-flop according to the following relationship: t_{PD-min(Delay2)}=t_H(RXFF)

In many systems, this will be zero because the hold time is zero. Of course, in this case, the maximum delay of delay 2 can also be zero.

The worst-case effect of skew in the XOR stage of the receiver is in the data-late/gated-early case, where the delay 1 is at the maximum and the clock output from the XOR gate appears as early as possible according to the following relationship: t_{SKEW-max(RXXOR)}=t_{PD-max(Delay1)-}t_PD-min(XOR)

In this case, the data can change between two-bit periods (n and n+1), which is very close to the timing of the bit n+1 to the receiver flip-flop.

The maximum data rate (minimum bit period) of MDDI Type 1 link is a function of the maximum skew encountered by all drivers, cables, and receivers in the MDDI link plus the total data set in the RXFF stage. The total delay skew in the link up to the output of the RXRCVR stage can be expressed as: t_{SKEW-max(LINK)}=t_{SKEW-max(TXFF)}+t_{SKEW-max(TXDRVR)}+t_{SKEW-max(CABLE)}+t_{SKEW-max(RXRCVR)}

And the minimum bit period system is given as: t_BIT-min=t_{SKEW-max(LINK)}+ts_{KEW-max(RXXOR)}+t_{PD-max(Delay2)}+t_SU(RXFF)

In the example shown in Figure 57, t_{SKEW-max(LINK)}=1.4 nsec and the minimum bit period can be expressed as: t_BIT-min=1.4+0.3+0.2+0.5==2.4nsec, or expressed as about 416 Mbps.

<b>B. MDDI Type 2, Type 3 and Type 4 Link Timing Analysis</b>

Figure 59 shows a typical interface circuit similar to that shown in Figures 41 and 57, which is used to cope with Type 2, Type 3, and Type 4 interface links. TXFF (5904), TXDRVR (5908), RXRCVCR (5922) and RXFF (5932, 5928, 5930) levels use additional components to cope with additional signal processing. Fig. 59 shows exemplary or typical values of propagation delay and skew at several processing or interface stages of MDDI type 2 forward link. In addition to the delay skew between MDDI_Stb and MDDI_Data0 that affects the duty cycle of the output clock, there is also a skew between these two signals and other MDDI_Data signals. The data at the D input of the receiver flip-flop B (RXFFB) stage composed of flip-flops 5928 and 5930 is slightly changed after the clock edge in order to be reliably sampled. If MDDI_Data1 arrives earlier than MDDI_Stb or MDDI_Data0, the sampling of MDDI_Data1 should be delayed, and the delay amount should be at least equal to the delay skew amount. To achieve this, a delay 3 delay line is used to delay the data. If MDDI_Data1 arrives later than MDDI_Stb and MDDI_Data0, the delay 3 should also delay MDDI_Data1, so that the change point of MDDI_Data1 is closer to the edge of the next clock. This process determines the upper limit of the data rate of MDDI Type 2, Type 3, or Type 4 links. 60A, 60B, and 60C illustrate some exemplary different possibilities of the timing or skew relationship between the two data signals and MDDI_Stb.

In order to reliably sample the data in RXFFB when MDDI_DataX arrives as early as possible, the delay 3 is set according to the following relationship:<maths><img file="TWI345404B_D0037.tif" /></maths>

The minimum allowable bit period determines the maximum link speed. This is most affected when MDDI_DataX arrives as late as possible. In this case, the smallest The allowable cycle time system is given as: t_BIT-min=t_{SKEW-max(LINK)}+t_{PD-max(Delay3)}+t_SU(RXFFB)-t_PD-min(XOR)

The upper limit of the link speed is: t_{PD-max(Delay3)}=t_{PD-min(Delay3)}

And suppose: t_{BIT-min(lower-bound)}=2. t_{SKEW-max(LINK)}+t_PD-Max(XOR)+t_SU(RXFFB)+t_H(RXFFB)

In the example given above, the lower limit of the minimum bit period is given by the following relationship: t_{BIT-min(lower-level)}=2.1.4+1.5+0.5+0.1=4.8 nsec, which is approximately 208 Mbps.

This is far below the maximum data rate that can be used for Type 1 links. MDDI's automatic delay skew compensation capability significantly reduces the influence of delay skew on the maximum link rate.

XIV. Physical layer interconnection description

The physical connection useful for implementing the interface according to the present invention can be realized by using commercially available components, for example, the host side uses Hirose Electric Company Ltd. (Hirose Electric Company Ltd.) No. 3260-8S2(01) component, and the display device side uses Component No. 3240-8P-C manufactured by Hirose Electric Co., Ltd. Table XIII lists and Figure 61 illustrates exemplary interface pin assignments or "pin layouts" for this type of connector for Type 1/Type 2 interface.

<tables><img file="TWI345404B_D0038.tif" /></tables>

The shield is connected to the HOST_Gnd in the host interface, and the shield drain wire in the cable is connected to the shield of the display connector. However, the shield and drain wires are not connected to the circuit ground inside the display.

Choosing or designing interconnection elements or devices to make them small enough for use in mobile communication and computing devices, such as PDAs and wireless phones, or portable gaming devices, so as not to be prominent or unsightly compared to the size of related devices. Any connector and cable should be durable enough to be used in a normal consumer environment, and allow small size (especially for cables) and relatively low cost. The transmission component should adapt to the data and strobe signal. It is a differential NRZ data, with a transmission rate of up to 450 Mbps for the 1st and 2nd type, and up to 3.4 Gbps for the 8-bit parallel type 4 version. rate.

For internal mode applications, there is no connector with the same meaning as the conductor used, Or there is no such connection element that tends to be extremely miniaturized. One example is a zero insertion force "socket" used to receive integrated circuits or package components of a host or client device. Another example is that the host and client reside on a printed circuit board with various interconnection conductors, and have "pins" or "pins" extending from the housing (which is soldered to the contacts on the conductors used for the integrated circuit interconnection) contact.

XV. Operation

54A and 54B show a summary of the general steps used to process data and packets in the operation of the interface of the specific embodiment of the present invention, and an overview of the interface device for processing packets in FIG. 55. In this diagram, the procedure starts at step 5402, where it is determined whether to use a communication path, here is a cable, to connect the client and the host. This can be done by the host using periodic polling. The host uses software or hardware that detects the presence of a signal at the connector or cable or input of the host (as seen from the USB interface), or other well-known technologies . If no client is connected to the host, it can simply enter a waiting state of a predetermined length (depending on the application), enter sleep mode, or deactivate for future use (this may require the user to take action to restart the host ). For example, when the host resides on a computer-type device, the user may need to click on a screen icon or request a program that initiates host processing to find the client. Similarly, simply plugging in a USB type connection can start host processing, depending on the capabilities and configuration of the host or host software that resides.

Once the client is connected to the host, or vice versa, or its existence is detected, in steps 5404 and 5406, the client or host sends an appropriate packet requesting service. In step 5404, the client can send a display service request or status message packet. It should be noted that the above link can be previously closed or in sleep mode, so it is not necessarily It is the complete initialization of the subsequent communication link. Once the communication link is synchronized and the host attempts to communicate with the client, the client also provides a display capability packet to the host, as in step 5408. The host can now start to determine the type of support, including the transfer rate that the client can adapt to.

Generally, in step 5410, the host and the client also negotiate the type of service mode (rate/speed) to be used, such as type 1, type 2, and so on. Once the service type is established, the host can start transmitting information. In addition, the host can use the round-trip delay measurement packet to optimize the timing of the communication link in parallel with other signal processing, as shown in step 5411.

As mentioned above, all transmission starts with the sub-frame header packet. The figure shows that it was transmitted in step 5412, followed by the data type, here is the video and audio stream packet, and the filler packet, shown in the figure It is transmitted in step 5414. The audio and video data have been previously prepared or mapped into the packet, and the filler packet is inserted according to the situation or as necessary to fill the media frame with the required number of bits. The host can send a packet such as a forward audio channel activation packet to activate the audio device. In addition, the host can use the aforementioned other packet types to transmit commands and information, which are shown here as the color mapping transmission, bit block transmission, or other packet in step 5416. In addition, the host and the client can use appropriate packets to exchange data about the keyboard or pointing device.

During operation, one of several different events may occur, which causes the host or client to require a different data rate or interface mode type. For example, computers or other data-transmitting devices may encounter loading conditions when processing data, causing the preparation or presentation of packets to slow down. The monitor that receives the data may change from a dedicated AC power source to a more limited battery power source, and the monitor is more restrictive. Under high power settings, either cannot transmit data or process commands as fast as possible, or cannot use the same resolution or color depth. Or, restrictive conditions may be eased or eliminated, allowing any device to transmit data at a higher rate. This is more in line with needs, and a request can be made to switch to a higher transmission rate mode.

If these or other types of well-known conditions occur or change, the host or client can detect these conditions and try to renegotiate the interface mode. This is shown in step 5420, where the host sends an interface type handover request packet to the client, requesting handover to another mode, and the client sends an interface type confirmation packet to confirm the request for change, and then the host sends the execution type handover. Deliver the packet to change to the specified mode.

Although no specific processing sequence is required, the client and the host can also exchange data packets related to data sent to or received from pointing devices, keyboards or other user-type input devices that are mainly associated with the client. Of course, such components It can also exist on the host side. Generally, general-purpose processor-type components rather than state machines (5502) are used to process such packets. In addition, some of the above commands are also processed by general-purpose processors (5504, 5508).

After the data and commands have been exchanged between the host and the client, it is determined at a certain point whether additional data needs to be transmitted or whether the host or the client will stop serving the transmission. This is shown in step 5422. If the link will enter a dormant state or shut down completely, the host sends a link close packet to the client, and both ends terminate data transmission.

The packets transmitted in the above operation process will be transmitted using the drivers and receivers previously discussed about the host and the client controller. Isometric drive The processor and other logic elements are connected to the above-mentioned state machine and general-purpose processor, as illustrated in the overview of Figure 55. In Figure 55, the state machine 5502 and general-purpose processors 5504 and 5508 can be further connected to other components not shown, such as dedicated USB interfaces, memory components, or other components that reside outside and interact with the link controller, including but not Limited to data sources and video control chips used to view display devices.

The processor and the state machine provide the control to activate and deactivate the driver, as discussed above on the guard time, etc., to ensure the effective establishment or termination of the communication link and the transmission of the packet.

XVI. Display frame buffer

Compared with computer graphics, video data buffering requirements for mobile video images are different. Pixel data is most often stored in the local frame buffer in the client so that the image on the display can be refreshed locally.

When displaying full-motion video (almost every pixel in the display changes in each media frame), it is usually better to store the incoming pixel data in a frame buffer and refresh the display from the second frame buffer at the same time On the image. More than two display buffers can be used to eliminate visible artifacts as described below. When the entire image has been received in a frame buffer, the role of the buffer is switched, and then the newly received image is used to refresh the display, and a frame under the image fills other buffers. This concept is illustrated in FIG. 91A, in which the pixel data is written to the offline image buffer by setting the display update bit to "01".

In other applications, the host only needs to update a small part of the image without redrawing the entire image. In this case, you need to write the new pixels directly to refresh the display. The buffer of the indicator is shown in detail in Figure 91B.

In an application with a fixed image (with a small video window), the easiest way is to write the fixed image into the two buffers shown in Figure 91C (display update bit equal to "11"), and then update the display by Set the bit to "01" and write the pixels of the moving image into the offline buffer.

The following rules illustrate the useful processing of buffer indicators and simultaneously write new information to the client and refresh the display. There are three buffer indicators: current_fill points to the buffer currently filled with data on the MDDI link. just_filled points to the most recently filled buffer. being_displayed points to the buffer currently used to refresh the display. All three buffers can contain values from 0 to N-1, where N is the number of display buffers, and N<img file="TWI345404B_D0039.tif" />2. The arithmetic operation on the buffer index is mod N. For example, when N=3 and current_fill=2, incrementing current_fill causes current_fill to be set to 0. In the simple case of N=2, just_filled is always the remainder of current_fill. The following operations are performed in the specified order on each MDDI media frame boundary (the sub-frame header packet whose sub-frame count field is equal to zero): set just_filled equal to current_fill, and set current_fill equal to current_fill+1.

The MDDI video stream packet updates the buffer according to the following structure or method: when the display update bit is equal to "01", the pixel data is written into the buffer specified by current_fill; when the display update bit is equal to "00", the pixel Data is written into the buffer specified by just_filled; and when the display update bit is equal to "11", the pixel data is written into all buffers. The display is refreshed from the buffer specified by the being_displayed indicator. The monitor refreshes the last pixel in a frame refresh cycle and then starts to refresh the next frame refresh Before the first pixel in the period, the display update program executes the operation of setting being_refreshed equal to just_filled.

The video stream packet contains a pair of display update bits, which specify the frame buffer into which pixel data should be written. The display capability packet has three extra bits, which indicate which combinations of display update bits are supported in the client. In many cases, computer-generated images need to be incrementally updated based on user input or obtained from information received from computer networks. The display update bit combinations "00" and "11" support this mode of operation by writing pixel data into the display frame buffer or two frame buffers.

When adapting to the video image, Figure 92 illustrates how to use a pair of frame buffers to display the video image when sending video data on the MDDI link where the display update bit is equal to "01". After the media-frame boundary is detected on the MDDI link, when the refresh process used to refresh the current frame is completed, the display refresh process will start to refresh from the next frame buffer.

The important assumption about Figure 92 is that the image is received from the host as a continuous stream of pixels, which is sent in the same order that the client uses to read pixels from the frame buffer to refresh the display (usually from the top left to the bottom right of the screen one by one. Read). This is an important detail in the case where the display refresh and image transmission operations refer to the same frame buffer.

The display refresh frame rate needs to be greater than the image transmission frame rate to avoid displaying part of the image. Figure 93 shows how image fragmentation occurs at a lower monitor refresh rate, that is, monitor refresh is slower than image transmission.

In images that include a combination of computer graphics images and moving video images, the video pixel data can occupy a small portion of the media frame. Refresh operation on the display This can be very important in the case where the image transmission refers to the same frame buffer. The cross-hatched shading in Fig. 94 shows the situation, where the pixels read from the buffer to refresh the display may be the pixels written to the buffer before two frames, or it may correspond to the immediate write to the same frame buffer. Frame.

Using three frame buffers on the client side can solve the small window problem of competition for access to the frame buffer, as shown in Figure 95.

However, if the display refresh rate is lower than the media frame rate on the MDDI link, there is still a problem, as shown in Figure 96.

As shown in Figure 97, using a single buffer to move video images has some problems. Since the display is refreshed faster than the image is transferred to the buffer, the refreshed image sometimes shows the higher part of the written frame and the lower part of the image is the previously transmitted frame. Since the display refreshes faster than the image transmission (preferred operation mode), there will be more frequent instances of the frame displaying the same separated image.

XVII. Delay Value Table

Packet processing delay parameters The packet uses a look-up table function to calculate the predicted delay to process specific commands in the client. The values in the table are increased logarithmically to provide a delay value with a very wide dynamic range. An exemplary delay value table useful for implementing specific embodiments of the present invention can be found in the following Table XX, corresponding to the index value to the delay value.

<tables><img file="TWI345404B_D0040.tif" /></tables>

Calculate the delay by performing a table lookup using the specified parameters as the index into the table. This means that the delay is equal to the packet processing table (index). For example: if one of the parameters from the delay parameter list item is equal to the 8-bit value of 134, the delay is equal to the packet processing table (134) of 16 μsec. The value 255 indicates that the command completion time cannot be determined by calculation, and the host must check the graphic busy flag in the display request and status packet or the MCCS VCP control parameter B7h.

In some cases, this delay is multiplied by the pixel height and width in the destination image Degree or number, and add other delays to calculate the total packet processing delay.

XVIII. Multiple client support

The current protocol version does not seem to directly support multiple client devices. However, most packets contain a reserved client ID field, which can be used to address a specific client device in a system with multiple clients. Generally, for many applications, this client ID or the client IDs are set to zero. The sub-frame header packet also includes a field to indicate whether the host supports a multi-client system. Therefore, in one approach, multiple client devices may be connected and addressed in future applications of the MDD interface or protocol, so as to assist the system designer in planning future compatibility with multi-client hosts and clients.

In a system with multiple clients, it is beneficial to use a daisy chain of the client or a hub (as shown in FIG. 98) or a combination of these technologies as shown in FIG. 99 to connect the client to the host.

XVIII. Appendix

In addition to the above-mentioned format, structure and content of the architecture and protocol used for various packet types for implementing specific embodiments of the present invention, the following will describe in more detail the field content or operations of some packet types. This description is used to further clarify its individual use or operation, so that those skilled in the art can more easily understand the present invention and use the present invention in various applications. Only a few fields that have not been discussed are further discussed here. In addition, exemplary definitions and values will be used to illustrate these fields with respect to the above-mentioned specific embodiments. However, such values should not be considered as limitations to the present invention, but represent one or more specific embodiments for implementing interfaces and protocols, and it is not necessary to implement all specific embodiments together or at the same time. In other specific embodiments, other values can be used to achieve data or data The required presentation of rate transmission results should be understood by those skilled in the art.

<b>A. About the video streaming package</b>

In a specific embodiment, the pixel data attribute field (2 bytes) has a series of bit values, which is explained as follows. Bits 1 and 0 select how to send display pixel data. For the bit value "11", the data is displayed to or used for both eyes, for the bit value "10", the data is only sent to the left eye, for the bit value "01", the data is only sent to the right eye, for the bit value With the value "00", the data is sent to the alternate display specified by the following bits 8 to 11.

Bit 2 indicates whether to present the pixel data in an interlaced format, where the value "0" indicates that the pixel data is in the standard progressive format, and when it advances from one row to the next, the row number (pixel Y coordinate) is incremented by 1. If this bit has the value "1", the pixel data is in the interlaced format, and when advancing from one row to the next, the row number is incremented by 2. Bit 3 indicates that the pixel data is in alternate pixel format. This is similar to the standard interlace mode activated by bit 2, but the interlace is vertical rather than horizontal. When bit 3 is "0", the pixel data is in the standard progressive format, and the row number (pixel X coordinate) is incremented by 1 when each continuous pixel is received. When bit 3 is "1", the pixel data is in alternate pixel format, and the row number is incremented by 2 when each pixel is received.

Bit 4 indicates whether the pixel data is related to a display or a camera, because the data is transmitted to or from the internal display of a wireless phone or similar device or even a portable computer or other such devices mentioned above, or the data is transmitted from the internal display. Transfer data to or from a camera built into the device or directly coupled to the device. When bit 4 is "0", the pixel data is transferred to or from the display frame buffer. When bit 4 is "1", the pixel data is transmitted to the camera or some Types of video devices or transmission of data from cameras or certain types of video devices, such devices are well known in the art.

Bit 5 is used to indicate when the pixel data contains the next consecutive row of pixels in the display. This is regarded as when bit 5 is set equal to "1". When bit 5 is set to "1", the X left edge, Y top edge, X right edge, Y bottom edge, X start and Y start parameters are undefined and ignored by the client. Set bit 15 to a logical bit on time, which indicates that the pixel data in this packet is the last pixel row in the image. Bit 8 of the client feature capability indicator field of the client capability packet indicates whether this feature is supported.

Bits 7 and 6 are display update bits, which specify the frame buffer that needs to write pixel data. Discuss more specific effects elsewhere. For the bit value "01", the pixel data is written into the offline image buffer. For the bit value "00", the pixel data is written into the image buffer used to refresh the display. For the bit value "11", the pixel data is written into all image buffers. The bit value or combination "10" is regarded as an invalid value or specified, and the pixel data is ignored and not written to any image buffer. This value can be used in future interface applications.

Bits 8 to 11 form a 4-bit unsigned integer, which specifies the display position of the alternate display or sending pixel data. Bits 0 and 1 are equal to "00" so that the display client interprets bits 8 to 11 as alternate display numbers. If bits 0 and 1 are not equal to "00", set bits 8 to 11 as the logic zero level.

Bits 12 to 14 are reserved for future use and are generally set to logic zero levels. As described above, bit 15 is used in conjunction with bit 5, and bit 15 is set as a logical one indicator, and the pixel row in the pixel data field is the last pixel row in the data frame. The next video stream packet with bit 5 set to logic one Will correspond to the first pixel row of the next video frame.

The 2-byte X start and Y start fields specify the X and Y coordinates of the point (X start, Y start) of the first pixel in the pixel data field. The 2-byte X left edge and Y top edge fields specify the left X coordinate and the top Y coordinate of the screen window filled by the pixel data field, while the X right edge and Y bottom edge fields specify the updated The X coordinate on the right side of the window and the Y coordinate on the bottom edge.

The pixel count field (2 bytes) specifies the number of pixels in the following pixel data field.

The parameter CRC field (2 bytes) includes the CRC of all the bytes from the packet length to the pixel count. If the CRC check is incorrect, the entire packet is discarded.

The pixel data field includes the original video information to be displayed, and it is formatted in the manner described in the video data format descriptor field. As described elsewhere, the data is sent one "row" at a time.

The pixel data CRC field (2 bytes) only includes the 16-bit CRC of the pixel data. If the CRC verification of this value fails, the pixel data can still be used, but the CRC error count will increase.

<b>B. About the audio streaming package</b>

In a specific embodiment, the audio channel ID field (1 byte) uses an 8-bit unsigned integer value to identify the specific audio channel through which the client device transmits audio data. The physical audio channel is assigned or mapped to the physical channel by this field. Values of 0, 1, 2, 3, 4, 5, 6 or 7 indicate front left, front right, back left, back right, center front, subwoofer, and left, respectively Surround and right surround channels. The audio channel ID value 254 indicates that a single digital audio sample stream is sent to the front left and front right channels. This simplifies the communication of the application, where the stereo headset microphone is used for voice Communication, productivity enhancement devices are used on PDAs, or other applications, where a simple user interface generates warning sounds. The values used in the ID field ranging from 8 to 253 and 255 are currently reserved for use in situations where new designs require additional designation, as expected by those skilled in the art.

Reserved 1 field (1 byte) is usually reserved for future use, and all bits in this field are set to zero. One of the functions of this field is to align the subsequent 2-byte field with the 16-bit character address and align the 4-byte field with the 32-bit character address.

The audio sample count field (2 bytes) specifies the number of audio samples in this packet.

The bit and packaging field of each sample contains 1 byte, which specifies the packaging format of the audio data. In a specific embodiment, the commonly used format is, bits 4 to 0 define the number of bits of each PCM audio sample. Then bit 5 specifies whether the digital audio data sample is packaged. As mentioned above, FIG. 12 illustrates the difference between the packed audio sample and the byte-aligned audio sample. The value "0" of bit 5 indicates that each PCM audio sample in the digital audio data field is aligned with the interface byte boundary system byte, and the value "1" indicates that each consecutive PCM audio sample is aligned with the previous The audio samples are packed. This bit is only valid when the value defined in bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of eight. Bits 7 to 6 are reserved for systems that require additional designation, and are generally set to a value of zero.

The audio sample rate field (1 byte) specifies the audio PCM sample rate. The format used is that the value 0 indicates the sampling rate (samples per second; sps) of 8,000 samples per second, the value 1 indicates 16,000 sps, the value 2 indicates 24,000 sps, and the value 3 indicates 32,000 sps, value 4 indicates 40,000 sps, value 5 indicates 48,000 sps, value 6 indicates 11,025 sps, value 7 indicates 22,050 sps, and value 8 indicates 44,100 sps, values 9 to 255 are reserved for future use, so it is currently set Is zero.

The parameter CRC field (2 bytes) includes the 16-bit CRC of all bytes from the packet length to the audio sample rate. If the CRC check is incorrect, the entire packet is discarded. The digital audio data field includes the original audio samples to be played, and usually exists in the form of an unsigned integer linear format. The audio data CRC field (2 bytes) only includes the 16-bit CRC of the audio data. If the CRC check is incorrect, the audio data can still be used, but the CRC error count will increase.

<b>C. About user-defined data stream packets</b>

In a specific embodiment, the 2-byte stream ID number field is used to identify a specific user-defined stream. The contents of the stream parameters and stream data fields are usually defined by the MDDI equipment manufacturer. The 2-byte stream parameter CRC field includes the 16-bit CRC of all bytes starting from the packet length to the stream parameter of the audio coding byte. If the CRC check is incorrect, the entire packet is discarded. If the MDD interface terminal application does not require the data stream parameter and the data stream parameter CRC field, both can be discarded, which is considered as optional. The 2-byte stream data CRC field only includes the CRC of the stream data. If this CRC is not properly checked, the use of stream data is optional and depends on the needs of the application. The use of stream data depending on whether the CRC is good or not generally requires buffering the stream data until it is confirmed that the CRC is good. If the CRC is not checked, the CRC error count is incremented.

<b>D. About color mapping information package</b>

The 2-byte hClient ID field contains information reserved for the client ID or Value, as used previously. Since this field is usually reserved for future use, set the current value to zero by setting the bit to "0".

The 2-byte color mapping item count field uses a value to specify the total number of 3-byte color mapping items contained in the color mapping data field, or the color mapping table items that exist in the color mapping data in this packet. In this specific embodiment, the number of bytes in the color mapping data is 3 times the count of the color mapping items. Set the color map item count equal to zero so that color map data is not transmitted. If the color mapping size is zero, the color mapping offset will generally be transmitted, but the display will ignore the color mapping offset. The color mapping offset field (4 bytes) specifies the offset of the color mapping data in this packet from the beginning of the color mapping table in the client device.

The 2-byte parameter CRC field includes the CRC of all the bytes from the packet length to the audio coding byte. If the CRC check is incorrect, the entire packet is discarded.

For the color mapping data field, the width of each color mapping position is specified by the color mapping item size field. In one specific embodiment, the first part specifies the size of blue, the second part specifies the size of green, and the third part specifies the size of red. . The color mapping size field specifies the number of 3-byte color mapping table items existing in the color mapping data field. If a single color map cannot be placed in a video data format and color map packet, the entire color map can be specified by transmitting multiple packets, each of which has different color map data and color map offsets. The number of blue, green and red bits in each color mapping data item should be the same as that specified in the color mapping RGB width field of the display capability packet.

The 2-byte color mapping data CRC field only includes the color mapping data CRC. If the CRC check is incorrect, the color mapping data can still be used, but the CRC error count will increase.

Each color mapping data item should be sent in the following order: blue, green, red, and the least significant bit of each component is sent first. The individual red, green, and blue components in each color mapping item should be packed, but each color mapping item (the least significant bit of the blue component) should be aligned by byte. FIG. 100 illustrates an example of color mapping data items with 6-bit blue, 8-bit green, and 7-bit red. For this example, the size of the color mapping item in the color mapping information packet is equal to 21, and the color mapping RGB width field in the display capability information packet is equal to 0x0786.

<b>E. About reverse link encapsulation packets</b>

The parameter CRC field (2 bytes) includes the 16-bit CRC of all the bytes from the packet length to the turn length. If the CRC check is incorrect, the entire packet is discarded.

In a specific embodiment, the reverse link flag field (1 byte) includes a set of flags to request information from the client. If a bit (for example, bit 0) is set to one, the host will use the client capability packet to request the specified information from the display. If this bit is zero, the host does not need information from the client. The remaining bits (bits 1 to 7) are reserved for future use and are set to zero. However, more bits can be used as needed to set the flag for the reverse link.

The reverse rate divisor field (1 byte) specifies the number of MDDI_Stb cycles that occur with respect to the reverse link data clock. The reverse link data period is equal to the forward link data clock divided by two times the reverse rate divisor. The reverse link data rate is related to the reverse reverse link data clock and the interface type on the reverse link. For the Type 1 interface, when the reverse data rate is equal to the reverse link data For Type 2, Type 3, and Type 4 interfaces, the reverse data rate is equal to twice, four times, and eight times the reverse link data clock, respectively.

The all-zero 1 field contains a set of bytes (here 8) whose value is set to zero by setting the bit to the logic zero level, and is used to ensure that all MDDI_Data signals are in the logic zero state for sufficient Time so that the client can only use MDDI_Stb to start the clock recovery before turning to the 1 field to disable the line driver of the host. In a specific embodiment, the length of the all-zero 1 field is greater than or equal to the number of forward link byte transmissions in the cable round-trip delay.

The Turn 1 Length field (1 byte) specifies the total number of bytes allocated for Turn 1 and establishes the first turn cycle. The number of bytes specified by the steering length parameter is allocated so that the MDDI_Data line driver in the client can be activated before the host internal line driver is disabled. The user terminal activates its MDDI_Data line driver in bit 0 of turn 1, and the host disables its output before the last bit of turn 1, so that it is completely disabled. The timing of the activation of the client driver and the deactivation procedure of the host driver is such that during the turn 1 process, one or both drives the MDDI_Data signal to a logical level, as seen by the line receiver in the host. The action of the MDDI_Stb signal seems to be that MDDI_Data0 is at the logic zero level during the entire turn-around 1 cycle. A more complete description of the steering 1 setting will be given below.

The reverse data packet field includes a series of data packets transmitted from the client to the host. When there is no data from the client to the host, the client can send a filler packet or drive the MDDI_Data line to the zero state. If the MDDI_Data line is driven to zero, the host interprets this as a zero-length (invalid length) packet, and the host does not accept it during the current reverse link encapsulation packet duration Additional information package from the client.

The Turn 2 Length field (1 byte) specifies the total number of bytes allocated for Turn 2 and establishes the second turn cycle. The number of bytes specified by the steering length parameter is allocated so that the MDDI_Data line driver in the host can be activated before the user-side internal line driver is disabled. The host activates its MDDI_Data line driver in bit 0 of the first byte of turn 2, and the user terminal disables its output before the last bit of turn 2, so that it is completely disabled. The timing of the deactivation of the client driver and the activation procedure of the host driver is such that during the entire turn 2 process, one or both drives the MDDI_Data signal to a logical level, as seen by the line receiver in the host. The action mode of the MDDI_Stb signal seems to be that MDDI_Data0 is at the logic zero level during the entire turn 2 cycle. The description of the steering 2 setting will be given below.

The reverse data packet field includes a series of data packets transmitted from the client to the host. As mentioned earlier, the filler packet is sent to fill the remaining space unused by other packet types.

The All Zero 2 field contains a set of bytes (8 in this specific embodiment), whose value is set equal to zero by setting the bit at the logic zero level, and is used to ensure that all MDDI_Data signals are in logic The zero state lasts for enough time to enable the user terminal to use MDDI_Data0 and MDDI_Stb to resume the clock after activating the line driver of the host after turning to the 2 field.

<b>F. About the client capability information package</b>

As described in a specific embodiment, the protocol version field uses 2 bytes to specify the protocol version used by the client. The initial version is set to be equal to zero, and the minimum protocol version field uses 2 bytes to specify that the client can use Or explain the minimum agreement version. The data rate capability field (2 bytes) specifies the maximum data rate that the client can receive on the forward link of the interface, and is specified in the form of megabits per second (Mbps). The interface type capability field (1 byte) specifies the interface types supported on the forward and reverse links. The current indication of this field is: select bit 0, bit 1, or bit 2 to select the type 2, type 3 or type 4 mode on the forward link respectively, select bit 3, bit 4 or bit Element 5 selects the type 2, type 3, or type 4 mode on the reverse link, respectively, while bits 6 and 7 are reserved and set to zero. The bitmap width and height fields (2 bytes) respectively specify the width and height of the bitmap in the pixel.

The Monochrome Capability field (1 byte) is used to specify the number of bits of the resolution that can be displayed in the monochrome format. If the monitor cannot use the monochrome format, set this value to zero. Bits 7 to 4 are reserved for future use, so they are set to zero. Bits 3 to 0 define the maximum number of grayscale bits that can exist for each pixel. These four bits make it possible to specify a value between 1 and 15 for each pixel. If the value is zero, the monitor does not support the monochrome format.

The Bayer capability field uses 1 byte to specify the maximum number of resolution bits, pixel groups, and pixel order that can be transmitted in Bayer format. If the client cannot use the Bayer format, this value is zero. The Bayer capability field is composed of the following values: bits 3 to 0 define the maximum number of intensity bits present in each pixel, bits 5 to 4 define the required pixel group pattern, and bit 8 To 6 defines the required pixel order, while bits 14 to 9 are reserved for future use, and are generally set to zero at this time. When bit 15 is set to one, it indicates that the client can accept Bayer pixel data in packaged or unpackaged format. If bit 15 is set to zero, this indicates that the client can only accept unpacked Bayer pixel data in format.

The color mapping capability field (3 bytes) specifies the maximum number of table items in the color mapping table in the display. If the monitor cannot use the color mapping format, set this value to zero.

The RGB capability field (2 bytes) specifies the number of bits of the resolution that can be displayed in the RGB format. If the monitor cannot use the RGB format, this value is equal to zero. The RGB capability character consists of three separate unsigned values, among which: bits 3 to 0 define the maximum number of blue bits, bits 7 to 4 define the maximum number of green bits, and bits 11 to 8 define each pixel The maximum number of inner red bits. Currently, bits 14 to 12 are reserved for future use, and are generally set to zero. Bits 14 to 12 are reserved for future use and are generally set to zero. When bit 15 is set to one, it indicates that the client can accept the color-mapped pixel data in packaged or unpackaged format. If bit 15 is set to zero, this indicates that the client can only accept color-mapped pixel data in an unpackaged format.

The Y Cr Cb capability field (2 bytes) specifies the number of bits of the resolution that can be displayed in the Y Cr Cb format. If the display cannot use the Y Cr Cb format, this value is set equal to zero. The Y Cr Cb capability character consists of three separate unsigned values: bits 3 to 0 define the maximum number of bits in the Cb sample, bits 7 to 4 define the maximum number of bits in the Cr sample, and bits 11 to 8 define the maximum number of bits in the Cr sample. The maximum number of bits in the Y sample, bits 15 to 12 are currently reserved for future use and set to zero.

The user-side feature capability field uses 4 bytes, which includes a set of flags to indicate specific features supported in the display. One bit is set to one indicator to support the ability, and one bit is set to zero to indicate that the ability is not supported. The value of bit 0 indicates whether bit-mapped block transmission packets are supported (packet type 71). Bit 1, 2 The value of and 3 respectively indicate whether to support bit-mapped area padding packets (packet type 72), bit-mapped pattern padding packets (packet type 73), or communication link data channel packets (packet type 74) . The value of bit 4 indicates whether the client has the ability to make a color transparent, while the values of bits 5 and 6 respectively indicate whether the client can accept the video data or audio data in the packaging format, and the value of bit 7 indicates whether the client Can transmit reverse link video streams from the camera. The value of bit 8 indicates whether the client has the ability to receive a complete pixel data line and ignore the display address specified in bit 5 of the pixel data attribute field of the video stream packet, and the client can use the pixel data attribute field Bit 15 is used to detect the end of frame synchronization or video frame data.

The values of bits 11 and 12 respectively indicate when the client communicates with the pointing device and can transmit and receive data packets of the pointing device or when it communicates with the keyboard and can transmit and receive keyboard data packets. The value of bit 13 indicates whether the client has the ability to set one or more audio or video parameters by supporting the VCP feature packet: request VCP feature packet, VCP feature capability response packet, set VCP feature packet, request valid Parameter packet and valid parameter reply packet. The value of bit 14 indicates whether the client has the ability to write pixel data into the offline frame buffer. If this bit is set to a logical level, the display update bit (bits 7 and 6 of the pixel data attribute field of the video stream packet) may be set to 01. The value of bit 22 indicates whether the client has the ability to respond to the register access packet. Bits 9 to 10 and 23 to 31 are currently reserved for future use or as an alternative designation by the system designer, and are generally set to zero.

The display video frame rate capability field (1 byte) specifies the maximum video frame update capability of the display, in units of frames per second. Host can choose low Update the image at the update rate of the value specified in this field.

The audio buffer depth field (2 bytes) specifies the depth of the elastic buffer dedicated to each audio stream in the display.

The audio channel capability field (2 bytes) includes a set of flags, which indicate which audio channels the display (client) supports. One bit is set to indicate that the channel is supported, and one bit is set to zero to indicate that the channel is not supported. Bit positions are assigned to different channels. For example, bit positions 0, 1, 2, 3, 4, 5, 6 and 7 indicate front left, front right, back left, back right, center front, subwoofer, surround left, and Right surround channel. Bits 8 to 15 are currently reserved for future use, and are generally set to zero.

The 2-byte audio sample rate capability field for the forward link contains a set of flags to indicate the audio sample rate capability of the client device. Bit positions are assigned to different sample rates accordingly, for example, bits 0, 1, 2, 3, 4, 5, 6, 7, and 8 are assigned to 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, respectively , 22,050 and 44,100 samples per second (SPS), and bits 9 to 15 are reserved for future use or as an alternative sample rate as needed, so they are currently set to "0". Setting the bit value of one of these bits to "1" indicates that the specific sample rate is supported, and setting the bit to "0" indicates that the sample rate is not supported.

The minimum sub-frame rate field (2 bytes) specifies the minimum sub-frame rate of the frame per second. The minimum sub-frame rate keeps the display status update rate sufficient to read certain sensors or pointing devices in the display.

The 2-byte microphone sample rate capability field for the reverse link includes a set of flags that indicate the audio sample rate capability of the microphone in the client device force. For the purpose of MDDI, the client device microphone is configured to support at least a sample rate of at least 8,000 samples per second. The bit positions used in this field are assigned to different sample rates, for example, bits 0, 1, 2, 3, 4, 5, 6, 7 and 8 are used to represent 8,000, 16,000, 24,000, 32,000, 40,000, respectively , 48,000, 11,025, 22,050 and 44,100 samples per second (SPS), and bits 9 to 15 are reserved for future use or as an alternative sample rate as needed, so they are currently set to "0". Setting the bit value of one of these bits to "1" indicates that the specific sample rate is supported, and setting the bit to "0" indicates that the sample rate is not supported. If the microphone is not connected, the sample rate capability bits of each microphone are set to be equal to zero.

The content protection type field (2 bytes) includes a set of flags that indicate the type of digital content protection supported by the display. Currently, bit position 0 is used to indicate when DTCP is supported, bit position 1 is used to indicate when HDCP is supported, and bit positions 2 to 15 are reserved for other protection schemes required or available. Therefore, these bits The element system is currently set to zero.

<b>G. About client request and status packet</b>

The reverse link request field (3 bytes) specifies the number of bytes required by the client to send information to the host in the reverse link in the next subframe.

The CRC error count field (1 byte) indicates how many CRC errors have occurred since the start of the media frame. When sending a sub-frame header packet with a sub-frame count of zero, reset the CRC count. If the actual number of CRC errors exceeds 255, this value is generally saturated to 255.

The ability change field uses 1 byte to indicate the ability of the display to change. like This may happen if the user connects a peripheral device, such as a microphone, keyboard, or display, or due to some other reasons. If the bit [7:0] is equal to 0, the display capability has not changed since the last client capability packet was transmitted. However, if the bit [7:0] is equal to 1 to 255, the display capability has been changed. Check the client capability packet to determine new display characteristics.

<b>H. About bit block transmission packet</b>

The X value and Y value fields of the upper left coordinate of the window use 2 bytes, and each is used to specify the X and Y values of the upper left coordinate of the window to be moved. The window width and height fields use 2 bytes, each of which is used to specify the width and height of the window to be moved. The window X movement and Y movement fields use 2 bytes to specify the number of pixels to move the window in the horizontal and vertical directions, respectively. Generally speaking, the coordinate systems are configured such that when X is a positive value, it causes the window to move to the right, when it is a negative value, it causes the window to move to the left, and when Y is a positive value, it causes the window to move downward, and when it is a negative value, it causes the window to move upward. .

<b>I. About bit mapping area filling packet</b>

The X value and Y value fields of the upper left coordinate of the window use 2 bytes, and each is used to specify the X and Y values of the upper left coordinate of the window to be filled. The window width and height fields (2 bytes each) specify the width and height of the window to be filled. The video data format descriptor field (2 bytes) specifies the format of the pixel area fill value. The format is the same as the same field in the video streaming packet. The pixel area filling value field (4 bytes) includes the pixel value to be filled in the window specified by the above field. The format of this pixel is specified in the video data format descriptor field.

<b>J. About bit-mapped pattern stuffing packet</b>

The X value and Y value fields of the upper left of the window use 2 bytes, each for specifying The X and Y values of the coordinates of the upper left corner of the window to be filled. The window width and height fields (2 bytes each) specify the width and height of the window to be filled. The pattern width and pattern height fields (2 bytes each) specify the width and height of the filled pattern respectively. The 2-byte video data format descriptor field specifies the format of the pixel area padding value. Figure 11 illustrates how to encode the video data format descriptor. The format is the same as the same field in the video streaming packet.

The parameter CRC field (2 bytes) includes the CRC of all bytes from the packet length to the video format descriptor. If the CRC check is incorrect, the entire packet is discarded. The pattern pixel data field includes original video information, which specifies the filling pattern of the format specified by the video data format descriptor. The data is packed into bytes, and the first pixel of each row must be aligned with the byte. The filling pattern data is sent one row at a time. The pattern pixel data CRC field (2 bytes) only includes the pattern pixel data CRC. If the CRC check is incorrect, the pattern pixel data can still be used, but the CRC error count will increase.

<b>K. Communication link data channel packet</b>

The parameter CRC field (2 bytes) includes the 16-bit CRC of all the bytes from the packet length to the packet type. If the CRC check is incorrect, the entire packet is discarded.

The communication link data field includes the original data from the communication channel. This data is simply passed to the computing device in the display.

The communication link data CRC field (2 bytes) only includes the 16-bit CRC of the communication link data. If this CRC check is incorrect, the communication link data can still be used or it is still useful, but the CRC error count will be incremented.

<b>L. About the interface type handover request packet</b>

The interface type field (1 byte) specifies the new interface type to be used. The value in this field specifies the interface type in the following way. If the value of bit 7 is equal to "0", the type handover request is used for the forward link; if the value is equal to "1", the type handover request is used for the reverse link. Bits 6 to 3 are reserved for future use and are generally set to zero. Bits 2 to 0 are used to define the type of interface used. Value 1 means handover to type 1 mode, value 2 means handover to type 2 mode, value 3 means handover to type 3 mode, A value of 4 means handover to type 4 mode. The values "0" and 5 to 7 are reserved for future designation of alternative modes or mode combinations.

<b>M. About the interface type confirmation package</b>

The value of the interface type field (1 byte) confirms the new interface type to be used. The value in this field specifies the interface type in the following way. If bit 7 is equal to "0", the type handover request is for the forward link, or if it is equal to "1", the type handover request is for the reverse link. Bit positions 6 to 3 are currently reserved for specifying other handover types as needed, and are generally set to zero. However, bit positions 2 to 0 are used to define the type of interface used, the value "0" indicates negative confirmation, or the delivery request cannot be performed, and the values "1", "2", "3" and "4" indicate delivery respectively To Type 1, Type 2, Type 3, and Type 4 modes. Values 5 to 7 are reserved for the required alternative mode designation.

<b>N. About the execution type handover packet</b>

The 1-byte interface type field indicates the new interface type to be used. The value in this field specifies the interface type. First, the value of bit 7 is used to determine whether the type handover is used for the forward link or the reverse link. The value "0" indicates that the type handover request is for the forward link, and the value "1" is for the reverse link. Bit 6 to 3 are reserved for future use, so they are generally set to a value of zero. However, bits 2 to 0 are used to define the type of interface to be used, and the values 1, 2, 3, and 4 specify handover to Type 1, Type 2, Type 3, and Type 4 modes, respectively. The values 0 and 5 to 7 of these bits are reserved for future use.

<b>O. About the forward audio channel activation packet</b>

The audio channel activation mask field (1 byte) includes a set of flags that indicate which audio channel should be activated in the client. A bit set to one activates the corresponding channel, and a bit set to zero deactivates the corresponding channel. Bits 0 to 5 specify channels 0 to 5, which address the left front, right front, left rear, right rear, front center, and subwoofer channels, respectively. Bits 6 to 7 are reserved for future use and are generally set equal to zero at the same time.

<b>P. About the reverse audio sample rate packet</b>

The audio sample rate field (1 byte) specifies the digital audio sample rate. The value of this field is assigned to different sample rates, where bit positions 0, 1, 2, 3, 4, 5, 6, 7 and 8 are used to specify 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, respectively , 11,025, 22,050 and 44,100 samples per second (SPS), and bits 9 to 254 are reserved for the required alternative sample rate, so they are currently set to "0". The value 255 is used to disable the reverse link audio stream.

The sample format field (1 byte) specifies the format of the digital audio sample. When the bit [1:0] is equal to "0", the digital audio sample is in linear format, when it is equal to 1, the digital audio sample is<i>μ</i>-Law format, when it is equal to 2, the digital audio samples are in A-Law format. Bits [7:2] are reserved for alternatively specifying the required audio format, and are generally set equal to zero.

<b>Q. About the digital content protection management information package</b>

The content protection type field (1 byte) specifies the digital content protection method used. The value "0" indicates Digital Transmission Content Protection (DTCP), and the value 1 indicates High Bandwidth Digital Content Protection System (HDCP). The value range of 2 to 255 has not yet been specified and is reserved for the required alternative protection schemes. The content protection management message field is a variable length field, which includes the content protection message transmitted between the host and the client.

<b>R. About transparent color actuation packet</b>

The transparent color activation field (1 byte) specifies when to activate or deactivate the transparent color mode. If the bit 0 is equal to 0, the transparent color mode is disabled; if it is equal to 1, the transparent color mode is activated, and the transparent color is specified by the following two parameters. Bits 1 to 7 of this byte group are reserved for future use, and are usually set equal to zero.

The video data format descriptor field (2 bytes) specifies the format of the pixel area fill value. Figure 11 illustrates how to encode the video data format descriptor. The format is generally the same as the same field in the video streaming packet.

The pixel area filling value field uses 4 bytes, which are allocated for the pixel value to be filled in the above-mentioned window. The format of this pixel is specified in the video data format descriptor field.

<b>S. About the round-trip delay measurement packet</b>

The 2-byte packet length field specifies the total number of bytes in the packet (not including the packet length field), and is selected to have a fixed length of 159 in a specific embodiment. The 2-byte packet type field uses a value of 82 to identify the packet type, which identifies the packet type as a round-trip delay measurement packet. As mentioned above, reserve the hClient ID field for future use as the client ID, and generally set this field to zero.

In a specific embodiment, the parameter CRC field (2 bytes) includes the 16-bit CRC of all the bytes from the packet length to the packet type. If the CRC check is incorrect, the entire packet is discarded.

The guard time 1 field (here 64 bytes) is used to enable the MDDI_Data line driver in the client to activate before the line driver in the host is disabled. The user terminal activates its MDDI_Data line driver in bit 0 of guard time 1, and the host disables its line driver before the last bit of guard time 1, making it completely deactivated. During guard time 1, when the host and the client are not disabled, both drive a logic zero level. Another purpose of this field is to ensure that all MDDI_Data signals are at the logic zero level for a sufficient period of time so that the client can only use MDDI_Stb to start recovering the clock or clock signal before disabling the line driver of the host. .

The measurement period field is a 64-byte window to allow the client to respond with two-byte 0xff and 30-byte 0x0 at half the data rate used on the forward link. This data rate corresponds to the reverse link rate divisor 1. At the time when it feels the beginning of the measurement period, the client immediately returns this response. A host will accurately receive the response from the client after the link back and forth delay after the start of the first bit of the measurement period at the host plus the logic delay of the client.

The all-zero field (2 bytes) contains zeros so that the MDDI_Data line driver in the host and the client overlaps, so that the MDDI_Data is always driven. The host activates the MDDI_Data line driver during bit 0 of guard time 2, and the user terminal also drives the signal to a logic zero level, just as the user terminal is measuring Do the same at the end of the measurement period.

The value in the Guard Time 2 field (64 bytes) allows the overlap of the measurement period driven by the client when the round-trip delay reaches the maximum amount that can be measured in the measurement period. The user terminal disables its line driver during bit 0 of guard time 2, and the host activates its line driver immediately after the last bit of guard time 2. During guard time 2, when the host and the client are not disabled, both drive a logic zero level. Another purpose of this field is to ensure that all MDDI_Data signals are at the logic zero level for a sufficient time, so that after the line driver of the host is activated, the user terminal can use MDDI_Data0 and MDDI_Stb to start recovering the clock signal.

<b>T. About the forward link skew calibration packet</b>

In a specific embodiment, the parameter CRC field (2 bytes) includes the 16-bit CRC of all the bytes from the packet length to the packet type. If the CRC check is incorrect, the entire packet is discarded.

The calibration data sequence field contains a 512-byte data sequence, which toggles the MDDI_Data signal in each data cycle. During the processing of the calibration data sequence, the MDDI host controller sets all MDDI_Data signals equal to the strobe signal. When the user-side display receives the calibration data sequence field, the display clock recovery circuit should only use MDDI_Stb instead of MDDI_Stb Xor MDDI_Data0 to recover the data clock. Depending on the exact phase of the MDDI_Stb signal at the beginning of the calibration data sequence field, the calibration data sequence will generally be one of the following according to the type of interface used when sending this packet: Type 1 -0xaa, 0xaa...or 0x55, 0x55... Type 2 -0xcc, 0xcc...or 0x33, 0x33... Type 3-0xf0, 0xf0... or 0x0f, 0x0f... Type 4-0xff, 0x00, 0xff, 0x00... or 0x00, 0xff, 0x00, 0xff...

Figure 62A and Figure 62B show examples of possible MDDI_Data and MDDI_Stb waveforms for Type 1 and Type 2 interfaces, respectively.

XVII. Conclusion

When different specific embodiments of the present invention have been described above, it must be understood that they are presented by way of examples only, and are not intended to constitute limitations. Therefore, the breadth and scope of the present invention are not limited to any of the above-mentioned exemplary embodiments, but should be defined only according to the following patent application scope and its equivalent content.

<p>1Conditions</p><p>2Conditions</p><p>3Conditions</p><p>4Conditions</p><p>5Conditions</p><p>6Conditions</p><p>100Portable or laptop computer</p><p>102Wireless phone or PDA device</p><p>104Display device</p><p>106Display device</p><p>108Audio Reproduction System</p><p>110Communication link</p><p>112Audio Reproduction System</p><p>114Larger display or screen</p><p>116Image Projector</p><p>130Portable or laptop computer</p><p>134 "Internal"display device</p><p>136Audio Reproduction System</p><p>138Communication link</p><p>140Wireless phone or PDA device</p><p>144 "Internal"display device</p><p>146Audio Reproduction System</p><p>148Communication link</p><p>202Host</p><p>202'Host</p><p>204Client</p><p>204'Client</p><p>206Two-way communication channel</p><p>208forward link</p><p>210Reverse link</p><p>402MDDI Link Controller</p><p>404MDDI Link Controller</p><p>406Two-way communication channel</p><p>502MDDI Link Controller</p><p>504MDDI Link Controller</p><p>506Two-way communication channel</p><p>3502Delay</p><p>3504Delay</p><p>3600CRC generator and checker</p><p>3602CRC register</p><p>3604Multiplexer</p><p>3606Multiplexer</p><p>3608NAND gate</p><p>3610NOR gate</p><p>3612Exclusive OR (XOR) gate</p><p>3614AND gate</p><p>4002DATA signal</p><p>4004STB signal</p><p>4006Clock signal</p><p>4100Transmission part</p><p>4102Intermediate signal path</p><p>4104D-type flip-flop circuit components</p><p>4106D-type flip-flop circuit components</p><p>4108Differential Line Driver</p><p>4110Differential line driver</p><p>4112Logic element</p><p>4120Receiving part</p><p>4122Differential line receiver</p><p>4124Differential line receiver</p><p>4126Logic element</p><p>4128D-type flip-flop circuit</p><p>4130D-type flip-flop circuit</p><p>4132Delay element</p><p>4202Host Controller</p><p>4204Display Controller</p><p>4206Communication link</p><p>4210Drive</p><p>4212Drive</p><p>4214Drive</p><p>4220Voltage source</p><p>4222Client Data Processing Receiver</p><p>4226Sixth drive</p><p>4900State Machine</p><p>4902Get synchronization status</p><p>4904Sync frame status</p><p>4906Get synchronization status</p><p>4908Synchronizing status</p><p>4910Synchronizing status</p><p>4912Synchronizing status</p><p>5000State Machine</p><p>5302First area</p><p>5304Second area</p><p>5306The third area</p><p>5502State Machine</p><p>5702Cable</p><p>5704Flip-Flop</p><p>5706Flip-Flop</p><p>5708Drive</p><p>5710Drive</p><p>5722Receiver</p><p>5724Receiver</p><p>5728Receiver Flip-Flop</p><p>5732Receiver Flip-Flop</p><p>5736XOR gate</p><p>5904Transmitter Flip-Flop</p><p>5908Transmitter Driver</p><p>5922Receiver line receiver</p><p>6600CRC override mechanism or device</p><p>6602Error detector or detection component</p><p>6604Error code generator or component</p><p>6606CRC value comparator or comparison component</p><p>6610Error code selector or select component or device</p><p>6612Error code CRC overwrite device or overwrite mechanism or component</p><p>6702Step</p><p>6704Step</p><p>6706Step</p><p>6708Step</p><p>6710Step</p><p>6712Step</p><p>6714Step</p><p>6716Step</p><p>6722Step</p><p>6724Step</p><p>6726Step</p><p>6728Step</p><p>4216aTerminal resistor</p><p>4216bTerminal resistor</p><p>4216cTerminal resistor</p><p>4216dTerminal resistor</p><p>4216eTerminal resistor</p><p>4216fTerminal resistor</p><p>4218aResistor</p><p>4218bResistor</p><p>5504, 5508Processor</p><p>5732aDelay</p><p>5928Receiver Flip-Flop</p><p>5930Receiver Flip-Flop</p><p>5932Receiver Flip-Flop</p><p>61-65Conditions</p>

Further characteristics and advantages of the present invention, as well as the structure and operation of various specific embodiments of the present invention, will be described in detail below with reference to the accompanying drawings. In the drawings, the same reference number usually indicates the same, functionally similar, and/or structurally similar element or processing step, and the first appearance of the element is represented by the leftmost digit in the reference number.

FIG. 1A illustrates the basic environment in which a specific embodiment of the present invention can operate, including the use of a micro display device or a projector used in combination with a portable computer or other data processing device.

FIG. 1B illustrates the basic environment in which the specific embodiment of the present invention can operate, including the use of a micro-display device or a projector and an audio presentation element used in combination with a wireless transceiver.

Figure 1C illustrates a basic loop in which specific embodiments of the present invention can operate Environment, including the use of internal display or audio presentation devices used in conjunction with portable computers.

Figure 1D illustrates a basic environment in which specific embodiments of the present invention can operate, including the use of internal display or audio presentation components used in conjunction with wireless transceivers.

Figure 2 illustrates the overall concept of a mobile digital data interface with a host and a client interconnection.

FIG. 3 illustrates the structure of a packet used to realize data transmission from the client device to the host device.

Figure 4 illustrates the use of the MDDI link controller and the types of signals transmitted between the host and the client through the physical data link conductor of the type 1 interface.

Figure 5 illustrates the use of the MDDI link controller and the types of signals transmitted between the host and the client through the physical data link conductors of the second, third, and fourth interfaces.

Figure 6 illustrates the structure of the frame and sub-frames used to implement the interface protocol.

Figure 7 illustrates the general packet structure used to implement the interface protocol.

Figure 8 illustrates the format of the sub-frame header packet.

Figure 9 illustrates the format and content of the filler message packet.

Figure 10 illustrates the format of a video streaming packet.

11A to 11E illustrate the format and content of the video data format descriptor used in FIG. 10.

Figure 12 illustrates the use of packaged and unpackaged data formats.

Figure 13 illustrates the format of the audio streaming packet.

Figure 14 illustrates the use of data byte alignment and packaging PCM format.

Figure 15 illustrates the format of a user-defined data stream packet.

Figure 16 illustrates the format of the color mapping packet.

Figure 17 illustrates the format of the reverse link encapsulated packet.

Figure 18 illustrates the format of the client capability packet.

Figure 19 illustrates the format of the keyboard data packet.

Figure 20 illustrates the format of the pointer device data packet.

Figure 21 illustrates the format of a link close packet.

Figure 22 illustrates the format of the client request and status packet.

Figure 23 illustrates the format of a bit block transmission packet.

Figure 24 illustrates the format of the bitmap area padding packet.

Figure 25 illustrates the format of a bit-mapped pattern padding packet.

Figure 26 illustrates the format of the data channel packet of the communication link.

Figure 27 illustrates the format of the interface type handover request packet.

Figure 28 illustrates the format of the interface type confirmation packet.

Figure 29 illustrates the format of an execution type handover packet.

Figure 30 illustrates the format of the forward audio channel activation packet.

Figure 31 illustrates the format of a reverse audio sample rate packet.

Figure 32 illustrates the format of a digital content protection management information packet.

Figure 33 illustrates the format of a transparent color activation packet.

Figure 34 illustrates the format of the round-trip delay measurement packet.

Figure 35 illustrates the timing of events in the round-trip delay measurement packet.

Figure 36 illustrates a sample implementation of the CRC generator and checker that can be used to implement the present invention.

Figure 37A illustrates the CRC signal used in the device of Figure 36 when transmitting data packets Timing.

FIG. 37B illustrates the timing of the CRC signal used in the device of FIG. 36 when receiving a data packet.

Figure 38 illustrates the processing steps for a typical contention-free service request.

Fig. 39 illustrates the processing steps of a typical service request that is used to determine after the link restart sequence has started that is in competition with the link start.

Figure 40 illustrates how DATA-STB encoding can be used to send a data sequence.

Figure 41 illustrates a circuit that can be used to generate DATA and STB signals from input data at the host and then restore the data on the user side.

Figure 42 illustrates drivers and terminating resistors that can be used to implement a specific embodiment.

Figure 43 illustrates the steps and signal levels used by the client to ensure services from the host and the host to provide such services.

Figure 44 illustrates the relative interval between transitions on Data0, other data lines (DataX), and strobe lines (Stb).

Figure 45 illustrates the response delay that can occur when the host disables the host driver after a packet is transmitted.

Figure 46 illustrates the response delay that can occur after the host activates the host driver to transmit a packet.

Figure 47 illustrates the relationship between the data transmission timing and the host receiver input between the front and back edges of the strobe pulse.

Figure 48 illustrates the switching characteristics and the corresponding client output delay developed from the reverse data timing.

Figure 49 illustrates the signal processing steps and conditions that can be synchronized using a state machine The high-level graph.

Figure 50 illustrates the typical amount of delay encountered in signal processing on the forward and reverse paths in a system using MDDI.

Figure 51 illustrates the marginal round-trip delay measurement.

Figure 52 illustrates the reverse link data rate change.

Figure 53 illustrates a graph of the reverse rate divisor value versus the forward link data rate.

Figures 54A and 54B illustrate the steps taken in the interface operation.

Figure 55 illustrates a schematic diagram of the interface device processing a packet.

Figure 56 illustrates the format of the forward link packet.

Figure 57 illustrates the typical values used for propagation delay and skew in the Type 1 link interface.

Figure 58 illustrates the data, Stb and clock recovery timing on the Type 1 link for exemplary signal processing through the interface.

Figure 59 illustrates the typical values of propagation delay and skew in a Type 2, Type 3, or Type 4 link interface.

Figures 60A, 60B, and 60C respectively illustrate different possibilities for the timing of two data signals and MDDI_Stb, which are ideal, earlier and later, relative to each other.

Figure 61 illustrates an exemplary connector for interface pin designation used with Type 1/Type 2 interfaces.

Figures 62A and 62B illustrate possible MDDI_Data and MDDI_Stb waveforms for both Type 1 and Type 2 interfaces, respectively.

Figure 63 illustrates a high-level diagram of alternative signal processing steps and conditions that can be synchronized using a state machine.

Figure 64 illustrates an exemplary relative timing between a series of clock cycles and various reverse link packet bit and divisor value timings.

Fig. 65 illustrates an exemplary error code transmission process.

Figure 66 illustrates a device that facilitates error code transmission processing.

Fig. 67A illustrates error code transmission processing for code overload.

Fig. 67B illustrates error code transmission processing for code reception.

Figure 68A illustrates the processing steps for host-initiated wake-up.

Figure 68B illustrates the processing steps for the wake-up initiated by the client.

FIG. 68C illustrates the processing steps of the wake-up initiated by the competing host and the client.

Figure 69 illustrates the format of a request VCP feature packet.

Figure 70 illustrates the format of a VCP feature response packet.

Figure 71 illustrates the format of the VCP feature response list.

Figure 72 illustrates the format of setting the VCP feature packet.

Figure 73 illustrates the format of a request valid parameter packet.

Figure 74 illustrates the format of a valid parameter response packet.

Figure 75 illustrates the format of the α-Cursor Video Capability Packet.

Figure 76 illustrates the format of an alpha-cursor transparency map packet.

Fig. 77 illustrates the format of the α-Cursor Image Offset Packet.

Figure 78 illustrates the format of an alpha-cursor video streaming packet.

Figure 79 illustrates the format of the zoom video streaming capability packet.

Figure 80 illustrates the format of the zoom video stream setting packet.

Figure 81 illustrates the format of the zoom video stream confirmation packet.

Figure 82 illustrates the format of a zoomed video streaming packet.

Figure 83 illustrates the format of a request specific status message packet.

Figure 84 illustrates the format of a valid status reply list packet.

Figure 85A illustrates the format of a packet processing delay parameter packet.

Figure 85B illustrates the format of the delay parameter list item.

Figure 86 illustrates the format of the personal display capability packet.

Figure 87A illustrates the format of a client error report packet.

Figure 87B illustrates the format of the error report list items.

Figure 88 illustrates the format of the client identification packet.

Figure 89 illustrates the format of the Alternate Display Capability Packet.

Figure 90 illustrates the format of the register access packet.

Figures 91A to 91C illustrate the use of two display buffers to reduce visible artifacts.

Figure 92 illustrates two buffers showing refreshing faster than image transmission.

Figure 93 illustrates two buffers showing refreshing slower than image transmission.

Figure 94 illustrates two buffers that display refreshing much faster than image transmission.

Figure 95 illustrates three buffers that display refresh faster than image transmission.

Figure 96 illustrates three buffers showing refreshing slower than image transmission.

Figure 97 illustrates a buffer that displays refresh faster than image transmission.

Figure 98 illustrates the connection between the host and the client via a daisy chain and hub.

Figure 99 illustrates a client device connected via a combination of hub and daisy chain.

Figure 100 illustrates one-color mapping.