HK1114272A - A signal interface for higher data rates - Google Patents

Description

Signal interface for higher data rates

Cross Reference to Related Applications

This patent application claims the priority of provisional patent application No. 60/494,983, entitled "MDDISpecification advances," filed on 13/8/2003 and assigned to the present assignee and is expressly incorporated herein by reference.

Technical Field

Embodiments of the invention in this disclosure relate to a digital signal protocol and process for signaling or signal transfer at high data rates between a host device and a client device. More particularly, the present disclosure relates to a technique for transferring multimedia and other types of digital signals from a host or controller device to a client device for presentation or display to an end user using a low power, high data rate transfer mechanism with internal and external device applications.

Background

In recent years, significant advances have been made in computers, video game-related products, and various video technologies (e.g., DVD and high-definition VCR) to provide end-users of such devices with increasingly higher resolution still, video-on-demand, and graphical images, including even certain types of text. These advances in turn require the use of higher resolution electronic viewing devices, such as high definition video monitors, HDTV monitors, or dedicated image projection elements. For example, when using CD-type sound reproduction, DVD, and other devices that also have an associated audio signal output, such visual images are combined with high definition or high quality audio data to create a more realistic, richer, or more realistic multimedia experience for the end user. In addition, high mobility, high quality sound systems and music delivery mechanisms, such as MP3 players, have been developed to present pure audio to end users. This has led to an increasing habit and desire for high quality or premium quality output by typical users of commercial electronic devices, from computers to televisions and even telephones.

In a typical video presentation scenario, video data related to electronic products is typically transmitted at a rate on the order of one to tens of kilobits per second using current techniques, and this rate is preferably referred to as slow or medium. These data are then buffered or stored in temporary or long term memory devices for delayed (later) playout at the desired viewing device. For example, images may be transferred "over" or using the internet using a program resident on a computer having a modem or internet connection device to receive or transmit data that can be used to digitally represent images. Similar transmissions can be made using wireless devices such as portable computers equipped with wireless modems, wireless Personal Digital Assistants (PDAs), or wireless telephones.

Once received, the data is stored in situ in a memory element, circuit or device, such as in RAM or flash memory, including in an external storage device for playback. Depending on the amount of data and image resolution, playback may begin sooner or be presented with a long delay. That is, in some cases, for small images or low resolution images that do not require large amounts of data or use some sort of buffering, some real-time playback is allowed, so that some content is presented with less delay while more content is still in transit. This transfer is suitably (reasonable) transparent to the end user of the viewing device once the presentation has started, provided that no interruption of the transfer link occurs.

Data used to produce still images or motion video is often compressed using one of several well-known techniques, such as those specified by the Joint Photographic Experts Group (JPEG), Moving Picture Experts Group (MPEG), and other standard organizations or companies well known in the media, computer, and communications industries, to accelerate the transfer of data over a communication link. These techniques use a smaller number of bits to transmit a given amount of information, allowing faster transmission of images or data.

Once the data is transferred to a "local" device, such as a computer or other receiver device, the resulting information is decompressed (or played using a special decoding player), decoded if necessary, and prepared for appropriate rendering based on the corresponding available rendering resolution and control elements. For example, typical computer video resolutions represented by an X by Y pixel screen resolution typically range from as low as 480 by 640 pixels to 600 by 800 to 1024 by 1024 pixels, although various other resolutions are generally possible as needed or desired.

Image presentation is also affected by the image content and the ability of a given video controller to manipulate the image in terms of certain predetermined color levels or color concentrations (bits per pixel used to generate the color) and intensities, as well as any additional overhead bits employed. For example, typical computer presentations expect about 8 to 32 bits or more per pixel to represent various colors (shades and hues), although other values are also encountered.

From the above values, it can be seen that a given screen image will require the transfer of around 2.45 megabits (Mb) to 33.55Mb of data, respectively, over a range of typical resolutions and densities from lowest to highest. When viewing video or motion type images at a rate of 30 frames per second, the amount of data required is about 73.7 to 1,006 megabits per second (Mbps), or about 9.21 to 125.75 megabytes per second (Mbps). In addition, one may wish to present audio data with images, such as a multimedia presentation, or as separate high resolution audio presentations, such as CD quality music. Additional signals handling interactive commands, controls, or signals may also be employed. Each of these options adds more data to the transfer. In any case, when one wishes to deliver high quality or high resolution image data and high quality audio information or data signals to an end user in order to create a rich-content experience, a link with a high data transfer rate is required between the rendering element and a source or host device configured to provide such data.

Typically, data rates on the order of 115 kilobytes (kBps) or 920 kilobits per second (kBps) can be handled by modern serial interfaces. Other interfaces, such as USB serial interfaces, can support data transfers at rates up to 12MBps, while dedicated high speed transfers, such as those configured using the Institute of Electrical and Electronics Engineers (IEEE)1394 standard, can occur at rates on the order of 100 to 400 MBps. Unfortunately, these rates have failed to achieve the desired high data rates noted above, which are desired for the purpose of being able to be used by future wireless data devices and services to provide high resolution, content rich output signals to drive portable video displays or audio devices. In addition, these interfaces require the use of a significant number of hosts or systems and guest software to operate. Their software protocol stacks also create an unnecessarily large amount of overhead, especially when mobile wireless devices or telephony applications are considered. Such devices have severe memory and power consumption limitations, as well as being already burdened with computational power. In addition, some interfaces use bulky cables that are too heavy and unsatisfactory for aesthetic mobile applications or utilize complex connectors that add cost or are too power hungry.

There are also other known interfaces such as analog Video Graphics Adapter (VGA), Digital Video Interactive (DVI) or Gigabit Video Interface (GVIF). The first two of these interfaces are parallel type interfaces for processing data at higher transfer rates, but they also employ heavy cables and consume large amounts of power, on the order of a few watts. None of these features are available for use with portable consumer electronic devices. Even the third interface consumes too much power and uses expensive or bulky connectors.

There is another major drawback to some of the above interfaces, as well as other very high rate data systems/protocols or transfer mechanisms associated with data transfer of fixedly mounted computer devices. Considerable power and/or operation with large currents is also required to support the required data transfer rates. Doing so greatly reduces the availability of this technology for consumer-oriented high-mobility products.

Generally, to support such data transfer rates, the use of alternatives such as fiber-optic type connections and transmission elements also requires a number of additional switches and elements, which are more complex and costly than what is really required for consumer-oriented commercial products. To date, their power requirements and their complexity have prevented their widespread use in portable, low power, portable applications, in addition to the very expensive nature of optical systems in general.

Lacking in the portable, wireless or mobile application industries is a technology that: a high quality presentation experience is provided to a high mobility end user, whether it be audio, video or multimedia based. That is, when using portable computers, wireless telephones, PDAs, or other high mobility communication devices or appliances, the video and audio presentation systems or devices currently in use are simply not able to deliver output at the desired high quality levels. The perceived lack of quality is often a result of the inability to achieve the high data rates required to transmit high quality presentation data. This includes transfer to more efficient, advanced or feature-full external devices for presentation to end-users, or between a host and a client within a portable device such as a computer, gaming device, or the like, as well as between a host and a wireless device including one such as a mobile phone.

In the latter case, a great step has been taken in adding higher and higher resolution internal video screens and other professional input and/or output devices, and connecting to wireless devices such as so-called third generation phones and so-called laptop computers. However, the internal data bus and connections may include bridging rotating or sliding hinges or hinge-like structures that mount or connect the video screen or other components to the main housing in which the host and/or various other control elements and output components are mounted. It is very difficult to construct a high throughput data transfer interface using existing techniques, such as in wireless telephones, which require up to 90 wires to achieve the desired throughput. There are a number of challenges to do so with respect to manufacturing, cost constraints, and reliability.

Therefore, a new transfer mechanism is needed to improve data throughput between a host device providing data and a client display device or element presenting output to an end user.

The applicants have proposed this new Transfer mechanism in currently granted U.S. patent applications entitled "Generating and distributing a Communication Protocol and Interface for High DataRate Signal Transfer," both assigned to the assignee of the present invention and incorporated herein by reference, serial numbers 10/020,520 and 10/236,657. The techniques discussed in these applications can greatly increase the transfer rate of large amounts of data in high speed data signals. However, there is an increasing demand for ever increasing data rates, particularly rates involving video presentation. Even with other advances being developed in the art of data signal utilization, there is a continuing need for further increases in transmission rates, increases in communication link efficiency, and makes communication links more robust. Accordingly, there remains a need to develop new or improved delivery mechanisms for improving data throughput between host and client devices.

Disclosure of Invention

The above-mentioned and other deficiencies in the art are addressed by embodiments of the present invention in which new protocols and data transfer means, methods and mechanisms for transferring data at high data rates between a host device and a recipient client device have been developed.

Embodiments of the present invention are directed to a Mobile Data Digital Interface (MDDI) that transfers digital data at high rates between a host device and a client device via a communication path, which employs a plurality or series of linked data packet structures to form a communication protocol for communicating a preselected set of digital control and presentation data between the host and client devices. The signal communication protocol or link layer is used by the physical layer of the host or client link controller. At least one link controller residing in the host device is coupled to the client device via a communication path or link and is configured to generate, transmit, and receive data packets forming a communication protocol and form the digital presentation data into one or more types of data packets. The interface provides bi-directional transfer of information between the host and client, which can reside within a common unitary housing or support structure.

The implementation is typically all digital in nature, except for differential drivers and receivers, which can be easily implemented on digital CMOS chips, require around 6 signals, and can operate at almost any data rate that is extremely convenient for system designers. The simplicity of the physical and link layer protocols facilitates integration, and the simplicity coupled with the sleep state allows the portable system to have very low system power consumption.

To facilitate use and acceptance, the interface will add little cost to the device, can allow for the consumption of little power while powering the display via the interface using standard battery voltages, and can enable the device to have a pocket-able form factor. The interface is scalable to support resolutions above HDTV, supports synchronized stereoscopic video and 7.1 audio for display devices, performs conditional updates to any screen area, and supports multiple data types bi-directionally.

According to another aspect of an embodiment of the present invention, at least one client link controller or client receiver is disposed in a client device and coupled to the host device via a communications path or link. The client link controller is also configured to generate, transmit, and receive data packets forming a communication protocol, and to form the digital presentation data into one or more types of data packets. Generally, the host or link controller employs a state machine to process data packets for use in command or some type of signal preparation and query processing, but can use a slower general purpose processor to manipulate data and some less complex packets for the communication protocol. The host controller comprises one or more differential line drivers; and the client receiver comprises one or more differential line receivers coupled to the communication path.

The data packets are combined in media frames that have a predefined fixed length, which are communicated between the host and client devices using a predetermined number of data packets having different variable lengths. The data packets each include a packet length field, one or more packet data fields, and a cyclic redundancy check field. The sub-frame header packet is transmitted or positioned at the beginning of other packet transmissions from the host link controller. The communication protocol uses one or more video stream type packets and audio stream type packets to transfer video type data and audio type data, respectively, from the host to the client via the forward link for presentation to the client device user. The communication protocol uses one or more reverse link encapsulation type packets to transfer data from the client device to the host link controller. In some embodiments, these transfers include transferring data from an internal controller having at least one MDDI device to an internal video screen. Other embodiments include transmission to an internal sound system, and to an internal host device from a variety of input devices including joysticks and complex keyboards.

Generating, by the host link controller, filler type packets to occupy periods of forward link transmission that are free of data. The communication protocol uses a plurality of other data packets in order to communicate video information. These packets include color mapping, bit block transfer, bitmap area fill, bitmap pattern fill, and transparent color enable type packets. The communication protocol uses user-defined stream type packets to communicate interface-user-defined data. The communication protocol uses keyboard data and pointing device data type packets to transfer data to and from user input devices associated with the client device. The communication protocol uses link shutdown type packets to terminate data transfer in either direction via the communication path.

The communication path typically includes or employs a cable having a series of four or more conductors and a shield. In addition, printed wires or leads, some of which reside on the flexible substrate, may be used as desired.

The host link controller requests display capability information from a client device to determine what types of data and data rates the client can support via the interface. The client link controller communicates display or presentation capability information to the host link controller using at least one display capability type packet. The communication protocol uses a plurality of transfer modes, each allowing a different maximum number of data bits to be transferred over a given time period, each mode being selectable by negotiation between the host and client link controllers. These transmission modes may be dynamically adjusted during data transmission and the same mode need not be used on the reverse link as on the forward link.

In other aspects of some embodiments of the invention, the host device comprises a wireless communication device, such as a wireless telephone, a wireless PDA, or a portable computer having a wireless modem disposed therein. Typical client devices include portable video displays, such as microdisplay devices, and/or portable audio presentation systems. In addition, the host may use a storage module or element to store rendering or multimedia data to be transferred for rendering to the user of the client device.

In yet another aspect of some embodiments, the host device includes a controller or communication link control device having a drive residing within a portable electronic device, such as a wireless communication device, such as a wireless telephone, wireless PDA, or portable computer. A typical client device of this architecture comprises client circuitry, an integrated circuit, or a component coupled to a host computer and resides in the same device and is coupled to an internal video display such as a high resolution screen of a mobile phone and/or a portable audio presentation system.

Drawings

Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements or process steps, and the drawing in which an element first appears is indicated by the leftmost digit(s) in the reference number.

FIG. 1A illustrates a basic environment in which embodiments of the present invention can operate, including the use of a microdisplay device in conjunction with a portable computer.

FIG. 1B illustrates a basic environment in which embodiments of the present invention can operate, including the use of microdisplay devices and audio rendering elements in conjunction with a wireless transceiver.

FIG. 1C illustrates a basic environment in which embodiments of the present invention can operate, including the use of a microdisplay device in conjunction with a portable computer.

FIG. 1D illustrates a basic environment in which embodiments of the present invention can operate, including the use of microdisplay devices and audio rendering elements in conjunction with a wireless transceiver.

Fig. 2 illustrates the general concept of a mobile digital data interface with host and client interconnections.

Fig. 3 illustrates a packet structure for implementing data transfer from a client device to a host device.

Fig. 4 illustrates the use of an MDDI link controller and the types of signals that are passed between the host and client via the physical data link wires of the type I and type U interfaces.

Fig. 5 illustrates the use of an MDDI link controller and the types of signals that are passed between the host and client via the physical data link conductors of the type II, type II and type IV interfaces.

Fig. 6 illustrates a frame structure of frames and subframes for implementing the interface protocol.

Fig. 7 illustrates a general structure of a packet for implementing the interface protocol.

Fig. 8 illustrates the format of a sub-frame header packet.

Fig. 9 illustrates the format and content of the filler data packet.

Fig. 10 illustrates the format of a video stream packet.

Fig. 11 illustrates the format and content of the video data format descriptor of fig. 10.

FIG. 12 illustrates the use of packed and unpacked formats for data.

Fig. 13 illustrates the format of an audio stream packet.

FIG. 14 illustrates byte alignment of data and use of packed PCM format.

Fig. 15 illustrates a user-defined stream packet format.

Fig. 16 illustrates the format of a color map data packet.

Fig. 17 illustrates the format of a reverse link encapsulated packet.

Fig. 18 illustrates the format of the display capability packet.

Fig. 19 illustrates the format of a keyboard data packet.

Fig. 20 illustrates the format of a pointing device data packet.

Fig. 21 illustrates the format of a link shutdown packet.

FIG. 22 illustrates the format of a display request and status packet.

Fig. 23 illustrates the format of a bit block transfer packet.

Fig. 24 illustrates the format of a bitmap area fill packet.

Fig. 25 illustrates the format of a bitmap pattern padding packet.

Fig. 26 illustrates the format of a communication link data lane packet.

Fig. 27 illustrates the format of the interface type switch request packet.

Fig. 28 illustrates the format of the interface type confirm packet.

Fig. 29 illustrates the format of the execution type switching packet.

Fig. 30 illustrates the format of a forward audio channel enable packet.

Fig. 31 illustrates the format of an inverse audio sample rate packet.

Fig. 32 illustrates the format of a digital content protection overhead packet.

FIG. 33 illustrates the format of a transparent color enable packet.

Fig. 34 illustrates the format of a round trip delay measurement packet.

FIG. 35 illustrates the timing of events during a round trip delay measurement packet.

Fig. 36 illustrates an exemplary implementation of a CRC generator and checker for implementing the present invention.

Fig. 37A illustrates the timing of the CRC signal when the device of fig. 36 transmits a data packet.

FIG. 37B illustrates the timing of the CRC signal when the data packet is received by the device of FIG. 36.

Fig. 38 illustrates the processing steps of a typical service request without contention.

Fig. 39 illustrates the processing steps of maintaining (alert) a typical service request after the start of a link restart sequence, and the steps of link initiation contention.

Fig. 40 illustrates how DATA sequences are transmitted using DATA-STB coding.

Fig. 41 illustrates circuitry that may be used to generate DATA and STB signals from input DATA in the host and then recover the DATA in the client.

FIG. 42 illustrates a driver and termination resistance that may be used to implement one embodiment.

FIG. 43 illustrates the steps and signal levels employed by a client to secure a service from a host, and the host to provide such a service.

Fig. 44 illustrates the relative spacing between transitions on Data0, other Data lines (DataX), and strobe lines (Stb).

FIG. 45 illustrates the delay that may occur in response to the host disabling the host drive after the packet is transmitted.

FIG. 46 illustrates the delay that may occur in response to the host enabling the host driver to transmit packets.

FIG. 47 illustrates the relationship between the timing of data being transferred at the input of the host receiver and the leading and trailing edges of the strobe.

Fig. 48 illustrates the reverse data timing induced switching characteristics and corresponding client output delays.

FIG. 49 illustrates a high level diagram of signal processing steps and conditions that can be synchronized using a state machine.

Fig. 50 illustrates typical amounts of delay encountered by signal processing on the forward and reverse paths in a system employing MDDI.

FIG. 51 illustrates edge round trip delay measurements.

Fig. 52 illustrates the variation of the reverse link data rate.

Fig. 53 depicts a graphical representation of the value of the reverse rate divisor as a function of the forward link data rate.

Fig. 54A and 54B illustrate steps performed in the interface operation.

Fig. 55 illustrates an overview of an interface device that processes a packet.

Fig. 56 illustrates the format of a forward link packet.

Fig. 57 illustrates typical values of propagation delay and skew (skew) in a type I link interface.

Fig. 58 illustrates Data, Stb and clock recovery timing on a type I link for exemplary signal processing via the interface.

Fig. 59 illustrates typical values for propagation delay and skew in type II, type III, or type IV link interfaces.

Fig. 60A, 60B, and 60C illustrate different possibilities of timing between two data signals and MDDI _ Stb, corresponding to ideal, early, and late, respectively.

FIG. 61 illustrates interface pin assignments for an exemplary connector for a type I/type II interface.

FIGS. 62A and 62B illustrate possible MDDI _ Data and MDDI _ Stb waveforms for type I and type II interfaces, respectively.

Fig. 63 illustrates a high level diagram of alternative signal processing steps and conditions that enable synchronization using a state machine.

Fig. 64 illustrates exemplary relative timing between a series of clock cycles and timing of various reverse link packet bits and divisor values.

Fig. 65 illustrates an exemplary error code transfer process.

FIG. 66 illustrates a device that may be used for error code transfer processing.

FIG. 67A illustrates an error code transfer process for code reloading.

Fig. 67B illustrates an error code transfer process for receiving a code.

FIG. 68A illustrates the processing steps for a host initiated wake up.

FIG. 68B illustrates the processing steps for client initiated wake up.

FIG. 68C illustrates the process steps for wake-up with competing host and client initiated.

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

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

Fig. 71 illustrates the format of the VCP feature answer list.

FIG. 72 illustrates the format of a set VCP feature packet

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

Fig. 74 illustrates the format of the validity parameter response packet.

Fig. 75 illustrates the format of an alpha cursor image capability packet.

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

Fig. 77 illustrates the format of an alpha cursor image offset packet.

Fig. 78 illustrates the format of an alpha cursor video stream packet.

Fig. 79 illustrates the format of a scalable video stream capability packet.

Fig. 80 illustrates the format of a scalable video stream setup packet.

Fig. 81 illustrates the format of a scalable video stream acknowledgment packet.

Fig. 82 illustrates the format of a scalable video stream packet.

Fig. 83 illustrates the format of a request specific status packet.

Fig. 84 illustrates the format of a valid-state acknowledgement list packet.

Fig. 85 illustrates the format of a packet processing delay parameter packet.

FIG. 86 illustrates the format of a personal display capability data packet.

FIG. 87 illustrates the format of a display error report packet.

Fig. 88 illustrates the format of a display identification packet.

FIG. 89 illustrates the format of an optional display capability packet.

FIG. 90 illustrates the format of a register access packet.

Fig. 91A-91C illustrate the use of two display buffers to reduce visual artifacts.

FIG. 92 illustrates two buffers displaying refreshes faster than image transfers.

FIG. 93 illustrates two buffers that are displayed refreshing slower than image transfer.

FIG. 94 illustrates two buffers that are displayed to refresh much faster than the image transfer.

FIG. 95 illustrates three buffers displaying refreshes faster than image transfers.

FIG. 96 illustrates three buffers that are displayed with refreshes slower than image transfers.

FIG. 97 illustrates one buffer with display refresh faster than image transfer.

Fig. 98 illustrates host-client connections via a daisy chain and hub.

Fig. 99 illustrates client devices connected via a hub and a daisy chain.

Detailed Description

I. Overview

It is a general object of the present invention to provide a Mobile Display Digital Interface (MDDI) that enables or provides a cost-effective, low-power consumption transfer mechanism that enables high-speed or very high-speed data transfer over a close-range communication link between a host device and a client device, such as a display element, using a "serial" type data link or channel, as described below. This mechanism is suitable for implementation with small connectors and thin flexible cables that are particularly suitable for connecting internal (to the housing or stand) display elements or input devices to a central controller or external display elements or devices such as wearable micro-displays (goggles or projectors) to portable computers, wireless communication devices or entertainment devices.

It is an advantage of embodiments of the present invention to provide a technique for data transfer that is low in complexity, low in cost, highly reliable, well suited to the environment of use, and very stable while maintaining very high flexibility.

Embodiments of the present invention may be used in a variety of situations to transfer or transfer large amounts of data, typically used for audio, video or multimedia applications, from a host or source device that generates or stores such data to a client display or rendering device at a high rate. One typical application discussed below is data transfer from a portable computer, wireless telephone or modem to a visual display device, for example a small video screen or a wearable micro-display appliance (micro-display appliance), such as in the form of a visor or helmet containing a small projection lens and screen, or within such a component from a host to a client device. That is, from the processor to an internal screen or other presentation element, and from various internal input devices or external input devices employing clients to an internally mounted (together within the same device housing or support structure) host.

The characteristics or attributes of MDDI are not dependent on the particular display technology. This is a highly flexible mechanism for transferring data at high rates, regardless of the internal structure of the data, or the functional aspects of the data or commands it executes. It allows the timing of the data packets being transmitted to be adjusted to suit the characteristics of the particular client device, such as the unique display requirements of certain devices, or to meet the combined audio and video requirements of certain a-V systems or certain input devices like joysticks, touch pads, and the like. Such an interface need not know what display elements or client devices are employed as long as they comply with the selected protocol. In addition, the overall serial link data or data rate can vary by orders of magnitude, which enables designers of communication systems or host devices to optimize cost, power requirements, complexity of client devices, and update speed of client devices.

Such data interfaces are primarily used to transfer large amounts of high-rate data via "wired" signal links or small cables. However, certain applications may also utilize wireless links, including optical-based links, as long as the links are configured to use the same data packets and data structures developed for this interface protocol and are able to achieve the desired level of transmission with sufficiently low power consumption or complexity to maintain practicality.

II. Environment

A typical application can be seen in fig. 1A and 1B, which show a portable or laptop computer 100 and a wireless telephone or PDA device 102 communicating data with display devices 104 and 106 and audio reproduction systems 108 and 112, respectively. In addition, FIG. 1A shows potential connections to a larger display or screen 114 or image projector 116, which are shown in only one figure for clarity, but which may also be connected to the wireless device 102. The wireless device may be currently receiving data or have pre-stored a certain amount of multimedia type data in a memory element or device for later presentation to an end user of the wireless device for viewing and/or listening. Since most of the time a typical wireless device is used for voice and simple text communications, it has a relatively small display screen and a simple audio system (speaker) to convey information to the user of the device 102.

The computer 100 has a very large screen, but the external sound system is still inadequate and still does not reach the level of other multimedia presentation devices such as high definition television or movie screens. The computer 100 is used for illustrative purposes, and other types of processors, interactive video games, or consumer electronics devices may be used with the present invention. The computer 100 may be capable of wireless communication using a wireless modem or other embedded device, or connected to such a device using a cable or wireless link, as desired, but is not limited to such.

This is not sufficient to enable the presentation of more complex or "rich" data to provide a beneficial or pleasant experience. Accordingly, the industry is developing other mechanisms and devices to present information to end users and to provide a desired minimum level of enjoyment or positive feel.

As previously mentioned, several types of display devices have been developed or are currently being developed to present information to the end user of device 100. For example, one or more companies have developed sets of wearable goggles for projecting images in front of the eyes of a user of the device to present a visual display. When correctly positioned, such devices can effectively "project" a virtual image, as perceived by the user's eyes, that is much larger than the elements that provide the visual output. That is, the very small projection elements allow the user's eyes to "see" a much larger image than would be seen with a typical liquid crystal screen or the like. The use of a larger virtual screen image also allows the use of images of much higher resolution than can be obtained with a more limited LCD screen display. Other display devices may include, but are not limited to, a small LCD screen or various flat panel display elements, a projection lens and display driver for projecting an image onto a surface, and the like.

There are additional elements connected to, or associated with, the use of the wireless device 102 or the computer 100 to present an output to other users or to other devices that also transmit signals elsewhere or store signals. For example, data may be stored in flash memory, in optical form, e.g., using a writable CD medium, stored or stored on a magnetic medium such as a tape recorder or the like for later use.

In addition, many wireless devices and computers currently have built-in MP3 music decoding capabilities, as well as other advanced sound decoders and systems. Typically, portable computers utilize CD and DVD playback capabilities, and some also have small dedicated flash memory readers to receive pre-recorded audio files. The problem with this capability is that: digital music files allow a highly increased feature rich experience, but only if the decoding and playing process can keep up. This is also true for digital video files.

To assist in sound reproduction, an external speaker 114 is shown in fig. 1A, with additional elements such as a subwoofer or "surround sound" speakers for front-to-back sound projection. Also, a speaker or earpiece 108 is shown as a form of mechanism embedded in the cradle or microdisplay device 106 of FIG. 1B. Other audio or sound reproduction elements including power amplification or sound shaping devices may also be used, as is well known.

In any case, as described above, high data rates are required when one wishes to transmit high quality or high resolution image data and high quality audio information or data signals from a data source to an end user via one or more communication links 110. That is, the transport link 110 is clearly a potential bottleneck in the data communication process, as discussed earlier, and limits system performance because current transport mechanisms are unable to achieve the high data rates that are typically desired. As described above, for higher image resolutions of 1024 × 1024 pixels, color density of 24 ~ 32 bits per pixel, and data rate at 30fps, for example, the data rate can approach a rate exceeding 755Mbps or higher. In addition, such images may be presented as part of a multimedia presentation that includes audio data and potentially additional signals to handle interactive games or communications, or various commands, controls or signals, which further increases the amount of data and data rate.

It is also apparent that the fewer cables or interconnections required to establish a data link means that the mobile device associated with the display is easier to use and more likely to be employed by more users. This is especially true in the case where multiple devices are typically used to create a full audio-visual experience, and is more pronounced as the quality levels of the display and audio output devices increase.

Other exemplary applications of the above and other improvements relating to video screens and other output or input devices can be seen in fig. 1C and 1D, which show a portable or laptop computer 130 and a wireless telephone or PDA device 140 communicating data with "internal" display devices 134 and 144 and audio reproduction systems 136 and 146, respectively.

In fig. 1C and 1D, the location of one or more internal hosts and controllers in a portion of a device is shown in a cut-away (cut-away) portion of the entire electronic device or product, with a common communications link (here 138 and 148, respectively) connecting these internal hosts and controllers to a video display element or screen with a corresponding client, through some known type of swivel connection, where the type of swivel connection used may be those currently used throughout the electronics industry. It can be seen that the amount of data contained in these transfers requires a large number of wires to form links 138 and 148. It is estimated that such communication links are close to 90 or more conductors in order to meet the growing demand now for display elements utilizing advanced color and graphics interfaces on such devices, since parallel or other known types of interface technologies are available for transferring such data.

Unfortunately, this higher data rate exceeds the available prior art for transferring data. This is true both in terms of the amount of raw data that needs to be transferred per unit time, and in terms of a practical transfer mechanism that is reliable to manufacture at low cost.

What is needed is a technique for transmitting data at high rates over a data transmission link or communication path between a presentation element and a data source that allows for a consistently low power consumption, light weight, and as simple and economical a cable construction as possible. The applicant has developed a new technique, method and apparatus to achieve these and other objectives in order to allow a range of mobile, portable or even fixed location devices to be able to transfer data to a desired display, microdisplay or audio delivery element at very high data rates, while maintaining the desired low power consumption and low complexity.

High rate digital data interface system architecture

To create and effectively utilize new device interfaces, signal protocols and system architectures have been formulated that provide very high data transfer rates using low power signals. The protocol is based on data packets and a common frame structure or structure linked together to form a protocol for communicating a preselected set of data or data type and command or operational structure imposed on the interface.

A. Overview

Devices connected or communicating via an MDDI link are referred to as hosts and clients, which are typically some type of display device, although other output and input devices are also contemplated. When enabled by the host, data from the host to the display is transferred in the forward direction (referred to as forward traffic or link) and data from the client to the host is transferred in the reverse direction (referred to as reverse traffic or link). This is illustrated in the basic structure shown in fig. 2. In FIG. 2, host 202 is connected to client 204 using a bi-directional communication channel 206, which is shown in a form that includes a forward link 208 and a reverse link 210. However, these lanes are formed by common conductor sets whose data transfer can be effectively switched between forward and reverse link operation. This can greatly reduce the number of wires, and immediately solve one of many problems faced by the current manner of high-speed data transmission in a low power consumption environment such as a mobile electronic device.

As discussed elsewhere, the host comprises one of a variety of types of devices that can benefit from the use of the present invention. For example, host 202 may be a portable computer in the form of a handheld, laptop, or similar mobile computing device, which may be a Personal Digital Assistant (PDA), a paging device, or one of a variety of wireless telephones or modems. Alternatively, host 202 may be a portable entertainment or presentation device, such as a portable DVD or CD player, or a gaming device.

In addition, the host may exist as a host device or control element in a variety of other widely used or planned commercial products that require high-speed communication links to be established with clients. For example, the host may be used to transfer data from a video recording device to a storage-based client at a high rate to improve response, or to transfer data to a high-resolution large screen for presentation. Appliances such as refrigerators that incorporate on-board inventory (on-board inventory) or computing systems and/or bluetooth connections to other home devices have improved display capabilities when operating in the internet or bluetooth connected mode, or reduce wiring requirements for an in-room display (client) and keypad or scanner (client) when an electronic computer or control system (host) is present elsewhere in the room. In general, those skilled in the art will appreciate that a wide variety of modern electronic devices and appliances will benefit from the use of such interfaces, and that legacy devices can be retrofitted by utilizing a limited number of conductors in a connector or cable to enable higher data rate transmission of information.

Meanwhile, the client 204 may include various devices for presenting information to an end user or presenting information from a user to a host. For example, a micro-display incorporating goggles or glasses, a projection device embedded in a hat or helmet, a small screen or even a holographic element embedded in a window or windshield such as a vehicle, or various speakers, headphones, or a sound system for presenting high quality sound or music. Another example is the use of touch pads or sensitive devices, voice recognition input devices, security scanners, etc., which may want to convey a vast amount of information from a user with less realistic "inputs" other than touch and sound from the user.

However, those skilled in the art will readily recognize that the present invention is not limited to these devices, and that there are many other devices available on the market that provide high quality images and sound to the end user, either in storage and transmission or in presentation when played. The present invention is useful in improving data throughput between various components or devices, thereby enabling adaptation to high data rates needed to achieve a desired user experience.

The MDD interface and communication signal protocol of the present invention can be used to simplify the interconnection between the host processor and the display within the device (internal mode) to reduce the cost of these connections and improve reliability, not just for external components (external mode). The total serial link data rate on each signal pair used by this interface architecture can vary by many orders of magnitude, which allows system or device designers to easily optimize cost, power, implementation complexity, and display update rate. The properties of MDDI are not dependent on display technology. The timing of the data packets transmitted via the interface can be readily adjusted to suit the characteristics of the overall timing requirements of a particular display device or audio-video system. While doing so allows the system to consume as little power as possible, it does not require the display to have a frame buffer in order to use MDDI.

B. Interface type

The MDD interface is contemplated to be capable of handling five or more types of interfaces that are physically somewhat different as may be found in the communications and computer industries. These types of interfaces are simply labeled as type I, type II, type III, type IV, and type U, although other labels or designations may be applied by those skilled in the art depending on the application environment of the interfaces.

The type I interface is configured as a 6-wire (lead) interface, which makes it suitable for use with mobile or wireless telephones, PDAs, ebooks, electronic games and portable media players such as CD players or MP3 players, and similar devices or devices used in similar types of electronic consumer technology. In one embodiment, the U-shaped interface is configured as an 8-wire (lead) interface that is more suitable for use with laptop, notebook, or desktop personal computers and similar devices or applications that do not require a display to be updated quickly, nor do there are embedded MDDI link controllers. This interface type can also be distinguished by using an additional two-wire Universal Serial Bus (USB) interface, which is very useful in supporting existing operating systems or software support common on most personal computers. The U-interface can also be used in USB single mode, where the display has only one USB connector, which is connected to a standard USB port on a computer or similar device, e.g. a consumer electronics device such as a digital camera or a video player, provided with such a port.

Type II, III and IV interfaces are suitable for high performance clients or devices and use more complex cables with additional twisted pair type conductors to provide proper shielding and low loss transmission of data signals.

The type I interface conveys signals including display, audio, control and limited signaling information and is typically used for mobile clients or client devices that do not require high resolution full rate video data. The type I interface can easily support SVGA resolution with 30fps plus 5.1 channel audio, and in a minimum configuration, only three line pairs are used in total, two for data transmission and one for power transfer. This type of interface is designed primarily for devices such as mobile wireless devices, which typically do not have a USB for connection and signal transfer. In this configuration, the mobile wireless device is an MDDI host device and acts as a "master device" for controlling the communication link from the host, which typically sends data (forward traffic or link) to the client for rendering, display or playing.

In such an interface, the host is able to receive communication data (reverse traffic or link) from the client at the client by sending special commands or packet types to the client, wherein the commands allow the client to occupy the bus (link) for a specified duration and send the data to the host as reverse packets. This is illustrated in fig. 3, where a packet type (discussed below), referred to as an encapsulated packet, is used to support the transmission of reverse packets over the transport link to create the reverse link. The time interval allocated to the host for polling the client's data is predetermined by the host and is based on the requirements of each specified application. This type of half-duplex, bi-directional data transfer is particularly beneficial when no USB port is used to transfer information or data from the client.

High performance displays capable of displaying HDTV types or similar high resolutions require data streams at rates around 1.5Gbps to support full motion video. The Type II interface supports a high data rate by parallel transferring 2 bits, the Type-III is supported by parallel transferring 4 bits, and the Type IV interface transfers 8 bits in parallel. Type II and III use the same cables and connectors as type I, but are capable of operating at twice and four times the data rate to support higher performance video applications on portable devices. Type IV is suitable for very high performance clients or displays and requires a slightly larger cable containing an additional twisted pair data signal.

