MXPA06005403A - High data rate interface with improved link control - Google Patents

Abstract

A data Interface for transferring digital data between a host and a client over a communication path using packet structures linked together to form a communication protocol for communicating a pre-selected set of digital control and presentation data. The signal protocol is used by link controllers configured to generate, transmit, and receive packets forming the communications protocol, and to form digital data into one or more types of data packets, with at least one residing in the host device and being coupled to the client through the communications path. The interface provides a cost-effective, low power, bi-directional, high-speed data transfer mechanism over a short-range"serial"type data link, which lends itself to implementation with miniature connectors and thin flexible cables which are especially useful in connecting display elements such as wearable micro-displays to portable computers and wireless communication devices.

Description

ELEVATED DATA SPEED INTERFACE FIELD OF THE INVENTION The embodiments of the invention in this description relate to a protocol and a process of a digital signal for communicating or transferring signals between a host device and a client device at high data rates. More specifically, the description relates to a technique for transferring multimedia or other types of digital signals from a host or controlling device to a client device for presentation or deployment by an end user using a data rate transfer mechanism high low power that has internal and external device applications.

BACKGROUND OF THE INVENTION Computers, products related to electronic games and various video technologies (for example, DVDs and high-definition VCRs) have advanced significantly over the past few years to provide their presentation of still images of a growing number high resolution, video, video on demand and graphics, even when they include some types of text, for the end users of such equipment. These advances in turn required the use of higher-resolution electronic display devices such as high-definition video monitors, HDTV monitors, or specialized imaging elements. Combining such visual images with quality or high-definition audio data, such as when used in CD-type playback, DVDs, surround sound, and other devices that also have associated audio signal outputs, is used to create a more realistic multimedia experience, with rich or true content for an end user. In addition, high-quality, highly mobile sound systems and music transport mechanisms, such as 1P3 players, have been developed for audio presentations only for end users. This has resulted in an increase in the expectations of typical users for commercial electronic devices, from computers to televisions and even telephones, which are now customized for and from which high-quality or high-quality output is expected. In a typical video presentation scenario, involving an electronic product, video data is typically transferred using current techniques at a rate that could be best determined as slow or medium, which is in the order of one to tens of kilobits per second . These data are either stored in an intermediate form, or stored in transient or long-term memory devices, for a delayed (later) reproduction in a desired display device. For example, images can be transferred "through" or using the Internet using a program resident on a computer that has a modem or other type of Internet connection device, to receive or transmit useful data in the digital representation of an image . A similar transfer can be carried out using wireless devices such as laptops equipped with wireless modems, or wireless personal data assistants (PDAs), or cordless telephones. Once received, the data is stored locally in memory elements, circuits or devices, such as a RAM or a non-volatile memory, including internal or external storage devices such as small-sized hard drives, for playback. Depending on the amount of data and the image resolution, playback may start relatively quickly, or may occur with a long-term delay. That is, in some cases, the presentation of the image allows some degree of real-time reproduction for very small or low resolution images that do not require a lot of data, or that use some type of intermediate storage, so that after a small delay, part of the material is present while more material is being transferred. Provided that there are no interruptions in the transfer link, or interference from other systems or users in relation to the transfer channel being used, once the presentation begins, the transfer is reasonably transparent to the end user of the deployment device . Naturally, when multiple users share a single communication path, such as a wired Internet connection, the transfers may be interrupted or reduced more than desired. The data used to create either still images or moving video is often compressed using one or several well-known techniques such as those specified by the Joint Group of Experts in Photography (JPEG), the Motion Picture Expert Group (MPEG), and other organizations of well-known standards or companies in multimedia, computing and communications industries to accelerate the transfer of data through a communication link. This allows a faster transfer of images or data by using a smaller number of bits to transfer a certain amount of information. Once the data is transferred to a "local" device such as a computer having a storage mechanism such as a memory, or magnetic or optical storage elements or to other receiving devices, the resulting information is decompressed (or reproduced) using special decoding players), and decoded if necessary, and prepared for proper presentation based on the available corresponding display resolution and control elements. For example, a typical video resolution for a computer in terms of on-screen resolution of X-by-Y pixels typically fluctuates from as low as 480x640 pixels, through 600x800 to 1024x1024, although a variety of other resolutions are generally possible, either as desired or necessary. The presentation of the image is also affected by the content of the image and the ability of video controllers determined to manipulate the image in terms of certain predefined color levels or color depth (bits per pixel used to generate colors) and intensities , and any additional auxiliary operations bits that are used. For example, a typical computer presentation would be anticipated from anywhere from about 8 to 32, or more, bits per pixel to represent different colors (shades and tints), although other values may be found. From the previous values, it can be seen that a certain screen image will require the transfer from anywhere from 2.45 Megabits (Mb) to approximately 33.55 Mb of data on the range from the lowest resolutions and typical depths. to the highest, respectively. When viewing video or moving type image at a rate of 30 frames per second, the amount of data required is approximately 73.7 to 1,006 Megabytes of data per second (Mbps), or approximately 9.21 to 125.75 Megabytes per second (MBps) ). In addition, it may be desirable to present audio data together with the images, such as for multimedia presentation, or as a separate high resolution audio presentation, such as CD-quality music. You can also use additional signals that have to do with interactive commands, controls or signals. Each of these options adds even more data to be transferred. In addition, the newer transmission techniques involve high definition (HD) television and movie recordings that can add even more data and control information. In any case, when it is desired to transfer high quality or high resolution image data and high quality audio data information or signals to an end user to create a rich content experience, a high data rate link between the presentation elements and the source or host device that is configured to provide such data types. Data rates of approximately 115 Kilobytes (KBps) or 920 Kilobits per second (Kbps) can be routinely handled by some modern serial interfaces. Other interfaces such as USB serial interfaces, can adjust data transfer at speeds as high as 12 MBps, and specialized high-speed transfers such as those configured using the 1394 standard from the Institute of Electrical and Electronics Engineers (IEEE) can occur at speeds in the order of 100 to 400 MBps. Unfortunately, those speeds fall short with the desired high data rates discussed above that are contemplated for use with future wireless data devices and other services to provide high resolution, rich content, output signals to control display devices. of portable or audio video.

This includes computers for business and other presentations, devices for games, etc. In addition, these interfaces require the use of a significant amount of a host or client's system and software to operate. Their software protocol stacks also create an enormously undesirable amount of ancillary operations, especially where wireless mobile devices or telephone applications are contemplated. Such devices have severe limitations of memory and electric power consumption, as well as a computational capacity already put to the test. In addition, some of these interfaces use bulky cables which are too heavy and unsatisfactory for mobile applications aimed at being highly aesthetic, complex connectors which add costs, or simply consume too much electrical power. There are other known interfaces such as the Analog Video Graphics Adapter (VGA), Interactive Digital Video (DVI) or Gigabit Video Interface Interfaces (GVIF). The first two of these are parallel type interfaces that process data at higher transfer rates, but they also use heavy cables and consume huge amounts of electrical energy, in the order of several watts. None of these features is affordable for use with portable consumer electronic devices. Even the third interface consumes too much electrical power and uses expensive or bulky connectors. For some of the above interfaces, and other very high speed data systems / protocols by transfer mechanisms associated with data transfers for fixed installation computing equipment, there is another major disadvantage. Substantial amounts of electrical power and / or operation at high current levels are also required to adjust the desired data transfer rates. This greatly reduces the utility of such techniques for highly mobile, consumer-oriented products. Generally, to adjust such data transfer rates using alternatives such as fiber optic connections and transfer elements, it also requires a number of converters and additional elements that introduce much more complexity and cost, than those desired for a properly oriented product. towards a commercial consumer. Apart from the generally expensive nature of optical systems so far, their electrical power requirements and complexity prevent the general use of portable applications of low electrical power, and low weight. What the portable, wireless or mobile applications industry has lacked is a technique that provides a high-quality presentation experience, whether based on audio, video or multimedia, for highly mobile end users. That is, when using laptops, cordless phones, PDAs, or other highly mobile communication devices or devices, the current video and audio presentation systems or devices that are used simply can not provide output at the high quality level. wanted. Often, the perceived quality that is needed is the result of high data rates that can not be obtained and that are necessary to transfer the high quality presentation data. These can include either transfer to more efficient, loaded or advanced external feature devices, for presentation to an end user, or transfer between hosts and internal clients to portable devices such as computers, gaming machines, and wireless devices such as mobile phones. . In this last case, there have been huge advances that have been made by adding higher resolution internal video screens, and other specialty input and / or output devices and connections to wireless devices such as the so-called third generation phones, and for the so-called laptop computers. However, buses and internal data connections which may include bridging through the rotation or sliding of articulation structures or the like to a joint which are mounted or connected to video screens or other elements to the main housing where the host and / or various control elements and output components reside. It is very difficult to build high total throughput data transfer interfaces that use prior techniques that may require up to 90 or more drivers, to achieve the desired total throughput, in such wireless phones, as an example. This presents many manufacturing issues, which are expensive and reliability challenges to overcome. Such issues and requirements have also been seen in fixed-location installations where communication or computing-type devices, as an example, are added to consumer appliances and other devices to provide advanced data capabilities, Internet and transfer connections of data, or integrated entertainment. Another example would be airplanes and buses where the individual audio and video presentation screen is mounted on the seat backs. However, in such situations it is often efficient and easily usable to provide service by having the main storage, processing or communication control elements located at a distance from visible displays or audio outputs with a link or interconnection channel for the presentation of the information. This link will require the handling of a significant amount of data to achieve the desired total throughput, as discussed above. Therefore, a new transfer mechanism is needed to increase the total data throughput between the host devices that provide the data and the client deployment devices or the elements that present an output to the end users. Such novel transfer mechanisms have been proposed in US Patent Applications Serial Nos. 10 / 020,520 and 10 / 236,657, both entitled "Generation and Implementation of a Communication Protocol and Interface for a High Data Rate Signal Transfer" , now granted, which are assigned to the assignee of the present invention and are incorporated herein by reference. In addition, Application Serial No. 10 / 860,116 entitled "Generation and Implementation of a Signal Protocol and Interface for Higher Data Rates". The techniques discussed in these applications can greatly improve the transfer speed for huge amounts of data in high-speed data signals. However, the demands for more and more data speeds increase, especially as a relation to video presentations, they continue to grow. Even with other ongoing developments in data signal technology, there is still a need to take care of faster transfer speeds, improved communication link efficiencies, and more powerful communication links. Therefore, there is a continuing need to develop a new or improved transfer mechanism, which is necessary to increase the total data throughput between the host and client devices.

SUMMARY OF THE INVENTION The above disadvantage and others, which exist in the art, are addressed by the embodiments of the invention in which a new protocol and means of data transfer, method and mechanism for transferring data between a host device and a client receiving device at high data rates.

The embodiments of the invention are directed towards a Mobile Data Digital Interface (MDDI) for transferring digital data at a high speed between a host device and a client device through a communication path employing a plurality or series of communication structures. package to form a communication protocol to communicate a pre-selected set of digital control and presentation data between the host and client devices. The signal communications protocol or link layer are used by a physical layer of the host or client link controllers. At least one link controller residing in the host device is coupled to the client device through a communications path or link, and is configured to generate, transmit and receive packets that form the communications protocol, and to form digital presentation data in one or more types of data packages. The interface provides a bi-directional transfer of information between the host and the client, which may reside within a common global hosting or support structure. The implementation is generally all digital in nature with the exception of differential controllers and receivers that can be easily implemented in a digital CMOS chip, which requires a few such as 6 signals, and operates at almost any data rate that is convenient for the designer of the system. The physical layer and simple link protocol makes it easy to integrate, and this simplicity plus a state of hibernation enables the portable system to have a very low system power consumption. To help in the use and acceptance, the interface will increase the cost of a device very little, it will allow a very small energy consumption while allowing the energy deployments through the interface to use standard battery voltages, and can adjust devices that have a physical size that can be put in your pocket. The interface is scalable to support resolutions beyond HDTV, supports simultaneous stereo video and 7.1 audio for a deployment device, performs conditional updates for any region of the screen, and supports multiple types of data in both directions. In. Further aspects of the embodiments of the invention, at least one client link controller, or client receiver, is arranged in the client device and coupled to the host device through the communications path or link. The client link controller is also configured to generate, transmit and receive packets that form the communications protocol, and to form the data of the digital presentation in one or more types of data packets. Generally, the host controller or link employs a state machine to process data packets used in commands or certain types of signal preparation and request processing, may use a slower general purpose processor to manipulate the data and some of the the less complex packages used in the communication protocol. The host controller comprises one or more differential line controllers; although the receiver of the client comprises one or more differential in-line receivers coupled to the communication path. The packets are grouped together within media frames that communicate between the host and client devices that have a pre-defined fixed length with a pre-determined number of packets having different variable lengths. The packets each comprise a packet length field, one or more packet data fields, and a cyclic redundancy check field. A Sub-frame Header Pack is transferred or placed at the beginning of the other packet transfers of the host link controller. One or more Video Stream type packets and Audio Stream type packets are used by the communication protocol to transfer video type data and audio type data, respectively, from the host to the client through a non return link for presentation to a user of the client device. One or more packets of type Return Link Encapsulation are used by the communication protocol to transfer data from the client device to the host link controller. This transfer in some modes includes the transfer of data from internal controllers that have at least one MDDI device for internal video screens. Other modes include transfer to the internal sound system, and transfer from various input devices that include joysticks and complex keyboards for internal host devices. Filling type packets are generated by the host link controller to occupy transmission periods on the non-return link that do not have data. A plurality of other packets are used by the communications protocol to transfer video information. Such packages include the Color Map, Bit Block Transfer, Bit Map Area Fill, Bitmap Pattern Fill and Transparent Color Enable type packages. The User-defined Stream type packets are used by the communications protocol to transfer data defined by the user interface. Keypad data and Signal Device Data type packets are used by the communication protocol to transfer data to or from the user input devices associated with the client device. A link-type packet is used by the communication protocol to terminate the transfer of data in any direction through the communication path. The communication path generally comprises or employs a cable that has a series of four or more conductors and a shield. Furthermore, if desired, printed cables or conductors can be used, with some resident or flexible substrates. The host link controller deploys the information capabilities of the client device to determine what type of data and data rates the client is able to adjust through the interface. The client link controller communicates with the deployment or presentation capabilities for the host link controller that uses at least one Client Capability type package. Multiple transfer modes are used by the communication protocol with each allowing the transfer of different maximum bit numbers of data in parallel over a given period of time, with each mode selectable by negotiation between the link controllers of host and the client. These transfer modes can be dynamically adjusted during data transfer, and the same mode does not need to be used in the return link as they are used in the non-return link. In other aspects of some embodiments of the invention, the host device comprises a wireless communications device, such as a wireless telephone, a wireless PDA, or a portable computer having a wireless modem disposed therein. A typical device of the client comprises a portable video screen such as a micro-screen device, and / or a portable audio presentation system. In addition, the host may use the storage medium or elements to store the presentation or multimedia data to be transferred to be presented to a client device user. In still other aspects of some modalities, the host device comprises a controller or a device for controlling the communication link with controllers as described below that resides within a portable electronic device such as a wireless communications device, such as a cordless telephone, a wireless PDA, or a laptop. A typical client device in this configuration comprises a client circuit or an integrated circuit or a module coupled to the host and residing within the same device, and to an internal video display such as a high resolution screen for a mobile telephone and / or a portable audio presentation system, or in some alternative type of system or input device.

BRIEF DESCRIPTION OF THE DRAWINGS The following describes in detail further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, with reference to the accompanying drawings. In the drawings, similar reference numbers generally indicate identical, functionally similar, and / or structurally similar processing elements or steps, and the pattern in which a first element as indicated by the digit or digits further to the left in the reference number. FIGURE 1A illustrates a basic environment in which the embodiments of the invention could operate including the use of a micro-screen device, or a projector, together with a laptop or other data processing device. FIGURE IB illustrates a basic environment in which embodiments of the invention could operate including the use of a micro-display device or projector, and audio presentation elements used in conjunction with a wireless transceiver. FIGURE 1C illustrates a basic environment in which embodiments of the invention could operate including the use of internal display or audio display devices used in a portable computer. FIGURE ID illustrates a basic environment in which the embodiments of the invention could operate including the use of internal display or audio display elements used in a wireless transceiver. FIGURE 2 illustrates the overall concept of a Mobile Digital Data Interface with a host and client interconnection. FIGURE 3 illustrates the structure of a packet useful for transferring data from a client device to a host device. FIGURE 4 illustrates the use of an MDDI link controller and the types of signals that pass between a host and a client through physical data link conductors for a mixed Type 1 interface. FIGURE 5 illustrates the use of a controller MDDI link and the types of signals that pass between a host and a client through physical data link conductors for the Type 2, 3, and 4 interfaces. FIGURE 6 illustrates the structure of frames and sub-frames used for implement the interface protocol. FIGURE 7 illustrates the general package structure used to implement the interface protocol. FIGURE 8 illustrates the format of a Sub-frame Header Pack. FIGURE 9 illustrates the format and content of a Filler Pack. FIGURE 10 illustrates the format of a Video Stream Package. FIGURES 11A-11E illustrate the format and content for the Video Data Format Descriptor used in FIGURE 10. FIGURE 12 illustrates the use of packaged and unpacked formats for the data. FIGURE 13 illustrates the format of an Audio Stream Package. FIGURE 14 illustrates the use of aligned byte and packed PCM data formats. FIGURE 15 illustrates the format of a Current Package Defined by the User. FIGURE 16 illustrates the format of a Color Map Package. FIGURE 17 illustrates the format of a Return Link Encapsulation Pack. FIGURE 18 illustrates the format of a Package of Customer capacity FIGURE 19 illustrates the format of a Keyboard Data Package. FIGURE 20 illustrates the Signal Device Data Package format. FIGURE 21 illustrates the format of a Link Break Package. FIGURE 22 illustrates the format of a Client Application Package and a State Package. FIGURE 23 illustrates the format of a Package of Transfer in Block of Bits. FIGURE 24 illustrates the format of a Bitmap Area Fill Pack. FIGURE 25 illustrates the format of a Bitmap Pattern Filling Packet.

FIGURE 26 illustrates the format of a Communication Channel Data Channel Package. FIGURE 27 illustrates the format of an Interface Type Transfer Request Package. FIGURE 28 illustrates the format of a Package of Type Interface Recognition. FIGURE 29 illustrates the format of an Execution Type Transfer Package. FIGURE 30 illustrates the format of a Package that enables the Audio Channel without Return. FIGURE 31 illustrates the format of a Return Audio Sample Rate Package. FIGURE 32 illustrates the format of a Package Over the Protection of Digital Content. FIGURE 33 illustrates the format of a Package that Enables Transparent Color. FIGURE 34 illustrates the format of an Outbound and Return Delay Measurement Package. FIGURE 35 illustrates the timing of events during the One-Time Return Measurement Package. FIGURE 36 illustrates a sample implementation of a CRC generator and a verifier useful for implementing the invention. FIGURE 37A illustrates the timing of the CRC signals of the apparatus of FIGURE 36 when sending data packets. FIGURE 37B illustrates the timing of the CRC signals for the apparatus of FIGURE 36 when receiving data packets. FIGURE 38 illustrates the processing steps for an application. Typical service without line conflict. FIGURE 39 illustrates the processing steps for a typical service request asserted after it has initiated the restart sequence of the link, which is in line conflict with the start of the link. FIGURE 40 illustrates how a data stream can be transmitted using a DATA-STB encoding. FIGURE 41 illustrates a system of electrical circuits useful for generating DATA and STB signals from the data input in the host, and then retrieving the data in the client. FIGURE 42 illustrates controllers and terminating resistors useful for implementing a modality. FIGURE 43 illustrates the steps and signal levels employed by a client to secure the service of the host and by the host to provide such a service.

FIGURE 44 illustrates the relative separation between the transitions in the DataO, other data lines (DataX), and the strobe lines (Stb). FIGURE 45 illustrates the presence of a response delay that can occur when a host disables the host controller after transferring a packet. FIGURE 46 illustrates the presence of a delay in the response that can occur when a host enables the host controller to transfer a packet. FIGURE 47 illustrates the relationship at the input of the host receiver between the timing of the data being transferred and the leading and trailing edges of the strobe pulses. FIGURE 48 illustrates the switching characteristics and the corresponding client exit delay developed by the timing of the return data. FIGURE 49 illustrates a high level diagram of the signal processing steps and the conditions by which synchronization using a state machine can be implemented. FIGURE 50 illustrates typical amounts of delay encountered for signal processing in the non-return and return paths in a system employing the MDDI. FIGURE 51 illustrates a marginal return and return delay measurement. FIGURE 52 illustrates the changes in data rate of the Return Link. FIGURE 53 illustrates a graphical representation of the values of the Return Speed Divider against a data rate of the non-return link. FIGURES 54A and 54B illustrate the steps that are carried out in the operation of an interface. FIGURE 55 illustrates a global view of the processing packets of the interface apparatus. FIGURE 56 illustrates the format of a Return Without Link Package. FIGURE 57 illustrates typical values for propagation delay and bias in a Type 1 Link interface. FIGURE 58 illustrates the Data, Stb and Recovery Timing of Measuring Time in a Type 1 Link for exemplary signal processing through the interface. FIGURE 59 illustrates typical values of delay and propagation bias in interfaces Type 2, Type 3 or Type 4.

FIGURES 60A, 60B and 60C illustrate different possibilities for the timing of two data signals and MDDI_Stb with respect to one another, which are ideal, early, and late, respectively. FIGURE 61 illustrates exemplary connectors of interface pin assignments used with Type I / Type 2 interfaces. FIGURES 62A and 62B illustrate possible waveforms of MDDI_Data and MDDI_Stb for both Type 1 and Type 2 interfaces, respectively. FIGURE 63 illustrates a high-level diagram of alternative signal processing stages and conditions by which synchronization can be implemented using a state machine. FIGURE 64 illustrates an exemplary relative timing between a series of cycles of timing and timing of various return link packet bits and divider values. FIGURE 65 illustrates an exemplary error code transfer processing FIGURE 66 illustrates an apparatus useful for error code transfer processing FIGURE 67A illustrates an error code transfer processing for a code overload.

FIGURE 67B illustrates an error code transfer processing for code reception. FIGURE 68A illustrates the processing steps for a wake-up call initiated by the host. FIGURE 68B illustrates the processing steps for a wake-up call initiated by the client. FIGURE 68C illustrates the processing steps for a wake-up call initiated by the host and the client with line conflict. FIGURE 69 illustrates the format of a VCP Feature Package Request. FIGURE 70 illustrates the format of a VCP Feature Response Package. FIGURE 71 illustrates the format of a List of VCP Feature Response. FIGURE 72 illustrates the format of a VCP Feature Package Kit. FIGURE 73 illustrates the format of a Valid Parameter Package Request. FIGURE 74 illustrates the format of a Valid Parameter Response Package. FIGURE 75 illustrates the format of an Alpha-Cursor Image Capability Package. FIGURE 76 illustrates the format of an Alpha-Cursor Transparency Map Package. FIGURE 77 illustrates the format of an Alpha-Cursor Image Shift Package. FIGURE 78 illustrates the format of an Alpha-Cursor .Video Current Package. FIGURE '79 illustrates the format of a Scaled Video Stream Capacity Pack. FIGURE 80 illustrates the format of a Video Scaled Stream Installation Package. FIGURE 81 illustrates the format of a Package of Recognition of Video Escalation Current. FIGURE 82 illustrates the format of a Video Scaled Stream Package. FIGURE 83 illustrates the format of a Request Specific Status Pack. FIGURE 84 illustrates the format of a Valid State Response List Package. FIGURE 85A illustrates the format of a Processing Delay Parameter Pack. FIGURE 85B illustrates the format of a Delay Parameter List Article. FIGURE 86 illustrates the format of a Personal Deployment Capability Package. FIGURE 87A illustrates the format of a Client Error Reporting Package.

FIGURE 87B illustrates the format of an Article in the Error Report List. FIGURE 88 illustrates the format of a Customer Identification Package. FIGURE 89 illustrates the format of a Package of Alternate Deployment Capacity. FIGURE 90 illustrates the format of a Registration Access Package. FIGURES 91A-91C illustrate the use of two deployment buffers to reduce visible artifacts. FIGURE 92 illustrates two buffers with a faster refresh than the image transfer. FIGURE 93 illustrates two buffers with slower rollover than the transfer of image. FIGURE 94 illustrates two buffers with deployment refresh much faster than image transfer. FIGURE 95 illustrates three buffers with faster rollover than image transfer. FIGURE 96 illustrates three buffers with slower rollover than image transfer. FIGURE 97 illustrates a buffer with renewal of display faster than image transfer. FIGURE 98 illustrates the client host connection through a daisy chain and a node center. FIGURE 99 illustrates client devices connected through a combination of nodal centers and daisy chains. FIGURE 100 illustrates a color map. FIGURE 101 illustrates a leakage current analysis.

DETAILED DESCRIPTION OF THE INVENTION I. Overview A general intent of the invention is to provide a Mobile Mobile Deployment Interface.

(MDDI), as discussed below, which results in or provides a cost-effective transfer mechanism, low power consumption that enables a high or very high speed data transfer through a communication link short-range between a host device and a client device, such as a deployment element, using a link or data channel "in series" this mechanism lends itself to implementation with miniature connectors and thin flexible cables that are especially useful when connecting internal deployment element (to a housing or support frame) or input devices to a central controller, or external deployment elements or devices such as micro-screens that can be worn (goggles or projectors) for laptops , wireless communication devices, or entertainment devices. Although the terms Mobile and Deployment are associated with the protocol name, it should be understood that this is for convenience only in terms of having a standardized name that is easily understood by those who have experience in the technique working with the interface and the protocol. However, it will be easy to understand after reviewing the modalities presented below in which many non-mobile and non-deployment related applications will benefit from the application of this protocol and the structure of the resulting interface, and the MDDI label it is not intended to imply any limitation to the nature or utility of the invention or its various modalities. An advantage of the embodiments of the invention is that a technique is provided for the transfer of data that is low in complexity, low cost, has a high reliability, fits well within the environment of use, and is very solid, although it remains very flexible The embodiments of the invention can be used in a variety of situations to communicate or transfer huge amounts of data, generally for audio, video or multimedia applications from a host or device or source where such data is generated or stored, for a client deployment or a presentation device at a high speed. A typical application, which is discussed below, is the transfer of data from either a portable computer or a wireless telephone or modem to a visual display device such as a small video screen or a micro-screen appliance that can worn, such as in the form of goggles or cases containing small lenses or projection screens, or from a host device to the client within such components. That is, from a processor to an internal screen or other presentation element, as well as from various internal or external input devices that employ a client for an internally located host (placed within the same device housing or structure). of support) . The characteristics or attributes of the MDDI are such that they are independent of the specific deployment or presentation technology. This is a highly flexible mechanism to transfer data at a high speed without considering the internal structure of that data, nor the functional aspects of the data or the commands it implements. This allows a timing of the data packets that are transferred to adjust them to suit the idiosyncrasies of the client's particular devices, such as for desires of unique deployments, for certain devices, or to meet the combined audio and video requirements for some AV systems or for certain input devices such as joysticks, touch screens, etc. The interface is the deployment element itself or the agnostic of the client device, as long as the selected protocol is followed. In addition, aggregate serial link data, or data rate, can vary by several orders of magnitude which allows a device communication system or host device designer to optimize cost, power requirements, complexity of the client device, and the refresh rates of the client device. The data interface is mainly presented for use in the transfer of huge amounts of high-speed data through a signal link. "threads" or small cable. However, some applications can take advantage of a wireless link as well, including optical-based links, provided it is configured to use the same packet and data structures developed for the interface protocol, and can sustain the desired level of transfer Low enough power consumption or complexity that continues to be practical.

II. Environment A typical application can be seen in FIGS. 1A and IB where a computer 100 laptop or notebook and a wireless telephone or device 102 PDA are shown communicating data with the deployment devices 104 and 106, respectively, together with systems 108 and 112 of audio playback. In addition, FIGURE 1A shows the potential connections for a larger display or screen 114 or an image projector 116, which are shown only in one figure for clarity, although they can be connected to the wireless device 102 as well. The wireless device may currently receive data or have previously stored a certain amount of multimedia-type data in an element or memory device for a later presentation for viewing and / or listening by an end user of the wireless device. Since a typical wireless device is used for voice and plain text communications most of the time, it has rather a small display screen and a simple audio system (speakers) to communicate the information to the user device 102. Computer 100 has a much larger screen, although it is still unsuitable for an external sound system, and is even short for other multimedia presentation devices such as a high-definition television, or movie screens. Computer 100 is used for purposes of illustration and other types of processors, interactive video games or consumer electronic devices may also be used with the invention. Computer 100 may employ, but is not limited to, or by means of, a wireless modem or other integrated device for wireless communications, or may be connected to such devices using a cable or wireless link, as desired. This makes the presentation of more complex or "rich" data less than a useful or pleasant experience. Therefore, the industry is developing other mechanisms and devices to present information to end users and to provide a minimum level of desired enjoyment or positive experience. As discussed previously in the above, various types of deployment devices have or are currently being developed to present information to the end users of the device 100. For example, one or more companies have developed goggle games that can be held posts that project a image in front of the eyes of a user device to present a visual display. When correctly placed, such devices effectively "project" a virtual image, as perceived through the eyes of the users, that is, much larger than what provides visual output. That is, a very small projection element allows the user's eyes to "see" images on a much larger scale than is possible with typical LCD screens and the like. The use of larger virtual screen images also allows the use of images of a much higher resolution than possible with more limited LCD screen displays. Other deployment devices could include, but are not limited to, small LCD screens of various flat panel display elements, projection lenses and display controllers for projecting images onto a surface, etc.

There may also be additional elements connected or associated with the use of a wireless device 102 or a computer 100 to present an output to another user, or to another device which in turn transfers the signals to any party or stores them. For example, the data may be stored in a non-volatile memory, in optical form, for example using a writable CD medium or in a magnetic medium such as a magnetic tape recorder and similar devices, for later use. further, many wireless devices and computers now have built-in MP3 music decoding capabilities, as well as other decoders and advanced sound systems. Laptops use CD and DVD playback capabilities as a general rule, and some have small non-volatile memory readers dedicated to receiving pre-recorded audio files. The problem with having such capabilities is that digital music files promise an experience rich in highly enhanced features, but only if the decoding and playback process can keep pace. The same is true for digital video files. To assist with sound reproduction, external speakers 114 are shown in FIGURE 1A, which may also be accompanied by addition elements such as "surround sound" speakers or an infrared speaker for front and rear projection of the sound. At the same time, the loudspeakers or headphones 108 are indicated as integrated for the support frame or mechanism of the micro-display device 106 of FIGURE IB. As is known, other audio or sound reproduction elements that include power amplification or sound modeling devices can be used. In any case, as discussed above, when it is desired to transfer high quality or high resolution image data and high quality audio data information or signals from a data source to an end user through one or more links 110 of communication, a high data rate is required. That is, the transfer link 110 is clearly a potential bottleneck in data communication as discussed at the beginning, and limits the performance of the system, since the current transfer mechanisms do not reach the high data rates that typically are they want As discussed above for example, for higher image resolutions such as 1024 by 1024 pixels, with color depths of 24-32 bits per pixel and at data rates of 30 fps, data rates can approach at speeds exceeding 755 Mbps or more. Furthermore, such images can be presented as part of a multimedia presentation that includes audio data and potentially additional signals that have to do with games or interactive communications, or various commands, controls or signals, which also increase the amount of data and the speed of data It is also clear that few cables or interconnections that are required to establish a data link means that the mobile devices associated with a deployment are easier to use, and that they are more likely to be adopted by a larger user base. This is especially true when multiple devices are commonly used to establish a complete audio-visual experience, and more especially as the level of quality of the audio output device deployments increases. Another typical application related to many of the above and other improvements in video displays and other output or input devices can be seen in FIGURES 1C and ID where a laptop or laptop computer and a cordless telephone or a 140 PDA device is shows communicating data with "internal" deployment devices 134 and 144, respectively, together with audio playback systems 136 and 146. In FIGS. 1C and ID, small sections in clipping of devices or electronic products in general are used to show the location of one or more internal hosts and controllers in a portion of the device with a generalized communication link, here 138 and 148 , respectively, connecting them to the video display elements or screens that the corresponding clients have, through a rotary union of some known type used throughout the electronics industry at present. It can be seen that the amount of data involved in such transfers requires a huge number of drivers to understand links 138 and 148. It is estimated that such communication links approximate 90 or more drivers to meet current growth needs to utilize interfaces of color and advanced graphics, deployment elements, in such devices due to the types of parallel or other known interface techniques available to transfer such data. Unfortunately, the highest data rates exceed the current available technology for transferring data, both in terms of the amount of data in the primary state that are needed to be transferred per unit of time, and in terms of cost-effective and reliable physical transfer mechanisms. in its manufacture. What is necessary is a technique, a structure, a means or method, to transfer data at higher speeds for the link or communication path of data transfer between the presentation elements and the data source, which allows a power consistently low (or lower) light weight, and make it simple and economical in your wiring structure as far as possible. A new technique or method and apparatus has been developed to achieve these and other goals to allow a series of mobile, portable or even fixed location devices to transfer data to audio transfer elements or micro-screens, desired displays at speeds of very high data, although a desired low power consumption and complexity is maintained.

III. Architecture of a High Speed Digital Data Interface System To create and efficiently use a new device interface, a protocol and signal system architecture has been formulated that provides a very high data transfer rate using low power signals. The protocol is based on a packet and a frame structure, or structures linked together to form a protocol for communicating a pre-selected data set or data types together with a command or an operational structure imposed on the interface.

A. Overview The devices connected through or communicating through the MDDI link are called host and client, the client typically being a deployment device of some type, although other input and output devices are contemplated. Host data to be deployed travel in a non-return direction (referred to as traffic or no return link), and customer data to the host travels in a return address (traffic or return link), as enabled by the host. This is illustrated in the basic configuration shown in FIGURE 2. In FIGURE 2, a host 202 connects to a client 204 using a bi-directional communication channel 206 that is illustrated as comprising a non-return link 208 and a link 210 of return. However, these channels are formed by a common set of conductors whose data transfer is effectively switched between the link operations - without return or return. This makes it possible to greatly reduce the number of drivers, directly addressing one of many problems that are faced with current methodologies for high speed data transfer in low power environments such as for mobile electronic devices. As discussed above, the host comprises one of several types of devices that can benefit from the use of the present invention. For example, host 202 could be a portable computer in the form of a portable mobile computing device, a laptop, or the like. It can also be a Personal Data Assistant (PDA), a radio locator device, or one of many wireless modem telephones. Alternatively, the host 202 could be a portable entertainment or presentation device such as a portable DVD or CD player, or a device for playing games. In addition, the host may reside as a host device or control element in a variety of other widely used or commercially planned products for which a high speed communication link with a customer is desired. For example, a host could be used to transfer data at high speeds from a video recording device to a client that relies on storage for improved response, or for a larger high resolution display screen. An appliance such as a refrigerator that incorporates on-board inventory or a computer system and / or Bluetooth connections to other home devices, may have enhanced deployment capabilities when operating in an Internet or Bluetooth-connected mode, or have cabling needs reduced for deployments at the door (one client) and keyboards or scanners (client) while the electronic computer or control systems (host) reside anywhere in the cabinet. In general, those skilled in the art will appreciate the wide variety of modern electronic devices and appliances that can benefit from the use of this interface, as well as the ability to retrofit older devices with a higher data rate of transport that uses Limited numbers of available drivers either recently added or in existing connectors or cables. At the same time the client 204 could comprise a variety of useful devices for presenting information to an end user, or present information from a user to the host. For example, a micro-screen incorporated in goggles or glasses, a projection device incorporated in a hat or a helmet, a small screen or even a holographic element incorporated within a vehicle, such as a window or windshield, or various loudspeakers, headphones or sound systems to present high quality sound or music. Other display devices include projectors or projection devices used to present information for meetings, or for films and television images. Another example would be the use of sensitive devices or touch sensitive tablet, speech recognition input devices, security scanners, etc. to which you can go to transfer a significant amount of information from a device or user system with few real "incomes" from a touch or a user sound. In addition, docking stations for computers and accessory sets for a car or desktop accessory sets and fasteners for cordless telephones can act as interface devices for end users or for other devices and equipment, and employ be it to clients or hosts (input and output devices such as a mouse) to assist in the transfer of data, especially where high-speed networks are involved. However, those skilled in the art will readily recognize that the present invention is not limited to those devices, there are many other devices on the market, and they are proposed for use, which they intend to provide to end users with high sound and images. quality, either in terms of storage and transport or in terms of presentation in reproduction. The present invention is useful to increase the total data throughput between various elements or devices to adjust the high data rates necessary to realize the desired user experience. The inventive MDD interface and the communication signal protocol can be used to simplify the interconnection between a host processor, a controller or a circuit component (for example), and a screen within a device or a housing or device structure (a which is referred to as an internal mode) to reduce the cost or complexity and the associated power and control requirements or the restrictions of those connections, and to improve reliability, not only for its connection to, or for elements, external devices or devices (referred to as external mode). The data rate of the aggregate serial link in each signal pair used for this interface structure can vary by many orders of magnitude, which allows a designer of a system or device to easily optimize cost, electric power, the complexity of implementation and the speed of update of the deployment for a specific application or purpose. The attributes of the MDDI are independent of the deployment or other presentation device technology (target customer). The timing of the data packets transferred through the interface can easily be adjusted to suit the idiosyncrasies of particular customers such as deployment devices, sound, memory and control elements, or combine the timing requirements of the audio-video systems. While this makes it possible to have a system with a very small electric power consumption, it is not a requirement of the various clients to have intermediate frame memories to make use of the MDDI protocol at least up to a certain level.

B. Interface Types The MDD Interface is intended to address at least four, and potentially more, different types of physical interfaces that are found in communications and the computer industry. These are labeled simply as Type 1, Type 2, Type 3 and Type 4, although other labels or designations may be applied by those who are experts in the technique depending on the specific applications they are using for or with the industry with which they are associated. For example, simple audio systems use fewer connections than more complex multimedia systems, and can refer to features such as "channels" differently, etc. The Type 1 interface is configured as a 6-wire or other conductor, or a conductive element, interface that is suitable for mobile or cordless phones, PDAs, electronic games and portable media players, such as CD players, or players. of MP3, and similar devices or devices that are used in similar types of consumer electronic technology. In one embodiment, an interface can be configured as an 8-wire (driver) interface that is more suitable for a laptop, electronic notebook, or personal desktop computers and similar devices or applications, which do not require rapid data updates and which do not have an integrated MDDI link controller. This Type Interface can also be distinguished by the use of a Universal Serial Bus (USB) interface, which is extremely useful for adjusting existing operating systems or software support found on most personal computers. . Type 2, Type 3 and Type 4 interfaces are suitable for high performance clients or devices and use more complex and larger cabling with additional twisted pair conductors to provide the appropriate shielding and low loss transfers for data signals. The Type 1 interface passes signals that may comprise a display, audio, control, and limited signaling information, and is typically used for mobile clients or client devices that do not require high-resolution maximum-speed video data. A Type 1 interface can easily support SVGA resolution at 30 fps in addition to a 5.1 audio channel, and a minimum configuration could use only a total of three wire pairs, two pairs for data transmission and a pair for wire transfer. electric power. This Type Interface is intended primarily for devices, such as mobile wireless devices, where typically a USB host is not available within such a device for connection and transfer of signals. In this configuration, the mobile wireless device is an MDDI host device, and acts as the "master control" that controls the communication link from the host, which generally sends the data to the client (traffic or non-return link) for presentation, deployment or reproduction. In this interface, a host enables the reception of communication data in the host from the client (traffic or return link) by sending a special command or a type of package to the client that allows it to take over the bus (link) for a specified duration and send the data to the host as return packets. This is illustrated in FIGURE 3, where a packet type referred to as an encapsulation packet (discussed below) is used to adjust the transfer of packets back through the transfer link, creating the link to the packet. return. The time interval intended for the host to probe the client in data search is predetermined by the host, and is based on the requirements of each application specified This type of semi-duplex bi-directional data transfer is especially advantageous when a USB port is not available to transfer the information or data from the client. High performance devices capable of HDTV type or similar high resolutions require approximately 1.5 Gbps data streams to support full motion video. The Type 2 interface supports high data rates through 2-bit transmission in parallel, Type 3 through the transmission of 4 bits in parallel, and the Type 4 interface transfers 8 bits in parallel. Type 2 and Type 3 interfaces use the same cable and connector as Type 1 but can operate at two to four times the data rate to support higher performance video applications on portable devices. A Type 4 interface is suitable for clients or very high performance deployments and requires a slightly larger cable that contains braided data signals. The protocol used by the MDDI allows each Host Type 1, 2 3 or 4 to communicate generally with any Client Type 1, 2, 3 or 4 through negotiation which is the highest possible data rate that can be used. Available capabilities or features that can be referred to as the minimum capacity device are used to establish link performance. As a rule, even for systems where the host and the client are able to use the Type 2, Type 3, or Type 4 interfaces, they start the operation as a Type 1 interface. The host then determines the target customer capacity, and negotiates an intracell transfer or re-configuration operation for either Type 2, Type 3 or Type 4 mode, as appropriate for the particular application. It is generally possible for the host to use the appropriate link-layer protocol (discussed further below) and to descend or reconfigure the operation generally at any time for a slower mode to save electrical power or to move up to a faster mode to support higher speed transfers, such as for a high resolution display content. For example, a host may change the interface types when the system switches from an electrical power source such as a battery to an AC electrical power, or when the source of the deployment medium switches to a lower or higher resolution format. , or a combination of those or other conditions or events can be considered as a basis for changing a Type Interface, or transfer mode. It is also possible for a system to communicate data using one mode in one direction and another mode in another direction. For example, a Type 4 interface mode could be used to transfer data to a screen at a high speed, while a Type 1 mode would be 'used when transferring data to a host device from peripheral devices such as a keyboard or a pointing device. Someone with experience in the art will appreciate that hosts and customers can communicate output data at different speeds. Often, users of the MDDI protocol can distinguish between an "external" mode and an "internal" mode. An external mode describes the use of the protocol and the interface to connect a host on a device to a client outside that device that is up to about 2 meters or so from the host. In this situation, the host can also send the power to the external client so that both devices can easily operate in a mobile environment. An internal mode describes when the host connects to a client that is contained within the same device, such as within a common housing or framework or support structure of some kind. An example would be applications within a cordless telephone or other wireless device, or a laptop or a gaming device where the client is a screen or screen controller, or an input device such as a keyboard or touch sensitive tablet , or a sound system, and the host is a central controller, a graphics processor or a CPU element. Since a client is located much closer to the host in applications in internal mode as opposed to applications in an external mode, there are generally no requirements that are discussed for the connection of the electric power to the client in such configurations.

C. Structure of the Physical Interface The general arrangement of a device or link controller to establish communications between host and client devices is shown in FIGURES 4 and 5. In FIGURES 4 and 5, a controller 402 and 502 of the link MDDI is displayed installed on a host device 202 and an MDDI link controller 404 and 504 is displayed installed on a client device 204. As before, the host 202 connects to a client 204 using a bi-directional communication channel 406 comprising a series of conductors. As discussed below, both the host and client link controllers can be manufactured as an integrated circuit using a single circuit design that can be placed, adjusted or programmed to respond to either a host controller or a controller. of the client (receiver). This makes possible lower costs due to a larger-scale manufacture of a single circuit device. In FIGURE 5, an MDDI link controller 502 installed in a client device 204 'is shown.

Like the previous one, the host 202 'connects to a client 204' using a bi-directional communication channel 506 comprising a series of conductors. As discussed above, both the host and client link controllers can be manufactured using a single circuit design. The signals pass between a host and a client, such as a deployment device, through the MDDI link, or the physical conductors are used, which are also illustrated in FIGURES 4 and 5. As can be seen in FIGURES 4 and 5 , the path or primary mechanism for transferring data through the MDDI uses data signals labeled as MDDI_DataO +/- and MDDI_Stb +/-. Each of those are low-voltage data signals that are transferred through a pair of differential wires in a cable. There is only one transition in either the MDDI_DataO pair or the MDDI-Stb pair for each bit sent through the interface. This is a voltage that is based on the transfer mechanism and is not based on current, so that the static current consumption is almost zero. The host controls the MDDI_Stb signals on the client's screen. Although the data can flow in both directions without return and return through the MDDI Data pairs, that is, it is a bi-directional transfer path, the host is the master or controller of the data link. The MDDI_DataO and MDDI_Stb signal paths are operated in a differential mode to maximize noise immunity. The data rate for the signals in those lines is determined by the speed of measuring the time sent by the host, and is variable across a range of approximately 1 kbps up to 400 Mbps or more. The Type 2 interface contains a pair of additional data or conductors or paths beyond that of Type 1, which is referred to as MDDI_Datall +/-. The Type 3 interface contains two additional data pairs or signal paths beyond that of the Type 2 interface referred to as MDDI_Data2 +/-, and MDDI_Data3 +/-. The Type 4 interface contains four data pairs or signal path beyond that of the Type 3 interface referenced as: MDDI_data4 +/-, MDDI_Data5 +/-, MDDI_Data6 +/- and MDDI_Data7 +/- respectively. In each of the above interface configurations, a host may send the power to the client or screen using the pair of wires or signals designated as H0ST_Pwr and H0ST_Gnd. As discussed further below, the power transfer can also be adjusted, if desired, in some configurations in the conductors MDDI_data4 +/-, MDDI Data5 +/-, MDDI Data6 +/- or MDDI Data7 +/- when using an interface of "Type" that employs few drivers that are available or present for the other modes. This power transfer is usually used for external modes, which are generally not needed for internal modes, although some applications may differ. Table I summarizes the signals that are passed between the host and the client (screen) through the MDDI link for various modes, then according to the Type Interface. Table I Type I Type 2 Type 3 Type 4 H HOOSSTT__PPwr / Gnd HOST_Pwr / Gnd HOST_Pwr / Gnd HOST_Pwr / Gnd MMDDDDII__SStb +/- MDDI_Stb +/- MDDI_Stb +/- MDDI_Stb +/- MDDI Data0 + / MDDI_Data0 +/- MDDI_Data0 +/- MDDI_DataO +/- MDDI Datal + / - MDDI_Datal +/- MDDI_Datal +/- MDDI_Data2 +/- MDDI_Data2 + / ~ Optional Pwr MDDI_Data3 +/- MDDI_Data3 + / ~ Optional Pwr Optional Pwr Optional Pwr MDDI_Data4 +/- Optional Pwr Optional Pwr Optional Pwr MDDI_Data5 + / ~ Optional Pwr Optional Pwr Optional Pwr MDDI_Data6 + / ~ Optiona1 Pwr Optional Pwr MDDI Data7 +/- It should also be noted that the connections HOST_Pwr / Gnd to transfer from the host are usually provided for external modes. In applications or internal modes of operation, we usually have clients that extract power directly from other internal resources, and do not use the MDDI to control the distribution of electrical energy, as may be apparent to those who have experience in the technique, so that distribution is not discussed further in detail herein. However, it is certainly possible to allow electrical power to be distributed through the MDDI interface to allow certain kinds of control of electrical power, synchronization, or convenience of interconnection, for example, as can be understood by someone who has experience in the field. technique. The wiring that is generally used to implement the previous structure and its operation is . nominally in the order of 1.5 meters in length, generally 2 meters or less, and contains three pairs of stranded conductors, each in turn is a 30 AWG multi- press thread. A sheet armor cover is rolled or otherwise formed above the three twisted pairs, as an additional draining yarn. The twisted pairs and the drainage shielding conductor terminate at the Customer's connector with the shield connected to the customer's shield, and there is an insulating layer, covering the entire cable, as is well known in the technique. The threads are formed in pairs like: HOST_Gnd with HOST_Pwr; MDDI_Stb + with MDDI_Stb-; MDDI_DataO + with MDDI_DataO-; MDDI_Datal + with MDDI_Datal-; etc. However, a variety of conductors and wiring can be used, as is well understood in the art, to implement the embodiments of the invention, which depend on the specific applications. For example, heavier external coatings or even metal coatings may be used to protect the cable in some applications, although thinner, flatter conductor-type structures may be more suitable for other applications.

D. Types and Data Speeds To achieve a useful interface for a full range of user experiences and applications, the Mobile Digital Data Interface (MDDI) provides support for a variety of clients and deployment information, audio translators, keyboards, signaling devices and many other input and output devices that could be integrated into or function in coordination with a mobile deployment device, together with the control information, and combinations thereof. The MDD interface is designed to enable the adjustment of a variety of potential types of data streams traversing between the host and the client either in non-return or return link directions using a minimum number of wires or conductors. Both isochrone currents and asynchronous currents are supported (updates). Many types of data combinations are possible as long as the aggregated data rates are less than or equal to the desired maximum MDDI link rate, which is limited by the maximum serial rate and the number of data transfers employed. These could include, but are not limited to, those items numbered in Tables II and III below. Table II Transferring from a Host to the Client 720x480, 12bit, 30 f / s video data -124.5 Mbps Isochronous audio data 44.1kHz, 16bit, 1.4 Mbps stereo isochronous stereo data graphics 800x600, 12bit, lOf / s, -115.2 Mbps stereo asynchronous Minimum asynchronous control < < 1.0 Mbps Table III The interface is not fixed but is extensible so that it can support the transfer of a variety of "types" of information that includes user-defined data, for a future flexibility of the system. Specific examples of data that can be adjusted are: full-motion video, either in the form of full or partial screen bitmap fields or compressed video; static bitmaps at low speeds to conserve power and reduce implementation costs; PCM or compressed audio data in a variety of resolutions or speeds; the position and selection of signaling device and user definable data for the capabilities that are to be defined. Such data may also be transferred together with control or status information to detect the capacity of the device or set the operating parameters. The embodiments of the invention advance the technique to be used in data transfers that include, but are not limited to: viewing a movie (display of video and audio); use a personal computer with limited personal screen (display of graphics, sometimes combined with video and audio); play a video game on a PC, console or personal device (display of motion graphics, or synthetic video and audio); "surf" on the Internet, using devices in the form of a video phone (low-speed bi-directional video and audio), a still image digital camera, or a video camera to capture digital video images; use a telephone, computer or PDA coupled with a projector to provide a presentation or coupled with a desktop docking station connected to a video monitor, keyboard and mouse; and to increase productivity or entertainment use with cell phones, smartphones or PDAs, including wireless signaling devices and keyboard data. The high-speed data interface discussed below is presented in terms of the proportion of huge amounts of type A-V data through a communication or transfer link that is usually configured as a metallic line or cable type link. However, it will be readily apparent that the structure of the signal, the protocols, the timing or the transfer mechanism could be adjusted to provide a link in the form of an optical or wireless medium, if it can hold the. desired level of data transfer. The MDD interface signals use a concept known as the Common Frame Rate (CFR) for the protocol or basic signal structure. The idea behind the use of a Common Frame Rate is to provide a synchronization pulse for simultaneous isochronous data streams. A client device can use this common frame rate as a reference time. A low CF rate increases the efficiency of the channel by decreasing auxiliary operations to transmit the sub-frame header.

On the other hand, a high CF rate decreases the latency, and allows a smaller elastic data buffer for the audio samples. The speed CF of the present inventive interface can be programmed dynamically and can be set to one or many values that are appropriate for the isochronous currents used in a particular application. That is, the CF value is selected to adapt the best to a specific client and to the configuration of the host, as desired. The number of bytes generally required for the sub-frame, which can be adjusted or can be programmed, for isochronous data streams that are most likely to be used with an application, such as for a video or a miero-pantall show in Table IV. Table IV Fractional byte counts per sub-frame are easily obtained using a simple programmable M / N counter structure. For example, a count of 26-2 / 3 bytes per CF is implemented by transferring two 27-byte frames followed by each one by a 26-byte sub-frame. A smaller CF rate can be selected to produce an integer number of bytes per sub-frame. However, speaking in general, to implement a counter M /? simple hardware would require a smaller area within an integrated circuit chip or electronic module used to implement part or all of the embodiments of the area needed for a larger audio sample FIFO buffer. An exemplary application that illustrates the impact of different data transfer rates and data types is a Karaoke system. For Karaoke, a system where an end user or users sing along with a music video program. The lyrics of the song are displayed somewhere above, typically at the bottom of, a screen for the user to know the lyrics that will sing, and in approximate form the timing of the song. This application requires a video deployment with non-frequent graphics updates, and mix the voice of the user or, the voices, with an audio stream in stereo. Assuming a common frame rate of 300 Hz, then each sub-frame will consist of: 92,160 bytes of video content and 588 bytes of audio content (based on 147 16-bit samples, in stereo) through the link No return for the client deployment device, and an average of 26.67 (26-2 / 3) voice bytes are sent back from a microphone to the mobile Karaoke machine. The asynchronous packets are sent between the host and the deployment, possibly mounted in the head. This includes a maximum of 768 bytes of graphics data (one quarter height of the screen), and less than about 200 bytes (several) bytes for miscellaneous control and status commands. Table V shows how data is allocated within a sub-frame for the Karaoke example. The total speed that is used is selected to be approximately 279 Mbps. A slightly higher speed of 280 Mbps allows approximately another 400 bytes of data per subframe to be transferred, which allows the use of occasional control and messaging. state. Table V III. (Continued) High Speed Digital Data Interface System Architecture E. Link Layer The data transferred using high speed MDD interface serial data signals consists of a stream of time-multiplexed packets that are linked one after the other. . Even when a transmission device has no data to send, an MDDI link controller automatically in general sends packets of stuffing, thereby, thereby maintaining a stream of packets. The use of a simple packet structure ensures reliable isochronous timing for video and audio signals or data streams. The packet groups are contained within elements or signal structures referred to as a sub-frame, and the groups of sub-frames are contained within elements or signal structures referred to as a frame of reference. medium. A sub-frame contains one or more sub-frames, depending on their size and respective data transfer uses, and a media frame contains one or more sub-frames. The largest sub-frame that is provided by the protocol that is employed through the embodiments presented herein is in the order of 232-l or 4,294,967,295 bytes, and the largest medium frame size is then transformed into the order of 216-1 or 65,535 sub-frames. A special sub-frame header packet contains a unique identifier that appears at the beginning of each sub-frame, as discussed below. That identifier is also used to acquire the frame timing on the client device when communication between the host and the client is initiated. The acquisition of link timing is discussed in more detail below. Typically, a display screen is updated once per media frame when a full motion video is being displayed. The frame display speed is the same for the media frame rate. The link protocol supports full-motion video through an entire display, or just a small region of the total motion video content surrounded by a static image, depending on the desired application. In some low power mobile applications, such as the deployment of web pages or emails, the deployment screen may only need to be updated occasionally. In those situations, it is advantageous to transmit a single sub-frame and then close or deactivate the link to minimize the consumption of electrical energy. The interface also supports effects such as stereo-vision, and handles basic graphics. The subframes allow a system to enable the transmission of high priority packets on a periodic basis. This allows simultaneous isochronous currents that co-exist with a minimum amount of data buffering. This is an advantage of the modalities that are provided for the deployment process, which allows multiple data streams (video communication, voice, control, status, high-speed signaling device data, etc.) to essentially share a channel common. It transfers information using relatively few signals. It also enables specific actions of the deployment technology, such as horizontal synchronization pulses and blocking intervals for a CRT monitor, or for other actions specific to the client's technology.

F. Link Controller The MDDI link controller shown in FIGURES 4 and 5 is manufactured or assembled to be a fully digital implementation with the exception of the differential in-line receivers that are used to receive MDDI data and strobe signals. However, even handlers and differential line receivers can be implemented in the same digital integrated circuits with the link controller, as a CMOS type IC is manufactured. Analog functions or closed phase circuits (PLLs) are not required for bit recovery or to implement the hardware for the link controller. The host and client link controllers contain very similar functions, with the exception of the client interface that contains a state machine for link synchronization. Therefore, the embodiments of the invention allow a practical advantage so that there is the possibility of creating a single controller or circuit design that can be configured either as a host or a client, which can reduce the manufacturing costs for the controllers of the invention. link in full form.

IV. Interface Link Protocol A. Frame structure The signal protocol or frame structure used to implement the non-return link communication for packet transfer is illustrated in FIGURE 6. As shown in FIGURE 6, the information or the digital data is grouped into elements known as packages. In turn, multiple packages are grouped together to form what is referred to as a "sub-frame" and multiple sub-frames in turn are grouped together to form a "media" frame. To control the formation of frames and to transfer the sub-frames, each sub-frame starts with a special predefined packet which is referred to as Sub-frame Header Pack (SHP). The host device selects the data rate to be used for a given transfer. This speed can be changed dynamically by the host device based on both the maximum transfer capacity of the host, data that is retrieved from a source by the host, and the maximum capacity of the client or other device to which they are being transferred. data. A receiver client device designed for, or capable of, operating with the MDDI or the inventive signal protocol is capable of being consulted by the host to determine the maximum, or currently maximum, data transfer rate that can be used. or a slower minimum speed by default that can be used, as well as the types of data that can be used and the features supported. This information could be transferred using a Client Capacity Package (DCP), as discussed further below. The client deployment device is capable of transferring data or communicating with other devices using the interface at a pre-selected minimum data rate or within a minimum data rate range, and the host will perform a query using a speed of data within this range to determine the total capabilities of the client's devices. Other status information that defines the nature of the bitmap and the video frame rate capabilities of the client can be transferred into a status packet for the host so that the host can configure the interface to be both efficient and optimal. in practice, or as desired within any system restrictions. The host sends the padding packets when there are no (more) data packets to be transferred in the current sub-frame, or when the host can not transfer at a sufficient speed to keep pace with the data transmission rate chosen by the link with no return. Since each sub-frame starts with a sub-frame header packet, the end of the previous sub-frame contains a packet (which is most likely a filler packet) that exactly fills the previous sub-frame. In the case of a lack of space for the packets that carry the data itself, a packet filler will most likely be the last packet in a sub-frame, or at the end of the next previous sub-frame and before a packet of the header the sub-frame It is a task of the control operations in a host device to ensure that there is enough remaining space in a sub-frame for each packet to be transmitted within that sub-frame. At the same time, once the host device initiates the sending of a data packet, the host should be able to successfully complete a packet of that size within a frame without incurring a condition of an insufficient amount of data. In one aspect of the modes, the transmission of sub-frames has two modes. One mode is a periodic sub-frame mode, times of periodic timing, used to transmit live video and audio streams. In this mode, the sub-frame length is defined as if it were not at zero. The second mode is an asynchronous or non-periodic mode in which frames are used to provide the Bitmap Data for a client when new information is available. This mode is defined by setting the sub-frame length to zero in the Header Pack of the sub-frame. When the periodic mode is used, the reception of the sub-frame packet may begin when the client has synchronized with the non-return link frame structure. This corresponds to the states "in synchronization" defined according to the state diagram discussed below with respect to FIGURE 49 or FIGURE 63. In the non-periodic asynchronous sub-frame mode, reception begins after the first Header package of the sub-frame has been received.

B. General Package Structure The format or structure of the packages used to formulate the communication or the signal protocol, or the method or means to transfer the data, implemented by the modalities is presented below, keeping in mind that the interface is extensible and additional package structures can be added if desired. Packages are labeled as, or divided into, different "packet types" in terms of their interface capability, ie, commands, information, value or data that they transfer or with which they are associated. Therefore, each packet type indicates a pre-defined packet structure for a given packet that is used in the handling of the packets and the data that is being transferred. It will be readily apparent, that packets may have pre-selected lengths or may have variable lengths or that they may be changed dynamically depending on their respective functions. Packages could also carry different names, although the same capacity is still being performed, as can happen when protocols are changed during acceptance within a standard. The byte or byte values used in the various packets are configured as unsigned multi-bit integers (8 or 16 bits). A summary of the packets that are used together with their "type" designations, enumerated in order of type, and which are shown in Tables VI-1 through VI-4. Each table represents a "type" of package within a general package structure to facilitate its illustration and understanding. There is no limitation or other impact that is implied or expressed for the invention by those groupings, and the packages can be organized in many other ways as desired. The address in which the transfer of a package is considered valid is also highlighted.

Table VI-1 Link Control Packages Table VI-2 Basic Media Stream Packs Table VI-3 Client Status and Control Packages Table V -4 Advanced Chart and Deployment Package Something that is clear from other discussions within this text is that although the Return Encapsulation Package, the Client Capacity Package and the Client Status and Application Package are each considered very important or even required in Many modalities of the communication interfaces for the operation of the External Mode, although they may be considered to be or are more likely to be optional for the Internal Mode operation. This creates even another type of MDD Interface protocol that allows data communication at very high speed with a set of reduced communication packets, and a simplification of control and corresponding timing. The packets have a common basic structure or global set of minimum fields comprising a Packet Length field, a Packet Type field, a Data Byte field or fields, and a CRC field, which is illustrated in FIGURE 7 As shown in FIGURE 7, the Packet Length field contains information in the form of a value of multiple bits or bytes, which specify the total number of bits in the packet, or its length between the Length field of the packet. Package and the CRC field. In one mode, the packet length field contains an unsigned broad 16-bit or 2-byte integer, which specifies the Packet Length. The Package Type field is another multi-bit field that designates the type of information that is contained within the package. In an exemplary embodiment, this is a wide value of 16 bits or 2 bytes, in the form of a 16-bit unsigned integer, and specifies such data types as display capabilities, intracell transfer, video or audio streams, state, etc. A third field is the Data Bytes field, which contains the bits or data that are transferred or sent between the host and Client devices as part of that packet. The format of the data is defined specifically for each type of packet according to the specific type of data that is transferred, and can be separated into a series of additional fields, each with its own format requirements. That is, each type of package will have a defined format for this portion or field. The last field is the CRC field that contains the results of a 16-bit cyclic redundancy check calculated through the fields Data Bytes, Package Type and Packet Length, which are used to confirm the integrity of the information in the package. In other words, it is calculated for the entire package except for the CRC field itself. The client generally keeps a total count of the detected CRC errors, and reports this count back to the host in the Client Status and Application Package (see below). Generally, those field widths and their organization are designed to hold 2-byte fields in a uniform byte boundary, and 4-byte fields are aligned by 4-byte boundaries. This allows packet structure that can be easily integrated within a main memory space of a host and a client or associated with them without violating the data type alignment rules that are found for most or typically used in circuits of control or processors. During the transfer of the packets, the fields are transmitted starting with the Last Significant Bit (LSB) first and ending with the last Most Significant Bit (MSB) transmitted. Parameters that have a length of more than one byte are transmitted using the last significant byte first, which results in the same bit transmission pattern that is used for a parameter greater than a length of 8 ites, such as the one that is would use for a shorter parameter where the LSB is transmitted first. The data fields for each packet are generally transmitted in the order in which they are defined in subsequent sections below, with the first field listed to be transmitted first, and the last field described so that it is transmitted to the latter. The data in the path of the MDDI_Data0 signal is aligned with the 0 'bit of the bytes that are transmitted on the interface in any of the modes Type 1, Type 2, Type 3 or Type 4. When manipulating data for the deployments, the data for the arrangement of the pixels are transmitted first by rows, then in columns, as is traditionally done in the electronics technique. In other words, all the pixels that appear in the same row in a bitmap are transmitted in order with the pixel that is most to the left transmitted first and the pixel that is more to the right transmitted at the end. After the pixel that is furthest to the right of a row is transmitted, then the next pixel in the sequence is the pixel that is furthest to the left of the next row. The rows of pixels are generally transmitted in order from top to bottom for most deployments, although other configurations may be adjusted as necessary. In addition, when handling bitmaps the conventional method, which is followed here, is to define a reference point by labeling the upper left corner of a bitmap as the location or displacement "0,0". The X and Y coordinates used to define or determine a position in the bitmap increase its value as they approach the right or the bottom of the bitmap, respectively. The first row and the first column (upper left corner of an image) start with an index value of zero. The magnitude of the X coordinate increases in the direction of the right side of the image, and the magnitude of the Y coordinate increases in the direction of the lower part of the image as it is displayed by the user of the screen. A screen window is the visible portion of a bitmap, the portion of the pixels in the bitmap that can be seen by the user in the physical deployment medium. It is often the case that the screen window and the bitmap are the same size. The upper left corner of the screen window always displays the pixel location in the "0" bitmap, 0. The width of the screen window corresponds to the X axis of the bitmap, and the width of the screen window for this mode is less than or equal to the width of the corresponding bitmap. Y-axis of the bitmap, and the height of the screen window for this mode is less than or equal to the height of the corresponding bitmap.In itself the screen window can not be addressed in the protocol because only is defined as the visible portion of a bitmap.The relationship between bitmaps and screen windows is well known in computer techniques, electronics, Internet communication and other related electronics techniques. , no additional discussions or illustrations of these principles are provided herein.

C. Package Definitions I. Sub-Frame Header Pacjuete The Sub-Frame Header package is the first sub-frame package, and has a basic structure as illustrated in FIGURE 8. The Header Pack of Sub-Frame is used for a host-client synchronization, each host must be able to generate this package, although each client must be able to receive and interpret this package. As can be seen in a modality of FIGURE 8, this type of package is structured to have the fields Packet Length, Packet Type, Single Term, Reserved 1, Sub-Frame Length, Protocol Version, Sub-Frame Count and Half-Plot Count, generally in that order. In one embodiment, this packet type is generally identified as a Type 15359 packet (hexadecimal 0x3bff) and uses a pre-selected fixed length of 20 bytes, which does not include the packet length field. The Package Type field and the Single Term field each use a 2-byte value (unsigned 16-bit integer). The 4-byte combination of these two fields jointly forms a single 32-bit term with good auto-correlation. In one embodiment, the only real term is 0x005a3bff, where the lowest 16 bits are transmitted first as the Package Type, and then transmitted as the 16 most significant bits. The reserved field 1 contains 2 bytes that are a reserved space for a future use, and it is generally configured at that moment with all the bits set to zero. One purpose of this field is to cause the subsequent 2-byte fields to be aligned with a 16-bit term address and cause the 4-byte fields to be aligned with 32-bit term addresses. The last significant byte is reserved to indicate if the host is able or not to address multiple client devices. A value of zero for this byte is reserved to indicate that the host is capable of operating only with a single client device. The Sub-Frame Length field contains 4 bytes of information, or values, that specify the number of bytes per sub-frame. In one embodiment, the length of this field can be set equal to zero to indicate that only one sub-frame will be transmitted by the host before the link is closed in an availability state. The value in this field can be changed dynamically "on the fly" when it makes the transition from one sub-frame to the next. This capability is useful for making minor timing adjustments in the synchronization pulses to adjust isochronous data streams. If the CRC of the Sub-frame Header Pack is not valid then the link controller must use the Sub-frame Length of the previous well-known Sub-frame Header packet to estimate the current sub-frame length. The Protocol Version field contains 2 bytes that specify the version of the protocol that is being used by the host. The Protocol Version field can be set to? 0 'to specify the first or the current version of the protocol that is being used. This value will change over time as new versions are created, and is already improved to a value x l 'for some version fields. The probable version values or generally follow a current version number for a document of approved standards that cover interfaces such as the MDDI, as it is already known. The Sub-frame Count field contains 2 bytes that specify a sequence number that indicates the number of sub-frames that have been transmitted since the start of the media frame. The first subframe of media frame has a sub-frame count of zero. The last subframe of media frame has a value of n-l, where n is the number of sub-frames per media frame. The value of the Sub-frame count field is equal to the Sub-frame count sent in the previous Sub-frame package plus 1, except for a sub-prime sub-frame of a media frame that will have a count of zero. It should be noted that if the Sub-frame Length is set equal to zero (indicating a non-periodic sub-frame) then the Sub-frame count is also set equal to zero. The Media Screen Count field contains 4 bytes (32-bit unsigned integer) that specifies a sequence number that indicates the number of media frames that have been transmitted since the start of the present media element or data that is being transferring. The first media frame of a media element has a Media Frame Count of zero. The Media Frame Count is incremented just before the first sub-frame of each media frame and is reset to zero after the maximum Media Frame Count (for example, the media frame number 23) is used. 1 = 4, 294, 967, 295.) The value of Media Frame Counts can usually be reset at any time by the Host to suit the needs of a final application. 2. Filler Package A filler package is a package that is transferred to or from a Client device when other information that is going to be sent is not available, either in the non-return or return link. It is recommended that the filler packets have a minimum length to allow maximum flexibility when sending other packets when required. Right at the end of a sub-frame or an encapsulation packet of the return link (see below), a link controller sets the size of the filler packet to fill in the remaining space to maintain packet integrity. The Filler Pack is useful for keeping the timing in the link when the host or client has no information to send or exchange. All host and client need to be able to send and receive this package to make effective use of the interface. An exemplary formatting modality and the content of a filler package is shown in FIGURE 9. As shown in FIGURE 9, this type of package is structured to have Packet Length fields, a Package Type, Filler Bytes and CRC In a modality, this type of package is generally defined as a Type 0, which is indicated in the Type 2 bytes field. The bits or bytes in the Bytes field of the Filler comprise a variable number of all zero bit values to allow the filler pack to be of the desired length. The smallest filler packet does not contain bytes in this field. That is, the packet consists only of one packet length, one packet type and one CRC, and in one mode uses a pre-selected fixed length of 6 bytes or a packet length value of 4. The value of the CRC it is determined for all bytes in the packet including the packet length, which can be excluded in some other packet types. 3. Video Stream Package Video Stream Packets carry video data to typically update rectangular regions of a deployment device. The size of this region can be as small as a single pixel or as large as the full deployment. There can be almost an unlimited number of streams deployed simultaneously, limited by system resources, because all the context required to deploy a stream is contained within the Video Stream Package. The format of a modality of a Video Stream Package (Video Data Format Descriptor) is shown in FIGURE 10. As can be seen in FIGURE 10, in one modality, this type of packet is structured to have fields Packet Length (2 bytes), Package Type, Client IDb, Video Data Descriptor, Pixel Deploy Attributes, Left Edge X, Top Edge Y, Right Edge X, Bottom Edge Y, Start X and Y, Pixel Count, CRC Parameter, Pixel Data and Pixel Data CRC. This type of packet is usually identified with a Type 16, which is indicated in the Type 2 bytes field. In one embodiment, a client indicates a capability to receive a Video Stream Package utilizing RGB, Monochrome, and Capacity and CrCb fields of the Client Capacity Package.

In one mode, the Client ID field contains 2 bytes of information that are reserved for a Client ID. Since this is a newly developed communications protocol, the current Client IDs are not yet known or can not be communicated enough. Therefore, the bits in this field are generally equal to zero until the values of the ID are known, at which time the values of the ID can be inserted or used, as will be apparent to those having experience in the art. The same process will generally be true for the Client ID fields that are discussed below. The common frame concept discussed above is an effective way to minimize the size of the audio buffer and decrease the latency. Nevertheless, for video data it may be necessary to scatter the pixels of a video frame through multiple Video Stream Packs within a media frame. It is also very likely that the pixels in a single Video Stream Package do not exactly correspond to a perfect rectangular window on the screen. For the exemplary video frame rate of 30 frames per second, there are 300 sub-frames per second, which results in 10 sub-frames per media frame. If there are 480 rows of pixels in each frame, each Video Stream Package in each sub-frame will contain 48 rows of pixels. In other situations, the Video Stream Package may not contain a whole number of rows of pixels. If this is true for other video frame sizes where the number of subframes per media frames is not divided by equality between the number of rows (also known as video lines) per video frame. For efficient operation, each Video Stream Package should generally contain an entire number of pixels. It might not even contain a whole number of rows of pixels. This is important if the pixels are more than one byte each, or if they are in a packet format like the one shown in FIGURE 12. The format and content used to make the operation of a Data Descriptor field a reality Exemplary video, as mentioned above, are shown in FIGURES 11A-11E. In FIGS. 11A-11E, the Video Data Format Descriptor field contains 2 bytes in the form of a 16-bit unsigned integer specifying the format of each pixel in the Pixel Data in the current present in the present packet. . It is possible that different Video Stream packets can use different pixel data formats, that is, they use a different value in the Video Data Format Descriptor, and similarly a stream (display region) can change its data format on the fly. The pixel data format must comply with at least one of the valid formats for the Client, as defined in the Client Capacity Package. The Video Data Format Descriptor defines the pixel format for the present packet only, which does not imply that it will continue to use a constant format during the lifetime of a particular video stream. FIGURES HA until 11D illustrate how the Video Data Format Descriptor is encoded. As used in these figures, and in this mode, when the bits [15:13] are equal to? 000 ', as shown in FIGURE HA, then the video data consists of a monochrome pixel arrangement where the number of bits per pixel is defined by the bits from 3 to 0 of the term of the Video Data Format Descriptor. Bits 11 through 4 are generally reserved for future use or applications and are set to zero in this situation. When the bits [15:13] instead of being equal to the values '001', as shown in FIGURE 11B, then the video data consists of a color pixel arrangement that specifies each one a color through A color map (palette) In this situation, the bits from 5 to 0 of the term of the Video Data Format Descriptor define the number of bits per pixel, and bits 11 through 6 are generally reserved for one use or applications If the bits [15:13] are instead of equal to the values? 010 ', as shown in FIGURE 11C, then the video data consists of an array of color pixels in where the number of bits per pixel of red is defined by bits 11 through 8, the number of bits per pixel of green is defined by bits 7 through 4, and the number of bits per pixel of blue is defined by the bits 3 up to 0. In this situation, the total number of bits in each pixel is the sum a of the number of bits used for red, green and blue- However, when the bits [15:13] are instead of equal to the values or to the sequence '011', as shown in FIGURE 11D, then the video data consists of a data arrangement video in a 4: 2: 2 YCbCr format with luminance and chrominance information, where the number of bits per pixel of luminance (Y) is defined by bits 11 through 8, the number of bits of component Cb is defined by bits 7 through 4, and the number of bits of the component Cr is defined by bits 3 through 0. The total number of bits in each pixel is the sum of the number of bits used for red, green and blue. The Cb and Cr components are sent at half the speed as Y. In addition, 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 , etc . Yn, Yn + 1, Yn + 2 and Yn + 3 are luminance values of four consecutive pixels in a single row from left to right. If there is an odd number of pixels in a row (X Right Edge - X Left Edge +1) in the window referenced by the Video Stream Package then the Y value corresponds to the last pixel in each row that is followed by the value Cb of the first pixel of the next row, and a value Cr that is not sent to the last pixel in the row. It is recommended that the windows use a Y Cb Cr format that has a width that is an even number of pixels. The Pixel Data in a packet must contain an even number of pixels. They can contain an odd or even number of pixels in the case where the last pixel Pixel Data corresponds to the last pixel of a row in the window specified in the header of the Video Stream Package, that is, when the location X of the The last pixel in the Pixel Data is equal to the Right Edge X. When the bits [15:13] are instead of equal to the values Y00 'then the video data consist of a Bayer pixel array where the number of bits per pixel is defined by the bits from 3 to 0 of the term of the Video Data Format Descriptor. The Pixel Group Pattern is defined by bits 5 and 4 as shown in FIGURE HE. The order of the pixel data can be horizontal or vertical, and the pixels in the rows or columns can be sent in a return order with no return and is defined by bits 8 through 6. Bits 11 through 9 they should be set to zero. The group of four pixels in the pixel group in the Bayer format resembles what is often referred to as a single pixel in some deployment technologies. However, a pixel in the Bayer format is only one of the four colored pixels of the mosaic pattern of the pixel group. For all five formats shown in the figures, Bit 12, which is designated as "P", specifies whether the Pixel Data samples are packed or not, or pixel data aligned with the byte. A value of Y 'in this field indicates that each pixel in the Pixel Data field is aligned with the byte and with a byte limit of the MDD interface. A value of ? 1 'indicates that each pixel and each color within each pixel in the Pixel Data are packaged against the previous pixel or the color within a pixel that leaves no unused bits. The difference between the data format Aligned with Byte and Packed Pixel is shown in more detail in FIGURE 12, where it can be clearly seen that the data aligned with the byte can leave unused portions of the data sub-frame, as opposed to the packaged pixel format that does not leave them. The first pixel in the first video stream packet of a media frame for a particular screen window will go to the upper left corner of the stream window defined by a Left Edge X and a Top Edge Y, and the next received pixel is placed in the following pixel location in the same row, etc. In this first media frame packet, the start value X will usually be equal to the Left Edge X and the start value Y will usually be equal to the Upper Edge Y. In the subsequent packets corresponding to the same screen window, the X and Y start values will usually be set to the pixel location in the screen window that would normally follow after the last pixel sent in the Video Stream Package that is transmitted in the previous sub-frame. 4. Pay for Audio Stream Audio packets carry audio data to be played through the customer's audio system, or for an independent audio presentation device. Different streams of audio data can be allocated for separate audio channels in a sound system, for example: left to front, right to front, center, back left and back right, depending on the type of audio system being used. A complement is provided for complete audio channels for hearing aids that contain improved spatial-acoustic signal processing. A client indicates an ability to receive an Audio Stream Package using the Audio Channel Capacity and the Audio Sample Speed fields of the Client Capacity Package. The format of the Audio Stream Packs is illustrated in FIGURE 13. As shown in FIGURE 13, this type of packet is structured in a modality to have fields of Packet Length, Packet Type, Client ID, ID, of the Audio Channel, Reserved 1, Audio Sample Count, Bits by Sample and Packaging, Audio Sample Rate, CRC Parameter, Digital Audio Data, and Audio Data CRC. In one embodiment, this type of packet is generally defined as a Type 32 packet. The ClientID field contains 2 bytes of information that are reserved for a Client ID, as previously used. The reserved field 1 contains 2 bytes that are reserved for future use, and that is generally configured at this point with all the bits set to zero. The Bits by Sample and Packaging field contains 1 byte in the form of an 8-bit unsigned integer that specifies the packaging format of the audio data. The format generally used is for Bits 4 through 0 to define the number of bits per sample of PCM audio. Bit 5 then specifies whether the samples of the Digital Audio Data are packaged or not. The difference between the packet and the audio samples aligned by the byte, which here use 10-bit samples, is illustrated in FIGURE 14. A value of '0' indicates that each sample of PCM audio in the Audio Data field Digitals are aligned with the byte with an MDDI interface byte limit and a value of Y 'indicates that each successive PCM audio sample is packaged against the previous audio sample. This bit is generally effective only when the value defined in the bits from 4 to 0 (the number of bits per PCM audio sample) is not a multiple of eight. Bits 7 through 6 are reserved for future use and are generally set to a value of zero.

. Reserved Current Packs In one modality, packet types 1 through 15, 18 through 31, and 33 through 55 are reserved for current packets that are to be defined for use in future versions or variations of protocols package, as desired for the various applications found. Again, this is part of what makes the MDD interface more flexible and useful despite the ever-changing designs of technology and systems when compared to other techniques. 6. User Defined Current Packs Eight types of data stream, known as Types 56 through 63, are reserved for use in owner applications that can be defined by equipment manufacturers for use with an MDDI link. These are known as User-Defined Current Packs. Such packages can be used for any purpose, although the host and the customer should only use such packages in situations in which the result of such use is well understood or known. The specific definition of the parameters and current data for those types of packets are left to be specific to the equipment manufacturers or interface designers that implement such packet types or seek their use. Some exemplary uses of User-defined Stream Packs are to transfer test parameters and test results., calibration data in the factory, and special use data of the owner. The format of user-defined current packets that are used in a modality is illustrated in FIGURE 15. As shown in FIGURE 15, this type of packet is structured to have Packet Length fields (2 bytes), a Package Type, a Customer ID number, Current Parameters, CRC Parameter, Current Data and Current Data CRC. 7. Color Map Packages Color map packages specify the contents of a color map look-up table used to present colors for a customer. Some applications may require a color map that is larger than the amount of data that can be transmitted in a single package. In those cases, the Multiple Color Map packages can be transferred, each with a different subset of the color map by using the displacement and length fields described below. The format of the Color Map Package in one mode is illustrated in FIGURE 16. As shown in FIGURE 16, this type of package is structured to have Packet Length, Packet Type, Client ID, Counting fields of Color Map Element, Color Map Offset, CRC Parameter, Color Map Data and Data CRC. In one embodiment, this type of packet is generally identified as a Type 64 package (Video Data Format and Color Map Package) as specified in the Package Type Field (2 bytes). A client indicates an ability to receive the Color Map Packs using the Color Map Size, and Color Map Width fields of the Client Capacity Packet. 8. Return Link Encapsulation Packages In an exemplary mode, the data is transferred in the return direction using a Return Link Encapsulation Pack. A non-return link packet is sent and the operation of the MDDI link (transfer address) is changed or half of this packet is reversed so that the packets can be sent in the return address. The format of the Return Link Encapsulation package in one modality is illustrated in FIGURE 17. As shown in FIGURE 17, this type of package is structured to have fields of Packet Length, Packet Type, Client ID, Return Link Indicators, Return Speed Divider, Turn Length 1, Turn Length 2, CRC Parameter, All Zero 1, Turn 1, Return Data Packs, Turn 2, and All Zero 2. In a modality, this type of package is generally identified as a Type 65 package. For External Mode, every host must be able to generate this packet and receive the data, and every client must be able to receive and send data to the host. to make efficient use of the desired protocol and the resulting speed. The implementation of this package is optional for the Internal Mode, although the Return Link Encapsulation Pack is used for the host to receive data from the client. The MDDI link driver behaves in a special way while sending a Return Link Encapsulation Pack. The MDD interface has a strobe signal that is generally controlled by the host as a link controller. The host behaves as if it were transmitting at zero for each bit of the Return Pack and Return Data portions of the Return Link Encapsulation packet.

The host alternates an MDDI_Strobe signal in each bit boundary during the two times it is turned over and during the time allocated for the return data packets.

(This is the same behavior as if all data were to be transmitted in zero).

The host disables its online handlers of the MDDI data signal during the time period specified by Turn Round 1, and the client re-enables its online handlers during the field Rehabilitate Handler 'after the period of time specified by the Turn Round 2 field. The customer reads the Turn Length parameter and activates the data signals in the direction of the host immediately after the last bit in the Turn Round 1 field. That is, the customer records the time of the new data within the link at certain MDDI strobe elevation edges as specified in the package content description below, and anywhere else. The client uses the parameters of Packet Length and Turn Length to know the length of time it has available to send the packets to the host. The client can send packets of filler or operate the data lines in the zero state when there is no data to send to the host. If the data lines are set to zero, the host interprets this as a packet with zero length (an invalid length) and the host does not accept any more client packets for the duration of the Current Return Link Encapsulation Pack. The Host activates the MDDI Data signals at the logical zero level during the All in Zero 1 field and the client operates the MDDI data lines at the logical zero level by at least one time period of the return link before the start of the Turn Round 2 field, which is during the All-Zero 2 field period. This keeps the data line in a deterministic state during the time period of the Turn Round 1 and Turn Round 2 fields. has no more packets to send, you can even disable the data lines after driving them to the logical-zero level because the polarization for hibernation resistors (discussed elsewhere) keep the data lines at a zero-level logical for the rest of the Return Data Packet field, or a duration of approximately 16 bytes of the non-return link or more. In one embodiment, the Return Link Request field of the Client Request and the Status Pack can be used to inform the host of the number of bytes the customer needs in the Return Link Encapsulation Pack to send the data back to the host. host. The host attempts to grant the request by allocating at least a number of bytes in the Return Link Encapsulation Pack. The host could send more than one Return Link Encapsulation Pack in a sub-frame. The client can send Client Request and a Status Packet almost at any time, and the host will interpret the Return Link Request parameter as the total number of bytes requested in a sub-frame. 9. Client Capacity Packages A host needs to know the client (deployment) capability with which it is communicating to configure the host-client link in a generally optimal or desired manner. It is recommended that the deployment send a Client Capacity Pack to the host after the synchronization of the non-return link was acquired. The transmission of such a packet is considered to be required when requested by the host using the Return Link Indicators in the Return Link Encapsulation Pack. The Client Capacity Package is used to inform the host of a client's capabilities. For all External Mode the host must be able to receive that package, and every client should be able to send that package to fully use this interface and protocols. The implementation of this package is optional for the Internal Mode, since the client's capabilities, such as a screen, keyboard or other input / output device, in this situation must be already well defined and must be known by the host in the moment of manufacture or assembly within a single component or unit of some kind. The format of the Client Capacity package in a modality is illustrated in FIGURE 18. As shown in FIGURE 18, for this modality this type of package is structured so that it has fields of Packet Length, Package Type, Count ID reserved, Protocol Version, Min Protocol Version, Data Rate Capacity, Interface Type Capacity, Alt Deploy Number, Reserved 1, Bitmap Width, Bitmap Height, Screen Window Width, Height of the Screen Window. Color Map Size, RGB Color Map Width, RGB Capacity, Monochrome Capacity, Reserved 2, Capacity And CrCb, Bayer Compatibility, Alpha-Cursor Image Planes, Client Feature Capacity, Max Video Frame Rate, Video Frame Rate Min., Min. Sub-Frame Rate, Audio Intermediate Memory Depth, Audio Channel Capacity, Audio Sample Rate Capacity, Audio Sample Resolution, Microphone Audio Sample Resolution , Microphone Sample Rate Capacity, Keyboard Data Format, Signal Device Data Format, Content Protection Type, Manufacturer Name, Product Code, Reserved 3, Serial Number, Manufacturing Week, Year of Manufacturing and CRC. In an exemplary mode, this type of package is generally identified as a Type 66 package.

. Keyboard Data Package A keypad data packet is used to send keyboard data from a Client device to the host. A wireless keyboard (or cabling) may be used in conjunction with various display or audio devices, including but not limited to, a head-mounted video display / audio presentation device. The Keyboard Data Pack that transmits the keyboard data received from one or several devices similar to a known keyboard to the host. This package can also be used in the non-return link to send data to the keyboard. A client indicates an ability to send and receive Keypad Data Pack using the Keypad Data Field in the Client Capacity Package. The format of a Keyboard Data Pack is shown in FIGURE 19, and contains a variable number of bytes of information from or for a keyboard. As shown in FIGURE 19, this type of packet is structured to have Packet Length fields, a Packet Type, Client IDb, Keyboard Data Format, Keypad Data, and CRC. Here, this type of packet is generally identified as a Type 67 packet. The ClientIDb is a reserved field, as before, and the CRC is carried out through all the bytes of the packet. The Keyboard Data Format field contains a 2-byte value that describes the keyboard data format. Bits 6 through 0 must be identical for the Keyboard Data Format field in the Client Capacity Package. This value is not equal to 127. Bits 15 through 7 are reserved for future use and therefore, are currently set to zero. 11. Signal Device Data Package A signaling device data packet is used as a method, structure or means for sending position information from a wireless mouse or other pointing device from the Client to the host. The data can also be sent to the signaling device on the non-return link using this package. An exemplary format of a Signal Device Data Package is shown in FIGURE 20, and contains a variable number of bytes of information from or for a pointing device. As shown in FIGURE 20, this type of packet is structured to have Packet Length fields, a Packet Type, Client IDb, a Signal Device Format, Signal Device Data and CRC. In an exemplary mode, this type of packet is generally identified as a Type 68 packet in the type 1 byte field. 12. Link Termination Packages A Link Termination Package is sent from the host to the Customer as a method or means to indicate that the MDDI data and the stroboscope will be closed and directed to a "hibernation" state of low power consumption electric This package is useful for closing the link and conserving the power after the static bitmaps are sent from a mobile communication device to the screen, or when this no more information to transfer from a host to a client at the moment. Normal operation is summarized when the host sends the packets again. The first packet sent after hibernation is a subframe header packet. The format of a Client Status Package for a modality is shown in FIGURE 21. As shown in FIGURE 21, this type of package is structured to have fields of Packet Length, Package Type, CRC, and All in Zeros . In a modality, this type of package is generally identified as a Type 69 package in the type 1 byte field. The packet length field uses 2 bytes to specify the total number of bytes in the packet without including the packet length field. In one embodiment, the packet length of this packet depends on the type of interface or link mode in effect at the time the link interruption packet is sent. Thore, the typical packet length becomes 20 bytes for Type 1 mode (22 bytes in total in the packet), 36 bytes for Type 2 mode (38 bytes in total in the packet), 68 bytes for the packet. Type 3 link mode (70 bytes total in the packet), and 132 bytes for Type 4 mode pun (with 134 bytes total in the packet). The All-in-Zero field uses a variable number of bytes to ensure that the MDDI_Data signals are at a logical zero level or enough time to allow the client to start retrieving the clock using only MDDI_Stb before disabling the handlers of the host line. The length of the All-to-Zero field depends on the Interface Type or link operation mode in effect at the time the Link Interrupt Package is sent. The length of the All-Zero field is intended to produce 64 pulses in MDDI_Stb for any Interface Type setting. Thore, the length of Everything in Zeros for each interface becomes 16 bytes Type 1, 32 bytes for Type 2, 64 bytes for Type 3, and 128 bytes for Type 4. The CRC field uses 2 bytes that contain a 16-bit CRC of the Package Length for the Package Type. In the low-power hibernation state, the MDDI_Data0 handler is disabled in a high-impedance state, which starts after the 16th cycle up to 48 ° of MDDI_Stb after the last bit of the All-Zero field. For Type 2, Type 3 or Type 4 links the MDDI_Datal to MDDI_DataPwr7 signals are also placed in a high impedance state at the same time that the MDDI_DataO handler is disabled. Either the host or the client can cause the MDDI link to "wake up" from the hibernation state as described elsewhlater, which is a key advantage for and an advantage of the present invention. As described in the definition of the All-to-Zero field, MDDI_Stb toggles for 64 cycles after the MSB of the CRC field of the Link Break Package to facilitate an orderly interruption in the client controller. A cycle is a low-to-high transition followed by an elevated-to-low transition, or an elevated-to-low transition followed by a low-to-high transition.

After the All in Zero field is sent, the MDDI__Stb handler on the host is disabled. 13. Client Request and State Packages The host needs a small amount of client information so that he can configure the host-to-client link in a generally optimal manner. It is recommended that the client send a Client Request, and State Package to the host in each sub-frame. The client must send this packet as the first packet in the Return Link Encapsulation Pack, to ensure that it is reliably supplied to the host. For the operation of the external mode, every host must be able to receive this packet in order to properly and optimally use the protocol of the MDD interface. Although it is also recommended that for internal operations, ie internal hosts and internal clients, there must be support for this package, this is not required. The format of a Client Request and State Package is shown in FIGURE 22. As shown in FIGURE 22, this type of package is structured to have fields of Packet Length, Package Type, Count ID, Request for Packet Return Link, Change of Capacity, Graphics Defects, Error Count CRC and CRC.

This type of packet is generally identified as a Type 70 packet in the Type 1 byte field, and typically uses a pre-selected fixed length of 12 bytes. The Return Link Request field can be used to inform the host of the number of bytes the client needs in the Return Link Encapsulation Pack to send data back to the host. The host must attempt to grant the request by allocating at least that number of bytes in the Return Link Encapsulation Pack. The host can send more than one Return Link Encapsulation Pack in a sub-frame to adjust the data. The client can send a Client Request and a State Packet at any time and the host will interpret the Return Link Request parameter as the total number of bytes requested in a sub-frame. Additional details and specific examples of how the return link data returned to the host is sent are shown below. 14. Bit Block Transfer Packages The Bit Block Transfer Pack provides a means, structure or method to slide deployment regions in any direction. Deployments that have this capability will report the capacity in bit O of the Display Capability Capacity Indicators field of the Client Capacity Package. The format for a modality of a Bit Block Transfer Package is shown in FIGURE 23. As shown in FIGURE 23, this type of package is structured to have fields of Packet Length, Packet Type, Client ID , Value X Upper Left, Upper Left Y Value, Window Width, Window Height, Window X Movement, Window Y Movement and CRC. This type of packet is generally identified as a Type 71 packet, and in one mode it uses a preselected fixed length of 15 bytes. The fields are used to specify the X and Y values of the coordinate 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 in which it is moved. it goes. to move the window horizontally, and vertically, in a respective way. Positive values for the last two fields cause the window to move to the right, and down, and negative values cause the movement to be left and up, respectively.

. Bitmap Area Filling Packets The Bitmap Area Filling Pack provides a means, structure or method to easily start a region of the screen for a single color. Screens that have this capability report the capacity in bit 1 of the Customer Feature Capacity Indicators field of the Client Capacity Package. FIGURE 24 shows a format of the Bit Map Area Fill Format. As shown in FIGURE 24, in this case this type of package is structured to have fields of Packet Length, Packet Type, Client ID, Left Upper X Value, Left Upper Y Value, Window Width, Window Height, Data Format Descriptor, Value of Area Fill Pixel, and CRC. This type of packet is generally identified as a Type 72 packet in the type 1 byte field, and uses a pre-selected fixed length of 17 bytes. 16. Bitmap Pattern Filling Packets The Bitmap Pattern Fill Pack provides a means or structure to easily start a region of the screen in a pre-selected pattern.

Screens that have this capacity will report the capacity in bit 2 of the Customer Feature Capacity field of the Client Capacity Package. The upper left corner of the fill pattern is aligned with the upper left corner of the window to be filled, unless the horizontal or vertical pattern offset is not zero. If the window to be filled is wider or taller than the fill pattern, then the pattern can be repeated horizontally or vertically a number of times to fill the window. When necessary, the right or bottom of the last repeated pattern is truncated. If the window is shorter than the fill pattern, then the right or bottom side of the last filled pattern can be truncated to adjust the window. If the displacement of the horizontal pattern is not zero, then the pixels between the left side of the window and the left side plus the horizontal pattern shift are filled in with the pixels that are furthest to the right of the pattern. The horizontal displacement of the pattern will be smaller than the width of the pattern. Similarly, if a vertical displacement of the pattern is not zero, then the pixels between the upper side of the window and the upper part of the pattern shift of the more vertical side are filled with the pixels that are lower than the pattern. The vertical displacement of the pattern will be less than the height of the pattern.

One modality for the formatting of a Bitmap Pattern Fill Pack is shown in FIGURE 25, as shown in FIGURE 25, this type of packet is structured to have fields of Packet Length, Packet Type, ID of Clienth, Left Upper X Value, Left Upper Y Value, Window Width, Window Height, Pattern Width, Pattern Height, Horizontal Pattern Offset, Pattern Vertical Offset, Data Format Descriptor, CRC Parameter, Data Pattern Pixel, and Pixel Data CRC. In some modalities, this type of package is generally identified as a Type 73 package in the type 1 byte field. 17. Link Data Channel Packages Communicate The Communication Link Data Channel Package provides a structure, means, or method for a Customer with a high-level computing capability, such as a PDA, to communicate with a wireless transceiver such as a cell phone or device. of wireless data port. In this situation, the MDDI link is acting as a convenient high-speed interface between the communication device and the computing device with the mobile screen, where this packet transports the data to a Data Link Layer of an operating system for the device. For example, this package could be used if a network browser, customer email or a whole PDA were integrated into a mobile screen. Screens that have this capability will report capacity in bit 3 of the Client Feature Capability field of the Client Capability Package. The format of a modality for a Package of Communication Link Data Channel is shown in FIGURE 26. As shown in FIGURE 26, this type of packet is structured to have fields of Packet Length, Packet Type, Client ID, CRC Parameter, Link Data of Communication, and CRC of Communication Data. In a modality, this type of package is generally identified as a Type 74 package in the type field. 18. Transfer Request Packages Intracellular Type Interface The Transfer Request Package Intracellular Type Interface provides a means, method or structure that enables the host to request that the client or deployment be changed from an existing or current mode to Type 1 (serial), Type 2 (2-bit parallel), Type 3 (4-bit parallel) modes , or Type 4 (8-bit parallel). Before the host requests a particular mode, you must confirm that the client is able to operate in the desired mode by examining bits 6 and 7 of the Deployment Characteristics Indicators field of the Client Capacity Package. One mode for the format of an Intracellular Transfer Type Request Package Interface is shown in FIGURE 27. As shown in FIGURE 27, this type of packet is structured to have fields of Packet Length, Packet Type, Type Interface , Reserved 1 and CRC. This type of packet is generally identified as a Type 75 packet, and uses a pre-selected fixed length of 4 bytes. 19. Interface Type Recognition Packs The Interface Type Recognition Package is sent by a client and provides a means, method or structure that enables a Client to confirm receipt of the Interface Type Intracellular Transfer Package. The requested mode, mode Type 1 (serial), Type 2 (parallel of 2 bits), Type 3 (parallel of 4 bits) or Type 4 (parallel of 8 bits), is reflected back to the host as a parameter in this package . The format of a modality for a Type Interface Recognition Package is shown in FIGURE 28. As shown in FIGURE 28, this type of package is structured to have fields of Packet Length, Packet Type, Count ID, Type Interface, Reserved 1 and CRC. This type of packet is generally identified as a Type 76 packet and uses a pre-selected fixed length of 4 bytes.

. Intracellular Transfer Packs Type Execution The Intracellular Transfer Package Type Execution is a means, structure or method for the host to instruct the client to the intracellular transfer mode specified in this package. This will be the same way as previously requested and recognized by the Intracellular Transfer Type Request Package Interface and the Interface Type Recognition Package. The host and the Client must switch to the mode that was agreed after this packet is sent. The client may lose and regain link synchronization during the mode change. The format of a modality for an Execution Intracellular Transfer Package is shown in FIGURE 29. As shown in FIGURE 29, this type of package is structured to have fields of Package Length, Package Type, Package Type, Reserve 1, and CRC. This type of packet is generally identified as a Type 77 packet in the type 1 byte field, and uses a preset fixed length of 4 bytes. 21. Packages that Enable the Audio Channel Without Return This package provides a structure, method or means that allows a host to enable or disable audio channels on a client. This capability is useful since a customer (for example a deployment) can turn off audio amplifiers or similar circuit elements to save electrical energy when there is no audio produced by the host. This is significantly more difficult to implement simply because it is implicit to use the presence or absence of audio streams as an indicator. The default state when the client's system is on is that all audio channels are enabled. The format of a modality of a No Return Audio Channel Enablement Package is shown in FIGURE 30. As shown in FIGURE 30, this type of packet is structured to have fields of Packet Length, Packet Type, ID of Clienteh, Mask that Enables the Audio Channel, and CRC. This type of packet is usually identified as a Type 78 packet in the type 1 byte field, and uses a fixed pre-selected length of 4 bytes. 22. Return Audio Sample Rate Packets This package allows the host to enable or disable the return link audio channel, and set the sample rate of audio data from this stream. The host selects a sample rate that is defined to be valid in the Client Capacity Package. If the host selects an invalid sample rate then the client will not send an audio stream to the host, and an inappropriate error, error value or error signal may be sent to the host in the Client Error Reporting Package. The host can disable the audio stream of the return link by setting the sample rate to a value of 255. The default state is assumed when the client system is initially switched on or connected to the audio stream of the link. return disabled. FIGURE 31 shows the format of a modality of a Return Audio Sample Speed Package. As shown in FIGURE 31, this type of package is structured to have fields of Packet Length, Packet Type, Client ID, Audio Sample Rate, Reserved 1, and CRC. This type of packet is generally identified as a Type 79 packet and uses a preset fixed length of 4 bytes. 23. Auxiliary Operations Packages for Digital Content Protection This package provides a structure, method or medium that allows a host and a customer to exchange messages related to the digital content protection method that is being used. Currently, two types of content protection are considered, the Protection of Digital Transmission Content (DTCP), or the Digital Broadband Content Protection System (HDCP), with space reserved for future alternative protection scheme designations. . The method that is used is specified by a parameter of the Content Protection Type in this package. The format of a modality of a Digital Content Protection Auxiliary Operations Package is shown in FIGURE 32. As shown in FIGURE 32, this type of packet is structured to have fields of Packet Length, Packet Type, ID of Clientb, Type of Content Protection, Messages of Auxiliary Operations of Content Protection and CRC. This type of package is generally identified as a Type 80 package. 24. Packages that Enable Transparent Color The Pack that Enables Transparent Color is a structure, method, or medium that is used to specify which color is transparent on a screen and to enable or disable the use of a transparent color for images that are displayed. Screens that have this capability will report that capacity in bit 4 of the Customer Capability Capacity field of the Client Capacity Package. When a pixel with the value for transparent color is written to the bitmap, the color does not change from the previous value. The format of a Transparent Color Enablement Package is shown in FIGURE 33. As shown in FIGURE 33, in a modality this type of package is structured to have fields of Packet Length, Packet Type, Client ID, Enable Transparent Color, Reserved 1, Alpha-Cursor Identifier, Data Format Descriptor, Transparent Pixel Value and CRC. This type of packet is generally identified as a Type 81 packet in the Type 1 byte field, and uses a pre-selected fixed length of 10 bytes.

. Round Trip Delay Measurement Packs The Round Trip Delay Measurement Package provides a structure, method, or means used to measure the propagation delay from the host to the client (deployment) plus the delay of the delay. client (display) back to the host. This measurement inherently includes the delays that exist in online handlers and receivers, and an interconnection subsystem. This measurement is used to establish round rotation delay and the parameters of the return link velocity divider in the Return Link Encapsulation Package, described generally above. This package is most useful when the MDDI link is running at the maximum speed intended for a particular application. The MDDI_Stb signal behaves as if all data at zero were being sent during the following fields: both, Guard Times, All at Zero, and the Measurement Period. This causes MDDI_Stb to alternate at half the data rate so that it can be used as a measure of the periodic time in the client during the Measurement Period. . In one embodiment, a client generally indicates a capability to support the Round Trip Delay Measurement Package through the use of 18 bits of the Client Feature Capacity Indicators field of the Client Capacity Package. It is recommended that all clients support the measurement of round trip delay, although it is possible for the host to know the worst case of round trip delay based on a maximum cable delay, and the maximum delays of the handler and receiver . The host can also know the round trip delay in advance for an MDDI link that is used in the internal mode, since this is an aspect of known design elements (conductor lengths, type of circuits and characteristics, etc.) of the device in which the interface is being used. The format of a Round Trip Delay Measurement Package is shown in FIGURE 34. As shown in FIGURE 34, in one embodiment, this type of package is structured to have Packet Length, Package Type, Client ID, CRC Parameter, Guard Time 1, Measurement Period, All-Zero, and Guard-Time 2. This type of packet is generally identified as a Type 82 packet, and uses a pre-selected fixed length of 159 bits . The timing of the events that take place during the Round Trip Delay Measurement Package is illustrated in FIGURE 35. In FIGURE 35, the host transmits the Round Trip Measurement Package, which is displayed by the presence of the CRC Parameter fields and Stroboscope Alignment followed by the All in Zeros and Guard Time fields 1. A 3502 delay occurs before the packet reaches the client deployment device or processing circuits. When the client receives the packet, it transmits the Oxff, Oxff, and 30 bytes of 0x0 as precisely as practical at the start of the Measurement Period as determined by the client. The actual time in which the Client begins to transmit this sequence is delayed from the beginning of the Measurement Period from the host's point of view. The amount of this delay is substantially the time it takes for the packet to propagate through the handlers and receivers of the line and the interconnection subsystem (wires, conductors). A similar amount of delay 3504 is incurred for the pattern to propagate from the client back to the host. To accurately determine the round trip delay time for the signals going to and from the client, the host counts the number of bit time periods of the non-return link that occur after the start of the Measurement Period until the start of Oxff, Oxff and 30 bytes of the 0x0 sequence that are detected upon arrival. This information is used to determine the amount of time for a round-trip signal that passes from the host to the client and returns again. In addition, about half of this amount is attributed to a delay created by a single-directional passage of a signal to the customer. The host and the client both operate the line for a zero-logical level during both guard times to keep the MDDI_DATA lines in a defined state. The enabling and disabling times of the host and the client during both guard times are those in which the MDDI_Data signals are at a valid low level for any valid round trip delay time. 26. Bind Non-Return Bias Calibration Package The Bind Non-Return Bias Calibration Package allows a client or screen to self-calibrate the differences in the propagation delay of the MDDI_Data signals with respect to the MDDI_Stb signal. Without delay bias compensation, the maximum data rate is generally limited to justify a potential variation in the worst cases in those delays. Typically, this packet is only sent when the data rate of the non-return link is configured for a rate of approximately 50 Mbps or lower.

After sending this packet to calibrate the screen, the data rate can be staggered above 50 Mbps. If the data rate is set too high during the bias calibration process, the screen could be synchronized with an alias of the period of bit that could cause the delay bias compensation to be set to off for more than one bit time, resulting in recording the wrong data time. The highest data rate type of interface or largest Interface Type possible is selected prior to sending the Bind Calibration Package of the No Return Link so that all existing data bits are calibrated. A Format Mode of the No Return Bias Calibration Package is shown in FIGURE 56. As shown in FIGURE 56, this type of packet is structured to have Packet Length fields (2 bytes), Package Type , Client ID, CRC Parameter, All in Zero, Calibration Data Sequence and CRC. This type of package is generally identified as a Type 83 package in the type field, and in one mode it has a pre-selected length of 515.

Virtual Control Panel The use of a Virtual Control Panel (VCP) allows a host to set certain user controls on a client. By allowing those parameters to be set by the host, the user interface on the client can be simplified because screens that allow a user to adjust parameters such as the audio volume or brightness of the display can be generated by the host's software instead of using one or more microprocessors in the client. The host has the ability to read the parameter settings in the client and to determine the range of valid values for each control. The client usually has the ability to return to the host which control parameters can be adjusted. The control codes (VCP codes) and the associated data values generally specified are used to specify the controls and settings in the client. The VCP Codes in the MDDI specification are expanded up to 16 bits to preserve the appropriate data field alignment in the package definitions, and in the future to support supplementary values that are unique to this interface or future enhancements. 27. Request VCP Feature Pack The Request VCP Feature Pack provides a means, mechanism or method for the host to request the current setting of a specific control parameter or all valid control parameters. Generally, a customer responds to a VCP Package with the appropriate information in a VCP Feature Response Package. In one embodiment, the client indicates a capability to support the VCP Request Feature Pack that uses 20 bits of the Indicators field of. Customer Characteristics Capacity of the Client Capacity Package. The format of the Request VCP Feature Pack in a modality is shown in FIGURE 69. As seen in FIGURE 69, this type of packet is structured to have fields of Packet Length, Packet Type, Client ID, Code VCP MCCS, and CRC. This type of package is usually identified in a modality such as Type 128, which is indicated in the field type 2 bytes. The Packet Length, which specifies the total number of bytes in the packet does not include the packet length field, typically is set for this packet type in a length of 8 bytes. The Client ID field is reserved for use as a Client ID in future implementations and typically is set to zero. The VCP MCCS Code field comprises 2 bytes of information that is specified by the VCP MCCS Control Code Parameter. A value in the range of 0 to 255 causes a VCP Feature Response Pack to be returned with a single element in the VCP Feature Response List that corresponds to the specified MCCS code. A VCP MCCS code of 65535 (Oxffff) requests a VCP Feature Response Package with a VCP Feature Response List containing a Feature Response List Element for each control supported by the client. The values from 256 to 65534, for this field, are reserved for future use and are not used at present. 28. VCP Feature Response Package The VCP Feature Response Package provides a means, mechanism, or method for a client to respond to a host request with the current setting of a specific control parameter or all valid control parameters. Generally, a client sends the VCP Feature Response Package in response to a Request VCP Feature Pack. This package is useful for determining the current setting of a specific parameter to determine the valid range for a specific control, to determine if a specific control is supported by the client, or to determine the set of controls that are supported by the client. If a request VCP characteristic is sent and refers to a specific control that is not implemented in the client then a VCP Feature Response Package is returned with a single element of the VCP Feature Response List that corresponds to the non-implemented control which contains the appropriate error code. In one embodiment, the client indicates a capability to support the VCP Feature Response Pack using 20 bits of the Client Feature Capability field of the Client Capability Package. The format of the Response Package VCP feature in a modality shown in FIGURE 70. As can be seen in FIGURE 70, this type of packet is structured to have Packet Length, Packet Type, Count ID, MCCS Version, Sequence Number Response, VCP Feature Response List and CRC. This type of packet is generally identified in a mode as a Type 129, such as the one indicated in the type 2 bytes field. The Count ID field contains information reserved for a Client ID. This field is reserved for future use and generally adjusts to zero. The MCCS version field contains 2 bytes of information that specify the Version of the VESA MCCS Specification implemented by the client. The 2-byte Response Sequence Number field contains information or data that specifies the sequence number of the VCP Feature Response Packets returned by the client. The client returns one or more VCP Feature Response Packets in response to a request VCP Feature Pack with a MCCS Control Code value of 65535. The client can distribute the feature's response list across multiple Packages of Characteristic Response VCP. In this case, the client assigns a sequence number for each successive packet, and the sequence numbers of the VCP Feature Response Packets sent in response to a single request VCP Feature Pack starts at zero and is incremented by one . The last Element of the VCP Feature List in the last VCP Feature Response Pack must contain a VCP MCCS Control Code value equal to Oxffff to identify that the packet is the last and contains the highest sequence number in the group of returned packages. If only one VCP Feature Response Package was sent in response to a request VCP Feature Pack then the Response Sequence Number in that single packet is zero and the VCP Feature Response List contains a record that has a code of MCCS control of VCP equal to Oxffff.

The Feature Number in this list field contains 2 bytes that specify the number of VCP Feature List Elements that are in the VCP Feature Response List in this packet, while the VCP Feature Response List field is a group of bytes that contains one or more elements of the VCP Feature Response List. The format of a single VCP Feature Response List Element is a modality shown in FIGURE 71. As shown in FIGURE 71, each Feature Response List Element VCP is 12 bytes long, and comprises the MCCS code fields of VCP, the Result Code, the Maximum Value and Present Value. The 2-byte VCP MCCS Code field contains the data or information that specifies the VCP MCCS Control Code Parameter associated with this list item. Only the Control Code values defined in the VESA MCCS Specification of version 2 and later are considered valid for this modality. The 2-byte Result Code field contains information that specifies an error code related to the information request with respect to the specified VCP MCCS Control. A value of 0 'in this field means that there is no error, although a value of? L' means that the specific control was not implemented in the client. The additional values in this field from 2 to 65535 are currently reserved for future use and for its implementation of another application contemplated by the technique, although not for use for now. The Maximum Value field of 4 bytes contains a 32-bit unsigned integer that specifies the largest possible value for which the specified MCCS Control can be set. If the requested control is not implemented in the client, this value is set to zero. If the returned value is less than 32 bits (4 bytes) in length, then the value is distributed among a 32-bit integer, leaving the most significant (unused) bytes set to zero. The 4-Byte Present Value field contains information that specifies the present value of the continuous (C) MCCS or non-continuous (NC) control of the specified VCP. If the requested control is not implemented in the client or if the control is implemented but is a type of table (T) data, then this value is set to zero. If the return value is less than 32 bits (4 bytes) in length per VESA MCCS Specification then the value is spread over a 32-bit integer leaving the most significant (unused) bytes set to zero. 29. Adjusted VCP Feature Package The Adjusted VCP Feature Package provides a means, mechanism or method for a host to adjust the VCP control values for both continuous and non-continuous controls in a client. In one embodiment, the client indicates the ability to support the Adjusted VCP Feature Pack using 20 bits of the Client Feature Capability field of the Client Capability Package. The format of the VCP Feature Pack Adjusted in a modality is shown in FIGURE 72. As can be seen in FIGURE 72, this type of package is structured to have fields of Packet Length, Packet Type, Client ID, VCP MCCS Code, Number of Values in List, Control Value List and CRC. This type of packet is generally identified as a Type 130, as indicated by the 2-byte type field, and is 20 bytes in length exclusively for the Packet Length field. The Client 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 VCP MCCS Code field uses 2 bytes of information or values to specify the VCP MCCS Control Code Parameter to be adjusted. The number of 2-byte values in the list field contains information or values that specify the number of 16-bit values that exist in the Control Value List. The Control Value List will usually contain an element unless the MCCS Control Code is related to a table in the client. In the case of controls not related to a table, the Control Value List will contain a value that specifies a new value to be written for the control parameter specified by the VCP MCCS Code field. For controls related to the table, the format of the data in the Control Value List is specified by the description of the specified VCC MCCS Code parameter. If the list contains values that are larger. than one byte, then the last 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.

. Valid Request Parameter Packet The Valid Request Parameter Packet is used as a useful means or structure to request a client to return a Valid Parameter Response Package that contains a list of parameters supported by non-continuous (NC) control or table (T) specified. This package should only specify non-continuous controls or controls that relate to a table in the client, and not specify a VCP MCCS Code value of 65535 (Oxffff) to specify all controls. If an unsupported or invalid VCP MCCS Code is specified then an appropriate error value is returned in the Valid Parameter Response Package. In one embodiment, the client indicates a capability to support the Valid Request Parameter Package using 20 bits of the Client Feature Capability field of the Deployment Capability Package. The format of the Valid Parameter Package of request in one modality is shown in FIGURE 73. As can be seen in FIGURE 73, this type of package is structured to have Packet Length fields, a Package Type, Client ID, VCP MCCS Code, and CRC.

This type of packet is usually identified in a mode such as Type 131, as indicated in the type 2 bytes field. The packet length, as indicated in the 2-Byte Packet Length Field is generally set to have a total number of bytes in the packet, not including the packet length field of 8. The Client ID again Specifies the Customer ID, but it is currently reserved for a future use, as it will be apparent to those who have experience in the technique, and it is adjusted to zero. The 2-byte VCP MCCS Code Field contains a value that specifies the Non-Continuous VCP MCCS Control Code Parameter to be queried. The value in this field must correspond to a non-continuous control that is implemented in the client. Values 256 to 65535 (Oxffff) are typically reserved or considered invalid, and are considered as a control not implemented in the error response. 31. Valid Parameter Response Package A Valid Parameter Response Package is sent in response to the Valid Parameter Response Package. It is used as a means, method or structure to identify the valid settings for a non-continuous VCP MCCS control or a control that returns the contents of a table. If the control is related to a table in a client, then the response list of the VCP parameter simply contains the specific list of sequential table values that were requested. If the contents of the table can not be adjusted within a single Valid Parameter Response Package then multiple packets with Sequential Response Sequence Numbers can be sent by the client. In one embodiment, a client indicates a capability to support a Valid Parameter Response packet using 20 bits of the Customer Capability Capability field of the Client Capability Package. A host may request the contents of a table in the following manner: the host sends a VCP Feature Package of Adjustment containing the necessary or desired parameters such as the read / write parameter, the LUT shift and the RGB selection; then a Valid Application Parameter Package that - specifies the desired control is sent through the host; then the client returns one or more Response from Valid parameter that contain the data of the table. This sequence of operations performs a similar capacity as that of the reading functions of the table described in the MCCS operation model. If a parameter of the specific client is not supported by the client then in a modality the corresponding field of this package will contain a value of 255. For the parameters that are used in the client, the corresponding field must contain a value of the parameter in the client . The format of the Valid Parameter Response Package for a modality is shown in FIGURE 74. As can be seen in FIGURE 74, this type of packet is structured to have fields of Packet Length, Packet Type, Count ID, Code VCP MCCS, Response Code, Response Sequence Number, Number Values in the List, Response List of the VCP Parameter and CRC. This type of packet is generally identified for a mode such as Type 132, as indicated in the 2-byte type field. The Client ID field is reserved for the Future Client ID, as known from the previous discussions, although the 3-byte VCP MCCS Code Package contains a value that specifies a VCP MCCS Control Code Parameter. is described by this package. If an invalid VCP MCCS Control Code is specified by a Valid Request Parameter Pack, then the same invalid parameter value will be specified in this field with the appropriate value in the Response Code field. If the MCCS Control Code is invalid then the Response List of the VCP Parameter will have a length of zero. The Response Code field contains 2 bytes of information or values that specify the nature of the response that relates to the request for information with respect to the specified VCP MCCS Control. If the value in this field is equal to 0, then the error for this type of data is not considered to be present, and the last Valid Parameter Response in the sequence is sent, having the highest Response Sequence Number. If the value in this field is equal to 1, then the error is not considered to be present, although other Valid Parameter Response Packets having a higher sequence number may be sent. If the value in this field is equal to • 2, then the specified control is not considered to be implemented in the client. If the value in this id field equals 3, then the specified control is not a control that it is not continuous (it is a continuous control that always has a valid set of all values from zero to its maximum value). Values for this field equal to 4 to 65535 are reserved for future use and are generally not used. The 2-byte Replication Sequence Number field specifies the sequence number of the Valid Parameter Response Packs returned by the client. The client returns one or more Valid Parameter Answer Packs in response to a Valid Request Parameter Package. The client can distribute the VCP Parameter Response List through multiple valid Parameter Answer Packs. On this last 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 Response Package in the sequence will have the highest Response Sequence Number and the Response Code contains a value of 0. The Number of 2-Byte Values in the field of List specifies the number of 16-bit values that exist in the VCP Parameter Response List. If the Response Code is not equal to zero then the Number of Values in the List parameter is zero. The VCP Parameter Response List field contains a list of 0 to 32760 2-byte values that indicates the set of valid values for the non-continuous control specified by the MCCS Control Code field. Definitions of control codes that are not continuous are specified in the VESA MCCS Specification. Finally, in this mode the CRC field contains a 16-bit CRC of all bytes in the packet including the Packet Length.

Alpha-Cursor Images The MDD interface and the associated inventive mechanisms and protocol for communicating data through a communication link provide support for multiple overlapping image planes that may have varying degrees of transparency. A hardware cursor can be implemented using the superimposed image that has a variable X-Y offset. An overview of the Alpha-Cursor functionality and the associated protocol support is provided below. The ability to support Alpha-Cursor image packets is defined in the Alpha-Cursor Image Capability Pack, which is sent in response to a Request Specific Status Pack. 32. Alpha-Cursor Image Capability Package The Alpha-Cursor Image Capability Package is used to define the characteristics of the alpha-cursor image and the associated transparency maps in a client. In one embodiment, a client indicates a capability to support an Alpha-Cursor Image Capability Pack using a parameter value of 133 in the Valid Parameter Response List of the Valid State Response List Package. The Package Length specified in the packet length field is set to a fixed value of 20 for a mode, not including the packet length field. The Alpha-Cursor Image Capability Package format for a modality is shown in Figure 75. As seen in Figure 75, this type of package is structured to have Packet Length, Package Type, Client ID fields , Alpha-Cursor Identifier, Alpha-Cursor Bit Map Width, Alpha-Cursor Bit Map Height, RGB Capacity, Monochrome Capacity, Reserved 1, Capacity Y Cr Cb, Transparency Map Response, Capacity Bits and CRC. The Customer ID field is typically reserved for future use of the Client ID and is currently set to zero. The Alpha-Cursor Identifier field (2 bytes) contains a value that identifies a specific Alpha-Cursor plane. If the client supports an alpha-cursor image plane n then the Alpha-Cursor Identifier has a valid range of 0 to n-1. In a modality, the value n is specified by the Alpha-Cursor Image Planes field of the Client Capacity Package. The client returns a unique Alpha-Cursor Image Capability Pack for each Alpha-Cursor image plane. The value of the 2-byte Alpha-Cursor Bitmap Width field specifies the image width of the alpha-cursor bitmap expressed as a number of pixels, although the value of the Alpha-Cursor Bitmap Height field of 2 bytes specifies the height of the alpha-cursor bitmap image expressed as a number of pixels. The RGB Capacity field uses 2 bytes to specify the number of resolution bits that can be displayed in the RGB format. If the client can not use the RGB format then this value is zero. The word RGB Capacity is composed of three separate values, which in one mode are implemented so that: Bits from 3 to 0 define the maximum number of blue bits (blue intensity) in each pixel; Bits 7 through 4 define the maximum number of green bits (green intensity) in each pixel; Bits 11 to 8 define the maximum number of red bits (intensity of red) in each pixel; and Bits 15 through 12 are reserved for future use when presenting the RGB capability information so they are generally set to zero for now. The 1-byte Monochrome Capacity field is used to specify the number of resolution bits that can be displayed in the monochrome format. If a client can not use the monochrome format then this value is set to zero. Bits 7 through 4 are reserved for future use and, therefore, are generally set to zero. Bits 3 through 0 define the maximum number of gray scale bits that can exist in each pixel. These four bits make it possible to specify that each pixel consists of 1 to 15 bits. If the value is zero, then the monochrome format is not supported by the client. The 1 byte reserved field 1 contains a value generally reserved for future use, and just as all the bits in that field are set to zero. This will cause your frequent 2-byte fields to align with the 16-bit word address and cause the 4-byte fields to be aligned with a 32-bit word address. The 2-byte capacity Y Cb Cr field contains values or information that specify the number of resolution bits that can be displayed in the Y Cb Cr format. If the client can not use the Y Cr Cb format then this value is zero. Generally, in one modality, the word Capacity Y Cb Cr is composed of three separate values with: Bits 3 to 0 that define a maximum number of bits specified by the sample Cr; Bits 7 to 4 that define the maximum number of bits specifying the sample Cb; Bits 11 to 8 that define the maximum number of bits that specify the sample Y; and with Bits 15 to 12 that are reserved for a future use in the presentation of information or the values of Capacity Y Cb Cr, although it is currently set to zero. The 1-Byte Transparency Map resolution field contains values or information that specify the number of bits (depth) in each pixel location of the alpha-cursor image transparency map. This value can vary from 1 to 8. If the value is zero then the transparency map is not supported by this alpha-cursor image buffer (the buffer specified by the Alpha-Cursor Identifier Field). Values or information are provided for the 1-byte Bits Capacity field that contains a set of indicators that specifies the capabilities associated with the alpha-cursor image buffer. In one mode, the indicators are defined so that: Bit 0 acts to select the Pixel data in the Alpha-Cursor Video Current Package that will be in a packed format. Bit 1 acts to show that the transparency map data in the Alpha-Cursor Transparency Package is in a packet format. An example of the aligned byte and the packed Transparency Map Data are shown in Figure 76. Bit 2 acts to show that the alpha-cursor image plane supports the ability to image shift using the Alpha Image Shift Package. Cursor. Bit 3 acts to show that the alpha-cursor image plane can support a color map data format. The same color map table is used for the alpha-cursor image planes since it is used for the main image buffer and the scaled video streams. The color map is configured using the Color Map Package described above. Bits 7 through 4 are reserved for future use and are generally, therefore, set at a level of zero or a logical value. 33. Alpha-Cursor Transparency Map Package The Alpha-Cursor Transparency Map Package defines the content of the transparency map of the image for the specified alpha-cursor image plane. Some applications may require a transparency map that is larger than the amount of data that can be transmitted in a single package. In those cases, multiple Alpha-Cursor Transparency Map Packs can be sent, each with a different subset of the transparency map when using the Transparency X and Home Map fields and described below. These fields operate in a similar way to the Start X and Start Y fields of the Video Stream Package. A client indicates a capability to support the alpha-cursor transparency map package in one modality using the Transparency Map Resolution field of the Alpha-Cursor Image Capability Package for each specific Alpha-Cursor Plane specified by the Alpha Identifier field -Cursor of the Alpha-Cursor Image Capability Package. The Packet Length and Client ID fields operate as previously discussed for other packages. In a modality, a value of 134 in the Package Type field is used to identify a package as an Alpha-Cursor Transparency Map Package. The format of the Alpha-Cursor Transparency Map Package for a modality is shown in Figure 76. As shown in Figure 76, this type of package is structured to have a Packet Length field, Package Type, Client ID , Alpha-Cursor Identifier, X Home of Transparency Map, Home and Transparency Map, Transparency Map Resolution, Reserved 1, CRC Parameter, Transparency Map Media and Transparency Map Data CRC. The 2-Byte Alpha-Cursor Identifier field has a value that identifies a specific alpha-cursor plane. If the client supports alpha-cursor image planes n then the Alpha-Cursor Identifier has a valid range of 0 to n-1. The Start X and Y fields of the 2-Byte Transparency Map each specify the absolute coordinates X and Y, where the point (Start Y of Transparency Map, Start X of Transparency Map) is the first pixel in the field of the Transparency Map Data below. The Transparency Map Resolution field of (1 byte) contains a value that specifies the resolution of the transparency map and whether the data is packed or not. In a modality of this field, Bits 3 to 0 define the number of bits of the resolution that exist in all the elements of the transparency map table. Valid values specify the width from 1 to 8 bits. Values 0 and 9 to 15 are considered invalid. This value must correspond to the value returned by a client in the Resolution field of the Transparency Map in the Alpha-Cursor Image Capability Package. Bits 6 through 4 are reserved for future use and, therefore, are generally set to zero-logical at this time. Bits 7 of this byte specify whether the Transparency Map Data is packed or not or in the form of an aligned byte. If bit 7 is equal to? L 'then the Map Data Transparency is in packet form, and if it is 10' the data is byte aligned. An example of the packed data and aligned byte of the Transparency Map is displayed elsewhere. The value of this bit must correspond to the value of bit 1 of the Capacity Bits field of the Alpha-Cursor Image Capability Package. The 1-byte reserved field 1 is reserved for future use, therefore, all bits in this field are generally set equal to a logical-zero level. The purpose of this field is to cause all subsequent 2-byte fields to be aligned with a 16-bit word address and cause the 4-byte fields to be aligned with 32-bit word addresses. The CRC Parameter field contains a 16-bit CRC of all bytes of the Packet Length in the Reserved field 1. If this CRC fails to verify, then the whole package is discarded. For the Transparency Map Data field, each transparency map location is 1 to 8 bits wide. If a single transparency map can not be set within an Alpha and Cursor Transparency Map Package, then the entire transparency map can be specified by sending multiple packages with different Transparency Map Data and Start X and Y values of the transparency map in each package. The CRC field of Transparency Map Data of 2 bytes contains a 16-bit CRC of only the Transparency Map Data. If this CRC fails to verify, then the Transparency Map Data can still be used even though the CRC error count is increased. 34. Alpha-Cursor Image Offset Package The Alpha-Cursor Offset Image Offset specifies the X and Y offset of the cursor in the upper left corner of the main display image. The format of the Alpha-Cursor Image Shift Package is illustrated in Figure 77. As shown in Figure 77, in one embodiment, the Alpha-Cursor Image Shift Package is structured with Packet Length, Type of Package, Client ID, Alpha-Cursor X Offset, Offset And Alpha-Cursor, and CRC. In one embodiment, a client indicates the ability to support the Alpha-Cursor Image Shift Package using 2 bits of the Capacity Bits field of the Alpha-Cursor Image Capability Package for each specific Alpha-Cursor plane specified by the Identifier field Alpha-Cursor of the Alpha-Cursor Image Capability Package. In one mode, the packet length is set to 10, as shown in the 2-Byte Packet Length field. In one embodiment, a Packet Type of 135 identifies the packet as an Alpha-Cursor Image Shift Package. The Shift X and Y Alpha-Cursor 2-byte fields contain values that specify the horizontal and vertical, respectively, the displacement of the leftmost column and the upper row, respectively, of pixels of the cursor image on the left and top side of the main image. The Client_ID - 2 bytes containing an unsigned 16-bit integer reserved for the Client ID. This field is reserved for future use and is generally set at zero-logical levels or values for the bits.

. Alpha-Cursor Video Streaming Package The Alpha-Cursor Video Streaming Package carries video data to update a rectangular region of an alpha-cursor image plane. The size of this region can be as small as a single pixel or as large as the full screen. The Alpha-Cursor Video Streaming Package format is illustrated in Figure 78. As shown in Figure 78, in one embodiment the Alpha-Cursor Video Streaming Package is structured with Packet Length fields, Package Type , Client IDb, Video Data Format Attributes, Left Edge X, Top Edge Y, Right Edge X, Bottom Edge Y, Start X, Start Y, Pixel Count, Pixel Data of the Crc Parameter and Data CRC Pixel In one embodiment, a client indicates a capability to support the Alpha-Cursor Video Stream Package and its associated parameters when using the Alpha-Cursor Image Capability Pack for each specific Alpha-Cursor Plane specified by the Alpha-Cursor Identifier field , of the Alpha-Cursor Image Capability Pack, and a value of 17 in the packet type field indicates or identifies a packet that is an Alpha-Cursor Video Stream Package. The Clienth ID field (2 bytes) is reserved for future use as a Client ID, and is generally set to zero in the meantime, as will be well understood in the art. The 2-Byte Video Data Format descriptor field contains information or a value that specifies the format of each pixel in the Pixel Data in the current present in the present packet. The pixel data format must meet at least one of the valid formats for the alpha-cursor image plane as defined in the Alpha-Cursor Image Capability Package. The Video Data Format Descriptor field contains a value that defines the Pixel format for the current packet only and does not imply that a constant format will continue to be used for the lifetime of a particular video stream. The Figure HA A HE, above illustrates how the Video Data Format Descriptor is encoded. The format is as follows: In one mode, when the bits [15:13] are? 000 'then the video data consists of a series of monochrome pixels where the number of bits per pixel is defined by the 3 bits to 0 of the word Video Data Format Descriptor. Bits 11 to 4 are then set to zero. When the bits [15:13] are Y01 'then the video data consists of a series of color pixels that each specify a color through a color map (palette). Bits 5 to 0 of the word Video Data Format Descriptor define the number of bits per pixel, and bits 11 to 6 are set to zero. When the bits [15:13] are v010 'then the video data consists of a series of color pixels in a RGB format in the primary state where the number of bits per pixel of the red is defined by bits 11 to 8, the number of bits per pixel of green are defined by bits 7 to 4 and the number of bits per pixel of blue are defined by bits 3 to 0. The total number of bits in each pixel is the sum of the number of bits used for red, green and blue. When the bits [15:13] are? 011 'then the video data consists of a series of video data in the 4: 2: 2 and Cb Cr format with luminance and chrominance information. The number of bits per pixel of the luminance(Y) is defined by bits 11 to 8, the number of bits of component Cb is defined by bits 7 to 4, and the number of bits of component Cr is defined by bits 3 to 0. Components Cb and Cr are sent at half the speed of Y. The video samples in the Pixel Data portion of this packet will be organized in this way: 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 etc. Yn, Yn + 1, Yn + 2 and Yn + 3, are luminance values of four consecutive pixels in a single row from left to right. The ordering of the color components is the same as the Microsoft UYVY FOURCC format. If there is an odd number of pixels in a row (Right Edge X - Left Edge X + l) in the window referenced by the Video Stream Package then the value Cb that corresponds to the last pixel in each row will be followed by the Y value of the first pixel in the next row. It is recommended that windows that use the Y Cb Cr format have a width that is an even number of pixels. The Pixel Data in a packet contains an even number of pixels. They can contain numbers of odd or even pixels in the case where the last pixel of the Pixel Data corresponds to the last pixel of a row in the window specified in the header of the Video Stream Package, that is, when the location X of the last pixel in the Pixel Data is equal to the Right Edge X. For all five formats, bit 12 (designated "P" in the figures) specifies whether the Pixel Data samples are packaged or not. When the value of bit 12 is '0' then each pixel and each color within each pixel in the Pixel Data field this byte is aligned with an MDDI interface byte limit. When the value of bit 12 is Y 'then each pixel and each color within each pixel in the Pixel Data are packaged against the previous pixel or color within a pixel that leaves unused bit. In one embodiment, the Pixel Data Attributes field (2 byte) has a series of bit values that are interpreted as follows. Bits 1 and 0 select how the display pixel data is routed. For the bit values of? 11 ', the data is displayed for both eyes, for the YO' bit values, the data is routed only for the left eye, and for the 101 'bit values, the data is routed only to the right eye. Bit 2 of the Pixel Data Attributes field indicates whether the pixel data is present or not in an interlaced format with a value of? 0 'meaning that the Pixel data is in the standard progressive format, and that the number row (Pixel Y coordinate) is incremented by 1 when advancing from one row to the next. When this bit has a value of Y ', the Pixel data is in the interlace format, and the number of rows increases by 2 when advancing from one row to the next. Bit 3 indicates that the Pixel Data is in an alternate pixel format. This is similar to the standard interleaving mode enabled by bit 2, although the interlacing is vertical instead of horizontal. When bit 3 is at 10 'the Pixel Data is in the standard progressive format, and the column number (pixel X coordinate) is increased by 1 as each succeeding pixel is received. When Bit 3 is Y 'the Pixel Data is in an alternate pixel format, and the number of columns is increased by 2 as each pixel is received. Bit 4 of the Pixel Data Attributes field indicates whether or not the Pixel data relates to a screen or a camera, such as when data is being transferred to or from an internal display for a wireless phone or similar device or even a laptop, or such other devices as those discussed above, or data that is transferred to or from an integrated camera within or directly coupled with the device. When Bit 4 is Y 'the pixel data is transferred to or from a screen frame buffer. When bit 4 is? L 'the pixel data that is transferred to or from a camera or video device of some kind, such devices are well known in the art. Bit 5 of the Data Attributes field of. Pixel is reserved for future use or for applications of the MDD interface and is, therefore, generally set to the value of zero or * 0 '. Bits 7 and 6 of the Pixel Data Attributes field are display update bits that specify a frame buffer in which the Pixel data is to be written. More specific effects are discussed elsewhere. For the bit values of x01 'the Pixel data is written to the buffer of the off-line image. For the YO 'bit values of the Pixel data are written to the image buffer used to refresh the display. For bit values of ll 'of the pixel data are written for all image buffers. The bit values or the combination of? 10 'are treated as an invalid value or designation and the Pixel data is ignored or not written to any of the buffers in the image. This value can have a use for future applications of the interface. Bits 8 to 15 of the Pixel Data Attributes field are reserved for future use and therefore, are generally set to zero. In one mode, the Start X and Start Y 2-byte fields specify the absolute X and Y coordinates of the point (Start X, Start Y) for the first pixel in the Pixel Data field. The fields of the Left Edge X and Upper Edge Y of 2 bytes specify the X coordinate of the left edge and the Y coordinate of the upper edge of the alpha-cursor image window populated by the Pixel Data field, while the Right Edge fields X and Bottom Edge Y specify the X coordinate of the right edge and the Y coordinate of the bottom edge of the alpha-cursor image window that is being updated. The Pixel Count field (2 bytes) specifies the number of pixels in the Pixel Data field below. The 2-byte CRC Parameter field contains a CRC of all bytes of the Packet Length in the Pixel Count. If this CRC fails to verify then the entire packet is discarded. The Pixel Data field contains the video information in the primary state that is being displayed, and which is formatted in the manner described by the Video Data Format Descriptor field.

The data is transmitted in a "row" at a time that will be discussed later. The CRC field of the Pixel Data (2 bytes) contains a 16-bit CRC of only the Pixel Data. If a CRC check of this value fails then the Pixel Data can still be used, but the error count of the CRC is increased.

Scaled Video Stream Images The MDD protocol interface or mechanism, structure, medium or method provides support for scaled video stream images that allow the host to send an image to the client that is scaled larger or smaller than the original image, and the scaled image is copied to a main image buffer. An overview of the functionality and support of the associated protocol of the Escalated Video Stream is provided below. A capability to provide scaled video stream is defined by or within the Video Scaled Stream Capacity Pack, which is sent in response to a Request Specific Status Pack. 36. Climbing Video Streaming Capacity Package The Climbing Video Streaming Capacity Package defines the characteristics of the source image of the video stream scaled or used by a customer. The format of the Scaled Video Stream Capacity Pack is generally shown in Figure 79. As can be seen in Figure 79, in one mode, a Scaled Video Stream Capacity Pack is structured to have Packet Length fields , Type of Package, Customer ID, Maximum Current Number, Maximum Font Size X, Maximum Font Size Y, RGB Capacity, Monochrome Capacity, Reserved 1, Capacity Y Cr Cb, Reserved 2 and CRC. The packet length in a mode is selected to be set to 20 bytes as shown in the length field, which includes the field of the 2-byte clientc ID, which is reserved for use for a Client ID, or otherwise it is set to zero, and the CRC field. In one embodiment, the client indicates a capability to support the scaled video stream capacity packet by using a parameter value of 143 in the Valid Parameter Response List of the Valid State Response List Package. The Maximum Current Number field of 2 bytes contains a value to identify the maximum number of simultaneous scaled video streams that can be assigned at a time. In one mode, a client could deny a request to assign a scaled video stream if the maximum number of scaled video streams has already been allocated. If less than the maximum number of scaled video streams are allocated, the client may also deny a destination request based on other limitations of the source at the client. The X Size and Maximum Y Size of the Source (2 bytes) fields specify the values for the maximum width and height, respectively, of the image of the scaled video stream source expressed as a number of pixels. The RGB Capacity field uses values to specify the number of resolution bits that can be displayed in the RGB format. If the scaled video stream is not used in the RGB format then this value is set equal to zero. The word RGB Capacity is composed of three unsigned values separated by: Bits 3 through 0 define a maximum number of bits of blue (the intensity of blue) in each pixel, Bits 7 through 4 define the maximum number of bits of the green (intensity of green) in each pixel, and bits 11 to 8 define the maximum number of red bits (intensity of red) in each pixel, while bits 15 to 12 are reserved for future use in future capacity definitions and they are generally set to zero. The 1-byte monochrome capability field contains a value that specifies the number of resolution bits that can be displayed in the monochrome format. If the scaled video stream can not use the monochrome formed then this value is set to zero. Bits 7 through 4 are reserved for future use and, therefore, should be set to zero (? 0 ') for current applications, although this may change over time, as will be appreciated by those with prior art experience. Bits 3 through 0 define the maximum number of gray scale bits that can exist in each pixel. These four bits make it possible to specify that each pixel consists of 1 to 15 bits. If the value is zero, then the monochrome format is not supported by the scaled video stream. The Reserved 1 field (here 1 byte) is reserved for future use by providing values related to the information or packet data of the Escalated Video Stream. Therefore, at present, all the bits in this field are set to a? 0 'logical. One purpose in this field is to cause all subsequent 2-byte fields to be aligned with a 16-bit word address and cause the 4-byte fields to be aligned with 32-bit word addresses. The 2-byte capacity Y Cb Cr field contains values that specify the number of resolution bits that can be displayed in the Y Cb Cr format. If the scaled video stream can not use the Y Cb Cr format then this value is zero. The word Capacity Y Cb Cr is composed of three separate unsigned values with: Bits 3 to 0 that define the maximum number of bits that specify the sample Cr; Bits 7 to 4 that define the maximum number of bits specifying the sample Cb; Bits 11 to 8 that define the maximum number of bits that specify the sample Y, and with the Bits 15 to 12 that are reserved for future use and that are generally set to zero. The 1-byte Capacity Bits field contains a set of indicators that specify the capabilities associated with the scaled video stream. The indicators are defined in the following way: Bit 0 covers the Pixel data in the Escalated Video Stream Package that can be of a packaged format. An example of the packed pixel data and aligned byte are previously shown in Figure 12. Bit 1 is reserved for future use and is generally set to zero; Bit 2 is also reserved for future use and is set to zero; Bit 3 covers scaled video streams that can be specified in the color map data format. The same color map table is used for the scaled video streams as they are used for the main image buffer and the alpha-cursor image planes. The color map is configured using the Color Map Package described below; and Bits 7 through 4 are reserved for future use and are generally set to zero. The Reserved 2 field (here of 1 byte) is reserved for future use by providing values related to information or packet data of the Escalated Video Stream. Therefore, at present, all the bits in this field are set to a logical '0'. One purpose of this field is to cause all subsequent 2-byte fields to align with a 16-bit word address and cause the 4-byte fields to be aligned with a 32-bit word address. 37. Climbing Video Streaming Installation Package The Climbing Video Streaming Installation Package is used to define the parameters of the scaled video stream and client information uses to allocate an internal storage to internally store and scale the image. A stream is unassigned when sending this packet with the fields of Image Size X and Image Size Y equal to zero. Escalated video streams that have been removed from where they were intended can be reassigned later with the same or different current parameters. In a modality, a client indicates a capability to support the Video Scale Installation Kit using a parameter value of 143 in the Valid Parameter Response List of the Valid State Response List Package, and by using a different value of zero in the field of Maximum Currents Numbers of the Climbing Video Streaming Capacity Package. The format of the Escalated Video Stream Installation Package is generally shown in Figure 80. As shown in Figure 80, in one embodiment, a Video Scaled Stream Installation Package is structured to have the Package Type fields Packet Length, Client, Stream ID, Visual Data Format Descriptor, Pixel Data Attributes, Left Edge X, Top Edge Y, Right Edge X, Bottom Edge Y, Image Size X, Image Size Y, and CRC . The 2-byte packet length field specifies the total number of bytes in the packet that do not include the packet length field. In one mode, this packet length is set to 24. The 2-byte packet type field uses a value of 136 to identify the packet as a Scaled Video Stream Installation Pack. The 2-byte ID field is reserved for future use as a Client ID, and is generally set to and in all bits as a logical-zero value at the moment or until a protocol user determines which values of ID will be used, as is already known. The Current ID field uses 2 bytes to specify a unique identifier for the Current ID. This value is assigned by the host and varies in value from zero to the value of the Maximum Current ID specified in the Client Capacity Package. The host must manage the use of the current ID values carefully to ensure that each stream is assigned a unique value, and that the streams that are no longer active are de-allocated or reassigned. In one embodiment, the Video Data Format Descriptor field uses 2 bytes to specify the format of each pixel in the Pixel Data in the current present in the present packet. The pixel data format must comply with at least one of the valid formats for the alpha-cursor image plane as defined in the Alpha-Cursor Image Capability Package. The Video Data Format Descriptor defines the pixel format for the current packet only and does not imply that a constant format will continue to be used during the lifetime of a particular video stream. FIGURE HA A HE illustrates an embodiment of how the Video Data Format Descriptor is encoded, and as discussed above for other packages. The 2-byte Pixel Data Attributes field has values that are interpreted as follows: Bits 1 and 0 select the display when the pixel data is to be routed. The Bits [1: 0] = 11 or 00 - of the data are displayed for both eyes. The bits [1: 0] = 10 - of the data are routed only to the left eye. The bits [1: 0] = 01 - of the data are routed only to the right eye. Bit 2 indicates whether the Pixel Data is in the interlace format or not. When Bit 2 is 0, then the Pixel Data is in the standard progressive format. The row number (pixel Y coordinate) is increased by 1 when advancing from one row to the next. When Bit 2 is 1, then the Pixel Data is in the interlaced format. The row number (Pixel's Y coordinate) is increased by two when advancing from one row to the next. Bit 3 indicates whether or not the Pixel Data is in the alternate pixel format. This is similar for the standard interlace mode enabled by bit 2, but the interlace is vertical instead of horizontal.

When bit 3 is zero, the Pixel Data is in the standard progressive format. The column number (Pixel's X coordinate) is incremented by 1 as each succeeding pixel is received. When Bits 3 is 1, then the Pixel Data is in an alternate pixel format. The column number (Pixel's X coordinate) is increased by 2 as each pixel is received. Bit 4 indicates if the Pixel data is related to the screen or the camera. When Bit 4 is 0, the Pixel Data is for or comes from the display frame buffer. When Bit 4 is 1, the Pixel Data is for or comes from the camera. Bit 5 is reserved for future use and, therefore, is generally set to zero. Bits 7 and 6 are the Update Bits of the Deployment specifying the buffer of the frame where the pixel data will be written. The effects of the Frame Update Bits are described in more detail later. When the Bits [7: 6] are? 01 ', the Pixel data is written to the buffer of the offline image. When the Bits [7: 6] are 00 'Pixel data is written to be used by the image buffer to refresh the display. When the Bits [7: 6] are Yl ', the Pixel data is written for all the image buffers. If the bits [7: 6] are '10', these are treated as an invalid value. Those bits are currently reserved for future use. In this situation, the Pixel data should be ignored and not written to any of the image's buffers.

Bits 8 through 15 are reserved for future use and are generally set at a zero-logical level or values. 38 Current Recognition Package Video Climbing The Climbing Video Streaming Recognition Package allows a customer to recognize the receipt of a Video Escalation Stream Installation Package. The client may indicate an ability to support the Video Scaled Video Recognition Package through a parameter value of 143 in the Valid Parameter Response List of the State Response List Package. Valid and through a non-zero value in the Maximum Number of Currents field of the Climbing Video Current Capacity Package. The format of the Scaled Video Stream Recognition Package is generally shown in Figure 81. As can be seen in Figure 81, in one mode, the Scaled Video Stream Recognition Pack is structured to have Packet Length Fields, Type of Package, Clientec, Current ID, ACK Code and CRC. The 2-byte Packet Length field is used to specify the total number of bytes, excluding the Packet Length field, with a value of 10 for this packet type, while a Packet Type of 137 identifies a packet as Climbing Video Streaming Recognition Package. The 2-byte Clientec ID field is reserved for future use for the Client ID, and is generally set to zero. The 2-byte Current ID field specifies a unique identifier for the Current ID. This is the same value assigned by the host in the Climbing Video Stream Installation Package. The 2-byte Ack Code field provides values that contain a code that describes the final result of an attempt to update the specified scaled video stream. In one mode, the codes are defined as follows: 0 - The current assignment attempt was successful. 1 - . 1 - the attempt to de-assign current was successful. 2 - the invalid attempt to assign a current ID that has already been assigned. 3 - invalid attempt to unassign a current ID that is already unassigned. 4 - the client does not support scaled video streams. 5 - the current parameters are inconsistent with the client's capacity. 6 -. 6 - the value of the current ID is larger than the maximum value allowed by the client. 7 - insufficient resources available in the client to assign the specified current. The 2-byte CRC field contains the CRC of all bytes in the packet that includes the Packet Length. 39. Scaled Video Streaming Package The Scaled Video Streaming Package is used to transmit the pixel data associated with a specific scaled video stream. The size of the region reference through this packet is defined by the Escalated Video Stream Installation Pack. The client may indicate an ability to support the Video Escalation Current Package through a parameter value of 143 in the Valid Parameter Response List of the Valid State Response List Package and using a current allocation response of successful video climbing in the Ack Code field of the Video Climbing Current Recognition Package. The format of a Video Scaled Streaming Package mode is generally shown in Figure 82. As shown in Figure 82, a Video Scaled Streaming Package is structured to have fields of Packet Length, Packet Type, ID of Client, Current ID, CRC Parameter, Pixel Count, Pixel Data and Pixel Data CRC. The 2-Byte Packet Type field uses a value of 18 to identify a packet as a Scaled Video Stream Package. The Client ID field is reserved for the Client ID, and is generally set to zero. As above, the 2-byte Current ID field specifies a unique identifier for the Current ID. This value is specified by the host in the Escalated Video Stream Installation Package and is confirmed in the Escalated Video Stream Recognition Package. The 2-byte Pixel Count field specifies the number of pixels in the Pixel Data field below. The 2-byte CRC Parameter field has the CRC of all bytes from the Packet Length to the Pixel Count. If this CRC fails to do the verification then the entire package is discarded. The 2-byte Pixel Data field contains video information in the primary state that is to be scaled and then expanded. The data is formatted in the manner described by the Video Data Format Descriptor field. The data is transmitted one row at a time as previously described. The CRC field of 2-byte Pixel Data contains a CRC of only the Pixel Data. If this CRC fails to verify then the Pixel Data can still be used for the CRC error count to increase. 40. Request-Specific Status Pack The Request-Specific Status Pack provides a means, mechanism, or method for a host to request that the client send a capacity or status packet back to the host as specified in that packet. The client returns the package of the type specified in the following Return Link Encapsulation Package. The client will set 17 bits in the Client Feature Capability field of the Client Capacity Package if the client has the capability to respond to the Request Specific Status Package. A convenient method for the host to use the determination of all types of state packets to which the client can respond is to use the Valid State Response List Pack described in any part. The client can indicate an ability to respond to the Request Specific Status Packet using 21 bits of the Client Feature Capability field of the Client Capability Package.

The format of a modality of a Request Specific Status Pack is generally shown in Figure 83. As can be seen in Figure 83, a Request Specific Status Pack is structured to have Packet Length fields, Package Type, Client ID, State Package ID and CRC. The Packet Length field specifies the total number of bytes in the packet that do not include the Packet Length field, and is generally set to the value of 10 for this packet type. A Package Type of 138 identifies the package as a Request Specific Status Pack. The Clienth ID field (2 bytes) is reserved for future use for a Client ID, and is set to zero for now, although the ID field of the 2-byte State Pack specifies the type of capacity packet or status that the client will send the host. The typical types of packages are: 66 - The Client Capacity Package is sent by the client. 133 - The Alpha-Cursor Image Capability Package is sent by the client. 139 - A State Response List Package Valid is sent which identifies the exact types of capacity and status packages that the client can send. 140 - The Package Processing Delay Parameter Package is sent by the client. 141 - The Personal Client Capacity Package is sent by the client 142 - The Client Error Report Package is sent by the client. 143 - The Climbing Video Streaming Capacity Package is sent by the client. 144 - The Customer Identification Package is sent by the customer. 145 - Alternate Deployment Capacity Package. Package Types 56 through 63 can be used for manufacturer-specific capacity and status identifiers. The CRC field again contains a CRC of all bytes in the packet that includes the Packet Length. 41 Valid State Response List Package The Valid State Response List Package provides the host with a structure, means or method to have a list of status and capacity packages for which the client has the ability to respond. A client may indicate an ability to support the Valid State Response List Pack using 21 bits of the Client Capability Capability Client Client Capability field. The format of a Valid State Response List Package modality is generally shown in Figure 84. As can be seen in Figure 84, a Valid State Response List Package is structured to have Packet Length fields, Type of Package, Customer ID, Number of Values in the List, Valid Parameter Response List and CRC. The Packet Length for this type of packet is usually set to a value of 10, and a value of type 139 identifies the packet as a Valid State Response Packet. The Client ID field is reserved for future use of the Client ID, and is generally set to zero. The Number of Values field in the 2-Byte List specifies the number of elements in the following Valid Parameter Response List. The Valid Parameter Response List field contains a 2-byte parameter list that specifies the types of capacity or status packets that the client can send to the host. If the Client has indicated that he can respond to the Request Specific Status Pack (using 21 bits of the Client Features Capability field in the Client Capacity Package) then he is able to send at least the Client Capacity Package (Type of Package = 66) and the Valid State Response List Package (Package Type = 139). The types of packages that can be sent by the client and that can be included in this list, along with their respective assignments for purposes of a modality, are: 66 - Client Capacity Package 133 - Alpha-Cursor Image Capability Package 139 - Valid State Response List Package, which identifies the exact types of capacity and status package that the customer can send. 140 - Package Processing Delay Parameter Package. 141 - Personal Client Capacity Package. 142 - Client Error Report Package. 143 - Climbing Video Streaming Capacity Package. 144 - Client Identification Package. Package Types 56 through 63 can be used for manufacturer-specific capacity and status identifiers. The CRC field contains a CRC of all bytes in the packet that includes the Packet Length. 42 Package Processing Delay Parameters Package The Package Processing Delay Parameters Package provides a set of parameters to allow the host to calculate the time it takes to complete the processing associated with the receipt of a specific package type. Some commands sent by the host can not be completed by the client at time zero. The host can query the status bits in the Client Status and Application Package to determine if certain functions have been completed by the client, or the host can calculate the end time using the parameters that were returned by the client in the Package Processing Delay Parameter Pack. The client may indicate an ability to support the Packet Processing Delay Parameter Pack by using a parameter value of 140 in the Valid Parameter Response List of the Valid State Response List Packet. The format of a modality of a Packet Processing Delay Parameter Package is generally shown in Figure 85A. As can be seen in Figure 85A, a Packet Processing Delay Parameter Packet is structured to have Packet Length, Packet Type, Cluster ID, Number of Items in the List, List of Delay Parameters fields and CRC The Package Length for this type of package is usually set to a value of 10, and a type value of 140 identifies the package as a Packet Processing Delay Parameter Pack. The Customer ID field is reserved for future use as the Customer ID, and is generally set to zero. The Number of Elements field in the 2-byte List specifies the number of elements in the following Valid Parameter Response List. The field of Delay Parameter List is a list that contains one or more elements of the Delay Parameter List. The format for a single element mode of the Delay Parameter List is shown in Figure 85B, where the fields Package Type for Delay, Pixel Delay, Horizontal Pixel Delay, Vertical Pixel Delay and Delay Fixed are displayed. Each Element in the Delay Parameter List is generally restricted to 6 bytes in length, and is further defined as follows. The delay field for Package Type of 2 bytes specifies the type of package for which the following delay parameters apply. The Pixel Delay field (1 byte) comprises an index for a delay value. The reading of the value of the table is multiplied by the total number of pixels in the destination field of the package. The total number of pixels is the number of times the width of the height of the destination area of the bitmap is referenced by the packet. The 1-Byte Horizontal Pixel Delay field contains a value that is an index for a delay value table (same table as DPVL). The reading of the value of the table is multiplied by the width (in pixels) of the destination field of the package. The 1-Byte Vertical Pixel Delay field contains a value that is an index for a delay value table (it generally uses the same table as DPVL). The value reading of the table is multiplied by the height (in pixels) of the destination field of the package. The Fixed Delay field uses 1 byte as an index for a delay value table (same table as DPVL). The value reading of the table is a fixed delay parameter that represents a time that is required to process the packet that is not related to any of the parameter values specified in the packet. The total delay or time delay to complete the processing of the package is determined according to the relationship: Delay = (PacketProcessingDelay (PixelDelay) «TotalPixels) + (PacketProcessingDelay (HorizontalPixelDelay)» Width) + (PacketProcessingDelay (VerticalPixelDelay) »Height) + PacketProcessingDelay (FixedDelay) For some packages, the Total Pixels, Width or Height do not apply because those parameters have no reference in the corresponding package. In those cases, the corresponding Pixel Delay parameter is usually set to be zero. 43 Personal Deployment Capability Package The Personal Deployment Capability Package provides a set of parameters that describe the capabilities of a personal deployment device, such as a head-mounted display or screen lenses. This enables the host to make a personal adaptation of the deployment information according to the specific capabilities of a client, a client, on the other hand, indicates an ability to send the Personal Deployment Capability Package by using a corresponding parameter in the Valid Parameter Response List of the Valid State Response List Package. The format of a Personal Deployment Capability Package form is generally shown in Figure 86. As can be seen in Figure 86, a Personal Deployment Capacity Package is structured to have Packet Length, Package Type, Client ID, Sub Pixel Distribution, Pixel Shape, Field or Horizontal View, Field or Vertical View, Visual Axis Crossing, Left / Right Image, Transparency, Maximum Brightness, Optical Capacity, Minimum IPD, Maximum IPD, Field of Curvature List and CRC. In one mode, the field value of Package Length is set to 68. A Package Type value of 141 identifies a packet as a Personal Deployment Capability Pack. The Customer ID field is reserved for future use and is generally set to zero for now. The Sub-Pixel Distribution field specifies the physical distribution of a sub-pixel from the top to the bottom and from left to right, using the values of: 0 to indicate that a sub-pixel distribution is undefined; 1 to indicate the red, green and blue band; 2 to indicate the blue, green or red band; 3 to indicate quad pixel, which has a sub-pixel arrangement of 2 by 2 of red in the upper left, blue in the lower right, two sub-pixels green, one in the lower left and one in the lower part Upper right; 4 to indicate a quad pixel, with a sub-pixel arrangement of 2 by 2 in red at the bottom left, blue at the top right, and two green sub-pixels, one at the top left and one at the top lower right part; 5 to indicate a Delta (Triad); 6 to indicate a mosaic with red, green and blue superimposed, (for example LCOS screen with field color in sequence); and with values from 7 to 255 that are generally reserved for future use. The Pixel Shape field specifies the shape of each pixel that is composed of a specific sub-pixel configuration, using a value of: 0 to indicate that the shape of a sub-pixel has not been defined; 1 to indicate round; 2 to indicate square; 3 to indicate rectangular; 4 to indicate oval; 5 to indicate elliptical and with the values of 6 to 255 are reserved for future use in the indication of desired shapes as can be appreciated by someone skilled in the art. A Field of Horizontal Field of Vision (HFOV) of 1 byte specifies the horizontal field of view in increments of 0.5 degrees (for example if the HFOV is 30 degrees, this value is 60). If this value is zero then the HFOV is not specified. A field of Vertical Field of Vision (VFOV) of 1 byte specifies the field of vertical vision in increments of 0.5 degrees (for example if the VFOV is of 30 degrees, that value is 60). If this value is zero then the VFOV is not specified. A 1-byte Visual Axis Crossing field specifies the crossing of the visual axis in diopter increments of 0.01 (l / m) (for example, if the crossing of the visual axis is 2.22 meters, this value is 45). If this value is zero, then the Visual Axis Crossing is not specified. A Left / Right Image Overlay field of 1 byte specifies the percentage of superimposition of a left and right image. The permissible range of the percentage image overlay is from 1 to 100. Values 101 to 255 are invalid and generally will not be used. If this value is zero, then the image overlay is not specified. A 1-byte Transparency field specifies the transparency percentage of the image. The permissible range of transparency in percent is from 0 to 100. Values from 101 to 254 are invalid and will not be used. If this value is 255 then the transparency percentage is not specified. A Maximum Brightness field of 1 byte specifies the maximum brightness in increments of 20 nits (for example, if the maximum brightness is 100 nits, this value is 5). If this value is zero then the maximum brightness is not specified. A 2-byte optical capability indicator field contains several fields that specify optical capabilities of the screen. These bit values are generally assigned according to: Bits 15 to 5 are reserved for future use, they are generally set to a logical zero state. Bit 4 selects the Focus Adjustment of the Eyeglass, with a value of? 0 'which means that the screen does not have an eyeglass setting, and a value of Y' which means that the screen has an eyeglass setting. Bits 3 to 2 select a Binocular Function according to: a value of 0 means that the screen is binocular and can only display two-dimensional (2D) images; 1 means that the screen is binocular and that it can display three-dimensional images (3D); 2 means that the screen is monocular, and 3 is reserved for future use. Bits 1 to 0 select the Curvature Symmetry of the Left-Right Field, with a value of 0 which means the curvature of the field is not defined. If this field is zero then all field curvature values from Al to E5 are set to zero except for point C3 that specifies a focal length of the screen or that is set to zero to indicate an unspecified focal length. A value of 1 means displays of left and right that have the same symmetry; 2 means left and right displays that are reflected on the vertical axis (column C); and 3 is reserved for future use. The 1-byte Minimum Interpupillary Distance (IPD) field specifies the minimum interpupillary distance in millimeters (mm). If this value is zero then the minimum interpupillary distance is not specified. The 1-byte Maximum Interpupillary Distance (IPD) field specifies the maximum interpupillary distance in millimeters (mm). If this value is zero then the maximum interpupillary distance is not specified. The Field Points Curve List field contains a list of 25 2-byte parameters that specify the focal length in thousandths of a diopter (l / m) with a range of 1 to 65535 (for example, 1 is 0.001 diopters and 65535 is 65,535 diopters). The 25 items in the Field Points Curve List are labeled from Al to E5 as shown below. Points will be distributed evenly over the active area of the screen. Column C corresponds to the vertical axis of the screen and row 3 corresponds to the horizontal axis of the screen. Columns A and E correspond to the left and right edges of the screen, respectively. And rows 1 and 5 correspond to the upper and lower edges of the screen, respectively. The order of the 25 points in the list is Al, Bl, Cl, DI, El, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5. A B C D E 0 The CRC field contains a CRC of all bytes in the package that includes the Packet Length. 44. Client Error Report Package The Client Error Report Package acts as a mechanism or means to allow a client to provide a list of operation errors to the host.

The client can detect a wide range of errors in the course of its normal operation as a result of receiving certain commands from the host. Examples of 0 such errors include: the client may have been ordered to operate in a mode that it does not support, the client may have received a package that contains certain parameters that are out of range or beyond the client's ability, have been instructed by client 5 to enter a mode in an inappropriate sequence. The Client Error Reporting Package can be used to detect errors during normal operation, but it is more useful for the designer and system integrator to diagnose problems in the development and integration of the host and client systems. A client indicates its ability to send a Client Error Reporting Package using a parameter value of 142 in the Valid Parameter Response List of the Valid State Response List Package. The format of a package modality Client Error Report is generally shown in Figure 87A. As shown in Figure 87A, a Client Error Reporting Package is structured to have fields of Packet Length, Packet Type, Count ID, Number of List Elements, Error Code List and CRC. A Package Type value of 142 identifies a package as a Client Error Report Package. The Customer ID field is reserved for future use and is generally set to zero for now. The Number of Elements field in the List (2 bytes) specifies the number of elements in the following Error Code List. The Error Code List field (here of 8 bytes) is a list that contains one or more elements of the Error Report List. The format of a single item in the error reporting list is shown in Figure 87B. In a modality, as shown in Figure 87B, each element of the Error Report List is exactly 4 bytes in length, and has a structure in a modality comprising: a 2-byte Deployment Error Code field specifying the type of error that is being reported, a 2-byte error sub-code field specifies a greater level of detail with respect to the error defined by the Client Error Code Package. The specific definition of each Client Error Code is defined by the customer's manufacturer. An error sub-code does not have to be defined for each Deployment Error Code, and in those cases where the Sub-Error Code is not defined the value is set to zero. The specific definition of each Error Sub-code is defined by the manufacturer of the client. 45. Customer Identification Package The Customer Identification Package allows a customer to return identification data in response to a Request Specific Status Package. In one embodiment, a client indicates an ability to send the Client Identification Pack using a parameter value of 144 in the Valid Parameter Response List of the Valid State Response List Package.

It is useful for the host to be able to determine the name of the manufacturer of the client device and the model number when reading this customer data. The information can be used to determine if the client has special capabilities that can not be described in the Client Capacity Package. There are potentially two methods, means or mechanisms to read the Client Identification information. One is through the use of the Client Capacity Package, which contains fields similar to those in the base EDID structure. The other method is through the use of the Client Identification Package that contains a richer set of information compared to similar fields in the Client Capacity Package. This allows a host to identify manufacturers that have not been assigned a 3-character EISA code, and allows serial numbers that contain alphanumeric characters. The format of a modality of a Client Identification Pack is generally shown in Figure 88. As can be seen in Figure 88, a Client Identification Pack is structured to have fields of Packet Length, Package Type, ID of Customer, Week of Manufacture, Year of Manufacture, Length of Name of Manufacture, Length of Product Name, Length of Serial Number, Series of Characters of Manufacturer's Name, Series of Characteristics of Product Name, Series of Characteristics of Number of Series and CRC. The 2-Byte Package Type field contains a value that identifies the packet as a Client Identification Pack. This value is selected to be 144 in a mode. The Clientc field (2 bytes) is again reserved for future use for the Client ID, and is generally set to zero. The CRC field (2 bytes) contains a 16-bit CRC of all bytes in the packet that includes the Packet Length. A 1-byte Manufacturing Week field contains a value that identifies the week of manufacturing the screen. In at least one mode, this value is in the range of 1 to 53 if it is supported by the client. If this field is not supported by the client then it is generally set to zero. A 1-byte manufacturing year field contains a value that defines the customer's manufacturing year (screen). This value is a displacement of the year 1990 as a starting point, although other base years could be used. The years in the range of 1991 to 2245 could be expressed through this field. For example: the year 2003 corresponds to a Manufacturing Year Value of 13. If this field was not supported by the customer, it would be set to a value of zero.

The fields of Length of the Manufacturer's Name, Length of the Product Name, and Length of the Serial Number each contain 2-byte values that specify the length of the Character Series field of the Manufacturer's Name that include any null-termination characters or null padding, field length Series of Product Name Characters that include any null or null padding characters, or the field length of the serial number string that includes null or null padding characters , respectively. The fields of the Character Series of the Name of the Manufacturer, Series of Characteristics of the Name of the Product, and the Series of Characters of the Series Number, each contain a varied number of bits specified by the fields of Length of the Name of the Manufacturer, the Product Name and Serial Number, respectively, that contain a series of ASCII characters that the manufacturer specifies, product name and alphanumeric serial number of the screen, respectively. Each of these serial numbers are terminated by at least one null character. 46. Alternate Display Capacity Package The Alternate Display Capacity Package indicates the alternating display capability attached to the MDDI client controller. It is sent in response to a Request Specific Status Pack. When stimulated, a client device sends an Alternate Display Capability Pack for each alternate screen that is supported. The client may indicate an ability to send the Alternate Display Capability Pack via a parameter value of 145 in the Valid Parameter Response List of the Valid State Response List Package. For MDDI systems operated in an internal mode, it may be common to have more than one screen connected to an MDDI client driver. An example of an application is a mobile phone with a huge screen inside the transition and a smaller screen on the outside. It is not necessary for a client of the internal mode to return an Alternate Deployment Capability Package for two potential reasons: first, the host may already be programmed or otherwise informed of the capabilities during manufacturing since they are used in a device or hosting common; second, due to the assembly of the two, the client can not disconnect or separate easily from a connection with the host, and the host may contain a closed programming copy of the client's capabilities, or at least they do not change with a change of the client. client, as it could happen in another way. The Alt Display Number field of the Client Capacity Package is used to report that more than one screen is attached and the Alternate Display Capacity Package reports the capacity of each alternate screen. The video stream packet contains 4 bits in the Pixel Data Attributes field to address each alternate screen on the client device. The format of a package modality Alternate Display Capacity is generally shown in FIGURE 89. As can be seen in FIGURE 89, an Alternate Display Capability Pack is structured to have Packet Length, Packet Type, Client ID, Alt Display Number fields, Reserved 1, Bitmap Width, Bitmap Height, Deployment Window Width, Deployment Window Height, Color Map RGB Width, RGB Capacity, Monochrome Capacity, Reserved 2, Capacity Y Cb Cr, Capacity Deployment Feature, Reserved 3, and CRC. A Package Type value of 145 identifies a packet as an Alternate Display Capability Pack. The Customer ID field is reserved for a Client ID for future use and is generally set to zero. The Screen Number Field Alt uses 1 byte to indicate the identity of the alternate screen with an integer in the range of 0 to 15. The first alternate screen is typically designated with the number 0 and the other alternate screens are identified by number values. Single Alt Displays with the largest value used as the total number of alternate screens minus 1. Larger values than the total number of alternate screens less 1 are not used. Example: a mobile phone that has a main screen and a caller ID display connected to an MDDI client has an alternate screen, so the Alt Display Number of the caller ID display is zero and the Caller ID Field is Alt Display of the Client Capacity Package has a value of 1. The Reserved 1 field (1 byte) is reserved for future use. All bits in this field are set to zero. One purpose of this field is to cause all subsequent 2-byte fields to align with a 16-bit word address and cause the 4-byte fields to align with 32-bit word addresses. The Bitmap Width field uses 2 bytes that specify the bitmap width expressed as a number of pixels. The Height field of the Bitmap uses 2 bytes that specify the height of the bitmap expressed as a number of pixels. The Wide Field of the Deployment Window used 2 bytes that specify the width of the display window expressed as a number of pixels. The Height field of the Deployment Window uses 2 bytes that specify the height of the display window expressed as a number of pixels. The RGB Width field of the Color Map uses 2 bytes that specify the number of bits in the red, green, and blue components that can be displayed in the color map (palette) display mode. A maximum of 8 bits can be used for each color component (red, green and blue). Although 8 bits of each color component are sent in the Color Map Pack, only the number of the last significant bits of each color component defined in this field is used. If the client's screen can not use the color map (palette) the format then this value is zero. The RGB Width word of the color map is composed of three separate unsigned values: Bits 3 through 0 define a maximum number of blue bits in each pixel with values from 0 to 8 that are considered valid. Bits 7 through 4 define the maximum number of green bits in each pixel with values from 0 to 8 that are considered valid. Bits 11 through 8 define the maximum number of red bits in each pixel with values from 0 to 8 that are considered valid. Bits 14 through 12 are reserved for future use and are generally set to zero. Bit 15 is used to indicate the ability of a client to accept Pixel data in the Color Map in a packaged or unpacked format. When Bit 15 is set to a logical-one level, this indicates that the client can accept the Pixel data from the Color Map either in a packaged or unpacked format. If bit 15 is set to a logical-zero, this indicates that the client can accept pixel data from the Color Map only in an unpacked format. The RGB Capacity _ field uses 2 bytes to specify the number of resolution bits that can be displayed in the RGB format. In a modality, if the client can not use the RGB format then this value is set equal to zero. The word RGB capability is composed of three separate unsigned values: Bits from 3 to 0 define the maximum number of bits in blue (the intensity of the blue) in each pixel, the Bits from 7 to 4 define the maximum number of green bits (green intensity) in each pixel, and Bits 11 through 8 define the maximum number of red bits (intensity of red) in each pixel. Bits 14 through 12 are reserved for future use and are set to zero. Bit 15 is used to indicate the ability of a client to accept RGB pixel data in a packaged or unpacked format. When Bit 15 is set to a logical-one level, this indicates that the client can accept the RGB pixel data in either a packaged or unpacked format. If bit 15 is set to a logical-zero, this indicates that the client can only accept RGB pixel data in an unpacked format. The 1-byte Monochrome Capability field contains a value or information to specify the number of resolution bits that can be displayed in the monochrome format. If the client can not use the monochrome format then this value is set equal to zero. Bits 6 through 4 are reserved for future use and are generally set to zero. Bits 3 through 0 define the maximum number of gray scale bits that can exist in each pixel. These four bits make it possible to specify that each pixel consists of 1 to 15 bits. If the value is zero then the monochrome format is not supported by the client. Bit 7 when set to one indicates that the client can accept monochrome Pixel data in any packaged or unpacked format. If bit 7 is set to incero this indicates that the client can accept monochrome pixel data only in an unpacked format. The Reserved field 2 is a field with a width of 1 byte reserved for future use and generally has all the bits in this field set to a logical-zero level. In a modality, one purpose of this field is to cause all subsequent 2-byte fields to align with a 16-bit word address and cause the 4-byte fields to be aligned with a 32-bit word address. A field of Capacity Y Cb Cr of 2 bytes specifies the number of resolution bits that can be displayed in the Y Cb Cr format. If the client can not use the format Y Cb Cr then this value is zero. The word Capacity Y Cb Cr is composed of three separate unsigned values: Bits 3 to 0 define the maximum number of bits specified by sample Cb, Bits 7 to 4 define the maximum number of bits specified by the sample Cr, Bits 11 through 8 define the maximum number of bits specified by sample Y and bits 14 through 12 are reserved for future use and are set to zero. When Bit 15 is set to one it indicates that the client can accept pixel data AND Cb Cr in any packaged or unpacked format. If bit 15 is set to zero this indicates that the client can only accept pixel data Y Cb Cr in an unpacked format. A 1-byte Bayer Capacity field specifies the number of resolution bits, the pixel group, and the pixel order that can be transferred in the Bayer format. If the client can not use the Bayer format, then this value is set to zero. The Bayer Capacity field is composed of the following values: Bits 3 to 0 define the maximum number of intensity bits that exist in each pixel, Bits 5 to 4 define the pixel group pattern that may be required, Bits 8 up to 6 define a pixel order that is required, and Bits 14 through 9 are reserved for future use and are set to zero. Bit 15 when set to one indicates that the client can accept Bayer pixel data in any packaged or unpacked format. If bit 15 is set to zero this indicates that the client can only accept Bayer pixel data in an unpacked format. The 2-byte CRC field contains a 16-bit CRC of all bytes in the packet including the Packet Length. 47. Registry Access Package The Registry Access Package provides either a host or a Client with a means, mechanism or method to access the configuration and status records at the opposite end of the MDDI link.

Those records are probably going to be unique for each screen or device driver. These records already exist on many screens that require adjustment settings, operating modes, and other useful and necessary adjustments. The Registry Access Pack allows the host or the MDDI client to both write to a record and request reading a record using the MDDI link. When the host or client requests to read a record, the opposite end must respond by means of Registration Data in the same type of package, but also by indicating that this is a reading of data from a particular record with the use of the field Reading / Writing information. The Registry Access Package can be used to read or write multiple records by specifying a record count greater than one. A client indicates a capability to support the Register Access Package using 22 bits of the Customer Capability Capability field of the Client Capability Package. The format of a package modality Registry access is generally shown in FIGURE 90. As seen in FIGURE 90, a Registration Access Package is structured to have fields of Packet Length, Packet Type, Client IDb, Read / Write Indicators, Address Registry, CRC Parameter, Registry Data List, Registration Data CRC. A Package Type value of 146 identifies a package as a Registration Access Package. The Client ID field b is reserved for future use and is generally set to zero for now. The 2-Byte Read / Write Indicators field specifies the specific packet either in writing or read, or in response to a reading, and provides a count of the data values. Bits 15 through 14 act like the Reading / Writing Indicators. If the Bits [15:14] are? 00 'then this packet contains data to be written to a register addressed through the Registration Address field. The data to be written for the specific records are contained in the field of Registration Data List. If the Bits [15:14] are YO ', then this is a request for data from one or more records directed by the Registration Address field. If the Bits [15:14] are lll 'then that packet contains data that is requested in response to a Register Access Pack having bits 15:14 of the Read / Write Indicators set to? 10'. The registration address field Contains the Registration Address that corresponds to the first item in the Registration Data List, and the Registration Data List field contains the data that is read from the address or addresses. If the Bits [15:14] are l01 'these are treated as an invalid value, this value is reserved for future use and is not used. Bits 13: 0 use an unsigned 14-bit integer to specify the number of 32-bit Registration Data elements to be transferred in the Record Data List field. If the 15:14 bits are equal to? 00 'then the bits 13: 0 specify the number of the elements of the 32-bit register data that are contained in the Record Data List field to be written for records that start in the specified record through the Registration Address field. If the 15:14 bits are equal to '10' then the bits 13: 0 specify the number of 32-bit register data elements that the receiving device sends to a device requesting that the records be read. The Record Data List field in this package contains no elements and is of a length of zero. If the 15:14 are equal '11' then the bits 13: 0 specify the number of the elements of the 32-bit Registration Data that have been read from the records that are contained in the Record Data List field. Bits 15:14 are not currently set equal to 01 ', which is considered an invalid value, and are reserved in another way for designations or future use. The Registration Address field uses 4 bytes to indicate the record address in which it is to be written or from which it will be read. To address records whose addressing is less than 32 bits, the upper bits are set to zero. The two-byte CRC Parameter field contains a CRC of all bytes forming the Packet Length for the Record Address. If this CRC fails to verify then the entire packet is discarded. The Record Data List field contains a list of 4-byte registry data values that are to be written to customer records or values that were read from the client device's registers. The CRC field of the two-byte Registration Data contains a CRC of only the Data List of Registry. If CRC fails to verify then the Registration Data can still be used, but the CRC error count is increased.

D. CRC Package The CRC fields appear at the end of the packets and sometimes after certain more crucial parameters in the packets that may have a significantly large data field, and thus, a higher probability of errors during the transfer. In packets that have two CRC fields, the CRC generator, when only one is used, is reset after the first CRC so that the CRC calculations that follow a long data field are not affected by the parameters at the beginning of the packet. In an exemplary embodiment, the polynomial used for the CRC calculation is known as the CRC-16, or X16 + X15 + X2 + X0. A sample implementation of a CRC generator and a verifier 3600 useful for implementing the invention is shown in FIGURE 36. In FIGURE 36, a register 3602 CRC is initialized at a value of 0x0001 just prior to the transfer of the first bit of a packet that is entered in the line Tx_MDDI_Data_Before_CRC, then the bytes of the packet move to the register starting with the first LSB. Note that the bit numbers of the register in this figure correspond to the order of the polynomial that is used, and not to the bit positions used by the MDDI. It is more efficient to move the CRC record in a single direction, and that results in having bit 15 of the CRC appear at the bit position 0 of the CRDI MDDI field, and bit 14 of the CRC record at position 1 bit of the MDDI CRC field, etc., until bit position 14 of the MDDI is reached.

As an example, if the package contents for the Client and Status Request Packages are: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (or are represented as a sequence of bytes like: 0x0c, 0x00, 0x46 , 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00), and are presented using the inputs of the multiplexers 3604 and 3606, and the gate 3608 NAND, the resulting CRC output on the line Tx_MDDI_Data_ ith_CRC is 0xd9aa (or represented as a sequence like Oxaa, 0xd9). When the CRC generator and the 3600 verifier are configured as a CRC verifier, the CRC that is received on the Rx_MDDI_Data line is entered into multiplexer 3604 and gate 3608 NAND, and bit by bit is compared with the value found in the CRC register using gate 3610 NOR gate 3612 exclusive-OR (XOR), and "gate 3614 AND If any errors exist, with exit through gate 3614 AND, the CRC is incremented once for each packet containing a CRC error at connect the output of gate 3614 to the entry of register 3602. Note that the example circuit shown in the diagram of FIGURE 36 can output more than one CRC error signal within a given window CHECK_CRC_NOW (see FIGURE 37B) Therefore, the CRC error counter generally only counts the first CRC error case within each interval where CHECK_CRC_NO is active.If it is configured as a CRC generator the CRC is chronometrically outside of the CRC record at the time it coincides with the end of the packet. The timing for the input and output signals, and the enabling of the signals are illustrated graphically in FIGURES 37A and 37B. The generation of a CRC and the transmission of a data packet is shown in FIGURE 37A with the status (0 or 1) of the signals Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data, together with the signals Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC. The reception of a data packet and the verification of the CRC value are shown in FIGURE 37B, with the status of the signals Gen_Reset, Check_CRC_Now, Generate_CRC_Now, Sending_MDDI_Data, together with the signals Rx_MDDI_Data and error CRC.

E. Overload of the Error Code for the CRC Package Whenever only data and CRC packets are transmitted between the host and the client, there are no error codes that fit. The only error is a loss of synchronization. Otherwise, you have to wait for a pause of the link from a need for a good path or cause of data transfer and then the link is restarted and proceeded. Unfortunately, this is time consuming and somewhat inefficient. To use it in a modality, a new technique has been developed in which the portion of the CRC packets is used to transfer the error code information. This is generally shown in FIGURE 65. That is, one or more error codes are generated by the processors or devices that handle the data transfer indicating error or specific predefined faults that could occur within the communication processing or link. When an error is found, then an appropriate error code is generated and transferred using the bits for the CRC of a packet. That is, the CRC value is overloaded, or overwritten, with the desired error code, which can be detected at the receiving end by a monitor or error verifier that monitors the values of the CRC field. For those cases in which the error code corresponds to the CRC value for some reason, the compliance of the error is transferred to avoid confusion. In one embodiment, to provide a blunt warning and error detection system, the error code can be transferred several times, using a series of packets, generally all, which are transferred or sent after the error has been detected. This occurs up to the point where the condition of creating the error is cleared from the system, at the point where the regular CRC bits are transferred without overload by another value. This CRC value overload technique provides a much faster response to system errors while using a minimum number of bits or extra fields. As shown in FIGURE 66, an overwriting mechanism or apparatus 6600 is shown using a 6602 detection means or error detector, which may be part of another set of previously described or known circuits, detects the presence or existence of errors within the link or communication process. A 6604 means or error code generator, which can be formed as part of another circuit set or uses techniques such as search tables to store preset error messages, generates one or more error codes to indicate specific errors or predefined faults that They may have been detected while they occur. It is readily understood that devices 6602 and 6604 can be formed as a single circuit or device as desired, or as part of a sequence of steps programmed for other known processors and elements. A comparison means 6606 or CRC value comparator is displayed for verification to see if the selected error code or codes are the same as the CRC value that is transferred. If this is the case, then a means or generating device or code compliance generation is used to provide compliance with the error codes as long as they are not confused as the original of the pattern or CRC value and confused or complicated. detection scheme. An element or device 6610 of a selector or error code selection means then selects the error code or value to be inserted or overwritten, or their respective compliance as appropriate. A mechanism or means 6612 about writer or CRC override error code is a device that receives the data stream, the packets and the desired codes to be inserted or overwrites the corresponding or appropriate CRC values, to transfer the Desired error codes to a receiving device. As mentioned, the error code can be transferred several times, using a series of packets, so the 6612 overwriter can use memory storage elements to keep copies of the codes during the processing or retrieval of those previous item codes or other known storage locations that can be used to store or maintain their values as necessary, or as desired. The general processing of the overwrite mechanism of FIGURE 66 is implemented shown in further detail in FIGURES 67A and 67B. In the 67A one or more errors are detected, in step 6702 in the data communication or process and an error code is selected in step 6704 to indicate this condition. At the same time, or at an appropriate point, the CRC value to be replaced is verified in a step 6706, and compared to the desired error code in step 6708. The result of this comparison, as discussed above, it is a determination as to whether the desired code, or other representative values, will be the same or not as those of the CRC value present. If this is the case, then the processing proceeds to a step 6712 where compliance is selected, or in some cases as desired another representative value, such as the code to be inserted. Once it is determined that error codes or values are to be inserted in steps 6710 and 6714, that appropriate code is selected for insertion. Those steps are illustrated separately for purposes of clarity although they generally represent a single choice based on the decision output of step 6708. Finally, at step 6716 the appropriate values are overwritten at the CRC location to transfer them with the packets that are have selected as a goal through the process. On the packet receiving side, as shown in FIGS. 67B, the packet CRC values are being monitored in a 6722 step. Generally, the CRC values being monitored by one or more processes within the system to determine if an error has occurred in the transfer of data and whether a retransmission of the packet or packets is requested or not, or to inhibit additional operations, etc., some of which were previously discussed. As part of such information monitoring it can also be used to compare values for known or pre-selected error codes, or representative values and to detect the presence of errors. Alternatively, a process and monitor can be implemented to detect separate errors. If a code appears to be present it is extracted or otherwise noted in step 6724 for further processing. A determination can be made in step 6726 as to whether this is the actual code or not or a fulfillment, in which case, an additional step 6728 is used to translate the value to the desired code value. In any case, the resulting extracted code, compliance or other recovered values are then used to detect what error has occurred from the code transmitted in step 6730.

V. Link Hibernation The MDDI link can enter the hibernation state quickly and wake up from the state of hibernation quickly. This receptivity allows a communication system or device forced the MDDI link to hibernate frequently to reduce the consumption of electrical energy, since it can wake up again to be used very quickly. In a modality, when a client of external way wakes up of the hibernation for the first time it does so so that a speed of data and with a timed of pulse stroboscopic that is consistent with a speed of one Mbps, that is to say, the pair MDDI_Stb should be tilted at a speed of 500 kHz. Once the Client Features have been discovered through the or communicated to the host, then the host can discard the link generally at a rate of 1 Mbps up to the maximum speed at which the client can operate. Clients can wake up internally at any speed at which both the host and the client can operate. This can also be applied generally to the first time a client wakes up internally. That in a modality, when the link wakes up from hibernation, the host and the client exchange a sequence of pulses. These pulses can be detected using low-speed line receivers that consume only a fraction of the current in the differential receivers that are required to receive the signals at maximum link operation speed. Either the host or the client can wake up the link, so the wake-up protocol is designed to handle possible contention that can occur if both the host and the client try to wake up simultaneously. During the hibernation state the differential MDDI_Data and MDDI_Stb handlers are disabled and the differential voltage across all the differential pairs is zero volts. The differential in-line receivers used to detect the pulse sequence during the awakening of hibernation have an intentional voltage shift. In one embodiment, the threshold between a logical-one and zero-logical level in those receivers is approximately 125 mV. This causes a non-triggered differential pair to be seen as a zero-logical level during the wake-up sequence of the link. To enter a Hibernation State, the host sends 64 MDDI_Stb cycles after the CRC of the Link Break Package. The host disables MDDI_Data 0 output from the host in the range of 16 to 56 MDDI_Stb cycles (including propagation delays that disable the output). The host finishes sending the MDDI_Stb cycles after the CRCs of the Link Breaker packet before it starts the wake-up sequence. In a modality, the awakening initiated by the host is defined as the host that has to wait at least 100 nsec after MDDI_DataO reaches a valid logical-one level before triggering the pulses in MDDI_Stb. In one mode, the client waits at least 60 MDDI_Stb cycles after the CRC of the Link Break Package before it triggers MDDI_Data0 at a logical-one level to try to wake the host. To "wake up" from a state of Hibernation, various actions or processes are carried out. When the client, here a screen, needs data or communication, or service, from the host the MDDI_Data0 line is operated in a one-logical state for approximately 70 to 1000 μsec, while MDDI_Stb is inactive and keeps MDDI_DataO driven on a level from one-logical for approximately 70 cycles MDDI_Stb (through a range of 60 to 80) then the MDDI_Stb becomes active, although other periods may be used as desired. The client then disables the MDDI_DataO handler by placing it in a high impedance state. If MDDI_Stb is active during hibernation, although unlikely, then the client could only trigger MDDI_DataO in a one-logical state for approximately 70 MDDI_Stb cycles (or through a range of 60 to 80). This action causes the host to initiate or restart the data traffic on the link (208) without return and to call a client to know its status. The host must detect the presence of the request pulse and start the start sequence by driving MDDI_Stb at a logical-zero level and MDDI_Data0 at a high logical level of at least about 100 nsec. And then, while pivoting, MDDI_Stb continues to drive MDDI_Data0 at a logical one level for approximately 50 MDDI_Stb cycles. The client should not send a service request pulse if MDDI_Data0 is detected in the logical state of one for more than 80 MDDI_Stb cycles. When the client has detected MDDI_Data0 at a logical one level for 60 to 80 cycles, MDDI_Stb begins looking for the interval in which the host triggers MDDI_DataO at a logical zero level for 50 MDDI_Stb cycles. After the host triggers MDDI_DataO at a logical zero level for a duration of 50 MDDI_Stb cycles, then the host starts sending packets to the link. The first packet sent is a Subframe Header Pack. The client starts looking for the Sub-frame Header Pack after MDDI_DataO is at a logical zero level for 40 _ MDDI_Stb cycles of the 50 cycle range. The nature of the selection of times and the tolerances of the time intervals related to the hibernation processing and the start of the sequence are discussed further below. (See FIGURES 68A-C below). The host can start the awakening by first enabling MDDI_Stb and simultaneously activating it at a logical-zero level. MDDI_Stb should not be operated at a logical-one level until the pulses occur as described below. After MDDI_Stb reaches a valid logical-zero level, the host enables MDDI_DataO and simultaneously operates it at a logical-one level. MDDI_Data0 should not be operated at a logical-zero level until the interval where the logical-zero level is being activated by a range of 50 MDDI Stb pulses as described below. The host must wait at least 100 nsec after MDDI_DataO reaches a valid logical-one level before triggering the pulses in MDDI_Stb. This timing relationship occurs while considering the worst case of delays that enable the exit. This substantially ensures that a client has enough time to fully enable their MDDI_Stb receiver after it has been woken up by a one-logical level in MDDI_DataO that was driven by the host. An example of the processing steps for a typical customer service request event 3800 without containment is illustrated in FIGURE 38, where events are labeled for convenience in the illustration using the letters A, B, C, D, E , F and G. The process begins at point A when the host sends a Link Break Package to the client device to inform it that the link will go into a low power hibernation state. In a next stage, the host enters the low-power hibernation state by disabling the MDDI_DataO handler and by setting the MDDI_Stb handler to a logical-zero, as shown in point B. MDDI_Data0 is driven at a logical-zero level through a high impedance polarization network. After some period of time, the client sends a service request pulse to the host by operating MDDI DataO at a logical-one level as seen in point C. The host still maintains the logical-zero level using the network of High impedance polarization, although the handler in the client forces the line to a logical one level. Within 50 μsec, the host recognizes the service request pulse, and maintains a one-logical level in MDDI_Data0 by enabling its handler, as seen in point D. Then the client stops trying to maintain the service request pulse, and the Client places its handler in a state of high impedance, as seen in point E. The host operates MDDI_DataO at a logical-zero level for 50 μsec, as shown in point F, and also begins to generate MDDI_Stb in a manner consistent with the logical-zero level in MDDI_DataO. The client starts looking for the Sub-tram Header Pack after MDDI_DataO is at a logical zero level for 40 MDDI_Stb cycles. After maintaining MDDI_DataO at a logical-zero level and driving MDDI_Stb for 50 μsec, the host begins to transmit the data on the non-return link by sending a Sub-frame Header Pack, as shown in point G. A similar example is illustrated in FIGURE 39 where a service request is maintained after the link restart sequence has been initiated, and the events are again labeled using the letters A, B, C, D, E , F and G. This represents the worst case scenario where a pulse or request signal from the client comes as close to altering the Subframe Header Pack. The process begins at point A where the host again sends a Link Break Package to the client device to inform it that the link will go into a low power hibernation state. In the next stage, the host enters the low-power hibernation state by disabling the MDDI_DataO handler and setting the MDDI_Stb handler to a logical-zero level, as shown in point B. As in the previous case, MDDI_DataO is activated in a zero-logic level through a high-impedance polarization network. After a period of time, the host begins the restart sequence of the link by driving MDDI_DataO at a logical-one level for 150 μsec as seen at point C. Before passing the 50 μsec after the restart sequence begins of the link the deployment also maintains MDDI_DataO for a duration of 70 μsec, as seen in point D. This happens because the deployment has a need to request the host service and does not recognize that the host has already started the sequence of link restart The client then stops trying to maintain the service request pulse, and the client places its handler in a state of high impedance, as seen in point E. The host continues to drive MDDI_DataO at a logical-one level. The host triggers MDDI_DataO at a logical-zero level for 50 μsec, as shown at point F, and also starts generating MDDI_Stb in a manner consistent with the logical-zero level in MDDI_DataO. After maintaining MDDI_Data 0 at a logical-zero level, and of driving MDDI_Stb for 50 μsec, the host begins to transmit the data on the non-return link by sending a Sub-frame Header Pack, as shown at point G From the previous discussion, it can be seen that the previous solution involved keeping the host going through two states as part of a waking sequence. For the first state, the host operates the high MDDI_DataO signal for 150 μs, and then drives the low MDDI_DataO signal for 50 us while activating the MDDI_Stb line, and then starts transmitting the MDDI packets. This process works well to improve the state of the art in terms of data speeds that can be achieved using the apparatus and MDDI methods. However, as stated above, there is always a demand for greater speed in terms of a reduced response time to conditions or to be able to more quickly select the next stage or process, namely the ability to simplify processing or elements. A new inventive methodology has been discovered to process and time the awakening in which the host uses a cycle of measuring time based on the timing of the tilt of the signal. In this configuration, the host starts the MDDI_Stb tilt from 0 to 10 μsec after the host triggers the raised MDDI__DataO signal at the start of the wake-up sequence, and does not wait until the signal is driven low. During a wake-up sequence, the host toggles MDDI_Stb even if the MDDI_DataO signal was always at a logical-zero level. This effectively removes the concept of time from the client side, and the host changes from the periods 150 μs and 50 μs previous for the first two states to 150 cycles of measuring time and 50 cycles of measuring time, for those periods. The host is now responsible for operating that high data line, and within 10 cycles of measuring the time they start transmitting a strobe signal as if the data line were at zero. After the host has triggered the high data line for 150 cycles of time measurement, the host triggers the low data line for 50 cycles of timing while continuing to transmit the strobe signal. After both of these processes have been completed, the host can begin to transmit the first sub-frame header packet. On the client side, the client implementation can now use to measure the time generated to calculate the number of cycles of measuring the time that the data line is first raised and then decreases. The number of cycles of measuring the time needed for both the data line operated in the high state to occur is 150 and the data line operated in the low state is 50. This means that for an appropriate awakening sequence , the client should be able to count at least 150 cycles of continuous time measurement of the data line that is high, followed by at least 50 cycles of continuous time measurement of the data line that is low. Once those two conditions have been met, the client can start looking for the unique word of the first sub-frame. A break in this pattern is used as a basis to return the counters to an initial state in which the client again searches for the first 150 cycles of continuous time measurement of the data line that is high. A client implementation of the invention for the host based on the awakening of hibernation is very similar to the initial boot case except that the speed of timing is not forced to start at IMbps, as discussed above. In contrast, the speed of time measurement can be adjusted to start over at any previous speed that was active when the communication link went into hibernation. If the host begins transmitting a strobe signal as described above, the client should be able to again count at least 150 continuous time measurement cycles of the data line that is high, followed by at least 50 cycles of measure the continuous time of the data line that is low. Once these two conditions have been met, the client can begin to search for the unique word. A client implementation of the invention for the Client based on the awakening of hibernation is similar to the host-based awakening except that it starts by keeping the client operating the data line. The client can asynchronously trigger the data line without measuring the time to wake up the host device. Once the host recognizes that the data line is being raised elevated by the client, it can begin its wake-up sequence. The client can count the number of cycles of measuring the time generated by the host at the beginning or during the awakening process. Once the Client counts 70 cycles of continuously measuring the data that are high, he can stop the high data line drive. At this point, the host should already trigger the elevated data line as well. A client can then count another 80 cycles of continuous time measurement of the data line which is high to reach the 150 cycles of measuring the time of the data line which is high, and can then look for the 50 cycles of measuring the time of the data line that is low. Once these three conditions have been met, the client can begin to search for the unique word. One advantage of this new wake-up processing implementation is that it removes the need for a time measurement device. Whether it is an oscillator, or a capacitor discharge circuit or other known devices, the customer no longer needs such external devices to determine the starting conditions. This saves money and circuit areas when the drivers, counters, etc., are implemented on a client device board. Although this may not be advantageous to the client, for the host, this technique should also potentially simplify the host in terms of a very high logical density (VHDL) that is used for the core circuitry. The electric power consumption of the use of the data lines and the stroboscope as the source of notification and measurement of awakening is also given lower since no external circuitry is needed that is working for the core elements to wait What an awakening based on the host. The number of cycles or periods of measuring the time used are exemplary and other periods may be used as will be apparent to those having experience in the art. One advantage of this new wake-up processing implementation is that it removes the need for a time measurement device. Whether it is an oscillator, or a capacitor discharge circuit or other known devices, the client no longer needs such external devices to determine the starting conditions. This saves money and circuit areas when the controllers, counters, etc. are implemented on a customer device board. Although this may not be so advantageous for the client, for the host, this technique should also potentially simplify the host in terms of a very high density (VHDL) logic that is used for the core circuitry. The consumption of electrical energy when using the data lines and stroboscope as the source of notification and measurement of awakening will also be lower since it will not be necessary a set of external circuits to work for the core elements that will be waiting for an awakening based on the host. To clarify and illustrate the operation of this new technique, the timing of MDDI_DataO, MDDI_Stdb, and various operations related to the cycles of measuring time are shown in FIGURES 68A, 68B and 68C. An example of the processing stages of a Awakening initiated by the typical Host without connection is illustrated in FIGURE 68A, where events are again labeled for illustration convenience using the letters A, B, C, D, E, F, and G. The process begins at point A when the host sends a Link Break Package to the client device to inform it that the link will go into a low power hibernation state. In a next step, at point B, the host toggles MDDI_Stb for approximately 64 cycles (or as desired for the system design) to allow processing to be completed by the client before stopping the tilt of MDDI_DataO, which stops to measure the time recovered on the client device. The host also initially sets MDDI_DataO to a logical-zero level and then disables the MDDI_DataO output in the range of 16 to 48 cycles (usually including delay propagation of output disabling) after the CRC. It may be desirable to place high-speed receivers for MDDI_DataO and MDDI_Stb on the client in a low power state some time after the 48 cycles after the CRC and before the next phase (C). The client places its high-speed receivers for MDDI_DataO and MDDI_Stb in hibernation at any time after the rising edge of the 48th MDDI_Stb cycle after the CRC of the Link Break Package. It is recommended that the client place its high-speed receivers for MDDI_DataO and MDDI_Stb in hibernation before the 64th MDDI_Stb upload edge after the CRC of the Link Break Package. The host enters the low power hibernation state at the point or stage C, by disabling the MDDI_DataO and MDDI_Stb handlers and places a host controller in a low power hibernation state. You can also adjust the MDDI_Stb handler to a logical-zero level (using a high-impedance bias network) or continue to tilt during hibernation, as desired. The client is also in a low power level hibernation state. After some period of time, the host begins the restart sequence of the link at point D, by enabling the output of the MDDI_DataO and MDDI_Stb handler. The host operates MDDI_DataO at a logical-one level and MDDI_Stb at a logical-zero level for as long as it takes the managers to fully enable their respective outputs. The host typically waits approximately 200 nanoseconds after those outputs reach the desired logical levels before triggering the pulses in MDDI_Stb. This allows the client time to prepare to receive. With the host handlers enabled and with MDDI_DataO being activated at a logical-one level, the host begins to tilt MDDI_Stb for a duration of 150 cycles MDDI_Stb, as seen in point E. The host operates MDDI_DataO at a level zero-logical for 50 cycles, as shown at point F, and the client begins to look for the Sub-frame Header Pack after MDDI_Data0 is at a logical-zero level for 40 MDDI_Stb cycles. The host begins to transmit the data in the non-return link by sending a Sub-frame Header Pack, as shown in point G. An example of the processing steps of an Awakening initiated by the typical Customer without containment is illustrated in FIGURE 68B, where events are labeled again for convenience in illustration using the letters A, B, C, D, E, F, G, H, and l. As before, the process begins at point A when the host sends a Link Break Package to inform the client that the link will go to the low power state. At point B, the host scales MDDI_Stb for approximately 64 cycles (or as desired for the system design) to allow it to be completed the processing by the client before stopping the MDDI_Stb tilt which stops measuring the time recovered in the client device. The host also initially sets MDDI_DataO to a logical-zero level and then disables the MDDI_DatáO output in the range of 16 to 48 cycles (which usually include propagation delay by exit disablement) after the CRC. It may be desirable to place the high-speed receivers for MDDI_DataO and MDDI_Stb on the client in a low power state sometime after the 48 cycles after the CRC and prior to the next phase (C). The host enters the low power hibernation state at the point or stage C, by disabling the MDDI_DataO and MDDI_Stb handlers and by placing a host controller in a low power hibernation state. You can also set the MDDI_Stb handler to a logical-zero level (using a high-impedance bias network) or continue to tilt during hibernation, as desired. The client is also in a low power level hibernation state. After some period of time, the client begins the restart sequence of the link in point D, by enabling the MDDI_Stb receiver, and also by enabling a movement in the MDDI_Stb receiver to guarantee the status of the received version of MDDI_Stb that is in the zero-logical level in the client before the host enables its MDDI_Stb handler. It may be desirable for the customer to enable the shift slightly ahead of the receiver enable to ensure the reception of a valid differential signal and inhibit erroneous signals, as desired. The Client enables the MDDI_Data0 handler while operating the MDDI_Data0 line at a logical-one level. MDDI_DataO and MDDI_Stb are allowed to be enabled simultaneously if the time to enable the offset and the standard MDDI_Stb differential receiver is less than 100 nsec. Within approximately 1 msec, at point E, the host recognizes the client's service request pulse, and the host begins the link restart sequence by enabling the MDDI_Data0 and MDDI_Stb handler output. The host triggers MDDI_DataO at a logical-one level and MDDI_Stb at a logical-zero level for the time it may take for the handlers to enable their respective outputs. The host typically waits around 200 nanoseconds after that output reaches the desired logical levels before triggering the pulses in MDDI_Stb. This allows the client time to prepare to receive. With the host handlers enabled and with This allows the client to have it actuated at a logical-one level, the host starts to output the pulses in MDDI_Stb for a duration of 150 MDDI_Stb cycles, as seen in the point F. When the client recognizes the first pulse in MDDI_Stb, it disables the movement of its MDDI_Stb receiver. The client continues to drive MDDI_Data0 at a logical-one level for 70 MDDI_Stb cycles, and disables its MDDI_Data0 handler at point G. The host continues to drive MDDI_Data0 at a logical level of one for an additional duration of 80 MDDI_Stb pulses, and in a point H triggers MDDI_Data0 at a logical zero level. As seen in points G and H, the host operates MDDI_Data0 at a logical-zero level for 50 cycles, and the client starts looking for the Sub-frame Header Pack after MDDI_Data0 is at a zero-level. logical for 40 cycles MDDI_Stb. After operating MDDI_Stb for a duration of 50 cycles, the host begins transmitting the data on the non-return link by sending a Sub-frame Header Pack, as shown in point I An example of the processing steps for a Awakening initiated by the typical Host with contention from the client, that is, the client always wants to wake up the link, as illustrated in FIGURE 68C. The events are again labeled for illustration convenience using the letters A, B, C, D, E, F, G, H, and I. As before, the process begins at point A when the host sends an Interruption Packet Link to inform the client that the link will go to the low power state, proceed to point B where MDDI_Stb is tilted for approximately 64 cycles (or as desired for the system design) to allow the processing to be completed by the client , and then goes to point C, where the host enters the low power hibernation state, by disabling the MDDI_DataO and MDDI_Stb handlers and placing a host controller in a low power hibernation state. After some period of time, the host begins the restart sequence of the link at point D, by enabling the output of the MDDI_DataO and MDDI_Stb handler and starts to tilt MDDI_Stb for a duration of 150 cycles MDDI_Stb, as seen in point E. Up to 70 MDDI_Stb cycles after From point E, for this moment point F, the client has no longer recognized that the host is driving MDDI_DataO at a logical-one level, so the client also operates MDDI_DataO at a logical-one level. This happens here - because the client has the desire to request the service but does not recognize that the host is trying to communicate with him and that he has already initiated the restart sequence of the link. At point G, the client stops operating MDDI_DataO, and places its handler in a high impedance state by disabling its output. The host continues to drive MDDI_Data0 at a logical-one level for 80 additional cycles. The host triggers MDDI_Data0 at a logical-zero level for 50 cycles, as shown at point H, and the client begins to look for the Sub-frame Header Pack after MDDI_DataO is at a logical-zero level during 40 cycles MDDI_Stb. The host begins transmitting the data in the non-return link by sending a Subframe Header Pack, as shown in point I.

SAW. Electrical Specifications of the Interface In exemplary modes, Data in a No Return to Zero (NRZ) format is encoded using a data-strobe signal or DATA-STB format, which allows the time measurement information to be included in the data and strobe signals. Measuring time can be recovered without a complex phase of closed loop circuits. The data is transported through a bi-directional differential link, which is usually implemented using a metallic line cable, although other conductors can be used, and the printed or transfer elements, as stated above. The strobe signal (STB) is transported through a uni-directional link that is powered only by the host. The strobe signal tilts the value (0 or 1) whenever there is an uninterrupted state, 0 or 1, which remains the same in the line or signal of the Data. An example of how a data sequence such as that of the "1110001011" bits can be transmitted using the DATA-STB coding is shown in graphic form in FIGURE 40. In FIGURE 40, a DATA signal 4002 is shown on the line The upper part of a signal time table and a 4004 STB signal is displayed on a second line, each time is aligned as appropriate (common start point). As time goes by, when there is a change of state that occurs on line 4002 of DATA (signal), then line 4004 STB (signal) maintains a previous state, thus in first l 'state of signal DATA correlates with the first state '0' for the STB signal, its start value. However, if or when the state, level of the DATA signal does not change, then the STB signal is tilted to the opposite state or? L 'in the present example, as is the case in FIGURE 40 where the DATA is provided with another value? l '. That is, there is only one and only one transition per bit cycle between DATA and STB. Therefore, the STB signal transitions again, this time at '0' as the DATA signal remains at? L 'and maintains this level or value as the DATA signal changes the level to? 0'. When the signal DATA remains in? L ', the signal STB swings to the opposite state or? L' in the present example, etcetera, as the signal DATA changes or maintains the levels or the values. Upon receiving these signals, an exclusive O-operation (XOR) is carried out on the DATA and STB signals to produce a signal 4006 for measuring time, which is shown at the bottom of the time table for relative comparison with the signals. wanted data signals and stroboscope. An example circuit set useful for generating the DATA and STB outputs or data input signals in the host, and then recovering or recapturing the data from the DATA and STB signals, is shown in FIGURE 41. In FIGURE 41, a transmission portion 4100 is used to generate and transmit the original DATA and STB signals through an intermediate signal path 4102, while a reception portion 4120 is used to receive the signals and recover the data. As shown in FIGURE 41, in order to transfer the data from a host to a client, the DATA signal is entered into two D-type circuit elements 4104 and 4106 together with a time-measuring signal to activate the circuits. The two outputs (Q) of the swing circuit are then divided into a pair of differential signals MDDI_DataO +, MDDI_DataO-, and MDDI_Stb +, MDDI_Stb-, respectively, using two differential line handlers 4108 and 4110 (voltage mode). A NOR-exclusive gate (XNOR) of three inputs, a circuit, or a logic 4112 element is connected to receive DATA and the outputs of both swingarms, and generates an output that provides the input data for the second swingarm, which at its once it generates the signals MDDI_Stb +, MDDI_Stb-. For convenience, the XNOR gate has the inversion bubble placed to indicate that it is effectively inverting the Q output of the swingarm that the Strobe generates. In the reception portion 4120 of FIGURE 41 the MDDI_DataO + signals, MDDI_DataO- and MDDI_Stb +, MDDI_Stb-are received by each of the two differential receivers 4122 and 4124 in line, which generate unique outputs of the differential signals. The outputs of the amplifiers are then input to each of the inputs of an exclusive OR gate (XOR) of two inputs, a circuit, or a logic element 4126 that produces the signal to measure time. The time measurement signal is used to activate each of the two D-type tilting circuits 4128 and 4130 that receive a delayed version of the DATA signal, through the delay elements 4132, one of which (4128) generates the values 0 'data and the other (4130) data values' 1'. Measuring time has an independent output from the logical XOR as well. Since the time-measuring information is distributed between the DATA and STB lines, none of the signal transitions between the states is faster than half the speed of measuring time. Since timing is reproduced using OR-exclusive processing of the DATA and STB signals, the system effectively tolerates twice the amount of bias between the input data and measuring the time compared to the situation when a signal to measure time it is sent directly through a single dedicated data line. The signals from the MDDI Data, MDDI_Stb +, and MDDI_Stb- pairs are operated in a differential mode to maximize immunity from the negative effects of noise. Each differential pair is terminated in parallel with the characteristic impedance of the cable or conductor that is used to transfer the signals. Generally, all terminations in parallel reside on the client device. This is close to the differential receiver for non-return traffic (data sent from the host to the client), but it is at the drive end of the cable or other conductors or transfer elements for the return traffic (data sent from the client to the host). For return traffic the signal is triggered by the client, reflected by the high impedance receiver in the host, and ends in the client. This avoids the need for a double termination that would increase the power consumption. It also works at higher data rates than the reciprocal round trip delay in the cable. The conductors or signals MDDI_Stb + and MDDI_Stb- are only activated by the host. An exemplary configuration of elements useful for getting handlers, receivers and terminations to transfer the signals as part of the inventive MDD interface is shown in FIGURE 42. This exemplary interface uses a low voltage detection, which here is 200 mV, with less than 1 volt of electric power oscillations and a low energy expenditure. The handler of each signal pair has a differential current output. While the MDDI packets are received, the MDDI_Data and MDDI_Stb pairs use a conventional differential receiver with a voltage threshold of zero volts. In the hibernation state the handler outputs are disabled and the parallel termination resistors draw the voltage at each signal pair at zero volts. During hibernation a special receiver in the MDDI_DataO pair has a positive input threshold of 125 mV, which causes the receiver of the hibernation line to interpret the non-driven signal pair as a logical-zero level. Sometimes the host or the client simultaneously drives the differential pair to a logical-one level or a logical-zero level to guarantee a valid logical level in the pair when the data flow direction changes (from the host to the client or from the client to the host). The output voltage range and output specifications must even comply with simultaneously driven outputs that are driven at the same logic level. In some systems it may be necessary to drive a small current within the finished differential pair to create a small displacement voltage at certain times during hibernation and when the link wakes up from the hibernation state. In those situations, the enabled displacement current bias circuits drive the current levels referred to as: I_sD-and-RX- internal ESD diode and differential receiver input with lESD-an-R <; 1 μA typically; ITX-HÍ-Z- differential driver output in high impedance state with ITX-HÍ-Z = 1 μA typically; and I_xter_ai-ESD- the leakage through the external ESD protection diodes with Iextemai-ESD < 3 μA typically. Each of these leakage currents is illustrated in FIGURE 101. The booster and voltage reducing circuits must achieve the minimum differential voltage under the worst case leakage conditions described above when everything occurs simultaneously. The total leak is < 4 μA for internal mode without external ESD protection diodes y = 10 μA for external mode with external ESD protection. The parameters and electrical characteristics of the differential line operators and the line receivers are described in Table VIII. Functionally, the handler transfers the logic level at the input directly to a positive output, and the inverse of the input to a negative output. The delay of the input to the outputs is well matched in the differential line that is differentially driven. In most implementations, the voltage oscillation at the outputs is less than the oscillation at the input to minimize electrical power consumption and electromagnetic emissions. Table VIII presents a minimum voltage swing that is around 0.5V. However, other values can be used, as those skilled in the art are well aware, and a smaller value is contemplated in some embodiments, depending on the design constraints. Differential in-line receivers have the same characteristics as a high-speed voltage comparator. In FIGURE 41 the entry without the bubble is the positive entry and the entry with the bubble is the negative entry. The output is a logical one if: (Vinput +) - (Vinput-) is greater than zero. Another way to describe this is a differential amplifier with a very large gain (virtually infinite) with the output subject to logical 0 and 1 voltage levels. The delay bias between the different pairs must be minimized to operate the differential transmission system at the highest potential speed. In FIGURE 42, a host controller 4202 and a client or deployment controller 4202 are shown transferring packets through the commution link 4206. The host controller employs a series of three handlers 4210, 4212, and 4214 to receive the host DATA and STB signals to be transferred, as well as to receive the client DATA signals to be transferred, while the client employs the three handlers 4230, 4232, and 4234. The handler responsible for the host step DATA (4212) employs an enabling signal input to allow activation of the commution link generally only when transfer from the host to the host is desired. client. Since the STB signal is formed as part of the data transfer, no additional enable signal is used for that handler (4212). The inputs of each of the DATA and STB client receivers (4132, 4230) have termination impedances or rheostats 4218 and 4220, respectively distributed through them. The handler 4234 in the client controller is used to prepare the data signals that are transferred from the client to the host, where the handler 4214 on the input side processes the data. The special receivers (handlers) 4212 and 4236 are coupled or connected to the DATA lines, and generate or use the previously discussed 125 mV voltage offset as part of the hibernation control discussed above. Offsets cause the in-line hibernation receivers to interpret the signal pairs without triggering as a zero-logic level. Handlers and previous impedances can be formed as discrete components or as part of a circuit module, or in a specific application integrated circuit (ASIC) that acts as a more cost-effective coding or decoding solution. It can be easily seen that the energy is transferred to the client device, or screen, from the host device using the signals labeled HOSTJPwr and HOST_Gnd through a pair of conductors. The HOST_Gnd portion of the signal acts as the reference ground and the return path of the electrical power supply for the client device. The signal H0ST_Pwr acts as the power supply of the client device that is driven by the host device. In an exemplary configuration, for low power applications, the client device is allowed to draw up to 500 mA. The HOST_Pwr signal may be provided from portable power sources, such as but not limited to a lithium-ion battery or a battery pack that resides in the host device, and may vary from 3.2 to 4.3 volts with respect to H0ST_Gnd .

VII. Timing Characteristics A. Overview The stages and signal levels used by a client to secure the service from the host and the host to provide such service are illustrated in FIGURE 43. In FIGURE 43, the first part of the signals are illustrated by showing a Link Break Package which is transferred from the host and the data line is then driven to a logic-zero state using the high impedance bias circuit. No data is transmitted through the client screen, or the host, who has its driver disabled. A series of strobe pulses can be seen for the signal line MDDI_Stb at the bottom, since MDDI_Stb is active during the Link Break Package. Once the packet ends and the logic level changes to zero as the host triggers the bias circuit and logic to zero, the line of the MDDI_Stb signal changes to a level of logical-zero as well. This represents the completion of the last signal or service transfer from the host, and could occur at any time in the past, and is included to show a prior cessation of the service, and the status of the signals prior to the start of the service. If desired, that signal can be sent just to restart the communication link in the proper state without prior 'known' communication that has been carried out by this host device. As shown in FIGURE 43, the signal output from the client is initially set to a logical-zero level. In other words, the client's output is at a high impedance, and the handler is disabled. When the service is being requested, the client enables its handler and sends a service request to the host, which is in a period of time designated tserice / during which the line is activated at a logical-one level. A certain amount of time passes then or may be needed before the host detects the request, which is termed as thos-detect / after which the host responds with a link start sequence by triggering the signal at a level of one-logical At this point, the client denies the request, and disables the service request handler so that the client exit line goes back to a logical-zero level. During this time, the MDDI_Stb signal is at a logical-zero level. The host triggers the host data output at level '1' for a period called subtract-high after which the host triggers the logic level at zero and activates MDDI_Stb for a period called trestart-iow / after which the First non-return traffic begins with a Sub-frame Header Pack, and packets of non-return traffic are then transferred. The MDDI_Stb signal is activated during the tester-io-period and the subsequent Sub-frame Header Pack. Tables VII and VIII show representative times or processing periods for the length of several periods discussed above, and the relation for exemplary minimum and maximum data rates where: tU = Link DataRate 'where Link_Data_Rate is the bit rate of a only pair of data. Tabal VII Table VIII Those skilled in the art will readily understand that the functions of the individual elements illustrated in FIGURES 41 and 42 are well known, and the function of the elements of FIGURE 42 is confirmed by the timing diagram in FIGURE 43 The details about the series terminations and the hibernation rheostats shown in FIGURE 42 were omitted in FIGURE 41 because that information is unnecessary for a description of how to execute the Strobe Data coding and for recover from these measuring time.

B. Non-Return Link of Strobe Data The switching characteristics for the data transfer in the non-return link from the output of the host handler are shown in Table IX. Table IX presents a tabular form of the desired minimum and maximum, against the typical times that will occur for certain signal transitions. For example, the typical length of time for a transition to occur from the start to the end of a data value (output of '0' or '1'), a transition DataO to DataO, called ttdd- (host-output) , is ttb_t while the minimum time is approximately ttbit-0.5 nseg., and the maximum is approximately ttb_.t + 0.5 nseg. The relative separation between the transitions in DataO, other data lines (DataX), and strobe lines (Stb), are illustrated in FIGURE 44 where the DataO for the Stroboscope, the Stroboscope to Stroboscope, Stroboscope to DataO, DataO to non-DataO, non-DataO to non-DataO, non-DataO to Stroboscope, and Stroboscope to non-DataO that are transitions that are shown which are referred to as ttds- (host-output) / ttss- (host-output) / Ysd- (host-output) / ttddx- (host-output) / ttdxdx- (host-output) _ ttdxs- (host-output) / And ttsdx- (host-output) / respectively.

Table IX The typical MDDI timing requirements for the customer's receiver input for the same data transfer signals on the non-return link are shown in Table X. Since the same signals are discussed although with delayed time, a new signal is not necessary. figure to illustrate the signal characteristics or the meaning of the respective labels, as can be understood by those who have experience in the art.

TABLE X FIGURES 45 and 46 illustrate the presence of a response delay that may occur when the host disables or enables the host handler, respectively. In the case of host re-routing of certain packets, such as the Return Link Encapsulation Pack or the Round Trip Delay Pack, the host disables the line handler after the desired packets have been forwarded, so that the CRC Parameter, Strobe Alignment, and All-Zero packages illustrated in FIGURE 45 as if they had been transferred. However, as shown in FIGURE 45, the state of the line does not necessarily switch from '0' to a desired higher value instantaneously, although this can potentially be achieved with some control or circuit elements present, but takes a period of time that it calls the Enabler Delay period of the Host Manager to respond. Although it could occur virtually instantaneously in such a way that this period of time is 0 nanoseconds (nsec.) In length, it could spread more easily over a somewhat longer period with 10 nsec. , which is a desired maximum period length, which occurs during the Guard Time 1 or Turn Around 1 pack periods. Looking at FIGURE 46, a change in the level of the signal experienced when the Host Manager can be seen is enabled to transfer a package such as the Return Link Encapsulation Package or the Round Trip Measurement Package. Here, after the Guard Time 2 or Turn Round 2 packet periods, the host handler is enabled and starts to activate a level, which here is '0', whose value is approaching or is reached during a period of time which is referred to as the Delay Period that the Host Manager allows, which occurs during the Handler Rehabilitation period, before the first packet is sent. A similar process occurs for handlers and signal transfers for the client device, here a screen. The general guidelines for the length of these periods, and their respective relationships are shown in Table XI below.

TABLE XI C. Return Link of Strobe Data Timing The switching characteristics and timing relationships for the data signals and stroboscope used to transfer data in the return link of the client handler output are shown in FIGURES 47 and 48 Typical times for certain signal transitions are discussed below. FIGURE 47 illustrates the relationship at the input of the host receiver between the timing of the data being transferred and the leading and trailing edges of the strobe pulses. That is, what is referred to as the settling time for the rising or front edge of the stroboscope signals, t? U-sr and the settling time for the trailing or descending edge of the strobe signals, tsu -sf- A typical length of time for these establishment periods is in the order of a minimum of 8 nanoseconds. FIGURE 48 illustrates the characteristics and corresponding customer exit delay switches developed by the return data timing. In FIGURE 48, the relationship between the timing of the data being transferred and the leading and trailing edges of the pulses of the stroboscope representing the induced delay can be seen. That is, what is referred to as the propagation delay between the rising or trailing edge of the strobe signals and the (valid) data, tpa-Sf, and the propagation delay between the data and the trailing or descending edge of the stroboscope signals, tpd_sf. A typical maximum length of time for these periods of propagation delay is in the order of 8 nanoseconds VIII. Implementation of Link Control (Link Controller Operation) A. State Machine Pack Processor Packages that are transferred through an MDDI link are dispatched very quickly, typically at a rate of the order of 300 Mbps or more , such as 400 Mbps, although of course lower speeds can be adjusted, as desired. This type of bus or transfer link speed is too large for currently commercially available (inexpensive) general-purpose microprocessors, or the like for control. Therefore, a practical implementation to achieve this type of signal transfer is to use a programmable state machine to analyze the input packet stream to produce packets that are transferred or reoriented to the appropriate audiovisual sub-system for which they are thought. Such devices are well known and use circuits that are generally dedicated to a limited number of operations, functions, or states to achieve a desired high speed or a very high speed operation. Controllers, processors or general-purpose processing elements can be used to more appropriately act on or manipulate some of the information such as control or status packets, which have lower speed demands. When these packets are received (control, status or other predefined packets), the state machine could pass them through a data buffer or similar processing elements to the general-purpose processor so that the packets can be activated to provide a desired result (effect) while the audio and visual packages are transferred to their appropriate destination for activation. If future microprocessors or other controllers, processors or general-purpose processing elements are manufactured to achieve higher data rate processing capabilities, then the state machines or states discussed below could also be implemented using the software control of such devices, typically as programs stored in a storage element or means. The capacity of the general-purpose processor can be realized in some modes by taking advantage of the processing power, or the surplus cycles available for microprocessors (CPUs) in computer applications, or controllers, processors or digital signal processors (DSPs), specialized circuits, or ASICs found in wireless devices, many in the same way that some modems or graphics processors use the processing power of the CPUs found in computers to perform some functions and reduce the complexity and hardware costs. However, this cycle of sharing or use can negatively impact the speed of processing, timing or overall operation of such elements, so in many applications circuits or dedicated elements are preferred for this general processing. In order for the image data to be viewed on a screen (micro-screen), or to reliably receive all the packets sent by the host device, the processing of the client signal is synchronized with the timing of the non-return link channel . That is, the signals arriving at the client and the client circuits need to be synchronized in time substantially so that appropriate signal processing occurs. In the illustration of FIGURE 49 a diagram of high level states reached for the signal for a modality is presented. In FIGURE 49 the possible "synchronization" states of the non-return link for a 4900 state machine are shown being classified as a STATUS 4904 of ASYNC TRAMAS, two STATES 4902 and 4906 SYNC of ACQUISITION, and three STATES 4908, 4910, and 4912 IN-SYNC.

As shown by the start stage or state 4902, the display or the client, such as a presentation device, initiates a preselected "no sync" state, and searches for a unique word in the first packet of the Sub-frame header what is detected It should be noted that this non-sync state represents the minimum communication setting or "backward" setting in which a Type 1 interface is selected. When the unique word is found during the search, the client saves the length field of Sub-frame There is no verification of the CRC bits to continue processing this first frame, or until synchronization is obtained. If this sub-frame length is zero, then the sync state of processing continues according to a state 4904 labeled here as the "async frames" state, which indicates that synchronization has not been achieved. This stage in the processing is labeled as having encountered a cond 3, or condition 3, in FIGURE 49. Otherwise, if the frame length is greater than zero, then the processing sync state continues to a state 4906 in where the state of the interface is set to "found one sync frame". This stage in processing is labeled as if a cond 5, or condition 5, were found in FIGURE 49. In addition, if the state machine sees a frame header packet and a good CRC determination for a frame length greater than zero, the processing continues to the "found one 'sync frame" state. This is labeled as if a cond 6, or condition 6, were found in FIGURE 49. In each situation in which the system is in a different state than the "no sync" state, if a packet with a good CRC result is detected , then the interface is changed to state 4908"in-sync". This stage in the processing is labeled as if a cond 1, or condition 1, had been found in FIGURE 49. On the other hand, if the CRC in any packet is not correct, then the sync state of processing continues or returns to the state 4902 of the interface or to the "NO SYNC FRAME" status. This portion of the processing is labeled as if a cond 2, or condition 2, were found in the state diagram of FIGURE 49.

B. Acquisition Time for Sync The interface can be configured to set a certain number of "sync errors" before deciding that synchronization is lost and returning to the "NO SYNC FRAME" state. In FIGURE 49, once the state machine has reached "IN-SYNC STATE" and no errors are found, a result of cond 1 is continuously found, and remains in the "IN-SYNC" state. However, once the result cond 2 is detected, the processing changes the state to a state 4910"one-sync-error". For this point, if the processing results in the detection of another result cond 1, then the state machine returns to the state "in-sync", otherwise it finds another result cond 2, and moves to a state 4912"TWO -SYNC-ERRORS. " Again, if a cond 1 occurs, the processing returns to the state machine in the "IN-SYNC" state. Otherwise, another cond 2 is found and the state machine returns to the "no-sync" state. It can also be understandable that the interface could find a "link shutdown packet", then this will cause the link to complete data transfers and return to the "no-sync frame" state since there is nothing to synchronize with, which refers to finding a cond 4, or condition 4 in the state diagram of FIGURE 49. It is understood that there may be a "false copy" repetition of the unique word that may appear at some fixed location within the Sub -plot. In this situation, it is highly unlikely that the state machine will synchronize with the Sub-frame because the CRC in the Sub-frame Header Pack must also be valid when it is processed so that the processing MDD interface proceeds to the state "IN SYNC". The sub-frame length in the Sub-frame Header Pack can be set to zero to indicate that the host will transmit only one sub-frame before the link is interrupted, and the MDD interface is placed in or configured in an inactive hibernation state. In this case, the client must immediately receive the packets through the non-return link after detecting the sub-frame Header Pack because only a single sub-frame was sent before the link transitions to the inactive state. In normal or typical operations, the sub-frame length is not zero and the client only processes the non-return link packets while the interface is in those states that are shown collectively as the "IN-SYNC" state in FIGURE 49. A client device can be attached externally to the host while the host is already transmitting a sequence of data from the non-return link. In this situation, the client must synchronize with the host. The time required for a client to synchronize with the non-return link signal varies depending on the size of the sub-frame and the data rate on the non-return link. The probability of detecting a "false copy" of the unique word as part of the random or more random, data in the non-return link is greater when the size of the sub-frame is larger. At the same time, the ability to recover from a false detection is slower, and the time it takes to do so is longer, when the data rate of the non-return link is slower.

C. Initiation As stated above, at the time of "start-up", the host configures the non-return link to operate at or below a minimum required, or desired, data rate of 1 Mbps, and configures the Sub-frame length and frame rate of the media appropriately for a given application. That is, both the non-return and return links start their operation using the Type 1 interface. These parameters are generally only to be used temporarily while the host determines the desired capacity or configuration for the client's screen (or another type of client device). ). The host sends or transfers a sub-frame Header Pack through the non-return link followed by a Return Link Encapsulation Pack having a '0' bit of the Request Indicators that are set to a value of one ( 1), to request that the screen or the client respond with a Client Capacity Package. Once the screen acquires the synchronization in (or with) the non-return link, it sends a Client Capacity Package and a Client Status and Application Package through the link or return channel. The host examines the contents of the Client Capacity Pack to determine how to reconfigure the link to an optimal or desired level of performance. The host examines the Protocol Version and Minimum Protocol Version fields to confirm that the host and the client are using versions of the protocol that are compatible with each other. The protocol versions generally remain as the first of two parameters of the Client Capability Package so that compatibility can be determined even when other elements of the protocol may not be compatible or fully understood as being compatible.

D. CRC Processing For all packet types, the packet processor state machine ensures that the CRC verifier is properly or appropriately controlled. It also increments a CRC error counter when a CRC comparison results in one or more errors that are detected, and restarts the CRC counter at the start of each sub-frame that is being processed.

E. Alternative Synchronization Verification Loss While the series of previous stages or states work to produce higher data rates or total throughput speed, it has been found that an alternative disposition or change in the conditions the client uses to declare that there is a loss of synchronization with the host, which can be used effectively to achieve even higher speeds or total data throughput. The new inventive modality has the same basic structure, but with conditions to change changed states. Additionally, a new counter is implemented to help carry out the checks for sub-frame synchronization. These stages and conditions are presented in relation to FIGURE 63, which illustrates a series of states and conditions useful for establishing the operations of the method or the state machine. Only the "ACQUIRING-SYNC STATES" and "IN-SYNC STATES" portions are shown for clarity. Furthermore, since the resulting states are substantially the same, as is the state machine itself, they use the same numbering. However, the conditions to change the states (and the operation of the state machine) vary a bit, so all are renumbered for clarity between the two figures (1, 2, 3, 4, 5, and 6, against 61, 62, 63, 64, and 65), for convenience to identify the differences. Since the ASYNC FRAME state is not considered in this discussion, a state (4904) and a condition (6) are no longer used in the figure. In FIGURE 63, the system or client (for deployment or presentation) starts with the state machine 5000 in the 4902 pre-selected state "no sync", as in FIGURE 49. The first state changes to change the states of the condition 4902 non-sync is a condition 64 that is the discovery of the sync pattern. It is assumed that the CRC of the sub-frame header also passes in this packet (meets condition 61), the status of the packet processor state machine can be changed to 4908 in-sync state. A sync error, in condition 62, will cause the state machine to move to state 4910, and a second state 4912 to occur. However, it has been discovered that any CRC failure of an MDDI packet will cause the state machine to fail. move out of state 4908 in-sync, towards sync error state 4910. Another CRC failure of any MDDI packet will cause a movement towards the two 4912 states of sync failure. A decoded packet with a correct CRC value will cause the state machine to return to 4908 in-sync state.

What has been changed is the use of the CRC value or the determination for 'each' package. That is, to make the state machine look at the CRC value for each packet to determine a loss of synchronization instead of just observing the sub-frame header packets. In this configuration or process, a loss of synchronization is not determined using the unique word and only the CRC header values of Sub-frame. This new interface implementation allows the MDD interface link to recognize synchronization failures much more quickly, and therefore, recover from them more quickly as well. To make this system more compelling, the client should also add or use a Sub-frame counter. The client then verifies the presence of a unique word at the moment in which it waits for a signal to arrive or occur. If the unique word does not occur at the correct time, the client can recognize that a synchronization failure has occurred much more quickly than if it had to wait several pack times (here three) or periods that were larger than the length of one sub-frame If the single word test indicates that it is not present, in other words that the timing is incorrect, then the client can immediately declare a sync link loss and move to the no-sync state. The process of verifying the presence of the only appropriate word, adds a condition 65 (cond 65) to the state machine that says that the unique word is incorrect. If a sub-frame packet is expected to be received at the client and does not correspond, the client can immediately go to the 4902 state of no-sync, saving an additional waiting time for multiple sync errors (condition 62) that is normally find through through states 4910 and 4912. This change uses an additional counter or counting function in the client's kernel to count the sub-frame length. In one mode, a countdown function is used and the transfer of any packet that is currently being processed is interrupted to verify the unique word of the sub-frame if the counter has expired. Alternatively, the counter may count, with the counter being compared to a particular desired or desired maximum value, at a point at which the current packet is verified. This process protects the client from decoding packets that are received incorrectly on the client with extraordinarily long packet lengths. If the sub-frame length counter needs to interrupt some other packet that is being decoded, a loss of synchronization can be determined since no packet could cross a sub-frame boundary.

IX. Packet Processing For each type of package discussed above that the state machine receives, a particular processing step or series of steps is carried out to implement the operation of the interface. The non-return link packets are generally processed in accordance with an exemplary processing that is listed in Table XII below.

Table XII Type of Package Response of the packet processor state machine Audio Stream Sends the speed setting of (AS) the audio sample to an audio sample clock generator, separates the audio samples of the specified size, unpacks audio sample data when necessary, and route the audio samples to the appropriate audio sample FIFO Color Map (CM) Read the color map size and displacement parameters, and write the map data color in a memory or storage location of the color map.

Encapsulation Facilitates the sending of packages in the Return Link appropriate return-in-time (REL) address. Return link indicators are examined and Client Capacity packages are sent as needed. The Request and Client Status packages are also sent when appropriate. Client Capacity Sends this type of packet when it is (CC) requested by a host using the return link indicator field of the Return Link Encapsulation Package Keyboard (K) Passes those packets to and from the general-purpose processor that communicates with a keyboard-type device, if any, and uses it if desired. Device Passes those packets to and from the signaling (PD) processor. general purpose that communicates with a pointing device, if any is present, and uses it if desired. Interruption Registers the fact that the Link (LS) link is interrupted and informs a general-purpose processor.

Request and Send Status this package as the first Customer Service package in the Package of (CSRS) Encapsulation of the Return Link.

Package Type Response of the packet processor state machine Execute Type of You can act on such packets either Transfer directly or to the Intracellular (PTH) transfer them to the general-purpose processor, also instructing the hardware to experience a mode change X. Reduce the Data Rate of the Return Link It has been observed that certain parameters used for the host link controller can be adjusted or configured in a certain way to achieve a maximum or more optimized return link data rate (scale), which is very desirable. For example, during the time it is used to transfer the Return Data Packet field of the Return Link Encapsulation Pack, the MDDI_Stb signal pair is tilted to create periodic data time measurement at half the data rate of the link without return. This happens because the host link controller generates the MDDI_Stb signal that corresponds to the MDDI_DataO signal as if it were sending all the zeros. The MDDI_Stb signal is transferred from the host to a client where it is used to generate a signal to measure the time to transfer data from the return link from the client whereby the return data is sent back to the host. An illustration of the typical delay quantities encountered for signal transfer and processing in the non-return and return paths in a system employing MDDI is shown in FIGURE 50. In FIGURE 50, a series of values of delay 1.5 nsec, 8.0 nsec, 2.5 nsec, 2.0 nsec, 1.0 nsec, 1.5 nsec, 8.0 nsec, and 2.5 nsec, as shown near the processing portions for generation Stb +/-, cable transfer to the client, client receiver, generation of time measurement, record the signal time, generation of Data0 +/-, transfer wire to the host, and host receiver phases, respectively. Depending on the data rate of the non-return link and the delays in signal processing encountered, more time of a cycle in the MDDI_Stb signal may be required for this "round-trip" effect or the set of events that is going to complete, which results in undesirable consumption of time amounts or cycles. To circumvent this problem, the Return Speed Divider makes one bit at a time in the return link possible to span multiple cycles of the MDDI_Stb signal. This means that the data rate of the return link is less than the rate of non-return link. It should be noted that the actual length of signal delays through the interface may differ depending on each specific host-client system or hardware being used. Although not required, each system can generally be made to perform better by using the Round Trip Delay Measurement Package to measure the actual delay in a system so that the Return Speed Divider can be set to an optimal value . The host can support either basic data sampling that is simpler but operates at a slower speed or advanced data sampling that is more complex but supports higher data rates of return. The client's ability to support both methods is considered the same. A round trip delay is measured when you have a host that sends a Round Trip Delay Measurement Package to the customer. The client responds to this packet by sending a sequence of ones back to the host within, or during, a preselected measurement window in the packet called the Measurement Period field. The detailed timing of this measurement was previously described. The round trip delay is used to determine the speed at which the return link data can be sampled safely. The measurement of round trip delay consists of determining, detecting or counting the number of intervals to measure the time of the data of the non-return link that occurs between the start of the Measurement Period field and the start of the time period when the Oxff response sequence, Oxff, 0x00 is received back in the host from the client. Note that it is possible that the client's response could be received in a small fraction of the period of measuring the non-return link time before the measurement count was about to increase. If this unmodified value is used to calculate the Return Speed Divider, bit errors could be caused in the return link due to unreliable data sampling. An example of this situation is illustrated in FIGURE 51, where the signals representing MDDI_Data in the host, MDDI_Stb in the host, measuring the data time of the non-return link in the host, and a Delay Count are illustrated in graphic form. In FIGURE 51, the response sequence was received from the client in a fraction of the time period of the no return link time before the Delay Count was about to increase from 6 to 7. Assuming the delay is going to be 6, then the host will sample the return data just after a bit transition or possibly half of the bit transition. This could result in erroneous sampling on the host. For this reason, the measured delay should typically be increased by one before it was used to calculate the Return Speed Divider. The Return Speed Divider is the number of MDDI_Stb cycles that the host should wait before sampling the return link data. Since MDDI_Stb is cycled at a speed that is half the non-return link speed, the corrected round-trip delay measurement needs to be divided by 2 and then rounded to the next whole number. Expressed as a formula, this relationship is: reverse _rate For the given example, this becomes: reverse _ rate _ divisor = RoundUpT Nextlnteger (< If the round-trip delay measurement is used in this example where 7 is opposed to 6, then the Speed Divider Return would also be equal to 4. The return link data is sampled by 'the host at the rising edge of Measure the Return Link Time. There is a counter or a circuit or similar known device present both in the host and in the client (screen) to generate Measure the Return Link Time. The counters are initialized so that the first rising edge of measuring the return link time occurs at the start of the first bit in the field of the Return Link Packs of the Return Link Encapsulation packet. This is illustrated, for example as given below, in FIGURE 52. The counters are incremented at each rising edge of the MDDI_Stb signal, and the number of counts that occur until the pass overwrite is set by the parameter Return Speed Divider in the Return Link Encapsulation package. Since the MDDI_Stb signal is tilted by one-half of the Non-Return Link Rate, then the return link rate is half the non-return link speed divided by the Return Speed Divider. For example, if the non-return link speed is 200 Mbps and the Return Speed Divider is 4 then the data rate of the return link is expressed as: _ 1 200Mbp _s_ _ n 25- M1? Bps 2 4 An example that shows the timing of the signal lines MDDI_DataO and MDDI_Stb in a Package Return Link Encapsulation is shown in FIGURE 52, where the pack parameters used for the illustration have the values: Package Length = 1024 (0x0400) Sense Inversion Length 1 = 1 Package Type = 65 (0x41) Sense Inversion Length 2 = 1 Return Link Indicators = 0 Return Speed Divider = 2 CRC Parameter = 0xdb43 All at Zero is 0x00 The packet data between the fields of Package length and CRC parameter are: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00, ... The first return link packet returned from the client is the Client Status and Application Pack that has a Packet Length of 7 and a packet type of 70. This packet begins with the values of byte 0x07, 0x00, 0x46, ... etc. However, only the first byte (0x07) is visible in FIGURE 52. The first return link packet is shifted in time by almost a period of measuring the return link time in the figure to illustrate a link delay of real return An ideal waveform with zero round-trip delay from the host to the client is shown as a dotted line trace. The MS byte of the CRC Parameter field is transferred, preceded by a packet type, and then the entire field is set to zero. The host's stroboscope is switched from one to zero and returns to one as the data from the host changes levels, forming larger pulses. As the data approaches zero, the stroboscope switches to the highest speed, only the change in the data in the data line causes a change near the end of the alignment field. The stroboscope switches to the highest speed of the rest of the figure due to the fixed levels of 0 or 1 of the data signal for the extended periods of time, and the transitions that fall in the pulse pattern (edge). Measuring the time of the return link for the host is at zero until the end of the Sense 1 Inversion period, when timing starts to adjust the return link packets. The arrows in the lower portion of the figure indicate when the data is sampled, as is apparent from the rest of the description. The first byte of the packet field that is transferred (which is here 11000000) is shown starting after Sense Inversion 1 and the line level has stabilized from the host handler that is disabled. The delay in the passage of the first bit, as can be seen for bit three, it can be seen in dotted lines for the Data signal. In FIGURE 53, typical values of the Return Speed Divider can be observed based on the data rate of the non-return link. The actual Return Speed Divider is determined as a result of a round trip link measurement to ensure proper operation of the return link. A first region 5302 corresponds to a safe operating area, a second region 5304 corresponds to a marginal performance area, while a third region 5306 indicates adjustments that are unlikely to work properly. The round trip delay measurement and the Return Speed Divider setting are the same as long as they are operating with any of the Interface Type settings on either the non-return or return link because they are expressed and operated on. terms of units of periods of actual time measurement rather than numbers of bits transmitted or received.

XI. Sense Inversion and Guard Time As discussed above, the Sense Inversion 1 field in the Return Link Encapsulation Pack and the Save Time 1 field in the Round Trip Delay Measure packet designate the values for the lengths of time that allow the host interface handlers to be disabled before the client interface handlers are enabled. The Sense 2 and Guard 2 Time fields provide time values that allow client managers to be disabled before the host handlers are enabled. The fields of Guard Time 1 and Guard Time 2 are usually filled with pre-set or pre-selected values for lengths that do not imply that they are to be adjusted. Depending on the hardware of the interface that is being used, these values can be developed using data, empirical and adjusted in some cases to improve its operation. Several factors contribute to the determination of the length of Inversion of Sense 1 and these are the data rate of the non-return link, and the maximum disablement time of MDDI_Data handlers in the host. The maximum host handler disable time is specified in Table XI, where it is shown that handlers take approximately 10 nsec., Maximum to disable and approximately 2 nsec., To be enabled. The minimum number of measure the time of link without return that is required for the handler of the host that is going to be disabled is expressed according to the relation: ,? r.? ,. ,. ForwardLinkDataRate __ ", Clocks _to_ d? Sablem = - - - - - - HostDriverDisableDelay ^ ¿ÍÍT6TJCICG i" jjTi * LQlOTp jr The range of allowable values for Inversion of Sense 1 is expressed according to the relationship: tum_ArouM_l = where the Interface Type Factor is 1 for Type 1, 2 for Type 2, 4 for Type 3, and 8 for the Type-4. Combining the two previous equations, it can be seen that the term Interface Type Factor is canceled, and the Inversion of Sense 1 is defined as: _ _, _ _, ", ^ _» _, _t (ForwardLikDatáRate HostDriveBisableDe &m? Turn_Aro nd_l = Ro ndUpToMxtIntegeY ^ = - °) For example, a Type 3 non-return link of 1500 Mbps would use a Sense Inversion 1 delay of: Turn __ Around _1 = RoundUpToNextlntegerl = IBytes As the round trip delay increases, the timing margin is improved from the time point in which the host is disabled until the time when the client is enabled. The factors that determine the length of time generally used for Sense Inversion 2 are the data rate of the non-return link, the maximum disablement time of MDDI_Data handlers in the client, and the round trip delay of the communication link. . The calculation of the time required to disable the client handler is essentially the same as that of the host handler discussed above, and is defined according to the relationship: _-.? T _-. »_ ForwardLinkDataRate _. , _. _. .7 _. Cloeks to_ d? SaberT? 2 = "t _,: 1" ^ -; ^ ~; 'D? SplayDr? VerD? SaberDelaya InterfaceTypeFactorf WD and the range of values allowed for Inversion of Sense 2 is expressed as: For example, a Type 3 non-return link of 1500 Mbps with a round trip delay of 10 non-return link time measurements uses a Sense Inversion 2 delay in the order of: Clocks "to_ disábleTM¡ =," - • 1 On sec = 3.75 XII. Alternative Return Link Timing Although the use of the timing and guard bands discussed above functions to achieve a high data rate interface, a technique has been discovered to accept return bit lengths that are not shorter than the round trip time, by changing the discovery of the return timing. As presented previously, the previous methodology of the return link timing is configured in such a way that the number of cycles to measure time is counted from the last bit of Guard Time 1 of a return timing packet until the first bit is sampled at the rising edge of measuring time 10. That is the signal (s) to measure the time that is used to time the inputs and outputs for the MDD interface. The calculation for the Return Speed Divider is then given by: reverse _rate ..divisor = RoundUpToNextlntegerí ° Und ~ trip -Ma ^ + ^ ^ 2 J This provides a bit width equal to the round trip delay that results in a very reliable return link. However, the return link has been shown to be able to run faster, or at a higher data transfer rate, from which one wishes to take advantage. A new inventive technique allows to use additional capabilities of the interface to achieve higher speeds. This is achieved by having the host counting the number of cycles of measuring the time until one is sampled, but sampling the host of the data line at both the up and down edges during the return timing package. This allows the host to choose the most useful or even optimal sampling point within the return bit to ensure that the bit is stable. That is, to find the most useful or optimum rising edge to sample the data in the return encapsulation packages of the return traffic. The optimal sampling point depends both on the divisor of the return link and on whether the first point was detected on an ascending edge or on a falling edge. The new timing method allows the host to concentrate only on the first edge of the OxFF OxFF 0x00 pattern sent by the client for the timing of the return link to determine where to sample a return encapsulation packet. The examples of the return bit that arrive and how that bit would look for various dividers of the rate of return, are illustrated in FIGURE 64, along with a number of cycles of measuring the time that have occurred since the last bit of Time. of Guard 1. In FIGURE 64 it can be seen that if the first edge occurs between an ascending and descending edge (labeled as ascending / descending), the optimum sampling point for a Return Speed Divider of one, the sampling point optimal is a cycle edge of measuring time labeled 'b', since that is the only rising edge that occurs within the period of the return bit. For a Return Speed Divider of two, the optimal sampling point is probably still the front edge 'b' since the edge 'C of the cycle is closer to a bit edge than' b '. For a Return Speed Divider of four, the optimum sampling point is probably the 'd' edge of the cycle of measuring time, since it is closer to the trailing edge of the return bit where the value has probably stabilized. Returning to FIGURE 64, however, if the first edge occurs between a descending and ascending edge (labeled as descend / ascend), the optimal sampling point for a Return Speed Divider of one, is the sampling point of the 'a' edge of the cycle of measuring time since that is the only rising edge within the period of the time of the return bit. For a Return Speed Divider of two, the optimum sampling point is the edge 'b', and for a Four Speed Return Divider, the optimum sampling point is the 'c' edge. It can be seen that as the velocity dividers become larger and larger, the optimal sampling point becomes easier to determine or select, as the rising edge that is closer to the middle should be. The host can use this technique to find the number of ascending timescale edges before the rising data edge of the timing packet data that is observed in the data line. It can then be decided based on whether the edge occurs between an ascending and descending edge or between a falling and ascending edge, and what rate of return velocity divider is, how many additional time-measuring cycles are added to a number counter, for reasonably ensure that the bit is always sampled as close to half as possible. Once the host has selected or determined the number of cycles to measure time, it can "explore" several divisors of the return speed with the client to determine if a particular Return Speed Divider will work. The host (and the client) can start with a divisor of one and verify the CRC of the return status packet received from the client to determine if this rate of return works properly for the data transfer. If the CRC is tampered with, there is probably a sampling error, and the host can increase the Return Speed Divider and try to request a status pack again. If the second requested package is altered, the divisor can be increased again and the request made again. If the packet is decoded correctly, this Return Speed Divider can be used for all future return packets. This method is effective and useful because the return timing should not change from the initial round trip timing estimate. If the non-return link is stable, the client must continue to decode the non-return link packets even if there are failures in the return link. Of course, it is still the responsibility of the host to establish a divider of the return link for the link, since this method does not guarantee a perfect return link. In addition, the divisor will depend primarily on the quality of measuring the time that is being used to generate time measurement 10. If that time measurement has a significant amount of oscillation, there is a greater possibility of a sampling error. This error probably increases with the number of cycles of measuring the time in the round trip delay. This implementation seems to work better for Type 1 return data, but may present problems for Type 2 to Type 4 return data due to bias between data lines that are potentially too large to run the link at the speed that works best for just a couple of data. However, the data rate probably does not need to be reduced for the previous method even with Type 2 to Type 4 for its operation. This method can also work better if it is duplicated on each data line to select the location of the sample to measure the ideal or optimal time. If they are in the same sample time for each data pair, this method would continue to work. If they are in different sample periods, two different methodologies can be used. The first thing is to select a more optimized or desired sample location for each data point, even if it is not the same for each pair of data. The host can then reconstruct the data stream after sampling all the bits of the set of data pairs: two bits for Type 2, four bits for Type 3, and eight bits for Type-IV. ' The other option is for the host to increment the Return Speed Divider so that the data bits for each data pair can be sampled at the same time-measuring edge.

XIII. Effects of Delay and Link Bias The delay bias in the non-return link between the MDDI_Data and MDDI_Stb pairs can limit the maximum possible data rate unless a compensation is used for the delay bias. The differences in the delay that cause a bias in the timing are due to the logic of the controller, the handlers and receivers of the line, and the cable and connectors as detailed below.

A. Link Timing Analysis Limited by Bias (MDDI Type 1) 1. Example of Delay and Bias of a Type 1 Link A typical interface circuit similar to the one shown in FIGURE 41, is shown in FIGURE 57 for adjust a Type 1 interface link. In FIGURE 57, exemplary or typical values for the propagation delay and bias are shown for each of the various processing phases or interface of a non-return MDDI Type 1 link. the delay between MDDI_Stb and MDDI_DataO causes the duty cycle of measuring the output time to be distorted. The data at input D of the receiver's swing circuit phase (RXFF) using tilting circuits 5728, 5732, changes slightly after the edge of measuring time so that it can be sampled reliably. The figure shows two cascade delay lines 5732a and 5732b that are used to solve two different problems with the creation of this timing relationship. In the current implementation these can be combined into a single delay element. The data, Stb, and the Recovery Timing of Measuring Time in a Type 1 Link for exemplary signal processing through the interface is illustrated in FIGURE 58. The total delay bias that is generally significant arises or comes from the sum of the bias in the following phases: transmitting tilting circuit (TXFF) with tilting 5704, 5706 circuits; transmitter handler (TXDRVR) with handlers 5708, 5710; CABLE 5702; receiver line receiver (RXRCVR) with 5722, 5724 receivers; and the logical XOR receiver (RXXOR). The Delayl 5732a must correspond to or exceed the gate delay 5736 XOR in the RXXOR phase that is determined by the relationship: pD - min (Delay 1) = tpD - max. { XOR) It is desirable to comply with this requirement so that the input D of the receiver tilting circuit 5728, 5732 does not change before its input to measure time. This is valid if the occupation time of RXFF is equal to zero. The purpose or function of Delay2 is to compensate the occupation time of the swinging circuit RXFF according to the relationship: tpo - min (Delay 2) = t__ (RXFP) In many systems this will be zero because the occupation time is zero, and of course in that case the maximum delay of Delay2 can also be zero. The worst case of contribution for the bias in the XOR phase of the receiver is in the case of delayed data / anticipated stroboscope where the Delayl is at a maximum value and the output of the XOR gate time measurement arrives as early as possible according to the relationship: tsKEW-max (RXXOR) ~ tpp-max. { .Delay 1) ~ tpD-min (0) In this situation, the data can change between two bit periods, n and n + 1, very close to the time where bit n + 1 is to measure the time within the receiver's tilting circuit . The maximum data rate (minimum bit period) of a Type 1 MDDI link is a function of the maximum bias that is found across all handlers, the cable, and the receivers in the MDDI link plus the total update of the data in the RXFF phase. The total delay bias in the link until the output of the phase RXRCVR can be expressed as: tsicEI.-max (J_INr.) = ts? -max (TXFF) + ts? _W-max (3XDJ.VR) + ts? EW-raax (CBLEBLE) + S? EW-max (RXRCVR) and the minimum bit period is provided by: * _Ur-m__ = tSKEW -em'mK) + 'ÍB-TP4 + i ?? yrnnett * tSKEW-ttm. { RXXOR) ^^ Itle -hoil + t PD-rpsxfd y) + ÍSU (.RXFF) In the example shown in FIGURE 57 for external mode, tSKEw-max (L__ ??) = 1000 psec. , and the minimum bit period can ^ be expressed as: tsxr-min = 1000 + 2 * 125 + 625 + 125 + 200 + 0 100 = 2300 psec, or set as approximately 434 Mbps.

B. Link Timing Analysis for MDDI Type 2, 3 and 4 A typical interphase circuit similar to that shown in FIGURES 41 and 57, is shown in FIGURE 59 for fitting Type 2, III and IV interface links. Additional elements are used in the phases TXFF (5904), TXDRVR (5908), RXRCVCR (5922), and RXFF (5932, 5928, 5930) can adjust the additional signal processing. In FIGURE 59, exemplary or typical values for propagation delay and bias are shown for each of the various processing phases or interface of a non-return link MDDI Type 2. In addition to the bias in the delay between MDDI_Stb and MDDI_Data0 that affects the duty cycle of measuring the output time, there is also a bias between these two signals and the other MDDI_Data signals. The data at the input D of the phase of the reciprocating circuit B of the receiver (RXFFB) consists of the tilting circuits 5928 and 5930, it is changed slightly after the edge of measuring the time so that they can be reliably sampled. If MDDI_Datal arrives before MDDI_Stb or MDDI_Data0 then MDDI_Datal should be delayed to be sampled by at least the amount of delay bias. To achieve this, the data is delayed using the Delay3 delay line. If MDDI_Datal arrives later than MDDI_Stb and MDDI_DataO and is also delayed by Delay3 then the point at which MDDI_Datal changes moves closer to the next edge of measuring time. This process determines an upper limit of the data rate of an MDDI Type 2, 3 or 4 link. Some different exemplary possibilities for the timing or bias relationship of the two data signals and MDDI_Stb with respect to each other is illustrated in FIGURES 60A, 60B and 60C. To reliably sample data in RXFFB when MDDI_DataX arrives as early as possible, Delay3 is set according to the following relationship: tpD-min (Delay3) = tsKEW-taax (LINK) + tH (FFB) + Maximum link speed it is determined by the minimum allowable bit period. This is mostly affected when MDDI_DataX arrives as delayed as possible. In that case, the minimum allowable cycle time is provided by: tB-T-min = tsKEW-max (LINK) + tpD -__ ax (Delay3) + tSu (RXFFB) ~ tpD-min (XOR) The upper limit of the Link speed is then: tpD-max (Delay3) ~ tpD-min (Delay3) and provides that assumption: tBIT-min (lower-bound) = 2 ts? EW-max (LINK) + tp -max (XOR) + tSu (RXFFB) + tH (RXFFB) In the example given above, the lower limit of the minimum bit period is given by the relation: Bjr-min (iot.er- £> ound) = 2 • (1000 + 2 «125 + 625 + 200) +1500+ 100 + 0 = 5750 psec , which is approximately 174 Mbps. This is much slower than the maximum data rate that can be used with a Type 1 link. The compensation capability of the MDDI automatic delay bias significantly reduces the impact that the delay bias has on The maximum link speed factor is just at the edge of the valid data set. The bias calibrated between MDDI_DataO and MDDI_Stb is: and the minimum bit period is: rr-pia-Calibrale ~ + * SU (SX) In the example shown in Figure 8-5, Tskwemax (DataO-Stb-Calibrated) = 300 psec and the minimum bit period is: -n? Lc «/ ¿rr r = 300 + 2.125 + 625 +200 +175 - lOO =: 1650 secJ of approximately 606 Mbps. To reliably sample the data in RXFFB when MDDI_Datal arrives as soon as possible, the associated programmable delay is adjusted in the optimal configuration with a precision of one derivation, and a delay of Additional derivation is added for security. The maximum link speed is determined by the minimum allowable bit period. This is mostly affected when MDDI_Datal arrives as late as possible. In that case, the minimum allowable cycle time is: TjlIT-ti? A-Datal-Calibrated ~ * • 'In the example given in Figure 8-5, the lower limit of the minimum bit period based on the DaDI MDDI sampling is: tm-t? i-Datal-Calibrated = 2-150 + 2-125 = 55 pSQC XIV. Description of Physical Layer Interconnection Useful physical connections for implementing an interface in accordance with the present invention can be made using commercially available parts such as part number 3260-8S2 (01) manufactured by Hirose Electric Company Ltd. on the host, and part number 3240-8P-C manufactured by Hirose Electric Company Ltd. on the client device side. An exemplary mapping of the interface contacts or "contact map" for such connectors is used with the Type I / Type 2 interfaces listed in Table XIII, and is illustrated in FIGURE 61.

Table XIII The shield connects to the H0ST_Gnd on the host interface, and a protective drain wire on the cable connects to the customer's connector shield.

However, the protector and drain wire are not connected to the interior of the customer's ground circuit. The interconnecting elements or devices are chosen or designed to be small enough to be used with mobile communication and computing devices, such as PDAs and cordless phones, or portable gaming devices, without being annoying or unsightly compared to the size relative of the device. Any connectors and wiring should be durable enough to be used in a typical consumer environment and allow for a small size, especially for wiring, and should be relatively inexpensive. The transfer elements must accommodate the data signals and strobes that are differential NRZ data that have a transfer rate of up to approximately 450 Mbps for Type 1 and Type 2 and up to 3.6 Gbps for the Type 4 8-bit version in parallel. For the applications of internal mode there are no connectors in the same sense that for the conductors that are used or such connection elements tend to miniaturize a lot. An example is the "female plugs" of zero insertion force to receive integrated circuits or elements that host either the host device or the client. Another example is where the host and the customer reside on printed circuit boards with multiple conductors that are interconnected, and that have "legs" or contacts extending from the housings that are welded to contacts in the conductors for their interconnection with the conductors. integrated circuits .

XV Operation FIGURES 54A and 54B show a summary of the general steps that are carried out in the processing of data and packets during the operation of an interface using embodiments of the invention, together with an overview of the packet processing of the invention. interface apparatus in FIGURE 55. In these figures, the process starts at a step 5402 with a determination as to whether the client and the host are connected or not using a communication path, which in this case is a cable. This can occur through the periodic use of queries by the host, using software or hardware that detects the presence of connectors or cables or signals at the host's inputs (as seen for USB interfaces), or other known techniques. If there is no client connected to the host, then simply enter a waiting state for some predetermined length, depending on the application, which is directed to a hibernation mode, or which is inactivated to wait for a future use that could require that a user will take some action to reactivate the host. For example, when a host resides on a computer-like device, a user could click on an icon on the screen or ask a program to activate host processing to search for the client. Again, a simple male plug in a USB type connection could activate the host's processing, depending on the functions and configuration of the host or the software of the resident host. Once a client connects to the host, or vice versa, or is detected to be present, either the client or the host sends appropriate packets requesting the service in stages 5404 and 5406. The client could send either Request packages or Customer Service Status in step 5404. It is noted that the link, as discussed above, could have been previously closed or could be in hibernation mode, so this might not be a complete initialization of the communication link that follows . Once the communication link is synchronized and the host is trying to communicate with the client, the client also provides a package of Client Functions to the host, as in step 5408. The host can now begin to determine the type of support , including transfer speeds, which the customer can adjust. Generally, the host and the client also negotiate the type (speed / speed) of the service mode to be used, for example Type 1, Type 2, etc., in a step 5410. Once the type of service is set, the host can begin to transfer information. In addition, the host may use Round Trip Delay Measurements to optimize the timing of communication links in parallel with other signal processing, as shown in step 5411. As stated above, all transfers begin with a Sub-Frame Header Pack, which is shown to be being transferred in step 5412, followed by the data type, which here are audio and video stream packets, and padding packets, which are shown to be being transferred in step 5414. The audio and video data will have been previously prepared or mapped within packets, and filler packets are inserted as necessary or desired to fill a required number of bits for the media frames. The host can send the packets so that the Enabled Audio Channel Enabled Packages activate the sound devices. In addition, the host can transmit commands and information using other types of packets discussed above, which are shown here as the Color Map transfer, Bit Block Transfer or other packets in step 5416. In addition, the host and The customer can exchange data that is related to a keyboard or pointing devices that use the appropriate packages. During the operation, one of several different events may occur that lead to the host or the client desiring a different data rate or type of interface mode. For example, a computer or other data communication device could encounter load conditions in the processing data which causes a slowdown in the preparation or presentation of the packets. A client device that receives the data could change from a dedicated AC power source to a more limited battery power source, and would not be able to transfer data as quickly, process commands easily, or be in a position to do so. to use the same degree of resolution or depth of color under the most limited electrical power settings. Alternatively, a restrictive condition could collapse or disappear allowing any device to transfer data at higher speeds. Since this is more desirable, a request can be made to change to a higher transfer rate mode. If these or other types of known conditions occur or change, either the host or the client can detect them and try to renegotiate the interface mode. This is shown in step 5420, where the host sends Type Intracellular Transfer Request Packs to the client requesting an intracell transfer to another mode, the client sends the Interface Type Recognition Packs confirming a change that is being sought, and the host sends the Intracellular Transfer Type Packages Execution to make the change to the specified mode. Although, a particular processing order is not required, the client and the host can also exchange packets that are related to the data that is intended for or received from the pointing devices, keyboards, or other type of data. user input devices mainly associated with the client, although such elements could also be present on the host side.

These packages are typically processed using a general processor type element and not the state machine (5502). In addition, some of the commands discussed above will also be processed by the general processor. (5504, 5508) After the data and commands have been exchanged between the host and the client, at some point a decision is made as to whether or not additional data will be transmitted or whether the host or the client is going to stop providing transfer service. This is shown in step 5422. If the link is going to either enter into a hibernation state or is to be closed completely, the host sends a Link Breaker packet to the client, and both sides terminate the data transfer. The packets that are transferred in the processing of the previous operations will be transferred using the handlers and receivers previously discussed in relation to the host and client controllers. These online handlers and other logic elements are connected to the state machine and the general processors discussed above, as illustrated in the overview of FIGURE 55. In Figure 55, a state machine 5502 and processors 5504 and 5508 general can be connected in addition to other elements that are not shown such as a dedicated USB interface, memory elements or other components that reside outside the link controller with which it interacts, including, but not limited to, the data source , and chips for video control to see the deployment devices. The processors, and the state machine provide control through the enabling and disabling of the drivers as discussed above in relation to guarding times, etc., to ensure an efficient establishment or termination of the communication link, and the transfer of packages.

XVI Deployment Screen Intermediate Memories Intermediate storage requirements for video data are different for moving video images compared to computer graphics. Most pixel data is often stored in a local frame buffer on the client so that the image on the client can be locally refreshed. When a full-motion video is being displayed (almost every pixel in the display changes every Media Frame) it is usually preferred to store the incoming Pixel data in a frame buffer while the image in the display is being refreshed from a second frame buffer. More than two deployment buffers can be used to eliminate visible artifacts as described below. When an entire image has been received in a frame buffer, then the role of the buffers can be swapped, and the newly received image is then used to refresh the display and the other buffer is filled with the next frame of the image . This concept is illustrated in FIGURE 91A, where the pixel data is written to the offline image buffer by setting the Deployment Update bits to '01'. In other applications the host needs to update only a small portion of the image without having to repaint the entire image. In this situation it is desired to write the new pixels directly into the buffer that is being used to renew the display, as illustrated in detail in FIGURE 91B. In applications that have a fixed image with a small video window it is easier to write the still image for both buffers (display update bits equal to "11") as shown in FIGURE 91C, and subsequently write the pixels of the moving image in the offline buffer when adjusting the update bits of deployment in '01'. The following rules describe the useful manipulation of the buffer flags while simultaneously writing new information to the client and to renew the deployment. There are three buffer flags: current_fill points for the buffer that is currently being filled from the data through the MDDI link. Just_filled points for the buffer that was almost recently filled. Points being_displayed for the buffer that is currently being used to refresh the deployment. All three buffer flags can contain values from 0 to N-l where N is the number of buffers in the deployment, and N _ >; 2. The arithmetic in the buffer flags is to modify N, for example when N = 3 and current_fill = 2, increasing current_fill causes current_fill to be set to 0. In the simple case where N = 2, just_filled is always complemented with current_fill . At each Frame Limit of MDDI Media (Sub-frame Header Pack with Sub-frame Count field equal to zero) carry out the following operations in the specified order: set just_filled equal to current_fill, and set current fill equal to current fill + 1.

The MDDI Video Stream Packs update the buffers according to the structure or methodology of: when the Deployment Update Bits are equal to '01', the pixel data is written to the buffer specified by current_fill; when the Deployment Update Bits are equal to '00', the pixel data is written to the buffer specified by just_filled, and when the Deployment Update Bits are equal to '11', the pixel data is written to all the intermediate memories. The deployment is refreshed from the buffer specified by the being_displayed flag. After the display renews the last pixel in a frame renewal time and before it starts to renew the first pixel in the next frame renewal time the deployment update process performs the adjustment operation being_refreshed equal to just_filled; The Video Stream Package contains a pair of Deployment Update Bits that specify the frame buffer where the pixel data is to be written. The Client Capacity Package has three additional bits that indicate which combinations of Deployment Update Bits are supported on the client. In many cases, computer generated images need to be updated gradually based on the user's data entry or derived from the information received from the computer network. The combinations of Display Update Bits '00' and "ii" support this mode of operation by causing the pixel data to be written to the frame buffer being deployed or to both frame buffers. When video images are accommodated, FIGURE 92 illustrates how video images are deployed using a pair of frame buffers when video data is transmitted over the MDDI link with the Display Update Bits equal to '01' After a media frame limit is detected in the MDDI link, the deployment refresh process will begin to renew from the next frame buffer when the refresh process for the frame that is currently being refreshed has been completed. An important assumption that relates to FIGURE 92 is that the image is received from the host as a direct stream of pixels that are transmitted in the same order that the client uses to read the pixels in the frame buffer to refresh the display (usually upper left, reading row by row, to the lower right corner of the screen.

This is an important detail in the cases in which the Renew Deploy and Transfer Image operations refer to the same frame buffer. It is necessary that the display frame refresh rate be greater than the frame rate of the image frame to avoid • partial display of images. FIGURE 93 shows how image fragmentation can occur with a slow roll-out refresh rate, that is, the roll-up refresh is slower than the image transfer. In an image that contains a combination of computer graphics images and moving video movies, the pixel data of the video could occupy a small portion of a media frame. This could be important in situations where the operation of renewing the display and transferring the image refers to the same frame buffer. These situations are shown by a grid shading in FIGURE 94, where the pixels read from the buffer to renew the display could be the pixels written in the buffer of two previous frames, or they could correspond to the frame that is being written immediately. in the same frame buffer. The use of three frame buffers in the client will solve the problem of the small containment window to access a frame buffer as shown in FIGURE 95. However, there is still a problem if the rollback refresh rate is less than the speed of the media frame through the MDDI link, as shown in FIGURE 96. The use of a single buffer for moving video images is somewhat problematic as shown in FIGURE 97. When the renewal of the display is faster than the transfer of the image within the buffer, the image that is being renewed can sometimes show the upper portion of the frame being written and the lower portion of the image will be that of the previously transferred frame. When the renewal of the display is faster than the image transfer (the preferred mode of operation) there will be more frequent cases of frames that show a similar image division.

XVII. Delay Value Table The Package Processing Delay Parameter Pack uses a table search capability to calculate the predicted delay to process certain commands on the client. The values in the table are increased in a logarithmic way to provide a very wide dynamic range of the delay values. An exemplary table of delay values useful for implementing the embodiments of the invention is found in Table XX below, with the corresponding index values confronted with the delay values.

Table XX 0-no_delay 37-1.5ns 74-51ns 111 - 1.8us 148 - 62us 185 - 2.2ms 222-75_ns 1 - 46ps 38 - l.dns 75 - 56ns 112-2.0us 149 - 68us 186-2.4ms 223 - 83ms 2-5.ps 39 - 1.8ps 76 - 62ns 113-2.2us 150-75us 187-2.6? Rts 224-91ms 3 - 56ps 40 - 2.0ps 77 - 68ns 114-2.4us 151 - 83us 188-2.9ms 225 - lOOms 4 - 62? s 41 - 2.2ns 78-75ns 115-2.6us 152-91us 189 - 3.2ms 226-110ms 5 - 68ps 42-2.4ns 79 - 83ns H6-2.9us 153 - lOOus 190 - 3.5p? s 227 - 120ms 6 - 75ps 43 - 2.6ps 80-91ps 117 - 3.2us 154-UOus 191 - 3.8ms 228 - 130ms 7 - 83ps 44-2.9ns 81 - lOOns 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 - lOOps 46 - 3.5ns 83 - 120ns 120-4.2us 157 - 150us 194-5.1 s 231 - 180 ? ns 10-110ps 47-3.8ns 84-130ns 121-4.6us 158 - 160us 195 - 5.6ms 232-200ms 11 - 120ps 48 - 4.2ns 85 - 150ps 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-240ras 13 - 150ps 50-5.1ns 87-1 80ns 124-6.2us 161 - 220us 198-7.5ms 235 - 260ras 14 - 160ps 51 - 5.6ns 88-200ns 125 - 6.8us 162 - 240us 199 - 8.3ms 236 - 290ms 15-180ps 52 - 6.2ps 89 -220- s 126-7.5us 163-260us 200-9.1ms 237 - 320ras 16 - 200ps 53 - 6.8ns 90 - 240r_5 127 - 8.3us 164-290us 201 - lOms 238 - 350ms 17-220ps 54-7.5ns 91 - 260ns 128- 9.1us 165 - 320us 202 - llms 239 - 380ms 18 - 240ps 55 - 8.3ns 92-290ns 129 - lOus 166-350us 203 - 12ms 240 - 420ms 19 - 260ps 56-9.1ps 93 - 320ns 130 - llus 167 - 380us 204 - 13ms 241 - 460ms 20 - 290ps 57-10ns 94-350ns 131 - 12us 168 - 420us 205 - 15ms 242-510ms 21 - 320ps 58 - llps 95 - 380ps 132-13us 169-460us 206 - 16ms 243 - 560r_s 22-350ps 59 - 12ns 96 - 420ns 133 - 15us 170 - 510us 207 - 18ms 244-620_as 23 - 380? S 60 - 13ns 97 - 460ps 134 - 16us 171-560us 208 - 20ms 245 - 680ms 24-420ps 61 - 15ns 98-510ns 135 - ldus 172 - 620us 209 - 22m_ 246 - 750ms 25 - 460ps 62 - 16ns 99 - 560ns 136 - 20us 173 - 680us 210-24m_ 247 - 830ms 26 - SlOps 63 - 18ns 100 - 620ps í3 7-22us 174-750us 211-26ms 248 - 910ms 27 - 560ps 64 - 20ns 101 - 680ps 138 - 24us 175 - 830us 212-29ms 249 - l.Osec 28 - 620ps 65 - 22ps 102-750ps 139-26us 176-910us 213 - 32ms 250 - l.lsec 29 - 680ps 66-24ns 103 - 830ns 140-29us 177 - l.Oms 214 - 35ms 251 - 1.2sec 30 - 750ps 67 - 26ns 104-910ns 141 - 32us 178 - l.lms 215 -38m_ 252 - 1.3sec 31 - 830ps 68-29ns 105-l.Ous 142-35us 179 - 1.2ms 216 - 42ms 253 - 1.5sec 32-910ps 69 - 32ns 106-l.lus 143 - 38us 180 - 1.3ms 217 -46ms 254-1.6s 33 - l.Ons 70-35ns 107 - 1.2us 144-42us 181 - 1.5ms 218-51ms 255 - undefined 34-l.lns 71 - 38ps 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.0 s 221 - 68ms The delay is calculated by executing a table search using the parameter specified as an index within the table. This means that a delay is equal to the PacketProcesingTable (index). For example: if one of the parameters of the Element of the List of Delay Parameters is an 8-bit value equal to 134, then the delay is equal to PacketProcesingTable (134) which is 16 μsec. The value 255 indicates that the end time of the command can not be determined by calculation, and that the host will check the Busy Graphics indicators in the Client Request and the Status Packet or the BCC Control Parameter B7h. In some cases this delay is multiplied by the height, width or number of pixels in the target image and added to other delays to calculate the overall delay of the packet processing.

XVIII. Multiple Client Support The current protocol version does not seem to directly support multiple client devices. However, most packages contain a reserved field for the Client ID that can be used to address client-specific devices in a system with multiple clients. Currently, for many applications, this customer ID or these customer IDs are set to zero. The sub-frame header packet also contains a field to indicate whether the host supports a multi-client system or not. Therefore, there is a way in which multiple client devices could probably be connected and addressed in future applications of the MDD interface or protocol to help system designers plan future compatibility with multiple hosts and clients. In systems that have multiple clients it is useful for clients to connect to the host using a client chain connection, or to use nodal centers, as shown in Figure 98, or to use a combination of these techniques as shown in FIGURE 99.

XIX Appendix In addition to the formats, structures and contents discussed above for the various packages used to implement the architecture and protocol of the embodiments of the invention, more detailed field operations or contents for some of the package types are presented here. These are presented here to further clarify their respective use or operations to enable those of ordinary skill in the art to more readily understand and make use of the invention for a variety of applications. Only a few of the fields that have not been discussed are already discussed here. In addition, these fields are presented with definitions and exemplary values in relation to the modalities presented above. However, such values should not be considered as limitations of the invention, but represent one or more useful modalities for implementing the interface and the protocol, and not all modalities need to be practiced together or at the same time. Other values may be used in other modalities to achieve the desired data presentation or data rate transfer results as understood by those of skill in the art.

A. For Video Stream Packages In a modality, the Attributes field of the Pixel data (2 bytes) has a series of bit values that are interpreted as follows. Bits 1 and 0 select how the pixel data of the display is routed. For bit values of '11' the data is displayed in or for both eyes, for bit values '10', data is routed only to the left eye, and for bit values of '01', the data is routed only to the right eye, and for bit values of '00' the data is routed for an alternate display as can be specified by bits 8 through 11 discussed above.

Bit 2 indicates whether or not the Pixel Data is presented in an interlaced format, with a value of '0' which means that the pixel data is in the standard progressive format, and that the row number (Y coordinate of pixel) is increased by one when advancing from one row to the next. When this bit has a value of '1', the pixel data is in the interlaced format, and the row number is increased by 2 when advancing from one row to the next. Bit 3 indicates that the Pixel Data is in the alternate pixel format. This is similar to the standard interlaced mode enabled by bit 2, but the interlacing is vertical instead of horizontal. When Bit 3 is O 'the Pixel Data is in the standard progressive format, and the column number (pixel X coordinate) is increased by 1 as each successive pixel is received. When Bit 3 is '1' the Pixel Data is in the alternate pixel format, and the column number is increased by 2 as each pixel is received. Bit 4 indicates whether or not the Pixel Data is related to a display or a camera, as if it were the data being transferred to or from an internal display for a cordless phone or similar device or even a portable computer, or some other devices such as those discussed above, or the data that is being transferred to or from an integrated camera or directly coupled to the device. When Bit 4 is '0' the Pixel data is being transferred to or from a deployment buffer. When Bit 4 is '1' they are being transferred to and from a camera or video device of some kind, such devices are well known in the art. Bit 5 is used to indicate when the pixel data contains the next consecutive row of pixels in the display. This is considered in the case where Bit 5 is set equal to '1'. When bit 5 is set to '1' then the parameters Left Edge X, Top Edge Y, Right Edge X, Bottom Edge Y, Start X and Start Y are not defined and are ignored by the client. When Bit 15 is set to a logical one level, this indicates that the pixel data in this packet is the last row of pixels in the image. Bit 8 of the Customer Feature Capacity Indicators field of the Client Capacity Package indicates whether this feature is supported. Bits 7 and 6 are Deployment Update Bits that specify a frame buffer where the pixel data is to be written. The more specific effects are discussed elsewhere. For bit values of '01' the Pixel data is written to the buffer of the offline image. For the bit values of '00' the Pixel data is written to the image buffer used to refresh the display. For the bit values of '11' the Pixel data is written to all the image buffers. The bit values or the combination of? 10 'are treated as an invalid value or designation and the Pixel data is ignored and is not written to any of the image buffers. This value can have a use for future applications of the interface. Bits 8 through 11 form an unsigned 4-bit integer that specifies an alternate display or deployment location when the pixel data is to be routed. Bits 0 and 1 are set equal to '00' so that the client's display interprets bits 8 through 11 as an alternate display number. If bits 0 and 1 are not equal to '00' then bits 8 to 11 are set to levels of logical zero. Bits 12 through 14 are reserved for future use and are generally set at logical zero levels. Bit 15, as discussed, is used in conjunction with bit 5, and setting bit 15 to a logical one indicates that the row of pixels in the Pixel Data field is the last row of pixels in a data frame . The next Video Stream Package having bit 5 set to a logical one will correspond to the first row of pixels of the next video frame. The Start X and Start Y 2-byte fields specify the absolute X and Y coordinates of the point (Start X, Start Y) for the first pixel in the Pixel Data field. The fields of Left Border X and Upper Border Y of 2 bytes specify the X coordinate of the left edge and the Y coordinate of the upper edge of the screen window filled with the 'Pixel Data field, while the Right Edge fields X and Bottom Edge Y specify the X coordinate on the right edge, and the Y coordinate on the bottom edge of the window that is being updated. The Pixel Count field (2 bytes) specifies the number of pixels in the Pixel Data field below. The CRC Parameter field (2 bytes) contains a CRC of all bytes from the Packet Length to the Pixel Count. If this CRC fails to verify then the entire packet is discarded. The Pixel Data field contains the video information in its primary state to be displayed, and which is formatted in the manner described by the Format Data Descriptor field. The data is transmitted one at a time "in a row" as discussed elsewhere. When Bit 5 of the Pixel Data Attributes field is set to a logical one level, then the Pixel Data field contains exactly one row of pixels, with the first one being transmitted in correspondence to the pixel that is most the left and the last transmitted pixel correspond to the pixel that is furthest to the right. The CRC field of the Pixel Data (2 bytes) contains a 16-bit CRC of only the Pixel Data. If a CRC check of this value fails then the Pixel Data can still be used, but the CRC error count is increased.

B. For Audio Stream Packages In one mode, the Audio Channel ID field (1 byte) uses an unsigned 8-bit integer value to identify a particular audio channel to which the audio streams are to be sent. audio data through the client device. Physical audio channels are specified or mapped for physical channels by this field as values of 0, 1, 2, 3, 4, 5, 6, 6, 1 indicating left front, right front, left rear, right back, center channels front, sub-bass (sub-woofer), surround left and envelope right, respectively. An audio channel ID value of 254 indicates that the only current of the digital audio samples is sent to both the front left and right front channels. This simplifies communications for applications such as where a stereo handset is used for voice communication, productivity improvement applications that are used in a PDA, or other applications where a simple User Interface generates warning tones. Values for the ID field ranging from 8 to 253, and 255 are currently reserved for use where new designs desire additional designations, as anticipated by those skilled in the art. The reserved field 1 (1 byte) is generally reserved for future use, and all bits in this field are set to zero. One capability of this field is to cause all subsequent 2-byte fields to align with a 16-bit word address and cause the 4-byte fields to be aligned with a 32-bit word address. The Audio Sample Count field (2 bytes) specifies the number of audio samples in this packet. The Bits Per Sample and Packaging field contains 1 byte that specifies the audio data packaging format. In one embodiment, the format generally used is for Bits 4 to 0 to define the number of bits per PCM audio sample. Bit 5 then specifies whether the Digital Audio Data samples are packaged or not. As mentioned above, FIGURE 12 illustrates the difference between audio samples packaged and aligned by byte. A value of '0' for Bit 5 indicates that each sample of PCM audio in the Digital Audio Data field is aligned by bytes with the interface byte limit, and a value of '1' indicates that each audio sample Successive PCM is packaged against the previous audio sample. This bit is effective only when the value defined in bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of eight. Bits 7 through 6 are reserved for use where system designs desire additional designations and are generally set to a value of zero. The Audio Sample Rate field (1 byte) specifies the speed of the audio PCM sample. The format used is for a value of 0 to indicate a speed of 8,000 samples per second (sps), a value of 1 indicates 16,000 sps., A value of 2 for 24,000 sps, a value of 3 for 32,000 sps, a value of 4 for 40,000 sps, a value of 5 for 48,000 sps, a value of 6 for 11,025 sps, a value of 7 for 22,050 sps, and a value of 8 for 44,100 sps, respectively, with values of 9 to 255 being reserved for a future use, so they are currently set to zero. The CRC Parameter 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 verify properly, then the entire packet is discarded. The Digital Audio Data field contains the audio samples in their original state to be played, and usually is in the form of a linear format as unsigned integers. The CRC field of the audio data (2 bytes) contains a 16-bit CRC of only Audio Data. If the CRC fails to verify, then the Audio Data can still be used, but the CRC error count is increased.

C. For User Defined Current Packs In one mode, the 2-byte Current ID Number field is used to identify a current defined by the particular user. The contents of the Current Parameter fields and the Current Data are typically defined by the manufacturer of the MDDI equipment. The CRC Parameter field of the 2-byte Current contains a 16-bit CRC for all bytes of the current parameters starting from the Packet Length up to the Audio Coding byte. If this CRC fails to verify, then the entire packet is discarded. Both Current Parameter and Current .CRC Parameter fields can be discarded if they are not necessary for a final application of the MDD interface, that is, they are considered optional. The CRC field of 2-byte Current Data contains a CRC of only the Current Data. If this CRC fails to verify properly, then the use of the Current Data is optional, depending on the requirements of the application. The use of the quotient of the data stream in the CRC that is good, generally requires that the current data be stored in an intermediate form until the CRC is confirmed as being good. The CRC error count is increased if the CRC is not verified.

D. For Color Map Packs The 2-byte Client ID field contains information or values that are reserved for a Client ID, as previously used. Since this field is generally reserved for future use, the current value is set to zero, by setting the bits to '0'. The 2-Byte Color Map Element Counting field uses values to specify the total number of 3-byte color map elements that are contained in the Color Map Data field, or the map table entries of color that exists in the Color Map Data in this package. In this mode, the number of bytes in the Color Map Data is 3 times the Color Map Element Count. The Color Map Element Count is set equal to zero to not send any data from the color map. If the Color Map Size is zero then a Color Map Offset value is generally still sent but ignored by the display. The Color Map Offset field (4 bytes) specifies the offset of the Color Map Data in this packet from the start of the color map table on the client device. A 2-byte CRC Parameter field contains a CRC of all bytes from the Packet Length to the Audio Coding byte. If this CRC fails to verify, then the entire packet is discarded. For the Color Map Data field, the width of each location of the color map is specified by the Color Map Element Size field, where in one mode the first part specifies the magnitude of the blue, the second part specifies the magnitude of the green, and the third part specifies the magnitude of the red. The Color Map Size field specifies the number of elements of the 3-byte color map table that exist in the Color Map Data field. If a single color map can not be set within a Video Data Format and Color Map Pack, then the entire color map can be specified by sending multiple packets with different Color Map Data and Color Map Offsets in each package . The number of bits for blue, green and red in each color map data element is generally the same as specified in the RGB Width field of the Color Map of the Deployment Capability Package. A 2-byte Color Map Data CRC field contains a CRC of only the Color Map Data. If this CRC fails to verify, then the Color Map Data can still be used even though the CRC error count is increased. Each color map data element will be transmitted in the order: blue, green, red, with the least significant bit of each component transmitted first. The individual red, green and blue components of each color map element are packed, although each color map element (the least significant bit of the blue component) should be aligned by bytes. Figure 100 illustrates an example of the color map elements with 6 bits of blue, 8 bits of green, and 7 bits of red. For this example, the Color Map Element Size in the Color Map Packet is equal to 21, and the RGB Width field in the Color Map of the Customer Capacity Packet is equal to 0x0786.

E. For Return Link Encapsulation Packages The CRC Parameter field (2 bytes) contains a 16-bit CRC of all bytes from the Packet Length to the Sense Inversion Length. If this CRC fails to verify, then the entire package is discarded. In one modality, the Return Link Indicators field (1 byte) contains a set of indicators to request customer information. If a bit (for example, Bit 0) is set to a logical one level, then the host only specifies the information of the deployment using the Client Capacity Package. If the bit is set to a logical zero level, then the host does not need the client's information. The remaining bits (which here are Bits 1 to 7) are reserved for future use and are set to zero. However, more bits may be used as desired to set indicators for the return link. The Return Speed Divider field (1 byte) specifies the number of MDDI_Stb cycles that can occur in relation to measuring the data time of the return link. Measuring the data time of the return link is equal to measuring the data time of the non-return link divided by twice the Return Speed Divider. The data rate of the return link is related to the data time measurement of the return link and the Interface Type on the return link. In this mode, for a Type 1 interface the return data rate equals the data time measurement of the return link, for the Type 2, Type 3 and Type 4 interfaces the return data rates equal twice, four times , and eight times the data measurement of the return link, respectively. The All-in-Zero 1 field contains a group of bytes, which here are 8, that is, it is set equal to zero in the value by setting the bits at a logical zero level, and is used to make sure that the MDDI_Data signals are at a logical zero level for a sufficient time to allow the client recovering the time measurement to use only MDDI_Stb prior to disabling the host's online handlers during the Sense Inversion field 1. In one mode, the length of the field of Everything in Zero 1 is greater than or equal to the number of times of the transmission of the byte of the non-return link in the round trip delay of the cable. The field of Length of Inversion of Sense 1 (1 byte) specifies the total number of bytes that are destined for Inversion of Sense 1, establishing the first period of inversion of direction. The number of bits specified by the Sense Inversion Length 1 parameter is intended to allow the MDDI_Data inline handlers on the client to be enabled, before the online handlers on the host are disabled. The client enables its MDDI_Data on-line handlers during 0 bit of Inversion of Sense 1 and the host disables its entries so that they are completely disabled before the last bit of Inversion of Sense 1. The timing processes to enable the handler of the The client and disable the host handler are such that one or both of them drive the MDDI_Data signals at a logical-zero level through all the Inversion of Sense 1 as seen by the online receivers in the host. The MDDI_Stb signal behaves as if MDDI_DataO were at a logical-zero level during the entire Sense-Inversion period 1. A more complete description of the Sense-1 inversion setting is given in the above. The Return Data Package field contains a series of data that is transferred from the client to the host. The client can send filler packets or trigger the MDDI_Data lines in a state or level of logical-zero when there is no data to send to the host. In this mode, if the MDDI_Data lines are set to zero, the host will interpret this as' a packet with a zero length (invalid length) and the host will not accept any additional packets from the client during the current Return Link Encapsulation Pack. The field of Length of Inversion of Sense 2 (1 byte) specifies the total number of bytes that are destined for Inversion of Sense 2, to establish a second period of reversal of direction. The number of bytes specified by the Sense Inversion Length parameter is intended to allow MDDI_Data in-line handlers on the host to be enabled before online handlers on the client are disabled. The host enables its handlers' in line MDDI_Data during bit 0 of the first byte in Inversion of Sense 2, and the client disables its outputs so that they are completely uninhabited in general prior to the last bit of Sense Inversion 2. The processes of timing to disable the client handler and enable the host handler are such that one or both of them drive the MDDI_Data0 signals at a logical-zero level through all or throughout, the Inversion of Sense 2 period, as seen by the online receivers in the host. The MDDI_Stb signal behaves as if MDDI_DataO were at a logical-zero level for substantially the entire Sense-Inversion period 2. A description of the Sense-Inversion 2 setting is given in the above. The Return Data Package field contains a series of data packets that are transferred from the client to a host. As stated above, the Filler packets are sent to fill the remaining space that is not used by other types of packages. The All-in-Zero 2 field contains a group of bytes (8 in this mode) that is set equal to zero in their value by setting the bits at a logical-zero level, and is used to ensure that all the MDDI_Data signals they are at a logical-zero level for a sufficient time to allow the client to start recovering the time measurement using both MDDI_DataO and MDDI_Stb after enabling the host's online handlers after the Sentido 2 reversal field.

F. For Client Capacity Packages As illustrated for a modality, the Protocol Version field uses 2 bytes to specify a version of the protocol that the client is using. The initial version is currently set equal to zero, and will change over time as new versions are generated as is known, although the Minimum Protocol Version field uses 2 bytes to specify the minimum protocol version that the client can send or interpret. In this case, a value of zero is also a valid value. The Data Rate capacity field (2 bytes) specifies the maximum data rate that the client can receive in each data pair in the non-return link of the interface, and is specified in the form of megabits per second (Mbps) ). The Interface Type capability field (1 byte) specifies the interface types that are supported on the non-return and return links. A bit set to "1" indicates that a specific interface type is supported, and a bit set to "0" indicates that the specified type is not supported. Hosts and customers should support at least Type 1 on the non-return and return lines. There is no requirement to support a contiguous range of interface types. For example, it would be perfectly valid to only support a Type 1 and Type 3, but not a Type 3 and Type 4 in an interface. This is also not necessary for non-return and return links to operate with the same type of interface. However, when a link exits from hibernation, both of the non-return and return links should start in type 1 mode until they can be negotiated, selected or approved in other ways to be used with both the host and the client. Supported interfaces are indicated in a mode by selecting either Bit 0, Bit 1, or Bit 2 to select either a Type 2 (2 bits), Type 3 (4 bits), or Type 4 (8 bits) in the link without return, respectively; and the Bit 3, Bit 4, or Bit 5 mode to select either a Type 2, Type 3, or Type 4 on the return link, respectively; with Bits 6 and 7 that are reserved and that are generally set to zero at this time. The 7th and High fields of the Bitmap have 2 bytes in each here, they specify the width and height of the bitmap, respectively, in pixels. The Monochrome (1 byte) capacity field is used to specify the number of resolution bits that can be displayed in a monochrome format. If a deployment can not use a monochrome format, then this value is set to zero. Bits 7 through 4 are reserved for future use and are thus set to zero. Bits 3 through 0 define the maximum number of bits of the gray scale that can exist for each pixel. These four bits make it possible to specify values from 1 to 15 for each pixel. If the value is zero, then the monochrome format is not supported by the display. The Bayer Capacity field uses 1 byte to specify the number of resolution bits, the pixel group and the order of the pixel that can be transferred in the Bayer format. If the client can not use the Bayer format then this value is zero. The Bayer Capacity field is composed of the following values: Bits 3 through 0 define the maximum number of intensity bits in each pixel, although Bits 5 through 4 define the pixel group pattern that is required, although Bits 8 up to 6 define the order of the pixel that is required; with Bits 14 through 9 that are reserved for future use and are generally set to zero in the meantime. Bit 15 when set to one indicates that the client can accept the Bayer pixel data either in the packaged or unpacked format. If bit 15 is set to zero this indicates that the client can accept the Bayer pixel data only in the unpacked format. The Color Map Capacity field (3 bytes) specifies the maximum number of table elements that exist in the color map table in the display. If the deployment can not use the color map format then this value is set to zero. The RGB Capacity field (2 bytes) specifies the number of resolution bits that can be displayed in the RGB format. If the deployment can not use the RGB format, then this value is equal to zero. The word RGB Capacity is composed of three separate unsigned values where: Bit 3 to 0 define the maximum number of blue bits, Bit 7 to 4 define the maximum number of green bits, and Bit 11 to 8 define the maximum number of red bits in each pixel. Currently, Bits 14 through 12 are reserved for future use and are generally set to zero. Bit 14 through 12 are reserved for future use and are generally set to zero. Bit 15 when set to one indicates that the client can accept the RGB pixel data in either the packaged or unpacked format. If bit 15 is set to a logical-zero level, this indicates that the client can accept the RGB pixel data only in the unpacked format. The Capacity field And Cr Cb (2 bytes) specifies the number of resolution bits that can be displayed in the Y Cr Cb format. If the deployment can not use the Y Cr Cb format then this value is set equal to zero. The word Capacity Y Cr Cb is composed of three separate unsigned values where: Bit 3 to 0 define the maximum number of bits in the sample Cb, bits 7 to 4 define the maximum number of bits in the sample Cr, the Bit 11 through 8 define the maximum number of bits in sample Y, and bits 15 through 12 are currently reserved for future use and are set to zero. The Client's Capability Capacity field uses 4 bytes that contain a set of indicators that indicate specific characteristics in the client that are supported. A bit that is set to one indicates that the capacity is supported, and a bit that is set to zero indicates that the capacity is not supported. In one mode, the value for Bit 0 indicates whether the Bitmap Block Transfer Package is supported or not. (package type 71). The value for Bit 1, 2 and 3 indicates whether or not the Map Area's Area Fill Packet is supported.

Bits (type 72 package), the Bitmap Pattern Filling Package (type 73 package), or a Communication Link Data Channel Package (type 74 package), respectively. The value for Bit 4 indicates whether or not the client has the ability to make a transparent color using the Enable Transparent Color Package, while bits from Bit 5 to 6 indicate whether the client can accept Video data or audio data in the packaged format, respectively, and the value for Bit 7 indicates whether the client can send a reverse link Video stream from a camera or not. The value for Bit 8 indicates whether or not the client has the ability to receive a complete line of pixel data and ignore the routing of the deployment as specified by bit 5 of the Pixel Data Attributes field of the Current Packet of Video, and the client can also detect the frame synchronization or the completion of the Video frame data using bit 15 of the Pixel Data Attributes field. The value for Bits 11 and 12 indicates when the client is communicating with either a pointing device and can send and receive Data Packs from the Pointing Device, or when with a keyboard and can send and receive Keypad Data Packet , respectively. The value for Bit 13 indicates whether or not the client has the ability to set one or more audio or video parameters by supporting the VCP Characteristics packets: The Request VCP Feature Pack, VCP Feature Response Pack, Set VCP Characteristics Package, Valid Application Parameter Package and Valid Parameter Response Package. The value for 'Bit 14 indicates whether or not the client has the ability to write pixel data within the buffer of the offline deployment frame. If this bit is set to a logical-one level then the Deployment Update Bits (bits 7 and 6 of the Pixel Data Attributes field of the Video Stream Package) can be set to the '01' values. The value for Bit 15 indicates when the client has the ability to write pixel data within only the buffer of the deployment frame that is currently being used to refresh the deployment image. If this bit is set to one then the update update bits (bits 7 and 6 of the Pixel Data Attributes field of the Video Stream Package) can be set to the '00' values. The value for Bit 16 indicates when the client has the ability to write pixel data from a single Video Stream Package within all the buffers in the deployment frame. If this bit is set to one, then the Deployment Update Bits (bits 7 and 6 of the Pixel Data Attributes field of the Video Stream Package) can be set to the value "11". The value for Bit 17 indicates when a client has the ability to respond to the Request Specific Status Pack, the value for Bit 18 indicates when the customer has the ability to respond to the Round Trip Delay Measurement Package, the value for Bit 19 indicates when the client has the capacity for the No Return Pairing Bias Calibration Package. The value for Bit 21 indicates when the client has the ability to interpret the Request Specific Status Pack and respond with the Valid State Response List Package. The client indicates a capability to return the additional status in the Valid Parameter Response List field of the Valid State Response List Package as described elsewhere. The value for Bit 22 indicates whether or not the client has the capacity to respond to the Registry Access Package. Bits 9 through 10 and 23 through 31 are currently reserved for future use or alternative useful designations for system designers and are generally set equal to zero. The Capacity field of the Video Frame Rate in Deployment (1 byte) specifies the ability to update the maximum video frame of the display in frames per second. A host may choose to update the image at a slower speed than the value specified in this field. The Depth of Memory-Intermediate Audio field (2 bytes) specifies the depth of the elastic buffer in a Deployment that is dedicated to each audio stream.

The Audio Channel Capacity field (2 bytes) contains a group of indicators that indicate which audio channels are supported by the client or the device connected to the client. A bit set to one indicates that the channel is supported, and a bit set to zero indicates that the channel is not supported. Bit positions are assigned to different channels, for example the positions of Bit 0, 1, 2, 3, 4, 5, 6, and 7 in one mode, which indicate the front left, front right, left rear, back channels right, front center, subwoofer, surround left and surround right, respectively. Bits 8 through 14 are currently reserved for use in the future, and are generally set to zero. In one mode, Bit 15 is used to indicate whether the client provides support for the Audio Return Enabled Package. If this is the case, Bit 15 is set to a one-logical level. However, if the client is not able to disable the audio channels as a result of the No Return Audio Channel Enablement Package or if the client does not support any audio capability, then this bit is set to a level or value of zero -logical. A 2-byte Audio Sample Rate capability field, for the non-return link, contains a set of indicators to indicate the speed capability of the audio sample of the client device. Bit positions are assigned for different speeds consequently, such as Bits 0, 1, 2, 3, 4, 5, 6, 7 and 8 that are 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, with Bits 9 through 15 that are reserved for future uses or alternative speeds, as desired, so they are currently set to '0'. Setting a bit value for one of those bits to '1' indicates that that particular sample rate is supported, and setting the "0" bit indicates that that sample rate is not supported. The Minimum Sub-frame Rate field (2 bytes) specifies the minimum sub-frame rate in frames per second. The minimum sub-frame rate maintains the refresh rate of the client's state enough to read certain sensors or pointing devices in the client. A 2-byte Mic Sample Rate Capability field, for the return link, contains a set of indicators indicating the speed capability of the audio sample of a microphone in the client device. For purposes of the MDDI, a microphone of the client device is configured to minimally support at least a speed of 8,000 samples per second. The Bit positions for this field are assigned for different speeds with Bit positions of 0, 1, 2, 3, 4, 5, 6, 7, and 8, for example, which are used to represent 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050 and 44,100 samples per second (SPS), respectively, with Bits 9 through 15 that are reserved for future uses or alternative speed, as desired, so they can currently be set to '0' . Setting a bit value for one of those bits? L 'indicates that that particular sample rate is supported, and setting the bit to' 0 'indicates that that sample rate is not supported. If no microphone is connected then each of the bits of the Mic Sample Rate Capacity is set equal to zero. The field of Keyboard Data Format (which is 1 byte here) is specific if the keyboard is connected or not to the customer's system and the type of keyboard that is connected. In one mode, the value set by Bits 6 through 0 is used to define the type of keyboard that is connected. If the value is zero (0) then the keyboard type is considered as unknown. For a value of 1, the format of the keyboard data is considered to be of a standard PS-2 style. Values currently in the range of 2 to 125 are not used, are reserved for use by the system designers and interface incorporators or product developers to define the specific keyboard or input devices for use with the MDD interface and the corresponding clients or hosts. A value of 126 is used to indicate that the keyboard data format is defined by the user, while a value of 127 is used to indicate that a keyboard can not connect to this client. In addition, Bit 7 can be used to indicate whether or not the keyboard can communicate with the client. The intended use of this bit is to indicate when the keyboard can communicate with the client using a wireless link. Bit 7 would be set to a zero level if bits 6 through 0 indicate that a keyboard can not connect to the client. Therefore, for a modality, when the value of Bit 7 is 0, the keyboard and the client can not communicate, whereas if the value of Bit 7 is 1, the keyboard and client have recognized that they can communicate with each other. The field of Data Format of the Signaling Device (which is 1 byte here) is specific if the signaling device is connected or not with the customer's system and the type of signaling device that is connected. In one mode, the value set by Bits 6 through 0 is used to define the type of signaling device that is connected. If the value is zero (0) then the type of signaling device is considered as unknown. For a value of 1, the data format of the pointing device is considered to be of a standard PS-2 • style. Current values in the range of 2 to 125 are not used, they are reserved for use by the system designers and the interface incorporators or the product developers to define the specific signaling device or the input devices for use with the MDD interface and the corresponding clients or hosts. A value of 126 is used to indicate that the data format of the pointing device is defined by the user, while a value of 127 is used to indicate that a pointing device can not connect to this client. In addition, Bit 7 can be used to indicate whether or not the signaling device can communicate with the client. The intended use of this bit is to indicate when the keyboard can communicate with the client using a wireless link. Bit 7 would be set to a level of zero if bits 6 through 0 indicate that a pointing device can not connect to the client. Therefore, for a modality, when the value of Bit 7 is 0, the pointing device and the client can not communicate, whereas if the value of Bit 7 is 1, the pointing device and the client have recognized that they can communicate with each other The Content Protection Type field (2 bytes) contains a set of indicators that indicate the type of protection of the digital content that is supported by Deployment. Currently, the position of bit 0 is used to indicate when the DTCP is supported and the position of bit 1 is used to indicate when the HDCP is supported with bit positions 2 to 15 being reserved for use with other protection schemes as desired or are available, so they are currently set to zero. Manufacturer's Name - 2 bytes that form a 16-bit value that contains the ID of character 3 EISA (Extended Industrial Standard Architecture) of the manufacturer, packaged in 3 5-bit characters in the same way as the VESA EDID specification. The character 'A' is represented as a binary 00001, the character 'Z' is represented as binary 11010, and all the letters between 'A' and 'Z' are represented as sequential binary values corresponding to the alphabetical sequence between 'A ' and Z' . The most important bit of The Manufacturer's Name field is not used and is generally set to logical zero for now until it is used in future implementations. For example: a manufacturer represented by the character string 'XYZ' should have a value other than the Manufacturer's Name of 0x633a. If this field is not supported by the client it must be set to zero. Product Code - 2 bytes that contain a product code assigned by the manufacturer of the deployment. If this field is not supported by the client it must be at zero. The fields Reserved 1, Reserved 2 and Reserved 3 (here of 2 bytes each) are reserved for a future use in the imparting of information. All bits in this field are usually set-at a logical zero level. The purpose of this field is to cause all subsequent 2-byte fields to be aligned with a 16-bit word address and cause the 4-byte fields to be aligned with a 32-bit word address. The Serial Number field uses 4 bytes in this mode that specify the serial number of the display in numerical form. If this field is not supported by the client, it is generally set to zero. The Manufacturing Week field uses 1 byte that defines the manufacturing week of the deployment. This value must be in the range of 1 to 53 if it is supported by the client. If this field is not supported by the client it must be at zero. The Year of Manufacture field is 1 byte that defines the year of manufacture of the deployment. This value is a range from the year 1990. The years in the range from 1991 to 2245 can be expressed by this field. Example: the year 2003 corresponds to a value of the Year of Manufacture of 13. If this field is not supported by the client it must be at zero. The CRC field (here 2 bytes) contains a CRC of 16 bits of all bytes in the package that includes the Package Length.

G. For Client Status and Request Packs The Return Link Request field (3 bytes) specifies the number of bytes that the client needs in the return link in the next sub-frame to send the information to the host. The CRC Error Count field (1 byte) indicates how many CRC errors have occurred since the start of the media frame. The CRC count is reset when a packet of the sub-frame header with a Sub-frame Undo of zero is sent. If the current number of CRC errors exceeds 255 then this. value is usually saturated at 255. The Capacity Change field uses 1 byte to indicate a change in the client's capacity. This could happen if a user connects a peripheral device such as a microphone, key or display, or for some other reason. When the Bits [7: 0] are equal to 0, then the capacity has not changed since the last Client Capacity Package was sent. However, when the Bits [7: 0] are equal to 1 to 255, the capacity has changed. The Client Capacity Package is examined to determine the new features of the deployment. The Busy Customer Flags field uses two bytes to indicate that the client is executing a specific function and that it is not ready to accept yet another package related to that function. A bit set to a level or logical value indicates that the particular function is currently being performed by the client and that the related function in the client is busy. If the function in the client is ready, the bit is set to a logical zero. The client should return a busy state (bit set to one) for all functions that are not supported by the client. In a modality, those bytes are interpreted according to the relation: if Bit 0 is a '1' then the transfer function of the bitmap block is occupied, whereas if Bit 2 is a Y ', then the fill function of the bitmap pattern is busy. Currently, Bits 3 through 15 remain reserved for future use and are generally set to a logical zero level or state to indicate a busy state in case these bits are assigned in the future.

H. For Bits Block Transfer Packs The X Value and Y Value fields of the Upper Left Coordinate of the Window use 2 bytes each to specify the X and Y value of the coordinates of the upper left corner of the window which is going to move. The Window Width and Height fields use 2 bytes each to specify the width and height of the window to be moved. The fields of Motion X and Motion Y of the Window use 2 bytes each to specify the number of pixels that the window will move horizontally and vertically, respectively. Typically, those coordinates are set so that positive values for X cause the window to move to the right, and negative values cause its movement to the left, while positive values for Y cause the window to move down and the negative values cause their upward movement.

I. For Batch Map Area Fill Packets The X Value and Y Value fields of the Upper Left Coordinate of the Window use 2 bytes each to specify the X and Y value of the coordinates of the upper left corner of the the window to fill in The fields of Width and Height of Window (2 bytes each) specify the width and height of the window to be filled. The Descriptor field of the Video Data Format (2 bytes) specifies the format of the Fill Value of the Pixel Area. The format is the same as the same field in the Video Stream Package. The field of the Fill Value of the Pixel Area (4 bytes) contains the pixel value to be filled within the specified window by means of the fields discussed above. The format of this pixel is specified in the Descriptor field of the Video Data Format.

J. For Binary Map Pattern Filling Packets The X Value and Y Value fields of the Upper Left Coordinate of the Window use 2 bytes each to specify the X and Y values of the coordinates of the upper left corner of the the window to be filled. The fields of Width and Height of Window (2 bytes each) specify the width and height of the window to be filled. The Width Pattern and High Pattern fields (2 bytes each) specify the width and height, respectively, of the fill pattern. The Pattern Horizontal Offset field (2 bytes) specifies a horizontal offset of the pixel data pattern of the left edge of the specific window to be filled. The value that is specified is going to be less than the value in the Pattern Width Field. The Vertical Offset Pattern field (2 bytes) specifies a vertical offset of the pixel data pattern from the top edge of the specific window to be filled. The value that is specified is going to be less than the value in the Pattern Height field. The Descriptor field of the 2-Byte Video Data Format specifies the format of the Fill-in Value of the Pixel Area. FIGURE HA A HE illustrates how the Video Data Format Descriptor is encoded. The format is the same as the same field in the Video Stream Package. The CRC Parameter field (2 bytes) contains a CRC of all bytes of the Packet Length of the Video Format Descriptor. If this CRC fails to verify, then the entire packet is discarded. The Pattern Pixel Data field contains raw video information that specifies the fill pattern in the format specified by the Video Data Format Descriptor. The data is packed in bytes, and the first pixel of each row is to be aligned by bytes. The fill pattern data is transmitted one row at a time. The CRC field of the Pattern Pixel Data (2 bytes) contains a CRC of only the Pixel Data of the Pattern. If these CRCs fail to verify, then the Pattern Pixel Data can still be used even though the CRC error count is increased.

K. Packages of the Link Data Channel Communication The CRC Parameter field (2 bytes) contains a 16-bit CRC of all bytes of the Package Length for the Package Type. If this CRC fails to verify, then the entire packet is discarded. The Data field of the Communication Link contains the raw data of the communication channel.

These data are simply passed in the computing device in the deployment. The CRC field of the Communication Link Data (2 bytes) contains a 16-bit CRC of only the Communication Link Data. If this CRC fails to verify, then the Communication Link Data can still be used or is useful, but the CRC error count is increased.

L. For Intracellular Transfer Request Packs Type Interface The Interface Type field (1 byte) specifies the new type of interface to be used. The value in this field specifies the type of interface in the following way. If the value in Bit 7 is equal to '0' the intracellular Transfer Type request is for the non-return link, if it is equal to '1', then the intracellular Transfer Type request is for the return link. Bits 6 through 3 are reserved for future use, and are generally set to zero. Bits 2 through 0 are used to define the Type of Interface to be used, with a value of 1 which means an intracellular transfer of a Type 1 mode, a value of 2 in an intracellular transfer of a Type 2 mode, a value of 3 in an intracellular transfer of a Type 3 mode, and a value of 4 in an intracellular transfer of a Type 4 mode. The values of? 0 'and 5 to 7 are reserved for a future designation of modes or combinations of modes alternative M. For Interface Type Recognition Packs The Interface Type field (1 byte) has a value that confirms the new type of interface to be used. The value in this field specifies the type of interface in the following way. If Bit 7 is equal to '0' the intracellular Transfer Type request is for the non-return link, alternatively, if it is equal to '1' the intracellular Transfer Type request is for the return link. The positions of Bits 6 to 3 are currently reserved for use in the design of other types of intracellular transfer, as desired, and are generally set to zero. However, bit positions 2 through 0 are used to define the type of interface to be used with a value of '0' indicating a negative acknowledgment, or that the requested intracell transfer can not carry out, the values of? l ',? 2',? 3 'and Y' indicate an intracellular transfer for Type 1, Type 2, Type 3 and Type 4 modes, respectively. Values 5 through 7 are reserved for use with alternative mode designations, as desired.

N. For Performance-Type Intracellular Transfer Packs The 1-byte Interface Type field indicates the new type of interface to be used. The value present in this field specifies the type of interface by first using the value of Bit 7 to determine whether or not the intracellular transfer type is for non-return or return links. A value of '0' indicates that the intracellular Transfer Type request is for the non-return link, and the value of? L 'for the return link. Bits 6 through 13 are reserved for future use, and these are generally set to a value of zero. However, Bits 2 through 0 are used to define the Type of Interface to be used, with values 1, 2, 3, and 4 specifying the use of intracell transfer for Type 1, Type 2, Type 3 and Type 4, respectively. The use of values 0 and 5 to 7 for those bits is reserved for future use.

O. For Packages that Enable the Audio Channel No Return The Mask field that enables the Channel Audio (1 byte) contains a group of indicators that indicate which audio channels are going to be enabled on a client. A bit that sets in one enables the corresponding channel, and a bit that is set to zero disables the corresponding channel. Bits 0 to 5 designate channels 0 through 5 that address the left front, right front, left rear, right rear, front center, subwoofer, surround left and right surround channels, respectively. Bits 6 and 7 are reserved for future use, and meanwhile they are generally set equal to zero.

P. Audio Sample Speed Package Return The Speed field of the Audio Sample (1 byte) specifies the speed of the digital audio sample. The values for this field are assigned for different speeds with values of 0, 1, 2, 3, 4, 5, 6, 7 and 8 which are used to designate 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050 and 44,100 samples per second (SPS), respectively, with values from 9 to 254 that are reserved for use with alternative speeds, as desired, so they are currently set to '0'. A value of 255 is used to disable the audio stream of the return link. The Sample Format field (1 byte) specifies the format of the digital audio samples. When the 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 alternating their use in the designation of audio formats, as desired, and are generally set equal to zero.

Q. For Auxiliary Operations Packs for Digital Content Protection The Content Protection Type (1 byte) field specifies the digital content protection method that is used. A value of '0' indicates a Digital Transmission Content Protection (DTCP) while a value of 1 indicates a Digital Content Protection System of High Bandwidth (HDCP). The value range is from 2 to 255 and is not currently specified although it is reserved for use with alternative protection schemes, as desired. The Auxiliary Operations Message field for Content Protection is a variable length field that contains content protection messages that are sent between the host and the client.

A. For Transparent Color Enable Packages The Transparent Color Enable (1 byte) field when the transparent color mode is enabled or disabled. If Bit 0 is equal to 0, then the transparent color mode is disabled, if it is 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 Descriptor field of the Video Data Format (2 bytes) specifies the format of the Fill Value of the Pixel Area. FIGURE HA A HE illustrates how the Video Data Format Descriptor is encoded. The format is generally the same as that of the same field in the Video Stream Package. The Fill Value field of the Pixel Area uses 4 bytes destined for the pixel value to be filled within the previously specified window. The format of this pixel is specified in the Descriptor field of the Video Format.

S. For Round Trip Delay Packet The 2 byte Packet Length field specifies the total number of bytes in the packet that do not include the Packet Length field, and in one mode, it is selected to have a length fixed of 159. The 2-Byte Package Type field that identifies this type of packet with a value of 82, identifying a packet as a Round Trip Delay Measurement Package. The Customer's ID field, as previously reserved for future use as a Customer ID, is generally set to zero. In one mode, the CRC Parameter field (2 bytes) contains a 16-bit CRC of all bytes of the Package Length for the Package Type. If this CRC fails to verify, then the entire packet is discarded. The Guard Time 1 field (which is 64 bytes here) is used to allow the MDDI_Data online handlers on the client to be enabled before the online handlers on the host are disabled. The client enables its MDDI_Data online handlers during bit 0 of Guard Time 1 and the host disables the online handlers so that they are completely disabled prior to the last bit of Guard Time 1. The host and the client have both a zero-logical level during Guard Time 1 when they are not disabled. Another purpose of this field is to ensure that all MDDI_Data signals are at a logical-zero level for a sufficient time to allow the client to initiate recovery to measure the time or signal to measure the time that MDDI_Stb uses prior to disabling the Online host management. The Measurement Period field is a 64-byte window used to allow the client to respond with two bytes of Oxff, and 30 bytes of 0x0 at half the data rate used in the non-return link. This data rate corresponds to a Divider of the Return Link Speed of 1. The client returns this response immediately at the time it is received. as if you were starting the Measurement Period. This response from the client will be received in a host precisely in the round trip delay of the link plus the logical delay in the client after the start of the first bit of the Measurement Period in the host. The All-Zero 1 (2 bytes) field contains the zeros that allow the MDDI_Data in-line handlers on the host and the client to overlap so that MDDI_Data is always on. The host enables MDDI_Data online handlers during bit 0 of Guard Time 2, and the client also triggers the signal at a zero-logical level as it did at the end of the Measurement Period.

The value in the Guard Time 2 field (64 bytes) allows you to superimpose the Measurement Period triggered by the client when the round trip delay is in the maximum amount that can be measured in the Measurement Period. The Client disables its online handlers during bit 0 of Guard Time 2 and the Host enables its handlers in line immediately after the last bit of Guard Time 2. The host and the client both operate a level of logical-zero during Guard 2 time when they are not disabled. Another purpose of this field is to ensure that all MDDI_Data signals are at a logical-zero level for a sufficient time to allow the client to start retrieving a time-to-time signal using both MDDI_Data0 and MDDI_Stb after enabling online handlers for a host.

T. For the Bind Calibration Packs of the Return Without Return In a modality, the CRC Parameter field (2 bytes) contains a 16-bit CRC for all bytes of the Package Length for the Package Type. If this CRC fails to verify them then the entire package is discarded. The All-in-Zero field uses a byte to ensure that there will be transitions in the MDDI_Stb at the end of the CRC field. The Sequence field of the Calibration Data contains a data sequence of 512 bytes that causes the MDDI_Data signals to switch in all data periods. The length of the Calibration Data Sequence field is determined by the interface that is being used in the non-return link. During the processing of the Calibration Data Sequence, the MDDI host controller sets all MDDI_Data signals equal to the strobe signal. The recovery circuit of measuring the client's time should only be used in MDDI_Stb more than in MDDI_Stb X or MDDI_DataO to recover the measurement of data time while the Sequence field of the Calibration Data is being received through the Customer Display . Depending on the exact phase of the MDDI_Stb signal at the start of the Sequence field of the Calibration Data, the Sequence of the Calibration Data will generally be one of the following based on the Type of interface being used when this packet is sent : Type I- (data sequence of 64 bytes) Oxaa, Oxaa ... or 0x55,0x55 ... Type II- (data sequence of 128 bytes) Oxee, Oxee ... or 0x33, 0x33 ... Type III- (data sequence of 256 bytes) OxfO, OxfO ... or OxOf, OxOf ... Type IV- (data sequence of 512 bytes) Oxff, 0x00, Oxff, 0x00. .. or 0x00, Oxff, 0x00, Oxff ... An example of the possible waveforms of MDDI_Data and MDDI_Stb for both Type 1 and Type 2 Interfaces is shown in FIGURES 62A and 62B, respectively.

XVII. Conclusion Although various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not of limitation. Thus, the breadth and scope of the present invention should not be limited to any of the exemplary embodiments described above, but should be defined only in accordance with the following claims and their equivalents.

Claims (70)

1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and therefore the property described in the following claims is claimed as property. CLAIMS 1. A digital data interface for transferring data from a digital presentation at a high speed between a host device and a client device through a communication path characterized in that it comprises: a plurality of package structures linked together to form a communication protocol for communicating a pre-selected set of digital control and presentation data between a host and a client through the communication path; and at least one link controller residing in the host device coupled to the client through the communication path, which is configured to generate, transmit or receive packets that form the communications protocol, and to form the presentation data digital in one or more types of data packets.
2. 2. The interface according to claim 1, further characterized in that it comprises the packages grouped together within the frame of means communicating between the host and the client that have a pre-defined fixed length with a pre-determined number of packets. that have different and variable lengths.
3. 3. The interface according to claim 1, further characterized in that it comprises a Sub-frame Header Pack placed at the beginning of the host packet transfers. The interface according to claim 1, characterized in that the link controller is a host link controller and further comprises at least one client link controller residing on the client device coupled to the host through the path of communications, which is configured to generate, transmit and receive packets that form the communications protocol, and to form data of a digital presentation in one or more types of data packets. The interface according to claim 1, further characterized in that it comprises one or more Video Stream Packs for video type data, and Audio Stream Packs for audio types data to transfer data from the host to the client to through a non-return link for presentation to a client user. The interface according to claim 2, further characterized in that it comprises: a plurality of transfer modes, each allowing the transfer of different maximum bit numbers of the data in parallel through a given period of time, with each so that it can be selected by negotiation between the host and client link managers; and where the transfer modes can be dynamically adjusted between modes during data transfer. The interface according to claim 1, further characterized in that it comprises a plurality of packets that can be used to transfer selected video information from a Color Map group, Bit Block Transfer, Bit Map Area Fill, Fill the Bitmap Pattern, and packets Enable Transparent Color. 8. The interface according to claim 1, further characterized in that it comprises filler packets generated by the host to occupy periods of the transmission of the non-return link that do not have data. 9. The interface according to claim 1, further characterized in that it comprises packets type Current Defined by the User to transfer data defined by the user interface. The interface according to claim 1, further characterized in that it comprises a link-closure type packet for transmission from the host to the client to terminate the data transfer in any direction through the communication path. 11. The interface according to claim 1, characterized in that it comprises means for the client to awaken the host from the hibernation state. 12. A method for transferring digital data at a high speed between a host device and a client device through a communication path for presentation to a user, characterized in that it comprises: generating one or more structures of a plurality of packets predefined and link them together to form a predefined communication protocol; communicating a preselected set of digital display and control data between the host and client devices through the communication path using the communication protocol; coupling at least one host link controller residing in the host device for the client device through the communication path, the host link controller is configured to generate, transmit and receive packets that form the communications protocol , and to form data from a digital presentation within one or more types of data packets; and transfer the data in the form of packets through the communication path using the link controllers. The method according to claim 12, further characterized in that it comprises grouping the packets together within the media frames for communication between the host and the client, the media frames have a predefined fixed length with a predetermined number of packets that have different and variable lengths. The method according to claim 12, further characterized in that it comprises starting the transfer of packets from the host with a packet type Sub-frame header. 15. The method according to claim 12, further characterized in that it comprises transferring information between the host and the client bi-directionally through the communication link. The method according to claim 12, further characterized in that it comprises at least one client link controller residing in the client device coupled to the host device through the communication path, which is configured to generate, transmit and receiving packets that form the communications protocol, and to form data from a digital presentation within one or more types of data packets. 17. The method according to claim 16, characterized in that it comprises the host link controller comprising one or more differential line handlers; and the client link controller comprises one or more differential in-line receivers coupled to the communication path. 18. The method according to claim 12, further characterized in that it comprises requesting information from the client's deployment functions by means of a host link controller so that it is determined what type of data and data rates the client is capable of adjusting. through the interface.19. The method according to claim 12, further characterized in that it comprises operating a USB data interface through each of the link controllers as part of the communication path. The method according to claim 12, characterized in that it comprises the packets each comprising a packet length field, one or more packet data fields, and a cyclic redundancy check field. 21. The method according to claim 13, further characterized in that it comprises: negotiating between the host and client link handlers, the use of a plurality of transfer modes in each direction, each allowing the transfer of numbers of different maximum bits of data in parallel through a given period of time; and dynamically adjust between transfer modes during data transfer. The method according to claim 12, further characterized in that it comprises using one or more of a plurality of packets to transfer selected video information from a Color Map group, Bit Block Transfer, Map Area fill, Bits, Bitmap Pattern Filling and Transparent Color type packages. 23. The method according to claim 12, further characterized in that it comprises generating packets type Filler by the host to occupy the transmission periods of the non-return link that do not have data. The method according to claim 12, further characterized in that it comprises terminating the data transfer in any direction through the communication path using a Link Closure type packet for transmission by the host to the client. 25. The method according to claim 12, further characterized in that it comprises waking the host from a hibernation state by communicating with the client. 26. An apparatus for transferring digital data at a high speed between a host device and a client device through a communication path for presentation to a user, characterized in that it comprises: at least one host link controller disposed in the host host device for generating one or more of a plurality of predefined package structures and linking them together to form a predefined communication protocol, and for communicating the preselected set of digital control and presentation data between the host and client devices through the communication path using the communication protocol; at least one client controller disposed on the client device and coupled to the host link controller through the communication path; and each link controller is configured to generate, transmit and receive packets that form the communications protocol, and to form data of a digital presentation within one or more types of packets. 27. The apparatus according to claim 26, characterized in that the host controller comprises a state machine. 28. The apparatus according to claim 26, characterized in that the host controller comprises a signal processor of general application. 29. The apparatus according to claim 26, further characterized by comprising a subframe Header type packet at the beginning of packet transfer from the host. 30. The apparatus according to claim 26, characterized in that the link controllers are configured to transfer information between the host and client devices bi-directionally through the communication link. 31. The apparatus according to claim 30, characterized in that it comprises the host controller comprising one or more differential on-line handlers.; and the client receiver comprises one or more differential in-line receivers coupled to the communication path. 32. The apparatus according to claim 26, further characterized by comprising Video Stream type packets for video type data, and Audio Stream type packets for audio type when data is transferred from the host to the client for presentation to the client. user of the client. 33. The apparatus according to claim 26, further characterized in that it comprises one or more packets of Return Link Encapsulation to transfer data from the client to the host. The apparatus according to claim 33, further characterized in that it comprises at least one Deployment Capability type packet for communicating the functions of the display or presentation from a client link controller to the host link controller. 35. The apparatus according to claim 26, characterized in that it comprises the packets each comprising a Packet Length field, one or more packet data fields, and a cyclic redundancy check field. 36. The apparatus according to claim 26, characterized in that the host and client link controllers are configured to use one of a plurality of transfer modes in each direction, each allowing the transfer of a different maximum number of bits. of data in parallel through a certain period of time; and that it is capable of dynamically adjusting between transfer modes during data transfer. 37. The apparatus according to claim 26, further characterized in that it comprises one or more of a plurality of packets for transferring selected video information from Color Map group, Bit Block Transfer, Bit Map Area Filling, Filling the Bitmap Pattern, and Transparent Color type packages. 38. The apparatus according to claim 26, further characterized in that it comprises filler-type packets to be transferred by the host to occupy non-return link transmission periods that do not have data. 39. The apparatus according to claim 26, characterized in that the host controller is configured to transmit a Link Closure type packet to the client means to complete the data transfer in any direction through the communication path. 40. A computer program product for use in an electronic system for transferring digital data at a high speed between a host device and a client device through a communication path for presentation to a user, characterized in that it comprises: a computer-usable medium having a means of readable program code on the computer contained in the medium to cause an application program to run on the computer system, a means of computer readable program code comprising: a means code of a first computer readable program to cause the computer system to generate one or more of a plurality of predefined package structures and link them together to form a predefined communication protocol; a second means of computer readable program code to cause the computer system to communicate a preselected set of digital control and presentation data between the host and client devices through the communication path using the communication protocol; a third means of computer readable program code to cause the computer system to be coupled with at least one client controller disposed on the client device through the communications path, the link controllers are configured to generate, transmit and receive packets that form the communications protocol, and to form data of a digital presentation within one or more types of data packets; and a fourth means of computer readable program code to cause the computer system to transfer data in packet form through the communication path using the link controllers. 41. An apparatus for transferring digital data at a high speed between a host device and a client device through a communication path for presentation to a user, characterized in that it comprises: means for generating one or more of a plurality of predefined package structures and link them together to form a predefined communication protocol; means for communicating a preselected set of digital control and presentation data between the host and client devices through the communication path using the communication protocol; means for coupling at least two link controllers together through the communication path, one in each host and client and each is configured to generate, transmit and receive packets that form the communications protocol, and to form data from a digital presentation in one or more types of data packets; and the means for transferring the data in the form of packets through the communication path using the link controllers. 42. The apparatus according to claim 41, further characterized in that it comprises means for connecting the packet transfer of the host with a packet type Sub-frame header. 43. The apparatus according to claim 41, further characterized in that it comprises means for transferring information between the host and the client bi-directionally through the communication link. Four . The apparatus according to claim 41, further characterized in that it comprises means for requesting information from client deployment functions by means of a host link controller so that it is determined what type of data at the data rates the client is capable of adjusting through the interface. 45. The apparatus according to claim 44, further characterized in that it comprises means for communicating display or display functions of a client link controller to the host link controller using at least one Deployment Capacity type packet. 46. The apparatus according to claim 42, further characterized in that it comprises: means for negotiating between the handlers of the host and the client the use of one of a plurality of transfer modes in each direction, each allowing the transfer of different maximum bit numbers of data in parallel through a given period of time; and the means for dynamically adjusting the transfer modes during data transfer. 47. The apparatus according to claim 41, further characterized in that it comprises means for using one or more of a plurality of packets to transfer selected video information from the Color Map group, Bit Block Transfer, Map Area Filling. of Bits, Filling the Bitmap Pattern, transparent Enable type color packages. 48. A processor for use in an electronic system for transferring digital data at a high speed between a host device and a client device through a communication path, the processor is configured to generate one or more of a plurality of structure of predefined packages and link them together to form a predefined communication protocol; form data of a digital presentation in one or more types of data packages; communicating a preselected set of digital control and presentation data between the host and client devices through the communication path using the communication protocol; and transfer the data in the form of packets through the communication path. 49. A state machine to use it in obtaining synchronization in the digital data of a transfer of an electronic system at a high speed between a host device and a client device through a communication path, the state machine is configured to have at least one Asynchronous Frame State synchronization state, at least two Synchronized Acquisition States synchronization states, and at least three synchronization states of Synchronized States. 50. A state machine to be used in obtaining synchronization of digital data from a transfer of an electronic system at a high speed between a host device and a client device through a communication path, the state is configured to have at least synchronization states of Synchronous Acquisition States and at least two synchronization states of States In Synchronization. 51. The state machine according to claim 50, characterized in that a condition for moving between a Synchronous Acquisition State and a first State In Synchronization is detected the presence of a synchronization pattern in the communication link. 52. The state machine according to claim 51, characterized in that a second condition for moving between a Synchronous Acquisition State and a first Synchronized State is detected from a packet of the sub-frame header and a good CRC value in a frame limit. 53. The state machine according to claim 50, characterized in that a condition for moving between a first state in synchrony and a state of synchronous acquisition is detected the presence of any synchronization pattern or a bad CRC value in a limit of sub-frame 54. The state machine according to claim 50, characterized in that a condition for moving between a first State In Sync and a second State In Sync is to detect the presence of any synchronization pattern or a bad CRC value within a limit of sub-frame 55. The state machine according to claim 50, characterized in that a condition for moving between a Synchronous Acquisition State and a first Synchronized State is to detect the presence of a synchronization pattern in the communication link is to detect the presence of a good package CRC value. 56. The state machine according to claim 50, characterized in that a condition for moving between a first State In Synchrony and a Synchronous Acquisition State is to detect the presence of a bad CRC value in a packet. 57. A state machine to be used in obtaining synchronization in the digital data of a transfer of an electronic system at a high speed between a host device and a client device through a communication path, the state is configured to have at least one of the synchronization status of Synchronous Acquisition Status, and at least two Synchronization States of States In Synchronization where a condition to move directly between a first State In Synchronization and a Synchronous Acquisition State is detect the presence of a bad CRC value in any of the packet series. 58. The state machine according to claim 57, characterized in that a condition for moving directly between a first state in synchrony and a state of synchronous acquisition is to detect when the unique word does not occur at a time that was expected to arrive. 59. The method according to claim 26, further characterized in that it comprises arousing a communication link by driving a data line for a high state for at least 10 cycles of timing and initiating the transmission of a strobe signal as if the data line were zero, through the host. 60. The method according to claim 59, further characterized in that it comprises operating the low data line for 50 cycles of time measuring by the host while continuing to transmit a strobe signal after the host has operated the data line elevated during 150 cycles of measuring time. 61. The method according to claim 59, further characterized in that it comprises starting to transmit the first packet of the header of the sub-frame through the host. 62. The method according to claim 60, further characterized by comprising continuing at least 150 cycles of continuous time measurement of the data line which is high, followed by at least 50 continuous time measurement cycles of the data line. which is low, through the client. 63. The method according to claim 62, further characterized in that it comprises searching for the unique word of the first sub-frame of the client. 64. The method according to claim 60, further characterized in that it comprises stopping the actuation of the elevated data line by the client after the client counts 70 continuous time measuring cycles of the data that are high. 65. The method according to claim 64, further characterized by comprising continuing another 80 cycles of measuring the continuous time of the data line which is high to reach the 150 cycles of measuring the time of the data line elevated by the client. , and look for the 50 cycles of measuring the time of the data line that is low, and look for the single word. 66 The method according to claim 26, further characterized by comprising continuing the number of cycles of measuring the time that occur until one is sampled by the host, by sampling the data line at both the edges of ascending and descending during the return timing package. 67. A method for transferring error code in a communication system in which digital data is transferred in the form of packets having a CRC value between a host device and a client device through a communication path comprising detect the presence of an error, select a predetermined error code that corresponds to the error, and overwrite the CRC value with the code. 68. The method according to claim 67, further characterized in that it comprises overwriting the CRC value in successive packets that are transferred until the error is corrected. 69. A method for transmitting digital data at a high speed between a host device and a client device through a communication path for presentation to a user, characterized in that it comprises: generating one or more of a plurality of memory structures. predefined packages each include at least one CRC field, and link them together to form a predefined communication protocol; communicating a preselected set of digital control and presentation data between the host and client devices through the communication path using the communication protocol; coupling at least one link controller of the client residing in the host device to the client device through the communications path, the host link controller is configured to generate, transmit and receive packets that form the communications protocol, and to form data from a digital presentation in one or more types of data packets; transfer the data in the form of packets through the communication path using the link controllers; detect the presence of an error for the communication link; select a predetermined error code that corresponds to the error; and overwrite the CRC value with the code. 70. The method according to claim 69, further characterized in that it comprises overwriting the CRC value in successive packets that are transferred until the error is corrected.