In general, the protocol used by MDDI allows each of the type I, II, III, or IV hosts to communicate with any type I, II, III, or IV client by negotiating what is the highest data rate that can be used. The capabilities or available features, which may be referred to as minimum capability devices, are used to set the performance of the link. Typically, even systems where both the host and the client are capable of using type II, type III, or type IV interfaces, both start with type I interfaces. The host then determines the capabilities of the target client and negotiates whether to perform a switch or reconfiguration operation on the type II, type III or type IV mode, as appropriate for the particular application.

For the host, the correct link layer protocol (discussed further below) can typically be used and is typically stepped down or reconfigured again to a slower mode at any time to save power consumption, or stepped up to a faster mode to support higher speed transfers such as high resolution display content. For example, the host computer may change the interface type when the system switches from power, such as a battery, to ac power, or when the display media source switches to a lower or higher resolution format, or may consider a combination of these or other conditions or events as the basis for changing the interface type or transfer mode.

The system is also capable of using one mode in one direction and another mode in the other direction to transfer data. For example, type IV interface mode may be used to transfer data at a high rate to a display, while type I or U mode is used when transferring data from a peripheral device such as a keyboard or pointing device to a host device. One of ordinary skill in the art will appreciate that the host and client are capable of transferring output data at different rates.

Users of the MDDI protocol often can distinguish between "external" and "internal" modes. External mode describes using MDDI to connect a host in a device to a client outside the device, up to about 2 meters away from the device. In this case, the host may also transmit power to the external client to facilitate both devices operating in a mobile environment. Internal schema describes a host connected to a client contained within the same device, such as within a common enclosure or cradle or structure. An example may be an application within a wireless telephone or other wireless device, or within a portable computer or gaming device, where the client is a display or display driver and the host is a central controller, graphics engine, or CPU element. In contrast to external mode applications, power is not typically required to connect power to the client in such a configuration, since the client is located very close to the host in internal mode applications.

C. Physical interface structure

The general configuration of a device or link controller for establishing communication between a host and a client device is shown in fig. 4 and 5. In fig. 4 and 5, MDDI link controllers 402 and 502 are shown installed in host device 202, and MDDI link controllers 404 and 504 are shown installed in client device 204. As previously described, host 202 is connected to client 204 using a bi-directional communication channel 406 that includes a series of conductors. As described below, both the host and client link controllers can be fabricated as integrated circuits using a single circuit design that can be set, adjusted, or programmed to respond as either a host controller (driver) or a client controller (receiver). This is less costly due to the larger scale manufacturing of the individual circuit devices.

In fig. 5, MDDI link controller 502 is shown installed in host device 202 'and MDDI link controller 504 is shown installed in client device 204'. As previously described, host 202 'is connected to client 204' using a bi-directional communication channel 506 comprising a series of conductors. As described above, both the host and client link controllers can be manufactured using a single circuit design.

The signals that are communicated between the host and a client, such as a display device, via an MDDI link or physical wires used are also illustrated in fig. 4 and 5. As shown in FIGS. 4 and 5, the primary path or mechanism for transferring Data via MDDI uses Data signals labeled MDDI _ Data0 +/-and MDDI _ Stb +/-respectively. Each of these signals is a low voltage data signal and is carried via a differential pair of wires in the cable. There is only one transition on either the MDDI _ Data0 pair or the MDDI _ Stb pair for each bit sent over the interface. This is a voltage-based, not current-based, transport mechanism, and thus the quiescent current consumption is close to zero. The host drives the MDDI _ Stb signal to the client display.

The host is the master or controller of the Data link when Data can flow in both forward and reverse directions via the MDDI _ Data pair, that is, it is a bi-directional transfer path. The MDDI _ Data0 and MDDI _ Stb signal paths operate in a differential mode to maximize immunity. The data rate of the signals on these lines is determined by the clock rate transmitted by the host and can vary from 1kbps up to 400Mbps or more.

In addition to the Data pair or path of the type I interface, the type II interface contains another Data pair or conductor or path, called MDDI _ Data1 +/-. In addition to those Data pairs or paths of the type II interface, the type III interface includes two additional Data pairs or signal paths, referred to as MDDI _ Data2 +/and MDDI _ Data3 +/-. In addition to the data pairs or paths of the type III interface, the type IV interface contains four further data pairs or signal paths, respectively referred to as: MDDI _ Data4+/-, MDDI _ Data5+/-, MDDI _ Data6 +/-and MDDI _ Data7 +/-. In each of the above interface configurations, the host may use line pairs or signals designated as MDDI _ Pwr and MDDI _ Gnd to provide power to the client or display. As will be discussed further below, if desired, power transfer may also occur in certain configurations based on MDDI _ Data4+/-, MDDI _ Data5+/-, MDDI _ Data6 +/-or MDDI _ Data7 +/-wires when the interface "type" being used utilizes fewer wires than are available or present in other modes.

The following is a summary of the signals passed between the host and client (display) via the MDDI link in the various modes, as per interface type, illustrated in table I.

TABLE I

It should also be noted that MDDIPwr/Gnd connections for transfer from the host are typically provided for external modes. The internal application or mode of operation typically lets the client power up directly from other internal resources without using MDDI to control the power distribution, as will be apparent to those of ordinary skill in the art, and therefore such distribution is not described in further detail herein. However, as will be appreciated by those of ordinary skill in the art, power can of course be distributed via the MDDI interface to facilitate some power control, synchronization, or interconnection.

The cable typically used to implement the above-described structure and operation is nominally about 1.5 meters in length, typically 2 meters or less, and includes three twisted pairs of conductors, again a plurality of 30AWG wires. A foil shield is wrapped or formed over the three twisted pairs as an additional ground wire. The twisted pairs and shielded ground conductors terminate in a display connector, the shield being connected to the shield of the display (client), and an insulating layer covering the entire cable, as is known in the art. The wires are paired in the following manner: MDDI _ Gnd and MDDI _ Pwr; MDDI _ Stb + and MDDI _ Stb-; MDDI _ Data0+ and MDDI _ Data 0-; MDDI _ Data1+ and MDDI _ Data 1-; and so on.

D. Data type and rate

To achieve a useful Interface for user experience and applications, a Mobile Digital Data Interface (MDDI) supports various clients and display information, audio transducers, keyboards, pointing devices, and various other input/output devices that may be integrated into or work in conjunction with a Mobile display device, as well as control information and combinations thereof. The MDD interface is designed to accommodate a variety of potential types of data streams that are transferred between the host and client in either the forward or reverse link directions using a minimum number of cables or wires. Both synchronous and asynchronous flows (updates) are supported. Many combinations of data types are possible so long as the aggregate data rate is less than or equal to the maximum desired MDDI link rate, which is limited by the maximum serial rate and the number of data pairs employed, so long as the aggregate data rate is less than the required maximum MDDI link rate. These may include, but are not limited to, those listed in tables II and III below.

TABLE II

TABLE III

To meet the flexibility requirements of future systems, the interface is not fixed, but rather is extensible, so that it can support the transfer of various "types" of information, including user-defined data. Specific examples of data supported are: full motion video in the form of full screen or partial screen bitmap fields or in compressed video form; static bitmaps at low rates to save power and reduce implementation cost; PCM or compressed audio data of multiple resolutions or rates; pointing device location and selection, and user definable data for capabilities to be defined. Such data may also be communicated with control or status information to detect device capabilities or to set operating parameters.

Embodiments of the present invention advance techniques for data transfer, including but not limited to: watching movies (video display and audio); limited personal viewing (graphical displays, sometimes in combination with video and audio) using a personal computer; playing a video game (sports graphics display or composite video and audio) on a PC, console or personal device; "surfing" (two-way low-rate video and audio) over the internet using a device in the form of a video phone, taking still digital images using a camera or taking digital video images using a camcorder; using a projector-equipped phone or PDA to present or assemble a desktop assembly station connected to a video monitor, keyboard, and mouse; and using a cellular phone, smart phone or PDA, including a wireless pointing device and keyboard data, to enhance productivity or for entertainment.

The mobile data interface, as described below, is provided in the form of a quantity of a-V type data provided via a communication or transmission link, which is typically configured as a wire line or cable type link. It will be apparent, however, that the signal structure, protocol, timing, or transport mechanism may be adjusted to provide a link in the form of an optical or wireless medium, so long as the link can maintain a desired level of data transfer.

The MDD interface signal uses a concept known as Common Frame (CF) for the basic signal protocol or structure. The idea of using a common frame is to provide synchronization pulses for simultaneous synchronization data streams. The client device may use this common frame rate as a time reference. The low CF rate improves channel efficiency by reducing overhead for transmitting the sub-frame header. On the other hand, a high CF rate can reduce latency and allow a less flexible data buffer to be used for audio sampling. The CF rate of the interface of the present invention is dynamically programmable and can be set to one of a plurality of values suitable for a plurality of isochronous streams for a particular application. That is, the CF values are selected to best suit a given client and host architecture, as needed.

The number of bytes typically required per common frame of a synchronous data stream that is likely to be used in applications such as a headband microdisplay is shown in table IV, which may be adjustable or programmable.

TABLE IV

Fractional bytes per common frame can be easily calculated using a simple programmable M/N counter structure. For example, by transmitting 2 frames of 27 bytes, each time followed by a frame of 26 bytes, a count of each CF 26-2/3 byte can be achieved. A smaller CF rate may be selected to produce an integer number of bytes per CF. However, in general, a simple M/N counter implemented in hardware requires less area in an integrated circuit chip or electronic module implementing some or all of the embodiments of the invention than would be required for a larger audio sample FIFO buffer.

An exemplary application illustrating the impact of different data transfer rates and data types is the karaoke system. For the karaoke system, the end user or end users sing along with the music video program. The lyrics of a song are displayed somewhere on the screen, usually at the bottom of the screen, so the user knows the words to sing and roughly the tempo of the song. Such an application requires a video display that is not updated frequently with graphics and mixes one or more user voices with the stereo audio stream.

If one assumes that the common frame rate is 300Hz, then each CF will include: 92,160 bytes of video content and 588 bytes of audio content (based on 14716 bit samples in stereo) over the forward link to the client display device, and an average of 26.67(26-2/3) bytes of speech fed back from the microphone to the mobile karaoke machine. Asynchronous packets are sent between the host and the display (possibly head-mounted). This includes a maximum of 768 bytes of graphics data (quarter screen height), and less than about 200 bytes (a few bytes) for a wide variety of control and status commands.

Table V shows how data is allocated within a common frame for the karaoke example. The total rate to be used is chosen to be about 225 Mbps. A slightly higher rate of 226Mbps allows another 400 bytes of data to be transmitted per sub-frame, thus enabling occasional control and transmission of status information.

TABLE V

Rate of element	byte/CF
		Music video of 640 x 480 pixels, 30fps	92160
640 x 120 pixels, 1fpsText of lyrics	768
		44,100sps, stereo, 16-bit CD audio	588
8,000sps, mono, 8-bit speech	26.67
		Sub-frame header	19
Reverse link overhead	26.67+2*9+20
		Total bytes/CF	93626.33
Total Rate (Mbps)	224.7032

(continue) high rate digital data interface system architecture

E. Link layer

Data transmitted using the MDD interface high speed serial data signal comprises a stream of time division multiplexed data packets, wherein the data packets are linked one after the other. MDDI link controllers typically automatically transmit filler data packets even if the transmitting device has no data to transmit, thereby maintaining the data packet stream. Thus, the use of a simple packet structure can ensure reliable synchronous timing of video and audio signals or data streams.

The data packet groups are included in signal elements called sub-frames(signal element) or structure, and the group of subframes is contained in a signal element or structure called a media frame. Depending on the respective size and data transfer purpose of the sub-frames, a sub-frame contains one or more data packets, while a media frame contains one or more sub-frames. The protocol employed by the embodiments presented herein provides a maximum subframe of approximately 2 ³²On the order of 1 or 4,294,967,295 bytes, while the size of the largest media frame is about 2¹⁶On the order of 1 or 65,535 subframes.

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

Typically, the display screen is updated once per media frame when full motion video is displayed. The display frame rate is the same as the media frame rate. Depending on the desired application, the link protocol supports full motion video on the entire display, or only a small area of full motion video content surrounded by still images. In some low power mobile applications, such as viewing web pages or e-mail, the display screen only needs to be updated occasionally. In these cases, it is beneficial to transmit a single subframe and then shut down the link or drop the link in order to minimize power consumption. The interface also supports effects such as stereoscopic vision and processes graphics primitives.

The sub-frames allow the system to periodically transmit high priority data packets. This allows simultaneous isochronous streams to coexist with a minimal amount of data buffering. This is an advantageous embodiment provided to the display process which allows multiple data streams (high speed communication of video, voice, control, status, pointing device data, etc.) to share substantially a common channel. The interface uses a relatively small number of signals to convey information. The interface also allows for display technology specific actions such as horizontal synchronization pulses and blanking intervals (blanking intervals) of a CRT monitor.

F. Link controller

The MDDI link controllers shown in fig. 4 and 5 would be manufactured or assembled in a fully digital implementation without the differential line receivers used to receive MDDI data and strobe signals. However, the differential line driver and receiver may even be implemented in the same digital integrated circuit together with the link controller, for example when making a CMOS type IC. No analog function or Phase Locked Loop (PLL) is required for bit recovery or to implement the hardware of the link controller. The host and client link controllers contain very similar functionality, except for the client interface, which contains a state machine for link synchronization. Thus, embodiments of the present invention allow a single controller design or circuit to be created and configured as either a host or a client, which in general may reduce the manufacturing cost of the link controller.

Interface Link protocol

A. Frame structure

The signal protocol or frame structure for forward link communications that implement packet transport is illustrated in fig. 6. As shown in fig. 6, information or digital data is assembled into elements (elements) known as packets. In turn, multiple data packets are combined together to form what is known as a "subframe", and multiple subframes are combined together to form a "media" frame. To control frame formation and the transmission of subframes, each subframe begins with a special predetermined packet called a Subframe Header Packet (SHP).

The host device selects a data rate to be used for a given transfer. The host device may dynamically change this rate based on the maximum transfer capability of the host, the data retrieved (retrieve) by the host from the information source, and the maximum capability of the client or other device to which the data is to be transferred.

A recipient client device designed to either work in conjunction with MDDI or the signaling protocol of the present invention can be queried by the host to determine the maximum or current maximum data transfer rate that can be used by the client, or a default slower minimum rate that can be used, as well as the useful data types and supported features. This information may be communicated using a display capability data packet (DCP), as will be discussed further below. The client display device is able to use the interface to transfer data or communicate with other devices at a preselected minimum data rate or within a range of minimum data rates, and the host will perform a query using the data rates within this range to determine the full capabilities of the client device.

Other status information defining bitmap attributes and video frame rate capabilities of the display may be communicated to the host in status packets so that the host can configure the interface as efficiently or optimally as practical or desired within any system constraints.

When there are no (more) packets to be transmitted in this subframe, or when the host cannot transmit at a rate sufficient to keep up with the (keep pace) forward link selected data transmission rate, the host sends filler packets. Since each subframe starts with a subframe header packet, the end of the previous subframe contains the packet that just filled the previous subframe (most likely a filler packet). In case the data carrying packet itself lacks space, the filler packet is likely to be the last packet in a subframe, or at the end of the immediately preceding (nextprevious) subframe and before the subframe header packet. In the host device, the task of controlling the operation is to ensure that sufficient space remains in the sub-frame for each data packet to be transmitted within the sub-frame. Meanwhile, once the host device begins sending data packets, the host must be able to successfully complete the transmission of packets of that size within a frame without causing a data underrun (under-run) condition.

In one aspect of the embodiment, the subframe transmission has two modes. One mode is a periodic subframe pattern, or periodic timing epochs, for transmitting live video and audio streams. In this mode, the subframe length is defined to be non-zero. The second mode is an asynchronous or aperiodic mode in which frames are used to provide bitmap data to the client only when there is new information. This pattern is defined by setting the subframe length to zero in the subframe header packet. When a periodic pattern is used, sub-frame packet reception can begin when the display is synchronized to the forward link frame structure. This corresponds to the state of "in sync" (insync), as defined in the state diagram discussed below with respect to fig. 49 or 63. In asynchronous aperiodic subframe mode, reception begins after the reception of the first subframe header packet.

B. Overall data packet structure

The following describes the packet format or structure used to specify the signaling protocol implemented by the embodiments, bearing in mind that the interface is extensible and that additional packet structures may be added as needed. The packets are marked or classified into different "packet types" in terms of their function in the interface, i.e. whether they carry commands or data. Thus, for a given packet used to manipulate the transmitted packets and data, each packet type represents a predefined packet structure. It is obvious that the data packets may have a pre-selected length or a variable or dynamically variable length according to the respective function. The packets may also have different names, although still performing the same function, as occurs when a protocol changes during the process of accepting the protocol into the standard. The bytes or byte values for the various data packets are configured as multi-bit (8 or 16 bit) unsigned integers. The data packet summaries employed, and their "type" designation, are listed in type order and are shown in tables VI-1 through VI-4.

For ease of illustration and understanding, each table gives a generic "type" packet within the overall packet structure. These packets do not imply or represent certain limitations or other impacts, and the data packets may be organized in a number of other ways, as desired. The direction in which packet delivery is considered valid is also indicated.

TABLE VI-1

Link control packet

Data packet name	Type of data packet	Positive direction effective	Effective in the reverse direction
				Sub-frame header packet	15359	X
Filler data packet	0	x	x
				Reverse link encapsulation packet	65	x
Link shutdown packet	69	x
				Interface type switching request data packet	75	x
Interface type acknowledgement packet	76		x
				Execution type switching packet	77	x
Round trip delay measurement packet	82	x
				Forward link offset calibration packets	83	x

TABLE VI-2

Elementary media stream data packet

Data packet name	Type of data packet	Positive direction effective	Effective in the reverse direction
				Video stream data packet	16	x	x
Audio stream data packet	32	x	x
				Reverse flow data packet	1-15，18-31，33-35	x	x
User-defined stream data packets	56-63	x	x
				Color mapping data packet	64	x	x
Forward audio channel enable packet	78	x
				Reverse audio sample rate data packet	79	x
Transparent color enable packet	81	x

TABLE VI-3

Display status and control data packet

Data packet name	Type of data packet	Positive direction effective	Effective in the reverse direction
				Display capability data packet	66		x
Keyboard data packet	67	x	x
				Pointing device data packet	68	x	x
Display request and status packet	70	x	x
				Digital content protection overhead data packet	80	x	x
Requesting VCP feature packets	128	x
				VCP feature response packet	129	x	x
Is provided withVCP feature data packet	130	x
				Request valid parameter data packet	131	x
Efficient parameter response packet	132		x
				Requesting specialized status packets	138	x
Valid status answer list packet	139		x
				Packet processing delay parameter packet	140		x
Personal display capability data packet	141		x
				Display error reporting data packet	142		x
Scalable video streaming capability packets	143		x
				Display identification data packet	144		x
Standby display capability data packet	145		x
				Register access packet	146		x

TABLE VI-4

Advanced graphics and display package

Data packet name	Type of data packet	Positive direction effective	Effective in the reverse direction
				Bit block transfer packet	71	x
Bitmap area fill packet	72	x
				Bitmap pattern fill packet	73	x
Reading frame buffer data packets	74	x
				Alpha-cursor image capability packet	133		x
Alpha-cursor transparency mapping data packet	134	x
				Alpha-cursor image offset data packet	135	x
Alpha-cursor video stream data packet	17	x
				Scalable video streaming capability packets	143		x
Scalable video stream setup packet	136	x
				Scalable video stream acknowledgment packets	137		x
RetractablePlaying video stream packets	18	x

It will be clear from the other discussions herein that while reverse encapsulation packets, display capability packets, and display request and status packets are also considered to be important, even necessary for external mode operation, they may be considered optional for internal mode operation. Doing so creates another type of MDD interface protocol that allows data to be communicated at very high speeds with a reduced set of communication packets, and that simplifies control and timing accordingly.

The packets have a common basic structure or overall set of minimum fields including a packet length field, a packet type field, a data byte field, and a CRC field, which are shown in fig. 7. As shown in fig. 7, the packet length field contains information in the form of a multi-bit or byte value for specifying the total number of bits of the packet or specifying the length between the packet length field and the CRC field. In one embodiment, the packet length field contains a 16-bit or 2-byte wide unsigned integer that specifies the packet length. The packet type field is another multi-bit field that indicates the type of information contained within the packet. In an exemplary embodiment, the packet type field is a 16-bit or 2-byte wide value in the form of a 16-bit unsigned integer, and specifies these data types as display capabilities, switching, video or audio streams, status, and the like.

The third field is a data byte field that contains bits or data that are transferred or sent as part of a data packet between the host and client devices. The data format is specifically defined for each packet type according to the specific type of data being transmitted, and may be divided into a series of additional fields, each with its own format requirements. That is, each packet type will have a defined format for this portion or field. The final field is the CRC field, which contains the result of the 16-bit cyclic redundancy check calculated over the data byte, packet type and packet length fields, which is used to confirm the integrity of the information in the packet. In other words, the result is calculated over the entire packet except for the CRC field itself. The client typically keeps a total count of detected CRC errors and reports this count to the host in display request and status packets (see below).

Typically, these field widths and organization structures are designed to align 2-byte fields on even byte boundaries and 4-byte fields on 4-byte boundaries. This allows the packet structure to be easily embedded in or associated with the host and client main memory spaces without violating data type alignment rules encountered in most or commonly used processors or control circuits.

During the transmission of the data packet, the field is transmitted first starting with the Least Significant Bit (LSB) and finally ending with the transmission of the Most Significant Bit (MSB). More than one byte length parameter is transmitted the least significant byte first, so that the resulting bit transmission pattern for transmitting parameters with a length greater than 8 bits is the same bit transmission pattern used for transmitting the shorter parameter of the LSB first. The data fields of each packet are typically transmitted in the order defined in the subsequent paragraphs below, with the first field listed being transmitted first and the last described field being transmitted last. In any of these modes, type I, type II, type III, or type IV, the Data on the MDDI _ Data0 signal path is aligned with the '0' bit of the byte being transferred on the interface.

When manipulating data for display, the data for the pixel array is first transferred by rows and then columns, as is conventionally performed in the electronics art. In other words, all pixels appearing in the same row in the bitmap are transferred in order, with the leftmost pixel being transferred first and the rightmost pixel being transferred last. After the rightmost pixel in a row has been transferred, then the next pixel in the order is the leftmost pixel in the next row. For most displays, the rows of pixels are typically transmitted in a top-down order, although other configurations may be used as desired. Furthermore, in processing the bitmap, the conventional approach, i.e., the approach followed herein, is to define a reference point by marking the upper left corner of the bitmap as a position or offset "0, 0". The values of the X and Y coordinates used to define or determine the position in the bitmap increase as one approaches the right side and bottom of the bitmap, respectively. The first row and column (top left corner of the image) starts with the index value zero. The value of the X coordinate increases towards the right side of the image and the value of the Y coordinate increases towards the bottom of the image when viewed from the display user.

The display window is the visible part of the bitmap, i.e. the part of the pixels in the bitmap that the user can see on the physical display medium. The display window and bitmap are often the same size. The upper left corner of the display window always displays the bit pixel position 0, 0. The width of the display window corresponds to the X-axis of the bitmap and the display window width is 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 display window height is less than or equal to the height of the corresponding bitmap. The display window itself is not involved in the protocol because it is defined as the visible part of the bitmap only. The relationship between the bitmap and the display window is shown.

C. Data packet definition

1. Sub-frame header packet

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 for host-client synchronization, and each host should be able to generate this packet while each client should be able to receive and interpret this packet. As can be seen in fig. 8, this type of packet is typically constructed in sequence with packet length, packet type, unique word, reserved 1, subframe length, protocol version, subframe count and media frame count fields. In one embodiment, this type of packet is typically identified as a type 15359 (0 x3bff hex) packet and uses a preselected fixed length of 20 bytes, excluding the packet length field.

The packet type field and the unique word field both use 2 byte values (16 bit unsigned integers). This combination of 4 bytes of the two fields together forms a 32-bit unique word with good autocorrelation. In one embodiment, the actual unique word is 0x005a3bff, where the lower 16 bits are transmitted first as the packet type and then the highest 16 bits.

The reserved 1 field contains 2 bytes of reserved space for future use and is generally configured here to zero all bits. One purpose of this field is to align the subsequent 2-byte field with a 16-bit word address and to align the 4-byte field with a 32-bit word address. The least significant byte is reserved to indicate that the host has access to multiple client devices. The value of zero is reserved to indicate that this host can only work with a single client device.

The subframe length field contains 4 bytes of information or value to indicate the number of bytes per subframe. In one embodiment, the length of this field may be set equal to zero to indicate that the host will only transmit one subframe before shutting down the link to idle state. The value in this field may change dynamically "during operation" when transitioning from one subframe to the next. This capability is useful for small timing adjustments in the synchronization pulses to support synchronous data flow. If the CRC of the sub-frame header packet is not valid, the link controller should estimate the length of the current sub-frame using the sub-frame length of the previous sub-frame header packet, which is known to be intact.

The protocol version field contains 2 bytes to specify the version of the protocol used by the host. Setting the protocol version field to '0' indicates the first or current version of the protocol being used. This value will change over time when a new version is created. The subframe count field contains 2 bytes, which illustrates a sequence number indicating the number of subframes transmitted from the beginning of the media frame. The subframe count of the first subframe of the media frame is zero. The last subframe of the media frame has a value of n-1, where n is the number of subframes per media frame. It should be noted that if the subframe length is set equal to zero (indicating an aperiodic subframe), the subframe count must also be set equal to zero.

The media frame count field contains 4 bytes (a 32-bit unsigned integer) to illustrate a sequence number indicating the number of media frames that have been transmitted since the current media item or data was transmitted. The media item first media frame has a media frame count of zero. The media frame count is incremented just prior to the first sub-frame of each media frame and when the maximum media frame count (e.g., media frame number 2) is used³²-1 ═ 4,294,967,295) and then returns to zero. The media frame count value is typically readily resettable by the host to accommodate the requirements of the end application.

2. Filler data packet

Filler data packets are data packets that are transmitted to or from a client device when no other information is available to send on the forward or reverse link. The filler data packets preferably have a minimum length to allow maximum flexibility in transmitting other data packets when required. At the end of a sub-frame or reverse link encapsulated packet (see below), the link controller sets the size of the filler packet to fill the remaining space, thereby maintaining packet integrity. The filler data packet is useful for maintaining timing on the link when the host or client has no information to send or exchange. Each host and client should be able to send and receive this packet in order to use the interface efficiently.

The format and content of the filler data packet is shown in fig. 9. This type of packet is constructed to have a packet length, a packet type, padding bytes, and a CRC field, as shown in fig. 9. In one embodiment, this type of packet is typically identified as type 0, which is indicated in the 2 byte type field. The bits or bytes in the padding byte field comprise a variable number of all-zero bit values in order to allow the padding data packet to have a desired length. The minimum filler data packet contains no bytes in this field. That is, the packet includes only a packet length, a packet type, and a CRC, and in one embodiment, a fixed length of a preselected 6 bytes or a packet length value of 4 is used. The CRC value is determined for all bytes in the packet, including the packet length, but is excluded in other packet types.

3. Video stream data packet

Video stream packets typically carry video data to update a rectangular area of a display device. The size of this area may be as small as a single pixel or as large as the entire display. There may be an almost unlimited number of streams being displayed simultaneously, which is limited by system resources because all the context needed to display the streams is contained within the video stream data packet. The format of one embodiment of a video stream data packet (video data format descriptor) is shown in fig. 10. As shown in fig. 10, in one embodiment, this type of packet is constructed to have a packet length (2 bytes), a packet type, a bClient ID, a video data descriptor, pixel display attributes, an X left edge, a Y top edge, an X right edge, a Y bottom edge, X and Y starts, a pixel count, a parameter CRC, pixel data, and CRC fields. This type of packet is typically identified as type 16, which is indicated in the 2 byte type field. In one embodiment, the client uses the RGB, monochrome, and Y Cr Cb capability fields of the display capability packet to indicate the capability to receive video stream packets.

In one embodiment, the bClient ID field contains 2 bytes of information reserved for the client ID. Since this is the most recently developed communication protocol, the actual client ID is still not known or sufficiently communicated. Thus, the bit in this field is typically set equal to zero until this ID value is known, at which point the ID value can be inserted or used, as will be apparent to those skilled in the art.

The common frame concept described above is an effective way to minimize the audio buffer size and reduce latency. However, for video data, it may be necessary to extend the pixels of one video frame to multiple video stream data packets within a media frame. It is also possible that the pixels in a single video stream data packet do not correspond exactly to a complete 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 10 subframes per media frame. If there are 480 lines of pixels in each frame, each video stream packet in each sub-frame will include 48 lines of pixels. In other cases, a video stream packet may not contain integer pixel rows. This is true for other video frame sizes where the number of sub-frames per media frame cannot be equally divided by the number of lines per video frame (also called video lines). Each video stream data packet typically must contain an integer number of pixels, even though it does not necessarily contain an integer number of rows of pixels. This is important if each pixel is larger than one byte, or if they have a packet format as shown in fig. 12.

The format and content employed for implementing the exemplary video data descriptor field operations described above are shown in fig. 11a-11 d. In fig. 11a-11d, the video data format descriptor field contains 2 bytes in the form of a 16-bit unsigned integer to illustrate the format of each pixel in the pixel data in the current stream of current data packets. Different video stream data packets may use different pixel data formats, i.e. different values in the video data format descriptor, and likewise the stream (display area) may change its data format during operation. The pixel data format should conform to at least one format valid for the client as defined in the display capability packet. The video data format descriptor defines the pixel format of the current packet only if the pixel format of the current packet implies that the unchanged format is no longer used for the lifetime of the particular video stream.

Fig. 11a to 11d illustrate how a video data format descriptor is encoded. As used in these figures, and in this embodiment, when bits [15:13] are equal to '000', as shown in fig. 11a, then the video data comprises an array of monochrome pixels, where the number of bits per pixel is defined by bits 3 through 0 of the video data format descriptor word. Bits 11 through 4 are typically reserved for future use or for other applications and are set to zero in this case. When bits [15:13] are changed to equal '001', as shown in FIG. 11b, then the video data includes an array of color pixels, each of which is assigned a color by a color map (palette). In this case, bits 5 to 0 of the video data format descriptor word define the number of bits per pixel, and bits 11 to 6 are typically reserved for future use or application, and these bits are set equal to zero. When bits [15:13] are changed to equal '010', as shown in FIG. 11c, then the video data includes an array of color pixels, where the number of bits per pixel for red is defined by bits 11-8, the number of bits per pixel for green is defined by bits 7-4, and the number of bits per pixel for blue is defined by bits 3-0. In this case, the total number of bits in each pixel is the sum of the bits of red, green, and blue.

However, when bits [15:13] are changed to equal '011', as shown in FIG. 11d, then the video data comprises an array of video data with luminance and chrominance information having a YCbCr format of 4:2:2, where the number of bits per pixel of luminance (Y) is defined by bits 11 through 8, the number of bits of the Cb component is defined by bits 7 through 4, and the number of bits of the Cr component is defined by bits 3 through 0. The total number of bits in each pixel is the sum of the number of bits for red, green and blue. The Cb and Cr components are sent at half the rate of the Y component. In addition, the video samples in the pixel data portion of this packet are organized as: cbn, Yn, Crn, Yn +1, Cbn +2, Yn +2, Crn +2, Yn +3, …, where Cbn and Crn are associated with Yn and Yn +1, and Cbn +2 and Crn +2 are associated with Yn +2 and Yn +3, and so on.

Yn, Yn +1, Yn +2, and Yn +3 are luminance values of four consecutive pixels from left to right in a single line. The order of the color components is typically selected to be the same format as the UYVY FOURCC format used by microsoft corporation in its software, although the invention is not limited to this format. If there are an odd number of pixels in a row of the window in which the video stream packet is located (X right edge-X left edge +1), then the Y value corresponding to the last pixel in each row will be followed by the Cb value of the first pixel of the next row and the Cr value of the last pixel in the row will not be sent. It is proposed that the window using the Y Cb Cr format has a width of an even number of pixels. The pixel data in the data packet should contain an even number of pixels. Where the last pixel of the pixel data corresponds to the last pixel of a line in the window specified in the header of the video stream packet, i.e., when the X position of the last pixel in the pixel data is equal to the X right edge, it may contain an odd or even number of pixels.

When bits [15:13] are substituted to equal '100', then the video data includes an array of spaced (Bayer) pixels, where the number of bits per pixel is defined by bits 3 through 0 of the video data format descriptor word. The pixel pattern is defined by bits 5 and 4, e.g. "error! No reference source (space (Bayer)) "was found as shown. The order of the pixel data may be horizontal or vertical, and the pixels in a row or column may be sent in a forward or backward order and defined by bits 8 through 6, such as "error! Reference source found not "as shown. Bits 11 to 9 should be set to zero.

For all four formats shown in the figure, bit 12, designated "P", indicates whether the pixel data sample is packed pixel data or byte aligned pixel data. A value of '0' in this field indicates that each pixel in the pixel data field is byte aligned with the MDD interface byte boundary. The value '1' indicates that each pixel and each color within each pixel in the pixel data is packed relative to the previous pixel or color within the pixel that has no unused bits left.

The first pixel in the first video stream packet of a media frame for a particular display window would go into the upper left corner of the stream window defined by the X left edge and the Y top edge, with the next pixel received placed at the next pixel location in the same row, and so on. In this first packet of a media frame, the X start value is typically equal to the X left edge, and the Y start value is typically equal to the Y top edge. In subsequent packets corresponding to the same screen window, the X and Y start values are typically set to a particular pixel position in the screen window that is a pixel position after the last pixel sent in the video stream packet transmitted in the previous subframe.

4. Audio stream data packet

The audio stream packets carry audio data to be played over the client audio system or for a separate audio rendering device. Different audio data streams may be assigned to separate audio channels in the sound system, for example: left front, right front, center, left back, and right back, depending on the type of audio system being used. The full audio channel is provided for headphones that incorporate enhanced spatial acoustic signal processing. The client uses the audio channel capability and audio sample rate fields of the display capability packet to indicate the ability to receive audio stream packets. The format of the audio stream packets is illustrated in fig. 13.

As shown in fig. 13, this type of packet is constructed to have packet length, packet type, bClient ID, audio channel ID, reserved 1, audio sample count, bits per sample and its packing, audio sample rate, parameter CRC, digital audio data, and audio data CRC fields. In one embodiment, this type of packet is generally identified as a type 32 packet.

The bClient ID field contains 2 bytes of information reserved for the client ID, as previously used. The reserved 1 field contains 2 bytes that are reserved for future use and is configured here to set all bits to zero.

The bits of each sample and its packing field contain 1 byte in the form of an 8-bit unsigned integer to illustrate the packing format of the audio data. The commonly employed format is to define the number of bits per PCM audio sample using bits 4 to 0. Bit 5 then indicates whether the digital audio data samples are packed. The difference between the packed audio samples and the byte aligned audio samples is illustrated in fig. 14. A value of '0' indicates that each PCM audio sample in the digital audio data field is byte aligned with an MDDI interface byte boundary, and a value of '1' indicates that each successive PCM audio sample is packed relative to the previous audio sample. This bit is usually valid only if the value defined by bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of 8. Bits 7 through 6 are reserved for future use and are typically set to zero.

5. Reserved stream data packet

In one embodiment, packet types 1 through 15, 18 through 31, and 33 through 55 are reserved streaming packets to be defined for future versions or packet protocol changes, depending on the requirements of the various applications encountered. This is part of making MDD interfaces more flexible and still very useful in the face of ever changing technologies and system designs, compared to other technologies.

6. User-defined stream data packets

The 8 data stream types, referred to as types 56 to 63, which may be defined by the device manufacturer for use by the MDDI link, are reserved for proprietary applications. These are called user-defined stream packets. Such packets may be used for any purpose, but the host and client should only use such packets if they are well understood or aware of the results of such use. The specific definition of flow parameters and data for these packet types is left to the specific device manufacturer that implements or seeks its purpose. Some exemplary uses of the user-defined stream data packets are to communicate test parameters and test results, factory calibration data, and proprietary special data. The format of a user-defined stream packet for one embodiment is illustrated in fig. 15. This type of packet is constructed to have packet length (2 bytes), packet type, bClient ID number, stream parameter, parameter CRC, stream data, and stream data CRC fields, as shown in fig. 15.

7. Color mapping data packet

The color mapping data packet specifies the contents of a color mapping look-up table used to present colors to the client. Some applications may require a color mapping that is larger than the amount of data that a single packet can transmit. As such, by using the offset and length fields as described below, multiple color mapping packets may be transmitted, each having a different subset of the color mapping. The format of the color map data packet in one embodiment is illustrated in FIG. 16. As shown in fig. 16, this type of packet is constructed to have packet length, packet type, hClientID, color mapping entry count, color mapping offset, parameter CRC, color mapping data, and data CRC fields. In one embodiment, this type of packet is typically identified as a type 64 packet (video data format and color map packet), as illustrated in the packet type field (2 bytes). The client uses the color map size and color map width fields of the display capability packet to indicate the capability to receive the color map packet.

8. Reverse link encapsulation packet

In an exemplary embodiment, data is transmitted in the reverse direction using reverse link encapsulated packets. A forward link packet is sent and the MDDI link operation is changed or diverted (in the transmit direction) approximately in the middle of the packet so that the packet can be sent in the reverse direction. Fig. 17 illustrates the format of a reverse link encapsulated packet in one embodiment. As shown in fig. 17, this type of packet is constructed to have packet length, packet type, hCLient ID, reverse link flag, reverse rate divisor, Turn-Around 1 length, Turn-Around 2 length, parameter CRC, all-zeros 1, Turn-Around 1, reverse data packet, all-zeros 2, Turn-Around 2, and driver re-enable field. This type of packet is typically identified as a type 65 packet. For 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 packet is optional for the internal mode.

The MDDI link controller operates in a particular manner when transmitting reverse link encapsulated packets. The MDD interface has a strobe signal that is always driven by the host as a link controller. The host behaves as if it were transmitting zeros for each bit of the diverted and reverse data packet portion of the reverse link encapsulation packet. The host issues an MDDI strobe signal at the boundary of each bit during both commutations and during the period assigned to the reverse data packet. (this is the same behavior as transmitting all zero data.) the host disables its MDDI data signal line drivers during the time period specified by turnaround 1, and the client re-enables its line drivers during the driver re-enable field after the time period specified by turnaround 2 field. The client reads the turnaround length parameter and drives a data signal to the host immediately after the last bit of the turnaround 1 field. That is, at some rising edge of the MDDI strobe, the client clocks new data into the (clock intos) link, as explained below and elsewhere in the description of the packet contents. The client uses the packet length and turn length parameters to learn the length of time it can use to send packets to the host. When there is no data to send to the host, the client may send filler data packets or drive the data lines to a zero state. If the data line is driven to zero, the host interprets it as a packet having a length of zero (not one active length) and during the current reverse link encapsulation packet, the host no longer receives any packets from the client.

The host drives the MDDI _ Data signal to a logic zero level during the all-zero 1 field, and the client drives the MDDI Data line to a logic zero level for at least one reverse link clock cycle before the turnaround 2 field begins, i.e., during the all-zero 2 field. This is done to keep the data line in a certain state during the time period of the turn 1 and turn 2 fields. If the client has no more packets to send, it may even disable the data lines after driving them to a logic zero level because the sleep bias resistance (discussed elsewhere) keeps the data lines at a logic zero level for the remainder of the reverse data packet field, or during about 16 or more forward link bytes.

In one embodiment, the reverse link request field of the display request and status packet may be used to inform the host of the number of bytes the client needs to send data back to the host in the reverse link encapsulated packet. The host attempts to grant the request by allocating at least that many bytes in the reverse link encapsulated packet. The host may send more than one reverse link encapsulated packet in a subframe. The display can send display request and status packets almost anytime, the host will interpret the reverse link request parameter as the total number of bytes requested in a sub-frame.

9. Display capability data packet

The host must know the capabilities of the client (display) with which it communicates in order to configure the host-to-client link in a generally optimal or desirable manner. It is proposed that after obtaining forward link synchronization, the display sends a display capability packet to the host. The transmission of reverse link encapsulated packets should be considered when requested by the host using the reverse link flag in such packets. The display capability packet is used to inform the host of the capabilities of the display. For external mode, each host must be able to receive this packet, and each display must be able to send this packet in order to fully utilize this interface and protocol. This packet implementation is optional for internal modes, since the capabilities of the display should already be well defined and known to the host at the time of manufacture or assembly into some type of individual component or unit.

The format of the display capability data packet in one embodiment is illustrated in FIG. 18. As shown in fig. 18, this type of packet is constructed to have a packet length, a packet type, a protocol version, a minimum protocol version, a bitmap width, a bitmap height, a monochrome capability, a color mapping capability, an RGB capability, a Y Cr Cb capability, a display feature capability, a data rate capability, a frame rate capability, an audio buffer depth, an audio streaming capability, an audio rate capability, a minimum subframe rate, and a CRC field. In one exemplary embodiment, this type of packet is generally identified as a type 66 packet.

10. Keyboard data packet

The keyboard data packet is used to transmit keyboard data from the client device to the host. A wireless (or wired) keyboard may be used in conjunction with various display or audio devices, including but not limited to a headband video display/audio presentation device. The keyboard data packet relays keyboard data received from several known keyboard-like devices to the host. This data packet may also be used on the forward link to send data to the keyboard. The client uses the keyboard data field in the display capability packet to indicate the capability to send and receive keyboard data packets.

The format of the keyboard data packet is shown in FIG. 19 and contains information from or for a variable number of bytes of keyboard data. This type of packet is constructed to have a packet length, a packet type, a bClient ID, a keyboard data format, keyboard data, and CRC fields, as shown in fig. 19. This type of packet is generally identified herein as a type 67 packet.

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

11. Pointing device data packet

The pointing device data packet is used to transmit position information from a wireless mouse or other pointing device from the display to the host. This data packet may also be used to transmit data to a pointing device on the forward link. An exemplary format of a pointing device data packet is shown in fig. 20, and contains a variable number of bytes of information from or for the pointing device. As shown in fig. 20, this type of packet is constructed to have a packet length, a packet type, pointing device data, and a CRC field. In an exemplary embodiment, this type of packet is identified as a type 68 packet, typically in a 1-byte type field.

12. Link shutdown packet

A link down packet is sent from the host to the client display to indicate that MDDI data and strobes are to be turned off and enter a low power "sleep" state. This packet is useful to close the link and save power after the static bitmap is sent from the mobile communication device to the display, or when there is temporarily no further information to transfer from the host to the client. When the host sends the data packet again, normal operation is resumed. The first packet sent after dormancy is a subframe header packet. The format of the display status packet is shown in fig. 21. This type of packet is constructed to have a packet length, a packet type, and a CRC field, as shown in fig. 21. In one embodiment, this type of packet is identified as a type 69 packet, typically in a type field of 1 byte, and a preselected fixed length of 3 bytes is used.

In the low power sleep state, the MDDI _ Data driver is disabled to a high impedance state and the MDDI _ Data signal is pulled to a logic zero state using a high impedance biasing network that can be overdriven by the display. In the sleep state, a strobe signal used by the interface is set to a logic zero level in order to minimize power consumption. As discussed elsewhere, it is a key advance and advantage of the present invention that either the host or the client can "wake up" the MDDI link from a dormant state.

13. Display request and status packet

The host needs a small amount of information from the display so that it can configure the host-to-client link in an overall optimal manner. It is proposed that the display send one display status packet per sub-frame to the host. The display should send this packet as the first packet in the reverse link encapsulated packet to ensure that the packet is reliably sent to the host. The format of the display status packet is shown in fig. 22. This type of packet is constructed to have a packet length, a packet type, a reverse link request, a CRC error count, and a CRC field, as shown in fig. 22. In a type field of 1 byte, this type of packet is typically identified as a type 70 packet, and a preselected fixed length of 8 bytes is used.

The reverse link request field may be used to inform the host of the number of bytes required by the display in a reverse link encapsulated packet for it to send data back to the host. The host should attempt to grant the request by allocating at least this number of bytes in the reverse link encapsulation packet. The host may send more than one reverse link encapsulated packet in a subframe to accommodate the data. The client may send display request and status packets at any time and the host may interpret the reverse link request parameter as the total number of bytes requested in one sub-frame. Additional details of specific examples of how reverse link data is sent back to the host are shown below.

14. Bit block transfer packet

Bit block transfer packets provide a method for scrolling a display area in an arbitrary direction. A display with this capability will report the capability in bit 0 of the display feature capability indicator field of the display capability packet. The format of the bit block transport packet is shown in fig. 23. As shown in fig. 23, this type of packet is constructed to have packet length, packet type, upper left X value, upper left Y value, window width, window height, window X shift, window Y shift, and CRC fields. This type of packet is typically identified as a type 71 packet and uses a preselected fixed length of 15 bytes.

These fields are used to specify the X and Y values of the coordinates 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 is to be moved horizontally and vertically, respectively. Positive values of the latter two fields cause the window to move down to the right, while negative values cause the window to move up to the left.

15. Bitmap area fill packet

The bitmap area fill packet provides a way to easily initialize the display area to a single color. A display with this capability will report the capability in bit 1 of the display feature capability indicator field of the display capability packet. The format of the bitmap area fill packet is shown in fig. 24. As shown in fig. 24, this type of packet is constructed to have a packet length, a packet type, an upper left X value, an upper left Y value, a window width, a window height, a data format descriptor, a pixel region fill value, and a CRC field. In the type field of 1 byte, this type of packet is typically identified as a type 72 packet, and a preselected fixed length of 17 bytes is used.

16. Bitmap pattern fill packet

Bitmap pattern fill packets provide a way to easily initialize the display area to a preselected pattern. A display with this capability will report the capability in bit 2 of the display feature capability indicator field of the display capability packet. The upper left corner of the fill 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 several times horizontally or vertically in order to fill the window. The right side or bottom of the last repeated pattern is truncated as desired. If the window is smaller than the fill pattern, the right side or bottom of the fill pattern can be truncated to accommodate the window.

The format of the bitmap pattern padding packet is shown in fig. 25. As shown in fig. 25, this type of packet is constructed to have packet length, packet type, upper left X value, upper left Y value, window width, window height, pattern width, pattern height, data format descriptor, parameter CRC, pattern pixel data, and pixel data CRC fields. In the 1-byte type field, this type of packet is typically identified as a type 73 packet.

17. Communication link data path data packet

The communication link data path packets provide a method for communicating such advanced computing capability displays as PDAs with such wireless transceivers as cellular phones or wireless data port devices. In this case, the MDDI link acts as a convenient high-speed interface between the communication device and the computing device with the mobile display, where such data packets carry data at the data link layer of the device's operating system. This data packet may be used, for example, if a web browser, email client program, or the entire PDA is embedded in the portable display. A display with this capability will report the capability in bit 3 of the display feature capability indicator field of the display capability packet.

The format of the communication link data lane packet is shown in fig. 26. As shown in fig. 26, this type of packet is constructed to have packet length, packet type, parameter CRC, communication link data, and communication data CRC fields. In the type field, this type of packet is typically identified as a type 74 packet.

18. Interface type switching request data packet

The interface type switch request packet enables the host to request the client or display to switch from an existing or current mode to a type I (serial), type II (2-bit parallel), type III (4-bit parallel), or type IV (8-bit parallel) mode. Before the host requests a particular mode, it should confirm that the display is capable of operating in the desired mode by checking bits 6 and 7 of the display feature capability indicator field of the display capability packet. The format of the interface type switch request packet is shown in fig. 27. As shown in fig. 27, this type of packet is structured to have a packet length, a packet type, an interface type, and a CRC field. This type of packet is typically identified as a type 75 packet and uses a preselected fixed length of 4 bytes.

19. Interface type acknowledgement packet

The interface type acknowledgement packet is sent by the display to acknowledge receipt of the interface type switch request packet. The requested mode, namely: type I (serial), type II (2-bit parallel), type III (4-bit parallel), or type IV (8-bit parallel) mode, as one parameter in this packet, is returned to the host. The format of the interface type acknowledgement packet is shown in fig. 28. As shown in fig. 28, this type of packet is structured to have a packet length, a packet type, an interface type, and a CRC field. This type of packet is typically identified as a type 76 packet and uses a preselected fixed length of 4 bytes.

20. Execution type switching packet

Executing the type switch packet is one method for the host to command the display to switch to the mode specified in this packet. This pattern is the same pattern as previously requested and acknowledged by the interface type switch request packet and the interface type acknowledge packet. After sending this packet, the host and display should switch to an agreed mode. The display may lose and regain link synchronization during the mode change. The format of the execution type switching packet is shown in fig. 29. As shown in fig. 29, this type of packet is structured to have a packet length, a packet type, and a CRC field. In the type field of 1 byte, this type of packet is typically identified as a type 77 packet, and a preselected fixed length of 4 bytes is used.

21. Forward audio channel enable packet

This data packet enables the host to enable or disable the audio channel in the display. This capability is useful because the display (client) can power down the audio amplifier or similar circuit elements to save power when the host has no audio output. It is clearly more difficult to use the mere presence or absence of an audio stream as an indicator. The default state when the display system is powered on is to enable all audio channels. The format of the forward audio channel enable packet is shown in fig. 30. As shown in fig. 30, this type of packet is constructed to have a packet length, a packet type, an audio channel enable mask, and a CRC field. In a type field of 1 byte, this type of packet is typically identified as a type 78 packet and a preselected fixed length of 4 bytes is used.

22. Reverse audio sample rate data packet

This packet enables the host to enable or disable the reverse link audio channel and set the audio data sampling rate for this stream. The host selects a sampling rate defined as valid in the display capability packet. If the host selects an invalid sampling rate, the display will not send the audio stream to the host. The host may disable the reverse link audio stream by setting the sample rate to 255. The default state assumed when the display system is initially powered up or connected is to disable the reverse link audio stream. The format of the inverse audio sample rate packet is shown in fig. 31. This type of packet is constructed to have a packet length, a packet type, an audio sampling rate, and a CRC field, as shown in fig. 31. This type of packet is typically identified as a type 79 packet and uses a preselected fixed length of 4 bytes.

23. Digital content protection overhead data packet

This data packet enables the host to exchange messages with the display relating to the digital content protection method being used. Two types of content protection are currently envisaged, Digital Transmission Content Protection (DTCP) or high bandwidth digital content protection system (HDCP), and space is reserved for future alternative protection scheme marking. The method used is specified by the content protection type parameter in this data packet. The format of the digital content protection overhead data packet is shown in fig. 32. As shown in fig. 32, this type of packet is constructed to have a packet length, a packet type, a content protection overhead message, and a CRC field. This type of packet is typically identified as a type 80 packet.

24. Transparent color enable packet

The transparent color enable packet is used to specify which colors are transparent in the display and enable or disable the display of images using transparent colors. A display with this capability reports the capability in bit 4 of the display feature capability indicator field of the display capability packet. When a pixel with a transparent color value is written to the bitmap, the color does not change from the previous value. The format of the transparent color enable packet is shown in fig. 33. As shown in fig. 33, this type of packet is constructed to have a packet length, a packet type, a transparent color enable, a data format descriptor, a transparent pixel value, and a CRC field. In the type field of 1 byte, this type of packet is typically identified as a type 81 packet, and a preselected fixed length of 10 bytes is used.

25. Round trip delay measurement packet

The round trip delay measurement packet is used to measure the propagation delay from the host to the client (display) plus the delay from the client (display) back to the host. This measurement inherently includes delays present in the line drivers and receivers and the interconnect subsystem. This measurement is used to set the steering delay and reverse link rate divisor parameters in the reverse link encapsulated packet generally described above. Such packets are most useful when the MDDI link is operating at maximum speed for a particular application. The MDDI _ Stb signal functions as if all zero data were sent in the following fields: all zero, two guard times and a measurement period. This causes MDDI _ Stb to flip at half the data rate, so that MDDI _ Stb can be used as a periodic clock in the display during the measurement period.

The format of the round trip delay measurement packet shown in fig. 34. As shown in fig. 34, this type of packet is constructed to have packet length, packet type, parameter CRC, all zeros, guard time 1, measurement period, guard time 2, and driver re-enable fields. This type of packet is typically identified as a type 82 packet and a preselected fixed length of 533 bits is used.

The timing of events occurring during a round trip delay measurement packet is illustrated in fig. 35. In fig. 35, the host sends a round trip delay measurement packet, which is illustrated by the presence of the parameter CRC and strobe alignment fields followed by the all zeros and guard time 1 fields. A delay 3502 occurs before the packet arrives at the client display device or processing circuit. When the display receives the data packet, at the beginning of the measuring period determined by the display, the display transmits a pattern of 0xff, 0x0 (pattern) at a time as accurate as possible to the actual time. From the perspective of the host, the actual time at which the display begins transmitting this sequence is delayed from the beginning of the measurement period. This amount of delay is essentially the time it takes for the packet to pass through the line drivers and receivers and the interconnect subsystem. A similar amount of delay 3504 is experienced for transferring this pattern from the display back to the host.

To accurately determine the round trip delay time of the signal to and from the client, the host counts the number of bit time periods that occur after the start of the measurement period until the beginning of the sequence of 0xff, 0x0 is detected. This information is used to determine when the round trip signal is passed from the host to the client and back again. Then, about half this amount is attributed to the delay caused by the unidirectional signal path to the client.

After sending the last bit of the 0xff, 0x0 mode, the display disables its line drivers substantially immediately. Guard time 2 allows the line driver of the display to go completely into a high impedance state at a time before the host transmits the packet length of the next packet. Sleep pull-up and pull-down resistors (see fig. 42) ensure that the MDDI _ Data signal remains at an active low level for these intervals in the host and display where the line drivers are disabled.

26. Forward link offset calibration packets

The forward link offset calibration packets allow the client or display to calibrate itself for differences in the propagation delay of the MDDI _ Data signal relative to the MDDI _ Stb signal. Without delay skew compensation, the maximum data rate is typically limited to a value for the potential worst-case amount of variation in these delays. This packet is typically sent only when the forward link data rate is configured to be around 50Mbps or lower. After sending this packet to calibrate the display, the data rate may be increased to over 50 Mbps. If the data rate is set too high during the offset calibration process, the display may synchronize to a glitch (alias) for that bit period, which may cause the delay offset compensation to be set off more than one bit time, resulting in a data clock error. Before sending the forward link deviation calibration packet, the highest data rate type or the highest possible interface type of the interface is selected to calibrate all the data bits present.

The format of the forward link offset calibration packet is shown in fig. 56. As shown in fig. 56, this type of packet is constructed to have a packet length (2 bytes), a packet type, a parameter CRC, a calibration data sequence, and a CRC field. In the type field, this type of packet is typically identified as a type 82 packet and has a preselected length of 515. Virtual control panel

The use of a Virtual Control Panel (VCP) allows the host to set certain user controls in the client. By allowing these parameters to be adjusted by the host, the user interface in the client is simplified because a screen allowing the user to adjust parameters such as volume or display brightness can be generated by the host software rather than by one or more microprocessors in the client. The host has the ability to read the parameter settings in the client and determine the range of valid values for each control. The client has the ability to return reports to the host of control parameters that it can adjust.

Commonly specified control codes (VCP codes) and associated data values are used to describe the controls and settings in the client. The VCP code in the MDDI specification is extended to 16 bits to maintain proper data field alignment in the packet definition and to support in the future supplemental values that are unique to this interface or future improvements.

27. Requesting VCP feature packets

Requesting a VCP feature packet provides a means, mechanism or method for the host to request the current setting of a particular control parameter or all valid control parameters. Typically, the client responds to the VCP packet with the appropriate information in the VCP feature reply packet. In one embodiment, the client uses bit 20 of the display feature capability indicator field of the display capability packet to indicate the capability to support the requested VCP feature packet.

The format of the request VCP feature packet in one embodiment is shown in fig. 69. This type of packet is constructed to have a packet length, a packet type, hClient ID, MCCS VCP code, and CRC fields, as shown in fig. 69. In one embodiment, this type of packet is generally identified as type 128, which is indicated in a 2-byte type field. The packet length describes the total number of bytes in the packet that do not include the packet length field and is typically fixed at a length of 8 bytes for this type of packet.

The hClient ID field contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and is typically set to zero. The MCCSVCP code field includes 2 bytes of information to specify MCCS VCP control code parameters. Values in the range of 0 to 255 cause the VCP feature reply packet to be returned as a single entry in the VCP feature reply list corresponding to the specified MCCS code. 65535(0xffff) the MCCS VCP code requests a VCP feature response packet with a VCP feature response list containing a list of feature response items for each control supported by the client. For this field, the values of 256 to 65534 are reserved for future use and are not currently used.

VCP feature response packet

The VCP feature reply packet provides a means, mechanism or method for the client to respond to the host request with the current setting of a particular control parameter or all active control parameters. Typically, the client sends the VCP feature response packet in response to requesting the VCP feature packet. This packet may be useful for determining the current settings for a particular parameter, determining the effective range of a particular control, determining whether a client supports a particular control, or determining the set of controls supported by a client. If a requested VCP feature is sent that relates to a particular control that is not implemented in the client, then a VCP feature reply packet is returned with a single VCP feature reply list entry corresponding to the non-implemented control containing the appropriate error code. In one embodiment, the client uses bit 20 of the display feature capability indicator field of the display capability packet to indicate the capability to support VCP feature response packets.

The format of the VCP feature acknowledgement packet in one embodiment is shown in fig. 70. As shown in fig. 70, this type of packet is constructed to have a packet length, a packet type, a clclient ID, an MCCS version, a response sequence number, a VCP feature response list, and a CRC field. In one embodiment, this type of packet is generally identified as type 129, as indicated in the 2 byte type field.

The cClientID field contains information reserved for client IDs. This field is reserved for future use and is typically set to zero. The MCCS version field contains 2 bytes of information that specifies the version of the VESAMCCS specification implemented by the client.

The 2-byte response sequence number field contains information or data specifying the sequence number of the VCP feature response packet returned by the client. The client, in response to requesting VCP feature packets having an MCCS control code value of 65535, returns one or more VCP feature response packets. The client may extend the feature reply list via a plurality of VCP feature reply packets. In this case, the client assigns a sequence number to each successive 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 1 each time. The last VCP feature list entry in the last VCP feature reply packet should contain an MCCS VCP control code value equal to 0xffff in order to determine that the packet is the last and contains the highest sequence number of the returned packet group. If only one VCP feature response packet is sent in response to the request VCP feature packet, then the response sequence number in the single packet is zero and the VCP feature response list contains records with an MCCS VCP control code equal to 0 xffff.

The number of features field in the list contains 2 bytes for specifying the number of VCP feature list entries in the VCP feature response list for the packet, and the VCP feature response list field is a set of bytes containing one or more VCP feature response list entries. The format of a single VCP feature reply list item in one embodiment is shown in fig. 71.

As shown in fig. 71, each VCP feature response list entry is strictly 12 bytes in length and includes an MCCS VCP code, a result code, a maximum value, and a current value field. The 2-byte MCCS VCP code field contains data or information specifying the MCCS VCP control code parameters associated with this list entry. 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 associated with the request for information for the designated MCCS VCP control. A value of '0' in this field means no error, while a value of '1' means that the specified control is not implemented in the client. The other values 2 to 65535 of this field are currently reserved for future use and for implementing other applications envisaged in the field, but are not used now.

The 4-byte maximum field contains a 32-bit unsigned integer to illustrate the maximum possible value that can set the specified MCCS control. This value is set to zero if the requested control is not implemented in the client. If the return value is less than 32 bits (4 bytes) in length, the value is converted to a 32-bit integer, and the most significant (unused) byte is set to zero. The 4-byte current value field contains information that specifies the current value of the MCCS VCP continuous (C) or discontinuous (NC) control that has been specified. If the requested control is not implemented in the client, or if the control is implemented but the table (T) data type, this value is set to zero. If the return value is less than 32 bits (4 bytes) in length for each VESA MCCS specification, the value is converted to a 32-bit integer with the most significant (unused) byte set to zero.

29. Setting VCP feature packets

The set VCP feature packet provides a means, mechanism or method for the host to set VCP control values for continuous and discontinuous control in the client. In one embodiment, the client uses bit 20 of the display feature capability indicator field of the display capability packet to indicate support for the ability to set the VCP feature packet.

The format of the set VCP feature packet in one embodiment is shown in fig. 72. As shown in fig. 72, this type of packet is constructed to have a packet length, a packet type, hClient ID, MCCS VCP code, the number of values in the list, a control value list, and a CRC field. This type of packet is typically identified as type 130, as shown in the 2 byte type field, and is 20 bytes long excluding the packet length field.

The hClient ID field again uses a 2 byte value to specify or act as a client ID. This field is reserved for future use and is currently set to zero. The MCCS VCP code field uses 2 bytes of information or value to specify the MCCS VCP control code parameter to be adjusted. The quantity of values field in the 2-byte list contains information or a value that specifies the number of 16-bit values present in the list of control values. The list of control values will typically contain an entry unless the MCCS control code refers to a table in the client. Without reference to the control of the table, the list of control values would contain a value that would be descriptive of the new value to be written to the control parameter specified by the MCCS VCP code field. For control involving tables, the format of the data in the list of control values 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 transmitted first, consistent with the method defined elsewhere. Finally, the 2-byte CRC field contains a 16-bit CRC of all bytes in the packet, including the packet length.

30. Request valid parameter data packet

The request-valid-parameters packet serves as a means or mechanism for requesting the client to return a valid-parameters-reply packet containing a list of parameters supported by the specified discontinuous (NC) or table (T) control. This packet should only specify discontinuous control or control involving tables in the client, and not the MCCS VCP code value of 65535(0xffff) in order to specify all control. If an unsupported or invalid MCCS VCP code is specified, an appropriate error value is returned in the valid parameter response packet. In one embodiment, the client uses bit 20 of the display characteristic capability indicator field of the display capability packet to indicate the capability to support a request for a valid parameter packet.

The format of the request valid parameter packet in one embodiment is shown in FIG. 73. As shown in fig. 73, this type of packet is constructed to have a packet length, a packet type, an hClient ID, an MCCS VCP code, and a CRC field. In one 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 typically set to have the total number of bytes in the packet, but does not include the packet length field 8. The hClient ID again specifies the client ID, but is now reserved for future use and is set to zero, as will be apparent to those of ordinary skill in the art. The 2-byte MCCS VCP code field contains a value that is used to specify a discontinuous MCCS VCP control code parameter to be queried. The value in this field should correspond to the discontinuous control implemented in the client. The values 256 to 65535(0xffff) are typically retained or considered invalid and are considered as control not implemented in the error response.

31. Efficient parameter response packet

The validity parameter response packet is sent in response to the request validity parameter packet. It serves as a means, method or mechanism to identify the active setting of the discontinuous MCCS VCP control or control for returning the contents of the table. If the control relates to a table in the client, then the VCP parameter answer list contains only a specific list of requested sequential table values. If the contents of the table cannot fit into exactly a single valid parameter response packet, multiple packets with sequential response sequence numbers may be sent by the client. In one embodiment, the client uses bit 20 of the display characteristic capability indicator field of the display capability packet to indicate the capability to support a valid parameter reply packet.

The host may request the contents of the table in the following manner: the host sends a set VCP feature packet containing the necessary or desired parameters, such as read/write parameters, LUT offset, and RGB selection; then the host sends the request effective parameter data packet for explaining the control; the client then returns one or more valid parameter response packets containing the table data. This sequence of operations performs a function similar to the table reading function described in the MCCS operational model.

If the client does not support the specific client parameters, then in one embodiment the corresponding field of this packet will contain the value 255. For parameters to be used in the client, the corresponding field should contain the value of the parameter in the client.

The format of the validity parameter response packet for one embodiment is shown in fig. 74. As shown in fig. 74, this type of packet is constructed to have a packet length, a packet type, a clclient ID, an MCCS VCP code, a response sequence number, the number of values in the list, a VCP parameter response list, and a CRC field. For one embodiment, this type of packet is typically identified as type 132, as indicated in a 2-byte type field.

The clclient ID field is reserved for future client IDs as can be appreciated from the discussion above, while the 3-byte MCCS VCP code packet contains a value that accounts for the discontinuous MCCS VCP control code parameter described by this packet. If the request valid parameter packet specifies an invalid MCCS VCP control code, the appropriate value in the response code field is used to specify the same invalid parameter value in this field. If the MCCS control code is invalid, then the VCP parameter answer list will have a length of zero.

The response code field contains 2 bytes of information or value that specifies the attributes of the response associated with the request for information regarding the designated MCCS VCP control. If the value in this field is equal to 0, then it is assumed that no errors exist for this data type and the last valid parameter reply packet in the sequence is sent, with the highest reply sequence number. If the value in this field is equal to 1, then no error is considered to be present, but other valid parameter response packets with higher sequence numbers are to be sent. If the value in this field is equal to 2, then the specified control is deemed not to be implemented in the client. If the value in this field is equal to 3, then the control specified is not discontinuous control (it is a continuous control and always has a valid set of all values from zero to its maximum). The value of this field, which is equal to 4 to 65535, is reserved for future use and is not typically used.

The 2-byte response sequence number field specifies the sequence number of the valid parameter response packet returned by the client. The client, in response to a request validity parameter packet, returns one or more validity parameter response packets. The client may extend the VCP parameter response column throughout the plurality of valid parameter response packets. In this latter case, the client will assign a sequence number to each successive packet and set the response code to 1 in all but the last packet in the sequence. The last valid parameter reply packet in the sequence will have the highest reply sequence number and the response code will contain a value of 0.

The quantity of values field in the 2-byte list specifies the number of 16-bit values present in the VCP parameter response list. If the response code is not equal to zero, the parameter for the number of values in the list is zero. The VCP parameter response list field contains a list of 2-byte values 0 through 32760 indicating the set of valid values for discontinuous control specified by the MCCS control code field. The definition of discontinuous control code is given in the VESA MCCS specification. Finally, in this embodiment, the CRC field contains a 16-bit CRC of all bytes in the packet, including the packet length.

Alpha cursor image

The MDD interface and associated protocol and mechanism of the present invention for communicating data over a communication link provides support for multiple image planes that overlap each other and have varying degrees of transparency. The hardware cursor may be implemented using overlapping images with variable X-Y offsets. An overview of alpha cursor functionality and related protocol support is provided below. The capability to support an alpha cursor image packet is defined in an alpha cursor image capability packet sent in response to a request dedicated status packet.

32. Alpha cursor image capability data packet

The alpha cursor image capability packet is used to define the characteristics of the alpha cursor image and the associated transparency map in the client. In one embodiment, the client indicates the capability to support alpha cursor image capability packets using the parameter value 133 in the valid parameter answer list of the valid status answer list packet. For one embodiment, the packet length specified in the packet length field is set to a fixed value of 20, which excludes the packet length field.

The format of the alpha cursor image capability packet in one embodiment is shown in fig. 75. As shown in fig. 75, this type of packet is constructed to have a packet length, a packet type, a clclient ID, an alpha cursor identifier, an alpha cursor bitmap width, an alpha cursor bitmap height, RGB Capability, monochrome Capability, reserved 1, Y Cr Cb Capability, transparency map resolution, Capability Bits (Capability Bits), and CRC fields. The clclient ID field is typically 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 alpha cursor image planes, the alpha cursor identifier has a valid range of 0 to n-1. In one embodiment, the value n is specified by an alpha cursor image plane field of the display capability packet. The client returns a unique alpha cursor image capability packet for each alpha cursor image plane.

The 2-byte alpha cursor bitmap width field value indicates the width of the alpha cursor bitmap image expressed in number of pixels, and the 2-byte alpha cursor bitmap height field value indicates the height of the alpha cursor bitmap image expressed in number of pixels.

RGB capability field-2 bytes, which contains a 16-bit unsigned integer to specify the number of bits of resolution that can be displayed in RGB format. If the client is not able to use the RGB format, then this value is zero. The RGB capability word includes three separate values, which in one embodiment is implemented as: bits 3 to 0 define the maximum number of bits of blue (blue intensity) in each pixel; bits 7 to 4 define the maximum number of bits of green (green intensity) in each pixel; bits 11 to 8 define the maximum number of bits of red (red intensity) in each pixel; bits 15 to 12 are reserved for future use in rendering RGB capability information and are now set to zero.

A 1-byte monochrome capability field is used to specify the number of bits of resolution that can be displayed in a monochrome format. If the client is unable to use a monochrome format, then this value is zero. Bits 7 through 4 are reserved for future use and are therefore typically set to zero. Bits 3 to 0 define the maximum number of bits of gray levels that can be present in each pixel. These four bits can be specified to include 1 to 15 bits per pixel. If the value is zero, the client does not support the monochrome format.

The 1-byte reserved 1 field contains a value that is normally reserved for future use, and therefore, all bits in this field are set to zero. This would align the subsequent 2-byte field with a 16-bit word address (address) and the 4-byte field with a 32-bit word address.

The 2-byte Y Cb Cr capability field contains a value or information that specifies the number of bits of resolution that can be displayed in the Y Cb Cr format. This value is zero if the client cannot use the Y Cr Cb format. In general, in one embodiment, the Y Cb Cr capability word includes three separate values: bits 3 to 0 define the maximum number of bits used to specify Cr sampling; bits 7 to 4 define the maximum number of bits used to account for Cb samples; bits 11 through 8 define the maximum number of bits used to account for the Y samples; and bits 15 through 12 are reserved for future use in rendering Y Cb Cr capability information or values, but are now set to zero.

The 1-byte transparency map resolution field contains a value or information that specifies the number of bits (depth) in each pixel position of the alpha cursor image transparency map. This value ranges from 1 to 8. If the value is zero, transparency mapping is not supported for this alpha cursor image buffer (the buffer specified by the alpha cursor identifier field).

The 1-byte capability bit field provides a value or information that includes a set of flags that specify capabilities associated with the alpha cursor image buffer. In one embodiment, the flag is defined as: the 0 bit is used to select the pixel data to be placed in the alpha cursor video stream packet in the packet format. Bit 1 is used to indicate that the transparency map data in the alpha cursor transparency packet is in packet format. An example of byte aligned and packed transparency map data is shown in fig. 76. Bit 2 is used to indicate that the alpha cursor image plane can support the image shift capability using the alpha cursor image shift packet. Bit 3 is used to indicate that the alpha cursor image plane can support the color mapping data format. The same color map table is used for the alpha cursor image plane as used for the main image buffer and scalable video stream. The color map is configured using color map data packets described elsewhere.

Bits 7 through 4 are reserved for future use and are therefore typically set to a zero value or logic level low.

33. Alpha cursor transparency mapping data packet

The alpha cursor transparency map packet defines the contents of the image transparency map for the designated alpha cursor image plane. Some applications may require a transparency map with a greater amount of data than can be transmitted in a single packet. As such, multiple alpha cursor transparency map packets may be sent, each with a different subset of the transparency map, using the transparency map X and Y start fields as described below. These fields operate in a similar manner to the X start and Y start fields of a video stream packet. In one embodiment, the client uses the transparency map resolution field of the alpha cursor image capability packet for each particular alpha cursor plane specified by the alpha cursor identifier field of the alpha cursor image capability packet to indicate its capability to support the alpha cursor transparency map packet. The packet length and client ID fields are used as described above for the other packets. In one embodiment, the value 134 in the packet type field is used to identify the packet as an alpha cursor transparency map packet.

The format of an alpha cursor transparency map packet is shown in fig. 76 for one embodiment. As shown in fig. 76, this type of packet is constructed to have a packet length, a packet type, an hClient ID, an alpha cursor identifier, a transparency map X start, a transparency map Y start, a transparency map resolution, a reserved 1, a parameter CRC, a transparency map medium, and a transparency map 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 alpha cursor image planes, the alpha cursor identifier has a valid range of 0 to n-1.

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

The transparency map resolution field (1 byte) contains a value to specify the resolution of the transparency map and whether the data is packed. In one embodiment of this field, bits 3 through 0 define the number of bits of resolution present in all transparency map entries. Valid values indicate that the width is 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 map resolution field in the alpha cursor image capability packet. Bits 6 through 4 are reserved for future use and are therefore typically set to logic zero at this time. Bit 7 of this byte indicates whether the transparency map data is packed or in byte aligned form. If bit 7 is equal to '1', then the transparency map data is in packed form, and if '0', the data is in byte aligned form. In error! No reference source was found. An example of packed and byte aligned transparency map data is shown in. The value of this bit must match the bit 1 value of the capability bit field of the alpha cursor image capability packet.

The 1-byte reserved 1 field is reserved for future use, and therefore all bits in this field are typically set equal to a logic zero level. One purpose of this field is to have all subsequent 2-byte fields aligned with 16-bit word addresses and 4-byte fields aligned with 32-bit word addresses.

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

For the transparency map data field, each transparency map location is 1 to 8 bits in width. If a single transparency map cannot fit into exactly one alpha and cursor transparency map packet, the entire transparency map may be specified by sending multiple packets, each with different transparency map data and transparency map X and Y start values.

The 2-byte transparency map data CRC field contains a 16-bit CRC of only the transparency map data. If this CRC fails to check, transparency map data may still be used, but the CRC error count will increase.

34. Alpha cursor image offset data packet

The alpha cursor image offset data packet specifies the X and Y offsets of the cursor from the upper left corner of the primary display image. The format of the alpha cursor image shift packet is illustrated in fig. 77. As shown in fig. 77, in one embodiment, the alpha cursor image offset packet is constructed to have a packet length, a packet type, an hClient ID, an alpha cursor X offset, an alpha cursor Y offset, and a CRC field. In one embodiment, the client indicates its ability to support an alpha cursor image shift packet using bit 2 of the capability bit field in the alpha cursor image capability packet for each particular alpha cursor plane specified by the alpha cursor identifier field of the alpha cursor image capability packet. In one embodiment, the packet length is fixed at 10, as indicated by the 2 byte packet length field. In one embodiment, the packet type 135 identifies the packet as an alpha cursor image offset packet.

The 2-byte alpha cursor X and Y offset fields contain values that respectively illustrate the horizontal and vertical offsets of the leftmost column and top row of pixels of the cursor image from the left and top of the main image. The 2-byte hClient ID contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

35. Alpha cursor video stream data packet

The alpha cursor video stream packet carries video data to update the rectangular area of the alpha cursor image plane. The size of this area may be as small as a single pixel or as large as the entire display. Fig. 78 illustrates the format of an alpha cursor video stream packet. As shown in fig. 78, in one embodiment, an alpha cursor video stream packet is constructed with packet length, packet type, bclent ID, 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 one embodiment, the client indicates its ability to support alpha cursor video stream packets and their associated parameters by using an alpha cursor image capability packet for each particular alpha cursor plane specified by the alpha cursor identifier field of the alpha cursor image capability packet and a value of 17 in the packet type field indicates or identifies the packet as an alpha cursor video stream packet. The hClient ID field (2 bytes) is reserved for future use as a client ID and is also set to typically zero, as will be appreciated in the art.

The 2 byte video data format descriptor field contains information or a value that specifies the format of each pixel within the pixel data in the current stream of the current packet. The pixel data format must conform to at least one valid format of the alpha cursor image plane, as defined in the alpha cursor image capability packet. The video data format descriptor field contains values that are only used to define the pixel format of the current packet and does not imply that an unchanged format will be used continuously during the lifetime (lifetime) of a particular video stream. Error! No source of reference was found. "illustrates how the video data format descriptor is encoded. The format is as follows:

in one embodiment, when bits [15:13] are '000', then the video data comprises an array of monochrome pixels, with the number of bits per pixel defined by bits 3-0 of a video data format descriptor word. Bits 11 through 4 are then set to zero. When bits [15:13] are '001', then the video data comprises an array of color pixels, all specifying a color by a color map (palette). Bits 5 to 0 of the video data format descriptor word define the number of bits per pixel, while bits 11 to 6 are set to zero. When bits [15:13] are '010', then the video data includes a color pixel array having the original RGB format, where the number of bits per pixel for red is defined by bits 11-8, the number of bits per pixel for green is defined by bits 7-4, and the number of bits per pixel for blue is defined by bits 3-0. The total number of bits in each pixel is the sum of the number of bits for red, green and blue.

When bits [15:13] are '011', then the video data comprises an array of video data in a 4:2: 2Y Cb Cr format with luminance and chrominance information. The number of bits per pixel of luminance (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 Cb and Cr components are sent at half the rate of the Y component. The video samples in the pixel data portion of this packet are organized as follows: cbn, Yn, Crn, Yn +1, Cbn +2, Yn +2, Crn +2, Yn +3, … …, where Cbn and Crn are associated with Yn and Yn +1, and Cbn +2 and Crn +2 are associated with Yn +2 and Yn +3, and so on. Yn, Yn +1, Yn +2, and Yn +3 are luminance values of four consecutive pixels from left to right in a single line. The order of the color components is the same as the microsoft UYVYFOURCC format. If there are an odd number of pixels (X right edge-X left edge +1) in a row of the window located by the video stream data packet, the Cb value corresponding to the last pixel in each row will be followed by the Y value of the first pixel of the next row. It is proposed that the window using the Y Cb Cr format has a width of an even number of pixels. The pixel data in the data packet contains an even number of pixels. Where the last pixel of the pixel data corresponds to the last pixel of a line in the window specified in the video stream packet header, i.e., when the X position of the last pixel in the pixel data is equal to the X right edge, the pixel data may contain an odd or even number of pixels. For all four formats, bit 12 (labeled "P" in the figure) specifies whether the pixel data sample is packed. When the value of bit 12 is '0', then each pixel in the pixel data field and each color within each pixel are byte aligned with the MDDI interface byte boundaries. When the value of bit 12 is a '1', then each pixel in the pixel data and each color within each pixel are packed relative to the previous pixel or color within the pixel that did not leave an unused bit.

In one embodiment, the pixel data attribute field (2 bytes) has a series of bit values as explained below. Bits 1 and 0 select how to route the display pixel data. For bit value '11', data is displayed to both eyes, for bit value '10', data is routed only to the left eye, and for bit value '01', the bit value is routed only to the right eye.

Bit 2 indicates whether the pixel data is provided in interlaced format, the value '0' means that the pixel data is in standard progressive format and the line number (pixel Y coordinate) is incremented by 1 as one proceeds from one line to the next. When this bit has the value '1', the pixel data is in interlaced format and the line number is incremented by 2 as one progresses from one line to the next. Bit 3 indicates that the pixel data is in an alternate pixel format. This is similar to the standard interlacing mode allowed by bit 2, but here the interlacing is vertical, not horizontal. When bit 3 is '0' the pixel data is in a standard pixel-by-pixel format, and the column number (pixel X coordinate) is incremented by 1 as each successive pixel is received. When bit 3 is '1', the pixel data is in an alternating pixel format, with the column number incremented by 2 as each pixel is received.

Bit 4 indicates whether the pixel data relates to a display or a camera as if the data were transferred to or from an internal display of a wireless telephone or similar device, or even a portable computer or other device as described above, or the data were transferred to or from a camera embedded in 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 a '1', the pixel data is transferred to or from some type of camera or video device, such devices being well known in the art.

Bit 5 is reserved for future use or for application of the MDD interface and is therefore typically set to a zero value or '0'.

Bits 7 and 6 are display update bits to illustrate the frame buffer to which pixel data will be written. More specific effects are discussed elsewhere. For bit value '01', the pixel data is written into the offline image buffer. For bit value '00', the pixel data is written to the image buffer for updating the display. For bit value '11', pixel data is written into all image buffers. The bit value or combination '10' is treated as an invalid value or flag and pixel data is ignored and not written to any image buffer. This value may be useful for future applications of the interface.

Bits 8 through 15 are reserved for future use and are therefore typically set to zero.

In one embodiment, the 2 byte X start and Y start fields describe the absolute 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 illustrate the X coordinate of the left edge and the Y coordinate of the top edge of the alpha cursor image window filled in by the pixel data field, while the X right edge and Y bottom edge fields illustrate the X coordinate of the right edge and the Y coordinate of the bottom edge of the alpha cursor image window being updated.

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

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

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

The pixel data CRC field (2 bytes) contains a 16-bit CRC over pixel data only. If the CRC validation of this value fails, the pixel data is still available for use, but the CRC error count is incremented.

Scalable video stream images

The MDD interface or protocol mechanism or method provides support for scalable video streaming images, which allows a host to send an image to a client, which may be scaled up or down compared to the original image, and the scalable image (the scaled image) is copied to a main image buffer. An overview of the functionality of a scalable video stream (scalable video stream) and associated protocol support is provided elsewhere. The capability to support the scalable video stream is defined within or by a scalable video stream capability packet that is transmitted in response to a request for a special status packet.

36. Scalable video streaming capability packets

The scalable video stream capability packet defines characteristics of scalable video stream source images in or used by the client. The format of the scalable video stream capability packet is generally shown in fig. 79. As shown in fig. 79, in one embodiment, a scalable video stream capability packet is constructed having a packet length, a packet type, a clclient ID, a maximum number of streams, a source maximum X size, a source maximum Y size, RGB capability, monochrome capability, reserved 1, Y Cr Cb capability, reserved 2, and CRC fields. In one embodiment, the packet length is selected to be a fixed 20 bytes, as shown in the length field, including a 2 byte cClientID field and CRC field, where the cClientID field is reserved for use by the client ID and is otherwise set to zero. In one embodiment, the client indicates its capability to support scalable video stream capability packets using the parameter values 143 in the valid parameter answer list of the valid status answer list packet.

The 2-byte maximum stream number field contains a value for identifying the maximum number of synchronous scalable video streams that can be allocated at one time. In one embodiment, if the maximum number of scalable video streams has been allocated, the client should deny the request to allocate the scalable video streams. The client may also deny the allocation request based on other resource limitations in the client if less than the maximum number of scalable video streams are allocated.

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

The RGB capability field uses values to specify the number of bits of resolution that can be displayed in RGB format. This value is set equal to zero if the scalable video stream cannot use the RGB format. The RGB capability word includes three independent unsigned values: bits 3 to 0 define the maximum number of bits for blue (blue intensity) in each pixel, bits 7 to 4 define the maximum number of bits for green (green intensity) in each pixel, bits 11 to 8 define the maximum number of bits for red (red intensity) in each pixel, and bits 15 to 12 are reserved for future capability definitions, typically set to zero.

The 1-byte monochrome capability field contains a value specifying the number of bits of resolution that can be displayed in monochrome format. This value is zero if the scalable video stream cannot use a monochrome format. Bits 7 through 4 are reserved for future use and should therefore be set to zero ('0') for the current application, although this value may change over time, as will be understood by those skilled in the art. Bits 3 to 0 define the maximum number of bits of gray levels that can be present in each pixel. These four bits can indicate that each pixel includes 1 to 15 bits. If the value is zero, the scalable video stream does not support the monochrome format.

The reserved 1 field (here 1 byte) is reserved for future use in providing values related to scalable video stream packet information or data. Thus, currently, all bits in this field are set to logic '0'. One purpose of this field is to have all subsequent 2-byte fields aligned with 16-bit word addresses and 4-byte fields aligned with 32-bit word addresses.

The 2-byte Y Cb Cr capability field contains a value to specify the number of bits of resolution that can be displayed in the Y Cb Cr format. This value is zero if the scalable video stream cannot use the Y Cb Cr format. Typically, the Y Cb Cr capability word includes three independent unsigned values: bits 3 to 0 define the maximum number of bits used to specify Cr sampling; bits 7 to 4 define the maximum number of bits used to account for Cb samples; bits 11 through 8 define the maximum number of bits used to account for the Y samples; bits 15 through 12 are reserved for future use and are typically set to zero.

The 1-byte capability bit field contains an 8-bit unsigned integer that contains a set of flags that specify capabilities associated with the scalable video stream. The flags are defined as follows: bit 0 covers the case where the pixel data in a scalable video stream packet can be in a packed format. In error! No reference source was found. An example of a data packet and byte aligned pixel data is shown. Bit 1 is reserved for future use and set to zero; bit 2 is reserved for future use and set to zero; bit 3 covers the case where the scalable video stream can be specified in the color mapping data format. The color map for the scalable video stream is the same as the color map for the primary image buffer and the alpha cursor image plane. The color map may be configured using color map data packets described elsewhere; and bits 7 through 4 are reserved for future use and are typically set to zero.

The reserved 2 field (here 1 byte) is reserved for future use in providing values related to scalable video stream packet information or data. Thus, currently, all bits in this field are set to logic '0'. One purpose of this field is to have all subsequent 2-byte fields aligned with 16-bit word addresses and 4-byte fields aligned with 32-bit word addresses.

37. Scalable video stream setup packet

The scalable video stream setup package is used to define parameters of the scalable video stream, and the client uses this information to allocate internal memory for buffering and scaling the images. The stream may be deallocated by sending packets with the X picture size and Y picture size fields being zero. The deallocated scalable video stream may later be reallocated using the same or different stream parameters. In one embodiment, the client indicates its capability to support scalable video stream setup packets using the parameter values 143 in the valid parameter answer list of the valid status answer list packet and by using a non-zero value in the maximum number of streams field of the scalable video stream capability packet.

In error! No source of reference was found. "specifies the packet definition.

Scalable video stream setup packet

Packet length

136 packet type

hClient ID

Stream ID

Video data format descriptor

Pixel data attributes

2 bytes

X left edge

Y top edge

X right edge

Y bottom edge

Size of X image

Size of Y image

CRC

2 bytes

The data packet content is as follows:

packet length-2 bytes, which contains a 16-bit unsigned integer to specify the total number of bytes in the packet that do not include the packet length field. The packet length of this packet is always 24.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 136 identifies the packet as a scalable video stream setup packet.

hClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and is set to zero.

Stream ID-2 bytes, which contains a 16-bit unsigned integer that is a unique identifier for specifying the stream ID. This value is assigned by the host and should be a value from zero to the maximum stream ID value specified in the display capability packet. The host must carefully manage the use of the flow ID values to ensure that each active flow is assigned a unique value and that no more active flows are deallocated or reassigned.

Video data format descriptor-2 bytes, which includes a 16-bit unsigned integer for specifying the format of each pixel of pixel data in the current stream of current data packets. The pixel data format must conform to at least one valid format of the alpha cursor image plane, as defined in the alpha cursor image capability packet. The video data format descriptor defines only the pixel format of the current packet and does not imply that a constant format will last during the lifetime of a particular video stream. Error! No source of reference was found. "illustrates how the video data format descriptor is encoded. The format is as follows:

if bits [15:13] are 000, the video data comprises an array of monochrome pixels, with the number of bits per pixel defined by the 3-0 bits of a video data format descriptor word. Bits 11 to 4 should be set to zero.

If bits [15:13] are 001, then the video data includes an array of color pixels, where each color pixel specifies a color through a color map (palette). Bits 5 through 0 of the video data format descriptor word define the number of bits per pixel. Bits 11 to 6 should be set to zero.

If bits [15:13] are 010, then the video data includes a color pixel array having the original RGB format, where the number of bits per pixel for red is defined by bits 11-8, the number of bits per pixel for green is defined by bits 7-4, and the number of bits per pixel for blue is defined by bits 3-0. The total number of bits in each pixel is the sum of the number of bits for red, green and blue.

If [15:13] ═ 011, the video data includes an array of video data having a Y Cb Cr format of 4:2:2 with luminance and chrominance information. The number of bits per pixel of luminance (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 Cb and Cr components are sent at half the rate of the Y component. In addition, the video samples in the pixel data portion of this packet will be organized as: cbn, Yn, Crn, Yn +1, Cbn +2, Yn +2, Crn +2, Yn +3, … …, where Cbn and Crn are associated with Yn and Yn +1, and Cbn +2 and Crn +2 are associated with Yn +2 and Yn +3, and so on. Yn, Yn +1, Yn +2, and Yn +3 are luminance values of four consecutive pixels from left to right in a single line. The order of the color components is the same as the UYVYFOURCC format from Microsoft corporation. If there are an odd number of pixels in a row of the window referred to by the video stream data packet (X right edge-X left edge +1), the Cb value corresponding to the last pixel in each row will be followed by the Y value of the first pixel of the next row. It is proposed that the window using the Y Cb Cr format has a width of an even number of pixels. The pixel data in the data packet should contain an even number of pixels. Where the last pixel of the pixel data corresponds to the last pixel of a line in the window specified in the video stream packet header, i.e., when the X position of the last pixel in the pixel data is equal to the X right edge, the pixel data may contain an odd or even number of pixels.

For all four formats, bit 12 (labeled "P" in error! no reference source found.) specifies whether the pixel data sample is packed. Error! No source of reference was found. "illustrates the difference between packed and byte-aligned pixel data.

Each pixel in the 0-pixel data field and each color within each pixel form a byte alignment with the MDDI interface byte boundaries.

Each pixel in the 1-pixel data and each color within each pixel is packed relative to the previous pixel or color within the pixel that did not leave an unused bit.

Pixel data attribute-2 bytes, which contains a 16-bit unsigned integer explained as follows:

bits 1 and 0 select the display to which the pixel data should be routed.

Bit [1:0] ═ 11 or 00-displays data to both eyes

Bit [1:0] — 10-data is routed to the left eye only.

Bit [1:0] ═ 01 — data is routed only to the right eye.

Bit 2 indicates that the pixel data is in interlaced format.

Bit 2 is 0-pixel data in the standard progressive format. When proceeding from one row to the next, the row number (pixel Y coordinate) is incremented by 1.

Bit 2 is 1-pixel data in interlaced format. When proceeding from one row to the next, the row number (pixel Y coordinate) is incremented by 2.

Bit 3 indicates that the pixel data is in an alternate pixel format. This is similar to the standard interlacing mode allowed by bit 2, but here the interlacing is vertical rather than horizontal.

Bit 3 is 0-pixel data in a standard progressive pixel format. As each successive pixel is received, the column number (pixel X coordinate) is incremented by 1.

Bit 3 is 1-pixel data in alternating pixel format. As each pixel is received, the column number (pixel X coordinate) is incremented by 2.

Bit 4 indicates whether the pixel data relates to a display or a camera.

Bit 4 is 0-pixel data is sent to or from the display frame buffer.

Bit 4 is 1-pixel data is sent to or from the camera.

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

Bits 7 and 6 are display update bits that are used to illustrate the frame buffer to which pixel data is to be written. In error! Reference Source "and" error!not found! The section "reference source not found" describes the utility of the frame update bit in more detail.

Bit [7:6] — 01-pixel data is written into the offline image buffer.

Bit [7:6] — 00-pixel data is written to the image buffer for updating the display.

Bit [7:6] — 11-pixel data is written to all image buffers.

Bit [7:6] ═ 10-null. Is reserved for future use. The pixel data is ignored and not written to any image buffer.

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

X left edge-2 bytes, which contains a 16-bit unsigned integer that is used to illustrate the X coordinate of the left edge of the destination image.

Y top edge-2 bytes, which contains a 16-bit unsigned integer that specifies the Y coordinate of the top edge of the target image.

X right edge-2 bytes, which contains a 16-bit unsigned integer that is used to illustrate the X coordinate of the right edge of the target image.

Y bottom edge-2 bytes, which contains a 16-bit unsigned integer that is used to illustrate the Y coordinate of the bottom edge of the target image.

The X-picture size is 2 bytes, which contains a 16-bit unsigned integer that accounts for the width of the source picture.

The Y-image size is 2 bytes, which contains a 16-bit unsigned integer that accounts for the height of the source image.

CRC-2 bytes, which contains a 16 bit CRC of all bytes in the packet, including the packet length.

Scalable video stream acknowledgment packets

The scalable video stream acknowledgement packet allows the client to acknowledge receipt of the scalable video stream setup packet. The client indicates its capability to support scalable video stream acknowledgement packets via the parameter values 143 in the valid parameter answer list of the valid status answer list packet and via a non-zero value in the maximum stream number field of the scalable video stream capability packet.

The packet definition is described.

Scalable video stream acknowledgment packets

Packet length

Packet type 137

cClinet ID

Stream ID

Confirmation code

CRC

2 bytes

The data packet content is as follows:

packet length-2 bytes, which contains a 16-bit unsigned integer to indicate the total number of bytes in the packet that do not include the packet length field. The packet length of this packet is always 10.

Packet type-packet type 137 identifies the packet as a scalable video stream acknowledgment packet.

cClientID-2 bytes, which contains a 16-bit unsigned integer reserved for client ID. This field is reserved for future use and set to zero.

Stream ID-2 bytes, which contains a 16-bit unsigned integer that is a unique identifier to specify the stream ID. This is the same value as the value assigned by the host in the scalable video stream setup packet.

The 2-byte confirmation code field provides a value containing a code describing the result of attempting to update the specified scalable video stream. The code is defined as follows:

0-flow allocation attempts were successful.

The 1-flow deallocation attempt was successful.

2-the assignment attempt to an already assigned stream ID is invalid.

3-deallocation attempt to a deallocated flow ID is invalid.

4-client does not support scalable video streaming

The 5-stream parameters are not consistent with client capabilities.

The 6-stream ID value is greater than the maximum allowed by the client.

7-the client has insufficient resources available to allocate the specified stream.

CRC-2 bytes, which contains a 16 bit CRC of all bytes of the packet including the length of the packet.

Scalable video stream data packet

A scalable video stream packet is used to transmit pixel data associated with a particular scalable video stream. The size of the area referred to by this packet is defined by the scalable video stream setup packet. The client indicates its capability to support scalable video stream packets via the parameter values 143 in the valid parameter acknowledgement list of valid status acknowledgement list packets and via a successful scalable video stream distribution response in the acknowledgement code field of the scalable video stream acknowledgement packets.

The packet definition is illustrated in fig. 1.

Scalable video stream data packet

Packet length

Packet type 18

hClientID

Stream ID

Parametric CRC

Pixel counting

Pixel data

Pixel data CRC

Packet length

2 bytes

-12 bytes

FIG. 1 scalable video stream packet

The data packet content is as follows:

packet length-2 bytes, which contains a 16-bit unsigned integer to indicate the total number of bytes in the packet that do not include the packet length field.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 18 identifies the packet as a scalable video stream packet.

hClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

Stream ID-2 bytes, which contains a 16-bit unsigned integer that gives the unique identifier of the stream ID. This value is specified by the host in the scalable video stream setup packet and acknowledged in the scalable video stream acknowledgement packet.

Pixel count-2 bytes, which contains a 16-bit unsigned integer that specifies the number of pixels in the pixel data field.

Parameter CRC-2 bytes, which contains a 16-bit CRC of all bytes from the packet length to the pixel count. If this CRC fails to check, the entire packet is discarded.

Pixel data-the original video information to be scaled and subsequently displayed. The data is formatted as described by the video data format descriptor field. The data is transferred one row at a time, as in error! No source of reference was found. As defined in the section.

Pixel data CRC-2 bytes, which contains a 16 bit CRC of only pixel data. If this CRC fails to check, the pixel data may still be used, but the CRC error count is increased.

Requesting specialized status packets

Requesting a dedicated status packet provides the host with a means for requesting the client to send a capability or status packet back to the host as specified in this packet. The client returns a packet of the specified type in the next reverse link encapsulation packet. If the client has the capability to respond to the request specific status packet, the client will set bit 17 in the display characteristic capability indicator field of the display capability packet. The client should indicate its capability to support requesting dedicated status packets via bit 21 of the display characteristic capability indicator field of the display capability packet.

Requesting specialized status packets

Packet length

Packet type 138

hClient ID

Status packet ID

CRC

2 bytes

Request-specific status packet

The data packet content is as follows:

packet length-2 bytes, which contains a 16-bit unsigned integer to indicate the total number of bytes in the packet that do not include the packet length field. The packet length of this packet is always 10.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 138 identifies the packet as a request-specific status packet.

hClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

Status packet ID-2 byte, which contains a 16-bit unsigned integer to specify the capabilities that the client should send to the host or the type of status packet, as follows:

66-display capability packets should be sent by the client.

133-an alpha cursor image capability packet should be sent by the client.

139-a valid status reply list packet should be sent identifying the client's ability to send and the exact type of status packet.

140-packet handling delay parameter packets should be sent by the client.

141-personal display capability packets should be sent by the client.

142-a display error report packet should be sent by the client.

143-scalable video streaming capability packets should be transmitted by the client.

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

Bits 56 through 63-may be used for manufacturer specific capability and status identifiers.

CRC-2 bytes, which contains a 16-bit CRC of all bytes in the packet, including the packet length.

Valid status answer list packet

The valid status reply list packet provides the host with a list of status and capability packets to which the client has the capability to respond. The client should indicate its ability to support a valid status answer list packet via bit 21 of the display characteristic capability indicator field of the display capability packet.

Valid status answer list packet

Packet length

Data packet type 139

cClinet ID

Number of values in the list

Efficient parameter answer list

CRC

2 bytes data packet length-8 bytes 2 bytes

The data packet content is as follows:

Packet length-2 bytes, which contains a 16-bit unsigned integer to indicate the total number of bytes in the packet that do not include the packet length field. The packet length of this packet is always 10.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 139 identifies the packet as a valid status acknowledgement packet.

cClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

The number of values in the list-2 bytes, which contains a 16-bit unsigned integer, is used to illustrate the number of entries in the subsequent valid parameter response list.

Valid parameter answer list-a list of 2 byte parameters that specify the capabilities or type of status packets that the client may send to the host. If the client has indicated that it can respond to the request-specific status packet (via bit 21 of the display feature capability indicator field in the display capability packet), it should always be able to send at least a display capability packet (packet type 66) and a valid status answer list packet (packet type 139). The packet types and their meanings that may be included in this list are:

66-the client is able to send a display capability packet.

133-client is capable of sending an alpha cursor image capability packet.

139-capable of sending a valid status reply list packet identifying the capabilities that the client is capable of sending and the exact type of status packet.

140-the client can send a packet processing delay parameter packet.

141-client is capable of sending personal display capability packets.

142-the client can send a display error report packet.

143-the client is capable of transmitting scalable video stream capability packets.

144-the client is able to send a display identification packet.

Bits 56 through 63-may be used for manufacturer specific capability and status identifiers.

CRC-2 bytes, which contains a 16 bit CRC of all bytes of the packet including the length of the packet.

Packet processing delay parameter packet

Packet processing delay parameter a packet provides a set of parameters to allow a host to calculate the time required to complete processing associated with the receipt of a particular packet type. Some commands sent by the host cannot be completed by the client in zero time. The host may poll status bits in the display request and status packets to determine whether certain functions have been completed by the client, or the host may calculate the completion time using parameters returned by the client in the packet processing delay parameter packet. The client should indicate its ability to support packet processing of delay parameter packets via parameter values 140 in the valid parameter answer list of valid status answer list packets.

Packet processing delay parameter packet

Packet length

Packet type 140

cClinet ID

Number of list entries

Delay parameter list

CRC

2 bytes data packet length-8 bytes 2 bytes

The data packet content is as follows:

packet length-2 bytes, which contains a 16-bit unsigned integer to indicate the total number of bytes in the packet that do not include the packet length field. The packet length of this packet is always 10.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 140 identifies the packet as a packet handling delay parameter packet.

cClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

The list entry number-2 bytes, which contains a 16-bit unsigned integer to account for the number of entries in the subsequent valid parameter response list.

Valid parameter answer list-a list containing one or more delayed parameter list items. In error! No source of reference was found. The format of a single delay parameter list entry is shown.

CRC-2 bytes, which contains a 16 bit CRC of all bytes of the packet including the length of the packet.

Delay parameter list items

Delayed packet type

Pixel delay

Horizontal pixel delay

Vertical pixel retardation

Fixed delay

2 bytes 1 byte

Each delay parameter list entry is exactly 6 bytes in length and is defined as:

delay packet type-2 bytes, which contains a 16-bit unsigned integer to specify the packet type for subsequent delay parameter application.

The pixel is delayed by-1 byte, which contains an 8-bit unsigned integer as the delay value index (index). The value read from the table is multiplied by the total number of pixels in the destination field of the packet. The total number of pixels is the width times the height of the destination area of the bitmap located by the packet. Equations 0-1 are used to calculate the total delay.

The horizontal pixel is delayed by-1 byte, which contains an 8-bit unsigned integer that is an index into a delay value table (the same table as the DPVL). The value read from the table is multiplied by the width (in pixels) in the destination field of the packet. Equations 0-1 are used to calculate the total delay.

The vertical pixels are delayed by-1 byte, which contains an 8-bit unsigned integer that is the index of the delay value table (the same table as the DPVL). The value read from the table is multiplied by the height (in pixels) in the destination field of the packet. Equations 0-1 are used to calculate the total delay.

Fixed delay-1 byte, which contains an 8-bit unsigned integer that is the index of a delay value table (the same table as the DPVL). The values read from the table are fixed delay parameters representing the time required to process a data packet independent of any parameter values specified in the data packet. Equations 0-1 are used to calculate the total delay.

Delay (packet processing delay (pixel delay) total number of pixels) +

(packet processing delay (horizontal pixel delay) +width)

(packet processing delay (vertical pixel delay). height) +

Packet processing delay (fixed delay)

Equation 0-1, packet processing completion time delay

For some packets, the total number of pixels, width or height is not used, since these parameters are not referenced in the corresponding packet. In these cases, the corresponding pixel delay parameter is zero.

Personal display capability data packet

The personal display capability data packet provides a set of parameters describing the capabilities of a personal display device, such as a headband display or display glasses. This enables the host to self-define the display information according to the specific capabilities of the client. On the other hand, the client indicates its ability to send the personal display capability packet by using the corresponding parameter in the valid parameter answer list of the valid status answer list packet.

Personal display capability data packet

Packet length

141 type of packet

cClinetID

Sub-pixel layout

Pixel shape

Horizontal field of view

Vertical field of view

Cross of visual axis

2 bytes 1 bytes

Left/right image overlay

Transparency

Maximum brightness

Optical power

Minimum IPD

Maximum IPD

View curvature point list (25 2 byte values)

CRC

1 byte 2 byte 1 byte 50 byte 2 byte

The data packet content is as follows:

packet length-2 bytes, which contains a 16-bit unsigned integer to indicate the total number of bytes in the packet that do not include the packet length field. The packet length of this packet is always 68.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 141 identifies the packet as a personal display capability packet.

cClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

The subpixel layout field contains an 8-bit unsigned integer to illustrate the physical layout of subpixels from top to bottom and left to right, and: 0 is used to indicate that the subpixel layout is undefined; 1 is used to indicate red, green, blue stripes; 2 is used to indicate blue, green, red stripes; 3 is used to indicate four pixels with a 2 x 2 subpixel layout comprising red on the top left, blue on the bottom right and two green subpixels, one on the bottom left and one on the top right; 4 is used to indicate four pixels with a 2 x 2 sub-pixel layout comprising red on the bottom left, blue on the top right and two green sub-pixels, one on the top left and one on the bottom right; 5 is used to indicate Δ (Delta) (triple); a mosaic with 6 to indicate overlap in red, green and blue (e.g., LCOS display with field sequential color); and values 7 to 255 are typically reserved for future use.

The pixel shape field includes an 8-bit unsigned integer for illustrating the shape of each pixel consisting of a particular configuration sub-pixel, where: 0 is used to indicate that the sub-pixel shape is not defined; 1 is used to indicate a circle; 2 is used to indicate a square; 3 is used to indicate a rectangle; use 4 to indicate an oval; the ellipse is indicated using 5; and values 6 through 255 are reserved for future use to indicate the desired shape, as will be understood by those of ordinary skill in the art.

The horizontal field of view (HFOV) field is 1 byte, which contains an 8-bit unsigned integer to illustrate a horizontal field of view in 0.5 degree increments (e.g., if the HFOV is 30 degrees, then its value is 60). If its value is zero, then HFOV is not specified.

Vertical field of view (VFOV) field-1 byte, which contains an 8-bit unsigned integer to illustrate a vertical field of view in 0.5 degree increments (e.g., if VFOV is 30 degrees, its value is 60). If its value is zero, then VFOV is not assigned.

Visual axis crossing field-1 byte, which contains an 8-bit unsigned integer to illustrate a visual axis crossing in 0.01 diopter (1/m) increments (e.g., if the visual axis crossing is 2.22 meters, then its value is 45). If its value is zero, then no visual axis crossing is specified. { Note: is the specification of this parameter suitable for the range required in most applications? }

Left/right image overlap field-1 byte, which contains an 8-bit unsigned integer to illustrate the percentage of left and right image overlap. The percentage of the allowable range of image overlap is 1 to 100. The values 101 to 255 are invalid and should not be used. If its value is zero, no image overlap is specified.

The transparency (see through) field-1 byte, which contains an 8-bit unsigned integer that is used to specify the percentage of transparency of an image. The percentage of the allowable range of transparency is 0 to 100. The values 101 to 254 are invalid and should not be used. If the value is 255, the transparency percentage is not specified.

Maximum luminance field-1 byte, which contains an 8-bit unsigned integer to illustrate maximum luminance in 20 nits increments (e.g., if the maximum luminance is 100 nits, its value is 5). If its value is zero, the maximum brightness is not specified.

Optical power flag field-2 bytes, which contains a 16-bit unsigned integer, which contains various fields for specifying the optical power of the display.

Bits 15 through 5-are reserved for future use, set to zero.

Position 4-glasses focus adjustment

0-displays have no glasses focus adjustment.

1-the display has glasses focus adjustment.

Bit 3 to 2-binocular function

The 0-display is binocular and can only display 2-dimensional (2D) images.

The 1-display is binocular and can display a 3-dimensional (3D) image.

2-the display is single-purpose.

3-is reserved for future use.

Bit 1 to 0-left and right field curvature symmetry

The 0-field curvature is not defined. If this field is zero, then all field curvature values from A1 to E5 except for point C3 are set to zero, point C3 specifies the focal length of the display, or it is set to zero to indicate that the focal length is not specified.

1-the left and right displays have the same symmetry.

2-the left and right displays are mirror images of each other on the vertical axis (column C).

3-reservation for future use.

Minimum interpupillary distance (IPD) -1 byte, which contains an 8-bit unsigned integer for specifying minimum interpupillary distance in millimeters (mm). If its value is zero, then the minimum interpupillary distance is not specified.

Maximum interpupillary distance (IPD) -1 byte, which contains an 8-bit unsigned integer for specifying maximum interpupillary distance in millimeters (mm). If its value is zero, the maximum interpupillary distance is not specified.

Field of view curvature point list-a list of 25 2 byte parameters for specifying focal length in units of thousandths of diopters (1/m) over a range of 1 to 65535 (e.g., 1 is 0.001 diopters and 65535 is 65.535 diopters). The 25 elements in the field of view curvature point list are labeled A1 through E5, as follows "error! No source of reference was found. "is shown. The dots should be evenly distributed over the active area of the display. Column C corresponds to the vertical axis of the display and row 3 corresponds to the horizontal axis of the display. Columns a and E correspond to the left and right edges of the display, respectively. And rows 1 and 5 correspond to the top and bottom edges of the display, respectively. The order of the 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.

CRC-2 bytes, which contains a 16 bit CRC of all bytes of the packet including the length of the packet.

Display error reporting data packet

The display error report packet serves as a mechanism or means for allowing the client to provide a list of operational errors to the host. As a result of receiving certain commands from the host, the client may detect a variety of errors in its normal operating conditions. Examples of such errors include: a client that has been commanded to operate in a mode that it does not support may have received a packet containing parameters that are beyond the capabilities or range of the client, and may be commanded to enter a mode in an incorrect sequence. The display error report packet may be used to detect errors during normal operation, but is most useful to system designers and integrators in diagnosing problems during development and integration of host and client systems. The client should indicate its ability to send display error report packets via the parameter values 142 in the active parameter answer list of the active status answer list packets.

Display error reporting data packet

Packet length

142 type of packet

cClinet ID

Number of list entries

Error code list

CRC

2 bytes data packet length-8 bytes 2 bytes

The data packet content is as follows:

packet length-2 bytes, which contains a 16-bit unsigned integer to indicate the total number of bytes in the packet that do not include the packet length field.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 142 identifies the packet as a display error report packet.

cClient ID-2 bytes, which contains the reserved client ID. This field is reserved for future use and set to zero.

The list entry number is 2 bytes, which contains a 16-bit unsigned integer to account for the number of entries in the subsequent error code list.

Error code list-a list containing one or more error report list items. In error! No source of reference was found. The format of a single error report listing is shown.

Error reporting list item

Display error code

Error subcode

2 bytes

In one embodiment, each error report list entry is exactly 4 bytes in length, and in one embodiment, has a structure that includes: a 2-byte display error code field to specify the type of error reported, and a 2-byte error subcode field to specify more detailed details about the error defined by the display error code packet. The specific definition of each display error code is defined by the manufacturer of the client. It is not necessary to define an error sub-code for each display error code and in case an error sub-code is not defined, the value is set to zero. The specific definition of each error subcode is defined by the manufacturer of the client.

Display identification data packet

The display identification packet allows the client to return identification data in response to requesting the dedicated status packet. In one embodiment, the client uses the parameter values 144 in the valid parameter answer list of the valid status answer list packet to indicate the ability to send a display identification packet. It is useful for the host to be able to determine the manufacturer name and model number of the client device by reading this data from the client. The information may be used to determine whether the client has special capabilities that cannot be described in the display capability packet. There are presumably two ways, means, or mechanisms to read the identifying information from the client. One is by using a display capability packet that contains fields similar to those in the basic EDID structure. Another approach is to identify the packet by using a display that contains a richer set of information than similar fields in the display capability packet. It allows the host to identify manufacturers that are not assigned a 3-character EISA code and allows the serial number to contain alphanumeric characters.

Display identification data packet

Packet length

Packet type 144

cClinet ID

Week of manufacture

Year of manufacture

Manufacturer name length

Product name length

Length of serial number

2 bytes 1 bytes 2 bytes

Manufacturer name string

Product name string

Serial number character string

CRC

Manufacturer name byte length 2 bytes

The 2 byte packet type field contains a value that identifies the packet as a display identification packet. In one embodiment, this value is chosen to be 144. The cllient ID field (2 bytes) is also reserved for future use for client IDs and is typically set to zero. The CRC field (2 bytes) contains a 16-bit CRC of all the bytes in the packet, including the packet length.

The 1-byte manufacturing week field contains a value that defines the week of display manufacturing. In at least one embodiment, this value is in the range of 1 to 53 if supported by the client. If the client does not support this field, it is typically set to zero. The year of manufacture field of 1 byte contains a value that defines the year of display manufacture. This value is a deviation from 1990 as the starting point, although other reference years may be used. This field may represent a year in the range of 1991 to 2245. For example, 2003 corresponds to a year of manufacture value of 13. If the client does not support this field, it is typically set to zero.

The manufacturer name length, product name length, and sequence number length fields all contain 2 byte values that specify the length of the manufacturer name string field including any null terminator or null stuff character, the length of the product name string field including any null terminator or null stuff character, and the length of the sequence number string field including any null terminator or null stuff character, respectively.

The manufacturer name string, product name string, and serial number string fields all contain variable numbers of bytes specified by the length fields of the manufacturer name, product name, and serial number, respectively, and contain ASCII strings that are used to specify the manufacturer, product name, and display alphanumeric serial number, respectively. Each of these strings is terminated by at least one null character.

Optional (alternate) display capability packet

The optional display capability packet indicates the capabilities of the optional display attached to the MDDI client controller. The data packet is sent in response to a request for a dedicated status packet. When prompted, the client device sends an optional display capability packet for each optional display supported. The client should indicate its ability to send the optional display capability packet via the parameter value 145 in the active parameter answer list of the active status answer list packet.

It is common for an MDDI system to operate in an internal mode to have more than one display connected to an MDDI client controller. One exemplary application is a mobile phone having a larger display inside the flip and a smaller display outside. The selectable number of displays field of the display capability packet is used to report the attached one or more displays, and the selectable display capability packet reports the capability of each selectable display. The video stream packet contains 4 bits in the pixel data attribute field to access each selectable display in the client device.

Optional display capability data packet

Packet length

Data packet type 145

cClinetID

Selectable display number

Retention 1

Bit map width

Height of bitmap

Width of display window

Display window height

2 bytes 1 bytes 2 bytes

Color mapping RGB Width

RGB capability

Ability to monochrome

Retention 2

YcbCr capability

Display feature capability

Retention 3

CRC

2 bytes 1 bytes 2 bytes

The data packet content is as follows:

packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 145 identifies the packet as an optional display capability packet.

cClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

The optional display number is-1 byte, contains an 8-bit unsigned integer, and indicates the identity of the optional display with an integer in the range of 0 to 15. The first selectable display should be a number 0 and the other selectable displays should be identified by a unique selectable display number whose maximum value is the total number of selectable displays minus 1. Values greater than the total number of selectable displays minus 1 should not be used. For example: a mobile phone having a main display and a caller ID display connected to the MDDI client has an optional display so that the optional display number of the caller ID display is zero and the optional display number field of the display capability packet has a value of 1.

1-1 bytes are reserved, which contains an 8-bit unsigned integer reserved for future use. All bits in this field should be set to zero. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit word address and to align a 4-byte field with a 32-bit word address.

Bitmap width-2 bytes, which contains a 16-bit unsigned integer to illustrate the bitmap width in number of pixels.

Bitmap height-2 bytes, which contains a 16-bit unsigned integer to illustrate the bitmap height in number of pixels.

Display window width-2 bytes, which contains a 16-bit unsigned integer to illustrate the display window width in number of pixels.

Display window height-2 bytes, which contains a 16-bit unsigned integer to illustrate the display window height in terms of number of pixels.

Color map RGB width-2 bytes, which contains a 16-bit unsigned integer that specifies the number of bits of the red, green, and blue color components that can be displayed in a color map (palette) display mode. Each color component (red, green and blue) can use up to 8 bits. Even if 8 bits of each color component are transmitted in the color map packet, only the number of bits of the least significant bit of each color component defined in this field is used. This value is zero if the display client cannot use the color mapping (palette) format. The color mapping RGB width word comprises three independent unsigned values:

bits 3 through 0 define the maximum number of bits of blue in each pixel. 0 to 8 is effective.

Bits 7 to 4 define the maximum number of bits of green in each pixel. 0 to 8 is effective.

Bits 11 through 8 define the maximum number of bits of red in each pixel. 0 to 8 is effective.

Bits 15 through 12 are reserved for future use and set to zero.

RGB capability-2 bytes, which contains a 16-bit unsigned integer to specify the number of bits of resolution that can be displayed in RGB format. If the client is not able to use the RGB format, then this value is zero. The RGB capability word includes three independent unsigned values:

bits 3 to 0 define the maximum number of bits of blue (blue intensity) in each pixel.

Bits 7 to 4 define the maximum number of bits of green (green intensity) in each pixel.

Bits 11 through 8 define the maximum number of bits of red (red intensity) in each pixel.

Bits 15 through 12 are reserved for future use and set to zero.

Monochrome capability-1 byte, containing an 8-bit unsigned integer, is used to specify the number of bits of resolution that can be displayed in a monochrome format. If the client is unable to use a monochrome format, then this value is zero. Bits 7 through 4 are reserved for future use and set to zero. Bits 3 to 0 define the maximum number of bits of gray levels that can be present in each pixel. These four bits can specify that each pixel includes 1 to 15 bits. If the value is zero, the client does not support the monochrome format.

2-1 bytes are reserved, which contains an 8-bit unsigned integer reserved for future use. All bits in this field should be set to zero. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit word address and to align a 4-byte field with a 32-bit word address.

Y Cb Cr capability-2 bytes, which contains a 16-bit unsigned integer to specify the number of bits of resolution that can be displayed in the Y Cb Cr format. This value is zero if the client cannot use the Y Cb Cr format. The Y Cb Cr capability word includes three independent unsigned values:

bits 3 through 0 define the maximum number of bits used to account for Cb samples.

Bits 7 to 4 define the maximum number of bits used to specify the Cr samples.

Bits 11 through 8 define the maximum number of bits used to account for the Y samples.

Bits 15 through 12 are reserved for future use and set to zero.

Display feature capability indicator-1 byte, which contains an 8-bit unsigned integer, contains a set of flags to indicate whether a particular feature in the client is supported. A bit set to 1 indicates that the capability is supported, and a bit set to zero indicates that the capability is not supported.

Bit 0-the client can accept the video data in packet format.

Bits 1 to 7 are reserved for future use and should be set to zero.

3-1 bytes are reserved, which contains an 8-bit unsigned integer reserved for future use. All bits in this field should be set to zero. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit word address and to align a 4-byte field with a 32-bit word address.

CRC-2 bytes, which contains a 16-bit CRC of all bytes in the packet, including the packet length.

Register access packet

The register access packet provides the host or client with a means, mechanism or method for accessing the configuration and status registers of the opposite end of the MDDI link. These registers are likely to be unique to each display or device controller. These registers already exist in many displays, requiring setting of configuration, operating mode and having other beneficial and necessary settings. The register access packet allows the MDDI host or client to write to the register and request a read of the register using the MDDI link. When the host or client requests to read a register, the peer should respond by sending the register data in the same packet type and by using the read/write information field to indicate that this is data read from a particular register. The register access packet may be used to read or write to multiple registers by specifying a register count greater than 1. The client indicates the ability to support register access to the data packet using bit 22 of the display characteristic capability indicator field of the display capability data packet.

Register access packet

Packet length

146 type of packet

bClientID

Reading/writing information

Register address

Register data list

CRC

Packet length

2 bytes 4 bytes 2 bytes

-12 bytes

Register access packet

The 2-byte packet length field contains a 16-bit unsigned integer that indicates the total number of bytes in the packet that do not include the packet length field.

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 146 identifies the packet as a register access packet.

bClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs. This field is reserved for future use and set to zero.

Read/write information-2 bytes, which contains a 16-bit unsigned integer, is used to interpret this particular data packet as either a write, read, or response to a read, and provides a count of these data values.

Bits 15 to 14-read/write flag.

Bits [15:14] ═ 10 — this is a request for one or more register data addressed by the host from the register address field.

Bit [15:14] — 00 — write this packet, which contains the data to be written to the register addressed by the register address field. The data packet to be written to the designated register is in the register data field.

Bit [15:14] — 11-contains the packet containing the data requested in response to the register access packet with the read/write flag set to 10. The register address field should contain the register address corresponding to the first register data item and the register data field should contain the data read from the one or more addresses.

Bit [15:14] — 10 — this value is reserved for future use and should not be used.

Bits 13:0-14 bit unsigned integer to illustrate the number of 32-bit register data items to be transferred in the register data list field.

If bit 15 is 0 in the host send packet, bits 13:0 specify the number of register data entries contained in the register data list field that start at the register specified by the register address field and are to be written to the guest register.

If bit 15 is a 1 in a packet sent by the host, then bits 13:0 specify the number of register data items that the guest should send to the host. The register data field in the packet sent by the host should contain no entries and be zero in length.

If bit 15 is a 1 in the packet sent by the client, then bits 13:0 specify the number of register data items contained in the register data list field.

Bit 15 should not be set to 0 in a packet sent by the client. This is not a valid value.

Register address-4 bytes, containing a 32-bit unsigned integer that contains the address of the register to be written to or read from. To address registers with addresses less than 32 bits, the high order bits should be set to zero.

Register data list-a list of 4-byte register data values to be written to the client register, or values read from the client device register.

CRC-2 bytes, which contains a 16-bit CRC of all bytes in the packet, including the packet length.

Frame synchronization data packet

The frame sync packet provides the host with the ability to indicate the start of a raster image and allows the client to avoid using pixel and window addressability features in the video stream packet. This is achieved by sending a frame sync packet at the beginning of each frame of the image and then sending a video stream packet (with bit 5 set in the pixel data attribute field) for each line of image data. In one embodiment, the client uses bit 23 of the display characteristic capability indicator field of the display capability packet to indicate the capability to support the frame synchronization packet.

The format is as follows:

frame synchronization data packet

Packet length

Packet type 147

bClient ID

CRC

2 bytes

Packet type-2 bytes, which contains a 16-bit unsigned integer. The packet type 147 identifies the packet as a frame synchronization packet.

bClient ID-2 bytes, which contains a 16-bit unsigned integer reserved for client IDs.

D. Data packet CRC

The CRC field appears at the end of the packet and sometimes after certain more critical parameters in the packet, which have significantly larger data fields, increasing the likelihood of errors during transmission. In a packet with two CRC fields, the CRC generator is reinitialized after the first CRC when only one CRC is used, so the CRC calculation following the long data field is not affected by the parameters at the beginning of the packet.

In an exemplary embodiment, the polynomial used for CRC calculation is CRC-16 or X16+ X15+ X2+ X0. Fig. 36 illustrates an exemplary implementation of a CRC generator and checker 3600 that may be used to implement the present invention. In fig. 36, CRC register 3602 is initialized to a value of 0x0001 just Before transmitting the first bit of a packet input onto Tx _ MDDI _ Data _ Before _ CRC (send MDDI Data Before CRC) line, and then bytes of the packet are first shifted into the register starting with LSB. It should be noted that the number of register bits in this figure corresponds to the order of the polynomial used, rather than the position of the bits used by the MDDI. The CRC register is shifted more efficiently in one direction, which causes CRC bit 15 to appear at bit position 0 of the MDDI CRC field, CRC register bit 14 to appear at MDDI CRC field bit position 1, and so on until MDDI bit position 14 is reached.

For example, if the packet content of the display request and status packet is: 0x07, 0x46, 0x000400, 0x00 (or as a sequence of bytes: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00), and committed using the multiplexers 3604 and 3606 and the inputs of the NAND gate 3608, the final CRC output on the Tx _ MDDI _ Data _ Width _ CRC lane is 0x0eal (or as a sequence of 0xa1, 0x0 e).

When CRC generator AND checker 3600 is configured as a CRC checker, the CRC received on Rx _ MDDI _ Data (receive MDDI Data) lines is input to multiplexer 3604 AND NAND gate 3608, AND is bitwise compared to the value found in the CRC register using NOR (NOR) gate 3610, exclusive or (XOR) gate 3612, AND (AND) gate 3614. If there are any errors, as output by AND gate 3614, then the CRC is incremented once for each packet containing a CRC error by connecting the output of gate 3614 to the input of register 3602. It should be noted that the exemplary circuit shown in fig. 36 may output more than one CRC error signal within a given CHECK _ CRC _ NOW window (see fig. 37B). Thus, the CRC error counter typically only counts the first CRC error instance within each interval that CHECK _ CRC _ NOW is active. If configured as a CRC generator, the CRC is clocked out of the CRC register at a time aligned with the end of the packet.

The timing of the input and output signals and the enable signal are illustrated graphically in fig. 37A and 37B. Fig. 37A shows generation of CRC and transmission of a Data packet of Data With the state (0 or 1) of Gen _ Reset, Check _ CRC _ Now, generation _ CRC _ Now, and transmission _ MDDI _ Data (transmitting MDDI Data) signals and the state (0 or 1) of Tx _ MDDI _ Data _ Before _ CRC (transmitting MDDI Data Before CRC) and Tx _ MDDI _ Data _ With _ CRC (transmitting MDDI Data With CRC) signals. Reception of a packet of Data and Check of a CRC value are shown in fig. 37B in the states of Gen _ Reset, Check _ CRC _ Now, generation _ CRC _ Now, and Sending _ MDDI _ Data signals, and Rx _ MDDI _ Data (received MDDI Data) and CRC _ Error (CRC Error) signals.

Error code overloading of packet CRC

Whenever only data packets and CRCs of data are transferred between the host and the client, no error codes are accommodated therein. The only error is loss of synchronization. Otherwise, one must wait for the link to time out due to lack of a good data transfer path or pipeline, then reset the link and proceed. Unfortunately, this is time consuming and inefficient.

For use in one embodiment, a new technique has been developed in which the CRC portion of a data packet is used to convey error code information. This is generally shown in fig. 65. That is, one or more error codes are generated by a processor or device processing the data transfer that indicate particular predetermined errors or defects that may occur within the communication process or link. When an error is encountered, the CRC bits of the packet are used to generate and transmit the appropriate error code. That is, the CRC value is reloaded or overwritten with a required error code that can be detected at the receiving end by an error monitor or checker that monitors the CRC field value. For the case where the error code and the CRC value match for some reason, the complement of the error code is transmitted to prevent confusion.

In one embodiment, to provide a robust error warning and detection system, the error code may be transmitted several times using a series of data packets, typically all data packets, that are transmitted or sent after an error has been detected. This is done until the error-generating condition is cleared from the system, at which point the normal CRC bits are transferred without reloading with another value.

This technique of reloading the CRC value provides a very fast response to system errors when a minimum amount of extra bits or fields are used.

As shown in fig. 66, a CRC overwrite mechanism or means 6600 is illustrated with an error detector or detection module 6602, which can form part of other circuitry previously described or understood to detect the presence or absence of an error within a communication link or process. An error code generator or module 6604, which may form part of other circuitry or use techniques such as look-up tables to store preselected error messages, generates one or more error codes to indicate that a particular predetermined error or defect has occurred is detected. It will be readily appreciated that devices 6602 and 6604 may be formed as a single circuit or device, or as part of a programmed sequence of steps for other known processors and elements, as desired.

A CRC value comparator or comparison module 6606 is shown for checking whether the selected error code or codes are the same as the transmitted CRC value. If so, the complement of the error code is provided by a code complement generator or generation module or device to avoid being mistaken for the original CRC pattern (pattern) or value, thereby confusing or complicating the detection scheme. An error code selector or selection module element or device 6610 then selects the error code that is desired to be inserted or rewritten, or their respective complements, as the case may be. Error code CRC rewriter or rewrite mechanism or module 6612 is a device that receives the data stream to be inserted, the data packet, and the desired code and rewrites the corresponding or appropriate CRC value to convey the desired error code to the receiving device.

As described above, error codes may be transmitted several times using a series of data packets, so rewriter 6612 may utilize a memory element to save a copy of the code during processing or calling of such code from a previous element or other known memory location so that such memory locations may be used to store or retain their values as needed.

The general process of the rewrite mechanism implementation of FIG. 66 is shown in greater detail in FIGS. 67A and 67B. At 67A, one or more errors are detected in the communicated data or process at step 6702, and an error code is selected to indicate this condition at step 6704. At the same time, or at an appropriate point, the CRC value to be replaced is checked in step 6706 and compared to the required error code in step 6708. As discussed earlier, the result of this comparison is whether the required code or other representative value is the same as the current CRC value. If so, then processing proceeds to step 6712 where the complement or, in some cases, other representative value, is selected as the code to insert as needed. Once it is determined in steps 6710 and 6714 what error code or value will be inserted, the appropriate code is selected for insertion. For clarity, these steps are shown as separate steps, but it is usually presented as a single choice based on the decision output of step 6708. Finally, at step 6716, these appropriate values are rewritten in the CRC locations for transmission with the packet targeted by the process.

On the packet reception side, as shown in fig. 67B, the packet CRC value is monitored in step 6722. Typically, the CRC value is monitored by one or more processes within the system to determine whether an error in the data transfer has occurred, and whether to request retransmission of one or more data packets, to inhibit further operations, and so on, some of which have been discussed above. As part of such monitoring, the information may also be used to compare with known or preselected error codes or representative values to detect the presence of errors. Separate error detection procedures and monitoring may also be implemented. If such a code appears to be present, it is extracted or otherwise marked for further processing at step 6724. In step 6726 it can be determined whether this is the actual code or the complement, in which case an additional step 6728 is used to convert the value to the required code value. In either case, the final extracted code, complement or other recovery value may be used to detect which errors have occurred from the transmitted code at 6730.

V. Link restart from dormancy

When the host restarts the forward link from the sleep state, it drives MDDI _ Data into a logic 1 state for approximately 150 microseconds, then activates MDDI _ Stb, and simultaneously drives MDDI _ Data into a logic 0 state for 50 microseconds, then begins forward link communications by sending a sub-frame header packet. Thus, by providing sufficient settling time between signals, bus contention is typically allowed to resolve before a sub-frame header packet is sent.

When the client, here the display, needs Data or communications from the host, it drives the MDDI _ Data0 lines to a logic 1 state for approximately 70 microseconds, although other cycles could be used if desired, and then disables the driver by placing it in a high impedance state. This action causes the host to start or re-enable data communication on the forward link (208) and poll the state of the client. The host must detect the presence of the request pulse within 50 microseconds and then begin the startup sequence, i.e., drive MDDI _ Data0 to logic 1 state for 150 microseconds and to logic 0 state for 50 microseconds. If the display detects that MDDI _ Data0 is in the logic 1 state for more than 50 microseconds, the display should not send a service request pulse. The selected attributes relating to the tolerances of the time and time intervals for the hibernation process and the startup sequence are discussed further below.

An example of the processing steps of a typical service request event 3800 without contention is illustrated in fig. 38, wherein the events are labeled with letters A, B, C, D, E, F and G for ease of illustration. The process begins at point a when the host sends a link shutdown packet to the client device to inform it that the link is to transition to a low power sleep state. In the next step, the host enters a low power sleep state, as shown at point B, by disabling the MDDI _ Data0 driver and setting the MDDI _ Stb driver to logic 0. MDDI _ Data0 is driven to a logic 0 level through a high impedance bias network. After some period of time, the client sends a service request to the host by driving MDDI _ Data0 to a logic 1 level, as shown at point C. The host still uses a high impedance bias network to maintain (assert) a logic 0 level, but the driver in the client forces the line into a logic 1 level. Within 50 microseconds, the host recognizes this service request pulse and maintains a logic 1 on MDDI _ Data0 by enabling its driver, as shown at point D. The client then stops its effort to maintain the service request burst and places its driver in a high impedance state, as shown at point E. The host drives MDDI _ Data0 to a logic 0 level for 50 microseconds, as shown at point F, and generates MDDI _ Stb in a manner that is in a manner compatible with the logic 0 level on MDDI _ Data 0. After placing MDDI _ Data0 at logic 0 level and driving MDDI _ Stb for 50 microseconds, the host begins transmitting Data on the forward link by sending a sub-frame header packet, as shown by point G.

A similar example is illustrated in fig. 39, where a service request is maintained (alert) after a link restart sequence has been started, and the events are also marked with letters A, B, C, D, E, F and G. This represents the worst case of a request burst or signal from a client and its near corrupted sub-frame header packet. The process begins at point a when the host sends a link shutdown packet to the client device again informing it that the link will transition to a low power sleep state. In the next step, the host enters a low power sleep state, as shown at point B, by disabling the MDDI _ Data0 driver and setting the MDDI _ Stb driver to logic 0. As previously described, MDDI _ Data0 is driven to a logic 0 level by a high impedance bias network. After a period of time, the host begins the link restart sequence by driving MDDI _ Data0 to a logic 1 level for 150 microseconds, as shown at point C. After the start of the link restart sequence and before 50 microseconds has elapsed, the display also maintains MDDI _ Data0 at 1 for a duration of 70 microseconds, as shown at point D. This is because the display needs to request service from the host and does not recognize that the host has started a link restart sequence. The client then stops its effort to maintain the service request burst and places its driver in a high impedance state, as shown at point E. The host continues to drive MDDI _ Data0 to a logic 1 level. The host drives MDDI _ Data0 to a logic 0 level for 50 microseconds, as shown by point F, and generates MDDI _ Stb in a manner that is compatible with the logic 0 level on MDDI _ Data 0. After maintaining MDDI _ Data0 to a logic 0 level and driving MDDI _ Stb for 50 microseconds, the host begins transmitting Data on the forward link by sending a sub-frame header packet, as shown by point G.

From the above discussion, one can see that: as part of the wake-up sequence, previous solutions involve having the host go through two states. For the first state, the host drives the MDDI _ Data0 signal high for 150 microseconds, then drives the MDDI _ Data0 signal low for 50 microseconds, while activating the MDDI _ Stb line, and then begins transmitting MDDI Data packets. This procedure is useful to improve the state of the art in terms of the data rates achievable using MDDI apparatus and methods. However, as previously mentioned, faster speeds are always required in terms of reducing response time to conditions or enabling faster selection of the next step or process (ability to simplify processing or components).

Applicants have discovered a new and innovative approach to wake-up processing and timing, where the host uses clock cycle based timing for signal toggling (toggle). According to this structure, after the host drives the MDDI _ Data0 signal high at the beginning of the wake-up sequence, the host flips MDDI _ Stb from 0 to 10 microseconds, and does not wait until the signal is driven low. During the wake-up sequence, the host flips MDDI _ Stb as if the MDDI _ Data0 signal were always at a logic 0 level. This effectively removes the notion of time from the client side and for these cycles the host changes from the 150 microsecond and 50 microsecond cycles of the first two states to 150 clock cycles and 50 clock cycles.

The host is now responsible for driving the data line high and starts transmitting the strobe signal within 10 clock cycles as if the data line were zero. After the host has driven the data line high for 150 clock cycles, the host drives the data line low for 50 clock cycles while continuing to transmit the strobe signal. After the host has completed these processes, the host may begin transmitting the first subframe header packet.

On the client side, the client implementation can now use the generated clock to calculate the number of clock cycles that the data line is first high and then low. The number of clock cycles that need to be present on a data line driven high is 150 and the number of clock cycles on a data line driven low is 50. This means that for a correct wake-up sequence, the client should be able to count at least 150 consecutive clock cycles of the data line in the high state followed by at least 50 consecutive clock cycles of the data line in the low state. Once these two conditions are met, the client may begin searching for the unique word of the first subframe. The interrupt in this mode is used as the basis for returning the counter to the initial state, where the client again looks for the first 150 consecutive clock cycles of the data line in the high state.

As discussed earlier, the client implementation of the present invention for host-based wake-up from hibernation is very similar to the initial startup case, except that there is no mandatory clock rate starting at 1 Mbps. Instead, the clock rate may be set to recover from any previous rate at which the communication link was active when it entered hibernation. If the host begins transmitting strobe signals as described above, the client should be able to count again at least 150 consecutive clock cycles of the data line in the high state followed by at least 50 consecutive clock cycles of the data line in the low state. Once these two conditions have been met, the client can begin searching for unique words.

The client implementation of the present invention for client-based wake-up from hibernation is similar to host-based wake-up, except that it begins by having the client drive the data lines. The client may asynchronously drive the data lines without a clock to wake up the host device. Once the host recognizes that the data line is driven high by the client, it may begin its wake-up sequence. The client may count the number of host-generated clock cycles that begin or are in its wake-up process. Once the client counts out 70 consecutive clock cycles that the data line is in the high state, it may stop driving the data line high. At this point, the host should also have driven the data line to a high state. The client can then count another 80 consecutive clock cycles that the data line is in the high state to bring the clock cycle that the data line is in the high state to 150 and can therefore look for 50 clock cycles that the data line is in the low state. Once these three conditions are met, the client can begin looking for unique words.

An advantage of this new implementation of the wake-up process is that it does not require a time measurement device. Whether it be an oscillator, a capacitor discharge circuit, or other such known device, the client no longer needs such an external device to determine the start-up condition. This saves money and circuit area when implementing controllers, counters, etc. on the client device board. While not necessarily as beneficial as for the client, for the host, this technique should also simplify the host in terms of Very High Density Logic (VHDL) for the core circuitry. The power consumption when using data and strobe lines as wake-up notification and measurement sources is also very low, since there is no need to run any external circuitry for the core element to wait for a host-based wake-up.

The number of cycles or clock cycles used is exemplary and other cycles may be used as will be apparent to those of ordinary skill in the art.

An advantage of this new implementation of the wake-up process is that it does not require a time measurement device. Whether it be an oscillator, a capacitor discharge circuit, or other such known device, the client no longer needs such an external device to determine the start-up condition. This saves money and circuit area when implementing controllers, counters, etc., and thus saves area on the client device board. While not necessarily as beneficial as for the client, for the host, this technique should also simplify the host in terms of Very High Density Logic (VHDL) for the core circuitry. The power consumption when using data and strobe lines as wake-up notification and measurement sources is also very low, since no external circuitry is required for the core element to wait for a host-based wake-up.

An advantage of this new implementation of the wake-up process is that it does not require a time measurement device. Whether it be an oscillator, a capacitor discharge circuit, or other such known device, the client no longer needs such an external device to determine the start-up condition. This saves money and circuit area when implementing controllers, counters, etc. on the client device board. While not necessarily as beneficial as for the client, for the host, this technique should also simplify the host in terms of Very High Density Logic (VHDL) for the core circuitry. The power consumption when using data and strobe lines as wake-up notification and measurement sources is also very low, since there is no need to run any external circuitry for the core element to wait for a host-based wake-up.

To clarify and illustrate the operation of this new technology, the timing of the various operations with respect to the clock cycles, MDDI _ Data0, MDDI _ Stb, and MDDI _ Stb are shown in fig. 68A, 68B, and 68C.

An example of the processing steps for a typical host initiated wake up without contention is illustrated in fig. 68A, where the events are also labeled with letters A, B, C, D, E, F and G for ease of illustration. The process begins at point a when the host sends a link shutdown packet to the client device to inform it that the link is to transition to a low power sleep state. In the next step, point B, the host rolls over (toggle) MDDI _ Stb and continues to roll over for 64 cycles (as required by the system design) to allow the client's processing to complete before stopping the MDDI _ Stb roll, which stops the recovered clock in the client device. The host initially also sets MDDI _ Data0 to a logic 0 level, and then after CRC, disables MDDI _ Data0 output for 16-48 cycles (typically including output disable propagation delay). It may be desirable to place the high speed receivers of MDDI _ Data0 and MDDI _ Stb in the client into a low power state after 48 cycles after the CRC, and before the next phase (C).

The host enters the low power sleep state at point or step C by disabling MDDI _ Data0 and MDDI _ Stb drivers and placing the host controller in the low power sleep state. The MDDI _ Stb driver may also be set to a logic 0 level (using a high impedance bias network) or to continuously toggle during sleep, as desired. The client is also in a low power level sleep state.

After some period of time, the host begins the link restart sequence at point D by enabling the MDDI _ Data0 and MDDI _ Stb driver outputs. The host drives MDDI _ Data0 to a logic 1 level and MDDI _ Stb to a logic 0 level, so long as it causes the drivers to fully enable their respective outputs. After these outputs reach the required logic levels, and before driving the pulse on the MMDI _ Stb, the host typically waits around 200 nanoseconds. This allows the client time to prepare for reception.

When the host driver is enabled and MDDI _ Data0 is driven to a logic 1 level, the host begins to flip MDDI _ Stb and makes it continue to flip 150 MDDI _ Stb cycles, as shown at point E. The host drives MDDI _ Data0 to logic 0 level for 50 cycles, as shown by point F, and the client begins looking for a subframe header packet as soon as MDDI _ Data0 is at logic 0 level for 40 MDDI _ Stb cycles. The host begins transmitting data on the forward link by sending a sub-frame header packet, as shown at point G.

An example of the processing steps of a typical client initiated wake up without contention is illustrated in fig. 68B, where the events are also labeled with letters A, B, C, D, E, F, G, H and I for ease of illustration. As previously described, the process begins at point A, when the host sends a link shutdown packet to the client informing it when the link will transition to a low power state.

At point B, the host rolls over MDDI _ Stb and continues to roll over for 64 cycles (as required by the system design) in order to allow the client processing to be completed before stopping the MDDI _ Stb roll, which is used to stop the recovered clock in the client device. The host initially also sets MDDI _ Data0 to a logic 0 level and then disables MDDI _ Data0 output for 16-48 cycles (typically including output disable propagation delay) after CRC. After 48 cycles after the CRC, and before the next phase (C), the high speed receivers of MDDI _ Data0 and MDDI _ Stb in the client need to be placed in a low power state for a period of time.

The host enters the low power sleep state at point or step C by disabling MDDI _ Data0 and MDDI _ Stb drivers and placing the host controller in the low power sleep state. The MDDI _ Stb driver may also be set to a logic 0 level (using a high impedance bias network) or to continue to toggle during sleep, as desired. The client is also in a low power level sleep state.

After some period of time, the client begins the link restart sequence at point D by enabling the MDDI _ Stb receiver and enabling an offset in the MDDI _ Stb receiver to ensure that the status of the version of MDDI _ Stb received in the client is a logic 0 level before the host enables its MDDI _ Stb drive. The client may be required to enable the offset slightly ahead of enabling the receiver to ensure that a valid differential signal is received and to prevent erroneous signals, as desired. The client enables the MDDI _ Data0 driver while driving MDDI _ Data0 lines to a logic 1 level.

Within about 1 millisecond, at point E, the host recognizes the service request pulse from the client, and the host begins the link restart sequence by enabling MDDI _ Data0 and MDDI _ Stb driver outputs. The host drives MDDI _ Data0 to a logic 1 level and MDDI _ Stb to a logic 0 level, as long as the drivers are able to enable their respective outputs. After these outputs reach the required logic levels, and before driving the pulse on the MMDI _ Stb, the host typically waits around 200 nanoseconds. This allows the client time to prepare for reception.

When the host driver is enabled and MDDI _ Data0 is driven to a logic 1 level, the host outputs a pulse on MDDI _ Stb and lasts 150 MDDI _ Stb cycle periods, as shown at point F. When the client recognizes the first pulse on the MDDI _ Stb, it disables the offset in its MDDI _ Stb receiver. The client continues to drive MDDI _ Data0 to a logic 1 level for 70 MDDI _ Stb cycles, and disables its MDDI _ Data0 driver at point G.

As shown at points G and H, the host drives MDDI _ Data0 to logic 0 level for 50 cycles, and the client starts looking for sub-frame header packets after MDDI _ Data0 is at logic 0 level for 40 MDDI _ Stb cycles. The host begins transmitting data on the forward link by sending a sub-frame header packet, as shown at point I.

An example of processing steps for a typical host initiated wake up with contention from the client, i.e., the client also wants to wake up the link, is illustrated in fig. 68C. For ease of illustration, the letters A, B, C, D, E, F, G, H and I are also used to mark the event. As previously described, the process begins at point a, when the host sends a link shutdown packet to the client device to inform the client that the link is to transition to a low power state, then proceeds to point B, where the MDDI _ Stb is flipped and flipped for approximately 64 cycles (or as required by the system design) to allow the processing performed by the client to complete, then proceeds to point C, when the host enters a low power sleep state by disabling the MDDI _ Data0 and MDDI _ Stb drivers and placing the host controller in a low power sleep state. After some period of time, the host begins the link restart sequence at point D by enabling MDDI _ Data0 and MDDI _ Stb driver outputs, and begins flipping MDDI _ Stb and continuing to flip it for 150 MDDI _ Stb cycles, as shown at point E.

At a maximum of 70 MDDI _ Stb cycles after point E, here point F, the client has not realized that the host is driving MDDI _ Data0 to a logic 1 level, so the client also drives MDDI _ Data0 to a logic 1 level. This occurs because the client has already needed to request service, but is unaware that the host with which it is attempting to communicate has begun the link restart sequence. At point G, the client stops driving MDDI _ Data0 and places its driver in a high impedance state by disabling its output. The host continues to drive MDDI _ Data0 to a logic 1 level and for 80 additional cycles.

The host drives MDDI _ Data0 to a logic 0 level for 50 cycles, as shown by point H, and the guest begins looking for a subframe header packet after MDDI _ Data0 is at a logic 0 level for 40 MDDI _ Stb cycles. The host begins transmitting data on the forward link by sending a sub-frame header packet, as shown at point I.

VI electrical specification of interface

In one exemplary embodiment, DATA in a non-return-to-zero (NRZ) format is encoded using a DATA strobe signal or DATA-STB format, which allows clock information to be embedded in the DATA and strobe signals. The clock can be recovered without a complex phase locked loop. Data is carried by a bi-directional differential link, which is typically implemented using wire line cables, although other wires, printed wiring, or transmission elements may be used as previously described. The strobe Signal (STB) is carried over a unidirectional link that is driven only by the host. Whenever there is a back-to-back (back-to-back) state, 0 or 1, the strobe signal toggles the value (0 or 1), which remains the same on the data line or signal.

An example of how a DATA sequence such as bit "1110001011" may be transmitted using DATA-STB (DATA-strobe) encoding is shown in graphical form in fig. 40. In fig. 40, the DATA signal 4002 is shown on the top row of the signal timing diagram, and the STB (strobe) signal 4004 is shown on the second row, aligned each time according to the appropriate need (common starting point). Over time, when the state appearing on the DATA line 4002 (signal) changes, then the STB line 4004 (signal) remains in the previous state, so that the first '1' state of the DATA signal correlates to the first '0' state of the STB signal, i.e., its starting value. However, if the state, level of the DATA signal does not change, then the STB signal flips to the opposite state, i.e., the '1' state in this example, as would be the case if DATA provided yet another '1' value in FIG. 40. That is, there is one and only one transition between DATA and STB per bit period. Thus, when the DATA signal remains at '1', the STB signal transitions again, this time to '0', and when the level of the DATA signal changes to '0', this level is maintained. When the DATA signal remains at '1', the STB signal flips to the opposite state, i.e., '1' in the present example, and the STB signal remains or transitions as the DATA signal changes or remains at a level or value.

Upon receipt of these signals, an exclusive OR (XOR) operation is performed on the DATA and STB signals to generate clock signal 4006, which is shown at the bottom of the timing diagram for comparison with the desired DATA and strobe signals. An example of a circuit that may be used to generate DATA and STB outputs or signals from input DATA at the host and then recover or retrieve DATA from the DATA and STB signals at the client is shown in fig. 41.

In fig. 41, a transmitting part 4100 is used to generate and transmit the original DATA and STB signals via an intermediate signal path 4102, while a receiving part 4120 is used to receive the signals and recover the DATA. As shown in fig. 41, to transfer DATA from the host to the client, the DATA signal is input to two D-type flip-flop circuit elements 4104 and 4106, and a clock signal is input to flip the circuits. The two trigger circuit outputs (Q) are then divided into differential pairs of signals MDDI _ Data0+, MDDI _ Data0-, and MDDI _ Stb +, MDDI _ Stb-, respectively, using two differential line drivers 4108 and 4110 (voltage mode). A three input exclusive nor (XNOR) gate, circuit or logic element 4112 is connected to receive DATA and the outputs of the two flip-flops and generates an output for providing a DATA input to a second flip-flop which in turn generates the MDDI _ Stb +, MDDI _ Stb-signal. For convenience, an inverting bubble is drawn on the XNOR gate to indicate that it effectively inverts the Q output of the flip-flop that generates the strobe signal.

In the receive section 4120 of fig. 41, the MDDI _ Data0+, MDDI _ Data0-, and MDDI _ Stb +, MDDI _ Stb-signals are received by each of two differential line receivers 4122 and 4124, which generate single-ended outputs from the differential signals. The output of the amplifier is then input to each input of a two-input exclusive or (XOR) gate, circuit or logic element 4126, which logic element 4126 is used to generate a clock signal. The clock signal is used to trigger each of two D-type flip-flop circuits 4128 and 4130 for receiving a delayed version of the DATA signal through a delay element 4132, one (4128) of the D-type flip-flops generating a DATA '0' value and the other (4130) generating a DATA '1' value. The clock also has a separate output from the XOR logic. Since clock information is distributed to the DATA and STB lines, none of the signal transitions between states is faster than half the clock rate. Since the clock is reproduced using exclusive-or processing of the DATA and STB signals, the system is practically tolerant of twice the amount of skew between the input DATA and the clock, as compared to the case where the clock signal is sent directly via a single dedicated DATA line.

The MDDI data operates in a differential mode on the MDDI _ Stb + and MDDI _ Stb-signals to maximize immunity from the negative effects of noise. Each section of the differential signal path is source terminated with a termination resistance that is half the characteristic impedance of the cable or wire used to carry the signal. The MDDI data pair is source terminated at both the host and the client. Since only one of the two drivers is active at a given time, there is always a termination resistance at the source end of the transmit link. The MDDI _ Stb + and MDDI _ Stb-signals are driven only by the host.

An exemplary configuration of the elements that may be used to implement the drivers, receivers and termination resistors that convey signals as part of the MDD interface of the present invention is shown in fig. 42, while the corresponding DC electrical characteristics of MDDI _ Data and MDDI _ Stb are shown in table VII. This exemplary interface uses low voltage detection, here 200mV, with a voltage swing less than 1 volt and low power consumption.

TABLE VII

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						Rterm	Serial terminal resistor	41.3	42.2	43.0	Ohm meter
Rhibernate	Sleep state bias termination resistor	8	10	12	Kilo ohm
						Vhibernate	Open circuit voltage in sleep state	0.5		2.8	A device
VOutput-Range	Allowable driver output voltage range with respect to GND	0		2.8	A device
						VOD+	Driver differential output high voltage	0.5			A device
VOD-	Driver differential output low voltage			-0.5	A device
						VIT+	Receiver differential input high threshold voltage			10	Millivolt
VIT-	Receiver differential input low threshold voltage	-10			Millivolt
						VInput-Range	Allowable receiver input voltage range with respect to GND	0		3.0	A device
Iin	Input leakage current (other than sleep bias)	-25		25	Microamperes

The electrical parameters and characteristics of the differential line driver and line receiver are described in table VIII. Functionally, the driver passes the logic level on the input directly to the positive output and the inverse of the input directly to the negative output. The delay from input to output is substantially matched to the differential lines of the differential drive. In most implementations, the voltage swing on the output is smaller than the swing on the input in order to minimize power consumption and electromagnetic emissions. Table VIII gives the minimum voltage swing around 0.5V. However, it is well known to those skilled in the art that other values may also be used, and in some embodiments, the inventors contemplate smaller values, depending on design constraints.

The differential line receiver has the same characteristics as the high-speed voltage comparator. In FIG. 41, the input without bubbles is the positive input, and the input with bubbles is the negative input. If (V) _{Input device}+)-(V_{Input device}-) is greater than 0, then the output is a logic 1. Another way to describe this is to have a very large (virtually infinite) gain, differential amplifier with the output clamped at logic 0 and 1 voltage levelsAnd an amplifier.

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

In fig. 42, host controller 4202 and client or display controller 4204 communicate data packets via communication link 4206. The host controller employs a series of three drivers 4210, 4212 and 4214 to receive the host DATA and STB signals to be transmitted and to receive the client DATA signal to be transmitted. The driver responsible for host DATA transfer employs an enable signal input to allow activation of the communication link only when transfer from the host to the client is required. Since the STB signal is formed as part of the data transfer, no additional enable signal is employed for this driver (4212). The output of each of the DATA and STB drivers is connected to a termination impedance or resistor 4216a, 4216b, 4216c, and 4216d, respectively.

Termination resistors 4216a and 4216b will also serve as impedances at the input of client-side receiver 4220 for STB signal processing, while additional termination resistors 4216e and 4216f are provided in series with resistors 4216c and 4216d, respectively, at the input of client data processing receiver 4222. A sixth driver 4226 in the client controller is used to prepare data signals for transmission from the client to the host, where the driver 4214 processes the data through termination resistors 4216c and 4216d on the input side for transmission to the host for processing.

As part of the sleep control discussed elsewhere, two further resistors 4218a and 4218b are placed between the termination resistor and ground and the voltage source 4220, respectively. The voltage source is used to drive the transmission line to the high or low level previously discussed in order to manage the data stream.

The above-described drivers and impedances may be formed as discrete components or as part of a circuit module, or as an Application Specific Integrated Circuit (ASIC) that acts as a more cost effective encoder or decoder solution.

It can be easily seen that: power is transferred from the host device to the client device or display via a pair of wires using signals labeled MDDI _ Pwr and MDDI _ Gnd. The MDDI _ Gnd portion of the signal serves as the reference ground and power return path or signal for the display device. The MDDI _ Pwr signal serves as a power supply for the display device, which in an exemplary configuration is driven by the host device for low power applications, which is allowed to use up to 500 mA. The MDDI _ Pwr signal may be provided from a portable power source, such as, but not limited to, a lithium ion type battery or battery pack resident at the host device, and may range from 3.2 to 4.3 volts with respect to MDDI _ Gnd.

Timing characteristics

A. Overview

FIG. 43 illustrates the steps and signal levels employed by a client to secure services from a host, and the steps and signal levels employed by a host to provide such services. In fig. 43, the first portion of signals are shown illustrating a link shutdown packet transmitted from the host and then driving the data lines to a logic 0 state using a high impedance bias circuit. At this point, the client display, or host, whose driver has been disabled, does not transfer data. Since MDDI _ Stb is active during the link down data packet, a series of strobes of the MDDI _ Stb signal line can be seen at the bottom. When the host drives the bias circuit and logic to zero, the MDDI _ Stb signal line also goes to a logic 0 level once this packet ends and the logic level goes to 0. This situation represents the last signal transmitted from the host or the end of service from the host, and this may occur at any time in the past, and this is included to show the state of the signal before the service was previously suspended and before the service started. If desired, for example, only signals may be sent to reset the communication link to the appropriate state without a 'known' prior communication by this host device.

As shown in fig. 43, the logic level of the signal output from the client is initially set to zero. In other words, the client output is at a high impedance and the driver is disabled. When service is requested, the client enables its driver and sends a service request to the host, which is a period of time denoted "tservice" during which the line is driven to a logic 1 level. Then, before the host detects the request, a certain amount of time, denoted as "thost-detect", elapses or may be required, after which the host responds with a link initiation sequence by driving the signal to a logic 1 level. At this point, the client no longer maintains (de-assert) the request and the service request driver is disabled, so the output line from the client also goes to a 0 logic level. At this time, the MDDI _ Stb signal is at a logic 0 level.

The host drives the host data output to '1' level during a period called 'trestart-high', after which the host drives the logic level to zero and activates MDDI _ Stb and holds for a period called 'trestart-low', after which the first forward traffic starts with a sub-frame header packet and then transmits the forward traffic packet. The MDDI _ Stb signal is active during the trestart-low period and during subsequent subframe header packets.

Table VIII shows typical times for the various cycle lengths described above and exemplary minimum and maximum data rates relationships, where:

TABLE VIII

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						tservice	Display service request burst period	60	70	80	Microsecond range
trestart-high	High pulse period for host link restart	140	150	160	Microsecond range
						trestart-low	Host link restart low pulse period	40	50	60	Microsecond range
tdisplay-detect	Display detects time of link restart sequence	1		50	Microsecond range
						thost-detect	Host detects time of service request pulse	1		50	Microsecond range
1/tbit-min-perf	Link data rate for minimum performance devices	0.001		1	Mbps
						1/tbit-max-perf	Maximum link data rate range of a device	0.001		450	Mbps
	Reverse link data rate	0.0005		50	Mbps
						tbit	One period of forward link data bits	2.2		106	Nanosecond

Those skilled in the art will readily appreciate that the function of the individual elements illustrated in fig. 41 and 42 are well known, and the function of the elements in fig. 42 is confirmed by the timing diagram in fig. 43. The details of the series connection of termination and sleep resistors shown in fig. 42 are omitted from fig. 41 because the information is not necessary to describe how data-strobe encoding is performed and from which the clock is recovered.

B. Data-strobe sequential forward link

The switching characteristics for transferring data from the host driver output on the forward link are shown in table IX. Table IX gives the minimum and maximum values required against the typical times at which certain signal transitions occur in tabular form. For example, a typical duration for a transition to occur from the beginning to the end of a Data value (' 0 ' or ' 1 ' output) (' ttdd- (host-output) Data0 to Data0 transition) is ttbit, with a minimum time of about ttbit-0.5 ns and a maximum time of about ttbit +0.5 ns. The relative spacing between transitions on Data0, other Data lines (DataX), and the gated lines (Stb) is illustrated in fig. 44, which shows the transitions of Data0 to gated, gated to Data0, Data0 to non-Data 0, non-Data 0 to non-Data 0, non-Data 0 to gated, and gated to non-Data 0, referred to as ttds- (host-output), ttss- (host-output), ttsd- (host-output), ttdddx- (host-output), and ttsdx- (host-output), respectively.

TABLE IX

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						ttdd-(host-output)	Data0 to Data0 transition	ttbit-0.5	ttbit	ttbit+0.5	Nanosecond
ttds-(host-output)	Data0 to strobe transition	ttbit-0.8	ttbit	ttbit+0.8	Nanosecond
						ttss-(host-output)	Strobe-to-strobe transition	ttbit-0.5	ttbit	ttbit+0.5	Nanosecond
ttsd-(host-output)	Strobe to Data0 transition	ttbit-0.8	ttbit	ttbit+0.8	Nanosecond
						ttddx-(host-output)	Data0 to non-Data 0 transition		ttbit		Nanosecond
ttdxdx-(host-output)	non-Data 0 to non-Data 0 transition	ttbit-0.5	ttbit	ttbit+0.5	Nanosecond
						ttdxs-(host-output)	non-Data 0 to strobe transition		ttbit		Nanosecond
ttsdx-(bost-output)	Gated to non-Data 0 transition		ttbit		Nanosecond

Typical MDDI timing requirements for client receiver inputs carrying the same signal on the forward link are shown in table X. Since the same signals are discussed except for the time delays, no new figures are needed to illustrate the signal characteristics or meanings of the various labels, as will be understood by those skilled in the art.

Table X

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						ttdd-(display-input)	Data0 to Data0 transition	ttbit-1.0	ttbit	ttbit+1.0	Nanosecond
ttds-(display-input)	Data0 to strobe transition	ttbit-1.5	ttbit	ttbit+1.5	Nanosecond
						ttss-(display-input)	Strobe-to-strobe transition	ttbit-1.0	ttbit	ttbit+1.0	Nanosecond
ttsd-(display-input)	Strobe to Data0 transition	ttbit-1.5	ttbit	ttbit+1.5	Nanosecond
						ttddx-(host-output)	Data0 to non-Data 0 transition		ttbit		Nanosecond
ttdxdx-(host-output)	non-Data 0 to non-Data 0 transition		ttbit		Nanosecond
						ttdxs-(host-output)	non-Data 0 to strobe transition		ttbit		Nanosecond
ttsdx-(host-output)	Gated to non-Data 0 transition		ttbit		Nanosecond

Fig. 45 and 46 illustrate the delay that exists in response when the host disables or enables the master drive, respectively. In the case where the host forwards certain packets, such as reverse link encapsulated packets or round trip delay measurement packets, the host disables the line driver after the required packets, such as the transmitted parameter CRC, strobe alignment, and all zero packets illustrated in fig. 45, are forwarded. However, as shown in fig. 45, the state of the line does not necessarily switch instantaneously from '0' to the required high value, although this can be achieved with some existing control or circuit elements, but rather responds over a period of time known as the host driver disable delay period. Although this switching can in fact be done immediately, so that this period is 0 ns in length, it can also easily extend over a longer period, i.e. 10 ns which is the maximum period length required, during guard time 1 or turnaround 1 packet period.

Referring to fig. 46, one sees a change in signal level when the host driver is enabled to transmit packets such as reverse link encapsulated packets or round trip delay measurement packets. Here, after guard time 2 or turnaround 2 packet period, the host driver is enabled and begins driving level (here '0') approaching or reaching this value for a period of time called the host driver enable delay period, which is performed during the driver re-enable period before the first packet is sent.

A similar process occurs for driver and signaling for client devices, here displays. Below, general criteria for the lengths of these periods and their respective relationships are shown in table XI.

TABLE XI

Description of the invention	Minimum value	Maximum value	Unit of
				Host driver disable delay	0	10	Nanosecond
Host driver enable delay	0	2.0	Nanosecond
				Display driver disable delay	0	10	Nanosecond
Display driver enable delay	0	2.0	Nanosecond

C. Data-gated time sequential reverse link

The switching characteristics and timing relationships of the data and strobe signals used to transfer data from the client driver output on the reverse link are shown in fig. 47 and 48. Typical times for some signal transitions are discussed below. FIG. 47 illustrates the relationship between the timing at which data is being transferred and the leading and trailing edges of a strobe at the host receiver input. I.e. the setup time t called the rising edge and the leading edge of the strobe signal_su-srAnd a setup time t called the trailing or falling edge of the strobe signal_su-sf. Typical durations of these build periods are at least on the order of about 8 nanoseconds.

Fig. 48 illustrates the switching characteristics and corresponding client output delays presented by the reverse data timing. In fig. 48, one can see the relationship between the timing of the data being transferred and the leading and trailing edges of the strobe to illustrate the cause of the delay. I.e. the propagation delay t between the rising or leading edge of the strobe signal and the data (valid) _pd-srAnd a propagation delay t between trailing or falling edges, called data and strobe signals_pd-sf. Typical maximum time lengths of these propagation delay periods are on the order of about 8 nanoseconds.

Implementation of link control (link controller operation)

A. State machine packet processor

Data packets transmitted over an MDDI link are typically delivered very quickly at a rate of about 300Mbps or more, such as 400Mbps, although lower rates can certainly be supported when needed. The speed of this type of bus or transfer link is too high to control for currently available general purpose microprocessors and the like. A practical implementation for implementing this type of signalling therefore consists in parsing the incoming packet stream with a programmable state machine in order to produce packets that are transmitted or redirected to the appropriate audio-video subsystem to which they should go. Such devices are well known and use circuitry that is typically dedicated to a limited number of operations, functions or states in order to achieve the desired high speed or ultra high speed operation.

A general purpose controller, processor, or processing element may be used to more appropriately act on or manipulate certain information having lower speed requirements, such as control or status packets. Upon receipt of those packets (control, status or other predefined packets), the state machine should have them passed to the general purpose processor via a data buffer or similar processing element so that the packets can be manipulated to provide the desired result (effect) while the audio and visual packets are being transferred to their appropriate destinations for action. The states or state machines discussed below may also be implemented using software control of such devices, typically as programs stored on memory elements or media, if microprocessors or other general purpose controllers, processors or processing elements capable of higher data rate processing capabilities are manufactured in the future.

In some embodiments, the general processor functions may be implemented using processing power or excess cycles available from a microprocessor (CPU) or controller in a computer application, a processor, a Digital Signal Processor (DSP), an application specific circuit, or an ASIC found in a wireless device in a manner very similar to some modems or image processors using the processing power of a CPU found in a computer to perform some functions and to reduce the complexity and cost of hardware. However, such sharing or use of cycles can negatively impact processing speed, timing, or overall operation of such elements, and thus in many applications dedicated circuits or elements are more suitable for such general purpose processing.

In order to be able to view image data on a display (microdisplay) or to reliably receive all data packets sent by a host device, the display signal processing is synchronized with the forward link channel timing. That is, the signals arriving at the display and display circuitry are substantially synchronized in time for proper signal processing. A high-level diagram of the signal processing steps or states of a method implementation in which such synchronization may be implemented is illustrated in fig. 49. In fig. 49, it is shown that the possible forward link synchronization "states" for the state machine 4900 are classified into one "asynchronous frame state" 4904, two "get synchronization states" 4902 and 4906, and three "in-synchronization states" 4908, 4910 and 4912.

As shown in a start step or state 4902, a display or client, such as a rendering device, starts in a preselected "no sync" state and searches for a unique word in the detected first sub-frame header packet. It should be noted that this unsynchronized state represents a minimum communication setting or "fall-back" setting when selecting a type I interface. When the unique word is found during the search, the display saves the subframe length field. The CRC bits are not checked while processing this first frame or until synchronization is achieved. If this sub-frame length is zero, then the synchronization state processing therefore continues to state 4904, here labeled "asynchronous frame" (async frame) state, which indicates that synchronization has not been achieved. In fig. 49, this step is labeled as having cond 3, or condition 3, in the process. Additionally, if the frame length is greater than zero, then the synchronization state processing proceeds to state 4906 where the interface state is set to "one synchronization frame found". In fig. 49, this step in the process is labeled as having cond 5, or condition 5. Additionally, if the state machine sees a frame header packet and determines that it has a good CRC for frames with a frame length greater than zero, then the process proceeds to the "find a sync frame" state. In fig. 49, it is marked as conformant to cond 6, or condition 6.

In each case where the system is in a state other than "out of sync", the interface state changes to "in sync" state 4908 when the unique word is detected, it is determined that the subframe header packet has a good CRC result, and the subframe length is greater than zero. In fig. 49, this step in the process is marked as cond 1, or condition 1, being satisfied. On the other hand, if the unique word or CRC in the sub-frame header packet is not correct, then the synchronization state processing continues or returns to the interface state 4902 of the "non-synchronous frame" state. In the state diagram of fig. 49, this part of the process is marked as conformant 2, or condition 2.

B. Synchronizing acquisition time

The interface may be configured to allow a certain number of "synchronization errors" before deciding to lose synchronization and return to the "unsynchronized frame" state. In FIG. 49, once the state machine has reached the "in sync state" and no errors are found, it will continuously encounter the result of cond 1 and remain in the "in sync" state. However, once a cond 2 result is detected, the process changes the state to a "one-sync-error" state 4910. At this point, if the process detects the result of yet another cond 1, then the state machine returns to the "in sync" state, otherwise it encounters the result of yet another cond 2 and transitions to the "two sync error" state 4912. Further, if cond 1 occurs, processing returns the state machine to the "in-sync" state. Otherwise, a further cond 2 is encountered and the state machine returns to the "unsynchronized" state. It will also be appreciated that if the interface encounters a "link down packet", this will cause the link to terminate the data transfer and return to the "unsynchronized frame" state, as if nothing can be synchronized with it, which in the state diagram shown in fig. 49 is referred to as cond 4 compliant.

It should be understood that there may be a duplicate "false copy" (false) of the unique word, which may occur at some fixed location within the subframe. In those cases, it is extremely unlikely that the state machine will synchronize to this subframe, since the CRC on the subframe header packet must also be valid in order for the MDD processing to go to the "in sync" state when processing is done.

The subframe length in the subframe header packet may be set to zero to indicate that the host transmits only one subframe before the link is down and the MDD interface is set or configured to the idle sleep state. In this case, the display must receive the data packet via the forward link immediately after detecting the sub-frame header data packet because only one sub-frame is sent before the link transitions to the idle state. In normal or typical operation, the sub-frame length is non-zero and the display only processes forward link packets, while the interface is in those states shown collectively as the "in sync" state in fig. 49.

The time required for the display to synchronize to the forward link signal varies with the subframe size and the forward link data rate. When the sub-frame size is larger, there is a greater likelihood that a "false copy" of the unique word that is part of the random data or more is detected in the forward link. Also, when the forward link data rate is slower, the ability to recover from error detection is lower, and the time it takes to perform this operation is longer.

C. Initialization

As previously described, at "start-up," the host configures the forward link to operate at or just below the minimum required or required data rate of 1Mbps, and configures the subframe length and media frame rate as appropriate for a given application. That is, both the forward and reverse links begin to operate using the type I interface. These parameters are typically only temporarily used when the host determines the capabilities or desired configuration of the client display (or other type of client device). The host sends or transmits a sub-frame header packet via the forward link followed by a reverse link encapsulation packet, setting bit '0' of the request flag to a value of one (1) in order to request the display or client to respond with a display capability packet. Once the display is synchronized on (or with) the forward link, it sends display capability packets and display request and status packets via the reverse link or channel.

The host examines the contents of the display capability packet to determine how to reconfigure the link for optimum consideration or desired level of performance. The host checks the protocol version and minimum protocol version fields to confirm that the host and display use protocol versions that are compatible with each other. The protocol version is typically the first two parameters of a display capability packet, so compatibility can be determined even if other elements of the protocol are not compatible or cannot be fully understood as compatible.

CRC processing

The packet processor state machine ensures that the CRC checker is properly or correctly controlled for all packet types. When a CRC comparison is detected that produces one or more errors, a CRC error counter is also incremented and reset at the beginning of each subframe being processed.

E. Optional out-of-sync verification

While the above series of steps or states can produce higher data rates or throughput speeds, applicants have discovered that: even higher data rates or throughput may also be effectively achieved using other alternative settings or changes in conditions that the client uses to declare loss of synchronization with the host. The new embodiment of the invention has the same basic structure but the conditions for changing states are changed. In addition, a new counter is implemented to facilitate subframe synchronization checks. These steps and conditions are presented with respect to fig. 63, which illustrates a series of states and conditions for establishing the operation of a method or state machine. For clarity, only the "get synchronization status" and "in synchronization status" portions are shown. In addition, since the resulting states are substantially identical to the state machine itself, they are given the same reference numerals. However, the conditions that change state (and state machine operation) change somewhat, so for clarity of both figures, all are renumbered (1, 2, 3, 4, 5 and 6 versus 61, 62, 63, 64, and 65) to facilitate identification of the differences. Since the asynchronous frame state is not considered in this discussion, there is a state (4904) and condition (6) that is not used in this figure.

In fig. 63, the system or client (for display or presentation) starts with state machine 5000 in a preselected "unsynchronized" state 4902, just as in fig. 49. The first state change to change state from the unsynchronized condition 4902 is made under condition 64 where the synchronized mode is found. Assuming that the CRC of the sub-frame header is also passed on this packet (conditional 61 is met), the state of the packet processor state machine may change to in-sync state 4908. A synchronization error, condition 62, will cause the state machine to switch to state 4910 and to state 4912 when this condition occurs a second time. However, it has been found that any CRC failure of an MDDI packet will cause the state machine to move out of the in-sync state 4908 and into a sync error state 4910. Yet another CRC failure of any MDDI packet results in a move to two synchronization failure states 4912. A packet decoded with the correct CRC value will cause the state machine to return to the in-sync state 4908.

Where a change has occurred is the use of a CRC value or CRC determination for 'per' data packet. That is, instead of just observing the sub-frame header packet, the state machine is made to look at (look at) the CRC value of each packet to determine loss of synchronization. In this structure or process, loss of synchronization is determined not using a unique word and only using a subframe header CRC value.

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

To make such a system more robust, the client should also add or utilize a subframe counter. The client then checks for the presence of the unique word when the unique word is expected to arrive or appear in the signal. If the unique word does not occur at the correct time, the client can more quickly realize that a synchronization failure has occurred, much faster than it would have to wait for a few (here three) packets of time or period, and where the packets are much larger than the sub-frame length. If the test on the unique word indicates that it is not present, in other words, the timing is incorrect, the client immediately declares that the link is out of sync and moves to an out of sync state. The process of checking for the presence of the correct unique word adds a condition 65(cond 65) to the state machine that the unique word is incorrect. If a sub-frame packet is expected to be received on the client but not matched, the client may immediately enter the unsynchronized state 4902, thereby saving additional time waiting for multiple synchronization errors (condition 62), which are typically encountered via states 4910 and 4912.

This change uses an additional counter or a counting function in the client core to count the subframe length. In one embodiment, a countdown function is used, and if the counter expires, the transmission of any data packet currently being processed is interrupted in order to check the subframe unique word. Alternatively, the counter may increment a count, compare the count to a maximum or specific required value, and check the current packet at the time corresponding to this value. This procedure protects the client from decoding extra long packets of data that are received incorrectly on the client. If the sub-frame length counter needs to interrupt some other data packet being decoded, it can be determined that synchronization has been lost since the data packet should not cross a sub-frame boundary.

IX. packet handling

For each type of packet received by the state machine, it performs a specific processing step or series of steps to implement the operation of the interface. The forward link packets are generally processed in accordance with the exemplary process set forth in table XII below.

TABLE XII

Type of data packet	Packet processor state machine response
		Sub-frame header (SH)	The good packet is acknowledged, the subframe length field is obtained and the packet parameters are sent to the general purpose processor.
Filler character (F)	The data is ignored.
		Video Streaming (VS)	Interpreting the video data format descriptors and other parameters, unpacking the packed pixel data if necessary, transforming the pixels by color mapping if necessary, and writing the pixel data into the appropriate location in the bitmap.

Type of data packet	Packet processor state machine response
		Audio Stream (AS)	Sending audio sample rate settings to an audio sample clock generator, distinguishing audio samples of a specified size, unpacking audio sample data if necessary, and routing audio samples to an appropriate audio sample FIFO
Color Mapping (CM)	The color map size and offset parameters are read and the color map data is written to a color map memory or storage location.
		Reverse link encapsulation (REL)	Facilitating the transmission of data packets in reverse at the appropriate time. The reverse link flag is checked and a display capability packet is sent when needed. Display request and status packets are also sent, as appropriate.
Display Capability (DC)	This type of packet is sent when requested by the host using the reverse link flag field of the reverse link encapsulated packet.
		Keyboard (K)	These packets, if present and needed for use, are passed to and received from a general purpose processor in communication with the keyboard type device.
Indicating equipment (PD)	If present and needed for use, the data packets are passed to and received from a general purpose processor in communication with the indicated type device.
		Link closing (LS)	The fact that the link is closed is recorded and the general purpose processor is notified.
Display Service Request and Status (DSRS)	This packet is sent as the first packet in the reverse link encapsulated packet.
		Bit block transfer (BPT)	Interpreting data packet parameters, such as video data format descriptors, determining which pixels move first, and moving the pixels in the bitmap as needed.
Bitmap Area Filling (BAF)	Interpreting the packet parameters, transforming the pixels by color mapping if necessary, and writing the pixel data in the appropriate location in the bitmap,
		bitmap Pattern Fill (BPF)	Interpreting the packet parameters, unpacking the packed pixel data if necessary, transforming the pixels by color mapping if necessary, and writing the pixel data into the appropriate location in the bitmap.
Communication Link Channel (CLC)	This data is sent directly to the general purpose processor.
		Display service request During Sleep (DSR)	The general purpose processor controls the low level functions that send the request and detects contention for a link restart on its own.
Interface type switch request (ITHR) and Interface Type Acknowledgement (ITA)	These packets may be passed to and received from a general purpose processor. The logic for receiving this type of packet and composing a response with an acknowledgement is substantially minimal. Thus, this operation may also be implemented within the packet processor state machine. The resulting switch exists as a low level physical layer action and is unlikely to affect the functionality of the general purpose processor.
		Execution type switching (PTH)	It may be done directly on such a packet or by passing such a packet to a general purpose processor and instructing the hardware to perform a mode change.

X. reducing reverse link data rate

The inventors have observed that: it is highly desirable that certain parameters for the host link controller be adjusted or configured in a particular manner to achieve maximum or more optimal (scaled) reverse link data rates. For example, during the reverse data packet field used to convey the reverse link encapsulation packet, the MDDI _ Stb signal pair is flipped (toggle) to generate a periodic data clock at half the forward link data rate. This occurs because the host link controller generates an MDDI _ Stb signal corresponding to the MDDI _ Data0 signal as if MDDI _ Data0 were sending all zeros. The MDDI _ Stb signal is transmitted from the host to the client where it is used to generate a clock signal to transmit reverse link data from the display, whereby the reverse data is sent back to the host. The typical amount of delay encountered in signaling and processing on the forward and reverse paths in a system employing MDDI is shown in fig. 50. In FIG. 50, a series of delay values are shown in the processing portion near the Stb +/-generation, cable to display, display receiver, clock generation, signal clock, Data0 +/-generation, cable to host and host receiver stages, respectively, namely: 1.5 nanoseconds, 8.0 nanoseconds, 2.5 nanoseconds, 2.0 nanoseconds, 1.0 nanoseconds, 1.5 nanoseconds, 8.0 nanoseconds, and 2.5 nanoseconds.

Depending on the forward link data rate and the signal processing delays encountered, more than one cycle on the MDDI _ Stb signal is required for a "round trip" effect or set of events to be completed, resulting in an undesirable consumption of time or amount of cycles. To prevent this problem, the reverse rate divisor allows a bit time on the reverse link to span multiple cycles of the MDDI _ Stb signal. This means that the reverse link data rate is less than the forward link rate.

It should be noted that the actual length of signal delay through the interface will vary with each particular host-client system or hardware used. Although not required, each system may generally perform better by using round trip delay measurement packets to measure the actual delay in the system, thereby setting the reverse rate divisor to an optimal value.

The round trip delay is measured by having the host send a round trip delay measurement packet to the display. The display responds to the packet by sending a 1 sequence back to the host within a preselected measurement window or period in the packet called the measurement period field. The detailed timing of this measurement was described previously. The round trip delay is used to determine the rate at which reverse link data can be safely sampled.

The round trip delay measurement involves determining, detecting, or counting the number of forward link data clock intervals that occur between the beginning of the measurement period field and the beginning of the time period when the host receives a 0xff, 0x00 response sequence from the client. It should be noted that it is possible to receive a response from the client for a fraction of the forward link clock cycle immediately before the measurement count is incremented. If this unmodified value is used to calculate the reverse rate divisor, it can result in bit errors on the reverse link due to unreliable data samples. One example of this is illustrated in fig. 51, where signals representing MDDI _ Data at the host, MDDI _ Stb at the host, the forward link Data clock internal to the host, and the delay count are graphically illustrated. In fig. 51, a response sequence has been received from the display for a portion of the forward link clock cycle immediately prior to the delay count increasing from 6 to 7. If the delay is assumed to be 6, the host will sample the inverted data just after the bit transition or possibly in the middle of the bit transition. Doing so can result in sampling errors at the host. For this reason, the measured delay should typically be increased by 1 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 the reverse link data. Since MDDI _ Stb is cycled periodically at half the forward link rate, the correct round trip delay measurement needs to be divided by 2 and then rounded up to the next integer. This relationship is expressed as the formula:

for the given example, it becomes:

if the round trip delay measurement for this example is 7 instead of 6, then the reverse rate divisor is also equal to 4.

The reverse link data is sampled by the host at the rising edge of the reverse link clock. Counters or similar known circuits or devices are present in the host and client (displays) for generating the reverse link clock. The counter is initialized so that the first rising edge of the reverse link clock occurs at the beginning of the first bit of the reverse link packet field of the reverse link encapsulated packet. The situation for the example given below is illustrated in fig. 52. The counter is incremented by 1 on each rising edge of the MDDI _ Stb signal and the count is set by the reverse rate divisor parameter in the reverse link encapsulated packet until the count returns (wraparound) zero. Since the MDDI _ Stb signal is flipped at half the forward link rate, the reverse link rate is half the forward link rate divided by the reverse rate divisor. For example, if the forward link rate is 200Mbps and the reverse rate divisor is 4, the reverse link data rate may be expressed as:

An example of the timing of the MDDI _ Data0 and MDDI _ Stb signal lines in a reverse link encapsulated packet is shown in fig. 52, where the packet parameters used for illustration 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

The parameter CRC 0xdb43 all zeros 0x00

The packet data between the packet length and the parameter CRC field is:

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 having a packet length of 7 and a packet type of 70. This packet starts with byte values 0x07, 0x00, 0x46, … …, and so on. However, only the first byte (0x07) can be seen in FIG. 52. This first reverse link packet is shifted in time by one reverse link clock cycle in the figure to illustrate the actual reverse link delay. The ideal waveform with zero host-to-display round trip delay is shown as a dashed trace.

The MS byte of the parameter CRC field is conveyed, the CRC being preceded by the packet type and then the all zero field. When the data from the host changes levels, the strobe from the host switches from a switch to zero and back to one, forming a wider pulse. When the data becomes zero, the strobe signal switches at a higher rate, only the data change on the data line produces a change near the end of the alignment field. For the rest of the figure, since the data signal has a fixed 0 or 1 level and extends for some period of time, the strobe signal switches at the higher rate and this transition falls on the pulse pattern (edge).

The host's reverse link clock is at zero until the end of the turnaround 1 period, at which time the clock begins to support reverse link packets. The arrows in the lower part of the figure indicate the moment of data sampling, as is evident from the rest of the disclosure. The first byte of the packet field being transferred (here 11000000) is shown to occur after a turnaround of 1, and the line level is stable because the host drive is disabled. The delay in the transition of the first bit (passage) can be seen in the dashed line of the data signal and as seen for bit three.

A typical value for the reverse rate divisor based on the forward link data rate can be seen in fig. 53. The actual reverse rate divisor is determined as a result of the round trip link measurement to ensure proper reverse link operation. The first area 5302 corresponds to a safe operation area, the second area 5304 corresponds to a marginal performance area, and the third area 5306 indicates settings that are highly unlikely to work properly.

When working with any of the interface type settings on the forward or reverse link, the round trip delay measurement and reverse rate divisor settings are the same because they are expressed and operated on the actual clock period rather than the number of bits transmitted or received.

XI steering and guard time

As discussed earlier, the turnaround 1 field in the reverse link encapsulation packet and the guard time 1 field in the round trip delay measurement packet indicate a duration value that allows the host interface driver to be disabled before the display interface driver is enabled. The Turn to 2 and guard time 2 fields provide time values for allowing the display driver to be disabled before the host driver is enabled. The guard time 1 and guard time 2 fields are typically filled with preset lengths or preselected length values, which cannot be adjusted. Depending on the interface hardware being used, empirical data may be used to obtain these values and in some cases adjust them to improve operation.

Several factors help determine the length of turnaround 1, including the forward link Data rate and the maximum disable time of the MDDI _ Data driver in the host. The maximum host drive disable time is specified in table XI, which indicates that the drive takes up to about 10 nanoseconds to complete disabling and about 2 nanoseconds to complete enabling. The minimum number of forward link clocks required for the host driver to be disabled is expressed in terms of the following relationship:

The range of values allowed for turn 1 is represented by the following relationship:

where the interface Type factor is 1 for Type-1, 2 for Type II, 4 for Type III, and 8 for Type IV.

As can be seen from the above two equations, the interface type factors can be cancelled, and then turn 1 is defined as:

for example, a 1500Mbps type III forward link would use the following turn-1 delay:

as the round trip delay increases, the timing edge improves from the point in time when the host is disabled to the point in time when the display is enabled.

Factors used to determine the duration typically used for turnaround 2 are the forward link Data rate, the maximum disable 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 substantially the same as that of the host driver described above and is defined in terms of the following relationship:

and the allowable range of values for turn 2 can be expressed as:

for example, a 1500Mbps type III forward link with a round trip delay of 10 forward link clocks typically uses a turn-by-2 delay on the order of:

xii. optional reverse link timing

Although a high data transfer rate interface can be realized using the above-described timing and guard band (guard band), the inventors of the present invention have found a technique of providing a reverse bit length shorter than a round trip time by changing a reverse timing discovery (reverse timing discovery).

As described above, the previous approach to reverse link timing is configured such that the number of clock cycles is counted from the last bit of guard time 1 of the reverse timing packet until the first bit is sampled on the rising edge of the IO clock. This is the clock signal used to time the inputs and outputs of the MDD interface. The calculation of the reverse rate divisor is then given by the following equation:

this provides a bit width equal to the round trip delay, thereby enabling a very reliable reverse link. However, it has been demonstrated that the reverse link can operate faster, or at higher data transfer rates, which the inventors wish to utilize. The new technology of the present invention allows the additional capabilities of the interface to be exploited to achieve higher speeds.

This is accomplished by having the host count the number of clock cycles until sampling is completed for one 1, but during the reverse timing packet the host samples the data line on both the rising and falling edges. Doing so allows the host to gather the most useful and even the best sample points within the inverted bits to ensure that the bits are stable. That is, the most useful or optimal rising edge is found to sample the data on the reverse direction communication reverse direction encapsulation packet. The optimal sampling point depends on the reverse link divisor and whether the first 1 is detected on the rising or falling edge. The new timing method allows the host to look for only the first edge of the 0xFF0xFF 0x00 pattern sent by the client in the reverse link timing to determine where to sample in the reverse encapsulated packet.

An example of the inverse bits that arrive and how the bits will look for the various inverse rate divisors, and the number of clock cycles that have occurred since the last bit of guard time 1, is illustrated in fig. 64. It can be seen in fig. 64 that if the first edge occurs between rising and falling edges (labeled rising/falling), then the best sampling point for the reverse rate divisor of 1, i.e., the best sampling point, is the edge of the clock cycle labeled 'b', because of the only rising edge that occurs within the reverse bit period. For the reverse rate divisor 2, the best sampling point may still be the clock period leading edge 'b' since the periodic edge 'c' is closer to the bit edge than 'b'. For the reverse rate divisor 4, the best sample point may be the clock cycle edge'd' since it is closer to the trailing edge of the reverse bit where the value has settled.

Returning to fig. 64, however, if the first edge occurs between the falling and rising edges (labeled falling/rising), then the optimal sampling point for the reverse rate divisor 1 is the sampling point clock period edge 'a' because this is the only rising edge that occurs within the reverse bit time period. The optimal sampling point is edge 'b' for the reverse rate divisor 2 and edge 'c' for the reverse rate divisor 4.

It can be seen that as the reverse rate divisor gets larger and larger, the optimal sampling point becomes easier to determine or select since it should be a rising edge near the middle.

Using this technique, the host can find the number of rising clock edges before observing the rising data edges of a timing packet on the data lines. Thus, a decision can be made based on whether the edge occurs between rising and falling edges or between falling and rising edges, and what the reverse rate divisor is, how many additional clock cycles to add to the counter, in order to reasonably ensure that the sampling of the bit is always as close to the middle as possible.

Once the host has selected or determined the number of clock cycles, it can "investigate" (explorer) the various reverse rate divisors with the client to determine if a particular reverse rate divisor is available. The host (and client) may start with a divisor of 1 and check the CRC of the reverse status packet received from the client to determine if this reverse rate can properly transfer the data. If the CRC is corrupted, there is a possibility of a sampling error, and the host may increase the reverse rate divisor in an attempt to request a status packet again. If the second requested packet is corrupted, the divisor may be increased again and the request made again. This reverse rate divisor can be used for all future reverse packets if this packet is decoded correctly.

This method is efficient and useful because the reverse timing should not change since the initial round trip timing estimate. If the forward link is stable, the client should continue decoding the forward link packets even if there is a reverse link failure. Of course, since this approach does not ensure that the reverse link is perfect, it is still the responsibility of the master to set the reverse link divisor for that link. In addition, the divisor will depend primarily on the clock quality used to generate the IO clock. If the clock has a large jitter, there is a greater likelihood of a sampling error. This error probability increases as the number of clock cycles in the round trip delay increases.

This implementation appears to be best suited for type I reverse data, but problems may arise for type II to type IV reverse data, since the skew between the data lines may be too large to operate the link at the rate best suited for one data pair. However, the data rate may not need to be reduced to the previous method even with type II to type IV operation. This method may also be most applicable if it is replicated on each data line in order to select the ideal or optimal clock sampling position. This method can continue to work if they are at the same sample time for each data pair. If they are at different sampling periods, two different approaches may be used. The first is to select a desired or more optimal sampling position for each data point, even though the sampling position is not the same for each data pair. The host is then able to reconstruct the data stream from the set of data pairs after sampling all the bits: two bits for type II, four bits for type III and eight bits for type IV. Another option for the host is to increase the reverse rate divisor so that the data bits of each data pair can be sampled on the same clock edge.

Effect of Link delay and skew XIII

The delay skew between the MDDI _ Data pair and MDDI _ Stb on the forward link will limit the maximum Data rate possible unless delay skew compensation is employed. The delay differences that create timing skew arise from the controller logic, line drivers and receivers, and cables and connectors, as outlined below.

A. Link timing analysis by deviation constraint (MDDI type I)

Delay and skew examples for type I links

An exemplary interface circuit for supporting a type I interface link, similar to that shown in fig. 41, is shown in fig. 57. In fig. 57, exemplary or typical values of propagation delay and skew are shown for each of a plurality of processing or interface stages of an MDDI type I forward link. The deviation in the delay between MDDI _ Stb and MDDI _ Data0 causes the duty cycle of the output clock to be distorted. The data at the D input of the receiver flip-flop (RXFF) stage using flip-flops 5728, 5732 must change slightly after a clock edge in order to be able to reliably sample it. The figure shows two cascaded delay lines 5732a and 5732b for solving two different problems with generating this timing relationship. In a practical implementation, they may be combined into a single delay element.

Fig. 58 illustrates data, Stb and clock recovery timing on a type I link for exemplary signal processing via the interface.

The total delay bias, which is usually significant, occurs or comes from the sum of the biases in the following stages: a transmitter flip-flop (TXFF) with flip-flops 5704, 5706; a transmitter driver (TXDRVR) with drivers 5708, 5710; CABLE (CABLE) 5702; a receiver line receiver (RXRCVR) with receivers 5722, 5724, and receiver XOR logic (RXXOR). The delay 15732a should match or exceed the delay of the XOR gate 5736 of the RXXOR stage, which is determined by the following relationship:

t_{PD-min (delay 1)}≥t_PD-max(XOR)

This requirement needs to be met so that the D input of the receiver flip-flops 5728, 5732 does not change before their clock inputs. This is valid if the hold time of RXFF is zero.

The purpose or function of Delay 2(Delay2) is to compensate for the hold time of the RXFF flip-flop as follows:

t_{PD-min (delay2)}＝t_H(RXFF)

In many systems this value will be zero, since the hold time is zero, in which case the maximum delay of delay2 is of course also zero.

The worst case of skew in the receiver XOR stage is a data-late/strobe-early case where delay 1 is at a maximum and the clock output from the XOR gate arrives as early as possible according to the following relationship:

t_{Offset-max (RXXOR)}＝t_{PD-max(Delay1)}-t_PD-min(XOR)

In this case, the data may change between two bit periods n and n +1, very close to the moment at which bit n +1 is clocked into the receiver flip-flop.

The maximum data rate (minimum bit period) of an MDDII type link is a function of the maximum skew encountered through all drivers, cables, and receivers in the MDDI link plus the aggregate data set by the RXFF stage. The total delay deviation in the link up to the output of the RXRCVR stage can be expressed as:

t_{offset-max (LINK)}＝t_{Offset-max (TXFF)}+t_{Offset-max (TXDRVR)}+t_{Deviation-max (Cable)}+t_{Offset-max (RXRCVR)}

And the minimum bit period is given by the following equation:

t_bit-min＝t_{Offset-max (Link)}+t_{Offset-max (RXXOR)}+t_{PD-max(Delay2)}+t_SU(RXFF)

In the example shown in FIG. 57, t_{Offset-max (Link)}1.4 nanoseconds and the minimum bit period can be expressed as:

t_bit-min1.4+0.3+0.2+ 0.5-2.4 ns, or approximately 416 Mbps.

MDDIII, III and IV link timing analysis

Typical interface circuits similar to those shown in fig. 41 and 57 are shown in fig. 59 for supporting type II, type III and type IV interface links. Additional components are used at the stages TXFF (5904), TXDRVR (5908), RXRCVCR (5922), and RXFF (5932, 5928, 5930) to support additional signal processing. In fig. 59, exemplary or typical values of propagation delay and skew are shown for each of a plurality of processing or interface stages of an MDDI type II forward link. In addition to the deviation in delay between MDDI _ Stb and MDDI _ Data0, which affects the duty cycle (duty-cycle) of the output clock, there is a deviation between these two signals and the other MDDI Data signals. The data at the D input of the receiver flip-flop b (rxffb) stage, which includes flip-flops 5928 and 5930, changes slightly after the clock edge so that it can be reliably sampled. If MDDI _ Data1 arrives earlier than MDDI _ Stb or MDDI _ Data0, then MDDI _ Data1 should be delayed in order to sample at least by the delay offset. To accomplish this, a Delay 3(Delay3) Delay line is used to Delay the data. If MDDI _ Data1 arrives later than MDDI _ Stb and MDDI _ Data0, and it is also delayed by delay3, then the point at which MDDI _ Data1 changes is moved closer to the next clock edge. This process determines the upper limit on the data rate of MDDIII, type III or type IV links. Some exemplary different possibilities for timing or offset relationships of the two data signals and MDDI _ Stb relative to each other are illustrated in fig. 60A, 60B, and 60C.

When MDDI DataX arrives early, to reliably sample data in RXFFB, delay 3 is set according to the following relationship:

t_{PD-min(Delay3)}≥t_{offset-max (LINK)}+t_H(RXFFB)+t_PD-max(XOR)

The maximum link speed depends on the minimum bit period allowed. This speed is most affected when MDDI _ DataX arrives as late as possible. In this case, the minimum allowable cycle time is given by the following equation:

t_bit-min＝t_{Offset-max (LINK)}+t_{PD-max(Delay3)}+t_SU(RXFFB)-t_PD-min(XOR)

The upper limit of the link speed is then:

t_{PD-max(Delay3)}＝t_{PD-min(Delay3)}

and under the above assumptions:

t_{digit-min (lower-bound)}＝2t_{Offset-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_{position-min (lower-level)}2 · 1.4+1.5+0.5+0.1 — 4.8 ns, which is approximately 208 Mbps.

This is much slower than the maximum data rate that can be used for a type I link. The automatic delay skew compensation capability of MDDI significantly reduces the impact of delay skew on maximum link rates.

XIV physical layer interconnect description

The physical connections of the interfaces that can be used to implement the present invention can be implemented using commercially available parts, such as part number 3260-8S2(01) manufactured by Hirose Electric Company Ltd on the host side and part number 3240-8P-C manufactured by Hirose Electric Company Ltd on the display device side. Exemplary interface pin assignments or "pin outs" for such connectors for use with type I/type II interfaces are listed in table XIII and illustrated in fig. 61.

TABLE XIII

Signal name	Pin number	Colour(s)	Signal name	Pin number	Colour(s)
						MDDI_Pwr	1	White colour	MDDI_Gnd	2	Black paired with white
MDDI_Stb+	3	Green colour	MDDI_Stb-	4	Black paired with green
						MDDI_Data0+	7	Blue color	MDDI_Data0-	8	Black paired with basket color
MDDI_Data1+	11	Brown colour	MDDI_Data1-	12	Black paired with brown
						MDDI_Data2+	15	Red colour	MDDI_Data2-	16	Black paired with red
MDDI_Data3+	19	Orange red	MDDI_Data3-	20	Black paired with orange
						MDDI_Data4+	17	TBD1	MDDI_Data4-	18	Black paired with TBD1
MDDI_Data5+	13	TBD2	MDDI_Data5-	14	Black paired with TBD2
						MDDI_Data6+	9	TBD3	MDDI_Data6-	10	Black paired with TBD3
MDDI_Data7+	5	TBD4	MDDI_Data7-	6	Black paired with TBD4
			Shielding

The shield is connected to the MDDI _ Gnd in the host interface and the shield ground in the cable is connected to the shield of the display connector. However, this shield and ground are not connected to the circuit ground inside the display.

The interconnecting elements or devices are selected or designed to be small enough for use in mobile communication and computing devices, such as PDAs and wireless telephones, or portable gaming devices, without exceeding or being aesthetically displeasing compared to the relative device sizes. Any connectors and cables should be sufficiently durable and small in size, especially for cables, and relatively low in cost in a typical consumer environment. The transfer element should support data and strobe signals as differential NRZ data having a transfer rate of up to around 450Mbps for type I and type II and up to 3.6Gbps for 8-bit parallel type IV versions.

For internal mode applications, there is no connector for the wires used as well, or such connecting elements tend to be miniaturized. One example is a zero insertion force "socket" for accepting an integrated circuit or component to which a host or client device is mounted. Another example is where the host and client reside on printed circuit boards having various interconnecting wires and have "pins" or contacts extending from the housing that are soldered to the wires used to interconnect the integrated circuits.

XV. operation

An overview of the general steps performed in processing data and packets during operation of an interface using an embodiment of the present invention is shown in fig. 54A and 54B, and an overview of the interface device processing the packets is shown in fig. 55. In these figures, the process begins at step 5402 by determining whether the client and host are connected using a communication path (here, a cable). This may be done by the host periodically polling using software or hardware that detects the presence of a connector, cable or signal (e.g., USB interface) at the input of the host, or by other known techniques. If no client is connected to the host, it may only enter a wait state for some predetermined length, depending on the application, enter a sleep mode, or be inactive for future use, which may require the user to take action to reactivate the host. For example, when a host resides on a computer type device, a user may have to click on a screen icon or request a program to activate the host process to find a client. Furthermore, merely plugging in a USB type connection, such as a connection for a U-type interface, can activate host processing, depending on the capabilities and configuration of the host or resident host software.

Once the client is connected to the host, or vice versa, or the client is detected as present, the client or host sends an appropriate service request packet at steps 5404 and 5406. At step 5404, the client may send a display service request or status packet. It should be noted that, as described above, the link may have been previously shut down or in a sleep mode, and thus the subsequent may not be a complete initialization of the communication link. Once the communication link is synchronized and the host attempts to communicate with the client, the client also provides the display capability packet to the host, as in step 5408. The host may now begin to determine the types of support, including transfer rates, that the client may support.

Typically, at step 5410, the host and client also negotiate the type (rate/speed) of service mode to be used, e.g., type I, type U, type II, etc. Once the service type is established, the host can begin to transmit information. Additionally, the host may use the round trip delay measurement packets in parallel with other signal processing to optimize the timing of the communication link, as shown in step 5411.

As previously described, all transfers begin with the sub-frame header packet being transferred as shown at step 5412, followed by the data type being transferred and filler packet, here video and audio stream packets, as shown at step 5414. The audio and video data have been pre-prepared or mapped into packets and filler packets inserted as needed or desired to fill in the number of bits required for the media frame. The host can send a packet, such as a forward audio channel enable packet, to activate the audio device. In addition, in step 5416, the host can use the other packet types described above to transfer commands and information, here shown as color mapping, bit block transfer, or transfer of other packets. Further, the host and client can exchange data relating to the keyboard or pointing device using appropriate packets.

During operation, one of a number of different events may occur, which may result in a different data rate or interface mode type being required by the host or client. For example, a computer or other device used to communicate data may encounter loading conditions (loading conditions) during processing of the data that result in a slower preparation or presentation of data packets. Displays receiving data may be switched from dedicated ac power to more limited battery power and may not be able to transmit data quickly, process commands easily, or use the same resolution or color depth with limited power settings. The constraints may also be reduced or eliminated, allowing the device to transmit data at a higher rate. It is more desirable to request a change to a higher transfer rate mode.

If these or other types of known conditions occur or change, the host or client may detect them and attempt to re-negotiate the interface mode. This is shown in step 5420, where the host client sends an interface type switch request packet to request a switch to another mode, the client sends an interface type acknowledgement packet to acknowledge that a change is sought, and the host sends an execute type switch packet to change to the specified mode.

Although no particular order of processing is required, the client and host may exchange packets relating to data to be sent to or received from a pointing device, keyboard or other user-type input device primarily connected to the client, although these elements may also be present on the host side. These packets are typically processed using a general purpose processor type element rather than a state machine (5502). In addition, some of the commands described above are also processed by the general purpose processor (5504, 5508).

After data and commands have been exchanged between the host and client, at some point a decision is made as to whether to transfer additional data or whether the host or client is to stop servicing the transfer. This is shown in step 5422. If the link is going to sleep or completely shut down, the host sends a link shutdown packet to the client and both sides terminate the transfer of data.

The data packets transmitted in the above-described operational process will be transmitted using the drivers and receivers discussed previously with respect to the host and client controllers. These line drivers and other logic elements are connected to the state machine and general purpose processor as shown in the overview of FIG. 55. In fig. 55, state machine 5502 and general processors 5504 and 5508 may be further connected to other elements not shown, such as a dedicated USB interface, memory elements or other components residing outside of the link controller with which they interact, including but not limited to a data source and a video control chip for viewing the display device.

The processor and state machine provide enable and disable control of the driver, as discussed above with respect to guard time and the like, to ensure that the communication link is effectively established or terminated and that data packets are transmitted.

XVI display frame buffer

The buffering requirements for video data are different for moving video images compared to computer graphics. The pixel data is often stored in the client's local frame buffer so that the image on the display can be refreshed locally.

When displaying full motion video (almost every pixel of the display changes in every media frame), it is generally preferable to store input pixel data in one frame buffer while updating the image on the display from the second frame buffer. More than two display buffers may be used to eliminate visual artifacts, as described below. When the entire image has been received in one frame buffer, the roles of the buffers can be switched, the newly received image being used to refresh the display, and the next frame of the image being filled into the other buffer. This concept is illustrated in FIG. 91A, where pixel data is written to an offline image buffer by setting the display update bit to "01".

In other applications, the host need only update a small portion of the image, rather than having to redraw the entire image. In this case, new pixels need to be written directly to the buffer for refreshing the display, as shown in fig. 91B.

In applications with fixed images with smaller video windows, it is easiest to write the fixed images to two buffers (display update bit equals "11"), as shown in FIG. 91C, and then write the motion image pixels to the offline buffer by setting the display update bit to "01".

The following rules describe the beneficial manipulation of the buffer pointer while writing new information to the client and refreshing the display. There are three buffer pointers: current _ file (currently filled) points to the buffer currently being filled by data on the MDDI link; just filled points to the most recently filled buffer; the bed _ displayed points to the buffer currently being used to refresh the display. All three buffer pointers may contain values from 0 to N-1, where N is the number of display buffers and N ≧ 2. The operation on the buffer pointer is modulo N (mod N), for example, when N is 3 and current _ file is 2, adding current _ file lets current _ file be set to 0. In the simple case of N-2, just _ file is always the complement of current _ file. The following operations are performed in the specified order at each MDDI medium frame boundary (subframe header packet of subframe count field equals zero): just _ file is set equal to current _ file, and current _ file is set equal to current _ file + 1.

The MDDI video stream packets update the buffer as follows: when the display update bit equals '01', writing the pixel data into the buffer specified by current _ file; when the display update bit is equal to '00', writing the pixel data to the buffer specified by just _ filed; when the display update bit equals "11", the pixel data is written to all buffers. The display is refreshed according to the buffer specified by the bed _ displayed pointer. After the display refreshes the last pixel in one frame refresh period (epoch) and before it starts refreshing the first pixel in the next frame refresh period, the display update process performs an operation of setting the waiting refresh equal to just filed.

The video stream packet includes a pair of display update bits, indicating the frame buffer to which pixel data should be written. The display capability packet has three additional bits indicating the combination of display update bits supported in the client. In many cases, computer-generated images need to be incrementally refreshed based on user input, or derived from information received from a computer network. Display update bit patterns "00" and "11" support this mode of operation by having pixel data written to either the frame buffer being displayed or to both frame buffers.

When supporting video images, fig. 92 illustrates how a pair of frame buffers are used to display video images when the display update bit is equal to "01" and video data is transmitted over the MDDI link. After a media frame boundary is detected on the MDDI link, the display refresh process will begin refreshing from the next frame buffer when the refresh process for the frame currently being refreshed is complete.

Two buffers, display refresh faster than image transfer

Two buffers, display refresh much faster than image transfer

An important assumption related to fig. 92 is that: the image is received from the host as a continuous stream of pixels that is transmitted in the order in which the client reads the pixels from the frame buffer to refresh the display (usually starting from the top left and reading line by line, up to the bottom right corner of the screen). This is an important detail in the case where the display refresh and image transfer operations involve the same frame buffer.

The display refresh frame rate needs to be greater than the image transfer frame rate in order to avoid displaying partial images. Fig. 93 shows how image fragmentation occurs in the case where the display refresh rate is slow, that is, the display refresh is slower than the image transfer.

Two buffers, display refresh slower than image transfer

In images containing a combination of computer graphics images and motion video images, video pixel data may occupy a small portion of the media frame. This is particularly evident in the case where the display refresh operation and the image transfer involve the same frame buffer. These cases are illustrated by the cross-hatched shading in fig. 94, where the pixels read from the buffer to refresh the display may be the pixels written to the buffer two frames ago, or they may correspond to the frames being written to the same frame buffer.

Two buffer display refresh is much faster than image transfer, small video window

Three frame buffers are used in the client to solve the problem of contention for small windows accessing the frame buffers, as shown in fig. 95.

Three buffers, display refresh much faster than image transfer, video window of any size

However, if the display refresh rate is less than the media frame rate on the MDDI link, then a problem still exists, as shown in fig. 96.

Three buffers, display refresh slower than image transfer

There is a problem in how much a single buffer is used for moving video images, as shown in fig. 97. When the display refreshes faster than the image is transferred into the buffer, the image being refreshed will sometimes display the upper portion of the frame being written, while the lower portion of the image is the previously transferred frame. The case of frames showing similar split images will occur more frequently when the display refreshes faster than the image transfer (preferred mode of operation).

A buffer for display refresh faster than image transfer

A buffer, display refresh being much faster than image transfer

Table of delay values xvii

Packet processing delay parameter the packet uses a table lookup function to calculate the predicted delay to process certain commands in the client. The values in the table are increased logarithmically to provide very wide dynamic range delay values. An exemplary table of delay values for implementing embodiments of the present invention can be found in table XX below, with corresponding indices being contrasted with the delay values.

Watch XX (adding whole new watch)

0-no delay	37-1.5ns	74-51ns	111-1.8us	148-62us	185-2.2ms	222-75ms
							1-46ps	38-1.6ns	75-56ns	112-2.0us	149-68us	186-2.4ms	223-83ms
2-51ps	39-1.8ns	76-62ns	113-2.2us	150-75us	187-2.6ms	224-91ms
							3-56ps	40-2.0ns	77-68ns	114-2.4us	151-83us	188-2.9ms	225-100ms
4-62ps	41-2.2ns	78-75ns	115-2.6us	152-91us	189-3.2ms	226-110ms
							5-68ps	42-2.4ns	79-83ns	116-2.9us	153-100us	190-3.5ms	227-120ms
6-75ps	43-2.6ns	80-91ns	117-3.2us	154-110us	191-3.8ms	228-130ms
							7-83ps	44-2.9ns	81-100ns	118-3.5us	155-120us	192-4.2ms	229-150ms
8-91ps	45-3.2ns	82-110ns	119-3.8us	156-130us	193-4.6ms	230-160ms
							9-100ps	46-3.5ns	83-120ns	120-4.2us	157-150us	194-5.1ms	231-180ms
10-110ps	47-3.8ns	84-130ns	121-4.6us	158-160us	195-5.6ms	232-200ms
							11-120ps	48-4.2ns	85-150ns	122-5.1us	159-180us	196-6.2ms	233-220ms
12-130ps	49-4.6ns	86-160ns	123-5.6us	160-200us	197-6.8ms	234-240ms
							13-150ps	50-5.1ns	87-180ns	124-6.2us	161-220us	198-7.5ms	235-260ms
14-160ps	51-5.6ns	88-200ns	125-6.8us	162-240us	199-8.3ms	236-290ms
							15-180ps	52-6.2ns	89-220ns	126-7.5us	163-260us	200-9.1ms	237-320ms
16-200ps	53-6.8ns	90-240ns	127-8.3us	164-290us	201-10ms	238-350ms
							17-220ps	54-7.5ns	91-260ns	128-9.1us	165-320us	202-11ns	239-380ms
18-240ps	55-8.3ns	92-290ns	129-10us	166-350us	203-12ms	240-420ms
							19-260ps	56-9.1ns	93-320ns	130-11us	167-380us	204-13ms	241-460ms
20-290ps	57-10ns	94-350ns	131-12us	168-420us	205-15ms	242-510ms
							21-320ps	58-11ns	95-380ns	132-13us	169-460us	206-16ms	243-560ms
22-350ps	59-12ns	96-420ns	133-15us	170-510us	207-18ms	244-620ms
							23-380ps	60-13ns	97-460ns	134-16us	171-560us	208-20ms	245-680ms
24-420ps	61-15ns	98-510ns	135-18us	172-620us	209-22ms	246-750ms
							25-460ps	62-16ns	99-560ns	136-20us	173-680us	210-24ms	247-830ms
26-510ps	63-18ns	100-620ns	137-22us	174-750us	211-26ms	248-910ms
							27-560ps	64-20ns	101-680ns	138-24us	175-830us	212-29ms	249-1.0sec
28-620ps	65-22ns	102-750ns	139-26us	176-910us	213-32ms	250-1.1sec
							29-680ps	66-24ns	103-830ns	140-29us	177-1.0ms	214-35ms	251-1.2sec
30-750ps	67-26ns	104-910ns	141-32us	178-1.1ms	215-38ms	252-1.3sec
							31-830ps	68-29ns	105-1.0us	142-35us	179-1.2ms	216-42ms	253-1.5sec
32-910ps	69-32ns	106-1.1us	143-38us	180-1.3ms	217-46ms	254-1.6s
							33-1.0ns	70-35ns	107-1.2us	144-42us	181-1.5ms	218-51ms	255-indeterminate
34-1.1ns	71-38ns	108-1.3us	145-46us	182-1.6ms	219-56ms
							35-1.2ns	72-42ns	109-1.5us	146-51us	183-1.8ms	220-62ms
36-1.3ns	73-46ns	110-1.6us	147-56us	184-2.0ms	221-68ms

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

In some cases, this delay is multiplied by the height, width, or number of pixels of the target image and added to the other delays to calculate the overall packet processing delay.

XVIII Multi-client support

Current protocol versions appear to be unable to directly support multiple client devices. However, most packets contain a reserved client ID field that can be used to address a particular client device in a system with multiple clients. Currently, for many applications, this client ID or these client IDs are set to zero. The sub-frame header packet also contains a field to indicate whether the host supports multiple client systems. Thus, there is a way in which it is possible to connect and address multiple client devices in future applications of the MDD interface or protocol to help system designers plan for future compatibility with multiple client hosts and clients.

In systems with multiple clients, it is beneficial to connect the clients to the host via a Daisy-chain (Daisy-chained) of clients or using a hub.

XVIII. appendix

In addition to the format, structure, and content of the architecture and protocols discussed above for implementing embodiments of the present invention, more detailed field content or operations are provided for certain packet types. These matters are presented to further clarify their respective use or operation in order to make it easier for a person skilled in the art to understand and use the present invention for various applications. Only a few fields that have not been discussed are discussed herein. In addition, these fields are given with exemplary definitions and values with respect to the embodiments given above. These values, however, should not be construed as limiting the invention, but rather they represent one or more embodiments useful for implementing these interfaces and protocols, and not all embodiments need be implemented together or simultaneously. Other embodiments may also employ other values in order to achieve presentation of the desired data or data rate transmission results, as will be understood by those skilled in the art.

A. With respect to video stream packets

In one embodiment, the pixel data attribute field (2 bytes) has a series of bit values as explained below. Bits 1 and 0 select how to route the display pixel data. For bit value '11' the data is displayed to both eyes, for bit value '10' the data is routed only to the left eye and for bit value '01' the data is routed only to the right eye, and for bit value '00' the data is routed to an alternative display, as specified by bits 8 to 11 discussed below.

Bit 2 indicates whether the pixel data is provided in interlaced format, and a value of '0' means that the pixel data is in standard progressive format, with the line number (pixel Y coordinate) incremented by 1 as one progresses from one line to the next. When this bit has the value '1', the pixel data is in interlaced format and the line number is incremented by 2 as one progresses from one line to the next. Bit 3 indicates that the pixel data is in an alternate pixel format. This is similar to the standard interlacing mode allowed by bit 2, but here the interlacing is vertical rather than horizontal. When bit 3 is '0', the pixel data is in a standard pixel-by-pixel format, and the column number (pixel X coordinate) is incremented by 1 as each successive pixel is received. When bit 3 is '1', the pixel data is in an alternating pixel format, with the column number incremented by 2 as each pixel is received.

Bit 4 indicates whether the pixel data relates to a display or a camera, i.e. where the data is transferred to or from an internal display of a wireless telephone or similar device, or even a portable computer or other device as described above, or where the data is transferred to or from a camera embedded in or directly coupled to the device. When bit 4 is '0', the pixel data is being transferred to or from the display frame buffer. When bit 4 is a '1', the pixel data is transferred to and from some type of camera or video device, such devices being 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 considered the case when bit 5 is set equal to '1'. When bit 5 is set to '1', then the X left edge, Y top edge, X right edge, Y bottom edge, X start, and Y start parameters are not defined and are ignored by the client. The frame synchronization packet defines the next line as the top line of the image.

Bits 7 and 6 are display update bits to illustrate the frame buffer to which pixel data will be written. More specific effects are discussed elsewhere. For bit value '01', the pixel data is written into the offline image buffer. For bit value '00', the pixel data is written into an image buffer for refreshing the display. For bit value '11', pixel data is written into all image buffers. The bit value or combination '10' is treated as an invalid value or designation and the pixel data is ignored and not written to any image buffer. This value may be useful for future applications of the interface.

Bits 8 through 11 form a 4-bit unsigned integer that illustrates the optional display or display location to which the data is routed. Bits 0 and 1 equal 00 to cause the display client to interpret bits 8 through 11 as selectable display numbers. If bits 0 and 1 are not equal to 00, then bits 8 through 11 are set to zero.

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

The 2 byte X start and Y start fields specify the absolute 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 edge X coordinate and the top edge Y coordinate of the screen window filled by the pixel data field, while the X right edge and Y bottom edge fields specify the right edge X coordinate and the bottom edge Y coordinate of the window being updated.

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

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

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

The pixel data CRC field (2 bytes) contains a 16-bit CRC of only the pixel data. If the CRC check for this value fails, the pixel data is still usable, but the CRC error count is incremented.

B. With respect to audio stream data packets

In one embodiment, the audio channel ID field (1 byte) identifies the particular audio channel to which the client device is to send audio data using an 8-bit unsigned integer value. The physical audio channels are designated or mapped by this field according to the values 0, 1, 2, 3, 4, 5, 6 or 7, which indicate the left front, right front, left rear, right rear, front center, subwoofer, surround left and surround right channels, respectively. The audio channel ID value 254 indicates that a single stream of digital audio samples is sent to the front left and front right channels. This simplifies communication for applications such as applications that use stereo headphones for voice communication, applications that improve productivity for PDA use, or other applications where a simple user interface generates an alert sound. The ID field values in the range from 8 to 253 and 255 are currently reserved for use in situations where new designs require additional identification, as would be expected by those skilled in the art.

The reserved 1 field (1 byte) is typically reserved for future use and all bits in this field are set to zero. One function of this field is to have all subsequent 2-byte fields aligned with a 16-bit word address and 4-byte fields aligned with a 32-bit word address.

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

Each of the number of sample bits and the packing field contains 1 byte for explaining the packing format of the audio data. In one embodiment, the commonly employed format is to define the number of bits per PCM audio sample using bits 4 through 0. Bit 5 then indicates whether the digital audio data samples are packed. As described above, fig. 12 illustrates the difference between packed audio samples and byte-aligned audio samples. A value of '0' for bit 5 indicates that each PCM audio sample in the digital audio data field is byte aligned with an interface byte boundary, and a value of '1' indicates that each successive PCM audio sample is packed relative to the previous audio sample. This bit is usually valid only if the value defined in bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of 8. Bits 7 through 6 are reserved for use when additional identification is required by the system design and are typically set to zero.

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

The parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the audio sample rate. If this CRC fails to properly check, the entire packet is discarded. The digital audio data field contains the original audio samples to be played and is typically in the form of a linear format of unsigned integers. The audio data CRC field (2 bytes) contains a 16-bit CRC for audio data only. If this CRC fails to check, the audio data may still be used, but the CRC error count is increased.

C. Streaming data packets on user definitions

In one embodiment, a 2 byte stream ID number field is used to identify a particular user-defined stream. The contents of the stream parameters and stream data fields are typically defined by the MDDI equipment manufacturer. The 2 byte stream parameter CRC field contains a 16 bit CRC of all bytes of the stream parameters from the beginning of the packet length to the audio encoded bytes. If this CRC fails to check, the entire packet is discarded. Both the flow parameters and the flow parameter CRC fields may be discarded if they are not needed by the end application of the MDD interface, i.e. they are considered optional. The 2 byte stream data CRC field contains a CRC for only the stream data. The use of stream data is optional if this CRC fails to check properly, depending on the requirements of the application. The use of stream data is dependent on the goodness of the CRC, which typically requires that the stream data be buffered until the CRC is confirmed as good. If the CRC does not pass the check, the CRC error count is incremented.

D. Color mapping data packet

The 2-byte hClient ID field contains information or values reserved for client IDs, as previously used. Since this field is normally reserved for future use, it is currently set to zero by setting these bits to '0'.

The 2-byte color mapping entry count field uses a value to specify a total of 3 byte color mapping entries contained in the color mapping data field, or entries of the color mapping table present in the color mapping data of this packet. In this embodiment, the number of bytes in the color mapping data is 3 times the color mapping item count. The color map item count is set equal to zero so that no color map data is sent. If the color map size is zero, the color map offset value is still typically sent but ignored by the display. 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 contains the CRC of all bytes from the packet length to the audio coding bytes. If this CRC fails to check, the entire packet is discarded.

For the color map data field, the width of each color map location is specified by a color map entry size field, where in one embodiment, a first portion specifies a blue value, a second portion specifies a green value and a third portion specifies a red value. The color map size field specifies the number of 3-byte color map entries present in the color map data field. If a single color map cannot conform to the (fit into) video data format and color map packet, the entire color map may be specified by sending multiple packets with different color map data and color map offsets in each packet. The number of bits of blue, green and red in each color map data entry should be the same as specified by the color map RGB width field of the display capability data packet.

The 2-byte color mapping data CRC field contains only the CRC of the color mapping data. If such a CRC fails to check, the color mapping data is still usable, but the CRC error count is increased.

Each color mapping data item is transmitted in the following order: blue, green, red, the least significant bit of each component is transmitted first. The individual red, green and blue components of each color map entry are packed, but each color map entry (the least significant bit of the blue component) should be byte aligned. Error! No source of reference was found. (new Z) "shows an example of a color mapping data item having 6 bits of blue, 8 bits of green, and 7 bits of red. For this example, the color map entry size in the color map packet is equal to 21, while the color map RGB width field of the display capability packet is equal to 0x 0786.

E. Encapsulating data packets with respect to reverse link

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

In one embodiment, the reverse link flag field (1 byte) contains a set of flags for requesting information from the display. If the bit (e.g., bit 0) is set to 1, then the host uses the display capability packet to request the specified information from the display. If the bit is zero, the host does not need information from the display. The remaining bits (here bits 1 to 7) are reserved for future use and set to zero. However, more bits may also be used to set the flag for the reverse link as needed.

The reverse rate divisor field (1 byte) specifies the number of MDDI _ Stb cycles that occur in relation to the reverse link data clock. The reverse link data clock is equal to the forward link data clock divided by a double reverse rate divisor. The reverse link data rate relates to the reverse link data clock and the type of interface on the reverse link. The reverse data rate is equal to the reverse link data clock for type I interfaces and 2, 4, and 8 times the reverse link data clock for type II, type III, and type IV interfaces, respectively.

The all-zero 1 field contains a set of bytes set to a zero value by setting these bits to a logic 0 level and is used to ensure that all MDDI _ Data signals are in a zero state before disabling the line drivers for the first guard time period to allow the reflected logic 1 level to be consumed before disabling the line drivers of the host during the turnaround 1 field. In one embodiment, the length of the all-zeros 1 field is greater than or equal to the number of forward link byte transmissions in the round trip delay of the cable.

The Turn 1 Length field (1 byte) specifies the total number of bytes allocated to Turn 1 to establish the first Turn period. The number of bytes specified by the turnaround length parameter is allocated to allow the MDDI _ Data line driver in the host to be disabled before the line driver in the client is enabled. During bit 0 of Flway 1, the host disables its MDDI _ Data line driver, and the client enables its output and drives MDDI _ Data0 to logic 0 during the last bit of Flway 1. The MDDI _ Stb signal behaves as if the turnaround 1 period is all zero. The suggested length of Flex 1 is the number of bytes needed for the MDDI _ Data driver in the host to disable the output. This is selected based on the output disable time, forward link data rate, and the type of forward link interface being used. A more complete description of the steering 1 arrangement is given above.

The all-zeros-2 field contains a set of bytes set to zero values by setting these bits to a logic 0 level and is used to ensure that all MDDI _ Data signals are in a zero state to allow the reflected logic 1 level to be consumed before disabling the line drivers of the host during the turnaround 1 field. In one embodiment, the length of the all-zeros 2 field is greater than or equal to the number of forward link byte transmissions in the round trip delay of the cable.

The Turn 2 Length field (1 byte) specifies the total number of bytes allocated to Turn 2 for establishing the second Turn period. The number of bytes specified by the turnaround length parameter is allocated to allow the MDDI _ Data line driver in the client to be disabled before the line driver in the host is enabled. During bit 0 of Flway 2, the guest disables its MDDI _ Data line driver, and the host enables its output and drives MDDI _ Data0 to logic 0 during the last bit of Flway 2. The MDDI _ Stb signal behaves as if MDDI _ Data0 were at a logic 0 level during the entire turnaround 2 period. The suggested length of Flex 2 is the number of bytes required for the MDDI _ Data driver to disable output in the display plus the round trip delay. A description of the steering 2 arrangement is given above.

The reverse data packet field contains a series of data packets transmitted from the client to the host. As previously described, filler data packets are sent to fill the remaining space not used by other data packet types.

The driver re-enable field uses 1 byte equal to logic zero to ensure that all MDDI _ Data signals are re-enabled before the packet length field of the next packet.

F. Data packet relating to display capabilities

In one embodiment, the protocol version field uses 2 bytes to specify the protocol version used by the client. The initial version is set equal to zero and the minimum protocol version field uses 2 bytes to specify the minimum protocol version that the client can employ or interpret. The display data rate capability field (2 bytes) specifies the maximum data rate that the display can receive on the forward link of the interface and is specified in the form of millions of bits per second (Mbps). The interface type capability field (1 byte) specifies the type of interface supported on the positive and negative links. This is presently indicated by selecting bit 0, bit 1 or bit 2 to select type II, type III or type IV mode, respectively, on the forward link, while bit 3, bit 4 or bit 5 to select type II, type III or type IV mode, respectively, on the reverse link; bits 6 and 7 are reserved and set to zero. The bitmap width and height field (2 bytes) specifies the width and height of the bitmap in pixels.

The monochrome capability field (1 byte) is used to specify the number of bits of resolution that can be displayed in monochrome format. This value is set to zero if the display cannot use a monochrome format. Bits 7 through 4 are reserved for future use and are set to zero. Bits 3 to 0 define the maximum number of bits of gray levels that can be present in each pixel. These four bits can specify values 1 to 15 for each pixel. If the value is zero, the display does not support the monochrome format.

The color mapping capability field (3 bytes) specifies the maximum number of entries present in the display color mapping table. This value is zero if the display cannot use the color mapping format.

The RGB capability field (2 bytes) specifies the number of bits of resolution that can be displayed in RGB format. This value equals zero if the display cannot use the RGB format. The RGB capability word includes three independent unsigned values, where: in each pixel, bits 3 to 0 define the maximum number of bits for blue, bits 7 to 4 define the maximum number of bits for green, and bits 11 to 8 define the maximum number of bits for red. Currently, bits 15 through 12 are reserved for future use and are typically set to zero.

The Y Cr Cb capability field (2 bytes) specifies the number of bits of resolution that can be displayed in the Y Cr Cb format. This value is set equal to zero if the display cannot use the Y Cr Cb format. The Y Cr Cb capability word includes three independent unsigned values, where: 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, bits 11 to 8 define the maximum number of bits in the Y sample, and bits 15 to 12 are currently reserved for future use and set to zero.

The display feature capability indicator field uses 4 bytes, which contains a set of flags to indicate the particular features supported in the display. A bit set to 1 indicates that the capability is supported, and a bit set to zero indicates that the capability is not supported. The value of bit 0 indicates whether bitmap block transfer packets (packet type 71) are supported. The values of bits 1, 2, and 3 indicate whether bitmap area fill packets (packet type 72), bitmap pattern fill packets (packet type 73), or communication link data channel packets (packet type 74), respectively, are supported. The value of bit 4 indicates whether the display has the ability to make one color transparent, while the values of bits 5 and 6 indicate whether the display can accept video or audio data in a packetized format, respectively, and the value of bit 7 indicates whether the display can transmit a reverse link video stream from the camera. The values of bits 11 and 12 indicate whether the client is communicating with the pointing device and is capable of sending and receiving pointing device data packets or is communicating with the keyboard and is capable of sending and receiving keyboard data packets, respectively. Bits 13 through 31 are currently reserved for future use or are used as optional flags to benefit the system designer and are typically set equal to zero.

The display video frame rate capability field (1 byte) specifies the maximum video frame update capability of the display in frames per second. The host may choose to update the image at a slower rate than the value specified in the field.

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

The audio channel capability field (2 bytes) contains a set of flags to indicate which audio channels are supported by the display (client). A bit set to 1 indicates that the channel is supported, while a bit set to zero indicates that the channel is not supported. Bit positions are assigned to different channels, e.g. bit positions 0, 1, 2, 3, 4, 5, 6 or 7 indicate left front, right front, left rear, right rear, front center, subwoofer, surround left and surround right channels, respectively. Bits 8 through 15 are currently reserved for future use and are typically 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. Thus, bit positions are assigned to different rates, such as bits 0, 1, 2, 3, 4, 5, 6, 7, and 8 being assigned to 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 Samples Per Second (SPS), respectively, bits 9 through 15 being reserved for future use or for alternative rates as needed, so they are currently set to '0'. Setting the bit value of one of the bits to '1' indicates that the particular sampling rate is supported, and setting the bit to '0' indicates that the sampling rate is not supported.

The minimum subframe rate field (2 bytes) specifies the minimum subframe rate in frames per second. The minimum sub-frame rate remains sufficient to read the display state refresh rate of certain sensors or pointing devices in the display.

The 2-byte microphone sample rate capability field for the reverse link contains a set of flags to indicate the audio sample rate capability of the microphone of the client device. For purposes of utilizing MDDI, the client device microphone is configured to minimally support a rate of 8,000 samples per second. The bit positions for this field are assigned to different rates, with bit positions 0, 1, 2, 3, 4, 5, 6, 7 and 8 being used to represent, for example, 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050 and 44,100 Samples Per Second (SPS), respectively, and bits 9 through 15 being reserved for future use or for alternative rates as needed, so they are currently set to '0'. Setting the bit value of one of the bits to '1' indicates that the particular sampling rate is supported, and setting the bit to '0' indicates that the sampling rate is not supported. If no microphone is connected, each bit of the microphone sample rate capability bits is set equal to zero.

The content protection type field (2 bytes) contains a set of flags to indicate the digital content protection types supported by the display. Presently, bit position 0 is used to indicate the support of DTCP and bit position 1 is used to indicate the support of HDCP, while bit positions 2 through 15 are reserved for use by other protection schemes or are available so they are presently set to zero.

G. Data packet relating to display request and status

The reverse link request field (3 bytes) specifies the number of bytes required by the display on the reverse link in the next sub-frame to send information to the host.

The CRC error count field (1 byte) indicates how many CRC errors have occurred since the beginning of the media frame. The CRC count is reset when a sub-frame header packet with a sub-frame count of zero is sent. This value typically saturates at 255 if the actual number of CRC errors exceeds 255.

The capability change field uses 1 byte to indicate a change in display capability. This may occur if the user connects a peripheral device such as a microphone, keyboard or display or for other reasons. When bits [7:0] are equal to 0, then there is no change in capability since the last display capability packet was sent out. However, when bits [7:0] are equal to 1 through 255, the capabilities have changed. The display capability data packet is examined to determine new display characteristics.

H. Transmitting data packets with respect to bit blocks

The window top left coordinate X-value and Y-value fields both use 2 bytes to specify the X and Y values of the coordinates of the top left corner of the window to be moved. The window width and height fields both use 2 bytes to specify the width and height of the window to be moved. The window X and Y move fields each use 2 bytes for specifying the number of pixels for the window to move horizontally and vertically, respectively. Typically, the coordinates are configured such that a positive value of X causes the window to move to the right, a negative value causes it to move to the left, and a positive value of Y causes the window to move downward and a negative value causes it to move upward.

I. Filling data packets with respect to bitmap regions

The window top left coordinate X and Y values fields both use 2 bytes for X and Y values that illustrate the coordinates of the top left corner of the window to be filled. The window width and height fields (each 2 bytes) are used to illustrate the width and height of the window to be filled. The video data format descriptor field (2 bytes) specifies the format of the pixel region fill value. The format is the same as the same field in the video stream packet. The pixel region fill value field (4 bytes) contains the pixel values to be filled into the window specified by the field. The format of this pixel is specified in the video data format descriptor field.

J. Filling data packets with respect to bitmap patterns

The window top left coordinate X and Y values fields both use 2 bytes to specify the X and Y values of the top left coordinate of the window to be filled. The window width and height fields (each 2 bytes) are used to illustrate the width and height of the window to be filled. The pattern width and pattern height fields (each 2 bytes) are used to illustrate the width and height of the fill pattern, respectively. The 2-byte video data format descriptor field specifies the format of the pixel region fill value. Fig. 11 illustrates how a video data format descriptor is encoded. The format is the same as the same field in the video stream packet.

The parameter CRC field (2 bytes) contains the CRC of all bytes from the packet length to the video format descriptor. If this CRC fails to check, the entire packet is discarded. The pattern pixel data field contains the original video information for specifying the fill pattern specified by the video data format descriptor. The data is packed into bytes and the first pixel of each row must be byte aligned. The fill pattern data is transmitted one line at a time. The pattern pixel data CRC field (2 bytes) contains only the CRC of the pattern pixel data. If this CRC fails to check, the pattern pixel data may still be used, but the CRC error count is increased.

K. Communication link data path data packet

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

The communication link data field contains the raw data from the communication channel. This data is merely passed on to the computing device in the display.

The communication link data CRC field (2 bytes) contains only a 16-bit CRC of the communication link data. If this CRC fails to check, the communication link data may still be used or still be useful, but the CRC error count is increased.

Request packet for interface type switch

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 manner. If the value of bit 7 is equal to '0', then the type switch request is for the forward link, and if equal to '1', then the type switch request is for the reverse link. Bits 6 through 3 are reserved for future use and are typically set to zero. Bits 2 to 0 are used to define the type of interface to be used, a value of 1 means switching to type I mode, a value of 2 means switching to type II mode, a value of 3 means switching to type III mode, and a value of 4 means switching to type IV mode. The values '0' and 5 to 7 are reserved for future use in identifying alternative modes or combinations of modes.

Acknowledge packet on interface type

The interface type field (1 byte) has a value for confirming a new interface type to be used. The value in this field specifies the interface type in the following manner. If the value of bit 7 is equal to '0', then the type switch request is for the forward link, and conversely, if equal to '1', then the type switch request is for the reverse link. Bit positions 6 through 3 are now reserved for designating other handover types as needed and are typically set to zero. However, bit positions 2 to 0 are used to define the type of interface to be used, where a value of '0' indicates negative, or the requested switch cannot be performed, and values of '1', '2', '3' and '4' indicate switching to type I, type II, type III and type IV modes, respectively. The values 5 to 7 are reserved to be used as optional identification of the mode as required.

Switching data packet with respect to execution type

The 1 byte interface type field indicates the new interface type to be used. The value present in this field specifies the interface type by first using the value of bit 7 to determine whether to type switch the forward or reverse link. A value of '0' indicates that the type handover request is for the forward link, and a value of '1' indicates that the type handover request is for the reverse link. Bits 6 through 3 are reserved for future use and are typically set to a value of zero. However, bits 2 to 0 are used to define the type of interface to be used, and values 1, 2, 3 and 4 specify switching to type I, type II, type III and type IV modes, respectively. The values 0 and 5 to 7 of these bits are reserved for future use.

Enabling packets for forward audio channels

The audio channel enable mask field (1 byte) contains a set of flags to indicate which audio channels are to be enabled in the client. A bit set to 1 enables the corresponding lane and a bit set to zero disables the corresponding lane. Bits 0 through 5 indicate channels 0 through 5, respectively, which are centered at the front left, front right, back left, back right, front, and subwoofer channels. Bits 7 through 6 are reserved for future use while normally being set to zero.

Data packet relating to reverse audio sampling rate

The audio sample rate field (1 byte) specifies the digital audio sample rate. The values of this field are assigned to different rates, with values 0, 1, 2, 3, 4, 5, 6, 7 and 8 being used to indicate 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050 and 44,100 Samples Per Second (SPS), respectively, and the values 9 through 254 are reserved for use at alternative rates as needed, 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 samples. When bits [1:0] are equal to '0', the digital audio samples are in a linear format, when they are equal to 1, the digital audio samples are in a μ -law format, and when they are equal to 2, the digital audio samples are in an A-law format. Bits [7:2] are reserved for alternative use to indicate audio format as needed and are typically set equal to zero.

Protecting overhead packets with respect to digital content

The content protection type field (1 byte) specifies the digital content protection method used. A value of '0' indicates Digital Transmission Content Protection (DTCP), and a value of 1 indicates a high-bandwidth digital content protection system (HDCP). The value range of 2 to 255 is not specified at present, but is reserved for optional protection schemes as required. The content protection overhead message field is a variable length field that contains the content protection message sent between the host and the client.

Enable data packet for transparent color

The transparent color enable field (1 byte) specifies the case where the transparent color mode is enabled or disabled. If bit 0 is equal to 0, then the transparent color mode is disabled, if equal to 1, then the transparent color mode is enabled, and the transparent color is specified by the following two parameters. Bits 1 through 7 of this byte are reserved for future use and are typically set equal to zero.

The video data format descriptor field (2 bytes) specifies the format of the pixel region fill value. Fig. 11 illustrates how a video data format descriptor is encoded. The format is typically the same as the same field in a video stream packet.

The pixel region fill value field uses 4 bytes to assign to the pixel values to be filled into the window specified above. The format of this pixel is specified in the video data format descriptor field.

Data packet for round trip delay measurement

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

The all-zero field (1 byte) contains zeros in order to ensure that all MDDI _ Data signals are in a zero state before the line drivers are disabled during the first guard time period.

The guard time 1 field (8 bytes) is used to allow the MDDI _ Data line driver in the host to be disabled before the line driver in the client (display) is enabled. During bit 0 of guard time 1, the host disables the MDDI _ Data line driver, and the display enables its line driver immediately after the last bit of guard time 1.

The measurement period field is a 512 byte window for allowing the display to respond with 0xff, 0x0 at half the data rate used on the forward link. This rate corresponds to a reverse link rate divisor of 1. The display returns this response immediately at the beginning of the measurement period. The host receives this response at the time when the precise link round trip delay has elapsed after the first bit of the measurement period started at the host. The MDDI _ Data line driver in the display is disabled immediately before and after the 0xff, 0x00 response from the display.

The value in the guard time 2 field (8 bytes) allows the client MDDI _ Data line driver to be disabled before enabling the line driver in the host. The guard time 2 is always present, but is only needed when the round trip delay is at a maximum amount, which can be measured in a measurement period. During bit 0 of guard time 2, the guest disables its line driver, and immediately after the last bit of guard time 2, the host enables its line driver.

The driver re-enable field (1 byte) is set equal to zero to ensure that all MDDI _ Data signals are re-enabled before the packet length field of the next packet.

Calibration data packet for forward link deviation

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

The calibration Data sequence field contains a 512-byte Data sequence for the MDDI _ Data signal to toggle every Data cycle. During processing of the calibration Data sequence, the MDDI host controller sets all MDDI _ Data signals equal to the strobe signal. When the calibration Data sequence field is received by the client display, the display clock recovery circuit should recover the Data clock using only the MDDI _ Stb instead of the exclusive or of the MDDI _ Stb and MDDI _ Data 0. Depending on the exact phase of the MDDI _ Stb signal at the beginning of the calibration data sequence field, the calibration data sequence will typically be one of the following based on the type of interface being used when sending this data packet:

Form I-0 xaa, 0xaa … … or 0x55, 0x55 … …

Form II-0 xcc, 0xcc … … or 0x33, 0x33 … …

Form III-0 xf0, 0xf0 … … or 0x0f, 0x0f … …

Type IV-0 xff, 0x00, 0xff, 0x00 … … or 0x00, 0xff, 0x00, 0xff … …

Examples of possible MDDI _ Data and MDDI _ Stb waveforms for type I and type II interfaces are shown in fig. 62A and 62B, respectively.

XVII. end word

While various embodiments of the present invention have been described, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (70)

1. A digital data interface for transferring digital presentation data at a high rate between a host device and a client device via a communication path, comprising:

a plurality of data packet structures linked together to form a communication protocol for communicating a preselected set of digital control and presentation data between the host and client devices via said communication path; and

at least one link controller residing in the host device, coupled to the client via the communication path, configured to generate, transmit, and receive data packets forming the communication protocol, and to form digital presentation data into one or more types of data packets.

2. The interface of claim 1, further comprising the data packets grouped together within media frames, wherein the media frames are communicated between the host and client and have a predefined fixed length, and the predetermined number of the data packets have different and variable lengths.

3. The interface of claim 1, further comprising a sub-frame header packet at the beginning of a transfer packet from the host.

4. The interface of claim 1, wherein the link controller is a host link controller, and further comprising at least one client link controller residing in the client device coupled to the host via the communication path, configured to generate, transmit, and receive data packets forming the communication protocol, and to form digital presentation data into one or more types of data packets.

5. The interface of claim 1, further comprising one or more video stream packets for video type data and audio stream packets for audio type data for transferring data from the host to the client via a forward link for presentation to a client user.

6. The interface of claim 2, further comprising:

a plurality of transfer modes, each transfer mode allowing a different maximum number of data bits to be transferred in parallel over a given period of time, each mode being selectable by negotiation between the host and client link drivers; and

wherein the transmission mode is dynamically adjusted between the modes during transmission of data.

7. The interface of claim 1, further comprising a plurality of packets capable of being used to transfer video information selected from the group consisting of color mapping, bit block transfer, bitmap area fill, bitmap pattern fill, and transparent color enable type packets.

8. The interface of claim 1, further comprising filler type packets generated by the host to occupy periods of forward link transmission that are free of data.

9. The interface of claim 1, further comprising user-defined stream type packets for conveying interface user-defined data.

10. The interface of claim 1, further comprising a link shutdown type packet for transmission by said host to said client to terminate data transfer in either direction via said communication path.

11. The interface of claim 1, further comprising means for the client to wake the host from a sleep state.

12. A method for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, comprising:

generating one or more of a plurality of predefined packet structures and linking them together to form a predefined communication protocol;

communicating a preselected set of digital control and presentation data between the host and the client device via the communication path using the communication protocol;

coupling at least one host link controller residing in the host device to the client device via the communication path, the host link controller configured to generate, transmit, and receive data packets forming the communication protocol, and form digital presentation data into one or more types of data packets; and is

Transmitting data in the form of data packets via the communication path using the link controller.

13. The method of claim 12, further comprising grouping the packets together in media frames for communication between the host and client, the media frames having a predefined fixed length, and the predetermined number of the packets having different and variable lengths.

14. The method of claim 12, further comprising initiating transmission of a data packet from the host using a sub-frame header type data packet.

15. The method of claim 12, further comprising transferring information bi-directionally between the host and client via the communication link.

16. The method of claim 12, further comprising at least one client link controller residing in the client device coupled to the host device via the communication path and configured to generate, transmit, and receive data packets forming the communication protocol and to form digital presentation data into one or more types of data packets.

17. The method of claim 16, wherein the host link controller comprises one or more differential line drivers; and the client link controller includes one or more differential line receivers coupled to the communications path.

18. The method of claim 12, further comprising requesting, by a host link controller, display capability information from the client to determine what types of data and data rates the client can support via the interface.

19. The method of claim 12, further comprising using a USB data interface as part of the communication path by each of the link controllers.

20. The method of claim 12, wherein each of the data packets includes a packet length field, one or more packet data fields, and a cyclic redundancy check field.

21. The method of claim 13, further comprising:

negotiating between the host and client link controllers the use of one of a plurality of transfer modes in each direction, each mode allowing a different maximum number of data bits to be transferred in parallel over a given period of time; and is

Dynamically adjusting between the transfer modes during transfer of data.

22. The method of claim 12, further comprising using one or more of the plurality of packets to transfer video information selected from the group consisting of color mapping, bit block transfer, bitmap area fill, bitmap pattern fill, and transparent color enable type packets.

23. The method of claim 12, further comprising generating, by the host, a filler type packet to occupy a period of forward link transmission without data.

24. The method of claim 12, further comprising terminating data transfer in either direction via the communication path using a link shutdown type packet transmitted by the host to the client.

25. The method of claim 12, further comprising waking the host from a sleep state through communication with the client.

26. Apparatus for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, comprising:

at least one host link controller disposed in said host device for generating and linking together one or more of a plurality of predefined packet structures to form a predefined communication protocol and for communicating a preselected set of digital control and presentation data between said host and said client devices via said communication path using said communication protocol;

at least one client controller disposed in the client device and coupled to the host link controller via the communication path; and is

Each link controller is configured to generate, transmit, and receive data packets forming the communication protocol, and to form digital presentation data into one or more types of data packets.

27. The apparatus of claim 26, wherein the host controller comprises a state machine.

28. The apparatus of claim 26, wherein the host controller comprises a general purpose signal processor.

29. The apparatus of claim 26, further comprising a sub-frame header type packet located at the beginning of a packet transmitted from the host.

30. The apparatus of claim 26, wherein the link controller is configured to transfer information bi-directionally between the host and client devices via the communication link.

31. The apparatus of claim 30, wherein the host controller comprises one or more differential line drivers; and the client receiver comprises one or more differential line receivers coupled to the communication path.

32. The apparatus of claim 26 further comprising video stream type packets for video type data and audio stream type packets for audio type in transferring data from the host to the client for presentation to a client user.

33. The apparatus of claim 26, further comprising one or more reverse link encapsulation type packets for communicating data from the client to the host.

34. The apparatus of claim 33 further comprising at least one display capability type packet for communicating display or rendering capabilities from a client link controller to said host link controller.

35. The apparatus of claim 26, wherein the packets each comprise a packet length field, one or more packet data fields, and a cyclic redundancy check field.

36. The apparatus of claim 26 wherein the host and client link controllers are configured to use one of a plurality of transfer modes in each direction, each allowing a different maximum number of data bits to be transferred in parallel over a given period of time; and can be dynamically adjusted between the transfer modes during the transfer of data.

37. The apparatus of claim 26, further comprising one or more of a plurality of packets for transmitting video information selected from the group of color mapping, bit block transmission, bitmap area stuffing, bitmap pattern stuffing, and transparent color enable type packets.

38. The apparatus of claim 26, further comprising filler type packets transmitted by the host to occupy periods of forward link transmission that are devoid of data.

39. The apparatus of claim 26, wherein the host controller is configured to transmit a link shutdown type packet to the client module for terminating data transmission in either direction via the communication path.

40. A computer program product for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user's electronic system, comprising:

a computer usable medium having computer readable program code means embodied in said medium for causing an application program to execute on said computer system, said computer readable program code means comprising:

computer readable first program code means for causing said computer system to generate one or more of a plurality of predefined packet structures and link them together to form a predefined communication protocol;

computer readable second program code modules for causing said computer system to communicate a preselected set of digital control and presentation data between said host and said client device via said communication path using said communication protocol;

Computer readable third program code modules for causing the computer system to couple at least one host link controller disposed in the host device to at least one client controller disposed in the client device via the communication path, the link controller configured to generate, transmit and receive data packets forming the communication protocol, and form digital presentation data into one or more types of data packets; and

computer readable fourth program code means for causing said computer system to transmit data in data packets over said communication path using said link controller.

41. Apparatus for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, comprising:

means for generating one or more of a plurality of predefined packet structures and linking them together to form a predefined communication protocol;

means for communicating a preselected set of digital control and presentation data between the host and the client device via the communication path using the communication protocol;

a module for coupling at least two link controllers together via the communication path, one in each of the host and client, and each configured to generate, transmit and receive data packets forming the communication protocol, and to form digital presentation data into one or more types of data packets; and

Means for transmitting data in the form of data packets via the communication path using the link controller.

42. The apparatus of claim 41 further comprising means for initiating transmission of a data packet from the host using a sub-frame header type data packet.

43. The apparatus of claim 41, further comprising means for transferring information bi-directionally between the host and client via the communication link.

44. The apparatus of claim 41, further comprising means for requesting display capability information from a client through a host link controller to determine what types of data and data rates the client can support via the interface.

45. The apparatus of claim 44 further comprising means for communicating display or rendering capabilities from a client link controller to the host link controller using at least one display capability type packet.

46. The apparatus of claim 42, further comprising:

means for negotiating between the host and client link drivers use of one of a plurality of transfer modes in each direction, each mode allowing a different maximum number of bits of data to be transferred in parallel over a given period of time;

And means for dynamically adjusting between the transfer modes during transfer of data.

47. The apparatus of claim 41, further comprising means for transmitting video information selected from the group of color mapping, bit block transmission, bitmap area stuffing, bitmap pattern stuffing, and transparent color enable type packets using one or more of a plurality of packets.

48. A processor of an electronic system for transferring digital data at a high rate between a host device and a client device via a communication path, the processor configured to generate one or more of a plurality of predefined packet structures and link them together to form a predefined communication protocol; forming the digital presentation data into one or more types of data packets; communicating a preselected set of digital control and presentation data between the host and the client device via the communication path using the communication protocol; and transmitting data in the form of data packets via the communication path.

49. A state machine for use in an electronic system that transfers digital data at a high rate between a host device and a client device via a communication path, the state machine configured to have a synchronization state of at least one asynchronous frame state, at least two synchronization states of which synchronization states are obtained, and a synchronization state of at least three in-synchronization states.

50. A state machine for use in obtaining synchronization in an electronic system that communicates digital data at a high rate between a host device and a client device via a communication path, the state machine configured to have at least one synchronization state that obtains a synchronization state and a synchronization state of at least two in-synchronization states.

51. The state machine of claim 50, wherein one condition for transitioning between the acquiring synchronization state and the first in-synchronization state is a detected presence of a synchronization pattern in the communication link.

52. The state machine of claim 51, wherein a second condition for transitioning between the acquiring synchronization state and the first in-synchronization state is detecting the presence of a sub-frame header packet and a good CRC value at a frame boundary.

53. The state machine of claim 50, wherein one condition to transition between the first in-sync state and the obtaining the sync state is detecting an absence of a synchronization pattern or a presence of a bad CRC value at a subframe boundary.

54. The state machine of claim 50, wherein one condition to transition between the first in-sync state and the second in-sync state is detecting an absence of synchronization pattern or a presence of a bad CRC value at a subframe boundary.

55. The state machine of claim 50, wherein one condition for transitioning between the acquiring synchronization state and the first in-synchronization state is detecting the presence of a synchronization pattern in the communication link and detecting the presence of a good packet CRC value.

56. The state machine of claim 50, wherein a condition for transitioning between the first in-sync state and the get-sync state is a detection of a bad CRC value in the data packet.

57. A state machine for use in obtaining synchronization in an electronic system that transfers digital data at a high rate between a host device and a client device via a communication path, the state machine configured to have at least one synchronization state that obtains a synchronization state and a synchronization state that is at least two in-synchronization states, wherein a direct transition between a first in-synchronization state and an obtaining a synchronization state is conditioned upon the detection of a bad CRC value in any of a series of data packets.

58. The state machine of claim 57, wherein a direct transition between the first in-sync state and the obtaining the sync state is conditioned upon detecting that the unique word does not occur when its arrival is expected.

59. The method of claim 26, further comprising waking up a communication link by the host by driving a data line to a high state for at least 10 clock cycles and beginning transmission of a strobe signal in a manner as if the data line were zero.

60. The method of claim 59, further comprising driving a data line to a low state by the host for 50 clock cycles during continued transmission of a strobe signal after the host has driven the data line to a high state for 150 clock cycles.

61. The method of claim 59, further comprising initiating transmission by the host of a first sub-frame header packet.

62. The method of claim 60, further comprising counting, by the client, at least 150 consecutive clock cycles of the data line in the high state followed by at least 50 consecutive clock cycles of the data line in the low state.

63. The method of claim 62, further comprising searching, by the client, for a unique word of a first subframe.

64. The method of claim 60, further comprising ceasing to drive the data line high after the client counts 70 consecutive clock cycles of the data in the high state.

65. The method of claim 64, further comprising counting, by the client, another 80 consecutive clock cycles of the data line in the high state to reach 150 clock cycles of the data line in the high state and looking for 50 clock cycles of the data line in the low state and looking for the unique word.

66. The method of claim 26, further comprising counting a number of clock cycles that occur by sampling a data line on rising and falling edges during a reverse timing packet until a 1 is taken by the host.

67. A method of transmitting error codes in a communication system in which digital data is transmitted between a host device and a client device via a communication path in the form of data packets having a CRC value, the method comprising detecting the presence of an error, selecting a predetermined error code corresponding to the error, and overwriting the CRC value with the code.

68. The method of claim 67 further comprising overwriting the CRC value in successive data packets transmitted until the error is corrected.

69. A method of transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, comprising:

generating one or more of a plurality of predefined packet structures, each including at least one CRC field, and linking them together to form a predefined communication protocol;

communicating a preselected set of digital control and presentation data between the host and the client device via the communication path using the communication protocol;

Coupling at least one host link controller residing in the host device to the client device via the communication path, the host link controller configured to generate, transmit, and receive data packets forming the communication protocol, and form digital presentation data into one or more types of data packets;

transmitting data in the form of data packets via the communication path using the link controller;

detecting the presence of an error of the communication link;

selecting a predetermined error code corresponding to the error; and rewriting the CRC value with the code.

70. The method of claim 69, further comprising rewriting the CRC values in consecutive packets transmitted until the error is corrected.