JP2010213299A - 高速データレートインタフェース装置及び方法 - Google Patents

Abstract

【課題】デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するための通信プロトコルを形成するために、共にリンクされるパケット構造を使用して、通信経路上、ホストとクライアントの間でデジタルデータを転送するためのデータインタフェースを提供する。
【解決手段】信号プロトコルは、通信プロトコルを形成するパケットを生成、送信、及び受信し、デジタルデータを１つ又は複数のタイプのデータパケットに形成するように構成され、少なくとも１台が該ホストデバイスに常駐し、該通信経路を通して該クライアントに結合される、リンクコントローラによって使用される。インタフェースは、短距離「シリアル」タイプデータリンクでの、費用効果が高い、低電力の、双方向高速データ転送機構となる。
【選択図】図３

Description

（関連出願の相互参照）
本特許出願は、ともに本譲受人に委譲され、参照してここに明示的に組み込まれる、２００４年６月４日に出願された「切り替え可能閾値差動インタフェース（Ｓｗｉｔｈｃｈａｂｌｅ Ｔｈｒｅｓｈｏｌｄ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｉｎｔｅｒｆａｃｅ）」と題される特許仮出願第６０／５７７，５００号に対する優先権と、２００４年６月７日に出願された「切り替え可能閾値差動インタフェース（Ｓｗｉｔｈｃｈａｂｌｅ Ｔｈｒｅｓｈｏｌｄ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｉｎｔｅｒｆａｃｅ）」と題される特許仮出願第６０／５７７，７９３号に対する優先権とを主張する。

本開示中の本発明の実施形態は、ホストデバイスとクライアントデバイスの間で高速データレートで信号を通信する、あるいは転送するための統合回路及び１つ又は複数の電子素子を含むデジタル信号プロトコル、プロセス、方法ステップ、及び装置に関する。さらに具体的には、本開示は、内蔵デバイスアプリケーション及び外部デバイスアプリケーションを有する低電力高データレート転送機構を使用して、エンドユーザに対するプレゼンテーション又はディスプレイのためにホスト又はコントローラデバイスからクライアントデバイスにマルチメディア及び他の種類のデジタル信号を転送する技法に関する。

コンピュータ、電子ゲーム関連製品及び多様なビデオ技術（例えばＤＶＤ及び高解像度ＶＣＲ）は、いくつかの種類のテキストを含むときにもますます高解像度化する静止画像、ビデオ画像、ビデオオンデマンド画像、及びグラフィック画像をこのような装置のエンドユーザへのプレゼンテーションに備えるために過去数年間に著しく進歩した。同様に、これらの進歩により高解像度ビデオモニタ、ＨＤＴＶモニタ、又は特殊画像投影要素などのさらに高解像度の電子表示装置の使用を使用しなければならなくなった。ＣＤ型音響再生、ＤＶＤ、サラウンドサウンド、及び音声信号出力に関連する他の装置を使用するときなど、このような視覚映像を高解像度又は高品質音声データと組み合わせることは、エンドユーザのためによりリアリスティックなコンテンツリッチな、又は真のマルチメディア経験を作り出すために使用される。

加えて、ＭＰ３プレーヤなどのきわめて移動性の高品質サウンドシステム及びミュージックトランスポート機構がエンドユーザに対する音声専用プレゼンテーションのために開発された。これは、コンピュータからテレビ及び電話まで、現在、高品質つまり品質を誇る生産に慣れ、それを期待している市販の電子機器の典型的なユーザの期待を高める結果となった。更に、例えば電話又は映画館、及びスポーツフランチャイズ又は施設のようなコンテンツプロバイダからの画像のリアルタイムあるいは時間遅れ再生のために、様々なポータブルデバイス及び無線受信機が現在提案されている。

電子製品を必要とする典型的なビデオプレゼンテーションシナリオでは、ビデオデータは、通常、毎秒約１キロビットから１０キロビットである、よくても低速又は中速と呼べる速度で以前の技法を使用して転送される。次にこのデータは所望される表示装置上での遅れた（後の）再生のためにバッファに入れられるか、あるいは一時的な又は長期の記憶装置に記憶されるかのどちらかである。例えば、画像は画像をデジタルで表すのに有効なデータを受信又は送信するためにモデム又はインターネット接続装置を有するコンピュータに常駐するプログラムを使用するインターネット「全体で」又はインターネットを使用して転送されてよい。類似する転送は無線モデム又は無線パーソナルデータアシスタント（ＰＤＡ）又は無線電話を備えるポータブルコンピュータなどの無線装置を使用して行うことができる。

データはいったん受信されると、プレイバックのために内蔵記憶装置又は小型ハードディスク等の外部記憶装置を含むＲＡＭ又はフラッシュメモリなどのメモリエレメント、記憶回路又はメモリ素子に記憶される。データ量と画像解像度に応じて、プレイバックは相対的に迅速に開始するか、あるいはより長期間の遅延を伴なって提示される可能性がある。すなわち、いくつかの例では、画像プレゼンテーションは、多くのデータを必要としない、あるいは何らかのタイプのバッファリングを使用する非常に小さい又は低い解像度の画像にはある程度のリアルタイムプレイバックを可能にし、その結果より多くのデータが転送されている間に、少し遅延した後にいくらかのデータが提示される。転送リンクに中断がない、あるいは使用されている転送チャネルに関して他のシステム又はユーザからの干渉がないならば、いったんプレゼンテーションが開始すると、転送は表示装置のエンドユーザに適度にトラスペアレントである。結線されたインターネット接続のような単一の通信経路を複数のユーザが共用する場合、転送は割り込まれたり、所望されるより低速になる可能性がある。

静止画像又は動画ビデオのどちらかを作成するために使用されるデータは、通信リンク上でのデータの転送を加速するために、多くの場合、ジェイペグ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）（ＪＰＥＧ）、エムペグ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）（ＭＰＥＧ）、及びメディア業界、コンピュータ業界、及び他の通信業界の周知の規格組織又は企業によって指定される技法等のいくつかの周知の技法の１つを使用して圧縮される。これにより、既定量の情報を転送するためにより少ないビット数を使用してより速く画像又はデータの転送することが可能になる。

データがいったんメモリあるいは磁気記憶素子又は光学記憶素子などの保存メカニズムを有するコンピュータ又は他の受取人装置などの「ローカル」デバイスに転送されると、結果として生じる情報は解凍され（あるいは特殊な復号プレーヤを使用して再生され）、必要な場合には復号され、対応する使用可能な提示解像度及び制御要素に基づいて適切なプレゼンテーションのために準備される。例えば、Ｘピクセル×Ｙピクセルの画面解像度に関して典型的なコンピュータビデオ解像度は、一般的には所望されるようにあるいは必要に応じて種々の他の解像度が可能であるが、通常、４８０ピクセル×６４０ピクセルほどの低さから６００×８００から１０２４×１０２４の範囲である。

画像プレゼンテーションは、画像コンテンツ及び既定のビデオコントローラの特定の所定のカラーレベル又はカラー階調（色を生じさせるために使用されるピクセルあたりビット）及び輝度に関して画像を操作する能力、及び追加の利用されているオーバヘッドビットによっても影響を受ける。例えば典型的なコンピュータプレゼンテーションは、他の値にも遭遇するが、多様な色（陰影と色相）を表現するために１ピクセルあたり約８から３２以上のビットを予想するであろう。

前記値から、既定の画面画像はそれぞれ最低から最高の典型的な解像度と深度の範囲で約２．４５メガビット（Ｍｂ）から約３３．５５Ｍｂのデータの転送を必要とすることが分かる。毎秒３０コマの速度でビデオ又は動画タイプの画像を見るとき、必要とされるデータ量は毎秒約７３．７メガビットから１，００６メガビット、つまり毎秒９．２１メガバイトから１２５．７５メガバイトである。加えて、マルチメディアプレゼンテーション用の画像と共に、あるいはＣＤ品質の音楽などの別個の高解像度音声プレゼンテーションとして音声データを提示することを所望する場合がある。対話型コマンド、コントロール、又は信号を処理する追加の信号も利用されてよい。これらのオプションのそれぞれが転送されるなおさらに多くのデータを追加する。さらに高精細度（ＨＤ）テレビ及び映画の録画もさらに多くのデータと制御情報を追加してもよい。いずれにせよ、高品質又は高解像度の画像データと高品質音声情報又はデータ信号をコンテンツリッチな経験を生じさせるためにエンドユーザに転送することを所望するとき、プレゼンテーション要素と、このようなタイプのデータを提供するように構成されるソース又はホストデバイスの間では高データ転送レートリンクが必要とされる。

１秒あたり約１１５キロバイト（ＫＢｐｓ）又は９２０キロビット（Ｋｂｐｓ）のデータレートは、現代のシリアルインタフェースによって日常的に処理できる。ＵＳＢシリアルインタフェースなどの他のインタフェースは、１２Ｍｂｐｓほどの速度のデータ転送に対処し、米国電気電子技術者協会（ＩＥＥＥ）１３９４規格を使用して構成される転送などの特殊高速転送が約１００ＭＢｐｓから４００ＭＢｐｓの速度で行われる。残念なことにこれらの速度は、ポータブルビデオディスプレイ又は音声デバイスを駆動するための高解像度でコンテンツリッチな出力信号を提供するために未来の無線データ装置とサービスと共に使用するために意図される前述された所望される高速データレートには及ばない。これは、事業用コンピュータ及びその他のプレゼンテーション、ゲーム機などを含む。加えて、これらのインタフェースは、操作するためにはかなりの量のホスト又はシステム及びクライアントソフトウェアの使用を必要とする。そのソフトウェアプロトコルスタックは、特にモバイルワイヤレス機器又は電話の応用例が意図される場合に、望ましくないほど大量のオーバヘッドも生じさせる。このような装置はすでに課されている計算能力だけではなく、厳しいメモリ制限と電力消費量制限も有する。さらに、これらのインタフェースのいくつかは、高度に美的指向のモバイル応用例には重すぎ、不満足な嵩張るケーブル、コストを追加する、つまり単に消費電力が多すぎる複雑なコネクタを活用する。

アナログビデオグラフィックスアダプタ（ＶＧＡ）、デジタルビデオインタラクティブ（ＤＶＩ）又はギガビットビデオインタフェース（ＧＶＩＦ）インタフェースなどの他の公知のインタフェースがある。これらの最初の２つは、さらに高速の転送速度でデータを処理するが、重いケーブルも利用し、大量の電力、つまり約数ワットを消費する並列型インタフェースである。これらの特性のどれも携帯型家庭用電子機器と使用するために修正できない。３番目のインタフェースも電力消費が大きすぎ、高価なあるいは嵩張るコネクタを使用する。

前記インタフェースのいくつか、及び他の非常に高速のデータシステム／プロトコル又は固定インストールコンピュータ装置用のデータ転送と関連付けられた転送機構の場合、別の主要な欠点がある。所望されるデータ転送速度に対処することは、大量の電力及び／又は高電流レベルでの動作も必要とする。これは、高度に移動性の消費財のためのこのような技法の実用性を大きく削減する。

一般的には例えば光ファイバ型接続及び転送要素などの代替策を使用してこのようなデータ転送速度に対処することは、真に商業的な消費財に所望されるよりはるかに高い複雑度と費用をもたらす多くの追加の変換器及び要素も必要とする。光学系の一般的に高価な性質に加えて、その電力要件と複雑度が軽量で低電力の携帯型応用例のための一般的な使用を妨げる。

携帯型、無線又はモバイル応用例のために業界で欠如してきたものは、それが音声であるのか、ビデオであるのか、あるいはマルチメディアベースであるのかに関係なく、きわめて移動性の高いエンドユーザ向けの高品質のプレゼンテーション経験を提供するための技法である。すなわち、携帯型コンピュータ、無線電話、ＰＤＡ又は他の高度に移動性の通信デバイス又は装置を使用するとき、使用されている現在のビデオプレゼンテーションシステム又はデバイス及び音声プレゼンテーションシステム又はデバイスは単に所望される高品質レベルで出力を配信することができない。多くの場合、欠如している知覚される品質は、高品質プレゼンテーションデータを転送するために必要とされる入手できない高速データレートの結果である。これは、エンドユーザに対するプレゼンテーションのためのより効率的で高度なあるいは機能満載（ｆｅａｔｕｒｅ ｌａｄｅｎ）の外付け装置への転送と、コンピュータ、ゲーム機などの携帯装置と携帯電話などの無線装置の内部のホストとクライアント間の転送も含むことがある。

後者の場合、さらに高解像度の内蔵ビデオ画面、及び他の特殊入力装置及び／出力装置及び接続をいわゆる第三世代電話のような無線装置に、及びいわゆるラップトップコンピュータに追加する上で大きな前進があった。しかしながら、ホスト及び／又は多様な他の制御要素及び出力構成要素が存在する、ビデオ画面又は他の要素を主要筐体に取り付ける又は接続する、回転式蝶番又は蝶番状の構造にかかるブリッジを含んでよい内蔵データバスと接続。一般に、高帯域幅、又は高スループットのインタフェースが存在する。一例としては、例えば、無線電話で所望されるスループットを達成するためには最高９０個の導体を必要とすることがある従来の技法を使用する高スループットデータ転送インタフェースを構築することは非常に困難である。現在の課題は、一般に、比較的高い信号レベルを持ったパラレルタイプのインタフェースを適用することを含んでいる。これは、相互接続をより高価にかつ低い信頼性にするとともに、デバイス機能と干渉しうる放射放出を潜在的に生成させる。これは、克服しなければならない多くの製造、費用、及び信頼性の問題を提示する。

このような問題点及び要件は、一例として、高度なデータ機能、インターネット及びデータ転送接続又は内蔵エンターテインメントを提供するために、通信装置又は計算型装置が電気製品及び他の消費者装置に追加される、固定されたロケーションのシステムにも見られる。別の例は、個別ビデオ及び音声プレゼンテーション画面がシートバックに取り付けられた、飛行機及びバスであろう。しかしながら、これらの状況では多くの場合、メイン記憶装置、処理要素及び通信制御要素を、情報のプレゼンテーションのための相互接続リンク又はチャネルとの可視画面又は音声出力からある距離離れて位置させる方が、より便利で効率的、且つ容易に実用的である。このリンクは、前述されたように所望のスループットを達成するために大量のデータを処理することを必要とする。

したがって、データを提供するホストデバイスとエンドユーザに出力を提示するクライアントディスプレイ装置又は要素の間のデータスループットを高めるためには新しい転送機構が必要とされる。

出願人は、新しい転送機構を、２００４年７月６日にＺｏｕらに発行された米国特許６，７６０，７７２号となった米国出願１０／０２０，５２０号と、２００２年９月６日に出願された米国特許出願１０／２３６，６５７号とで提案した。これらは、共に”Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer”と題され、本発明の譲受人に委譲され、参照してここに組み込まれる。また、”Generating And Implementing A Signal Protocol And Interface For Higher Data Rates”と題され、２００４年６月２日に出願された米国特許出願１０／８６０，１１６もある。それらの出願で説明されている技法は、高速データ信号の中の大量のデータのための転送速度を大幅に改善できる。しかしながら、特にビデオプレゼンテーションに関して増加の一途を辿るデータレートに対する需要は伸び続ける。データ信号技術における他の継続中の開発をもってしても、依然としてなおさらに高速の転送速度、通信リンク効率の改善、より強力な通信リンクを目指して努力する必要がある。したがって、ホストデバイスとクライアントデバイスの間のデータスループットを高めるために必要とされる新しい、あるいは改善された転送機構を開発する継続するニーズがある。

技術に存在する前記の欠点及び他は、新しいプロトコル及びデータ転送手段、方法及び機構が、高速でホストデバイスと受取人クライアントデバイスの間でデータを転送するために開発された本発明の実施形態により対処される。

本発明の実施形態は、ホストデバイスとクライアントデバイス間のデジタル制御及びプレゼンテーションデータの事前に選択されたセットを通信するための通信プロトコルを形成するための複数の又は一連のパケット構造を利用する通信経路上で、ホストデバイスとクライアントデバイス間で高速でデジタルデータを転送するためのモバイルデータデジタルインタフェース（ＭＤＤＩ）を目的としている。信号通信プロトコル又はリンク層はホスト又はクライアントリンクコントローラ、受信機、又はドライバの物理層によって使用される。ホストデバイス内に常駐する少なくとも１台のリンクコントローラ又はドライバは通信経路又はリンクを通してクライアントデバイスに結合され、通信プロトコルを形成するパケットを生成し、送信し、受信するように、及び１種類又は複数の種類のデータパケットにデジタルプレゼンテーションデータを形成するように構成される。インタフェースは、１つの共通した全体的なハウジング又はサポート構造内に常駐できる、ホストとクライアント間の情報の双方向転送を実現する。

インプリメンテーションは、一般的には、デジタルＣＭＯＳチップ上に容易に実現できる差動ドライバと受信機を例外として本来すべてデジタルであり、６のように少ない信号を必要とし、システムデザイナにとって便宜的であるほとんどすべてのデータレートで動作する。簡略な物理層プロトコルとリンク層プロトコルにより統合は容易になり、ハイバネーション状態が加わったこの簡略さによりポータブルシステムは非常に低いシステム電力消費を有することができる。

使用と受容に役立つために、インタフェースはデバイスのコストをほとんど増加せず、標準電池電圧を使用するインタフェースを通じてディスプレイに電力を供給できる一方、電力をほとんど消費しないで済むようにし、ポケットサイズのフォームファクタを有する装置に対処できる。インタフェースはＨＤＴＶを超える解像度をサポートするためにスケラブルであり、表示措置に対する同時ステレオビデオと７．１音声をサポートし、任意の画面領域への条件付更新を実行し、両方向での複数のデータタイプをサポートする。

本発明の実施形態の更なる態様では、少なくとも１台のリンクコントローラ、受信機、デバイス、又はドライバがクライアントデバイス内に配置され、通信経路又はリンクを通じてホストデバイスに結合される。クライアントリンクコントローラも通信プロトコルを形成するパケットを生成し、送信し、受信するように、及び１種類又は複数の種類のデータパケットにデジタルプレゼンテーションデータを形成するようにも構成される。一般的には、ホスト又はリンクコントローラはコマンド又は特定の種類の信号作成及び照会処理で使用されるデータパケットを処理するための状態機械を利用するが、通信プロトコルで使用されるデータ及びあまり複雑ではないパケットのいくつかを操作するためにより低速の汎用プロセッサを使用できる。ホストコントローラは、１台又は複数台の差動ラインドライバを備える。一方クライアントレシーバは通信経路に結合される１台又は複数台の差動ラインレシーバを備える。

パケットは、様々な可変長を有する所定数のパケットと共に所定の固定長を有するホストデバイスとクライアントデバイス間で通信されるメディアフレーム内で共にグループ化される。パケットはそれぞれパケット長フィールド、１つ又は複数のパケットデータフィールド、及びサイクリックリダンダンシーチェックフィールドを備える。サブフレームヘッダパケットはホストリンクコントローラからの他のパケットの転送の始めに転送される又は配置される。１つ又は複数のビデオストリーム型パケット及び音声ストリーム型パケットは、クライアントデバイスユーザへのプレゼンテーションのために、順方向リンクで、ホストからクライアントへそれぞれビデオタイプデータと音声タイプデータを転送するために通信プロトコルによって使用される。１つ又は複数の逆方向リンクカプセル化タイプのパケットはクライアントデバイスからホストリンクコントローラにデータを転送するために通信プロトコルによって使用される。いくつかの実施形態におけるこれらの転送は、少なくとも１つのＭＤＤＩデバイスを有する内蔵コントローラから内蔵ビデオ画面へのデータの転送を含む。他の実施形態は内部サウンドシステムへの転送及びジョイスティック及び複雑なキーボードを含む多様な入力装置から内蔵ホストデバイスへの転送を含む。

フィラー型パケットは、データを有さない順方向リンク伝送の期間を占有するために、ホストリンクコントローラによって生成される。複数の他のパケットは、ビデオ情報を転送するために通信プロトコルによって使用される。このようなパケットは、カラーマップパケット、ビットブロック転送パケット、ビットマップ領域塗りつぶしパケット、ビットマップパターン塗りつぶし、及び透明カラーイネーブル型パケットを含む。ユーザ定義ストリーム型パケットは、インタフェースユーザ定義データを転送するために通信プロトコルによって使用される。キーボードデータと及びポインティングデバイスデータ型パケットは、前記クライアントデバイスと関連付けられるユーザ入力装置に、及びユーザ入力装置からデータを転送するために通信プロトコルによって使用される。リンクシャットダウン型パケットは、前記通信経路上のどちらかの方向でのデータの転送を終了するため通信プロトコルによって使用される。

ディスプレイ電力ステータスパケットは、システムリソース上のドレイン又はシステム電力消費を最小にするために、ディスプレイのようなクライアントが使用されていないか、あるいは現在アクティブに使用されている場合に、特定のディスプレイコントローラハードウェアを低電力状態にするための構造、手段、又は方法を提供するために生成される。一つの実施形態では、クライアントは、クライアント機能パケットのクライアント特徴機能インジケータのビット９を用いて、ディスプレイ電力ステータスパケットに応答する能力を示す。

ディスプレイ電力ステータスパケットのための一つの実施形態のフォーマット。この種のパケットは、パケット長さフィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、電力状態フィールド、及び周期的冗長チェック（ＣＲＣ）フィールドを持つように構成されている。この種のパケットは一般に２バイトタイプフィールド内のタイプ７５フィールドとして識別される。２バイトのｈＣｌｉｅｎｔＩＤフィールドは、ＣｌｉｅｎｔＩＤのために予約された値又は情報を含んでいる。電力状態フィールドは、特定のディスプレイを、ある予め選択されたビットの値に従って特定された電力状態にするために用いられる情報を特定する。２バイトのＣＲＣフィールドは、パケット長さを含むパケット内の全てのバイトのＣＲＣを特定するか、又は含んでいる。

通信経路は、通常、一連の４本又は５本以上の導線と１つのシールドを有するケーブルを備え、又は利用する。さらにプリントワイヤ又は導体を所望されるように使用でき、いくつかはフレキシブル基板上に存在する。

ホストリンクコントローラは、前記クライアントが前記インタフェースを通じてどのような種類のデータとデータタイプに対処できるのかを決定するためにクライアントデバイスから表示能力情報を要求する。クライアントリンクコントローラは、少なくとも１つのクライアント機能型パケットを使用して表示能力又はプレゼンテーション機能をホストリンクコントローラに伝達する。複数の転送モードが通信プロトコルによって使用され、それぞれは既定の期間で平行して異なる最大数のデータのビットの転送を可能にし、それぞれのモードはホストリンクコントローラとクライアントリンクコントローラの間の交渉によって選択可能である。これらの転送モードはデータの転送中に動的に調整可能であり、順方向リンクで使用されるのと同じモードが逆方向リンクで使用される必要はない。

本発明のいくつかの実施形態の他の態様では、ホストデバイスは、無線電話、無線ＰＤＡ、又はその中に配置される無線モデムを有するポータブルコンピュータ等の無線通信装置を備える。典型的なクライアントデバイスはマイクロディスプレイ装置及び／又は携帯型音声プレゼンテーションシステム等のポータブルビデオディスプレイを備える。さらに、ホストはクライアントデバイスユーザに提示されるために転送されるプレゼンテーションデータ又はマルチメディアデータを記憶するための記憶手段又は要素を使用してよい。

いくつかの実施形態のさらに他の実施形態では、ホストデバイスは、無線電話、無線ＰＤＡ又はポータブルコンピュータ等の無線通信装置などの携帯型電子装置内に常駐する、後述されるような、ドライバ付きのコントローラ又は通信リンク制御装置を備える。この構成の典型的なクライアントデバイスは、クライアント回路又は集積回路、あるいはホストに結合され、同装置内に常駐する、及び携帯電話用の高解像度画面等の内蔵ビデオディスプレイ、及び／又は携帯型音声プレゼンテーションシステムに結合される、代替の何らかの種類の入力システム又は装置の中のモジュールを備える。

本発明の多様な構造及び動作だけではなく、本発明の追加の特徴及び利点も添付図面に関して詳細に説明される。図中、同様の参照番号は、一般的に同一の、機能上類似する、及び／又は構造上類似する要素又は処理ステップを示す。

ポータブルコンピュータ又は他のデータ処理装置と関連する、マイクロディスプレイ装置又はプロジェクタの使用を含む、本発明の実施形態が動作する可能性がある基本的な環境を示す図である。 マイクロディスプレイ装置又はプロジェクタ、及び無線トランシーバと関連して使用される音声プレゼンテーション要素の使用を含む、本発明の実施形態が動作する可能性のある基本的な環境を示す図である。 ポータブルコンピュータで使用される内蔵ディスプレイ又は音声プレゼンテーション装置の使用を含む、本発明の実施形態が動作する可能性のある基本的な環境を示す図である。 無線トランシーバで使用される内蔵ディスプレイ要素又は音声プレゼンテーション要素の使用を含む、本発明が動作する可能性のある基本的な環境を示す図である。 ホストとクライアント相互接続のモバイルデジタルデータインタフェースの全体的な概念を示す図である。 クライアントデバイスからホストデバイスへのデータ転送を実現するために有効なパケットの構造を示す図である。 ＭＤＤＩリンクコントローラの使用、及びＩ型インタフェース用物理データリンク導線上でのホストとクライアント間で受け渡される信号の種類を示す図である。 ＭＤＤＩリンクコントローラの使用、及び２型インタフェース、３型インタフェース、及び４型インタフェース用の物理データリンク導線上で、ホストとクライアントの間で受け渡される信号の種類を示す図である。 インタフェースプロトコルを実現するために使用されるフレームとサブフレームの構造を示す図である。 インタフェースプロトコルを実現するために使用されるパケットの一般構造を示す図である。 サブフレームヘッダパケットのフォーマットを示す図である。 フィラーパケットのフォーマット及びコンテンツを示す図である。 ビデオストリームパケットのフォーマットを示す図である。 図１１で使用されるビデオデータフォーマット記述子のフォーマットとコンテンツを示す図である。 データのパックフォーマットとアンパックフォーマットの使用を示す図である。 音声ストリームパケットのフォーマットを示す図である。 データのためのバイト位置合わせされたＰＣＭフォーマットとパックされたＰＣＭフォーマットの使用を示す図である。 ユーザにより定義されるストリームパケットのフォーマットを示す図である。 カラーマップパケットのフォーマットを示す図である。 逆方向リンクカプセル化パケットのフォーマットを示す図である。 クライアント機能パケットのフォーマットを示す図である。 キーボードデータパケットのフォーマットを示す図である。 ポインティングデバイスデータパケットのフォーマットを示す図である。 リンクシャットダウンパケットのフォーマットを示す図である。 クライアント要求ステータスパケットのフォーマットを示す図である。 ビットブロック転送パケットのフォーマットを示す図である。 本発明の実施形態を実施するために有効な典型的ラスタ動作のデータフローを示す図である。 ビットマップ領域塗りつぶしパケットのフォーマットを示す図である。 ビットマップパターン塗りつぶしパケットのフォーマットを示す図である。 リードフレームバッファパケットのフォーマットを示す図である。 ディスプレイ電力ステータスパケットのフォーマットを示す図である。 実行型ハンドオフパケットのフォーマットを示す図である。 順方向音声チャネルイネーブルパケットのフォーマットを示す図である。 逆方向音声サンプルレートパケットのフォーマットを示す図である。 デジタルコンテンツ保護オーバヘッドパケットのフォーマットを示す図である。 透明色及びマスク設定パケットのフォーマットを示す図である。 往復遅延測定パケットのフォーマットを示す図である。 往復遅延測定パケットの間のイベントのタイミングを示す図である。 本発明を実現するために有効なＣＲＣジェネレータ及びチェッカのサンプルインプリメンテーションを示す図である。 データパケットを送信するときの図３６の装置のＣＲＣ信号のタイミングを示す図である。 データパケットを受信するときの図３６の装置のＣＲＣ信号のタイミングを示す図である。 標準的な差分受信機と比較した特別な低電力差分受信機の典型的な挙動を示す図である。 標準的な差分受信機と比較した特別な低電力差分受信機の典型的な挙動を示す図である。 競合のない典型的なサービス要求のための処理ステップを示す図である。 リンク起動と競合する、リンク再起動シーケンスが開始した後に確かめられた典型的なサービス要求の処理ステップを示す図である。 ＤＡＴＡ−ＳＴＢ符号化を使用してどのようにしてデータシーケンスを送信できるかを示す図である。 ホストで入力データからＤＡＴＡ信号とＳＴＢ信号を発生させ、その後クライアントでデータを回復するために有効な回路網を示す図である。 一実施形態を実現するために有効な信号を転送するドライバと終端レジスタを示す図である。 差分電流モードドライバのブロック図を示す図である。 ハイバーネーションに入るタイミングを示す図である。 ホストからサービスを提供するためにホストによって利用されるステップ及び信号レベルを示す図である。 ホストからサービスを保証するためにクライアントによって、及びこのようなサービスを提供するためにホストによって利用されるステップ及び信号レベルを示す図である。 Ｄａｔａ０、他のデータライン（ＤａｔａＸ）、及びストローブライン（Ｓｔｂ）での遷移間の相対的な間隔を示す図である。 ホストが、パケット転送後にホストドライバをディスエーブルするときに発生することがある応答の遅延の存在を示す図である。 ホストが、ホストドライバがパケットを転送できるようにイネーブルするときに発生することがある応答の遅延の存在を示す図である。 リーク電流分析を示す図である。 ホスト出力とクライアント出力とのイネーブル時間及びディスエーブル時間の相対的なタイミング関係と切り替え特性とを示す図である。 状態機械を使用して同期を実現できる信号処理ステップと条件の高水準図である。 ＭＤＤＩを利用するシステムでの順方向経路と逆方向経路での信号処理について遭遇される典型的な遅延量を示す図である。 境界の往復遅延測定を示す図である。 逆方向リンクデータレート変化を示す図である。 改良された逆方向データサンプリングの例を示す図である。 逆方向速度除数対順方向リンクデータレートの値のグラフィック表現を示す図である。 インタフェースの動作で講じられるステップを示す図である。 インタフェースの動作で講じられるステップを示す図である。 インタフェース装置処理パケットの概要を示す図である。 順方向リンクパケットのフォーマットを示す図である。 Ｉ型リンクインタフェースの伝搬遅延及び歪みの典型的な値を示す図である。 インタフェースを通じた例示的な信号処理のためのＩ型リンクのＤａｔａ、Ｓｔｂ、及びクロック回復タイミングを示す図である。 ２型、３型又は４型リンクインタフェースの伝搬遅延及び歪みのための典型的な値を示す図である。 理想的である早いデータ信号と、互いに関するＭＤＤＩ＿Ｓｔｂのタイミングのための様々な可能性を示す図である。 理想的である遅いデータ信号と、互いに関するＭＤＤＩ＿Ｓｔｂのタイミングのための様々な可能性を示す図である。 理想的である遅いデータ信号と、互いに関するＭＤＤＩ＿Ｓｔｂのタイミングのための様々な可能性を示す図である。 インタフェースを介した典型的な信号処理のための遅延歪み補償回路を備えた一般的な２型順方向リンクを示す図。 １型インタフェースのための考えられるＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形を示す図である。 ２型インタフェースのための考えられるＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形を示す図である。 状態機械を使用して同期を実現できる代替の信号処理ステップと条件の高水準図を示す図である。 一連のクロックサイクルの間の相対的なタイミングと、多様な逆方向リンクパケットビットと除数値のタイミングとを示す図である。 例示的なエラーコード転送処理を示す図である。 エラーコード転送処理に有効な装置を示す図である。 コード過負荷のためのエラーコード転送処理を示す図である。 コード受信のためのエラーコード転送処理を示す図である。 ホストによって起動されるウェークアップのための処理ステップを示す図である。 クライアントによって起動されるウェークアップのための処理ステップを示す図である。 ホストと、競合状態のあるクライアントによって起動されるウェークアップのための処理ステップを示す図である。 要求ＶＣＰ特徴パケットのフォーマットを示す図である。 ＶＣＰ特徴応答パケットのフォーマットを示す図である。 ＶＣＰ特徴応答パケットリストのフォーマットを示す図である。 セットＶＣＰ特徴応答パケットのフォーマットを示す図である。 要求有効パラメータパケットのフォーマットを示す図である。 有効パラメータ応答パケットのフォーマットを示す図である。 スケーリング済みのビデオストリーム機能パケットのフォーマットを示す図である。 スケーリング済みのビデオストリームセットアップパケットのフォーマットを示す図である。 スケーリング済みのビデオストリーム肯定応答パケットのフォーマットを示す図である。 スケーリング済みのビデオストリームパケットのフォーマットを示す図である。 特殊ステータス要求パケットのフォーマットを示す図である。 有効ステータス応答リストパケットのフォーマットを示す図である。 パーソナルディスプレイ機能パケットのフォーマットを示す図である。 フィールド曲率リストのポイントにおける要素を示す図である。 クライアントエラーレポートパケットのフォーマットを示す図である。 エラーレポートリストアイテムのフォーマットを示す図である。 クライアント識別パケットのフォーマットを示す図である。 代替表示機能パケットのフォーマットを示す図である。 レジスタアクセスパケットのフォーマットを示す図である。 可視アーチファクトを削減するための２つのディスプレイバッファの使用を示す図である。 可視アーチファクトを削減するための２つのディスプレイバッファの使用を示す図である。 可視アーチファクトを削減するための２つのディスプレイバッファの使用を示す図である。 画像転送より高速のディスプレイリフレッシュ付きの２つのバッファを示す図である。 画像転送より低速のディスプレイリフレッシュ付きの２つのバッファを示す図である。 画像転送よりはるかに高速のディスプレイリフレッシュ付きの２つのバッファを示す図である。 画像転送より高速のディスプレイリフレッシュ付きの３つのバッファを示す図である。 画像転送より低速のディスプレイリフレッシュ付きの３つのバッファを示す図である。 画像転送より高速のディスプレイリフレッシュ付きの１つのバッファを示す図である。 デイジーチェーンとハブを介するホスト−クライアント接続を示す図である。 ハブとデイジーチェーンの組み合わせを介して接続されるクライアントデバイスを示す図である。 カラーマップを示す図である。 データ転送構成における複数のクライアントの用途を示す図である。 ２つのクライアントとの送信ライン上の終端されていないスタブの使用に対する用途を示す図である。

Ｉ．概要
本発明の全般的な目的は、後述されるように、「シリアル」型のデータリンク又はチャネルを使用して、表示要素等のホストデバイスとクライアントデバイス間の短距離通信リンクでの高速又は非常に高速のデータ転送を可能にする、費用効果が高く、電力消費が低い転送機構をもたらすモバイルディスプレイデジタルインタフェース（ＭＤＤＩ）を提供することである。本機構は、特に、内部（ハウジング又はサポートフレームの中にある）表示装置又は出力要素又はデバイス、又は入力装置を中央コントローラ、あるいは通信要素又は装置に接続する上で有効な小型コネクタと薄い可撓ケーブルを用いるインプリメンテーションに役立つ。更に、この接続機構は、例えばウェアラブルマイクロディスプレイ（ゴーグル又はプロジェクタ）又はその他のタイプのビジュアル、オーディオ、感知情報表示デバイスのような外部表示要素又は装置を、ポータブルコンピュータ、無線通信装置又はエンターテインメント装置へ接続するのに非常に役に立つ。

用語モバイルとディスプレイはプロトコルの命名に関連しているが、これがインタフェースとプロトコルを扱う仕事をする当業者により容易に理解される標準的な名称を有するという点でのみの便宜上であることが理解されなければならない。ビデオエレクトロニクス規格協会（ＶＥＳＡ）規格及びその規格の様々なアプリケーションに関連する。しかしながら、以下の提示される実施形態を検討後、多くの移動性ではなく、ディスプレイに関係しない応用例がこのプロトコルの適用及び結果として生じるインタフェース構造から恩恵を受け、結果として得られるインタフェース構造又は転送機構、及びＭＤＤＩラベルが本発明の性質又は有効性、あるいは多様な実施形態に対する制限を暗示することを目的としないことが容易に理解されるであろう。

本発明の実施形態の利点とは、非常に柔軟でありながら、複雑度が低く、低コストで、信頼性が高く、使用環境によく適合し、非常に堅牢であるデータ転送のための技法が提供される点である。

本発明の実施形態は、通常は音声、ビデオ又はマルチメディアの応用例用の大量のデータをホスト又はソースデバイスから通信又は転送するための多岐に渡る状況で使用でき、この場合このようなデータは、生成され、例えば具体的なデバイスへ転送するために操作され、又は処理され、あるいは例えばビデオディスプレイ、プロジェクション要素、オーディオスピーカのようなクライアントデバイス又は受信デバイス、あるいはその他の表示デバイスへ高速で記憶される。後述される典型的な応用例は、ポータブルコンピュータ又は無線電話又はモデムのどれかから、小型ビデオ画面あるいは小型投射レンズとスクリーンを含むゴーグル又はヘルメットの形を取る等のウェアラブルマイクロディスプレイ器具への、あるいはホストからこのような構成要素内のクライアントデバイスへのデータの転送である。多様な内部入力装置、又はクライアントを利用する外部入力装置から内部に位置する（同じ装置のハウジング又はサポート構造内に配置される）、あるいはケーブル又は導電体によって接続されたホストへだけではなく、プロセッサ又はコントローラから内蔵スクリーン又は他のプレゼンテーション要素である。

ＭＤＤＩの特性又は属性は、それらが特殊な表示技術又はプレゼンテーション技術と無関係であるほどである。これは、そのデータの内部構造に関わらず、あるいはそれが実現するデータ又はコマンドの機能上の態様に関係なく高速でデータを転送するためのきわめて柔軟な機構である。これにより、例えば特定の装置の一意の表示要望等のある特定のクライアントデバイスの特異性に適応するように、あるいはいくつかのオーディオビジュアル（Ａ−Ｖ）システム用の結合された音声とビデオの、あるいはジョイスティック、タッチパッド等の特定の入力装置の要件を満たすように転送されているデータパケットのタイミングを調整できるようになる。選択されたプロトコルに従う限り、インタフェースは非常に表示要素又はクライアントデバイスに非常にとらわれない（ａｇｎｏｓｔｉｃ）。加えて、集合シリアルリンクデータ、つまりデータレートは数桁変化することがあり、通信システム又はホストデバイス設計者がコスト、電力要件、クライアントデバイス複雑度、又はクライアントデバイス更新速度を最適化できるようにする。

データインタフェースは現在主に「有線」信号リンク又は小型ケーブル上で大量の高速データを転送する際に使用するために提示される。しかしながら、いくつかの応用例では、インタフェースプロトコルのために開発された同じパケットとデータ構造を使用することが構成されるならば光ベースのリンクを含む無線リンクも利用してよく、十分に低い電力消費量又は実際的であり続ける複雑度での所望されるレベルの転送を持続できる。

ＩＩ．環境
典型的な応用例は、音声再生システム１０８と１１２と共に、それぞれ表示装置１０４と１０６とデータを通信しているポータブルコンピュータ又はラップトップコンピュータ１００及び無線電話又はＰＤＡ装置１０２が示されている図１Ａと図１Ｂに見られる。さらに、図１Ａは、明確にするためだけに１つの図に示されているが、無線装置１０２にも接続可能である大型のディスプレイ又は画面１１４あるいは画像プロジェクタ１１６への潜在的な接続を示す。無線装置は、現在データを受信できる、あるいは無線装置のエンドユーザによる表示及び／又は聴聞のための後のプレゼンテーション用に特定量のマルチメディアタイプデータを記憶素子又は記憶装置に過去に記憶した。典型的な無線装置は、大体の場合、音声及び単純なテキスト通信用に使用されるので、情報を装置１０２のユーザに通信するためにやや小型の表示画面と単純な音声システム（スピーカ）を有する。

コンピュータ１００は、はるかに大型の画面を有するが、依然として不適当な外部サウンドシステムを有し、高精細度テレビ又は映画のスクリーンなどの他のマルチメディアプレゼンテーション装置には及ばない。コンピュータ１００は図解の目的に使用され、他の種類のプロセッサ、対話型ビデオゲーム又は家庭用電子機器も本発明と共に使用できる。コンピュータ１００は無線通信のために無線モデル又は他の内蔵装置を利用できる、あるいは所望されるようにケーブル又は無線リンクを使用してこのような装置に接続できるが、これらに限定されない。

これにより、より複雑な、つまり「リッチな」データのプレゼンテーションが有効又は楽しい経験になる。したがって、業界はエンドユーザに情報を提示し、最小レベルの所望される楽しみ又は積極的な経験を提供するために他の機構及び装置を開発している。

前述されたように、装置１００のエンドユーザに情報を提示するために複数の種類の表示装置が開発された又は開発されている。例えば、一社又は複数の企業が視覚的表示を提示するためにデバイスユーザの目の前で画像を投影するウェアラブルゴーグルのセットを開発した。正しく配置されると、このようなデバイスは、視覚的な出力を提供する要素よりはるかに大きい「仮想画像」を、ユーザの目によって知覚されるように効果的に「投射」する。つまり非常に小さい投射要素により、ユーザの目（複数の場合がある）は、典型的な液晶ディスプレイ（ＬＣＤ）画面等で可能であるよりはるかに大規模に画像を「見る」ことができる。より大型の仮想画面画像を使用することにより、さらに限定されたＬＣＤ画面ディスプレイで可能となるよりはるかに高い解像度の画像の使用も可能になる。他の表示装置は、表面等の上に画像を映写するために、小型ＬＣＤ画面又は多様なフラットパネルディスプレイ要素、映写レンズ及びディスプレイドライバを含むことができるが、これらに限定されないであろう。

別のユーザに、又は代わりに信号を他のどこかに転送する又はそれらを記憶する別の装置に出力を提示するために無線装置１０２又はコンピュータ１００に接続されるあるいは無線装置１０２又はコンピュータ１００の使用に関連付けられる追加の要素もあってよい。例えば、データは、例えば書き込み可能ＣＤ媒体を使用して光学形式でフラッシュメモリに、あるいは後の使用のために磁気テープレコーダ及び類似する装置内等の磁気媒体に記憶されてよい。

加えて、多くの無線装置とコンピュータは現在、他の高度なサウンドデコーダとサウンドシステムだけではなく、内蔵ＭＰ３ミュージック復号機能も有している。ポータブルコンピュータは原則としてＣＤプレイバック機能とＤＶＤプレイバック機能を活用し、いくつかは事前に記録された音声ファイル用を受信するための小型専用フラッシュメモリ読取装置も有する。このような機能を有することの問題点は、デジタルミュージックファイルが、復号とプレイバックプロセスが足並みを合わせることができる場合にだけであるが、きわめて強化されたフィーチャリッチ（ｆｅａｔｕｒｅ ｒｉｃｈ）な経験を約束するという点である。同じことはデジタルビデオファイルにも当てはまる。

音声再生を支援するために、サブウーファー等の追加要素、あるいは前部と後部のサウンドプロジェクション用の「サラウンドサウンド」スピーカも加えることができるであろう外部スピーカ１１４が図１Ａに示されている。同時に、スピーカ又はイヤホン１０８は、図１Ｂのマイクロディスプレイ装置のサポートフレーム又は機構にとって内蔵として示されている。公知となるように、電力増幅装置又は音声整形装置を含む他の音声又はサウンド再生要素が使用できる。

いずれにせよ、前述されるように、データソースからエンドユーザに対して１つ又は複数の通信リンク１１０上で高品質又は高解像度の画像データ及び高品質の音声情報又はデータ信号を転送することを所望するときには高速データレートが必要とされる。すなわち転送リンク１１０は明らかに前述されたようなデータの通信では潜在的なボトルネックであり、現在の転送機構は通常所望されるような高速データレートを達成しないため、システム性能を制限している。例えば前述されたように、１０２４ピクセル×１０２４ピクセル等のさらに高解像度の場合、１ピクセルあたり２４から３２ビットのカラー階調と、３０ｆｐｓというデータレートを用いると、データレートは７５５Ｍｂｐｓ以上を凌ぐ速度に近づくことができる。加えて、このような画像は、音声データとおそらく対話型ゲーム又は通信に対処する追加の信号、あるいは多様なコマンド、制御又は信号を含むマルチメディアプレゼンテーションの一部として提示されてよく、量又はデータ及びデータレートをさらに増加する。

データリンクを確立するために必要なケーブル又は相互接続がより少ないということは、ディスプレイに関連付けられるモバイル機器がさらに使用しやすく、さらに大きなユーザベースに採用される可能性が高いことを意味することも明らかである。これは、特に、複数の装置が完全な視聴覚経験を確立するために一般的に使用される場合に、及びさらに特にディスプレイと出力装置の品質レベルが増加するにつれて当てはまる。

ビデオ画面及び他の出力装置や入力装置における前述の、及び他の改善に関する別の典型的な応用例は、音声再生システム１３６と１４６と共に、それぞれ「内蔵」表示装置１３４と１４４とデータを通信をしているポータブルコンピュータ又はラップトップコンピュータ１３０及び無線電話又はＰＤＡ装置１４０が示される図２Ａと図２Ｂに見られる。

図２Ａと図２Ｂでは、全体的な電子デバイス又は製品の小さな切取内部図が、今日のエレクトロニクス産業全体で使用されている何らかの公知のタイプの回転接続全体で、それらをビデオディスプレイエレメント又は対応するクライアントを有する画面に接続する汎用通信リンク、ここでは１３８と１４８を備えた装置の一部分の中の１つ又は複数の内部ホストとコントローラの位置を示すために使用される。これらの転送に関与するデータ量が多数の導線がリンク１３８と１４８を構成することを必要とすることが分かる。このようなデータを転送するために使用可能な並行した、又は他の公知のインタフェース技法のタイプのために、このような装置上で高度なカラーインタフェースとグラフィックインタフェース、ディスプレイエレメントを活用する今日の増大する必要性を満たすためにこのような通信リンクは９０以上の導線に近づいていると推定される。

残念なことに、該さらに高いデータレートは、単位時間あたりに転送される必要がある未処理のデータ量と信頼性のある費用効果の高い物理的な転送機構を製造するという両方の点において、データを転送するために現在使用可能な技術を超えている。

必要とされるのは、一貫して（さらに）低い電力、軽量、及び可能な限り簡略且つ経済的なケーブル布線構造を可能にする提示要素とデータソース間のデータ転送リンク又は通信経路用のさらに高速でデータを転送するための技法、構造、手段、又は方法である。出願人は、所望される低電力消費と複雑さを維持する一方で、モバイル機器、携帯機器又は固定位置の装置も所望されるディスプレイ、マイクロディスプレイ又は音声転送要素に非常に高速でデータを転送できるようにするためにこれらの目標及び他の目標を達成するための新しい技法又は方法と装置を開発した。

ＩＩＩ．高速デジタルデータインタフェースシステムアーキテクチャ
新しいデバイスインタフェースを作成し、効率的に活用するために、低電力信号で非常に高速のデータ転送速度を提供する信号プロトコルとシステムアーキテクチャが考案された。該プロトコルはパケットと共通フレーム構造、つまりインタフェースに課されるコマンド又は操作構造と共にデータ又はデータタイプの事前に選択されたセットを通信するためのプロトコルを形成するために共にリンクされる構造に基づいている。

Ａ．概要
ＭＤＤＩリンクによって接続される、あるいはＭＤＤＩリンク上で通信する装置はホストとクライアントと呼ばれ、他の出力装置と入力装置も意図されるが、クライアントは通常何らかのタイプの表示装置である。ホストからディスプレイへのデータは（順方向トラフィック又はリンクと呼ばれる）順方向で移動し、クライアントからホストへのデータは、ホストによりイネーブルされるように逆方向（逆方向トラフィック又はリンク）で移動する。これは図３に示される基本的な構成に描かれている。図３では、ホスト２０２は、順方向リンク２０８と逆方向リンク２１０を備えるとして描かれる双方向通信チャネル２０６を使用してクライアント２０４に接続される。しかしながら、これらのチャネルはそのデータ転送が順方向リンク動作と逆方向リンク動作の間で効果的に切り替えられる導線の１つの共通したセットにより形成されている。これにより、導線の数は大幅に削減され、モバイル電子デバイス向け等の低電力環境における現在の高速データ転送に対する手法が直面する多くの問題の１つに即座に対処できる。

他の箇所に説明されるように、ホストは、本発明を使用することから恩恵を受けることができる複数の種類の装置の内の１つを備える。例えば、ホスト２０２は携帯用デバイス、ラップトップ装置、又は類似するモバイル計算機器の形をしたポータブルコンピュータとなるであろう。それはパーソナルデータアシスタント（ＰＤＡ）、ページング装置、又は多くの無線電話又はモデムの１つである場合もあるであろう。代わりに、ホスト２０２は携帯ＤＶＤ又はＣＤプレーヤ、又はゲームプレイ装置等のポータブルエンターテインメント装置又は提示装置である場合もあるであろう。

さらに、ホストは、高速通信リンクがクライアントと共に所望される、種々の他の広く使用されている、又は計画されている商品にホストデバイス又は制御要素として常駐できる。例えば、ホストは、ビデオ記録装置から応答の改善のために記憶装置ベースのクライアントに、あるいはプレゼンテーションのために高解像度大型画面に高速でデータを転送するために使用できるであろう。機載在庫システム又は計算システム、及び／又は他の家庭用装置に対するブルーツース接続を組み込んだ冷蔵庫等の電気製品は、インターネットモード又はブルーツース接続モードで動作しているときに改善された表示機能を有することができる、あるいは電子コンピュータシステム又は電子制御システム（ホスト）がキャビネット内のどこかに常駐する一方で、ドア内（ｉｎ−ｔｈｅ−ｄｏｏｒ）ディスプレイ（クライアント）及びキーパッド又はスキャナ（クライアント）に対する配線のための書き込みニーズを削減した。一般的には、当業者は、新規の追加された又は既存のコネクタ又はケーブルのどちらかで使用可能な制限された数の導線を活用する情報のより高速なデータレートトランスポートで旧い装置を改良する能力だけではなく、このインタフェースの使用から恩恵を受ける可能性のある種々の現代的な電子デバイスと家庭用製品を理解するであろう。

同時にクライアント２０４は、エンドユーザに情報を提示するため、あるいはユーザからホストに情報を提示するために有用な種々の装置を備えることができるであろう。例えばゴーグル又はめがねに組み込まれているマイクロディスプレイ、帽子又はヘルメットに内蔵されている映写装置、ウィンドウ又はフロントガラス等の車両に内蔵される小型画面又はホログラフィック素子、又は多様なスピーカ、ヘッドフォン、あるいは高品質のサウンド又は音楽を提示するためのサウンドシステム等である。他のプレゼンテーション装置は会議用、あるいは映画とテレビの画像用に情報を提示するために使用されるプロジェクタ又は映写装置を含む。別の例は、実際にはユーザからの接触又はサウンド以外の「入力」はほとんどない装置又はシステムユーザから大量の情報を転送するように要求される可能性のあるタッチパッド又は敏感な装置、音声認識入力装置、セキュリティスキャナ等の使用であろう。加えて、コンピュータ及びカーキット又はデスクキット、及び無線電話用のホルダのためのドッキングステーションは、エンドユーザ又は他のデバイスと装置に対するインタフェース装置として動作してよく、特に高速ネットワークが関係する場合にデータの転送を支援するためにクライアント（マウス等の出力装置又は入力装置）又はホストのどちらかを利用してよい。

しかしながら、当業者は、本発明がこれらの装置に限定されず、記憶とトランスポート、あるいはプレイバック時のプレゼンテーションのどちらかの点で高品質の画像とサウンドをエンドユーザに提供することを目的とした、市場には使用に提案される多くの他の装置があることを容易に認識するであろう。本発明は所望されるユーザ経験を実現するために必要とされる高データレートに対処するために多様な要素又は装置の間のデータスループットを増加するという点で有効である。

本発明のＭＤＤインタフェース及び通信信号プロトコルは、コスト又は複雑度及び関連する電力と制御の要件又はこれらの接続の制約を削減するために、ホストプロセッサ、コントローラ、又は（例えば）回路構成要素及びデバイス又はデバイスハウジング又は構造内のディスプレイの間の相互接続を簡略化するために（内蔵モードと呼ばれる）、及び外部要素、デバイス又は装置に対する接続のため、又はそれらのためだけではなく信頼性を高めるため（外部モードと呼ばれる）に使用されてよい。

このインタフェース構造により利用される各信号ペアの集合シリアルリンクデータレートは、何桁も変化することがあり、システム又は装置設計者が、既定の用途又は目的のためにコスト、電力、インプリメンテーションの複雑度及び表示更新速度を容易に最適化できるようにする。ＭＤＤＩの属性は表示又は他のプレゼンテーション装置（ターゲットクライアント）技術とは無関係である。インタフェースを通して転送されるデータパケットのタイミングは、表示装置、サウンドシステム、記憶素子と制御要素、又は視聴覚システムの結合されたタイミング要件等の特定のクライアントの特異性に適応するように容易に調整できる。これにより、電力消費が非常に小さいシステムを有することができる一方、少なくともなんらかのレベルでＭＤＤＩプロトコルを利用するためにフレームバッファを有することは多様なクライアントの要件ではない。

Ｂ．インタフェースタイプ
ＭＤＤインタフェースは、少なくとも４種類、おそらく５種類以上の通信業界及びコンピュータ業界の何らかの異なる物理的な種類のインタフェースに対処するとして意図されている。それらが使用されている特定の用途あるいはそれらが関連している業界に応じて、他のラベル又は名称が当業者によって適用されてよいが、これらは単に１型、２型、３型及び４型と名付けられている。例えば、単純な音声システムはより複雑なマルチメディアシステムより少ない接続を使用し、「チャネル」等の特徴を別に参照してよい等である。

該１型インタフェースは６ワイヤ、又は他のタイプの導線又は導電素子、つまりそれを携帯電話又は無線電話、ＰＤＡ、電子ゲーム、及びＣＤプレーヤ等のポータブル媒体プレーヤ、又はＭＰ３プレーヤ、及び類似した装置又は類似したタイプの電子消費者技術で使用される装置にとって最適にするインタフェースとして構成される。一実施形態では、インタフェースはラップトップコンピュータ、ノート型パソコン、又はデスクトップパソコン及び類似した装置又は用途により適し、迅速なデータの更新を必要とせず、内蔵ＭＤＤＩリンクコントローラを持たない８ワイヤ（導線）インタフェースとして構成できる。このインタフェースのタイプは、大部分のパソコンで見られる、既存のオペレーティングシステム又はソフトウェアサポートを適応させる上できわめて有効である追加の２線ユニバーサルシリアルバス（ＵＳＢ）インタフェースの使用によっても区別可能である。

２型、３型、及び４型インタフェースは高性能クライアント又はデバイスに適切であり、データ信号に適切な遮蔽及び低損失転送を提供するために、追加のツイストペア型導線と共により大きくさらに複雑なケーブル布線を使用する。

１型インタフェースは、ディスプレイ、音声、制御及び制限されたシグナリング情報を備えることができる信号を送出し、通常、高解像度全速度ビデオデータを必要としないモバイルクライアント又はクライアントデバイスのために使用される。１型インタフェースは５．１チャネル音声が加えられた３０ｆｐｓでスーパービデオグラフィックアレイ（ＳＶＧＡ）解像度を容易にサポートでき、最小の構成で２組をデータ伝送用、１組を電力伝送用とする合計３組のワイヤ組だけを使用する可能性がある。この種のインタフェースはおもに、ＵＳＢホストは信号の接続と転送のためのこのような装置内では使用できないモバイル無線機器等の装置向けである。この構成では、モバイル無線装置はＭＤＤＩホストデバイスであり、通常は、プレゼンテーション、表示又はプレイバックのためにクライアントに（順方向トラフィック又はリンク）データを送信するホストからの通信リンクを制御する「マスタ」として働く。

このインタフェースでは、ホストは、指定された期間それがバス（リンク）を占有し、逆方向パケットとしてデータをホストに送信できるようにするクライアントに特殊なコマンド又はパケットタイプを送信することによってクライアントからの通信データのホストでの受信（逆方向トラフィック又はリンク）を可能にする。これは、（後述される）カプセル化パケットと呼ばれる種類のパケットが転送リンク上での逆方向パケットの転送に対処し、逆方向リンクを生じさせるために使用される図４に描かれている。ホストがデータのためにクライアントをポーリングするために割り当てられた時間間隔がホストによって予定され、それぞれの指定された用途の要件に基づいている。この種の半二重双方向データ転送は、ＵＳＢポートがクライアントからの情報又はデータの転送に使用できない場合に、特に有利である。

ＨＤＴＶ型又は類似した高解像度を可能にする高性能ディスプレイは、フルモーションビデオをサポートするために約１．５Ｇｂｐｓレートのデータストリームを必要とする。該２型インタフェースは並列で２ビットを送信することによって、該３型は並列で４ビットを送信することによって高速データレートをサポートし、該４型インタフェースは８ビットを並列で転送する。２型と３型インタフェースは１型と同じケーブルとコネクタを使用するが、ポータブルデバイスでさらに高性能のビデオアプリケーションをサポートするためのデータレートの２倍及び４倍で動作できる。４型インタフェースは、非常に高性能のクライアント又はディスプレイに適しており、追加のツイストペアデータ信号を備えるわずかに大きなケーブルを必要とする。

ＭＤＤＩによって使用されるプロトコルは、各１型、２型、３型又は４型のホストが、通常、何が使用できる最高のデータレートなのかを交渉することによって１型、２型、３型又は４型のクライアントと通信できるようにする。最も低機能の装置と呼ばれるものの能力又は使用可能な機能はリンクの性能を設定するために使用される。概して、ホストとクライアントが両方とも２型、３型又は４型のインタフェースを使用しているシステムの場合にも、両方とも１型インタフェースとして動作を開始する。ホストは、次に、ターゲットクライアントの機能を決定し、特定の用途に適切な２型、３型又は４型のモードのどれかに応じてハンドオフ動作又は再構成動作を交渉する。

一般的には、ホストが（さらに後述される）適切なリンク層プロトコルを使用し、省電力のためにより低速なモードに通常どんなときでも下げる、つまり再び動作を設定し直す、あるいは高解像度表示コンテンツなどのより高速な転送をサポートするためにより高速なモードに上げることが可能である。例えば、ホストは、システムが電池等の電源からＡＣ電力に切り替わるとき、あるいは表示媒体のソースがさらに低い解像度フォーマット又は高い解像度フォーマットに切り替わるときに、あるいはこれらの組み合わせ又は他の条件又は事象がインタフェースタイプ、つまり転送モードを変更する根拠とみなされてよいときにインタフェースタイプを変更してよい。

システムが一方向で１つのモードを使用し、別方向で別のモードを使用してデータを通信することも可能である。例えば、１型モードがキーボード又はポインティングデバイス等の周辺装置からホストデバイスにデータを転送するときに使用され、４型インタフェースモードは高速でディスプレイにデータを転送するために使用できるであろう。ホストとクライアントが様々な速度で発信データを通信してよいことは当業者によって理解されるであろう。

多くの場合、ＭＤＤＩプロトコルのユーザは「外部」モードと「内部モード」とを区別してよい。外部モードは、ある装置内のホストを、ホストから最高約２メートルくらいであるその装置の外部にあるクライアントに接続するためのプロトコルとインタフェースの使用を説明する。この状況では、ホストは、両方の装置がモバイル環境で容易に動作できるように外部クライアントに電力を送信してもよい。内部モードは、ホストが、共通ハウジング又はサポートフレームあるいは何らかの種類の構造内等、同じ装置の内部に含まれるクライアントにいつ接続されるのかを記述する。一例は、無線電話又は他の無線装置内、あるいはクライアントがディスプレイ又はディスプレイドライバ、あるいはキーパッド又はタッチパッド等の入力装置、又はサウンドシステムであり、ホストが中央コントローラ、グラフィックエンジン又はＣＰＵ要素であるポータブルコンピュータ又はゲーム装置の応用例であろう。クライアントが外部モード応用例と対照的に内部モード応用例でのホストにはるかに近く位置するので、通常、このような構成ではクライアントに対する電力接続について説明される要件はない。

Ｃ．物理インタフェース構造
ホストデバイスとクライアントデバイスの間で通信を確立するためのデバイス又はリンクコントローラの一般的な配置が図５と図６に示されている。図５と図６では、ＭＤＤＩリンクコントローラ４０２と５０２がホストデバイス２０２内に取り付けられて示され、ＭＤＤＩリンクコントローラ４０４と５０４がクライアントデバイス２０４内に取り付けられて示される。前述されたように、ホスト２０２は、一連の導線を備える双方向通信チャネル４０６を使用してクライアント２０４に接続される。後述されるように、ホストコントローラとリンクコントローラの両方とも、ホストコントローラ（ドライバ）又はクライアントコントローラ（受信機）のどちらかとして対応するように設定、調整又はプログラミングできる単一の回路設計を使用して集積回路として製造できる。これは、単一回路デバイスのより大規模な製造のためのさらに低いコストを可能にする。

図６では、ＭＤＤＩリンクコントローラ５０２はホストデバイス２０２’に取り付けられ、ＭＤＤＩリンクコントローラ５０４はクライアントデバイス２０４’に取り付けられて示されている。前述されたように、ホスト２０２’は一連の導線を備える双方向通信チャネル５０６を使用してクライアント２０４’に接続される。前述されたように、ホストコントローラとクライアントリンクコントローラの両方とも単一回路設計を使用して製造できる。

ＭＤＤＩリンク上で、あるいは使用されている物理的な導線の間でホストと表示装置等のクライアントの間で受け渡される信号も図５と図６に示されている。図５と図６で分かるように、ＭＤＤＩを通してデータを転送するための一次的な経路又は機構はＭＤＤＩ＿Ｄａｔａ０＋／−ＭＤＩ＿Ｓｔｂ＋／−と呼ばれるデータ信号を使用する。これらのそれぞれは、ケーブル内の差動組のワイヤで転送される低圧データ信号である。インタフェース上で送信されるビットごとにＭＤＤＩ＿Ｄａｔａ０組又はＭＤＤＩ＿Ｓｔｂ組のどちらかで１つの遷移しかない。これは電流ベースではなく、電圧ベースの転送機構であるため、静的な電流消費はほぼゼロである。ホストはクライアントディスプレイにＭＤＤＩ＿Ｓｔｂ信号を駆動する。

データはＭＤＤＩ＿Ｄａｔａ組上で順方向と逆方向の両方で流れることができる、つまりそれは双方向転送経路であるが、ホストはデータリンクのマスタ又はコントローラである。ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ−Ｓｔｂ信号経路は雑音排除性を最大限にするために差動モードで操作される。これらの線路での信号のためのデータレートは、ホストによって送信されるクロックのレートで決定され、約１ｋｂｐｓから４００Ｍｂｐｓ以上の範囲で可変である。

該２型インタフェースは、ＭＤＤＩ＿Ｄａｔａ１＋／−と呼ばれる該１型のそれを超える１つの追加データ組又は導線又は経路を含む。該３型インタフェースはＭＤＤＩ＿Ｄａｔａ２＋／−及びＭＤＤＩ＿Ｄａｔａ３＋／−と呼ばれる２型インタフェースのそれを超える２つの追加のデータ組又は信号経路を含む。該４型インタフェースは、それぞれＭＤＤＩ＿ｄａｔａ４＋／−、ＭＤＤＩ＿Ｄａｔａ５＋／−、ＭＤＤＩ＿Ｄａｔａ６＋／−、及びＭＤＤＩ＿Ｄａｔａ７＋／−と呼ばれる該３型インタフェースのそれを超える４つのさらに多くのデータ組又は信号経路を含む。前記インタフェース構成のそれぞれでは、ホストはＨＯＳＴ＿ＰｗｒとＨＯＳＴ＿Ｇｎｄと表されるワイヤ組又は信号を使用してクライアント又はディスプレイに電力を送ることができる。さらに後述されるように、電力伝達は、使用可能であるあるいは他のモードのために存在するよりさらに少ない導体を利用するインタフェース「タイプ」が使用されているとき、所望される場合、ＭＤＤＩ＿Ｄａｔａ４＋／１、ＭＤＤＩ＿Ｄａｔａ＋／−５、ＭＤＤＩ＿Ｄａｔａ６＋／−、又はＭＤＤＩ＿Ｄａｔａ７＋／−の導線の上のいくつかの構成で対処できる。電力伝達は、通常外部モードに利用され、いくつかの応用例は異なってよいが、通常内部モードの必要性はない。

多様なモードについてＭＤＤＩリンク上でホストとクライアント（ディスプレイ）の間で受け渡される信号の要約は、インタフェースタイプに従って以下の表Ｉに描かれている。

ホストからの転送のためのＨＯＳＴ＿Ｐｗｒ／Ｇｎｄ接続が通常外部モードに提供されることにも注意する。内部応用例又は運転モードは、当業者に明らかであるように、通常、他の内部リソースから直接電力を引き出し、電力分配を制御するためにＭＤＤＩを使用しないクライアントを有するため、このような分配はここではさらに詳細に説明されない。しかしながら、当業者によって理解されるように、例えば何らかの種類の電力制御、同期又は相互接続の便利さを可能にするために、ＭＤＤＩインタフェースを通して電力を配分できるようにすることは確かに可能である。

通常、前記構造及び動作を実現するために使用されるケーブル布線の長さは約１．５メートル、通常２メートル以下であり、それぞれが同様に、マルチストランドワイヤである３本のツイストペアの導線を含む。ワイヤサイズは特定のサイズには制約されないが、電気仕様又は制約は、最大合計抵抗、フット（foot）当たりの最大キャパシタンス、各ペアのインピーダンス、及び混線に対して満足すべきである。

フォイルシールドカバリングが巻き付けられるか、あるいは、ここでは３本であるツイストペアの組又はグループ全体、及び追加のドレイン線であるドレイン線の上に形成される。ツイストペアとシールドドレイン導線は、技術で周知であるように、シールドがクライアント用のシールドに接続されるクライアントコネクタで終端し、ケーブル全体を覆う絶縁層がある。該ワイヤは、ＨＯＳＴ＿ＧｎｄとＨＯＳＴ＿Ｐｗｒ、ＭＤＤＩ＿Ｓｔｂ＋ＭＤＤＩ＿Ｓｔｂ−、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｄａｔａ０−、ＭＤＤＩ＿Ｄａｔａ＋とＭＤＤＩ＿Ｄａｔａ１−等のように組にされる。しかしながら、当該技術で理解されるように、本発明の実施形態を実現するために、具体的な用途に依存して様々な導線及びケーブル布線が使用されうる。例えば、幾つかの用途においては、ケーブルを保護するために厚い外部皮膜や金属層さえも使用されうる。一方、別の用途には、薄い、平坦な導電性リボンタイプの構造も良好に適する。

後述するようにデータ転送のための内部接続又は相互接続モード、デバイス、プロトコル、装置、又は技術として「内部モード」で使用される場合、１つ以上のクライアントが１つのホストデバイスに接続されることが可能である。内部モード動作の場合、この種の設定を持つことが許される。しかしながら、この場合、１つのクライアントのみがＭＤＤＩインタフェース用の信号及びＭＤＤＩデータ信号をホストに戻すように構成されているか、あるいは戻すことができる。この場合、他のクライアントは、ホストからの信号のための受信機としてのみ動作し、ＭＤＤＩデータ信号のためのソース又はドライバとして動作しない。

１つのホストに対して多くのクライアントを用いる１つのアプリケーションは、携帯電話のような無線デバイス上のＬＣＤパネルのようなビジュアルディスプレイパネル又はビデオの領域にある。そのような多くの無線デバイスは、２つのＬＣＤパネルを備えて設計されている。１つは情報又は画像のメイン、すなわち主要な大型ディスプレイである。もう１つは、例えば、電話が待機状態にあるか、あるいは呼び出しを待っているインアクティブモードにある場合、あるいは呼び出しを行うためにアクティブである場合のように、メインすなわち主要ディスプレイが使用されていない間、電話状態、呼出人ＩＤ、日時、又はその他の機能を示すために使用される小型ディスプレイである。

各ＬＣＤパネルは、ＭＤＤＩホストに接続されたＭＤＤＩクライアントを含むか、または接続されている。メインＬＣＤパネルは、パケットをホストに送り戻すことができるが、サブパネルは、ホストからのパケットの受信のみする。これは、内部モードアプリケーションであるので、サブパネルがその機能又はステータスをホストに送ることができることは必須ではない。なぜなら、ホストは既にクライアントデバイスの特徴を前もって知っているからである。

データ転送構成において、１つより多いクライアント、この場合２つのクライアントを用いる例を図９８に示す。図９８では、ホスト９８００が、導電体、ケーブル、又はバス９８０２，９８０４を介してクライアント９８０６，９８０８にそれぞれ接続されている。ＭＤＤＩ＿Ｄａｔａ及びＭＤＤＩ＿Ｓｔｂの各ペアは、本明細書に記載したように振る舞い、後述するパケット、転送関係、及びメカニズムを有する開示された発明的信号プロトコルを用いて、高データレートでデータを転送することができる。同様に、表示機能等を確認するために、クライアントからのコマンドや設定、要求情報を通信することができる。この実施形態では、クライアント９８０６は、例示したある種の器具、機器、ホストを利用するデバイス、あるいはホスト及びクライアントのための「主要な」すなわちメインディスプレイパネルとして動作するＬＣＤディスプレイデバイス又はある種のパネルに関連付けられているか、一部として形成されているか、あるいは接続されている。一方、クライアント９８０８は、例示したホストを利用するデバイス、ホスト及びデバイスのための「主要な」すなわちメインディスプレイとして動作するＬＣＤディスプレイ又はある種のパネルの一部として形成されているか、接続されている。

２つのディスプレイ要素又はデバイスは、同一である必要も、同じ種類又は性質である必要もなく、その使用が望まれる単なる２つの個別のディスプレイデバイスであることが容易に理解されるべきである。例えば、それらは異なる種類のＬＣＤパネルであるか、又はＬＣＤベースのディスプレイ要素であるかもしれない。一方、他のものは、望まれるように、ＣＲＴ管からの別のタイプのディスプレイ技術を使用する。図９８では、情報及び／又は命令又は制御情報又は信号を各ディスプレイ要素又はパネルに転送するために、別のバスまたは各導線９８１０，９８１２のセットを介して通信する各クライアントが示されている。上述したように、クライアントは、パネルコントローラ９８１４，９８１６を実装するために使用される回路の一部として構成されうる。あるいは、パネルの領域における導線又は要素、回路の一部として形成あるいは確保される。

パネルの回路又は要素を形成する場合、他の要素のための適切なトランジスタを形成することによって、あるいは、当該技術における熟練者に明白な回路モジュールの後付けによって、パネル上にそのようなクライアントを配置するための幾つかの可能なシナリオが存在する。更に、クライアントとパネルコントローラとは、多くの用途において個別の要素となり、単一モジュール又は統合回路要素、他のデバイス又は要素として見られたり、生成される。パネルを介した物理アレイに配置されたピクセル、すなわちイメージ表示素子は、図中においてＬＣＤパネルと称されるものを形成する。ここでは、２つのパネルのうちの一方がメインすなわち主ＬＣＤパネルとして動作し、他方がサブ、追加、あるいは補助的なパネル（望まれるなら、冗長のためのバックアップとなりうる）として動作する。従って、主（メイン）クライアント及びサブクライアントを関連付けた。与えられた任意の時間、又は時間期間において、唯一のクライアントが、ホストを情報を通信したり、あるいは信号を送り戻す。そうでない場合には、ホストは、この情報が異なるクライアントから来ているのか、あるいはどのクライアントから来ているのか正確には分からない。更なるプロトコルのバージョンは、クライアントを介したより洗練された制御、又は所望によりクライアント間の切り替えに対処するために、クライアントＩＤ又は識別表示指定を使用しうる。本明細書で示すように、パケット内には多くの予約されたＩＤ部が存在する。一般に、サブパネルを使用することは、この時間にホストと、同じ種類の返信信号又は通信を必要もしないし、使用もしない。しかしながら、本発明は、必要な場合には、コマンドや、故障モード等に応じて、例えば一定の期間にわたった１次状態及び２次状態の制御又は変更を妨げない。更に、これが、動作の内部モードのためになされた場合、遅延要素の特徴は、一般に、前もって知られ、前の主ディスプレイがもはやそのモードで使用されない新たな主ディスプレイとして選択可能でない場合には、情報の逆方向リンク通信は、単にサブディスプレイの一部上で必要とされない。

Ｄ．データ型及び速度
一連のユーザ経験と応用例にとって有効なインタフェースを達成するために、モバイルデジタルデータインタフェース（ＭＤＤＩ）は、制御情報、及びその組み合わせと共に種々のクライアントと表示情報、音声トランスデューサ、キーボード、ポインティングデバイス及びモバイル表示装置に統合される、又はモバイル表示装置に合わせて作動する可能性のある他の多くの入力装置又は出力装置にサポートを提供する。ＭＤＤＩは、最小数のケーブル又は導線を使用して、順方向又は逆方向のどちらかでホストとクライアント間で行き来するデータの種々の潜在的な種類のストリームに対処できるように設計される。等時性ストリームと非同期ストリーム（更新）の両方ともサポートされる。集合データレートが、最大シリアルレートと利用されるデータエア数により制限される最大所望ＭＤＤＩリンクレート以下である限り、データ型の多くの組み合わせが考えられる。これらは、以下の表ＩＩと表ＩＩＩに一覧表示されるそれらのアイテムを含むことがあるが、これらに限定されない。

インタフェースは固定されていないが、将来のシステム柔軟性のためにユーザにより定義されるデータを含む種々の情報「タイプ」の転送をサポートできるように拡張可能である。対処されるデータの特定の例は、全画面又は部分画面ビットマップフィールド又は圧縮ビデオのどちらかの形式のフルモーションビデオ、電力を節約し、インプリメンテーション費用を削減するための低速の静的ビットマップ、種々の解像度又は速度でのＰＣＭ又は圧縮音声データ、ポインティングデバイス位置と選択、ならびにまだ定義されなければならないユーザ定義可能なデータである。このようなデータは、装置の機能を検出する、あるいは操作パラメータを検出するために制御情報又はステータス情報と共に転送されてもよい。

本発明の実施形態は、映画（ビデオディスプレイ及び音声）を見ること、個人表示が制限されたパソコン（グラフィックディスプレイ、ビデオと音声と結合されることもある）使用すること、ビデオゲームをＰＣ、コンソール、又はパーソナルデバイス（動画グラフィックスディスプレイ又は同期ビデオと音声）でプレイすること、ビデオ電話（双方向低速ビデオと音声）、静止デジタル写真用カメラ、又はデジタルビデオ画像を捕捉するためのカムコーダの形でデバイスを使用してインターネットを「サーフィンすること」、電話、コンピュータ又はプレゼンテーションを行うためにプロジェクタにドッキングされるか、ビデオモニタ、キーボード及びマウスに接続されるデスクトップドッキングステーションにドッキングされるＰＤＡを使用すること、及び無線ポインティングデバイスとキーボードデータを含む携帯電話、スマートフォン、又はＰＤＡによる生産性の強化又はエンターテインメントの用途を含むが、これらに制限されないデータ転送での使用のための技術を進展させる。

後述されるような高速データインタフェースは、大量のＡ−Ｖ型データを、通常はワイヤライン又はケーブル型リンクとして構成される通信リンク又は転送リンク上で提供するという点で提示される。しかしながら、信号構造、プロトコル、タイミング、又は転送機構が、それが所望されるレベルのデータ転送を持続できる場合に、光媒体又は無線媒体の形をとるリンクを提供するように調整できるであろうことは容易に明らかになる。

ＭＤＤＩ信号は、基本的な信号プロトコル又は構造用の共通フレームレート（ＣＦＲ）として公知である概念を使用する。共通フレームレートを使用する背景にある考え方は、複数のストリームのためのフレームタイミング又はクロックを導出するために使用可能なレートでサブフレームヘッダパケットを送信することによって同時等時性データストリームに同期パルスを与えることである。サブフレームヘッダパケットが送信されるレートは、共通フレームレートである。クライアントデバイスはこの共通フレームレートを時間基準として使用できる。低ＣＦＲは、サブフレームヘッダを送信するためにオーバヘッドを減少させることによりチャネル効率を高める。他方、高ＣＦＲは待ち時間を減少させ、音声サンプル用にさらに小さく、融通の利くデータバッファを可能にする。本発明のＣＦＲは動的にプログラム可能であり、特定の用途で使用される等時性ストリームに適切である多くの値の内の１つとして設定されてよい。つまり、ＣＦ値は、所望されるように、既定のクライアントとホスト構成に最も適するように選択される。

ビデオ又はミクロディスプレイ用等の用途と使用される可能性の高い等時性データストリーム用の調整可能又はプログラム可能であるサブフレームごとに通常必要とされるバイト数が表ＩＶに示される。

サブフレームあたりのバイトの部分的なカウントは、簡略なプログラム可能Ｍ／Ｎカウンタ構造を使用して容易に得られる。例えば、サブフレームあたり２６−２／３バイトのカウントは、それぞれ２６バイトの１つのサブフレームが後に続く２７バイトの２つのフレームを転送することによって実現される。さらに小さいＣＦＲは、サブフレームあたりのバイトの整数を生じさせるために選択されてよい。しかしながら、一般的にはハードウェア内で単純なＭ／Ｎカウンタを実現するためには、本発明の実施形態の一部又はすべてを実現するために使用される集積回路チップ又は電子モジュール内では、大型の音声サンプルＦＩＦＯバッファに必要とされる面積より少ない面積を必要とするはずである。

様々なデータ転送速度とデータ型の影響を描く例示的な応用例がカラオケシステムである。カラオケの場合、一人又は複数人のエンドユーザがミュージックビデオプログラムに沿って歌うシステム。歌の歌詞は、ユーザが歌われる歌詞と、大体歌のタイミングとを分かるように画面上のどこか、通常は最下部に表示される。この用途はグラフィック更新が不定期なビデオディスプレイ、及びユーザの１つの又は複数の声をステレオ音声ストリームと混合することを必要とする。

３００Ｈｚという共通フレームレートを想定する場合には、各サブフレームはクライアントに対する順方向リンク上での（ステレオの１４７個の１６ビットのサンプルに基づき）９２，１６０バイトのビデオコンテンツと５８８バイトの音声コンテンツからなり、平均２６．６７（２６−２／３）バイトの音声がマイクから移動性カラオケ機械に送り返される。非同期パケットがホストとおそらくヘッドマウント式のディスプレイの間で送信される。これは、３０秒間隔の１／３０で歌詞テキストが更新される下部１／４スクリーン高さと、歌詞テキストが更新されていない場合にサブフレームに送られるその他の様々な制御及び状態コマンドを含む。

表Ｖは、カラオケ例のサブフレーム内でデータがどのように割り当てられるのかを示す。使用されている合計速度は約２７９Ｍｂｐｓであるように選択される。２８０Ｍｂｐｓというわずかに高いレートは、サブフレームあたり別の約４００バイトのデータを転送できるようにし、臨時の制御メッセージとステータスメッセージの使用を可能にする。

ＩＩＩ．（続き）高速デジタルデータインタフェースシステムアーキテクチャ
Ｅ．リンク層
ＭＤＤＩ高速シリアルデータ信号を使用して転送されるデータは、次々にリンクされる時分割パケットのストリームからなる。たとえ送信側装置に送信するデータがなくても、ＭＤＤＩリンクコントローラは通常自動的にフィラーパケットを送信し、このようにしてパケットのストリームを維持する。単純なパケット構造の使用は、ビデオ信号又は音声信号あるいはデータストリームのための信頼性の高い等時性タイミングを確実にする。

パケットのグループは、サブフレームと呼ばれる信号要素又は構造の中に含まれ、サブフレームのグループはメディアフレームと呼ばれる信号要素又は構造の中に含まれる。サブフレームは、そのそれぞれのサイズとデータ転送用途に応じて１つ又は複数のパケットを含み、メディアフレームはもう１つのサブフレームを含む。ここに提示される実施形態により利用されるプロトコルによって提供される最大サブフレームは約２^３２−１、つまり４，２９４，９６７，２９５バイトであり、最大メディアフレームサイズは約２^１６−１、つまり６５，５３５サブフレームとなる。

特殊なサブフレームヘッダパケットは後述されるように各サブフレームの始まりに表示される一意の識別子を含む。その識別子は、ホストとクライアント間の通信が開始されるとクライアントデバイスでフレームタイミングを獲得するためにも使用される。リンクタイミング獲得は以下にさらに詳細に説明される。

通常、表示画面は、フルモーションビデオが表示されている間にメディアフレームあたりに一度更新される。該表示フレームレートは該メディアフレームレートと同じである。リンクプロトコルは、所望される応用例に応じて、ディスプレイ全体、あるいは静的画像によって囲まれるフルモーションビデオコンテンツの小さな領域だけでフルモーションビデオをサポートする。ウェブページ又はｅメールを表示する等いくつかの低電力のモバイル応用例では、表示画面はときおりしか更新される必要がない場合がある。それらの状況では、単一のサブフレームを送信してから、電力消費を最小限にするためにリンクをシャットダウンする、又は非アクティブ化することが有利である。インタフェースはステレオビジョン等のエフェクトもサポートし、グラフィックスプリミティブを処理する。

サブフレームは、システムが周期的に優先順位が高いパケットの伝送をイネーブルできるようにする。これにより、同時等時性ストリームは最小量のデータバッファリングと共存できる。これは、実施形態が表示プロセスに提供する１つの利点であり、複数のデータストリーム（ビデオ、音声、制御、ステータス、ポインティングデバイスデータ等の高速通信）が本質的に１つの共通したチャネルを共用できるようにする。それは、比較的に少ない信号を使用して情報を転送する。また、それはＣＲＴモニタの、あるいは他のクライアント技術に特殊な作用のための水平同期パルス及びブランキング間隔等の表示技術に特殊な作用が存在できるようにもする。

Ｆ．リンクコントローラ
図５と図６に示されているＭＤＤＩリンクコントローラは、ＭＤＤＩデータとストローブ信号を受信するために使用される差動ラインレシーバを例外として完全にデジタルなインプリメンテーションとなるように製造又は組み立てられる。しかしながら、差動ラインドライバと差動ラインレシーバは、ＣＭＯＳ型ＩＣを作成するとき等、リンクコントローラ付きの同じデジタル集積回路内でも実現できる。アナログ機能又は位相ロックループ（ＰＬＬ）はビット回復のために、あるいはリンクコントローラ用のハードウェアを実現するために必要とされない。ホストコントローラとクライアントリンクコントローラは、リンク同期のために状態機械を含むクライアントインタフェースを例外として、非常に類似した機能を含む。したがって、本発明の実施形態は、ホスト又はクライアントのどちらかとして構成できる単一のコントローラ設計又は回路を作成できるという実用的な利点を可能にし、リンクコントローラの製造コストを全体として削減できる。

ＩＶ．インタフェースリンクプロトコル
Ａ．フレーム構造
パケット転送のために順方向リンク通信を実現するために使用される信号プロトコル又はフレーム構造が図７に描かれている。図７に示されているように、情報又はデジタルデータはパケットとして知られる要素にグループ化される。複数のパケットは同様に共にグループ化され、「サブフレーム」と呼ばれるものを形成し、複数のサブフレームが同様に共にグループ化され、「メディア」フレームを形成する。フレームの形成及びサブフレームの転送を制御するために、各サブフレームは、特にサブフレームヘッダパケット（ＳＨＰ）と呼ばれる所定のパケットで開始する。

ホストデバイスは既定の転送に使用されるデータレートを選択する。この速度は、ホストの最大転送機能、つまりホストによりソースから取り出されるデータ、及びクライアントの最大機能、つまりデータが転送されている先の他の装置の両方に基づいてホストデバイスによって動的に変更できる。

ＭＤＤＩ又は本発明の信号プロトコルと共に作業するために設計される、あるいは本ＭＤＤＩ又は本発明の信号プロトコルを扱うことができる受取人クライアントデバイスは、それが使用できる最大又は現在の最大データ転送速度を決定するためにホストにより照会できる、あるいは使用可能なデータ型とサポートされている特徴だけではなく、デフォルトのより低速な最小速度も使用されてよい。この情報は、さらに後述されるようにクライアント機能パケット（ＤＣＰ）を使用して転送できるであろう。クライアント表示装置は、事前に選択された最小データレートで又は最小データレート範囲内でインタフェースを使用してデータを転送する、あるいは他の装置と通信することができ、ホストはクライアントデバイスの完全な機能を突き止めるためにこの範囲内のデータレートを使用して照会を実行する。

ビットマップ及びクライアントのビデオフレームレート機能の性質を定義する他のステータス情報は、ホストがインタフェースを実用的と同程度に効率的又は最適に構成できるようにステータスパケットでホストに転送できる、あるいは任意のシステム制約の中で所望される。

ホストは、現在のサブフレームの中に転送される（それ以上の）データがないときに、あるいはホストが順方向リンクに選ばれるデータ伝送速度に後れを取らないほど十分な速度で転送できないときにはフィラーパケットを送信する。各サブフレームはサブフレームヘッダパケットで始まるため、前のサブフレームの最後は正確に前のサブフレームを充填するパケット（十中八九フィラーパケット）を含む。パケットにデータ本来を運ぶベータのための余地が欠如している場合、フィラーパケットはサブフレーム内の最後のパケットとなる、あるいは次に前のサブフレームサブフレームの最後で、サブフレームヘッダパケットの前になる可能性が高い。サブフレーム内に、各パケットがそのサブフレーム内で送信されるための残りの十分な空間があることを保証することはホストデバイス内の制御動作のタスクである。同時に、いったんホストデバイスがデータパケットの送信を開始すると、ホストはデータアンダーラン状況を生じさせずにフレーム内でそのサイズのパケットを無事に完了できなければならない。

実施形態の一態様においては、サブフレーム伝送は２つのモードを有する。１つのモードは周期的なサブフレームモード、つまりライブビデオと音声ストリームを送信するために使用される周期的なタイミングエポックである。このモードでは、サブフレーム長は非ゼロであると定義されている。第２のモードは、新しい情報が入手可能であるときだけフレームがクライアントにビットマップデータを提供するために使用される非同期つまり非周期モードである。このモードはサブフレームヘッダパケット内でサブフレーム長をゼロに設定することによって定義される。周期モード使用時、サブフレームパケット受信は、クライアントが順方向リンクフレーム構造に同期したときに開始してよい。これは、図４９又は図６３を参照して後述されている状態図に従って定義された「同期中」状態に相当する。非同期非周期サブフレームモードでは、第１のサブヘッダパケットが受信された後に受信が開始する。

Ｂ．全体的なパケット構造
本実施形態により実現される通信又は信号プロトコルを考案するために使用されるパケットのフォーマット又は構造、又はデータ転送のための方法又は手段は、インタフェースが拡張可能であり、追加のパケット構造が所望されるとおりに追加できることを念頭にして以下に提示されている。パケットは、インタフェースにおけるそれらの機能、つまりそれらが転送するかあるいは関連するコマンド、情報、値、又はデータという点で様々な「パケットタイプ」とされる、つまり分類される。したがって、各パケットタイプは転送されているパケットとデータを操作する上で使用される規定のパケットの所定のパケット構造を示す。容易に明らかとなるように、パケットは事前に選択された長さを有するか、あるいはそれらのそれぞれの機能に応じた可変又は動的に変更可能な長さを有してよい。プロトコルが標準に受け入れられる間に変更されるときに発生するように、同じ機能が依然として実現されるとしても、パケットには異なる名称も付けることができるであろう。多様なパケットで使用されるバイト又はバイト値はマルチビット（８ビット又は１６ビット）の符号なし整数として構成されている。タイプ順で一覧表示されるその「タイプ」名称と共に、利用されているパケットのまとめは、表ＶＩ−１からＶＩ−４に図示される。

各表は、説明及び理解を容易にするために全体的なパケット構造の中のパケットの一般的な「タイプ」を表す。これらのグループ分けによって本発明について暗示される又は表される制限又は他の影響はなく、パケットは所望されるとおりに多くの他の様式で編成できる。パケットの転送が有効であると見なされる方向も注記される。

本文の他の説明から明らかであることは、サブフレームヘッダ、フィラー、逆方向カプセル化、リンクシャットダウン、クライアント機能及びクライアント要求及びステータスパケットがそれぞれ外部モード動作にとって重要であり、外部モードのための通信インタフェースの多くの実施形態においても必要とされるという点である。しかしながら、逆方向カプセル化、リンクシャットダウン、クライアント機能、クライアント要求及びステータスパケットは、内部モード動作のためにもオプションとして考えられるか、あるいは考えられることが好ましい。このことから、通信パケットの縮小セットを用いた非常に高速のデータ通信、及び対応する制御とタイミングの簡略化を可能にするさらに別のタイプのＭＤＤＩプロトコルが生じる。

パケットは、図８に描かれている、パケット長フィールド、パケットタイプフィールド、データバイトフィールド（複数の場合がある）、及びＣＲＣフィールドを備える最小のフィールドの共通の基本的な構造又は全体的な集合を有する。図８に示されるように、パケット長フィールドは、パケットの中のビット総数、つまりパケット長フィールドとＣＲＣフィールドの間のその長さを指定するマルチビット値又はマルチバイト値の形をした情報を含む。一実施形態では、パケット長フィールドは、パケット長を指定する１６ビットつまり２バイト幅の符号なし整数を含む。パケットタイプフィールドは、パケットの中に含まれる情報のタイプを指定する別のマルチビットフィールドである。例示的な実施形態では、これは、１６ビットの符号なし整数の形を取る１６ビットつまり２バイト幅の値であり、表示機能、ハンドオフ、ビデオストリーム又は音声ストリーム、ステータス等のようなデータ型を指定する。

第３のフィールドは、ホストデバイスとクライアントデバイスの間でそのパケットの一部として転送又は送信されているビット又はデータを含むデータバイトフィールドである。データのフォーマットは、転送されているデータ特定の型に従ってパケットタイプごとに特に指定され、それぞれがそれ自体のフォーマット要件を備える一連の追加のフィールドに分離されてよい。つまり、各パケットタイプはこの部分又はフィールドの所定のフォーマットを有するであろう。最後のフィールドは、パケット内で情報の完全性を確認するために使用される、データバイトフィールド、パケットタイプフィールド、及びパケット長フィールド上で計算される１６ビットサイクリックリダンダンシーチェックの結果を含むＣＲＣフィールドである。言い換えるとＣＲＣフィールド自体を除きパケット全体で計算される。クライアントは通常、検出されたＣＲＣエラーの総カウントを保存し、このカウントをクライアント要求及びステータスパケット（以下を参照）でホストに報告する。

一般的には、これらのフィールド幅と編成は２バイトフィールドを偶数バイト境界で位置合わせされた状態に、及び４バイトフィールドを４バイト境界で位置合わせされた状態に保つように作られている。これにより、大部分の、又は通常使用されるプロセッサ又は制御回路について遭遇されるデータ型位置合わせ規則に違反することなく、ホストとクライアントのメインメモリ空間内にパケット構造を容易に構築できるようにする、あるいはパケット構造をホストとクライアントに関連付けることができるようにする。

パケットの転送中、フィールドは最初に最下位ビット（ＬＳＢ）で開始し、最後に送信される最上位ビット（ＭＳＢ）で終了する。長さが１バイトを超えるパラメータは、最下位ビットを最初に使用して送信され、その結果、ＬＳＢが最初に送信されるより短いパラメータに使用されるように、同じビット伝送パターンが長さ８ビットを上回るパラメータに使用されることになる。各パケットのデータフィールドは通常、それらが以下の後の項で定められる順序で送信され、一覧表示されている最初のフィールドが最初に送信され、記述されている最後のフィールドが最後に送信される。ＭＤＤＩ＿Ｄａｔａ０信号経路上のデータは、モード１型、２型、３型又は４型のどれかでインタフェース上で送信されるバイトのビット「０」と位置合わせされる。

ディスプレイ用にデータを操作するとき、ピクセルのアレイのためのデータは、エレクトロニクス技術で従来行われるように最初に行、次に列単位で送信される。言い換えるとビットマップの中の同じ行に表示されるすべてのピクセルは、最も左のピクセルが最初に送信され、最も右のピクセルが最後に送信される順序で送信される。行の最も右のピクセルが送信された後、シーケンスの中の次のピクセルは、続く行の最も左のピクセルである。他の構成に必要に応じて対処できるが、ピクセルの行は通常、大部分のディスプレイの場合上から下への順で送信される。さらに、ビットマップを処理する上で、ここで従われる従来の手法は、ビットマップの左上角をロケーション又はオフセット「０、０」と名付けることによって基準点を定めることである。ビットマップの中で位置を定める又は突き止めるために使用されるＸ座標とＹ座標は、それぞれビットマップの右と下部に近づくにつれて値を増加させる。第１の行と第１の列（画像の左上角）はゼロというインデックス値で開始する。Ｘ座標の規模は、ディスプレイのユーザによって見られるときに画像の右側に向かって大きくなり、Ｙ座標の規模は画像の下部に向かって大きくなる。

ディスプレイウィンドウはビットマップの可視部分、つまり物理的な表示媒体上でユーザが見ることができるビットマップのピクセルの部分である。ディスプレイウィンドウ及びビットマップが同じサイズである場合が多い。ディスプレイウィンドウの左上角はつねにビットマップピクセルロケーション「０、０」を表示する。ディスプレイウィンドウの幅はビットマップのＸ軸に相当し、ディスプレイウィンドウ幅は、本実施形態の場合、対応するビットマップの幅以下である。ウィンドウの高さはビットマップのＹ軸に相当し、ディスプレイウィンドウの高さは、本実施形態の場合、対応するビットマップの高さ以下である。ディスプレイウィンドウ自体は、それはビットマップの可視部分として定義されるに過ぎないためプロトコル内でアドレス指定可能ではない。

ビットマップとディスプレイウィンドウの関係性はコンピュータ、電子技術、インターネット通信、及び他のエレクトロニクス関連の技術で周知である。したがって、これらの原理についての追加の説明又は図解はここでは提供されない。

Ｃ．パケット定義
１．サブフレームヘッダパケット
サブフレームヘッダパケットはあらゆるサブフレームの最初のパケットであり、図９に描かれているような基本的な構造を有する。サブフレームヘッダパケットはホスト−クライアント同期に使用され、あらゆるクライアントがこのパケットを受信し、解釈できなければならない一方であらゆるホストはこのパケットを作成できなければならない。図９の一実施形態で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、一意のワードフィールド、予約１フィールド、サブフレーム長フィールド、プロトコルバージョンフィールド、サブフレームカウントフィールド及びメディアフレームカウントフィールドを、通常その順序で有するように構造化されている。一実施形態では、この種のパケットは通常１５３５９型（０ｘ３ｂｆｆ １６進）パケットとして識別され、パケット長フィールドを含まずに２０バイトという事前に選択された固定長を使用する。

パケットタイプフィールドと一意のワードフィールドはそれぞれ２バイト値（１６ビットの符号なし整数）を使用する。これらの２つのフィールドの４バイトの組み合わせは共に、優れた自己相関のある３２ビットの一意のワードを形成する。一実施形態では、実際の一意のワードは０ｘ００５ａ３ｂｆｆであり、ここでは下位の１６ビットはパケットタイプとして最初に送信され、最上位の１６ビットが後に送信される。

予約１フィールドは将来の使用のために予約される２バイトを含み、通常この点で構成され、すべてのビットがゼロに設定される。このフィールドの１つの目的は、以後の２バイトのフィールドを１６ビットのワードアドレスに位置合わせさせ、４バイトのフィールドを３２ビットのワードアドレスに位置合わせさせる。最下位バイトは、ホストが複数のクライアントデバイスをアドレス指定できるか否かを示すために予約される。このバイトに対するゼロという値は、ホストが単一のクライアントデバイスと共にのみ動作できることを示すために予約される。

サブフレーム長フィールドは、４バイトの情報又はサブフレームあたりのバイト数を指定する値を含む。一実施形態では、このフィールド長は、リンクがシャットダウンされアイドル常態になる前に、サブフレームだけがホストによって送信されることを示すためにゼロに設定されてよい。このフィールドの値は、あるサブフレームから次のサブフレームに遷移するときに「オンザフライで」動的に変更できる。この機能は等時性データストリームに対処するために同期パルスで軽微なタイミング調整を行うために有効である。サブフレームヘッダパケットのＣＲＣが有効ではない場合は、リンクコントローラは現在のサブフレームの長さを推定するために過去の公知の良好なサブフレームヘッダパケットのサブフレーム長を使用する必要がある。

プロトコルバージョンフィールドは、ホストによって使用されるプロトコルバージョンを指定する２バイトを含む。プロトコルバージョンフィールドは、プロトコルの第１のバージョン又はカレントバージョンを使用されているとして指定するために「０」に設定される。この値は新しいバージョンが作成されると経時的に変化し、幾つかのバージョンフィールドについては、既に「１」の値にアップグレードされている。バージョン値は、知られるようになるであろうが、例えばＭＤＤＩのようなインタフェースをカバーする承認された標準的なドキュメントに対する現在のバージョン番号におそらく、あるいは一般には従うであろう。

サブフレームカウントフィールドは、メディアフレームの開始後に送信されたサブフレーム数を示すシーケンス番号を指定する２バイトを含む。メディアフレームの第１のサブフレームはゼロというサブフレームカウントを有する。メディアフレームの最後のサブフレームはｎ−１という値を有し、この場合ｎはメディアフレームあたりのサブフレーム数である。サブフレームカウントフィールドの値は、ゼロの値を持つメディアフレームの第１のサブフレームの場合を除いて、前のサブフレームパケット内で送られたサブフレームカウントに１を加えたものに等しい。サブフレーム長が（非周期サブフレームを示す）ゼロに設定される場合に、サブフレームカウントもゼロに等しく設定されなければならないことに注意する。

メディアフレームカウントフィールドは、転送されている本メディアアイテム又はデータの開始後に送信されたメディアフレーム数を示すシーケンス番号を指定する４バイト（３２ビットの符号なし整数）を含む。メディアアイテムの第１のメディアフレームはゼロというメディアフレームカウントを有する。メディアフレームカウントは、各メディアフレームの第１のサブフレームの直前に増分し、最大メディアフレームカウント（例えば、メディアフレーム数２^３−１＝４，２９４，９６７，２９５）が使用された後に完了して戻る（ｗｒａｐｓ ｂａｃｋ）。メディアフレームカウント値は、通常、最終用途のニーズに合うようにホストによっていつでもリセットされてよい。

２．フィラーパケット
フィラーパケットは、順方向リンク又は逆方向リンクのどちらかで送信するために使用可能な他の情報がないときにクライアントデバイスに、又はクライアントデバイスから転送されるパケットである。必要時に他のパケットを送信する上で最大の柔軟性を可能にするためにフィラーパケットが最小長を有することが勧められる。サブフレーム又は逆方向リンクカプセル化パケット（以下を参照されたい）のまさに最後に、リンクコントローラはパケット完全性を維持するために残りの空間を充填するためのフィラーパケットのサイズを設定する。フィラーパケットは、ホスト又はクライアントが、送信又は交換する情報をともに有しないときに、リンク上でタイミングを維持するために有効である。あらゆるホストとクライアントは、インタフェースを効果的に使用するためにこのパケットを送受できる必要がある。

フィラーパケットのフォーマットとコンテンツの典型的な実施形態は図１０に示されている。図１０に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、フィラーバイトパケット、及びＣＲＣフィールドを有するように構造化されている。一実施形態では、この種のパケットは通常、２倍とタイプのフィールドで示されるタイプ０として識別される。フィラーバイトフィールドの中のビット又はバイトは、フィラーパケットが所望される長さとなることができるようにするために可変数の全ゼロビット値を備える。最小のフィラーパケットはこのフィールドにバイトを含まない。すなわち、パケットはパケット長、パケットタイプ、及びＣＲＣだけからなり、一実施形態では、６バイトという事前に選択された固定長又は４というパケット長を使用する。ＣＲＣ値は、何らかの他のパケットタイプでは排除されてよい、パケット長を含むパケットの中のすべてのバイトについて求められる。

３．ビデオストリームパケット
ビデオストリームパケットは、表示装置の通常は矩形領域を更新するためにビデオデータを搬送する。この領域のサイズは、単一のピクセルと同程度に小さいか、ディスプレイ全体と同じ程度大きくてよい。ストリームを表示するために必要とされるすべてのコンテキストはビデオストリームパケット内に含まれるために、同時に表示され、システムリソースによって制限されるほぼ無制限な数のストリームがあってよい。ビデオストリームパケット（ビデオデータフォーマット記述子）の一実施形態のフォーマットは図１１に示される。図１１で見られるように、一実施形態では、この種のパケットはパケット長（２バイト）フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、ビデオデータ記述子フィールド、ピクセル表示属性フィールド、Ｘ左端縁フィールド、Ｙ上部端縁フィールド、Ｘ右端縁フィールド、Ｙ下部端縁フィールド、Ｘ開始フィールドとＹ開始フィールド、ピクセルカウントフィールド、パラメータＣＲＣフィールド、ピクセルデータフィールド及びピクセルデータＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、２バイトタイプフィールドに示される１６型として識別される。一実施形態では、クライアントはクライアント機能パケットのＲＧＢフィールド、白黒フィールド、及びＹ Ｃｒ Ｃｂ機能フィールドを使用してビデオストリームパケットを受信する能力を示す。

一実施形態では、ｂＣｌｉｅｎｔＩＤフィールドは、クライアントＩＤに予約される２バイトの情報を含む。これは新規に開発された通信プロトコルであるので、実際のクライアントＩＤはまだ公知ではないあるいは十分に通信可能ではない。したがって、このフィールドの中のビットは、このようなＩＤ値が公知になるまで通常ゼロに等しく設定され、その時点でＩＤ値は、当業者に明らかであるように挿入又は使用できる。一般的には同じプロセスが、後述されるクライアントＩＤフィールドに当てはまる。

前述されたように、例示的なビデオデータ記述子フィールドの動作を実現するために利用されるフォーマット及びコンテンツは、図１２Ａから図１２Ｅに示される。図１２Ａから図１２Ｅでは、ビデオデータフォーマット記述子フィールドは、本パケットの本ストリームのピクセルデータの中の各ピクセルのフォーマットを指定する１６ビットの符号なし整数の形の２バイトを含む。様々なビデオストリームパケットが様々なピクセルデータフォーマットを使用してよい、つまりビデオデータフォーマット記述子で違う値を使用してよく、同様にストリーム（表示の領域）がそのデータフォーマットをオンザフライで変更してよいことが考えられる。ピクセルデータフォーマットはクライアント機能パケットで定義されるようにクライアントの有効なフォーマットの内の少なくとも１つに従わなければならない。ビデオデータフォーマット記述子は、一定のフォーマットがある特定のビデオストリームの存続期間中使用し続けられることを暗示しない本パケットだけのピクセルフォーマットを定義する。

図１２Ａから図１２Ｄは、ビデオデータフォーマット記述子がどのようにしてコード化されるのかを描く。これらの図で使用されるように、及びこの実施形態では、ビット［１５：１３］が図１２Ａに示されるように「０００」に等しいときには、ビデオデータはピクセルあたりのビット数がビデオデータフォーマット記述子ワードのビット３から０で定義される、白黒ピクセルのアレイからなる。ビット１１から４は通常将来の使用又は用途のために予約され、この状況ではゼロに設定される。代わりにビット［１５：１３］が図１２Ｂに示されるように値「００１」に等しいときには、ビデオデータはカラーマップ（パレット）を通してそれぞれが色を指定するカラーピクセルのアレイからなる。この状況では、ビデオデータフォーマット記述子ワードのビット５から０はピクセルあたりのビット数を定義し、ビット１１から６は通常将来の使用又は用途のために予約され、ゼロに等しく設定される。ビット［１５：１３］が図１２Ｃに示されるように代わりに値「０１０」に等しいときには、ビデオデータは、赤のピクセルあたりのビット数がビット１１から８によって定められ、緑のピクセルあたりビット数がビット７から４によって定められ、青のピクセルあたりビット数がビット３から０によって定められるカラーピクセルのアレイからなる。この状況では、各ピクセルのビット総数は赤、緑及び青に使用されるビット数の合計である。

しかしながら、ビット［１５：１３］が、図１２Ｄに示されるように代わりに値又は文字列「０１１」に等しいときには、ビデオデータは、輝度とクロミナンス情報を含む４：２：２ＹＣｂＣｒフォーマットのビデオデータのアレイからなり、ルミナンス（Ｙ）のピクセルあたりビット数はビット１１から８によって定義され、Ｃｂ成分のビット数はビット７から４によって定義され、Ｃｒ成分のビット数はビット３から０によって定義される。各ピクセルの中のビット総数は、赤、緑及び青に使用されるビット数の合計である。Ｃｂ成分とＣｒ成分はＹの速度の半分で送信される。加えて、このパケットのピクセルデータ部分の中のビデオサンプルは以下の通りに編成される。つまりＣｂｎ、Ｙｎ、Ｃｒｎ、Ｙｎ＋１、Ｃｂｎ＋２、Ｙｎ＋２、Ｃｒｎ＋２、Ｙｎ＋３，．．．であり、ここではＣｂｎとＣｒｎはＹｎとＹｎ＋１と関連付けられ、Ｃｂｎ＋２とＣｒｎ＋２はＹｎ＋２とＹｎ＋３に関連付けられる等である。

Ｙｎ、Ｙｎ＋１、Ｙｎ＋２、及びＹｎ＋３は、左から右へ単一行の中の４つの連続ピクセルの輝度値である。ビデオストリームパケットにより参照されるウィンドウの中の１行に奇数のピクセルがある場合（Ｘ右端縁−Ｙ左端縁＋１）、各行の最後のピクセルに対応するＹ値の後には次の行の第１のピクセルのＣｂ値が続き、Ｃｒ値は行の中の最後のピクセルのために送信されない。Ｙ Ｃｂ Ｃｒフォーマットを使用するウィンドウが偶数のピクセルである幅を有することが勧められる。パケットの中のピクセルデータは偶数のピクセルを含まなければならない。それは、ピクセルデータの最後のピクセルがビデオストリームパケットヘッダに指定されるウィンドウの中の行の最後のピクセルに相当する場合、つまりピクセルデータの最後のピクセルのＸロケーションがＸ右端縁に等しいときに奇数又は偶数のピクセルを含んでよい。

ビット［１５：１３］が代わりに値「１００」に等しいときには、ビデオデータはピクセルあたりビット数がビデオデータフォーマット記述子ワードのビット３から０で定義される、Ｂａｙｅｒピクセルのアレイからなる。ピクセルグループパターンは、図１２Ｅに示されるように、ビット５と４によって定義される。ピクセルデータの順序は水平又は垂直であってよく、行又は列の中のピクセルは順方向順又は逆方向順で送信されてよく、ビット８から６によって定義される。ビット１１から９はゼロに設定されなければならない。Ｂａｙｅｒフォーマットを取るピクセルグループの中の４個のピクセルのグループは、多くの場合、いくつかの表示技術において単一ピクセルと呼ばれるものに似ている。しかしながらＢａｙｅｒフォーマットの１ピクセルはピクセルグループモザイクパターンの４個の色つきピクセルの内の１つに過ぎない。

図に示される５つすべてのフォーマットについて、「Ｐ」として示されるビット１２が、ピクセルデータサンプルがパックされるのか、あるいはバイト位置合わせピクセルデータであるのかを指定する。このフィールドの「０」という値は、ピクセルデータフィールドの各ピクセルがＭＤＤＩバイト境界とバイト位置合わせされていることを示す。「１」という値は、各ピクセルと、ピクセルデータの各ピクセル内の各色がピクセル内の過去のピクセル又は色と対照してパックされ、未使用のビットを残さないことを示している。バイト位置合わせされたデータフォーマットとパックされたピクセルデータフォーマットの相違点は図１３にさらに詳しく示され、バイト位置合わせされたデータが、未使用の部分を残さないパックされたピクセルフォーマットと対照的に、データサブフレームの未使用の部分を残していることが明確に分かる。

４．音声ストリームパケット
音声ストリームパケットは、クライアントの音声システムを通して、あるいはスタンドアロン音声プレゼンテーション装置用に再生される音声データを搬送する。様々な音声データストリームが、使用されている音声システムに応じて、例えば左前、右前、中央、左後ろ、及び右後ろ等サウンドシステムの別々の音声チャネルに割り当てられてよい。音声チャネルの完全な補完物は機能強化された空間−音響信号処理を含むヘッドセットに提供される。クライアントは、クライアント機能パケットの音声チャネル機能フィールドと音声サンプルレートフィールドを使用して音声ストリームパケットを受信する能力を示す。音声ストリームパケットのフォーマットは図１４に示されている。

図１４に示されるように、この種のパケットは、一実施形態においてパケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、音声チャネルＩＤフィールド、予約１フィールド、音声サンプルカウントフィールド、サンプルあたりビット及びパッキングフィールド、音声サンプルレートフィールド、パラメータＣＲＣフィールド、デジタル音声データフィールド及び音声データＣＲＣフィールドを有するように構造化されている。一実施形態では、この種のパケットは通常パケットタイプ３２として識別される。

ｂＣｌｉｅｎｔＩＤフィールドは、過去に使用されたようにクライアントＩＤに予約される２バイトの情報を含む。予約１フィールドは将来の使用のために予約される２バイトを含み、すべてのビットがゼロに設定され、通常この点で構成される。

サンプルあたりビット及びパッキングフィールドは、音声データのパッキングフォーマットを指定する８ビットの符号なし整数の形を取る１バイトを含む。通常利用されているフォーマットは、ＰＣＭ音声サンプルあたりのビット数を定めるためのビット４から０用である。次にビット５は、デジタル音声データサンプルがパックされるかどうかを指定する。パックされた音声サンプルと、ここでは１０ビットのサンプルを使用するバイト位置合わせされた音声サンプルの相違点は、図１５に示されている。「０」という値は、デジタル音声データフィールドの中の各ＰＣＭ音声サンプルがＭＤＤＩバイト境界とバイト位置合わせされていることを示し、「１」という値は、各連続ＰＣＭ音声サンプルが過去の音声サンプルに対照してパックされることを示す。このビットは通常、ビット４から０で定義される値（ＰＣＭ音声サンプルあたりのビット数）が８の倍数ではないときにだけ有効である。ビット７から６は将来の使用に予約され、通常、ゼロという値で設定される。

５．予約ストリームパケット
一実施形態では、パケットタイプ１から１５、１８から３１、及び３３から５５が、遭遇される多様な応用例について所望されるようにパケットプロトコルの将来のバージョン又は変形での使用のために定義されるストリームパケットに予約される。再び、これは、他の技法に比較して千変万化の技術及びシステム設計に直面してＭＤＤＩをより柔軟且つ有効にすることの一部である。

６．ユーザ定義ストリームパケット
タイプ５６からタイプ６３として知られている８つのデータストリームタイプは、ＭＤＤＩリンクと使用するために装置製造メーカによって定義されてよい独自仕様の応用例で使用するために予約されている。これらはユーザ定義ストリームパケットとして知られている。このようなパケットは任意の目的で使用されてよいが、ホストとクライアントはこのような使用の結果が非常によく理解されている、又は知られている状況だけでこのようなパケットを使用しなければならない。ストリームパラメータ及びこれらのパケットタイプのためのデータの特定の定義は、このようなパケットタイプを実現する、又はその使用を求める特定の装置製造メーカ又はインタフェース設計者に委ねられる。ユーザ定義ストリームパケットのいくつかの例示的な用途は、試験パラメータと試験結果、工場校正データ、及び独自仕様の特殊使用データを伝達することである。一実施形態で使用されるようなユーザ定義ストリームパケットのフォーマットは図１６に示されている。図１６に示されるように、この種のタイプのパケットはパケット長（２バイト）フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤ番号フィールド、ストリームパラメータフィールド、パラメータＣＲＣフィールド、ストリームデータフィールド及びストリームデータＣＲＣフィールドを有するように構造化されている。

７．カラーマップパケット
カラーマップパケットは、クライアントのために色を提示するために使用されるカラーマップルックアップテーブルのコンテンツを指定する。いくつかの応用例は、単一のパケットで送信できるデータ量より大きいカラーマップを必要とすることがある。これらの場合、後述されるオフセットフィールドと長さフィールドを使用することによってそれぞれがカラーマップの異なる部分集合を含む、複数のカラーマップパケットが転送されてよい。一実施形態でのカラーマップパケットのフォーマットは、図１７に示されている。図１７に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、カラーマップアイテムカウントフィールド、カラーマップオフセットフィールド、パラメータＣＲＣフィールド、カラーマップデータフィールド、及びデータＣＲＣフィールドを有するように構造化されている。一実施形態では、この種のパケットは通常、パケットタイプフィールド（２バイト）に指定されるようなパケットタイプ６４（ビデオデータフォーマット及びカラーマップパケット）として識別される。クライアントは、クライアント機能パケットのカラーマップサイズフィールドとカラーマップ幅フィールドを使用してカラーマップパケットを受信する能力を示す。

８．逆方向リンクカプセル化パケット
例示的な実施形態では、データは逆方向リンクカプセル化パケットを使用して逆方向で転送される。順方向リンクパケットは送信され、ＭＤＤＩリンク動作（転送方向）は、パケットが逆方向で送信できるようにこのパケットの真中のあたりで変更又は方向転換される。一実施形態での逆方向リンクカプセル化パケットのフォーマットは図１８に示されている。図１８に示されるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、逆方向リンクフラグフィールド、逆方向レート除数フィールド、方向転換１長フィールド、方向転換２長フィールド、パラメータＣＲＣフィールド、全ゼロフィールド、方向転換１フィールド、逆方向データパケットフィールド、方向転換２フィールド、及び全ゼロ２フィールドとを有するように構造化されている。一実施形態では、この種のパケットは通常パケットタイプ６５として識別される。外部モードの場合、あらゆるホストがこのパケットを生成し、データを受信することができなければならず、あらゆるクライアントは、所望のプロトコルと、結果として生じるスピードとを効率的に利用するために、データを受信し、ホストに送信できなければならない。このパケットのインプリメンテーションは内部モードの場合オプションであるが、ホストが、クライアントからデータを受信するために逆方向リンクカプセル化パケットが使用される。

ＭＤＤＩリンクコントローラは、逆方向リンクカプセル化パケットの送信中特別に動作する。ＭＤＤＩは、通常リンクのコントローラとしてホストによって常に駆動されるストローブ信号を有する。ホストは、それが逆方向リンクカプセル化パケットの方向転換部分と逆方向データパケット部分の各ビットについてゼロを送信しているかのように動作する。ホストは、２回の方向転換の間、及び逆方向データパケットに割り当てられる時間中、各ビット境界でＭＤＤＩ＿Ｓｔｒｏｂｅ信号をトグルする。すなわち、ホストは、全ゼロ１フィールドの初めから、全ゼロ２フィールドの終わりまでＭＤＤＩ＿Ｓｔｂをトグルする（これは、それがあたかも全ゼロデータを送信しているかのと同じ動作である。）。

ホストは、そのＭＤＤＩデータ信号線ドライバをディスエーブルし、一般に、方向転換１フィールドの最後のビットの前にそれらが完全にディスエーブルされたことを保証する。そして、方向転換２フィールドの間、そのラインドライバを再イネーブルし、一般に、方向転換２フィールドの最後のビットの前にそれらが完全に再イネーブルされたことを保証する。クライアントは方向転換長パラメータを読み取り、方向転換１フィールドの最後のビットの直後にホストに向かってデータ信号を起動する。すなわち、クライアントは、パケットコンテンツの以下の説明、及びそれ以外の箇所に指定されるようにＭＤＤＩストローブの特定の立ち上がりでリンクの中に新しいデータの時間を記録する（ｃｌｏｃｋｓ）。クライアントは、それがホストにパケットを送信するために有する利用可能な時間の長さを知るためにパケット長と方向転換長のパラメータを使用する。クライアントは、ホストに送信するデータがないときには、フィラーパケットを送信する、あるいはデータラインをゼロ状態に駆動してよい。データラインがゼロに駆動されると、ホストはこれをゼロ長（有効長ではない）パケットとして解釈し、ホストは現在の逆方向リンクカプセル化パケットの期間中、クライアントからそれ以上のパケットを受け入れない。

一実施形態では、クライアント要求及びステータスパケットの逆方向リンク要求フィールドは、クライアントがデータをホストに送り返すために逆方向リンクカプセル化パケットの中で必要とするバイト数をホストに知らせるために使用されてよい。ホストは、逆方向リンクカプセル化パケットで少なくともそのバイト数を割り当てることによって要求を許可しようとする。ホストは１サブフレームで複数の逆方向リンクカプセル化パケットを送信してよい。クライアントはほぼつねにクライアント要求及びステータスパケットを送信してよく、ホストは１サブフレームで要求される総バイト数として逆方向リンク要求パラメータを解釈する。

９．クライアント機能パケット
ホストは、通常最適な又は所望される方法でホストからクライアントへのリンクを構成するためにそれが通信しているクライアント（ディスプレイ）の機能を知る必要がある。ディスプレイは、順方向リンク同期が取得された後にホストにクライアント機能パケットを送信することが薦められる。このようなパケットの伝送は、逆方向リンクカプセル化パケットで逆方向リンクフラグを使用してホストによって要求されるときに必須と見なされる。クライアント機能パケットは、ホストにクライアントの機能を知らせるために使用される。外部モードの場合、あらゆるホストはこのパケットを受信できるべきであり、あらゆるクライアントはこのインタフェースとプロトコルを完全に活用するためにこのパケットを送信できるべきである。この状況におけるディスプレイ、キーボード、又はその他の入力／出力デバイス等のクライアントの機能は、製造又はなんらかのタイプの単一の構成部品又は装置への組み込みの時点ですでに明確でなければならず、ホストに知られていなければならないので、このパケットのインプレイメンテーションは内部モードに対してはオプションである。

一実施形態でのクライアント機能パケットのフォーマットは図１９に描かれている。図１９に示されているように、この実施形態では、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、プロトコルバージョンフィールド、最小プロトコルバージョンフィールド、校正前データレート機能フィールド、インタフェースタイプ機能フィールド、代替（Ａｌｔ）ディスプレイ数フィールド、予約１フィールド、校正後データレート機能フィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、ディスプレイウィンドウ幅フィールド、ディスプレイウィンドウ高さフィールド、カラーマップサイズフィールド、カラーマップＲＧＢ幅フィールド、ＲＧＢ機能フィールド、白黒機能フィールド、予約１フィールド、Ｙ Ｃｒ Ｃｂ機能フィールド、Ｂａｙｅｒ機能フィールド、予約２フィールド、クライアント特徴機能フィールド、最大ビデオフレームレートフィールド、最小ビデオフレームレートフィールド、最小サブフレームレートフィールド、音声バッファ深さフィールド、音声チャネル機能フィールド、音声サンプルレート機能フィールド、音声サンプル解像度フィールド、マイクサンプル解像度フィールド、マイクサンプルレート機能フィールド、キーボードデータフォーマットフィールド、ポインティングデバイスデータフォーマットフィールド、コンテンツ保護タイプフィールド、製造メーカ名フィールド、製品コードフィールド、予約３フィールド、シリアル番号フィールド、製造週フィールド、製造年フィールド及びＣＲＣフィールドを有するように構造化されている。例示的な実施形態では、この種のパケットは通常、タイプ６６として認識される。

１０．キーボードデータパケット
キーボードデータパケットは、クライアントデバイスからホストにキーボードデータを送信するために使用される。無線（又は有線）キーボードは、ヘッドマウントビデオディスプレイ／音声プレゼンテーション装置を含むが、これに限定されない多様なディスプレイ又は音声装置と共に使用されてよい。キーボードデータパケットは、複数の公知のキーボード状の装置の１つから受信されるキーボードデータをホストに中継する。この種のパケットはキーボードにデータを送信するために順方向リンクで使用することもできる。クライアントは、クライアント機能パケットのキーボードデータフィールドを使用してキーボードデータパケットを送受する能力を示す。

キーボードデータパケットのフォーマットは図２０に示され、キーボードからの、又はキーボード用の可変数のバイトの情報を含んでいる。図２０に示されているように、このパケットは、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、キーボードデータフォーマットフィールド、キーボードデータフィールド、及びＣＲＣフィールドを有するように構造化されている。ここでは、この種のパケットは通常パケットタイプ６７として識別される。

ｂＣｌｉｅｎｔＩＤは前述されたように予約されたフィールドであり、ＣＲＣはパケットの全バイトで実行される。キーボードデータフォーマットフィールドは、キーボードデータフォーマットを記述する２バイト値を含む。ビット６から０は、クライアント機能パケットのキーボードデータフォーマットと同一でなければならない。この値は１２７に等しくない。ビット１５から７は、将来の使用のために予約されているため、現在はゼロに設定されている。

１１．ポインティングデバイスデータパケット
ポインティングデバイスデータパケットは、クライアントからホストへ、無線マウス又は他のポインティングデバイスからの位置情報を送信するための方法、構造、又は手段に使用される。データはこのパケットを使用して順方向リンクでポインティングデバイスに送信することもできる。ポインティングデバイスデータパケットの例示的なフォーマットは図２１に示され、ポインティングデバイスから、又はポインティングデバイス用の可変数のバイトの情報を含む。図２１に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、ポインティングデバイスフォーマットフィールド、ポインティングデバイスデータフィールド、及びＣＲＣフィールドを有するように構造化されている。例示的な実施形態では、この種のパケットは通常１バイトタイプフィールドにおけるパケットタイプ６８として識別される。

１２．リンクシャットダウンパケット
リンクシャットダウンパケットは、ＭＤＤＩデータとストローブがシャットダウンされ、低電力消費「ハイバネーション」状態に入ることを示す方法又は手段としてホストからクライアントに送信される。このパケットはリンクをシャットダウンし、静的ビットマップが移動通信装置からディスプレイに送信された後、あるいはホストからクライアントに当面転送する追加の情報がないときに電力を節約するために有効である。ホストがパケットを再び送信すると通常の動作が再開される。一つの実施形態の場合、ハイバネーション後に送信される最初のパケットはサブフレームヘッダパケットである。クライアントステータスパケットのフォーマットは図２２に示されている。図２２に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ＣＲＣフィールド及び全ゼロフィールドを有するように構造化される。一実施形態では、この種のパケットは、通常１バイトタイプフィールドでパケットタイプ６９として識別される。

パケット長フィールドは、パケット長フィールドを含んでないパケット内の合計バイト数を特定するために２バイト使用する。一つの実施形態では、このパケットのパケット長は、リンクシャットダウンパケットが送られた時において有効であるインタフェースタイプ又はリンクモードに依存する。従って、典型的なパケット長は、１型モードの場合には２０バイト（パケット内で合計２２バイト）、２型モードの場合には３６バイト（パケット内で合計３８バイト）、３型モードリンクの場合には６８バイト（パケット内で合計７０バイト）、及び４型モードの場合には１３２バイト（パケット内で合計１３４倍）となる。

全ゼロフィールドは、ホストのラインドライバをディスエーブルする前に、可変数のバイトを用いて、ＭＤＤＩ＿Ｄａｔａ信号が十分な時間の間、論理ゼロレベルにあることを確証し、クライアントが、ＭＤＤＩ＿Ｓｔｂのみを用いてクロックの回復を始めることを許可する。全ゼロフィールドの長さは、リンクシャットダウンパケットが送られた時に有効であるリンクオペレーティングモード又はインタフェースタイプに依存する。全ゼロフィールドの長さは、任意のインタフェースタイプ設定に対するＭＤＤＩ＿Ｓｔｂ上に６４のパルスを生成することが意図されている。従って、各インタフェースタイプに対する全ゼロフィールドは、１型の場合１６バイト、２型の場合３２バイト、３型の場合６４バイト、４型の場合１２８バイトとなる。

ＣＲＣフィールドは、パケット長さからパケットタイプへのバイトからなる１６ビットＣＲＣを含む２バイトを使用する。

低電力ハイバネーション状態では、ＭＤＤＩ＿Ｄａｔａ０ドライバは、１６番目から４８番目のＭＤＤＩ＿Ｓｔｂサイクルの後、又は全ゼロフィールドの最終ビットの後に始まる高インピーダンス状態にディスエーブルされる。２型、３型、又は４型リンクの場合、ＭＤＤＩ＿Ｄａｔａ１からＭＤＤＩ＿ＤａｔａＰｗｒ７信号までもまた、ＭＤＤＩ＿Ｄａｔａ０ドライバがディスエーブルされるのと同じ時間に、高インピーダンス状態に置かれる。ホスト又はクライアントのどちらかによって、ＭＤＤＩリンクはどこか他の箇所に説明されるようにハイバネーション状態から「目覚め」させられ、それが本発明のための重要な進展であり、本発明の利点である。

全ゼロフィールドの定義において記述したように、ＭＤＤＩ＿Ｓｔｂは、クライアントコントローラにおける規則的なシャットダウンを容易にするために、リンクシャットダウンパケットのＣＲＣフィールドのＭＳＢに続く６４サイクルのためにトグルする。１サイクルは、高−低遷移が後に続く低−高遷移であるか、低−高遷移が後に続く高−低遷移である。全ゼロフィールドが送られた後、ホスト内のＭＤＤＩ＿Ｓｔｂドライバがディスエーブルされる。

１３．クライアント要求及びステータスパケット
ホストは、それが通常最適にホストからクライアントへのリンクを構成できるように、クライアントから少量の情報を必要とする。クライアントがクライアント要求及びステータスパケットをサブフレームごとにホストに送信することが勧められる。クライアントは、それが確実にホストに配信されることを保証するために逆方向リンクカプセル化パケット内で最初のパケットとしてこのパケットを送信することが一般に勧められる。また、このパケットの転送は、逆方向リンクカプセル化パケット内で逆方向リンクフラグを使用してホストによって要求されるときに達成される。クライアント要求及びステータスパケットは、ホストにエラーとステータスを報告するために使用される。外部モード動作の場合、あらゆるホストはこのパケットを受信できなければならず、あらゆるクライアントはＭＤＤＩプロトコルを適切に又は最適に利用するためにこのパケットを送信できなければならない。それは、内部ホスト及び内部クライアントである内部動作の場合にも推奨されるが、パケットに対するサポートがあるべきであり、それは要求されない。

クライアント要求及びステータスパケットのフォーマットは図２３に示されている。図２３に示されるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、逆方向リンク要求フィールド、機能変更フィールド、クライアントビジーフィールド、ＣＲＣエラーカウントフィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、１バイトタイプフィールドのパケットタイプ７０として識別され、通常は１２バイトという事前に選択された固定長を使用する。

逆方向リンク要求フィールドは、ホストのデータを送り返すために逆方向カプセル化パケットでクライアントが必要とするバイト数をホストに知らせるために使用されてよい。ホストは逆方向リンクカプセル化パケット内で少なくともその数のバイトを割り当てることによって要求を許可しようとしなければならない。ホストはデータに対処するためにサブフレーム内で複数の逆方向リンクカプセル化パケットを送信してよい。クライアントはいつでもクライアント要求及びステータスパケットを送信してよく、ホストは逆方向リンク要求パラメータを１つのサブフレームで要求されるバイトの総数として解釈する。逆方向リンクデータがどのようにしてホストに送り返されるのかの追加の詳細及び特定の例が後述される。

１４．ビットブロック転送パケット
ビットマップブロック転送パケットは、一般に、一つの長方形領域から別の長方形領域にピクセルのブロックをコピーすることによって、任意の方向でディスプレイの領域をスクロールするための手段、構造、又は方法を提供する。この機能を有するクライアントは、クライアント機能パケットの表示特徴機能インジケータフィールドのビット０で機能を報告する。ビットブロック転送パケットの、一つの実施形態のフォーマットは図２４に示されている。図２４に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ピクセルデータ属性フィールド、ラスタ動作フィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、ウィンドウＸ移動フィールド、ウィンドウＹ移動フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは通常７１タイプパケットとして識別され、一つの実施形態では、１５バイトという事前に選択された固定長を使用する。２バイトのｈＣｌｉｅｎｔＩＤフィールドは、説明したようにクライアントＩＤのために予約された値又は情報を含んでいる。このフィールドは、一般に、将来の使用のために予約されているので、所望の情報を転送するために、当該技術における熟練者によってその他の値が設定又は使用されることも可能であるが、ビットを論理ゼロレベルに設定することによって、一般にゼロに設定される。

一つの実施形態では、２バイトのピクセルデータ属性フィールドは、ピクセルデータがどこで更新されるべきかを特定する値を持つ。ここでは、ビット１とビット０とが、ピクセルデータが更新されるディスプレイを選択する。クライアントの主ディスプレイがステレオイメージをサポートしていないのであれば、クライアントは、主ディスプレイ内のピクセルデータを、０１，１０，又は１１からなるビット組み合わせのうちの１つに作用させることができる。値１１は、ステレオディスプレイ機能をサポートしていないクライアントにおける主ディスプレイに対処するために使用されることが推奨される。ビット［１：０］が値１１（２つとも論理１）をもつ場合、ピクセルデータは、左目及び右目の両方のフレームバッファ内で更新される。ビット［１：０］が値１０（論理１、論理０）を持つ場合、ピクセルデータは、左目のみのフレームバッファ内で更新される。ビット［１：０］が値０１（論理０、論理１）を持つ場合、ピクセルデータは、右目のみのフレームバッファ内で更新される。ビット［１：０］が値００（２つとも論理０）を持つ場合、ピクセルデータは、ビット８乃至１１で特定される別のディスプレイのフレームバッファ内で更新される。

１つの実施形態では、ピクセルデータ属性フィールドのビット２は、左目又は右目のためのバッファが、この動作のイメージのソースであるか否かを特定する。ビット２は、ビット[１:０]が００に等しくない場合にのみ当てはまる。これは、一般に、イメージの宛先が、代替ディスプレイのうちの１つである場合、主イメージからのソースデータではないことを意味するように実装される。ビット２は、左目フレームバッファと右目フレームバッファとを区別するか、あるいは、データソースとして、左目フレームバッファと右目フレームバッファとの間として特定する。ビット２が０に等しい場合、左目フレームバッファがデータソースであるが、ビット２が１に等しい場合、右目フレームバッファがデータソースである。

ピクセルデータ属性フィールドのビット３は、ディスプレイをリフレッシュするために使用されるバッファ、又はオフラインイメージバッファが、この動作のためのイメージのソースになるのかを特定する。ビット３は、代替ディスプレイが、オフラインイメージバッファを利用するのであれば、代替ディスプレイにも当てはまる。しかしながら、イメージの宛先が代替ディスプレイである場合には、主イメージバッファからのソースデータをサポートしない。あるいはその逆でもよい。ビット３が値０、すなわち論理零レベルに等しい場合、ディスプレイをリフレッシュするために使用されるイメージバッファは、データソースである。ビット３が値１、すなわち論理１レベルに等しい場合、オフラインイメージバッファがデータソースである。

ピクセルデータ属性フィールドのビット７及びビット６は、フレームバッファを特定するディスプレイ更新ビットとして作用する。このフレームバッファでは、ピクセルデータが更新又は書き込まれる。フレーム更新ビットの効果は、後で詳述する。ビット［７：６］が‘０１’（論理０、論理１）である場合、ピクセルデータは、オフライン画像バッファに書き込まれる。ビット［７：６］が‘００’（２つとも論理０）である場合、ピクセルデータはディスプレイをリフレッシュするために使用される画像バッファに書き込まれる。ビット［７：６］が‘１１’（２つとも論理１）である場合、ピクセルデータは画像バッファに書き込まれる。ビット［７：６］が‘１０’である場合、無効な値として扱われる。これらビットは今のところ、将来の使用のために予約されている。この状況では、コマンド全体が無視され、フレームバッファは更新されない。

ピクセルデータ属性フィールドのビット１１乃至８は、４ビットの符号なし整数である。これは、ピクセルデータが更新されるべき代替クライアント位置、あるいは代替ディスプレイを特定する。ビット０とビット１は、クライアントが、ビット１１乃至８を、代替ディスプレイ数として解釈するために００（２つとも論理０）に等しく設定される。ビット１とビット０とが００に等しくない場合には、ビット８乃至１１は一般に論理ゼロ値あるいは論理ゼロレベルに等しく設定される。ビット４乃至５とビット１２乃至１５は、将来の使用のために予約され、一般に、論理ゼロ値又は論理ゼロレベルに設定される。

一つの実施形態では、２バイトのラスタ動作フィールドが、宛先イメージ位置に書き込まれる新たなピクセル値を生成するために、ソース位置と宛先位置とにおけるピクセルをどのように合成するのかを特定する。ラスタ動作は、フレームバッファ内の等しい大きさソース領域と宛先領域とが、宛先領域にどのようにして合成されるのかを定義する。宛先イメージ領域はまた、合成される２つのイメージのうちの一つである。２つのイメージのうちの２つ目は、ソースイメージと呼ばれる。クライアントが、クライアント機能パケット内で特定されたラスタ動作フィールドをサポートしない場合、ホストは、一般に、３に等しいビット３乃至０でパケットを送り、クライアントはビット３からビット０を無視する。

一つの実施形態では、ビット３からビット０が、これらビットを用いることによって、あるいは、これらビットを、表ＶＩＩに示すように、値の次に示される動作を選択するために、表ＶＩＩに示す値の１つと等しく設定することによって、実際のラスタ動作を特定するために使用される。すなわち、第一カラムにリストされた各特定されたビット［３：０］値によって、第二カラムで特定され、明確化のために第三カラムで定義された動作になる。

ビット９乃至８は、透明色に関連する場合、宛先ピクセルが宛先位置に書き込まれたか否かを特定するために使用される。クライアント機能パケットのクライアント特徴機能インジケータのビット４は、透明色及び透明マスク機能がクライアントによってサポートされているか否かを示す。同様に、代替ディスプレイ機能パケットのディスプレイ特徴機能インジケータフィールドは、透明色及び透明マスク機能が、特定された代替ディスプレイによってサポートされているかを示す。透明色及び透明マスク機能がサポートされていない場合、ラスタ動作は、ビット[９:８]があたかも００に設定されているかのように振舞う。ビット[９:８]によって特定される動作は、ラスタ動作が、クライアントデバイスによってサポートされているか否かに当てはまる。クライアントがラスタ動作をサポートしない場合、ビット[９:８]によって定義される動作のために考慮される結果として得られる宛先ピクセルは、ソースピクセル値のみに等しい。この挙動は、ビット[３:０]を３に設定することと同様である。

ビット［９：８］の値が００に等しい場合、透明色は使用されない。結果として得られる宛先ピクセルは、透明色又は透明マスクの値を考慮することなく宛先ピクセル位置に書き込まれる。透明色は、透明色及びマスク設定パケットによって定義される。０１に等しいビット［５：４］の値は、当該技術分野における熟練者が関連する使用を設定するように利用可能であれば、今のところ、将来の使用のために予約されており、使用されていない。ビット［５：４］の値が１０に等しい場合、ラスタ動作による計算の結果として得られる宛先ピクセル、透明マスクとＡＮＤを取られたソースピクセルが透明色に等しいのであれば、結果として得られるピクセルは宛先ピクセル位置には書き込まれない。そうでない場合には、宛先ピクセル位置に書き込まれる。ビット［９：８］の値が１１に等しい場合、ラスタ動作による計算の結果として得られる宛先ピクセルが透明色に等しいのであれば、結果として得られるピクセルは、宛先ピクセル位置に書き込まれる。そうでない場合には、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。

ビット１５乃至１０，及び７乃至４は、将来の使用のために予約されており、一般的に、論理ゼロ値又は論理ゼロレベルに等しく設定されている。

残りのフィールドは、移動すべきウィンドウの上左隅のＸ座標値とＹ座標値、移動すべきウィンドウの幅及び高さ、水平方向、垂直方向それぞれに移動すべきウィンドウのピクセル数を特定するために使用される。後者の２フィールドの正の値によって、ウィンドウは、右及び下に移動し、負の値によって、左及び上にそれぞれ移動するようになる。ＣＲＣフィールド（ここでは２バイト）は、パケット長さを含むパケット内の全バイトのうちの１６ビットＣＲＣを含む。

１５．ビットマップ領域塗りつぶしパケット
ビットマップ領域塗りつぶしパケットはディスプレイの領域を単一の色に容易に初期化する手段、構造、又は方法を提供する。この機能を有するディスプレイは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット１で該機能を報告する。ビットマップ領域塗りつぶしパケットのフォーマットの一つの実施形態は図２５に示されている。図２５に示されているように、この場合、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔフィールド、ビデオデータフォーマット記述子フィールド、ピクセルデータ属性フィールド、ラスタ動作フィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、ピクセル領域塗りつぶし値フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは通常２バイト型フィールドでパケットタイプ７２として識別される。

２バイトのｈＣｌｉｅｎｔフィールドは、説明したように、クライアントＩＤのために予約された情報又は値を含む。このフィールドは一般に将来の使用のために予約されているので、ビットを論理ゼロレベルに設定することによって、一般には現在値をゼロに設定している。しかしながら、当該技術分野における熟練者によってその他の値に設定又は使用され、所望の情報の転送のために使用されることもある。

２バイトを用いるこの実施形態では、ビデオデータフォーマット記述子フィールドは、ピクセル領域塗りつぶし値のフォーマットを特定する。このフォーマットは、既に説明および図示したビデオストリームパケットにおける同じフィールドと同じである。ピクセル領域塗りつぶし値フィールド（４バイト）は、パケット内のパラメータによって特定されるウィンドウに塗りつぶされるピクセル値を含む。このピクセルのフォーマットは、ビデオデータフォーマット記述子フィールド内で特定される。ピクセル領域塗りつぶし値のためのピクセルフォーマットの一例は、前に示したものと同じである。Ｙ Ｃｂ Ｃｒフォーマットが選択されると、透明色及び透明マスクは、正確に示すと、ピクセル１及び２Ｃｂ、ピクセル１Ｙ、ピクセル１及び２Ｃｒ、及びピクセル２Ｙのサブフィールドを含むものとする。透明色値に割り当てられるバイト数は、ビデオデータフォーマット記述子フィールドによって決定される。

ピクセルデータ属性フィールド及びラスタ動作フィールドは、上述したビットマップブロック転送パケットにおける同じフィールドと同様に機能し、詳細は後述する。

残りのフィールドは、移動するウィンドウの上左隅の座標のＸ値及びＹ値を特定するために使用される。ウィンドウ上左座標Ｘ値フィールド及びＹ値フィールドは、塗り潰されるウィンドウの上左隅の座標のＸ値及びＹ値を特定するためにそれぞれ２バイト使用する。ウィンドウ幅フィールド及びウィンドウ高さフィールド（それぞれ２バイト）は、塗り潰されるウィンドウの幅及び高さを特定する。ＣＲＣフィールド（ここでは２バイト）は、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

１６．ビットマップパターン塗りつぶしパケット
ビットマップパターン塗りつぶしパケットは、事前に選択されたパターンに表示の領域を容易に初期化する手段又は構造を提供する。この機能を有するディスプレイはクライアント機能パケットのクライアント特徴機能フィールドのビット２で該機能を報告する。塗りつぶしパターンの左上角は、水平又は垂直パターンが、ゼロ以外にオフセットされていなければ、塗りつぶされるウィンドウの左上角と位置合わせされている。塗りつぶされるウィンドウが塗りつぶしパターンより幅広い、又は背が高い場合には、パターンはウィンドウを塗りつぶすために何回も水平に又は垂直に繰り返されてよい。最後に繰り返されるパターンの右又は下部は必要に応じて切り捨てられる。ウィンドウが塗りつぶしパターンより小さい場合には、塗りつぶしパターンの右上又は右下がウィンドウに適合するために切り捨てられてよい。

水平パターンオフセットがゼロ以外であれば、ウィンドウの左隅と、この左隅に水平パターンオフセットとを加えたものとの間のピクセルが、最も右側のピクセルパターンで塗り潰される。水平パターンオフセットは、パターン幅未満になるべきである。同様に、垂直パターンオフセットがゼロ以外であれば、ウィンドウの上側と、この上側に垂直パターンオフセットを加えたものとの間のピクセルが、最も下側のピクセルパターンで塗り潰される。垂直パターンオフセットは、パターン高さ未満になるべきである。

ビットマップ塗りつぶしパケットのフォーマットの一つの実施形態は図２６に示されている。図２６に示されているように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ビデオデータフォーマット記述子フィールド、ピクセルデータ属性フィールド、ラスタ動作フィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、パターン幅フィールド、パターン高さフィールド、水平パターンオフセットフィールド、垂直パターンオフセットフィールド、パラメータＣＲＣフィールド、パターンピクセルデータフィールド及びピクセルデータＣＲＣフィールドを有するように構造化されている。ある実施形態では、この種のパケットは通常１バイト型フィールドでパケットタイプ７３として識別される。

２バイトのｈＣｌｉｅｎｔＩＤフィールドは、説明されているように、ＣｌｉｅｎｔＩＤのために予約された情報又は値を含む。このフィールドは、一般に、将来の使用のために予約されているので、現在の値は、ビットを論理ゼロレベルに設定することによって一般にゼロに設定される。

２バイトのビデオデータフォーマット記述子フィールドは、ピクセル領域塗りつぶし値のフォーマットを特定する。図１１は、ビデオデータフォーマット記述子がどのように符号化されるかを示す。このフォーマットは、ビデオストリームパケットにおける同じフィールドと同じである。

ピクセルデータ属性フィールド及びラスタ動作フィールドは、上述したようなビットマップ転送パケット内の同じフォールドと同様に機能し、詳細については後述する。

ビットマップパターン塗り潰しパケットの残りのフィールドは、塗り潰されるウィンドウの上左隅の座標のＸ値及びＹ値、塗り潰されるウィンドウの幅及び高さ、塗り潰しパターンとして使用されるパターン幅及び高さ、特定された塗り潰されるウィンドウの左端及び上端それぞれからのピクセルデータパターンの水平オフセット及び垂直オフセットを特定するために使用される。パターンＣＲＣフィールド（ここでは２バイト）は、パケット長からビデオフォーマット記述子へのパケット内の全てのバイトの１６ビットＣＲＣを含む。このＣＲＣが、チェックに失敗した場合には、全てのパケットが破棄されるものとする。パターンピクセルデータＣＲＣフィールドは、パターンピクセルデータのみからなる１６ビットＣＲＣを含む。このＣＲＣが、チェックに失敗した場合には、パターンピクセルデータは使用され続けるが、ＣＲＣエラーカウントがインクリメントされる。パターンピクセルデータフィールドは、ビデオデータフォーマット記述子によって特定されるフォーマット内の塗り潰しパターンを特定する生ビデオ情報を含む。

１７．リードフレームバッファパケット
リードフレームバッファパケットは、逆方向リンクを介してホストへ送り戻されるクライアント内フレームバッファの長方形領域を選択、決定、又は特定するための構造、手段、又は方法を提供する。戻されたピクセルデータのフォーマットは、ディスプレイの元々のフォーマットである、このフォーマットは、一般に、逆方向リンクを介してホストへ送られたビデオストリームパケットのデータフォーマット記述子フィールド内で特定される。ホストに戻されたピクセルデータは、現在表示されているイメージバッファからのものである。クライアントは、必要に応じて、リードフレームバッファパケットによって特定されたディスプレイ領域に戻るために、できる限り多くの逆方向リンクカプセル化パケット内のできる限り多くのビデオストリームパケットを使用する。この機能を有するクライアントは、クライアント機能パケットのクライアント特徴機能表示フィールドのビット３を用いて該機能を表示するか、あるいは報告する。

リードフレームバッファパケットのための実施形態のフォーマットは図２７に示されている。図２７に示されているように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ディスプレイデータ属性フィールド、Ｘ左端フィールド、Ｙ上端フィールド、Ｘ右端フィールド、Ｙ下端フィールド、及びＣＲＣフィールドを有するように構造化されている。一つの実施形態では、この種のパケットは、通常、タイプフィールドでパケットタイプ７４として識別される。

２バイトのパケット長フィールドは、パケット長フィールドを含まないパケットにおける合計バイト数を特定する。１つの実施形態では、パケット長フィールドは、１６に固定される。２バイトのｈＣｌｉｅｎｔＩＤフィールドは、前に使用されたように、ＣｌｉｅｎｔＩＤのために予約された値又は情報を含む。このフィールドは、当該技術における熟練者によって所望の情報を転送するために使用することができるが、一般に、将来の使用のために予約されており、現在値は、ビットを‘０’（論理ゼロレベル又はゼロ状態）に設定することによって零に設定される。

１つの実施形態では、２バイトのディスプレイデータ属性フィールドは、ピクセルデータが読まれる場所を特定する値を有する。ここでは、ビット０が、ピクセルデータが読み始められるフレームバッファを選択する。ビット０が値０（論理ゼロ）に等しい場合、ピクセルデータが、ビット８乃至１１によって特定される代替ディスプレイのフレームバッファから読まれる。ビット０が値１（論理１）に等しい場合、ピクセルデータは、主ディスプレイのフレームバッファから読まれる。

１つの実施形態では、デイスプレイデータ属性フィールドのビット２は、左目フレームバッファ又は右目フレームバッファ用のバッファが、読まれるデータのソースであるか否かを特定する。一般に、主ディスプレイがステレオイメージをサポートする場合、ビット２のみが適応する。ビット２が０（論理ゼロレベル）に等しい場合、左目フレームバッファがデータソースであるが、ビット２が１（論理１レベル）に等しい場合、右目フレームバッファがデータソースである。

ディスプレイデータ属性フィールドのビット３は、該動作のためにイメージのソースが、ディスプレイをリフレッシュするために使用されるバッファであるか、あるいはオフラインイメージバッファであるかを特定する。ビット３は、代替ディスプレイがオフラインイメージバッファを用いるのであれば、代替ディスプレイにも適応する。しかしながら、イメージの宛先が、代替ディスプレイである場合には、メインイメージバッファからのソースデータをサポートしない。あるいはその逆でもよい。ビット３が値０すなわち論理ゼロレベルに等しい場合、ディスプレイをリフレッシュするために使用されるイメージバッファがデータソースである。ビット３が値１すなわち論理１レベルに等しい場合、オフラインイメージバッファがデータソースである。

ディスプレイデータ属性フィールドのビット１１乃至８は、ピクセルデータが読まれる代替クライアント位置又はディスプレイを特定する。クライアントが、ビット１１乃至８を、代替ディスプレイ数として解釈できるために、ビット０は、値０（論理ゼロ）に等しく設定される。ビット０が０に等しくないのであれば、ビット８乃至１１は一般に、論理ゼロ値またはレベルに設定される。ビット１，４乃至７，及び１２乃至１５は、将来の使用のために予約され、一般に論理ゼロレベルすなわちゼロ値に設定される。

１つの実施形態では、２バイトのＸ左端フィールド及びＹ上端フィールドは、ピクセルデータフィールドによって塗り潰されるスクリーンウィンドウの左端のＸ座標と、上端のＹ座標とを特定する。一方、Ｘ右端フィールド及びＹ下端フィールドは、更新されているウィンドウの右端のＸ座標と、下端のＹ座標とを特定する。

１つの実施形態では、２バイトのＣＲＣフィールドは、パケット長を含むパケットにおける全てのバイトのＣＲＣを特定するか、含む。

１８．ディスプレイ電力ステータスパケット
ディスプレイ電力ステータスパケットは、システムリソース上のドレイン又はシステム電力消費を最小にするために、ディスプレイのようなクライアントが使用されていないか、あるいは現在アクティブに使用されている場合に、特定のクライアント制御された、又はクライアントに関連付けられた、あるいは接続されたコントローラハードウェアを低電力状態にするための構造、手段、又は方法を提供する。この種のパケットは、外部モード設定もしくは動作のためのインタフェース又はインタフェース構造、及びプロトコルのアプリケーションのために最も役に立つ。これらアプリケーションでは、外部デバイスは、恐らくは、例えばバッテリのように制限された電力リソースで動作するか、例えば限定された空間内でのオーバヒートのようなその他の電力制約及び不安を持っている。従って、期間中、又はアクティブではない場合、若しくは非使用時には最小の動作状態が望まれる。一つの実施形態では、クライアントが、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット９を用いて、ディスプレイ電力ステータスパケットに応答する能力を示す。

図２８には、ディスプレイ電力ステータスパケットのための一つの実施形態のフォーマットが示されている。図２８に示すように、一つの実施形態では、この種のパケットは、パケット長さフィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、電力状態フィールド、及びＣＲＣフィールドを持つように構成されている。この種のパケットは一般に、２バイトタイプフィールド内のタイプ７５パケットとして識別され、８バイトからなる事前選択された固定長さを使用する。２バイトのｈＣｌｉｅｎｔＩＤフィールドは、既に述べたように、ＣｌｉｅｎｔＩＤのために予約された値又は情報を含んでいる。このフィールドは将来の使用のために予約されており、当該技術における熟練者によって、所望の情報を転送するように使用することができるが、現在は、ビットを‘０’（論理ゼロレベルまたは状態）に設定することによってゼロに設定されている。

ここでは２バイトである電力状態フィールドは、特定のデバイス、ハードウェアの一部、あるいは例えばディスプレイのようなクライアントに関連付けられた機器を、特定の電力状態にするために使用される情報を特定する。ディスプレイのために使用される場合、このフィールドのビット０は、このパケットがメインディスプレイ又は代替ディスプレイに当てはまるか否かを特定する。ビット０が１に等しい場合には、パケットはメインディスプレイに当てはまる。ビット０が０に等しい場合には、パケットは、ビット１１乃至８によって特定される代替ディスプレイに当てはまる。ビット１は、将来の使用のために予約され、一般的にはゼロに設定されている。

電力状態フィールドのビット３乃至２は、ビット１１乃至８及びビット０によって選択されたディスプレイの電力状態を特定する。ビット［３：２］が‘００’の値を持っている場合には、この状態の間、選択されたディスプレイは照明されず、最小の電力量を消費するようにされ、フレームバッファの内容の保持は保証されない。ビット［３：２］が‘０１’の値を持っている場合には、この状態の間、選択されたディスプレイは照明されず、比較的少量の電力が消費され、フレームバッファの内容の保持が保証される。ディスプレイは、この状態では、状態００よりも多くの電力を消費する。クライアントは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット１０を用いて、状態０１をサポートする能力を示すことができる。電力状態フィールドのビット［３：２］が‘１０’の値を持っている場合には、選択されたディスプレイが照明され、関連するフレームバッファからの画像を表示する。ビット［３：２］の値‘１１’は、将来の使用のために予約された値又は状態であり、使用されていない。

当該技術分野における熟練者であれば、このパケットの利用は、ディスプレイ用途に最も役立つが、本発明ではディスプレイのみに限定されず、ＭＤＤＩが使用され、クライアントが制御又は通信しているその他のハードウェア要素に関連して必要又は要求されるその他の用途、設定、又は状態が存在しうることを認識するであろう。これらの状態では、上述したビットは、類似の機能を持ちうるが、理解されるように、それら要素の第一及び第二のものを起動したり、電力レベルを設定したりしうる。

一つの実施形態では、電力状態フィールドのビット１１乃至８は、電力状態が適用される代替ディスプレイを特定する４ビット符号なし整数となる。クライアントが、ビット１１乃至８を代替ディスプレイ数と解釈するために、ビット０は、理論ゼロ値に設定される。ビット０が１に等しいのであれば、ビット１１乃至８はゼロである。

ビット７乃至４及びビット１５乃至１２は、将来の使用のために予約され、現在のアプリケーション又は設計のために一般に理論ゼロレベル又は理論ゼロ値に設定されている。

２バイトのＣＲＣフィールドは、パケット長さを含み、パケット内の全バイトのＣＲＣを特定するか、あるいは含む。

ディスプレイ電力状態が一般にインタフェース構造又はプロトコルによってサポートされている要約を、表ＶＩＩＩを示す。これを見て分かるように、クライアント特徴機能ビット１０及び９の様々な組み合わせが、所望の電力状態のうちの一つを確立、設定、又はトリガするために使用されている。所定の行及び列位置に存在する印は、その列のトップで特定されているディスプレイ電力状態が、クライアント特徴機能インジケータビットの組み合わせでサポートされていることを示す。表ＶＩＩＩの第１行及び第３行は、クライアントが、ディスプレイ電力ステータスパケットをサポートする能力を持たない場合、電力状態“１０”のみが許可されることを示していることがわかる。たとえディスプレイ電力状態が、ディスプレイに送られることがなくても、１つの印は、ディスプレイが「常にオン」状態にあり、このビットセットを用いて低電力状態に置き換わることがないことを示している。

１９．実行型ハンドオフパケット
実行型ハンドオフパケットは、ホストが、このパケットで指定されるモードにハンドオフするようにクライアントに命令するために使用する手段、構造、又は方法である。これは、クライアント機能パケットで説明したように、クライアントによってサポートされているインタフェースタイプ設定のうちの一つであるべきである。ホストとクライアントは、このパケットが送信された直後に、具体的な順方向及び逆方向リンクインタフェースタイプに切り替わるべきである。実行型ハンドオフパケットの一つの実施形態のフォーマットは図２９に示されている。タイプ１以外のインタフェースタイプをサポートするホストとクライアントとは、このパケットのためのサポートを備えるべきである。クライアントがホストと同期していることを確認するために、ホストが、実行型ハンドオフパケットを送る直前に、クライアント要求とステータスパケットとをリードすることが一般に推奨される。

図２９に示すように、一つの実施形態では、この種のパケットが、パケット長さフィールド、パケットタイプフィールド、インタフェースタイプフィールド、予約１フィールド、遅延フィラーフィールド、及びＣＲＣフィールドを持つように構成される。この種のパケットは一般に、２バイトのタイプフィールド内のタイプ７７パケットとして特定され、パケット長さフィールドと遅延フィラーフィールドの外部である６バイトの予め選択された固定長さを使用する。

一つの実施形態では、インタフェースタイプフィールドは、リンクのために使用又は適用される新たなインタフェースタイプを確認するために、１バイト値を使用する。このフィールドにおける値は、以下に示す手法で、インタフェースタイプを特定又は表示する。ビット２乃至０は順方向リンクで使用されるインタフェースタイプを定義する。ここで、値１はタイプ１モードへの、値２はタイプ２モードへの、値３はタイプ３モードへの、値４はタイプ４モードへのハンドオフをそれぞれ意味又は特定する。ビット５乃至３は、逆方向リンクで使用されるインタフェースタイプを定義し、値１はタイプ１モードへの、値２はタイプ２モードへの、値３はタイプ３モードへの、値４はタイプ４モードへのハンドオフをそれぞれ意味又は特定する。ビット０，５，７は現在、将来の使用のために予約されている。

遅延フィラーは、クライアントが、システムの一部に、実行インタフェースタイプハンドオフパケットのすぐ後に続くパケットの始めに設定する新たなインタフェースタイプを用いるための使用又は設定のために切り換えられるように準備又は設定するための十分な時間を与える手段、構造、又は方法として生成された。このフィールドは、全てが論理ゼロレベルに設定されているか、論理ゼロ値に等しく設定されている８ビット値又はビットグループを含む。このフィールドで使用されているバイト数は、６４ＭＤＤＩ＿Ｓｔｂサイクルに等しい長さであるフィールドになるように選択される。遅延フィラーフィールドの長さは、タイプ１順方向リンクインタフェースタイプの場合には１６バイト、タイプ２インタフェースの場合には３２バイト、タイプ３インタフェースの場合には６４バイト、タイプ４順方向リンクインタフェースタイプを特定又は使用している場合には１２８バイトである順方向リンクのインタフェースタイプ設定に基づいている。

予約１フィールド（ここでは１バイト）は、情報を伝える場合の将来の使用のために予約されている。このフィールド内の全てのビットは、一般に論理ゼロレベルに設定されている。このようなフィールドの目的は、今のところ、次に続く全ての２バイトフィールドを、１６ビットワードアドレスにそろえさせ、４バイトフィールドを、３２ビットワードアドレスにそろえさせることである。ＣＲＣフィールド（ここでは２バイト）は、パケット長さを含むパケット内の全てのバイトの１６ビットＣＲＣを含む。

２０．順方向音声チャネルイネーブルパケット
このパケットは、ホストがクライアントの音声チャネルをイネーブル又はディスエーブルできるようにする構造、方法、又は手段を提供する。この機能は、クライアント（例えばディスプレイ）が、ホストによって出力される音声がないときに節電するために音声増幅器又は類似する回路要素の電源を切ることができる。これは、単にインジケータとして音声ストリームの存在又は不在を使用して暗示的に実現するのはかなり困難である。クライアントシステムの電源投入時のデフォルト状態は、すべての音声チャネルがイネーブルされることである。順方向音声チャネルイネーブルパケットの一つの実施形態のフォーマットは図３０に示されている。図３０に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、音声チャネルイネーブルマスクフィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、１バイト型フィールドでパケットタイプ７８として識別され、４バイトという事前に選択された固定長を使用する。

２１．逆方向音声サンプルレートパケット
この種のパケットは、ホストが、クライアント内の音声チャネルをイネーブル又はディセーブルすることを可能にする構造、方法、及び手段を提供する。この機能は有用であり、クライアントは、ホストによって出力される音声が存在しない場合には、電力を節約するために、音声アンプの電源をオフにすることができる。音声ストリームの存在又は不在を用いて絶対的に実行するのは非常に難しい。クライアントシステムの電源がオンされたか、あるいはホストに接続された場合であるデフォルト状態は、全ての音声チャネルがイネーブルされている。ホスト及びクライアントに接続された音声システムは、０から１へ状態又は値を遷移した音声チャネルイネーブルマスクフィールド内のビットのうちの少なくとも一つを持つ順方向音声チャネルイネーブルパケットをクライアントが受け取った後、約１００ミリ秒かそれ以内のうちに、意図した方法、あるいは所望の方法で音声信号の出力を準備するか、あるいは出力できなくてはならない。クライアントは、クライアント機能パケットの音声チャネル機能フィールドのビット１５に設定された値を用いて順方向音声チャネルイネーブルパケットへ応答する能力を示す。

このパケットは、ホストが、逆方向リンク音声チャネルをイネーブル又はディスエーブルし、このストリームの音声データサンプルを設定できるようにする。ホストはクライアント機能パケットの中で有効であると定義されるサンプルレートを選択する。ホストが無効なサンプルレートを選択すると、クライアントはホストに音声ストリームを送信せず、適切なエラー、エラー値、又はエラー信号がクライアントエラーレポートパケットでホストに送信されてよい。ホストはサンプルレートを２５５という値に設定することによって逆方向リンク音声ストリームをディスエーブルしてよい。クライアントシステムが最初に電源を入れられる、あるいは接続されるときに想定されるデフォルトの状態は、逆方向リンク音声ストリームがディスエーブルされている状態である。逆方向音声サンプルレートパケットの一つの実施形態のフォーマットは、図３１に示されている。図３１に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、音声サンプルレートフィールド、予約１フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常パケットタイプ７９として識別され、４バイトという事前に選択された固定バイトを使用する。

２２．デジタルコンテンツ保護オーバヘッドパケット
このパケットは、ホストとクライアントが使用されているデジタルコンテンツ保護方法に関してメッセージを交換できるようにする構造、方法、又は手段を提供する。現在、デジタル伝送コンテンツ保護（ＤＴＣＰ）又は高帯域幅デジタルコンテンツ保護システム（ＨＤＣＰ）という、将来の代替保護方式名称のために空間が予約される、二種類のコンテンツ保護が熟考されている。使用されている方法はこのパケットのコンテンツ保護タイプパラメータによって指定される。デジタルコンテンツ保護オーバヘッドパケットの一つの実施形態のフォーマットは図３２に示されている。図３２に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、コンテンツ保護タイプフィールド、コンテンツ保護オーバヘッドメッセージフィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは通常パケットタイプ８０として識別されている。

２３．透明色イネーブルパケット
透明色イネーブルパケットは、どの色がディスプレイで透明であるのかを指定するため、及び画像を表示するために透明色の使用をディスエーブルするために使用される構造、方法、又は手段である。１つの実施形態では、この機能を有するクライアント又はディスプレイは、クライアント機能パケットのクライアント特徴機能フィールドの４でその機能を報告する。透明色の値が付いたピクセルがビットマップに書き込まれると、色は過去の値から変化しない。透明色イネーブルパケットのフォーマットは図３３に示されている。図３３に示されているように、一つの実施形態では、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ディスプレイデータ属性フィールド、予約１フィールド、データフォーマット記述子フィールド、透明色値フィールド、透明マスク値フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、１バイト型フィールドでパケットタイプ８１として識別され、事前に選択される１６バイトという固定長を使用する。

ｈＣｌｉｎｅｔＩＤフィールドは、将来実施されるＣｌｉｅｎｔＩＤとして使用のために予約され、一般にゼロ値（論理ゼロビット）に設定されている。

１つの実施形態では、２バイトのディスプレイデータ属性フィールドは、透明ピクセル色が当てはまるところを特定する値を有している。ここでは、ビット０が、透明ピクセル色が適用されるディスプレイを選択する。ビット０が値０（論理ゼロ）に等しい場合、透明ピクセル色が、ビット８乃至１１によって特定される代替ディスプレイに適用される。ビット０が値１（論理１）に等しい場合、透明ピクセル色が主ディスプレイに提供される。

１つの実施形態では、ビット１が、透明色フィールド又はマスクフィールドが透明色又は透明マスクを含んでいるかを選択又は特定する。ビット０がゼロ（論理ゼロ）に等しい場合、透明色フィールド又はマスクフィールドは、次のラスタ動作で、あるいはビデオストリームパケット又はスケーリングビデオストリームパケットを復号する場合に使用される透明色値を含んでいる。ビット０が１（論理１）に等しい場合、透明色フィールド又はマスクフィールドは、次のラスタ動作で、あるいはビデオストリームパケット又はスケーリングビデオストリームパケットを復号する場合に使用される透明マスク値を含んでいる。

ディスプレイデータ属性フィールドのビット１１乃至８は、透明ピクセル色が適用されるディスプレイ又は代替クライアント位置を特定する。クライアントが、ビット１１乃至８を、代替ディスプレイ数と解釈するために、ビット０が値０（論理ゼロ）に等しく設定される。ビット０が０に等しくない場合、ビット８乃至１１は一般に論理ゼロ値又はレベルに等しく設定され、無視される。

ディスプレイデータ属性フィールドのビット７乃至２、及びビット１５乃至１２は、将来の使用のために予約され、一般に、論理ゼロレベル又はゼロ値に設定される。

２バイトからなる予約１フィールドは、将来の使用のために予約される。このフィールドの全てのビットは、一般に、ゼロ（論理ゼロレベル又は状態）に設定される。１つの実施形態では、このフィールドの１つの目的は、次に続く２バイトフィールドが全て１６ビットワードアドレスに整列され、４バイトフィールドが３２ビットワードアドレスに整列される。

１つの実施形態では、透明色イネーブルパケットのビデオデータフォーマット記述子フィールドが２バイトを使用して、透明色値のフォーマットを特定する。図１１は、ビデオデータフォーマット記述子がどのように符号化されるかを示す。このフォーマットは一般に、ビデオストリームパケット内の同じフィールドと同じである。

１つの実施形態では、透明色値フィールドが、次のラスタ動作において、あるいはビデオストリームパケット又はスケーリングビデオストリームパケットを復号する場合に、透明色の値として使用されるピクセル値のための幾つかのバイト（この例では、パケット長として指定され、値のないフィールドのためであって、透明マスクフィールドと共有するために２で割られた１２）を特定又は割り当てるために使用される。値のフォーマットは、ビデオデータフォーマット記述子フィールドにおいて特定される。透明色のためのピクセルフォーマットの例は、前に示したものと同じである。Ｙ Ｃｂ Ｃｒフォーマットが選択された場合、透明色及び透明マスクは一般に、前に示したように、ピクセル１及び２ Ｃｂ、ピクセル１Ｙ、ピクセル１及び２ Ｃｒ、及びピクセル２Ｙのためのサブフィールドを正確に含む。透明色値のために割り当てられたバイト数は、ビデオデータフォーマット記述子フィールドによって決定される。

１つの実施形態では、透明マスク値フィールドが、次のラスタ動作において、あるいはビデオストリームパケット又はスケーリングビデオストリームパケットを復号する場合に、透明マスクとして使用されるピクセル値のための幾つかのバイト（この例では、パケット長として指定され、値のないフィールドのためであって、透明マスクフィールドと共有するために２で割られた１２）を特定又は割り当てるために使用される。この値のフォーマットは、ビデオデータフォーマット識別子フィールドにおいて特定される透明色値のフォーマットと同一である。このフィールドに割り当てられるバイト数は、ビデオデータフォーマット記述子フィールドによって決定される。このフィールドの長さは、透明色値フィールドの長さと同じである。

１つの実施形態では、透明色フィールド又はマスク値フィールドは、ディスプレイデータ属性フィールドのビット１によって特定される透明色あるいは透明マスクのうちの何れかの値として使用されるピクセル値のために、４バイトを使用又は割り当てる。このピクセルのフォーマットは、ビデオデータフォーマット識別子フィールドにおいて特定される。

ＣＲＣフィールドは、２バイトを用いて、パケット長を含むパケットにおける全てのバイトのＣＲＣを含むか、あるいは表す。

２４．往復遅延測定パケット
往復遅延測定パケットは、クライアント（ディスプレイ）からホストへ戻る遅延を加えた、ホストからクライアント（ディスプレイ）への伝搬遅延を測定するために使用される構造、方法、又は手段を提供する。この測定は、本来、ラインドライバとラインレシーバ、及び相互接続サブシステムに存在する遅延を含む。測定は、方向転換遅延と逆方向リンク速度除数パラメータを、通常前記に説明される逆方向リンクカプセル化パケットに設定するために使用される。このパケットは、ＭＤＤＩリンクが特定の応用例に意図された最大速度で運転しているときに最も有効である。パケットは、往復遅延測定の範囲を増加するために、１型モードで、低いデータレート送信される。ＭＤＤＩ＿Ｓｔｂ信号は、あたかも全ゼロデータが以下のフィールドの間に送信されているかのように動作する。つまり両方のガード時間、全ゼロ、及び測定期間である。これによりＭＤＤＩ＿Ｓｔｂは、それが測定期間中にクライアント内の周期クロックとして使用できるようにデータレートの半分でトグルする。

一実施形態では、クライアントは、通常、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット１８を使用することにより往復遅延測定パケットをサポートする能力を示す。すべてのクライアントが往復遅延測定をサポートすることが薦められるが、ホストは最大ケーブル遅延に基づいて、及び最大ドライバと受信機遅延に基づいて最悪のケースの往復遅延を知ることが可能である。これはインタフェースが使用されている装置の公知の設計要素（銅線長、回路網種類、及び特徴等）の一態様であるため、ホストは、内部モードで使用されるＭＤＤＩリンクに先行して往復遅延を知る可能性もある。

往復遅延測定パケットのフォーマットは図３４に示されている。図３４に示されているように、一実施形態では、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、パラメータＣＲＣフィールド、ガード時間１フィールド、測定期間フィールド、全ゼロフィールド、及びガード時間２フィールドを有するように構成されている。この種のパケットは、通常パケットタイプ８２として識別され、２００ビットという事前に選択された固定長を使用する。

往復遅延測定パケットの間に発生するイベントのタイミングは図３５に示されている。図３５では、ホストは、全ゼロフィールドとガード時間１フィールドが後に続くパラメータＣＲＣフィールドとストローブ位置合わせフィールドの存在によって示される往復遅延測定パケットを送信する。パケットがクライアントディスプレイ装置又は処理回路網に達する前に遅延３５０２が発生する。クライアントがパケットを受信すると、それはクライアントにより決定されるような測定期間の始まりにできる限り正確に、０ｘｆｆ、０ｘｆｆ及び０ｘ０パターンの３０バイトを送信する。クライアントがこのシーケンスの送信を開始する実際の時間は、ホストの観点では測定期間の始まりから遅延している。この遅延の量が実質的に、パケットがラインドライバとレシーバを通して伝搬し、サブシステム（ケーブル、導線）を相互接続するために要する時間である。類似する遅延の量３５０４が、パターンがクライアントからホストに伝搬して戻るパターンについて発生する。

クライアントに、及びクライアントから行き来する信号のために往復遅延時間を正確に決定するために、ホストは、測定期間の開始後、０ｘｆｆ、０ｘｆｆ、及び３０バイトの０ｘ０シーケンスの始まりが到着時に検出されるまでに発生する順方向リンクビット時間期間の数をカウントする。この情報は、往復遅延信号がホストからクライアント、及び再び逆に通過する時間量を求めるために使用される。２乃至４型の逆方向リンク又はモードが使用されている場合、ホストは、データレート及び往復遅延歪みが、各ビットの到着時間に対して別々に影響を与えるのに十分である場合には、全てのＭＤＤＩ＿Ｄａｔａペアの往復遅延値を測定し保存する。

ホストとクライアントの両方とも、ＭＤＤＩ＿ＤＡＴＡラインを定められた状態に保つために、両方のガード時間中にラインを論理ゼロレベルに駆動する。両方のガード時間中におけるホストとクライアントのイネーブル時間及びディスエーブル時間が、ＭＤＤＩ＿Ｄａｔａ信号が、あらゆる有効な往復遅延時間に対して有効な低レベルにあるようにされる。

ホスト及びクライアントは共に、ガード時間中に、ラインを論理ゼロレベルに駆動し、ＭＤＤＩ＿Ｄａｔａラインを、定義された状態に保つ。両方のガード時間中におけるホストとクライアントのイネーブル時間及びディスエーブル時間が、ＭＤＤＩ＿Ｄａｔａ信号が、あらゆる有効な往復遅延時間に対して有効な低レベルにあるようにされる。

２５．順方向リンク歪み校正パケット
１つの実施形態では、順方向リンク歪み校正パケットは、クライアント又はディスプレイがＭＤＤＩ＿Ｓｔｂ信号に関してＭＤＤＩ＿Ｄａｔａ信号の伝搬遅延での差異がないかそれ自体を校正できるようにする。遅延歪み補償を行わないと、最大データレートは通常これらの遅延の潜在的な最悪のケースの変動を考慮に入れるために制限される。通常、このパケットは、順方向リンクデータが約５０Ｍｂｐｓ以下の速度に構成されるときにだけ送信される。ディスプレイを校正するためにこのパケットを送信した後に、データレートは５０Ｍｂｐｓを超えて強化される。データレートが歪み補償プロセスの間に高く設定しすぎると、ディスプレイは、遅延歪み補償設定値を１ビットを超える時間オフにし、その結果誤ったデータクロッキングを生じさせる結果となる、ビット期間のエイリアスに同期する可能性がある。最高データレートタイプのインタフェース又は最大可能インタフェースタイプは、すべての既存のデータビットが校正されるように、順方向リンク歪み校正パケットを送信する前に選択される。クライアントは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット１９を用いて、順方向リンク歪み校正パケットをサポートする能力を示す。

歪み校正を実行する前に、ホストは、クライアント機能パケットの校正前データレート機能フィールドによって特定されるレートよりも速くデータを送るべきではない。しかしながら、校正が促進された後、ホストは、校正後データレート機能フィールドによって定義されるレートまでデータを送るかもしれない。ホストが、規則的な間隔で順方向リンク歪み校正パケットを送り、温度変化による異なる信号ペア間の相対的な遅れにおける変化を補正することが推奨される。

順方向リンク歪み校正パケットのフォーマットの一つの実施形態は図５６に示されている。図５６に示されているように、この種のパケットはパケット長（２バイト）フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、パラメータＣＲＣフィールド、全ゼロ１フィールド、校正データシーケンスフィールド及び全ゼロ２フィールドを有するように構造化されている。この種のパケットは通常、タイプフィールドでタイプ８３として識別される。

仮想制御パネル
仮想制御パネル（ＶＣＰ）を使用すると、ホストはクライアントで特定のユーザ制御を設定できる。これらのパラメータをホストにより調整できるようにすることによって、クライアントのユーザインタフェースは、ユーザが音声音量又はディスプレイ明度等のパラメータを調整できるようにする画面がクライアント内の１台又は複数台のマイクロプロセッサによってよりむしろホストソフトウェアによって生成できるために簡略化できる。ホストは、クライアントのパラメータ設定値を読み取り、制御ごとの有効値の範囲を求める能力を有する。クライアントは、一般に、どの制御パラメータを調整できるのかをホストに報告する能力を有する。

制御コード（ＶＣＰコード）及び一般的に指定される関連データ値は、クライアントの制御と設定値を指定するために活用される。ＭＤＤＩ指定のＶＣＰコードはパケット定義における適切なデータフィールド位置合わせを保存するために、及び将来、このインタフェースに、又は将来の機能強化に一意である補足値をサポートするために１６ビットに拡大される。

２６．ＶＣＰ特徴要求パケット
ＶＣＰ特徴要求パケットは、ホストが特定の制御パラメータ又はすべての有効な制御パラメータの現在の設定値を要求するための手段、機構又は方法を提供する。一般的には、クライアントはＶＣＰ特徴応答パケットで適切な情報でＶＣＰパケットに応答する。一実施形態では、クライアントはクライアント機能パケットのクライアント特徴機能インジケータのビット１３を使用してＶＣＰ特徴要求パケットをサポートする能力を示す。

ＶＣＰ特徴要求パケットのフォーマットは図６９に示されている。図６９で見られるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ディスプレイセレクタフィールド、モニタ制御コマンドセット（ＭＣＣＳ）ＶＣＰコードフィールド及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、２バイト型フィールドに示されているタイプ１２８として一実施形態で識別される。パケット長フィールドを含まないパケット内のビットの総数を指定するパケット長は、通常、１０ビットという長さでこの種のパケットに固定されている。

ｈＣｌｉｅｎｔＩＤフィールドは、将来の実施においてクライアントＩＤとして使用するために予約され、一般にゼロに設定される。

１つの実施形態では、ＶＣＰ特徴応答パケットが、ＶＣＰパケットを適用するディスプレイを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットが適合するディスプレイを選択する。ビット０が、０に等しい場合、ＶＣＰパケットは、ビット１１乃至８によって特定される代替ディスプレイに適合する。一方、ビット０が１、論理１レベルに等しい場合には、ＶＣＰパケットは、主ディスプレイに適合する。現在、ディスプレイセレクタフィールドのビット７乃至１が将来の使用のために予約され、一般に、ゼロ値に設定されている。すなわち、ビットは論理ゼロレベルに設定されている。

ディスプレイセレクタフィールドのビット１１乃至８は、４ビットの無符号整数値を用いて、ＶＣＰパケットが適合する代替ディスプレイを特定する。ディスプレイセレクタフィールドのビット０が、０（論理ゼロレベル）に等しい場合、クライアントは、ビット１１乃至８を代替ディスプレイ数として解釈する。ビット０が０に等しくない場合、ビット１１乃至８はゼロに設定され、無視される。ビット１５乃至１２は、将来の使用のために予約され、一般にゼロ値に設定される。すなわち、各ビットが論理ゼロレベルに設定される。

１つの実施形態では、ＭＣＣＳ ＶＣＰコードフィールドは、ＭＣＣＳ ＶＣＰ制御コードパラメータを特定する情報からなる２バイトを備えている。０から２５５の範囲の値は、ＶＣＰ特徴応答パケットが、特定されたＭＣＣＳコードに対応するＶＣＰ特徴応答リスト内の単一の項目とともに戻るようにする。６５５３５（０ｘｆｆｆｆ）からなるＭＣＣＳ ＶＣＰコードは、クライアントによってサポートされる各制御のための特徴応答リスト項目を含むＶＣＰ特徴応答リストを備えたＶＣＰ特徴応答パケットを必要とする。このフィールドの場合、２５６乃至６５５３４の値は、将来の使用のために予約され、現在は使用されていない。

２バイトのＣＲＣフィールドは、パケット長を含むパケット内の全バイトのＣＲＣを含む。

２７．ＶＣＰ特徴応答パケット
ＶＣＰ特徴応答パケットは、クライアントが特定の制御パラメータ又はすべての制御パラメータの現在の設定値でホスト要求に応えるための手段、機構又は方法を提供する。一般的には、クライアントはＶＣＰ特徴要求パケットに応えてＶＣＰ特徴応答パケットを送信する。このパケットは、特定のパラメータの現在設定値を突き止め、特定の制御のための有効な範囲を決定し、特定の制御がクライアントによってサポートされているかどうかを判断し、あるいはクライアントによってサポートされている制御のセットを決定するために有効である。クライアント内で実現されない特定の制御を参照するＶＣＰ特徴要求が送信される場合、ＶＣＰ特徴応答パケットは適切なエラーコードを含む実現されていない制御に対応する単一ＶＣＰ特徴応答リストアイテムと共に返される。一実施形態では、クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット１３を使用してＶＣＰ特徴応答パケットをサポートする能力を示す。

一実施形態でのＶＣＰ特徴応答パケットのフォーマットは図７０に示されている。図７０で分かるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、ディスプレイセレクタフィールド、ＭＣＣＳバージョンフィールド、応答シーケンス番号フィールド、ＶＣＰ特徴応答リストフィールド、及びＣＲＣフィールドを有するように構造化されている。通常一実施形態では、この種のパケットは、２バイト型フィールドに示されるようにタイプ１２９として識別される。

ｃＣｌｉｅｎｔＩＤフィールドはクライアントＩＤに予約される情報を含む。このフィールドは将来の使用のために予約され、通常はゼロに設定されている。

１つの実施形態では、ＶＣＰ特徴応答パケットにおける２バイトのディスプレイセレクタフィールドが、ＶＣＰパケットを適用するディスプレイを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットを適用するディスプレイを選択する。ビット０が０に等しい場合、ＶＣＰパケットは、ビット１１乃至８によって特定される代替ディスプレイに適合する。一方、ビット０が１、ロジック１レベルに等しい場合、ＶＣＰパケットは、主ディスプレイに適合する。現在、ディスプレイセレクタフィールドのビット７乃至１は、将来の使用のために予約され、一般に、ゼロ値に設定される。すなわち、各ビットが論理ゼロレベルに設定される。

ディスプレイセレクタフィールドのビット１１乃至８は、４ビットの無符号整数値を用いて、ＶＣＰパケットが適合する代替ディスプレイを特定する。ディスプレイセレクタフィールドのビット０が０（論理ゼロレベル）に等しい場合、クライアントは、ビット１１乃至８を、代替ディスプレイ数として解釈する。ビット０が０に等しくない場合、ビット１１乃至８は、零に設定され、無視される。ビット１５乃至１２は、将来の使用のために予約され、一般に零値に設定される。すなわち、各ビットは論理ゼロレベルに設定される。

ＭＣＣＳバージョンフィールドは、クライアントによって実現されるＶＥＳＡ ＭＣＣＳ仕様のバージョンを指定する２バイトの情報を含む。

２バイトの応答シーケンス番号フィールドは、クライアントによって返されるＶＣＰ特徴応答パケットのシーケンス番号を指定する情報又はデータを含む。クライアントは６５５３５というＭＣＣＳ制御コード値と共に、ＶＣＰ特徴要求パケットに応えて１つ又は複数のＶＣＰ特徴応答パケットを返す。クライアントは複数のＶＣＰ特徴応答パケットによって特徴応答リストを拡散又は転送してよい。この場合、クライアントは各連続パケットにシーケンス番号又は識別子を割り当てるべきである。そして、単一のＶＣＰ特徴要求パケットに応えて送信されるＶＣＰ特徴応答パケットのシーケンス番号は一般にゼロで開始し、１つずつ増分する。最後のＶＣＰ特徴応答パケット内のＶＣＰ特徴リストアイテムはパケットが最後のパケットであることを識別するために０ｘｆｆｆｆに等しいＭＣＣＳ ＶＣＰ制御コード値を含まなければならず、返されるパケットのグループの最高のシーケンス番号を含む。ただ１つのＶＣＰ特徴応答パケットがＶＣＰ特徴要求パケットに応えて送信される場合、その単一のパケット内の応答シーケンス番号は一般にゼロに設定され、ＶＣＰ特徴応答リストは、０ｘｆｆｆｆに等しいＶＣＰ特徴応答リストアイテム内のＭＣＣＳ ＶＣＰコードを有するリストアイテムを含む。ＶＣＰ特徴応答リストアイテムパケット内の最大値フィールド及び現在値フィールド（図７１）は、ＭＣＣＳ ＶＣＰ制御コードが０ｘｆｆｆｆに等しい場合、ゼロに設定される。

ＶＣＰ特徴応答リストフィールドは１つ又は複数のＶＣＰ特徴応答リストアイテムを含むバイトのグループである一方、リストフィールド内の特徴の数は、このパケットの中のＶＣＰ特徴応答リスト内にあるＶＣＰ特徴応答リストアイテム数を指定する２バイトを含む。一実施形態での単一のＶＣＰ特徴応答リストアイテムのフォーマットは図７１に示される。

図７１に示されているように、各ＶＣＰ特徴応答リストアイテムは長さが正確に１２バイトであり、ＭＣＣＳ ＶＣＰコードフィールド、結果コードフィールド、最大値フィールド及び現在値フィールドを備える。２バイトのＭＣＣＳ ＶＣＰ制御フィールドはこのリストアイテムと関連付けられるＭＣＣＳ ＶＣＰ制御コードパラメータを指定するデータ又は情報を含む。この実施形態では、ＶＥＳＡ ＭＣＣＳ仕様書バージョン２以降に定められる制御コード値だけが有効と見なされる。２バイト結果コードフィールドは指定されたＭＣＣＳ ＶＣＰ制御に関して情報の要求に関係するエラーコードを指定する情報を含む。「１」という値が、指定された制御がクライアントで実現されないことを意味する一方、このフィールドの「０」という値はエラーがないことを意味する。２から６５５３５のこのフィールドの追加の値は、将来の使用及び技術によって考慮される他の応用例のインプリメンテーションのために現在予約されているが、当面使用されることはない。

４バイトの最大値フィールドは、指定されたＭＣＣＳ制御を設定できる最大可能値を指定する。要求される制御がクライアントの中で実現されない場合、この値はゼロに設定される。返された値の長さが３２ビット（４バイト）未満である場合は、値は３２ビット整数の中に入れられ、最上位（未使用）バイトをゼロに設定されたままにする。４バイトの現在値提示フィールドは、指定されたＭＣＣＳ ＶＣＰ連続（Ｃ）又は非連続（ＮＣ）制御の現在値を指定する情報を含む。要求された制御がクライアントで実現されない場合、あるいは制御が実現されるが、テーブル（Ｔ）データ型である場合には、この値はゼロに設定される。指定されたＭＣＣＳ ＶＣＰが、不連続制御又はテーブルデータ型式に対応している場合、この最大値フィールドは、ゼロに設定又は選択される。

２８．ＶＣＰ特徴設定パケット
ＶＣＰ特徴設定パケットは、ホストがクライアント内での連続制御と非連続制御の両方にＶＣＰ制御値を設定するための手段、機構又は方法を提供する。一実施形態では、クライアントはクライアント機能パケットのクライアント特徴機能フィールドのビット１３を使用してＶＣＰ特徴設定パケットをサポートする能力を示す。

一実施形態におけるＶＣＰ特徴設定パケットのフォーマットは図７２に示されている。図７２で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ディスプレイセレクタフィールド、ＭＣＣＳ ＶＣＰコードフィールド、リスト中の値数フィールド、制御値リストフィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、２バイト型フィールドで示されるようにタイプ１３０として識別され、パケット長フィールドを除き２０バイトの長さである。

１つの実施形態では、ｈＣｌｉｅｎｔＩＤフィールドは、再びクライアントＩＤとして指定するために、あるいはＣｌｉｅｎｔＩＤとして働くために２バイト値を使用する。このフィールドは将来の仕様のために予約され、現在はゼロに設定されている。

１つの実施形態では、設定されたＶＣＰ特徴パケットにおける２バイトのディスプレイセレクタフィールドが、ＶＣＰパケットをどこに適用するかを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットが適合するディスプレイを選択する。ビット０が０に等しい場合、ＶＣＰパケットは、ビット１１乃至８によって特定される代替ディスプレイに適合する。一方、ビット０が１に等しい場合、すなわち論理１レベルである場合、ＶＣＰパケットは、主ディスプレイに適合する。現在、ディスプレイセレクタフィールドのビット７乃至１は、将来の使用のために予約され、一般にゼロ値に設定されている。すなわち、ビットが論理ゼロレベルに設定されている。

ディスプレイセレクタフィールドのビット１１乃至８は、ＶＣＰパケットが適合する代替ディスプレイを特定する。ディスプレイセレクタフィールドのビット０が０（論理ゼロレベル）に等しい場合、クライアントは、ビット１１乃至８を代替ディスプレイ数として解釈する。ビット０が０に等しくない場合、ビット１１乃至８は、ゼロに設定され、無視される。ビット１５乃至１２は、将来の使用のために予約され、一般にゼロ値に設定される。すなわち、各ビットは、論理ゼロレベルに設定される。

設定されたＶＣＰ特徴パケットのためのＭＣＣＳ ＶＣＰコードフィールドは、調整されるＭＣＣＳ ＶＣＰコードパラメータを指定するための２バイトの情報、又は値を使用する。２バイトのリスト中の値数フィールドは、制御値リストに存在する１６ビット値の数を指定する情報又は値を含む。制御値リストは、ＭＣＣＳ制御コードがクライアント内のテーブルに関連しない限り通常１つのアイテムを含む。非テーブル関連制御の場合、制御値リストはＭＣＣＳ ＶＣＰコードフィールドにより指定される制御パラメータに書き込まれる新しい値を指定する値を含むであろう。テーブル関連制御の場合、制御値リスト中のデータのフォーマットは指定されたＭＣＣＳ ＶＣＰコードのパラメータ説明によって指定される。リストが１バイトより大きい値を含む場合には、どこか他の箇所に定義される方法に一貫して最下位ビットが最初に送信される。最後に２バイトのＣＲＣフィールドが、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

２９．有効パラメータ要求パケット
有効パラメータ要求パケットは、クライアントが指定された非連続（ＮＣ）又は表（Ｔ）制御によってサポートされているパラメータのリストを含む有効パラメータ応答パケットを返すことを要求するために役立つ手段又は構造として使用される。このパケットは、非連続（ＮＣ）制御又はクライアントの表に関連する制御だけを指定しなければならず、すべての制御を指定するために６５５３５（０ｘｆｆｆｆ）というＭＣＣＳ ＶＣＰコード値を指定してはならない。サポートされていない、又は無効のＭＣＣＳ ＶＣＰコードが指定される場合には、適切なエラー値が有効パラメータ応答パケットで返される。一実施形態では、クライアントは表示機能パケットのクライアント特徴機能フィールドのビット１３を使用して有効パラメータ要求パケットをサポートする能力を示す。

一実施形態における有効パラメータ要求パケットのフォーマットは図７３に示されている。図７３に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ディスプレイセレクタフィールド、ＭＣＣＳ ＶＣＰコードフィールド及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、２倍と型フィールドに示されているように、通常タイプ１３１として１つの実施形態で識別されている。

２バイトのパケット長フィールドに示されているようにパケット長は、通常、８というパケット長フィールドを含まずにパケット内のバイトの総数を有するために設定される。ｈＣｌｉｅｎｔＩＤは再びクライアントＩＤを指定するが、当業者に明らかとなるように現在は将来の使用のために予約されており、ゼロ値または論理ゼロレベルに設定されている。

１つの実施形態では、要求有効パラメータパケットにおける２バイトのディスプレイセレクタフィールドは、ＶＣＰパケットをどこに適用するかを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットが適合するディスプレイを選択する。ビット０が０に等しい場合、ＶＣＰパケットは、ビット１１乃至８によって特定される代替ディスプレイに適用する。一方、ビット０が１、すなわち論理１レベルに等しい場合、ＶＣＰパケットは主ディスプレイに適合する。現在、ディスプレイセレクタフィールドのビット７乃至１は、将来の使用のために予約され、一般にゼロ値に等しく設定されている。すなわち、ビットが論理ゼロレベルに設定される。

ディスプレイセレクタフィールドのビット１１乃至８は、ＶＣＰパケットが適合する代替ディスプレイを特定する。ディスプレイセレクタフィールドのビット０が０（論理ゼロレベル）に等しい場合、クライアントは、ビット１１乃至８を、代替ディスプレイ数として解釈する。ビット０が０に等しくない場合には、ビット１１乃至８は、ゼロに設定され、無視される。ビット１５乃至１２は将来の使用のために予約され、一般に、ゼロ値に設定される。すなわち、各ビットは論理ゼロレベルに設定される。

要求有効パラメータパケットの２バイトのＭＣＣＳ ＶＣＰコードフィールドは、照会される非連続ＭＣＣＳ ＶＣＰ制御コードパラメータを指定する値を含む。このフィールドの値は、クライアントで実現される非連続制御に相当すべきである。値２５６乃至６５５３５（０ｘｆｆｆｆ）は通常、予約されるか、あるいは無効と見なされ、エラー応答の中で実現されない制御として見なされている。ここで２バイトであるＣＲＣフィールドは、パケット長を含むパケット内の全てのバイトのＣＲＣを含む。

３０．有効パラメータ応答パケット
有効パラメータ応答パケットは、有効パラメータ要求パケットに応えて送信される。それは、非連続ＭＣＣＳ ＶＣＰ制御又は表のコンテンツを返す制御のための有効な設定値を識別するための手段、方法又は構造として使用される。制御がクライアント内の表に関する場合、ＶＣＰパラメータ応答リストは単に要求された順次表値の特定なリストを含むだけである。表のコンテンツが単一の有効パラメータ応答パケットに適合しない場合、順次応答シーケンス番号の付いた複数のパケットがクライアントによって送信できる。一実施形態では、クライアントはクライアント機能パケットのクライアント特徴機能フィールドのビット１３を使用して有効パラメータ応答パケットをサポートする能力を示す。

ホストは、次のようにテーブルのコンテンツを要求してよい。ホストは、読み取り／書き込みパラメータ、ルックアップテーブル（ＬＵＴ）オフセット、及びＲＧＢ選択等の必要な又は所望されるパラメータを含むＶＣＰ特徴設定パケット設定を送信する。それから所望される制御を指定する有効パラメータ要求パケットがホストによって送信され、次にクライアントが、表データを含む１つ又は複数の有効パラメータ応答パケットを返す。動作のこのシーケンスがＭＣＣＳ動作モデルに説明される表読み取り機能として類似する機能を実行する。

特定のクライアントパラメータがクライアントによってサポートされていない場合には、一実施形態においてこのパケットの対応するフィールドは２５５という値を含むであろう。クライアントで使用されるパラメータの場合、対応するフィールドはクライアント内にパラメータの値を含む必要がある。

一実施形態の有効パラメータ応答パケットのフォーマットは図７４に示されている。図７４で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、ディスプレイセレクタフィールド、ＭＣＣＳ ＶＣＰコードフィールド、応答コードフィールド、シーケンス番号応答フィールド、リスト中の番号値フィールド、ＶＣＰパラメータ応答リストフィールド及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、２バイト型フィールドに示されているようにタイプ１３２として一実施形態について識別される。

ｃＣｌｉｅｎｔＩＤフィールドは、前述の説明から公知であるように、将来のクライアントＩＤのために予約されている。

１つの実施形態では、２バイトのディスプレイセレクタフィールドは、ＶＣＰパケットをどこで適用するかに関する情報を含む。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットを適用するディスプレイを選択する。ビット０が０に等しい場合、ＶＣＰパケットは、ビット１１乃至８によって特定される代替ディスプレイに適合する。一方、ビット０が１、論理１レベルに等しい場合、ＶＣＰパケットは、主ディスプレイに適合する。現在、ディスプレイセレクタフィールドのビット７乃至１は、将来の使用のために予約されており、一般にはゼロ値に等しく設定されている。すなわち、ビットは論理ゼロレベルに設定されている。

ディスプレイセレクタフィールドのビット１１乃至８は、ＶＣＰパケットが適合する代替ディスプレイを特定する。ビット０が０（論理ゼロレベル）に等しい場合、クライアントは、ビット１１乃至８を、代替ディスプレイ数として解釈する。ビット０が０に等しい場合、ビット１１乃至８はゼロに設定され、無視される。ビット１５乃至１２は、将来の使用のために予約され、一般にゼロ値に設定されている。すなわち、各ビットは論理ゼロレベルに設定される。

１つの実施形態では、３バイトのＭＣＣＳ ＶＣＰコードパケットは、このパケットによって記述される不連続なＭＣＣＳ ＶＣＰ制御コードパラメータを特定する値を含む。無効なＭＣＣＳ ＶＣＰ制御コードが要求有効パラメータパケットによって特定される場合、同じく無効なパラメータ値が、応答コードフィールド内の適切な値を持つこのフィールドにおいて特定される。ＭＣＣＳ制御コードが無効である場合、ＶＣＰパラメータ応答リストはゼロ長さを持つであろう。 応答コードフィールドは、指定されたＭＣＣＳ ＶＣＰ制御に関する情報に対する要求に関連する応答の性質を指定する２バイトの情報又は値を含む。このフィールドの値が０に等しい場合には、エラーはこのデータ型に存在するとは見なされず、シーケンスの中の最後の有効パラメータ応答パケットが送信され、それは最高の応答シーケンス番号を有する。このフィールドの値が１に等しい場合には、エラーは存在すると見なされないが、さらに高いシーケンス番号を有する他の有効パラメータ応答パケットが送信される。このフィールドの値が２に等しい場合には、指定された制御はクライアントで実現されると見なされない。このフィールドｉｄの値が３に等しい場合には、指定された制御は非連続制御ではない（ゼロからその最大値まですべての値の有効な集合をつねに有するのは連続制御である）。４から６５５３５に等しいこのフィールドの値は将来の使用のために予約され、通常は使用されるべきではない。

２バイト応答シーケンス番号フィールドは、クライアントによって返される有効パラメータ応答パケットのシーケンス番号を指定する。クライアントは、有効パラメータ要求パケットに応えて１つ又は複数の有効なパラメータ応答パケットを返す。クライアントは複数の有効パラメータ応答パケット上でＶＣＰパラメータ応答リストを広げてよい。この後者のケースでは、クライアントが各連続パケットにシーケンス番号を割り当て、シーケンス内の最後のパケットを除くすべてで応答コードを１に設定する。シーケンス内の最後の有効パラメータ応答パケットは最高の応答シーケンス番号を有し、応答コードは０という値を含む。

２バイトのリスト中の値の数フィールドは、ＶＣＰパラメータ応答リストに存在する１６ビット値という数を指定する。応答コードがゼロに等しくない場合には、リスト中の値の数パラメータはゼロである。ＶＣＰパラメータ応答リストフィールドはＭＣＣＳ 制御コードフィールドにより指定される非連続制御の有効な値の集合を示す０から３２７６０の２バイト値のリストを含む。非連続制御コードの定義はＶＥＳＡ ＭＣＣＳ仕様で指定される。最後に本実施形態では、ＣＲＣフィールドはパケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

スケーリングビデオストリーム画像
ＭＤＤＩ又はプロトコル機構、構造、手段、又は方法は、ホストが元の画像より大きく又は小さく拡大縮小されるクライアントに画像を送信できるようにするスケーリングビデオストリーム画像に対するサポートを提供し、スケーリングされた画像はメイン画像バッファにコピーされる。スケーリング済みのビデオストリーム機能性と関連プロトコルサポートの概要は他の箇所で示される。スケーリング済みのビデオストリームをサポートする能力は、特殊ステータス要求パケットに応えて送信されるスケーリングビデオストリーム機能によって、あるいは中で定義される。

以下に説明するスケーリングビデオストリームパケットのヘッダは、画像を表示するために必要なコンテクスト全体を含むヘッダを持つより簡素なビデオストリームパケットとは若干異なっている。このスケーリングビデオストリームパケットは、ソース及び目的ウィンドウサイズと位置を定義するセットアップパケットと、ピクセルデータを送信する別のスケーリングビデオストリームパケットとを使用する。クライアントは、セットアップパケットと、各ストリームに関連付けられたピクセルデータの一部とからのストリームパラメータを格納するために、各ストリームに関連付けられた内部記憶装置を割り当てる。各ストリームのために必要とされる記憶容量は、ソース及び目的イメージのサイズと、セットアップパケット内で特定された値に依存して変わる。この理由により、プロトコルは、クライアントが、各スケーリングビデオストリームに関連付けられた記憶装置のために、動的なメモリ割り当てを実施できるように設計される。

ビデオストリームを、プログラムソースに由来するサイズを持つディスプレイに送り、ディスプレイスケール及び位置を持つことは有用である。複数のビデオ画像のリアルタイムスケーリングの実施は、とても複雑であり、クライアントにおいて、オプションでこの特徴のサポートをすることができない。

３１．スケーリングビデオストリーム機能パケット
スケーリングビデオストリーム機能パケットはクライアントの中の、あるいはクライアントによって使用されるスケーリングビデオストリームソース画像の特性を定義する。スケーリングビデオストリーム機能パケットは、概して図７９に示されている。図７９で分かるように、一実施形態では、スケーリングビデオストリーム機能パケットはパケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、最大ストリーム数フィールド、ソース最大Ｘサイズフィールド、ソース最大Ｙサイズフィールド、ＲＧＢ機能フィールド、白黒機能フィールド、予約１フィールド、Ｙ Ｃｒ Ｃｂ機能フィールド、予約２フィールド及びＣＲＣフィールドを有するように構造化されている。一実施形態において、パケット長は、長さフィールドに示されているように、クライアントＩＤの使用のために予約され、それ以外の場合ゼロに設定される２バイトのｃＣｌｉｅｎｔＩＤフィールド、及びＣＲＣフィールドを含む固定された２０バイトとなるように選択されている。一実施形態では、クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中で１４３というパラメータ値を使用してスケーリングビデオストリーム機能パケットをサポートする能力を示す。

２バイトの最大ストリーム数フィールドは、一度に割り当てられてよい同時スケーリングビデオストリームの最大数を識別するための値を含む。一実施形態では、クライアントは、最大数のスケーリングビデオストリームがすでに割り当てられている場合、スケーリングビデオストリームを割り当てる要求を拒絶しなければならない。最大数未満のスケーリングビデオストリームが割り当てられている場合は、クライアントはクライアントにおける他のリソース制限に基づいて割り当て要求を拒否してもよい。

ソース最大ＸサイズフィールドとＹサイズフィールド（２バイト）は、多くのピクセルとして表されるスケーリングビデオストリームソース画像の、それぞれ最大幅と高さの値を指定する。

ＲＧＢ機能フィールドは、ＲＧＢフォーマットで表示できる解像度のビット数を指定するために値を使用する。スケーリングビデオストリームがＲＧＢフォーマットを使用できない場合、この値はゼロに等しく設定される。ビット５から１２は将来の機能定義で将来使用するために予約され、通常はゼロに設定されているが、ＲＧＢ機能ワードは、各ピクセルの青の最大ビット数（青輝度）を定義するビット３から０、各ピクセルの緑の最大ビット数（緑輝度）を定義するビット７から４、及び各ピクセルの赤の最大ビット数（赤輝度）を定義するビット１１から８の３つの別々の符号なし値から構成されている。

１バイトの白黒機能フィールドは、白黒フォーマットで表示できる解像度のビット数を指定する値を含む。スケーリング済みのビデオストリームが白黒フォーマットを使用できない場合、この値はゼロに設定される。ビット７から４は将来の使用のために予約されているため、当業者によって理解されるように、これは経時的に変化する可能性はあるが現在の応用例についてはゼロ（「０」）に設定されなければならない。ビット３から０は各ピクセルに存在できるグレイスケールの最大ビット数を定義する。これらの４個のビットは、各ピクセルが１から１５ビットからなることを指定できるようにする。値がゼロである場合には、白黒フォーマットはスケーリングビデオストリームによってサポートされていない。

予約１フィールド（ここでは１バイト）は、スケーリングビデオストリームパケット情報又はデータに関係する値を提供する際に将来使用するために予約されている。したがって、現在このフィールドのすべてのビットは論理「０」に設定されている。このフィールドの１つの目的は、すべての以後の２バイトフィールドを１６ビットワードアドレスに一合わせさせ、４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。

２バイトのＹ Ｃｂ Ｃｒ機能フィールドは、Ｙ Ｃｂ Ｃｒフォーマットで表示できる解像度のビット数を指定する値を含む。スケーリングビデオストリームがＹ Ｃｂ Ｃｒフォーマットを使用できない場合には、この値はゼロである。Ｙ Ｃｂ Ｃｒ機能ワードは３つの別々の符号なし値から構成されている。つまり、Ｃｒサンプルを指定するビット最大数を定義するビット３から０、Ｃｂサンプルを指定するビット最大数を定義するビット７から４、Ｙサンプルを指定するビット最大数を定義するビット１１から８である。そしてビット１５から１２は将来の使用に予約されており、通常はゼロに設定されている。

１バイトの機能ビットフィールドは、スケーリングビデオストリームと関連する機能を指定するフラグのセットを含む。フラグは以下のとおりに定義される。ビット０はスケーリングビデオストリームパケットのピクセルデータをカバーし、パックフォーマットとなることができる。パックされ、バイト位置合わせされたデータは図１３に前記に示されている。ビット１は将来の使用のために予約され、通常は、ゼロに設定される。ビット２もまた将来の使用のために予約され、ゼロに設定される。ビット３は、カラーマップデータフォーマットで指定できるスケーリングビデオストリームをカバーする。同じカラーマップテーブルが、メイン画像バッファ及びアルファ−カーソル画像平面に使用されるようにスケーリングビデオストリームに使用される。カラーマップは、他の箇所で説明されるカラーマップパケットを使用して構成されている。そしてビット７から４は将来の使用のために予約され、通常はゼロに設定されている。

予約２フィールド（ここでは１バイト）は、スケーリングビデオストリームパケット情報又はデータに関係する値を提供する上で将来の使用に予約されている。したがって、現在、このフィールドのすべての値は論理「０」に設定されている。このフィールドの１つの目的は、すべての以後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。

３２．スケーリングビデオストリームセットアップパケット
スケーリングビデオストリームセットアップパケットは、スケーリングビデオストリームのパラメータを定義するために使用される手段、構造、又は方法を提供し、クライアントは、画像のバッファリング及びスケーリングのために内部記憶域を割り当てるための情報を使用する。ストリームは、Ｘ画像サイズフィールドとＹ画像サイズフィールドがゼロに等しい状態で、このパケットを送信することによって割り当て解除されてよい。割り当て解除されたスケーリングビデオストリームは、後で、同じストリームパラメータ又は異なるストリームパラメータを用いて割り当てし直されてよい。一実施形態では、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの１４３というパラメータ値を使用して、及びスケーリングビデオストリーム機能パケットの最大ストリーム数フィールドで非ゼロ値を使用することによってスケーリングビデオストリームセットアップパケットをサポートする能力を示す。

スケーリングビデオストリームセットアップパケットのフォーマットは概して図８０に示されている。図８０で分かるように、一実施形態では、スケーリングビデオストリームセットアップパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔフィールド、ストリームＩＤフィールド、視覚データフォーマット記述子フィールド、ピクセルデータ属性フィールド、Ｘ左端縁フィールド、Ｙ上部端縁フィールド、Ｘ右端縁フィールド、Ｙ下部端縁フィールド、Ｘ画像サイズフィールド、Ｙ画像サイズフィールド、及びＣＲＣフィールドを有するように構造化されている。

２バイトのパケット長フィールドは、パケット長フィールドを含まないパケットの中のバイト総数を指定する。一実施形態では、このパケット長は２４で固定されている。２バイトのパケットタイプフィールドはパケットをスケーリングビデオストリームセットアップパケットとして識別するために１３６という値を利用する。２バイトのｈＣｌｉｅｎｔＩＤフィールドはクライアントＩＤとしての将来の使用のために予約されており、通常は当面、あるいはプロトコルユーザが、公知であるように、どのＩＤ値を使用しなければならないのか判断するまで、論理ゼロ値に全てのビットが設定される。

ストリームＩＤフィールドは、ストリームＩＤの一意の識別子を指定するために２バイトを使用する。この値はホストにより割り当てられ、ゼロから、クライアント機能パケットで指定される最大ストリームＩＤ値までの値の範囲をとる。ホストは、各アクティブストリームに一意の値が割り当てられ、もはやアクティブではないストリームが割り当て解除される、あるいは再配分されることを保証するために注意深くストリームＩＤ値の使用を管理しなければならない。

一実施形態では、ビデオデータフォーマット記述子フィールドは、本パケットの本ストリームのピクセルデータの各ピクセルのフォーマットを指定するために２バイトを使用する。ピクセルデータフォーマットは、アルファカーソル画像機能パケットで定義されうるアルファ−カーソル画像平面の有効なフォーマット、あるいは上述したその他のパケット内で一般に定義されるようなその他の予め定義したパターンのうちの少なくとも１つと準拠する必要がある。ビデオデータフォーマット記述子は、現在のパケット専用のピクセルフォーマットを定義し、一定のフォーマットがある特定のビデオストリームの存続期間中に使用し続けられることを暗示していない。図１２は、ビデオデータフォーマット記述子がどのようにコード化されるのか、他のパケットについて前述されたように実施形態を示す。

例えば、図１２Ａ乃至図１２Ｄに示すように、一つの実施形態において使用するために、ビット［１５：１３］が‘０００’に等しい場合、ビデオデータは、白黒ピクセルのアレイから構成される。ここでは、ピクセル毎に多くのビットが、ビデオデータフォーマット記述子のビット３乃至０によって定義されている。ビット１１乃至４は、一般に将来の使用またはアプリケーションのために予約されており、この場合ゼロに設定されている。一方、ビット［１５：１３］が値‘００１’に等しい場合、ビデオデータは、カラーマップ（パレット）から各々色を特定するカラーピクセルのアレイから構成される。この場合、ビデオデータフォーマット記述子のビット５乃至０は、ピクセル毎のビット数を定義し、ビット１１乃至６は、一般に、将来の使用又はアプリケーションのために予約され、ゼロに等しく設定されている。ビット［１５：１３］が値‘０１０’に等しい場合、ビデオデータは、カラーピクセルのアレイからなる。ここでは、赤のピクセルに関するビット番号が、ビット１１乃至８で定義され、緑のピクセルに関するビット番号が、ビット７乃至４で定義され、青のピクセルに関するビット番号が、ビット３乃至０で定義される。この場合、各ピクセルの合計数は、赤、緑、及び青のために使用されたビット数の合計である。

しかしながら、図１２Ｄに示すように、ビット［１５：１３］が値又はストリング‘０１１’に等しい場合、ビデオデータは、輝度とクロミナンスとを備えた４：２：２ ＹＣｂＣｒフォーマットのビデオデータのアレイからなる。ここでは、輝度（Ｙ）のピクセル毎のビット番号が、ビット１１乃至８で定義され、Ｃｂ成分のビット番号がビット７乃至４で定義され、Ｃｒ成分のビット番号がビット３乃至０で定義される。各ピクセルにおけるビットの合計数は、赤、緑、及び青のために使用されているビット数の合計である。Ｃｂ成分及びＣｒ成分は、Ｙの半分のレートで送られる。更に、このパケットのピクセルデータ部におけるビデオサンプルは、Ｃｂｎ，Ｙｎ，Ｃｒｎ，Ｙｎ＋１，Ｃｂｎ＋２，Ｙｎ＋２、Ｃｒｎ＋２，Ｙｎ＋３，・・・のように構成される。ここでＣｂｎとＣｒｎとはＹｎ及びＹｎ＋１に関連しており、Ｃｂｎ＋２とＣｒｎ＋２とはＹｎ＋２及びＹｎ＋３に関連している。Ｙｎ，Ｙｎ＋１，Ｙｎ＋２，及びＹｎ＋３は、一つの行の左から右への連続した４つのピクセルに対する輝度値である。

全４つのフォーマットについて説明した。図中“Ｐ”として示されているビット１２は、ピクセルデータサンプルがパックされているか否かを、又はバイトが整えられたピクセルデータを特定する。このフィールド内の値‘０’は、ピクセルデータフィールド内の各ピクセルが、ＭＤＤＩバイト境界でバイトが整えられていることを示す。値‘１’は、ピクセルデータの各ピクセル及び各ピクセル内の各色とが、前のピクセル、又は未使用ビットを残さないピクセル内の色に対してパックされたことを示す。

一つの実施形態では、２バイトのピクセルデータ属性フィールドは、以下のとおり、一般には論理ゼロに設定され、将来の使用のために予約されているビット１とビット０とを用いて解釈される。そして、ビット２は、ピクセルデータがインタレースフォーマットを取っているかどうかを示す。ビット２が０であるときには、ピクセルデータは標準漸次フォーマットを取っている。行番号（ピクセルＹ座標）は、ある行から次の行に進むと１増分される。ビット２が１であるときには、ピクセルデータはインタレースフォーマットとなる。行番号（ピクセルＹ座標）は、ある行から次の行に進むと２増分される。

一つの実施形態では、ビット３は、ピクセルデータが代替のピクセルフォーマットを取っているかどうかを示す。これはビット２によってイネーブルされる標準インタレースモードに類似しているが、インターレースは水平の代わりに垂直である。ビット３が０であるとき、ピクセルデータは標準漸次フォーマットで生成又は配置される。列番号（ピクセルＸ座標）は、各連続ピクセルが受信されると１増分される。ビット３が１であるときには、ピクセルデータは代替ピクセルフォーマットで生成または配置される。列番号（ピクセルＸ座標）は、各ピクセルが受信されると、２増分される。

ビット４から１５もまた将来の使用のために予約されており、一般に、現在のアプリケーション又は設計について論理ゼロのレベル又は値に設定される。

３３．スケーリングビデオストリーム肯定応答パケット
スケーリングビデオストリーム肯定応答パケットにより、クライアントはスケーリングビデオストリームセットアップパケットの受信を確認できる。クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４３というパラメータ値を介して、及びスケーリングビデオストリーム機能パケットの最大ストリーム数フィールドの非ゼロ値を介してスケーリングビデオストリーム肯定応答パケットをサポートする能力を示すことができる。

スケーリングビデオストリーム肯定応答パケットのフォーマットは概して図８１に示されている。図８１で分かるように、一実施形態では、スケーリングビデオストリーム肯定応答パケットはパケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔフィールド、ストリームＩＤフィールド、ＡＣＫコードフィールド及びＣＲＣフィールドを有するように構造化されている。２バイトのパケット長フィールドは、１３７というパケットタイプがスケーリングビデオストリーム肯定応答パケットとしてパケットを識別する一方で、このパケットタイプの１０という値で、パケット長フィールドを除き、バイト総数を指定するために使用される。

２バイトのｃＣｌｉｅｎｔＩＤフィールドは、クライアントＩＤのための将来の使用のために予約されており、通常はゼロに設定されている。２バイトのストリームＩＤフィールドはストリームＩＤの一意の識別子を指定する。これはスケーリングビデオストリームセットアップパケットのホストによって割り当てられるのと同じ値である。

２バイトの肯定応答コードフィールドは、指定されたスケーリングビデオストリームを更新しようとする試みの結果を説明するコードを含む値を提供する。一実施形態では、コードは以下のとおりに定義される。

０−ストリーム割り当て試行は成功した。
１−ストリーム割り当て解除試行は成功した。
２−すでに割り当てられているストリームＩＤを割り当てようとする無効な試行。
３−すでに割り当て解除されているストリームＩＤを割り当て解除しようとする無効な試行。
４−クライアントはスケーリングビデオストリームをサポートしない。
５−ストリームパケットはクライアントの機能と一貫していない。
６−ストリームＩＤ値はクライアントによって許可される最大値より大きい。
７−指定されたストリームを割り当てるには不十分なクライアント内で入手可能なリソース。
２バイトのＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを含む。

３４．スケーリングビデオストリームパケット
スケーリングビデオストリームパケットは、特殊なスケーリングビデオストリームと関連したピクセルデータを送信するために使用される。このパケットにより参照される（ｒｅｆｅｒｅｎｃｅ）領域のサイズは、スケーリングビデオストリームセットアップパケットにより定義される。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中のパラメータ値１４３を介して、及びスケーリングビデオストリーム肯定応答パケットのＡｃｋコードフィールド内での成功したスケーリングビデオストリーム割り当て反応を使用して、スケーリングビデオストリームパケットをサポートする能力を示すことができる。

スケーリングビデオストリームパケットの１つの実施形態のフォーマットは、概して図７８に示されている。図７８で分かるように、スケーリングビデオストリームパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ストリームＩＤフィールド、ピクセルデータ属性フィールド、ピクセルカウントフィールド、パラメータＣＲＣフィールド、ピクセルデータフィールド、及びピクセルデータＣＲＣフィールドを有するように構造化されている。２バイトのパケットタイプフィールドはスケーリングビデオストリームパケットとしてパケットを識別するために１８という値を使用する。ｈＣｌｉｅｎｔＩＤフィールドはクライアントＩＤのために予約されており、通常ゼロに設定されている。前述されたように２バイトのストリームＩＤフィールドがストリームＩＤの一意の識別子を指定する。この値は、スケーリングビデオストリームセットアップパケット内のホストによって指定され、スケーリングビデオストリーム肯定応答パケット内で確認される。

一つの実施形態では、２バイトのピクセルデータ属性フィールドは、ピクセルデータ経路及びディスプレイ更新又はバッファ位置を特定する値を持っている。これらの値は、一つの実施形態では、以下のように解釈される。すなわち、ビット１とビット０とは、ピクセルデータが経路付けられるディスプレイを選択する。ビット値‘１１’又はビット値‘００’では、ピクセルデータが両目に対して、又は両目のために表示される。ビット値‘１０’の場合、ピクセルデータは左目のみに送られ、ビット値‘０１’の場合、ピクセルデータは右目のみに送られる。

ビット７とビット６とは、ピクセルデータが書き込まれるフレームバッファを特定するディスプレイ更新ビットである。フレーム更新バッファの効果は、本明細書内の別の箇所に、より詳細に記載されている。ビット［７：６］が‘０１’である場合、ピクセルデータは、オフライン画像バッファに書き込まれる。ビット［７：６］が‘００’である場合、ピクセルデータは、ディスプレイをリフレッシュするために使用される画像バッファに書き込まれる。ビット［７：６］が‘１１’である場合、ピクセルデータは、全ての画像バッファに書き込まれる。ビット［７：６］が‘１０’であれば、無効な値として取り扱われる。これらのビットは現在、将来の使用のために予約されている。この場合、ピクセルデータは無視され、画像バッファの何れにも書き込まれない。ビット１５乃至１４、及びビット１１乃至８は将来の使用のために予約され、一般に論理ゼロレベル又は論理ゼロ値に設定される。

１つの実施形態では、ビット[１３:１２]すなわちビット１３及び１２は、透明色及び透明マスクに関連しており、宛先ピクセルが、宛先位置に書き込まれるべきか否かを特定するために使用される。ビット[１３:１２]が値００に等しい場合、透明色は使用されない。結果として得られる宛先ピクセルは、透明色又は透明マスクの値を考慮することなく、宛先ピクセル位置に書き込まれる。透明色は、透明色及びマスク設定パケットによって定義される。ビット[１３:１２]のための値０１は、将来の使用のために予約され、一般には、有効状態として使用または考慮されない。ビット[１３:１２]が値１０に等しい場合、透明マスクとＡＮＤを取られたソースイメージピクセルが透明色に等しくなければ、宛先ピクセルが宛先位置に書き込まれる。この場合、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。ビット[１３：１２]が値１１に等しい場合、宛先ピクセルは、透明マスクとＡＮＤを取られたソースイメージピクセルが透明色に等しくなければ、宛先ピクセル位置に書き込まれない。この場合、結果として得られるピクセルは、宛先ピクセル位置に書き込まれる。

２バイトのピクセルカウントフィールドは、以下のピクセルデータフィールド内のピクセル数を指定する。２バイトパラメータＣＲＣフィールドはパケット長からピクセルカウントへすべてのバイトのＣＲＣを有する。ＣＲＣがチェックできない場合には、パケット全体が廃棄される。２バイトピクセルデータフィールドは、スケーリングされてから表示されなければならない未処理のビデオ情報を含む。データは、ビデオデータフォーマット記述子フィールドによって記述されるようにフォーマットされる。データは過去に定められたように、一度に１行ずつ送信される。

２バイトのピクセルデータＣＲＣフィールドはピクセルデータだけのＣＲＣを含む。このＣＲＣがチェックできない場合には、ピクセルデータが依然として使用されるものとするが、ＣＲＣエラーカウントは増分されるものとする。

３５．特殊ステータス要求パケット
特殊ステータス要求パケットは、このパケットに指定されるように、クライアントが機能又はステータスパケットをホストに送り返すことをホストが要求するための手段、機構又は方法を提供する。クライアントは、次の逆方向リンクカプセルかパケット内に指定されるタイプのパケットを返す。クライアントは、クライアントが特殊ステータス要求パケットに応答する機能を有する場合、一般に、クライアント機能パケットのクライアント特徴機能フィールドでビット１７を設定する。クライアントが返信又は転送することができるステータスパケットの全てのタイプを判定するためにホストが用いる便利な方法は、説明した有効ステータス応答リストパケットを使用することである。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット２１を使用して有効ステータス応答リストパケットを用いて応答する能力を示すことができる。

特殊ステータス要求パケットの一実施形態のフォーマットは、概して図７９に示されている。図７９で分かるように、特殊ステータス要求パケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ステータスパケットＩＤフィールド、及びＣＲＣフィールドを有するように構造化されている。パケット長フィールドはパケット長フィールドを含まないパケット内のバイト総数を指定し、通常このパケットタイプの場合１０という値で固定されている。１３８というパケットタイプは、パケットを特殊ステータス要求パケットに識別する。ｈＣｌｉｅｎｔＩＤフィールド（２バイト）はクライアントＩＤのための将来の使用のために予約されており、当面ゼロに設定されている。一方、２バイトのステータスパケットＩＤフィールドは、ホストに送信する機能又はステータスパケットのタイプを指定する。典型的なパケットタイプは、
６６−クライアント機能パケットがクライアントにより送信される。
１３３−アルファ−カーソル画像機能パケットがクライアントに送信される。
１３９−クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス応答リストパケットが送信される。
１４１−個人クライアント機能パケットがクライアントによって送信される。
１４２−クライアントエラーレポートパケットがクライアントによって送信される。
１４３−スケーリングビデオストリーム機能パケットがクライアントによって送信される。
１４４−クライアント識別パケットがクライアントによって送信される。

パケットタイプ５６から６３は、製造メーカに特殊な機能識別子とステータス識別子に使用できる。

ＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを再び含む。

３６．有効ステータス応答リストパケット
有効ステータス応答リストパケットは、ホストに、クライアントがそれに返信する機能を有するステータスパケットと機能パケットのリストを持つ構造、手段、又は方法を与える。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット２１を使用して有効ステータス応答リストパケットをサポートする能力を示すことができる。

有効ステータス応答リストパケットの一実施形態のフォーマットは概して図８０に示されている。図８０で分かるように、有効ステータス応答リストパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、リスト中の値数フィールド、有効パラメータ応答リストフィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットのパケット長は通常１０という値に固定され、１３９というタイプ値は有効ステータス応答パケットとしてパケットを識別する。ｃＣｌｉｅｎｔＩＤフィールドはクライアントＩＤとしての将来の使用のために予約され、通常ゼロに設定されている。２バイトのリスト中の数フィールドは、以下の有効パラメータ応答リスト内で項目の数を指定する。

有効パラメータ応答リストフィールドは、クライアントがホストに送信できる機能パケット又はステータスパケットのタイプを指定する２バイトのパラメータのリストを含む。クライアントが、それが（クライアント機能パケットのクライアント特徴機能フィールドのビット２１を使用して）特殊ステータス要求パケットに応答できることを示した場合には、それは少なくともクライアント機能パケット（パケットタイプ＝６６）と有効ステータス応答リストパケット（パケットタイプ＝１３９）を送信できる。クライアントによって送信でき、このリストの中に含められてよいパケットタイプは、一実施形態の目的のためのそのそれぞれの割り当てと共に、以下のとおりである。

６６−クライアント機能パケット
１３３−アルファ−カーソル画像機能パケット
１３９−クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス応答リストパケット
１４１−パーソナルディスプレイ機能パケット
１４２−クライアントエラーレポートパケット
１４３−スケーリング済みビデオストリーム機能パケット
１４４−クライアント識別パケット
１４５-代替ディスプレイ機能パケット。

パケット５６から６３は、製造メーカに特殊な機能及びステータス識別子のために使用できる。

ＣＲＣフィールドはパケット長を含むパケット内のすべてのバイトのＣＲＣを含む。

３７．パーソナルディスプレイ機能パケット
パーソナルディスプレイ機能パケットは、ヘッドマウントディスプレイ又はディスプレイ眼鏡等のパーソナルディスプレイ装置の機能を記述するパラメータのセットを提供する。これによりホストはクライアントの特定の機能に従って表示情報をカスタマイズできる。他方、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの対応するパラメータを使用することによってパーソナルディスプレイ機能パケットを送信する能力を示す。

パーソナルディスプレイ機能パケットの１つの実施形態のフォーマットは概して図８１に示されている。図８１で分かるように、パーソナルディスプレイ機能パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、サブピクセルレイアウトフィールド、ピクセル形状フィールド、水平視野フィールド、垂直視野フィールド、視軸交差フィールド、左右画像フィールド、シースルーフィールド、最大明度フィールド、光学機能フィールド、最小ＩＰＤフィールド、最大ＩＰＤフィールド、曲率リストのＩＦｅｌｄの点フィールド及びＣＲＣフィールドを有するように構造化されている。このパケットのパケット長はつねに６８である。１４１というパケットタイプ値は、パーソナルディスプレイ表示機能パケットとしてパケットを識別する。ｃＣｌｉｅｎｔＩＤフィールドは将来の使用のために予約されており、通常は当面ゼロに設定されている。

１つの実施形態では、サブピクセルレイアウトフィールドは以下の値を使用して上から下へ、及び左から右へサブピクセルの物理的なレイアウトを指定する。つまり、０はサブピクセルレイアウトが定義されていないことを示し、１は赤、緑、青の縞を示し、２は青、緑、赤の縞を示し、３は、左上に赤、右下に青、及び一方が左下、他方が右上の２個の緑のサブピクセル２×２のサブピクセル配列を有するクワッドピクセルを示し、４は、左下に赤、右上に青の２×２のサブピクセル配列及び一方が左上、他方が右下の２個の緑のサブピクセルを示し、５はデルタ（トライアド）を示し、６は、赤、緑及び青がオーバレイされた（たとえば、フィールド順次色のＬＣＯＳディスプレイ）モザイクを示し、７から２５５の値が将来の使用のために通常予約されている。

１つの実施形態では、ピクセル形状フィールドは、以下の値を使用し特殊な構成のサブピクセルから構成されている各ピクセルの形状を指定し、０はサブピクセル形状が定められていないことを示し、１は円形を示し、２は正方形を示し、３は矩形を示し、４は長円を示し、５は楕円を示し、値６から２５５が、当業者が理解できるように、所望される形状を示す上での将来の使用に予約されている。

１つの実施形態では、１バイトの水平視野（ＨＦＯＶ）フィールドは、０．５度の増分で水平視野を指定する（例えばＨＦＯＶが３０度である場合、この値は６０である）。この値がゼロである場合にはＨＦＯＶは指定されていない。

１つの実施形態では、１バイトの垂直視野（ＶＦＯＶ）フィールドは、０．５度の増分で垂直視野を指定する（例えば、ＶＦＯＶが３０である場合、この値は６０である）。この値がゼロである場合、ＶＦＯＶは指定されていない。

１つの実施形態では、１バイト視軸交差フィールドは、０．０１ジオプタ（１／ｍ）増分で視軸交差を指定する（例えば、視軸交差が２．２２メートルである場合、この値は４５である）。この値がゼロである場合、視軸交差が指定されない。

１つの実施形態では、１バイトの左／右画像重複フィールドは、左画像と右画像の重複のパーセンテージを指定する。パーセント単位の画像重複の許容可能な範囲は１から１００である。１０１から２５５の値は無効であり、一般には使用されない。この値がゼロである場合には、画像重複は指定されない。

１つの実施形態では、１バイトシースルーフィールドは、画像のシースルーパーセンテージを指定する。パーセント単位のシースルーの許容範囲は０から１００である。１０１から２５４の値は無効であり、使用されない。この値が２５５である場合には、シースルーパーセンテージは指定されない。Ａ１バイト最大明度フィールドは２０ニットの増分で最大明度を指定する（例えば、最大明度が１００ニットである場合、この値は５である）。この値がゼロである場合には、最大明度は指定されない。

１つの実施形態では、２バイト光学機能フラグフィールドはディスプレイの光学機能を指定する多様なフィールドを含む。これらのビット値は、通常、以下に従って割り当てられている。ビット１５から５は将来の使用のために受信され、一般に、論理ゼロ状態に設定される。ビット４はメガネ焦点調整を選択し、「０」という値はディスプレイにメガネ焦点調整がないことを意味し、「１」という値はディスプレイがメガネ焦点調整を有することを意味する。ビット３から２は、以下に従って両眼機能を選択する。０という値は、ディスプレイが両眼用であり、２次元（２Ｄ）画像だけを表示できることを意味し、１は、ディスプレイが両眼用であり、３次元（３Ｄ）画像を表示できることを意味し、２は、ディスプレイが単眼用であることを意味し、３は将来の使用のために予約されている。ビット１から０は、左右像面湾曲対称を選択し、０という値は像面湾曲が定義されていないことを意味する。このフィールドがゼロである場合には、Ａ１からＥ５までのすべての像面湾曲値は、点Ｃ３を除きゼロに設定され、ディスプレイの焦点距離を指定するか、あるいはゼロに設定され、焦点距離が指定されていないことを示す。１という値は左右のディスプレイが同じ対称性を有することを意味する。２は、左右のディスプレイが垂直軸（列Ｃ）でミラーリングされていることを意味し、３は将来の使用のために予約されている。

１つの実施形態では、１バイト相互瞳孔間距離（ＩＰＤ）最小フィールドは、ミリメートル（ｍｍ）で最小の相互瞳孔間距離を指定する。この値がゼロである場合には、最小相互瞳孔間距離が指定されない。１バイトの相互瞳孔間距離（ＩＰＤ）最大フィールドはミリメートル（ｍｍ）で最大相互瞳孔間距離を指定する。この値がゼロである場合には、最大相互瞳孔間距離は指定されない。

像面湾曲の点リストフィールドは、１から６５５３５（例えば、１は０．００１ジオプターであり、６５５３５は６５．５３５ジオプターである）の範囲でジオプター（１／ｍ）の千分の１で焦点距離を指定する２５の２バイトパラメータを含む。像面湾曲の点リストの２５の要素は、図８２に示されているようにＡ１からＥ５と呼ばれている。該点はディスプレイのアクティブな領域で均等に分散される。列Ｃはディスプレイの垂直軸に相当し、行３はディスプレイの水平軸に相当する。列ＡとＥは、それぞれディスプレイの左端縁と右端縁に相当する。そして、行１と５は、それぞれディスプレイの上部端縁と下部端縁に相当する。リスト中の２５の点の順序は以下のとおりである。Ａ１、Ｂ１、Ｃ１、Ｄ１、Ｅ１、Ａ２、Ｂ２、Ｃ２、Ｄ２、Ｅ２、Ａ３、Ｂ３、Ｃ３、Ｄ３、Ｅ３、Ａ４、Ｂ４、Ｃ４、Ｄ４、Ｅ４、Ａ５、Ｂ５、Ｃ５、Ｄ５、Ｅ５。

ＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを含む。

３８．クライアントエラーレポートパケット
クライアントエラーレポートパケットは、クライアントがホストに動作エラーのリストを提供できるようにするための機構又は手段として働く。クライアントはホストから特定のコマンドを受信した結果としてその通常の動作の過程で幅広い範囲のエラーを検出してよい。これらのエラーの例は以下を含む。クライアントは、それがサポートしていないモードで動作するように命令された可能性がある、クライアントは範囲外である、あるいはクライアントの能力を超えている特定のパラメータを含むパケットを受信した可能性がある、クライアントは不適切な順序でモードに入るように命令された可能性がある。クライアントエラーレポートパケットは、通常の動作中にエラーを検出するために使用される可能性があるが、ホストシステムとクライアントシステムの開発及び統合における問題点を診断するためにシステム設計者と統合者にもっとも有効である。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストで１４２というパラメータ値を使用して、クライアントエラーレポートパケットを送信するその機能を示す。

クライアントエラーレポートパケットの一実施形態のフォーマットは、概して図８３に示されている。図８３で分かるように、クライアントエラーレポートパケットはパケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、リストアイテム数フィールド、エラーコードリストフィールド及びＣＲＣフィールドを有するように構造化されている。１４２というパケットタイプ値は、パケットをクライアントエラーレポートパケットとして識別する。ｃＣｌｉｅｎｔＩＤフィールドは将来の使用のために予約され、通常、当面はゼロに設定されている。リストアイテム数フィールド（２バイト）は以下のエラーコードリストの中のアイテム数を指定する。エラーコードリストフィールド（ここでは８バイト）は、１つ又は複数のエラーレポートリストアイテムを含むリストである。単一のエラーレポートリストアイテムのフォーマットは図８４に示されている。

一実施形態では、図８４に示されているように各エラーレポートリストアイテムの長さは正確に４バイトであり、以下を備える一実施形態での構造を有する。つまり、報告されているエラーのタイプを指定する２バイトの表示エラーコードフィールド、２バイトのエラーサブコードフィールドはクライアントエラーコードパケットにより定められるエラーに関してより大きなレベルの詳細を指定する。各クライアントエラーコードの特殊な定義はクライアントの製造メーカによって定義されている。エラーサブコードは、表示エラーコードごとに定義される必要はなく、エラーサブコードが定義されていないそれらの場合、該値はゼロに設定される。各エラーサブコードの特定の定義はクライアントの製造メーカにより定義される。

３９．クライアント識別パケット
クライアント識別パケットは、クライアントが特殊ステータス要求パケットに応えて識別データを返すことができるようにする。一実施形態では、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４４というパラメータを使用してクライアント識別パケットを送信する能力を示す。ホストが、クライアントからこのデータを読み取ることによってクライアントデバイスの製造メーカ名及び型番を決定できるようにすることが有効である。情報は、クライアントがクライアント機能パケットに記述できない特殊な機能を有するかどうかを判断するために使用されてよい。クライアントから識別情報を読み取るための潜在的に２つの方法、手段又は機構がある。一方は、ベースＥＤＩＤ構造でのフィールドに類似するフィールドを含むクライアント機能パケットの使用による。他方の方法は、クライアント機能パケットないの類似するフィールドに比較される、より濃密な情報のセットを含むクライアント識別パケットの使用による。これは、ホストが３文字ＥＩＳＡコードを割り当てられていない製造メーカを識別できるようにし、シリアル番号が英数字文字を含むことができるようにする。

クライアント識別パケットの一実施形態のフォーマットは、概して図８５に示されている。図８５で分かるように、クライアント識別パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、製造週フィールド、製造年フィールド、製造メーカ名フィールド、製品名長フィールド、シリアル番号長フィールド、製造メーカ名文字列フィールド、製品名文字列フィールド、シリアル番号文字列フィールド、及びＣＲＣフィールドを有するように構造化されている。

２バイトのパケットタイプフィールドは、クライアント識別パケットとしてパケットを識別する値を含む。この値は一実施形態で１４４になるように選択される。ｃＣｌｉｅｎｔＩＤフィールド（２バイト）は再びクライアントＩＤ用の将来の使用のために予約され、通常ゼロに設定されている。ＣＲＣフィールド（２バイト）は、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

１バイトの製造週フィールドは、ディスプレイの製造週を定める値を含む。少なくとも一実施形態では、この値は、それがクライアントによってサポートされる場合１から５３の範囲内にある。このフィールドがクライアントによってサポートされていない場合には、それは通常ゼロに設定されている。１バイトの製造年フィールドは、クライアント（ディスプレイ）の製造の年を定める値を含む。他のベース年も使用できるであろうが、この値は開始点としての年１９９０からオフセットである。１９９１から２２４５の範囲の年をこのフィールドによって表すことができる。例：年２００３は１３という製造年値に対応する。このフィールドがクライアントによってサポートされていない場合には、それはゼロという値に設定されなければならない。

製造メーカ名長フィールド、製品名長フィールド、及びシリアル番号長フィールドは、あらゆるヌル終端又はヌルパッド文字を含む製造メーカ名文字列フィールドの長さ、あらゆるヌル終端又はヌルパッド文字を含む製品名文字列フィールドの長さ、及びそれぞれヌル終端文字又はヌルパッド文字を含むシリアル番号文字列フィールドの長さを指定する、それぞれ２バイトの値を含む。

製造メーカ名文字列フィールド、製品名文字列フィールド、及びシリアル番号文字列フィールドは、それぞれ製造メーカ、製品名、及び英数字シリアル番号を指定するＡＳＣＩＩ文字列を含む、それぞれディスプレイの製造メーカ名長フィールド、製品名フィールド、及びシリアル番号フィールドによって指定される可変数のバイトを含む。これらの文字列のそれぞれは少なくとも１つのヌル文字で終端する。

４０．代替ディスプレイ機能パケット
代替ディスプレイ機能パケットは、ＭＤＤＩクライアントコントローラに取り付けられる代替ディスプレイの機能を示す手段、構造、又は方法として使用される。それは特殊ステータス要求パケットに応えて送信される。プロンプトを出されると、クライアントデバイスは、サポートされている代替ディスプレイごとに代替ディスプレイ機能パケットを送信する。クライアントが一つより多い代替ディスプレイを持っている場合、非効率的ではあるものの、希望に応じて幾つかの構成が複数の要求特有ステータスパケットを使用するが、クライアントは、一つの要求特有ステータスパケットに応じて、各ディスプレイのためにそれぞれ代替ディスプレイ機能パケット送り、生成し、提供する。クライアントは、代替ディスプレイ機能パケットを送る。ここでは、代替ディスプレイ数フィールドの値に基づいて、「不連続な順番」としても称されうる。クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４５というパラメータ値を介して代替ディスプレイ機能パケットを送信する能力を示すことができる。

内部モードで操作されているＭＤＤＩシステムの場合、ＭＤＤＩクライアントコントローラに接続される複数のディスプレイを有することはよくあることである可能性がある。例の応用例は、フリップの内側に大型ディスプレイ、外側に小型のディスプレイを備えた携帯電話である。内部モードクライアントは、２つの潜在的な理由により、代替ディスプレイ機能パケットを返す必要はない。第１に、ホストは既にプログラムされているか、或いは製造中に、その機能が通知されているかもしれない。なぜなら、それらは共通のデバイス又は筐体で使用されているからである。第２に、これら２つの組み立てによって、クライアントは、接続が切られたり、ホストへの接続から分離されることが容易にはなされない。そして、ホストは、クライアント機能のハードコードコピーを含むか、あるいは、起こるかもしれないクライアント内の変化によって変化しないことを少なくとも知っているかもしれない。

クライアント機能パケットの代替ディスプレイ数フィールドは、複数のディスプレイが取り付けられ、代替ディスプレイ機能パケットが各代替ディスプレイの機能を報告することを報告するために使用される。ビデオストリームパケットは、クライアントデバイスの中の各代替ディスプレイに対処するためにピクセルデータ属性フィールドに４ビットを含む。

代替ディスプレイ機能パケットの一実施形態のフォーマットは、概して図８６に示されている。図８６で分かるように、代替ディスプレイ機能パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、代替ディスプレイ数フィールド、予約１フィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、ディスプレイウィンドウ幅フィールド、ディスプレイウィンドウ高さフィールド、カラーマップＲＧＢ幅フィールド、ＲＧＢ機能フィールド、白黒機能フィールド、予約２フィールド、Ｙ Ｃｂ Ｃｒ機能フィールド、Ｂａｙｅｒ機能フィールド、予約３フィールド、ディスプレイ特徴機能フィールド及びＣＲＣフィールドを有するように構造化されている。１４５というパケットタイプ値は、代替ディスプレイ機能パケットとしてパケットを識別する。ｃＣｌｉｅｎｔＩＤフィールドは、現在、将来の使用のためのクライアントＩＤのために予約され、通常は、ビットを論理ゼロレベルに設定することによってゼロに設定されている。

代替ディスプレイ数フィールドは、０から１５の範囲内の整数で代替ディスプレイのアイデンティティを示すために１バイトを使用する。第１の代替ディスプレイは一般に０番に指定され、他の代替ディスプレイは、使用されている最大数が１を差し引いた代替ディスプレイの総数である、一意の代替ディスプレイ数値で識別される。１を差し引いた代替ディスプレイ総数より大きい値は、使用されない。例：一次ディスプレイとＭＤＤＩクライアントに接続されている発呼者ＩＤディスプレイを有する携帯電話は、１つの代替ディスプレイを有するため、発呼者ＩＤディスプレイの代替ディスプレイ数はゼロであり、クライアント機能パケットの代替ディスプレイ数フィールドは１という値を有する。

予約１フィールド（１バイト）は、将来の使用のために予約されている。従って、このフィールドの中のすべてのビットは現在、ゼロ、すなわち論理ゼロレベルに設定されている。１つの実施形態では、このフィールドの１つの目的は、すべての以後の２バイトフィールドを１６ビットのワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードのアドレスに位置合わせさせることである。

ビットマップ幅フィールドは、ピクセル数として表されるビットマップの幅を指定する２バイトを使用する。ビットマップ高さフィールドはピクセル数として表されるビットマップの高さを指定する２バイトを使用する。ディスプレイウィンドウ幅フィールドは、ピクセル数として表されるディスプレイウィンドウの幅を指定する２バイトを使用する。ディスプレイウィンドウ高さフィールドはピクセル数として表されるディスプレイウィンドウの高さを指定する２バイトを使用する。

カラーマップＲＧＢ幅フィールドは、カラーマップ（パレット）表示モードで表示できる赤、緑、及び青の色成分のビット数を指定する２バイトを使用する。色成分（赤、緑、及び青）ごとに最大８ビットが使用できる。８ビットの各色成分がカラーマップパケットで送信されるとしても、このフィールドに定義される各色成分の最下位ビットの数だけが使用される。ディスプレイクライアントがカラーマップ（パレット）フォーマットを使用できない場合、この値はゼロである。カラーマップＲＧＢ幅ワードは、３つの別々の符号なし値から構成されている。

ビット３から０は、０から８という値が有効と考えられる、各ピクセル内の青の最大ビット数を定義する。ビット７から４は、０から８の値が有効と考えられる、各ピクセル内の緑の最大ビット数を定義する。ビット１１から８は、０から８の値が有効と考えられる、各ピクセル内の赤の最大ビット数を定義する。ビット１４から１２は将来の使用のために予約されており、通常ゼロに設定されている。ビット１５は、パックフォーマット又はアンパックフォーマットでカラーマップピクセルデータを受け入れるクライアントの能力を示すために使用される。ビット１５が論理１レベルに設定されているとき、こは、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでカラーマップピクセルデータを受け入れることができることを示す。ビット１５が論理ゼロに設定されている場合、これは、クライアントがアンパックフォーマットでのみカラーマップピクセルを受け入れることができることを示している。

ＲＧＢ機能フィールドは、ＲＧＢフォーマットで表示できる解像度のビット数を指定するための２バイトを使用する。一実施形態では、クライアントがＲＧＢフォーマットを使用できない場合に、この値はゼロに等しく設定される。ＲＧＢ機能ワードは、以下の３つの別々の符号なし値から構成されている。ビット３から０は、各ピクセル内の青の最大ビット数（青輝度）を定義し、ビット７から４は各ピクセル内の緑の最大ビット数（緑輝度）を定義し、ビット１１から８は各ピクセル内の赤の最大ビット数（赤輝度）を定義する。ビット１４から１２は将来の使用のために予約されており、ゼロに設定されている。ビット１５は、パックフォーマット又はアンパックフォーマットでＲＧＢピクセルデータを受け入れるためのクライアントの能力を示すために使用される。ビット１５が論理１レベルに設定されているとき、これは、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでＲＧＢピクセルデータを受け入れることができることを示している。ビット１５が論理ゼロに設定されると、これは、クライアントがアンパックフォーマットだけでＲＧＢピクセルデータを受け入れることができることを示している。

１バイトの白黒機能フィールドは、白黒フォーマットで表示できる解像度のビット数を指定するための値又は情報を含む。クライアントが白黒フォーマットを使用できない場合には、この値はゼロに等しく設定される。ビット６から４は、将来の使用のために予約され、通常はゼロに設定されている。ビット３から０は、各ピクセルに存在できるグレイスケールの最大ビット数を定義する。これらの４つのビットにより、各ピクセルが１ビットから１５ビットからなることを指定できるようになる。値がゼロである場合には、白黒フォーマットはクライアントによってサポートされていない。ビット７は、１に設定時、クライアントがパックフォーマット又はアンパックフォーマットのどちらかで白黒ピクセルデータを受け入れることを示す。ビット７がゼロに設定されている場合、これはクライアントがアンパックフォーマットだけで白黒ピクセルデータを受け入れることができることを示している。

予約２フィールドは、将来の使用のために予約されている１バイト幅のフィールドであり、通常、このフィールドの中のすべてのビットは論理ゼロレベルに設定されている。一実施形態では、このフィールドを有する目的は、すべての以後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。

２バイトのＹ Ｃｂ Ｃｒ機能フィールドは、Ｙ Ｃｂ Ｃｒフォーマットで表示できる解像度のビット数を指定する。クライアントがＹ Ｃｂ Ｃｒフォーマットを使用できない場合には、この値はゼロである。Ｙ Ｃｂ Ｃｒ機能ワードは以下の３つの別々の符号なし値から構成されている。ビット３から０は、Ｃｂサンプルを指定する最大ビット数を定義し、ビット７から４はＣｒサンプルを指定する最大ビット数を定義し、ビット１１から８はＹサンプルを指定する最大ビット数を定義し、ビット１４から１２は将来の使用のために予約され、ゼロに設定されている。ビット１５は、１に設定時に、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでＹ Ｃｂ Ｃｒピクセルデータを受け入れることができることを示す。ビット１５がゼロに設定されている場合、これはクライアントがＹ Ｃｂ Ｃｒピクセルデータをアンパックフォーマットだけで受け入れることができることを示している。

２バイトＢａｙｅｒ機能フィールドは、解像度、ピクセルグループ及びＢａｙａｅｒフォーマットで転送できるピクセル順序のビット数を指定する。クライアントがＢａｙｅｒフォーマットを使用できない場合には、この値はゼロに設定されている。Ｂａｙｅｒ機能フィールドは以下の値から構成されている。ビット３から０は各ピクセルに存在する輝度の最大ビット数を定義し、ビット５から４は、必要とされる可能性のあるピクセルグループパターンを定義し、ビット８から６は必要とされるピクセル順序を定義し、ビット１４から９は将来の使用のために予約され、ゼロに設定されている。ビット１５は、１に設定時、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでＢａｙｅｒピクセルデータを受け入れることができることを示す。ビット１５がゼロに設定されている場合、これは、クライアントがアンパックフォーマットだけでＢａｙｅｒピクセルデータを受け入れることができることを示す。

ここでは２バイトである予約３フィールドは、将来の使用のために予約されている。従って、このフィールド内の全てのビットは、論理ゼロレベル又はゼロ値にあるいはそれに等しく設定されている。１つの実施形態では、現在、パケット内のこのフィールドを有する目的は、次の２バイトのフィールドを、１６ビットワードアドレスに揃え、４バイトフィールドを、３２ビットワードアドレスに揃えることである。

ここでは４バイトであるディスプレイ特徴機能インジケータフィールドは、代替ディスプレイにおける具体的な特徴がサポートされているかを示すフラグのセットを含んでいる。１に設定されたビットは、特定の、又は現在の機能がサポートされていることを示し、ゼロに設定されたビットは、この機能がサポートされていないことを示す。

１つの実施形態では、ディスプレイ特徴機能フィールドは、サポートされる代替ディスプレイ内の具体的な機能を示すフラグのセットを含む４バイトを使用する。論理１レベルに設定されたビットセットは、この機能がサポートされていることを示す。一方、論理ゼロレベルに設定されたビットは、この機能がサポートされていないことを示す。一つの実施形態では、ビット０の値は、ビットマップブロック転送パケット（パケットタイプ７１）がサポートされているか否かを示す。ビット１，２及び３の値は、ビットマップ領域塗り潰しパケット（パケットタイプ７２）、ビットマップパターン塗り潰しパケット（パケットタイプ７３）、又はリードフレームバッファパケット（パケットタイプ７４）がそれぞれサポートされているか否かを示す。ビット４の値は、代替ディスプレイが、透明色イネーブルパケットを用いて、１つの色を透明にする機能を持っているか否かを示す。

この実施形態では、ディスプレイ特徴機能フィールドのビット１０の値は、代替ディスプレイが、ディスプレイ電力状態０１をサポートする能力を持っているか否かを示す。ディスプレイ電力状態は、上述したディスプレイ電力ステータスパケットの電力状態フィールドのビット[３:２]を用いて設定される。ディスプレイ電力状態０１は、選択されたディスプレイが点灯しておらず、最小の電力量を消費している状態である。そして、この状態の間は、もしあれば、一般に、フレームバッファのコンテンツが保証される、すなわち適切に保持され続ける。

ディスプレイ特徴機能フィールドのビット１３の値は、代替ディスプレイが、ＶＣＰ特徴パケット、要求ＶＣＰ特徴パケット、ＶＣＰ特徴応答パケット、セットＶＣＰ特徴パケット、要求有効パラメータパケット、及び有効パラメータ応答パケットをサポートすることによって、１つ又は複数のビデオパラメータを設定する能力を有するか否かを示す。ビット１４の値は、図８８Ａに示すように、代替ディスプレイが、ピクセルデータを、オフラインディスプレイフレームバッファに書き込む能力を持っているか否かを示す。このビットが論理１レベルに設定されると、ディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性フィールドのビット７及び６）が値‘０１’に設定されうる。

ディスプレイ特徴機能フィールドのビット１５の値は、図８８Ｂに示すように、代替ディスプレイが、ディスプレイイメージをリフレッシュするために使用されているディスプレイフレームバッファのみにピクセルデータを書き込む能力を持つ時を示す。このビットが論理１に設定されているのであれば、ディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性フィールドのビット７及び６）が値‘００’に設定されうる。ビット１６の値は、図８８Ｃに示すように、代替ディスプレイが、単一のビデオストリームパケットからのピクセルデータを、全てのディスプレイフレームバッファに書き込む能力を持つ時を示す。このビットが論理１レベルに等しく設定されているのであれば、ディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性フィールドのビット７及び６）が値‘１１’に設定されうる。

１つの実施形態では、ディスプレイ特徴機能フィールドのビット２１の値は、もしも以下のパケットが代替ディスプレイによって、ビット２，１，０又はフィールドによって特定されるようにサポートされているのであれば、ビットマップパターン塗り潰しパケット（パケットタイプ７３）、ビットマップ領域塗り潰しパケット（パケットタイプ７２）、及びビットマップブロック転送パケット（パケットタイプ７１）のラスタ動作フィールドを使用する能力を持っている時を示す。１つの実施形態では、ビット２１が論理ゼロレベルまたは値を持ち、これらパケットがサポートされているのであれば、代替ディスプレイは、ラスタ動作フィールドを使用する能力を持っておらず、代替ディスプレイは一般に、これらパケットによって特定されるピクセル位置に単にコピーするか、書き込む能力しか持たない。

１つの実施形態では、ディスプレイ特徴機能フィールドのビット９乃至５、１１，１２，２０乃至１７，３１乃至２２は、現在、将来の使用のために予約されているか、システム設計者のために利用可能な別の設定であり、一般にゼロ値又は論理ゼロレベルに等しく設定されている。

１つの実施形態では、２バイトのＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

４１．レジスタアクセスパケット
レジスタアクセスパケットは、ホスト又はクライアントのどちらかに、ＭＤＤＩリンクの反対端の構成レジスタとステータスレジスタにアクセスする手段、機構又は方法を与える。これらのレジスタは、各ディスプレイ又はデバイスコントローラに一意となる可能性がある。これらのレジスタは、設定構成、運転モードを必要とするすでに多くのディスプレイに存在し、他の有用且つ必要な設定値を有している。レジスタアクセスパケットは、ＭＤＤＩホスト又はクライアントがレジスタに書き込むだけではなく、ＭＤＤＩリンクを使用してレジスタを読み取ることも要求できるようにする。ホスト又はクライアントがレジスタ読み取りを要求すると、反対側はレジスタデータを同じパケットタイプで送信することによるが、これが読み取り／書き込み情報フィールドを使用してある特定のレジスタから読み取られたデータであることを示すことによっても応答しなければならない。レジスタアクセスパケットは、１より大きいレジスタカウントを指定することによって複数のレジスタを読み取る、又は書き込むために使用されてよい。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット２２を使用してレジスタアクセスパケットをサポートする能力を示す。クライアントは、カプセル化パケットを用いてレジスタアクセスパケットを送信する。これによって、パケット設定又は構造内で何がパケットとして表れるのかを示す。

レジスタアクセスパケットの一実施形態のフォーマットは概して図８７に示されている。図８７で分かるように、レジスタアクセスパケットは、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、読み取り／書き込み情報フィールド、レジスタアドレスフィールド、パラメータＣＲＣフィールド、レジスタデータリストフィールド及びレジスタデータＣＲＣフィールドを有するように構造化されている。１４６というパケットタイプ値は、レジスタアクセスパケットとしてパケットを識別する。ｂＣｌｉｅｎｔＩＤフィールドは将来の使用のために予約されており、通常、当面ゼロに設定されている。

１つの実施形態では、２バイトの読み取り／書き込み情報フィールドは、書き込み又は読み取り、あるいは読み取りに対する応答のどちらかとして特定のパケットを指定する機能として動作し、データ値のカウントを提供する。

ビット１５から１４は、読み取り／書き込みフラグとして働く。ビット［１５：１４］が「００」である場合には、このパケットはレジスタアドレスフィールドによってアドレス指定されるレジスタに書き込まれるデータを含む。指定されたレジスタに書き込まれるデータはレジスタデータリストフィールドに含まれている。ビット［１５：１４］が「１０」である場合には、これはレジスタアドレスフィールドによってアドレス指定されている１つ又は複数のレジスタからのデータに対する要求である。ビット［１５：１４］が［１１］である場合には、そのパケットは、読み取り／書き込みフラグのビット１５：１４が「１０」に設定されているレジスタアクセスパケットに応えて要求されたデータを含む。レジスタアドレスフィールドは、第１のレジスタデータリストアイテムに対応するレジスタのアドレスを含み、レジスタデータリストフィールドは、１つ又は複数のアドレスから読み取られたデータを含む。ビット［１５：１４］が「０１」である場合には、この場合、これは無効値として処理され、この値は将来のために予約され、使用されないが、当該技術分野における熟練者であれば、将来における利用のためにどのようにしてそれを適用するかを理解するであろう。

ビット１３：０はレジスタデータリストフィールドで送信される３２ビットのレジスタデータアイテムの数を指定するために１４ビットの符号なし整数を使用する。ビット１５：１４が「００」に等しい場合には、ビット１３：０はレジスタアドレスフィールドにより指定されるレジスタで開始するレジスタに書き込まれるレジスタデータリストフィールドに含まれる３２ビットのレジスタデータアイテムの数を指定する。ビット１５：１４が「１０」に等しい場合には、ビット１３：０は、受信側装置がそのレジスタが読み取られるのを要求する装置に送信する３２ビットのレジスタデータアイテムの数を指定する。このパケットの中のレジスタデータリストフィールドにはアイテムは含まれず、ゼロ長である。ビット１５：１４が「１１」に等しい場合には、ビット１３：０は、レジスタデータリストフィールドに含まれているレジスタから読み取られた、３２ビットレジスタデータアイテムの数を指定する。現在、ビット１５：１４は無効値と見なされている「０１」に等しく設定されておらず、無効の値とみなされ、それ以外の場合は将来の指定又は使用のために予約されている。

レジスタアクセスフィールドは、書き込まれる又は読み取られるレジスタアドレスを示すために４バイトを使用する。そのアドレス指定が３２ビット未満であるレジスタをアドレス指定する場合、上位ビットはゼロに設定される。

２バイトパラメータＣＲＣフィールドはパケット長からレジスタアクセスまでのすべてのバイトのＣＲＣを含む。このＣＲＣがチェックできない場合、パケット全体が廃棄される。

レジスタデータリストフィールドは、クライアントレジスタに書き込まれる４バイトのレジスタデータ値、又はクライアントデバイスレジスタから読み取られた値のリストを含む。

２バイトのレジスタデータＣＲＣＦフィールドは、レジスタデータリストだけのＣＲＣを含む。このＣＲＣがチェックできない場合には、レジスタデータは依然として使用されてよいが、ＣＲＣエラーカウントが増分される。

Ｄ．パケットＣＲＣ
ＣＲＣフィールドは、パケットの最後に、著しく大きなデータフィールドを有することがあるパケットの中のより重大なパラメータの後にも出現することがあり、したがって転送中のエラーの尤度が上昇する。２つのＣＲＣフィールドを有するパケットの場合、ＣＲＣジェネレータは、ただ一方だけが使用されるときに、長いデータフィールドの後のＣＲＣ計算がパケットの始まりでパラメータによって影響を及ぼされないように第１のＣＲＣの後に再初期化される。

多くのビット誤りを含むパケットが、良好なＣＲＣを生成するわずかな可能性がある。誤りを持つパケットについて良好なＣＲＣを検出する可能性は、多くの誤りを含む非常に長いパケットについて７×１０^−６に近づく。設計によって、ＭＤＤＩリンクは、非常に低いか、あるいはゼロの誤り率となる。ＣＲＣは、リンクの健全性の監視のために使用されることが意図されており、パケットが再送信されるべきかを判定するために特定のパケットに関する誤りを検出するように意図されていない。

例示的な実施形態では、ＣＲＣ計算のために使用される多項式はＣＲＣ−１６、つまりＸ１６＋Ｘ１５＋Ｘ２＋Ｘ０として知られている。本発明を実現するために有効なＣＲＣジェネレータとチェッカ３６００のサンプルインプリメンテーションは図３６に示されている。図３６では、ＣＲＣレジスタ３６０２は、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｂｅｆｏｒｅ＿ＣＲＣ線路上の入力であるパケットの第１のビットの転送の直前に０ｘ０００１という値に初期化され、次にパケットのバイトがＬＳＢで最初に開始するレジスタの中にシフトされる。この図のレジスタビット番号が、使用されている多項式の順序に対応し、ＭＤＤＩによって使用されるビット位置には対応しないことに注意する。単一方向でＣＲＣレジスタをシフトする方がより効率的であり、この結果、ＭＤＤＩビット位置１４に達するまで、ＣＲＣビット１５をＭＤＤＩ ＣＲＣフィールドのビット位置０に、ＣＲＣレジスタビット１４をＭＤＤＩ ＣＲＣフィールドビット位置１に表示させる等である。

一例としては、クライアント要求及びステータスパケットのパケットコンテンツが０ｘ０００ｃ、０ｘ００４６、０ｘ０００、０ｘ０４００、０ｘ００、０ｘ００、０ｘ００００であり（あるいは０ｘ０ｃ、０ｘ００、０ｘ４６、０ｘ００、０ｘ００、０ｘ００、０ｘ００、０ｘ０４、０ｘ００、０ｘ００、０ｘ００、０ｘ００等のバイトのシーケンスとして表現され）、マルチプレクサ３６０４と３６０６及びＡＮＤゲート３６０８の入力を使用して提出されると、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｗｉｔｈ＿ＣＲＣ線路で結果として生じるＣＲＣ出力は０ｘｄ９ａａである（あるいは０ｘａａ、０ｘｄ９のようなシーケンスとして表される）。

ＣＲＣジェネレータとチェッカ３６００が１台のＣＲＣチェッカとして構成されるとき、Ｒｘ＿ＭＤＤＩ＿Ｄａｔａ線路で受信されるＣＲＣは、マルチプレクサ３６０４と排他的ＯＲ（ＸＯＲ）ゲート３６１２に入力され、ＮＯＲゲート３６１０、ＡＮＤゲート３６０８、及びＡＮＤゲート３６１４を使用してＣＲＣレジスタ内で発見される値とビット単位で比較される。ＡＮＤゲート３６１４によって出力されるようなエラーがある場合には、ゲート３６１４の出力をレジスタ３６０２の入力に接続することによりＣＲＣはＣＲＣエラーを含むパケットごとに一度増分される。図３６の図に示される例の回路が、既定のＣＨＥＣＫ＿ＣＲＣ＿ＮＯＷウィンドウ内で複数のＣＲＣエラー信号を出力できる（図３７Ｂを参照されたい）ことに注意する。したがって、ＣＲＣエラーカウンタは通常、ＣＨＥＣＫ＿ＣＲＣ＿ＮＯＷがアクティブである各間隔内に第１のＣＲＣエラーだけをカウントする。ＣＲＣジェネレータとして構成される場合、ＣＲＣはパケットの最後と一致する時間にＣＲＣレジスタから退出時間を記録される。

入力信号と出力信号及びイネーブル信号のタイミングは、図３７Ａと図３７Ｂに図で描かれている。ＣＲＣの生成とデータのパケットの伝送は、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｂｅｆｏｒｅ＿ＣＲＣ信号とＴｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｗｉｔｈ＿ＣＲＣ信号と同様に、Ｇｅｎ＿Ｒｅｓｅｔ信号、Ｃｈｅｃｋ＿ＣＲＣ＿Ｎｏｗ信号、Ｇｅｎｅｒａｔｅ＿ＣＲＣ＿Ｎｏｗ信号及びＳｅｎｄｉｎｇ＿ＭＤＤＩ＿Ｄａｔａ信号の状態（０又は１）と共に図３７Ａに示されている。データのパケットの受信及びＣＲＣ値のチェックは、Ｒｘ＿ＭＤＤＩ＿Ｄａｔａ信号とＣＲＣエラー信号と同様に、Ｇｅｎ＿Ｒｅｓｅｔ信号、Ｃｈｅｃｋ＿ＣＲＣ＿Ｎｏｗ信号、Ｇｅｎｅｒａｔｅ＿ＣＲＣ＿Ｎｏｗ信号、及びＳｅｎｄｉｎｇ＿ＭＤＤＩ＿Ｄａｔａ信号の状態と共に図３７Ｂに示されている。

Ｅ．パケットＣＲＣのためのエラーコードオーバロード
データパケットとＣＲＣだけがホストとクライアントの間で転送されているときはつねに、対処されているエラーコードはない。唯一のエラーは同期の損失である。それ以外の場合、リンクが良好なデータ転送経路又はパイプラインの欠如からタイムアウトするのを待機してから、リンクをリセットし、先に進まなければならない。残念なことに、これは多大な時間を必要とし、いくぶん非効率である。

一実施形態で使用するために、パケットのＣＲＣ部分がエラーコード情報を転送するために使用される新しい技法が開発された。これは概して図６５に示されている。すなわち、１つ又は複数のエラーコードが、通信処理又はリンクの内に発生する可能性のある特定の所定のエラー又は不具合を示すデータ転送を処理するプロセッサ又は装置によって作成される。エラーに遭遇すると、該適切なエラーコードが作成され、パケットのＣＲＣのためのビットを使用して転送される。つまり、ＣＲＣ値はＣＲＣフィールドの値を監視するエラーモニタ又はチェッカによって受信端で検出できる所望されるエラーコードと共にオーバロードされるか、上書きされる。エラーコードが何らかの理由からＣＲＣ値に一致するケースでは、エラーの賛辞（ｃｏｍｐｌｉｍｅｎｔ）が混乱を妨げるために転送される。

一実施形態では、ロバストなエラー警告検出システムを提供するために、エラーコードは、エラー検出後に転送又は送信される一連のパケット、通常はすべてを使用して数回転送されてよい。これは、エラーを生じさせた状態がシステムから取り除かれる点まで発生し、その点で規則正しいＣＲＣビットが別の値にオーバロードされることなく転送される。

ＣＲＣ値をオーバロードするこの技法は、最小量の余分なビット又はフィールドを使用する一方でシステムエラーに対するはるかに迅速な対応を提供する。

図６６に示されているように、前述された、あるいは公知の他の回路網の一部を形成できるエラー検出器又は検出手段６６０２を使用し、通信リンク又はプロセスの中でのエラーの存在又は実在を検出する、ＣＲＣ上書き機構又は装置６６００が示されている。他の回路網の一部として形成できるあるいは、事前に選択されるエラーメッセージを記憶するためにルックアップテーブル等の技法を使用することができるエラーコードジェネレータ又は手段６６０４は、発生中として検出された特定の所定のエラー又は不具合を示すために１つ又は複数のエラーコードを作成する。デバイス６６０２と６６０４が、所望されるように、単一の回路又は装置として、あるいは他の公知のプロセッサと要素のためのステップのプログラミングされたステップの一部として形成できることは容易に理解される。

１つ又は複数の選択されたエラーコードが転送されているＣＲＣ値と同じであるかどうかを確かめるためにチェックするためのＣＲＣ値コンパレータ又は比較手段６６０６が示されている。そうである場合には、コード賛辞ジェネレータ又は生成手段又は装置が、元のＣＲＣパターン又は値と間違われないように、及び検出方式を混乱させたり、複雑化しないようにエラーコードの賛辞を提供するために使用される。エラーコードセレクタ又は選択手段要素又は装置６６１０は、挿入する、又は上書きすることが所望されるエラーコード又は値、あるいはそれらのそれぞれの賛辞を適宜に選択する。エラーコードＣＲＣオーバーラーター又は上書き機構又は手段６６１２は、挿入されるデータストリーム、パケット及び所望されるコードを受信し、所望されるエラーコードを受信側装置に転送するために対応する又は適切なＣＲＣ値を上書きする装置である。

言及されたように、エラーコードは一連のパケットを使用して数回転送されてよいため、オーバーライター６６１２は、処理中にコードのコピーを維持するためにメモリ記憶素子を活用する、あるいは必要に応じて、又は所望されるようにその値を記憶する又は保持するために使用できる過去の要素又は他の公知の記憶ロケーションからこれらのコードをリコールしてよい。

図６６の汎用処理、上書き機構が実現している、さらに詳細に図６７Ａと図６７Ｂに示されている。図６７Ａでは、１つ又は複数のエラーが、通信データ又はプロセスのステップ６７０２で検出され、この状態を示すためにステップ６７０４でエラーコードが選択される。同時に、又は適切な時点で、置換されるＣＲＣ値はステップ６７０６でチェックされ、ステップ６７０８で所望されるエラーに比較される。この比較の結果は、前述されたように、所望されたコード又は他の代表的な値が存在するＣＲＣ値と同じであるかどうかに関する決定である。これが当てはまる場合、処理は、賛辞、あるいはいくつかのケースでは所望されるように別の代表値が挿入するためのコードとして選択されるステップ６７１２に進む。どのエラーコード又は値がステップ６７１０と６７１４で挿入されなければならないのかがいったん決定されると、その適切なコードが挿入のために選択される。これらのステップは明確にするために別々として描かれているが、通常はステップ６７０８の決定の出力に基づいた単一の選択である。最後に、ステップ６７１６では、パケットがプロセスのターゲットとされている状態での転送のために、適切な値がＣＲＣロケーションで上書きされる。

図６７Ｂに示されるように、パケット受信側では、パケットＣＲＣ値はステップ６７２２で監視されている。一般的に、ＣＲＣ値は、データ転送のエラーが発生したかどうか、及び１つ又は複数のパケットの再送を要求するか否か、あるいは追加の動作を抑制するかどうか等を判断するためにシステム内は１つ又は複数のプロセスに監視されており、そのうちのいくつかは前述されている。情報はこのような監視の一部として値を公知の又は事前に選択されたエラーコード又は代表的な値に比較し、エラーの存在を検出するためにも使用できる。代わりに、別個のエラー検出プロセスとモニタが実現できる。コードが存在すると考えられる場合に、それは抽出され、あるいはそれ以外の場合は追加の処理のためにステップ６７２４で注記される。これが実際のコードであるのか否か、あるいは賛辞であるのか否かに関する決定はステップ６７２６で下すことができ、その場合、追加ステップ６７２８が値を所望されるコード値に変換するために使用される。どちらのケースでも結果として生じる抽出コード、賛辞、又は他の回復された値は、次にステップ６７３０で送信されたコードからどのようなエラーが発生したのかを検出するために使用される。

Ｖ．リンクハイバネーション
ＭＤＤＩリンクは、迅速にハイバーネーション状態に入り、ハイバーネーション状態から迅速にウェイクアップすることができる。この応答性によって、通信システム又はデバイスは、ＭＤＤＩリンクをハイバーネーションに頻繁に入れて、電力消費を低減させることが可能となる。なぜなら、使用のために極めて迅速に再びウェイクアップすることができるからである。一つの実施形態では、外部モードクライアントが、初めてハイバーネーションからウェイクアップすると、データレートにおいて、１Ｍｂｐｓレートに一致したストローブパルスタイミングでそうする。すなわち、ＭＤＤＩ＿Ｓｔｂペアは、５００ｋＨｚレートでトグルすべきである。一旦、クライアントの特徴がホストによって発見、あるいはホストに通知されると、ホストは一般に、１Ｍｂｐｓから、クライアントが動作できる最大レートまでの任意のレートでリンクをウェイクアップさせる。内部モードクライアントは、ホストとクライアントとの両方が動作可能な任意のレートでウェイクアップする。これは一般に、内部モードクライアントがウェイクアップした最初の時にも適用可能である。

一つの実施形態では、リンクがハイバーネーションからウェイクアップした時、ホストとクライアントとはパルスのシーケンスを交換する。これらのパルスは、最大リンク動作速度において信号を受信することが要求される差分受信機として、電流のほんの一部のみを消費する低速ライン受信機を用いて検出することができる。ホスト又はクライアントの何れか一方が、リンクをウェイクアップさせることができるので、ウェイクアッププロトコルは、もしもホストとクライアントとの両方が同時にウェイクアップを試みる場合に発生しうる可能な競合を取り扱うように設計される。

リンクが、ハイバーネーション状態である、あるいはハイバーネーション状態を続ける間、ＭＤＤＩ＿ＤａｔａとＭＤＤＩ＿Ｓｔｂとの差分ドライバが高インピーダンス状態でディスエーブルされ、全ての差分ペアの間の差分電圧はゼロボルトである。ハイバーネーションからのウェイクアップの間にパルスのシーケンスを検出するために使用される差分ライン受信機は、意図的な電圧オフセットを持っている。一つの実施形態では、これら受信機における論理１レベルと論理０レベルとの間の閾値は、約１２５ｍＶである。これは、リンクウェイクアップシーケンスの間、論理ゼロレベルとして見られる駆動されない差分ペアをもたらす。しかしながら、熟練者が理解するように、差分ドライバによって駆動される通常の論理１レベルは、依然として、１２５ｍＶオフセットを有する差分受信機によって、論理１レベルとして解釈される。ゼロ入力オフセットを持つ標準的な差分受信機と比較して、１２５ｍＶオフセットを持つ特別な低電力差分受信機の挙動の例が図３８に示されている。この波形は、一般的なＭＤＤＩ信号の代表ではないが、ここでは、２種類の差分受信機間の相違を明確化、すなわち例示するためにのみ示される。

ハイバーネーション状態に入るためには、リンクシャットダウンパケットのＣＲＣの後、ホストが６４ＭＤＤＩ＿Ｓｔｂサイクルを送る。ホストは、ＣＲＣの後、１６から５６ＭＤＤＩ＿Ｓｔｂサイクルの範囲にあるホストのＭＤＤＩ＿Ｄａｔａ０出力をディスエーブルにする（出力ディスエーブル伝搬遅延を含む）。ホストは、リンクシャットダウンパケットのＣＲＣの後、ウェイクアップシーケンスを開始する前に、６４ＭＤＤＩ＿Ｓｔｂサイクルを送ることを完了する。一つの実施形態では、ホストによるウェイクアップの開始は、ＭＤＤＩ＿Ｓｔｂ上でパルスを駆動する前、ＭＤＤＩ＿Ｄａｔａ０が有効な論理１レベルに達した後、少なくとも１００ｎｓ待つ必要があるホストとして定義される。一つの実施形態では、クライアントは、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動してホストをウェイクアップさせることを試みる前に、リンクシャットダウンンパケットのＣＲＣの後、少なくとも６０ＭＤＤＩ＿Ｓｔｂサイクル待つ。

ハイバーネーション状態から「ウェイクアップ」するためには、幾つかの動作又は処理が行われる。他の期間も所望されるように使用できるが、ＭＤＤＩ＿Ｓｔｂは、ＭＤＤＩ＿Ｓｔｂがアクティブになった後に、非アクティブであり、約７０ＭＤＤＩ＿Ｓｔｂサイクル（６０から８０の範囲にわたって）の間、論理１レベルに駆動されたＭＤＤＩ＿Ｄａｔａ０を保つが、クライアント、ここではディスプレイはデータ又は通信、サービスをホストから必要とするとき、約７０μｓｅｃから１０００μｓｅｃの間、ＭＤＤＩ＿Ｄａｔａ０線路を論理１状態に駆動することによって要求パルスを生成する。次にクライアントは、高インピーダンス状態にすることによりＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルする。

可能性は低いがＭＤＤＩ＿Ｓｔｂがハイバネーション中にアクティブである場合は、クライアントは７０ＭＤＤＩ＿Ｓｔｂサイクルの間（６０から８０の範囲にわたって）論理１状態にＭＤＤＩ＿Ｄａｔａ０を駆動するに過ぎない可能性がある。この動作により、ホストは順方向リンク（２０８）でデータトラフィックを起動又は再起動し、そのステータスについてクライアントをポーリングする。

ホストは要求パルスの存在を検出してから、まず、ＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに、ＭＤＤＩ＿Ｄａｔａ０を論理高レベルに、少なくとも約２００ｎｓ駆動する起動シーケンスを開始しなければならない。そして、トグル中、ＭＤＤＩ＿Ｓｔｂは、約１５０ＭＤＤＩ＿Ｓｔｂサイクル（１４０から１６０の範囲）の間、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに、約５０ＭＤＤＩ＿Ｓｔｂサイクルの間、論理ゼロに駆動し続ける。クライアントは、論理１状態で８０ＭＤＤＩ_Ｓｔｂサイクルを超えてＭＤＤＩ＿Ｄａｔａ０を検出する場合にサービス要求パルスを送信してはならない。クライアントが、６０〜８０ＭＤＤＩ＿Ｓｔｂサイクルの間、論理１レベルにおいてＭＤＤＩ＿Ｄａｔａ０を検出した時、ホストが、５０ＭＤＤＩ＿Ｓｔｂサイクルの間、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動した間隔を探索し始める。ホストが、５０ＭＤＤＩ＿Ｓｔｂサイクルの持続時間の間、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動した後、ホストは、リンク上でパケットを送り始める。送られる最初のパケットはサブフレームヘッダパケットである。クライアントは、５０サイクル間隔の４０ＭＤＤＩ＿Ｓｔｂサイクルの間、ＭＤＤＩ＿Ｄａｔａ０が、論理ゼロレベルであった後、サブフレームヘッダパケットを探索し始める。ハイバネーション処理と起動シーケンスに関連する時間の選択及び時間間隔の公差の性質は後述されるとおりである（以下の６８Ａ−Ｃを参照すること）。

ホストは、まずＭＤＤＩ＿Ｓｔｂをイネーブルすることによってウェイクアップを開始し、同時にそれを論路ゼロレベルに駆動する。ＭＤＤＩ＿Ｓｔｂは、以下に述べるように、パルスが出力されるまで、論理１レベルに駆動されるべきではない。ＭＤＤＩ＿Ｓｔｂが論理ゼロレベルに達した後、ホストはＭＤＤＩ＿Ｄａｔａ０をイネーブルし、同時にそれを論理１レベルに駆動する。ＭＤＤＩ＿Ｄａｔａ０は、ウェイクアッププロセスの間、以下に述べるように、５０ＭＤＤＩ＿Ｓｔｂパルスの期間中、論理ゼロレベルに駆動される期間まで論理ゼロレベルに駆動されるべきではない。ホストは、ＭＤＤＩ＿Ｓｔｂ上でパルスを駆動する前、ＭＤＤＩ＿Ｄａｔａ０が有効な論理１レベルに達した後、少なくとも２００ｎｓ待つべきである。この時間関係は、最悪ケースの出力可能遅延を考慮している間に起こる。これは、ホストによって駆動されたＭＤＤＩ＿Ｄａｔａ０上の論理１レベルによってアウェイクされた後にＭＤＤＩ＿Ｓｔｂ受信機を完全にイネーブルにするための十分な時間をクライアントが持っていることを実質的に保証する。

競合状態のない典型的なクライアントサービス要求イベント３８００のための処理ステップの例は、イベントが文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ及びＧを使用して図解の便宜上名付けられている図３９Ａに描かれている。プロセスは、ホストがクライアントデバイスに、リンクが低電力ハイバネーション状態に遷移することをそれに知らせるために、リンクシャットダウンパケットを送信するときに点Ａで開始する。次のステップで、ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルし、ＭＤＤＩ＿Ｓｔｂドライバを点Ｂで示されるように論理ゼロに設定することによって低電力ハイバネーション状態に入る。ＭＤＤＩ＿Ｄａｔａ０は高インピーダンスバイアスネットワークによって論理ゼロレベルに駆動される。しばらくしてから、クライアントはＭＤＤＩ＿Ｄａｔａ０を、点Ｃで見られるような論理１レベルに駆動することによってサービス要求パルスをホストに送信する。ホストは高インピーダンスバイアスネットワークを使用して依然として論理ゼロレベルをアサートするが、クライアントの中のドライバが強制的に回線を論理１レベルにする。５０μｓｅｃ以内にホストはサービス要求パルスを認識し、点Ｄで見られるように、そのドライバをイネーブルすることによってＭＤＤＩ＿Ｄａｔａ０上で論理１レベルをアサートする。次に、クライアントはサービス要求パルスをアサートしようとするのやめ、クライアントは点Ｅで見られるように、そのドライバを高インピーダンス状態にする。ホストは、点Ｆで示されるように５０μｓｅｃの間ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、ＭＤＤＩ＿Ｄａｔａ０の論理ゼロレベルと一貫した方法でＭＤＤＩ＿Ｓｔｂを作成し始める。クライアントは、４０ＭＤＤＩ＿Ｓｔｂサイクルの間、ＭＤＤＩ＿Ｄａｔａ０が論理ゼロレベルにあった後、サブフレームヘッダパケットを探索し始める。ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルにアサートし、ＭＤＤＩ＿Ｓｔｂを５０μｓｅｃの間駆動した後に、ホストは点Ｇで示されるようにサブフレームヘッダパケットを送信することにより順方向リンクでデータの送信を開始する。

類似する例は、リンク再起動シーケンスが開始後にサービス要求がアサートされ、イベントがやはり文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ及びＧを使用して名付けられる図３９に示されている。これは、要求パルス又はクライアントからの信号がサブフレームヘッダパケットを破壊しそうになる最悪のケースのシナリオを表している。プロセスは、ホストがクライアントデバイスに、リンクが低電力ハイバネーション状態に遷移することをそれに知らせるために再びリンクシャットダウンパケットを送信するときに、点Ａで開始する。次のステップでは、ホストは、点Ｂで示されるように、ＭＤＩ＿Ｄａｔａ０ドライバをディスエーブルし、ＭＤＤＩ＿Ｓｔｂドライバを論理ゼロレベルに設定することによって低電力ハイバネーション状態に入る。前記のように、ＭＤＤＩ＿Ｄａｔａ０は、高インピーダンスバイアスネットワークによって論理ゼロレベルに駆動される。しばらくすると、ホストは、点Ｃで見られるように１５０μｓｅｃの間論理１レベルにＭＤＤＩ＿Ｄａｔａ０を駆動することによってリンク再起動シーケンスを開始する。リンク再起動シーケンス開始後５０μｓｅｃが経過する前に、ディスプレイは点Ｄで見られるように７０μｓｅｃの持続期間ＭＤＤＩ＿Ｄａｔａ０もアサートする。これは、ディスプレイがホストからのサービスを要求する必要があり、ホストがすでにリンク再起動シーケンスを開始したことを認識していないために発生する。次にクライアントはサービス要求パルスをアサートしようとすることをやめ、点Ｅで見られるように、クライアントはそのドライバを高インピーダンス状態にする。ホストは論理１レベルにＭＤＤＩ＿Ｄａｔａ０を駆動し続ける。ホストは点Ｆに示されているように、５０μｓｅｃの間ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、ＭＤＤＩ＿Ｄａｔａ０での論理ゼロレベルと一貫するようにＭＤＤＩ＿Ｓｔｂも作成し始める。ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルにアサートし、ＭＤＤＩ＿Ｓｔｂを５０μｓｅｃ駆動した後、ホストはサブフレームヘッダパケットを送信することにより順方向リンクでデータの送信を開始する。

前記説明から、過去の解決策が、スリープ解除シーケンスの一部としてホストに２つの状態を経験させることを必要としたことが分かる。第１の状態の場合、ホストは１５０μｓの間ＭＤＤＩ＿Ｄａｔａ０信号を高に駆動し、次に、ＭＤＤＩ＿Ｓｔｂ回線をアクティブ化する一方で５０μｓの間ＭＤＤＩ＿Ｄａｔａ０信号を低に駆動し、次にＭＤＤＩパケットの送信を開始する。このプロセスは、ＭＤＤＩ装置と方法を使用して達成可能なデータレートという点で最先端に進展するためにうまく働く。しかしながら、前述されたように、状態に対する応答時間の短縮又は次のステップ又はプロセスをより迅速に選択できるようにするという点でのさらなる速度は処理又は要素を簡略化する能力であり、つねに要求されている。

出願人は、ホストが信号トグルのためにクロックサイクルベースのタイミングを使用するスリープ解除処理及びタイミングに対する新しい発明の手法を発見した。この構成では、ホストは、ホストがスリーブ解除シーケンスの始まりにＭＤＤＩ＿Ｄａｔａ０信号を高に駆動してから０から１０μｓｅｃ、ＭＤＤＩ＿Ｓｔｂのトグルを開始し、信号が低に駆動されるまで待機しない。スリープ解除シーケンスの間、ホストは、ＭＤＤＩ＿Ｄａｔａ０信号がつねに論理ゼロレベルであるかのようにＭＤＤＩ＿Ｓｔｂをトグルする。これは事実上クライアント側から時間の概念を排除し、ホストは、最初の２つの状態のための過去の１５０μｓの期間と５０μｓの期間から、これらの期間の間の１５０クロックサイクルと５０クロックサイクルに変化する。

ホストはそのデータラインを高に駆動することに責任を持つようになり、１０−クロックサイクルのうちに、データラインがゼロであるかのようにストローブ信号の送信を開始する。ホストが１５０クロックサイクルの間データラインを高に駆動した後、ホストは、ストローブ信号の送信を続けながら５０クロックサイクルの間データラインを低に駆動する。ホストは、これらのプロセスの両方ともを完了後、最初のサブフレームヘッダパケットの送信を開始できる。

クライアント側では、クライアントインプリメンテーションは、ここでデータラインが最初は高く、次に低くなるクロックサイクル数を計算するために生成されたクロックを使用できる。データライン駆動高状態で発生する必要のあるクロックサイクル数は１５０であり、データライン駆動低状態で発生する必要のあるクロックサイクル数は５０である。つまり、適切なスリープ解除シーケンスのために、クライアントは、低であるデータ利案の少なくとも５０の連続クロックサイクルが後に続く、高であるデータラインの少なくとも１５０の連続クロックサイクルをカウントできなければならない。いったんこれらの２つの条件が満たされると、クライアントは第１のサブフレームの一意のワードの検索を開始できる。このパターンの中断は、カウンタを、クライアントが高であるデータラインの最初の１５０連続クロックサイクルを再び探す初期状態に戻すための基礎として使用される。

ハイバネーションからのホストベースのスリープ解除のための本発明のクライアントインプリメンテーションは、クロックレートが前述されたように１Ｍｂｐｓで強制的に開始されないことを除き、初期の起動ケースに非常に類似している。代わりに、クロックレートは、通信リンクがハイバネーションに入ったときにどのような過去の速度でアクティブであっても再開するために設定できる。ホストが前述されたようにストローブ信号の伝送を開始すると、クライアントは、低であるデータラインの少なくとも５０連続クロックサイクルが後に続く、高であるデータラインの少なくとも１５０連続クロックサイクルを再びカウントできなければならない。いったんこれらの２つの条件が満たされると、クライアントは一意のワードの検索を開始できる。

ハイバネーションからのクライアントベースのスリープ解除のための本発明のクライアントインプリメンテーションは、それがクライアントにデータラインを駆動させることによって起動するという点を除きホストベースのスリープ解除に類似している。クライアントはホストデバイスをスリープ解除するために、クロックを使用せずにデータラインを非同期で駆動できる。いったんホストが、データラインがクライアントによって高に駆動されていると認識すると、それはそのスリーブ解除シーケンスを開始できる。クライアントは、ホストがそのスリープ解除プロセスを開始することによって、あるいはそのスリープ解除プロセスの間に生成されるクロックサイクルの数をカウントできる。いったんクライアントが高であるデータの７０連続クロックサイクルをカウントすると、それはデータラインを高に駆動するのを停止できる。この点で、ホストはすでにデータラインも高にしているはずである。クライアントは、次に高であるデータラインの１５０クロックサイクルに達するために、高であるデータラインの別の８０連続クロックサイクルをカウントすることができ、次に低であるデータラインの５０クロックサイクルを探すことができる。いったんこれらの３つの条件が満たされると、クライアントは一意のワードを探し始めることができる。

スリープ解除処理のこの新しいインプリメンテーションの利点とは、それが時間測定装置に対する必要性を排除するという点である。これが発振器であるのか、あるいはコンデンサ式放電回路であるのか、あるいは他のこのような公知の装置であるのかに関係なく、クライアントは起動状態を確認するためにもはやこのような外部装置を必要としない。これにより、コントローラ、カウンタ等をクライアントデバイスボードで実現するときに資金と回路面積を節約する。これはクライアントにとって利点ではない可能性があるが、ホストにとってはこの技法はコア回路網のために使用される超高密度論理回路（ＶＨＤＬ）という点でホストを潜在的に簡略化するはずである。コア要素がホストベースのスリープ解除を待機するために外部回路網が実行している必要はないため、スリープ解除通知及び測定ソースとしてデータラインとストローブラインを使用することの電力消費も低くなる。使用されたサイクル又はクロック期間の数は例示的であり、他の期間は当業者に明らかとなるように使用できる。

スリープ解除処理のこの新しいインプリメンテーションの利点とは、それが時間測定装置に対する必要性を排除するという点である。これが発振器であるのか、あるいはコンデンサ式放電回路であるのか、あるいは他のこのような公知の装置であるのかに関係なく、クライアントは起動状態を確認するためにもはやこのような外部装置を必要としない。これにより、コントローラ、カウンタ等をクライアントデバイスボードで実現するときに資金と回路面積を節約する。これはクライアントにとって利点ではない可能性があるが、ホストにとってはこの技法はコア回路網のために使用される超高密度論理回路（ＶＨＤＬ）という点でホストを潜在的に簡略化するはずである。コア要素がホストベースのスリープ解除を待機するために外部回路網が実行している必要はないため、スリープ解除通知及び測定ソースとしてデータラインとストローブラインを使用することの電力消費も低くなる。

この新しい技法の動作を明確にし、説明するために、ＭＤＤＩ＿Ｄａｔａ０、ＭＤＤＩ＿Ｓｔｂ及びクロックサイクルに関する多様な動作のタイミングが図６８Ａ、図６８Ｂ及び図６８Ｃに示されている。

競合のない典型的なホスト起動型スリープ解除の処理ステップの例は、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ及びＧを使用して、イベントが図中再び便宜上名付けられている図６８Ａに示されている。プロセスは、ホストがクライアントデバイスに、それにリンクが低電力ハイバネーション状態に遷移することを知らせるためにリンクシャットダウンパケットを送信するときに点Ａで開始する。次のステップ、点Ｂでは、ホストは、ＭＤＤＩ＿Ｓｔｂがトグルするのを停止する前にクライアントによる処理を完了できるようにするために、約６４サイクル（あるいはシステム設計のために所望されるとおりに）ＭＤＤＩ＿Ｓｔｂをトグルし、クライアントデバイス内の回復したクロックを停止する。ホストは、当初ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに設定してから、ＭＤＤＩ＿Ｄａｔａ０出力を、ＣＲＣ後に１６サイクルから４８サイクル（通常は出力ディスエーブル伝播遅延を含む）の範囲でＭＤＤＩ＿Ｄａｔａ０出力をディスエーブルする。ＣＲＣから４８サイクル後、及び次の段階（Ｃ）の前にクライアント内のＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのための高速受信機を低電力状態にすることは望ましい場合がある。

ホストはＭＤＤＩ＿Ｄａｔａ０ドライバとＭＤＤＩ＿Ｓｔｂドライバをディスエーブルし、ホストコントローラを低電力ハイバネーション状態にすることによって点又はステップＣで低電力ハイバネーション状態に入る。所望されるように（高インピーダンスバイアスネットワークを使用して）ＭＤＤＩ＿Ｓｔｂドライバを論理ゼロレベルに設定する、あるいはハイバネーションの間トグルを続けることもできる。クライアントは低電力レベルハイバネーション状態にもある。

しばらくしてから、ホストはＭＤＤＩ＿Ｄａｔａ０ドライバ出力とＭＤＤＩ＿Ｓｔｂドライバ出力をイネーブルすることによって点Ｄでリンク再起動シーケンスを開始する。ホストは、ドライバがそのそれぞれの出力を完全にイネーブルするために要する時間の限り、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに、ＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに駆動する。ホストは、通常、ＭＭＤＩ＝Ｓｔｂｄｅパルスを駆動する前に、これらの出力が所望される論理レベルに達してから約２００ナノ秒待機する。これにより、受信を準備するためのクライアント時間が可能になる。

ホストドライブがイネーブルされ、ＭＤＤＩ＿Ｄａｔａ０が論理１レベルに駆動されている状態で、ホストは、点Ｅで見られるように１５０ＭＤＤＩ＿Ｓｔｂサイクルの持続期間中ＭＤＤＩ＿Ｓｔｂのトグルを開始する。ホストは、点Ｆで示されているように５０サイクル、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、クライアントは、ＭＤＤＩ＿Ｄａｔａ０が４０ＭＤＤＩ＿Ｓｔｂサイクルの間論理ゼロレベルにあった後にサブフレームヘッダパケットを探し始める。ホストは、点Ｇで示されているようにサブフレームヘッダパケットを送信することによって順方向リンクでデータ送信を開始する。

競合のない典型的なホスト起動型スリープ解除の処理ステップの例は、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ及びＩを使用して、イベントが図中再び便宜上名付けられている図６８Ｂに示されている。前記のように、プロセスは、ホストがクライアントに、それにリンクが低電力状態に遷移することを知らせるためにリンクシャットダウンパケットを送信するときに点Ａで開始する。

点Ｂでは、ホストは、ＭＤＤＩ＿Ｓｔｂがトグルするのを停止する前にクライアントによる処理を完了できるようにするために約６４サイクル（又はシステム設計のために所望されるとおりに）ＭＤＤＩ＿Ｓｔｂをトグルし、クライアントデバイス内の回復されたクロックを停止する。ホストは当初ＭＤＤＩ＿Ｄａｔａ０も論理ゼロレベルに設定し、次にＣＲＣ後に１６から４８サイクル（通常は出力ディスエーブル伝搬遅延を含む）の範囲でＭＤＤＩ＿Ｄａｔａ０出力をディスエーブルする。ＣＲＣ後の４８サイクルの後で、次の段階（Ｃ）の前に、クライアント内のＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのための高速受信機を低電力状態にすることが望ましい場合がある。クライアントは、リンクシャットダウンパケットのＣＲＣの後、４８番目のＭＤＤＩ＿Ｓｔｂサイクルの上昇端の後の任意の時間に、ＭＤＤＩ＿Ｄａｔａ０及びＭＤＤＩ＿Ｓｔｂのための高速受信機をハイバーネーションにする。クライアントが、リンクシャットダウンパケットのＣＲＣの後、６４番目のＭＤＤＩ＿Ｓｔｂサイクルの上昇端の前の任意の時間に、ＭＤＤＩ＿Ｄａｔａ０及びＭＤＤＩ＿Ｓｔｂのための高速受信機をハイバーネーションにすることが推奨される。

ホストはＭＤＤＩ＿Ｄａｔａ０ドライバとＭＤＤＩ＿Ｓｔｂドライバをディスエーブルし、ホストコントローラを低電力ハイバネーション状態にすることによって点つまりステップＣで低電力ハイバネーション状態に入る。所望されるように、（高インピーダンスバイアスネットワークを使用して）ＭＤＤＩ＿Ｓｔｂドライバを論理ゼロレベルに設定すること、あるいはハイバネーションの間トグルし続けることもできる。クライアントも低電力レベルハイバネーション状態にある。

しばらくしてから、クライアントは、ＭＤＤＩ＿Ｓｔｂ受信機をイネーブルし、ＭＤＤＩ＿Ｓｔｂの受信されたバージョンが、ホストがそのＭＤＤＩ＿Ｓｔｂドライバをイネーブルする前にクライアントの論理ゼロレベルにあると保証するためにＭＤＤＩ＿Ｓｔｂ受信機でオフセットをイネーブルすることによっても点Ｄでリンク再起動シーケンスを開始する。所望されるように有効な差動信号の受信を保証し、誤りのある信号を抑止するために、クライアントが、受信機をイネーブルするのよりわずかに先にオフセットをイネーブルすることが望ましい場合がある。クライアントは、ＭＤＤＩ＿Ｄａｔａ０ラインを論理１レベルに駆動する一方でＭＤＤＩ＿Ｄａｔａ０ドライバをイネーブルする。オフセットをイネーブルし、標準的なＭＤＤＩ＿Ｓｔｂ差分受信機をイネーブルする時間が２００ｎｓ未満である場合、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂとが同時にイネーブルされることが許可される。

約１ｍｓｅｃ以内、点Ｅ内に、ホストはクライアントからのサービス要求パルスを認識し、ホストはＭＤＤＩ＿Ｄａｔａ０ドライバ出力とＭＤＤＩ＿Ｓｔｂドライバ出力をイネーブルすることによってリンク再起動シーケンスを開始する。ホストは、ドライバがそのそれぞれの出力をイネーブルするのにかかる限り、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに、ＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに駆動する。ホストは通常、ＭＤＤＩ＿Ｓｔｂでパルスを駆動する前に、これらの出力が所望される論理レベルに達してから約２００ナノ秒待機する。これによりクライアントに受信に備える時間が与えられる。

ホストドライバがイネーブルされ、ＭＤＤＩ＿Ｄａｔａ０が論理１レベルに駆動されている状態で、ホストは、点Ｆで見られるように１５０ＭＤＤＩ＿Ｓｔｂサイクルの持続期間、ＭＤＤＩ＿Ｓｔｂでパルスを出力し始める。クライアントは、ＭＤＤＩ＿Ｓｔｂで最初のパルスを認識すると、そのＭＤＤＩ＿Ｓｔｂ受信機でオフセットをディスエーブルする。クライアントは７０ＭＤＤＩ＿Ｓｔｂサイクルの間論理１レベルにＭＤＤＩ＿Ｄａｔａ０を駆動し続け、点ＧでＭＤＤＩ＿Ｄａｔ０ドライバをディスエーブルする。ホストは、更に８０ＭＤＤＩ＿Ｓｔｂパルスの間、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動し続け、点Ｈにおいて、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動する。

点ＧとＨで見られるように、ホストは５０サイクルの間ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、クライアントは、ＭＤＤＩ＿Ｄａｔａ０が４０ＭＤＤＩ＿Ｓｔｂサイクルの間論理ゼロレベルにあった後サブフレームヘッダパケットを探し始める。ＭＤＤＩ＿Ｓｔｂを５０サイクルの間駆動した後、ホストは、点Ｉで見られるようにサブフレームヘッダパケットを送信することにより順方向リンクでデータ送信を開始する。

クライアントから競合がある、つまりクライアントもリンクをスリープ解除することを希望する典型的なホスト起動型スリーブ解除のための処理ステップの例は、図６８Ｃに示されている。イベントは、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ及びＩを使用して図中、便宜上再び名付けられる。前記のように、プロセスは、ホストがクライアントに、リンクが低電力状態に遷移することを知らせるためにリンクシャットダウンパケットを送信するときに点Ａで開始し、クライアントによる処理を完了できるようにするために、ＭＤＤＩ＿Ｓｔｂが約６４サイクルの間（又はシステム設計のために所望されるとおりに）トグルされる点Ｂに進み、それから、ＭＤＤＩ＿Ｄａｔａ０ドライバとＭＤＤＩ＿Ｓｔｂドライバをディスエーブルし、ホストコントローラを低電力ハイバネーション状態にすることによってホストが低電力ハイバネーション状態に入る点Ｃに進む。しばらくしてから、ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバ出力とＭＤＤＩ＿Ｓｔｂドライバ出力をイネーブルすることによって点Ｄでリンク再起動シーケンスを開始し、点Ｅで見られるように１５０ＭＤＤＩ＿Ｓｔｂサイクルの期間、ＭＤＤＩ＿Ｓｔｂのトグルを開始する。

点Ｅの後最大７０ＭＤＤＩ＿Ｓｔｂサイクルで、ここでは点Ｆで、クライアントはまだ、ホストが論理１レベルにＭＤＤＩ＿Ｄａｔａ０を駆動していることを認識していないため、クライアントもＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動する。これは、クライアントがサービスしたいという望みを有するが、それが通信しようとしているホストがすでにリンク再起動シーケンスを開始していることを認識していないためにここで発生する。点Ｇでは、クライアントはＭＤＤＩ＿Ｄａｔａ０を駆動するのをやめ、その出力をディスエーブルすることによってそのドライバを高インピーダンス状態にする。ホストは、追加の８０サイクルＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動し続ける。

ホストは、点Ｈで示されているように５０サイクルの間、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、クライアントは、ＭＤＩ＿Ｄａｔａ０が４０ ＭＤＤ＿Ｓｔｂサイクルの間論理ゼロレベルにあった後にサブフレームヘッダパケットを探し始める。ホストは点Ｉに示されているようにサブフレームヘッダパケットを送信することによって順方向リンクでデータの転送を開始する。

ＶＩ．インタフェース電気仕様
例の実施形態では、非ゼロ復帰（ＮＲＺ）フォーマットは、クロック情報をデータ信号とストローブ信号の中に埋め込むことを可能にするデータ−ストローブ信号又はＤＡＴＡ−ＳＴＢフォーマットを使用して符号化される。クロックは、複雑な移送ロックループ回路網を使用しなくても回復できる。前述されたように他の導線、プリント配線、又は転送要素を使用することもできるが、データは双方向差動リンク上で伝搬され、通常ワイヤラインケーブルを使用して実現される。ストローブ（ＳＴＢ）信号は、ホストによってのみ駆動される単向性のリンク上で伝搬される。ストローブ信号は、データライン又は信号上で同じままとなる連続状態０又は１があるときはつねに値（０又は１）をトグルする。

ビット「１１１０００１０１１」等のデータシーケンスをＤＡＴＡ−ＳＴＢ符号化を使用してどのようにして送信できるのかの例は図４０にグラフ形状で示されている。図４０では、ＤＡＴＡ（データ）信号４００２は、信号タイミングチャートの一番上の行に示され、ＳＴＢ（ストローブ）信号４００４は２番目の行に示され、毎回適宜に位置合わせされている（共通開始点）。時間が過ぎるにつれて、データライン４００２（信号）で状態の変化が発生し、次にＳＴＢ（ストローブ）ライン４００４（信号）が過去の状態を維持し、このようにしてデータ信号の第１の「１」状態は、その開始値であるＳＴＢ（ストローブ）信号の最初の「０」状態と相関する。しかしながら、もしデータ信号の状態、レベルが変化しないときには、データが別の「１」値を提供する図４０のケースと同様に、ＳＴＢ信号は本例で反対の状態つまり「１」にトグルする。つまり、ＤＡＴＡとＳＴＢの間にはビットサイクルあたりただ１つの遷移しかない。したがって、ＤＡＴＡ（データ）信号が「１」でとどまるのでＳＴＢ信号は再び、今回は「０」に遷移し、ＤＡＴＡ（データ）信号がレベルを「０」に変えると、このレベル又は値を保持する。データ（ＤＡＴＡ）信号が「１」にとどまるときには、ＤＡＴＡ（データ）信号が変化する、あるいはレベル又は値を保持するので、ＳＴＢ（ストローブ）信号は本例では反対の状態、つまり「１」にトグルする等である。

これらの信号を受信すると、排他的ＯＲ（ＸＯＲ）演算が、所望されるデータ信号とストローブ信号との相対比較のためにタイミングチャートの下部に示されている、クロック信号４００６を作成するためにＤＡＴＡ（データ）信号とＳＴＢ（ストローブ）信号で実行される。ホストにある入力データからＤＡＴＡ（データ）出力又は信号とＳＴＢ（ストローブ）出力又は信号を生成し、次にクライアントにあるデータからＤＡＴＡ（データ）信号とＳＴＢ（ストローブ）信号を回復する又は捕捉しなおすための有効な回路網の例は図４１に示されている。

ＤＡＴＡについて生じる状態の変化がある場合には、ＳＴＢは、前の状態を維持する。しかしながら、ＤＡＴＡが変化しない場合には、ＳＴＢは、反対の状態に対してトグルする。言い換えると、ＤＡＴＡとＳＴＢとの間では、常にビットサイクル毎に１つで唯一の遷移が存在する。リンクの受信端では、クロック信号（図４０におけるＣＬＫ信号）が、ＤＡＴＡ及びＳＴＢの排他的ＯＲを実行することによって生成される。データストローブ符号の使用は、データ及びクロックを使用する従来システムに対する利点を有する。なぜなら、データストローブ符号信号は、データ及びクロックを使用するシステムに比べて、歪みを遅延するのに約２倍許容性があるからである。ＭＤＤＩ＿Ｓｔｂ＋／−における歪みは、ＭＤＤＩ＿Ｄａｔａ０＋／−及びＭＤＤＩ＿Ｓｔｂ＋／−の接続を通じた遅延による差分と同様に、ホスト及びクライアントにおけるドライバと受信機とを通じた経路遅延による差分によって生じうる。ＭＤＤＩ＿Ｄａｔａ０＋／−及びＭＤＤＩ＿Ｓｔｂ＋／−経路における歪み及びその他の欠点によって悪影響を受けるタイミングの定量的な解析は、後に詳述する。

２型、３型、及び４型モードの場合、ＭＤＤＩ＿Ｄａｔａ０＋／−及びＭＤＤＩ＿Ｓｔｂ＋／−は、それらが、ビットサイクル毎に１つで唯一の遷移を持つという特性をもつ１型と同じように動作する。その他のＭＤＤＩ＿Ｄａｔａ信号は、ＭＤＤＩ＿Ｄａｔａ０と同じレート及び位相でデータを渡す。ＭＤＤＩ＿Ｄａｔａ０＋／−及びＭＤＤＩ＿Ｓｔｂ＋／−の排他的ＯＲから生成されるクライアントにおける復元されたクロックもまた、ＭＤＤＩ＿Ｄａｔａ０１＋／−乃至ＭＤＤＩ＿Ｄａｔａ０７＋／−をサンプルするために使用される。

入力データからＤＡＴＡ及びＳＴＢを生成し、次に、ＤＡＴＡ及びＳＴＢから入力データを復元するために利用可能な典型的な回路を、図４１に示す。図４１では、送信部分４１００は、中間信号経路４１０２を介してオリジナルのＤＡＴＡ及びＳＴＢを生成し、送信するために使用される。一方、受信部分４１２０は、信号を受信し、データを復元するために使用される。図４１に示すように、ホストからクライアントへデータを転送するために、ＤＡＴＡ信号が、回路をトリガするクロック信号とともに、２つのＤ型フリップフロップ回路素子４１０４，４１０６に入力される。２つのフリップフロップ回路出力（Ｑ）は、その後、差分ラインドライバ４１０８，４１１０（電圧モード）を用いて、ＭＤＤＩ＿Ｄａｔａ０＋とＭＤＤＩ＿Ｄａｔａ０−、及び、ＭＤＤＩ＿Ｓｔｂ＋とＭＤＤＩ＿Ｓｔｂ−の信号の差分ペアにそれぞれ分割される。３入力排他的ＮＯＲ（ＸＮＯＲ）ゲート、回路、又は論理素子４１１２は、両方のフリップフロップのＤＡＴＡ（データ）と出力を受信するために接続され、同様にＭＤＤＩ＿Ｓｔｂ＋信号、ＭＤＤＩ＿Ｓｔｂ−信号を生成する第２のフリップフロップにデータ入力を提供する出力を生成する。便宜上、ＸＮＯＲゲートは、それが事実上ストローブを生成するフリップフロップのＱ出力を反転していることを示すために反転バブル（ｉｎｖｅｒｓｉｏｎ ｂｕｂｂｌｅ）を設置させる。

図４１の受信部分４１２０では、ＭＤＤＩ＿Ｄａｔａ０＋信号、ＭＤＤＩ＿Ｄａｔａ０−信号及びＭＤＤＩ＿Ｓｔｂ＋信号、ＭＤＤＩ＿Ｓｔｂ−信号が、差動信号から単一の出力を生成する２台の差動ラインレシーバ４１２２と４１２４のそれぞれにより受信される。増幅器の出力は次に２入力排他的ＯＲ（ＸＯＲ）ゲート、回路、又はクロック信号を発生させる論理素子４１２６の入力のそれぞれに入力される。該クロック信号は、遅延素子４１３２を通してＤＡＴＡ（データ）信号の遅延バージョンを受信する２つのＤ型フリップフロップ回路４１２８と４１３０のそれぞれをトリガするために使用され、その内の一方（４１２８）がデータ「０」値を生じさせ、他方（４１３０）がデータ「１」値を生じさせる。クロックはＸＯＲ論理から独立した出力も有する。クロック情報はＤＡＴＡ（データ）回線とＳＴＢ（ストローブ）回線の間で分配されるため、どちらの信号も、クロックレートの半分より高速な状態の間で遷移しない。クロックはＤＡＴＡ（データ）信号とＳＴＢ（ストローブ）信号の排他的ＯＲ処理を使用して再生されるため、システムは、事実上、クロック信号が単一の専用データラインで直接的に送信されるときの状況に比べて、入力データとクロック間の二倍の量の歪みに耐えている。

図４１又は図５７で例示されるデータ復元回路における遅延素子は、従来のクロック−データ通信リンクのために一般に使用される同期データキャプチャ回路とは異なり、実装することがより挑戦的である。しかしながら、データ−ストローブ符号によって、遅延歪み校正を使用する必要なく、データレートを約２倍にすることが可能となる。データ復元回路の素子の重大な伝搬遅延は、同じ回路内の他の遅延と関連しているので、達成することが容易である。これは、例えばＩ／Ｏパッド回路における単純な論理素子を用いることによって、カスタム回路内に容易に実装することができる。なぜなら、他の経路における遅延よりも長い遅延を持つ経路を生成することのみが必要だからである。

ＭＤＤＩデータペア、つまりＭＤＤＩ＿Ｓｔｂ＋信号とＭＤＤＩ＿Ｓｔｂ−信号は、雑音の負の影響からの免疫を最大限にするために差動モードで運用される。各差分ペアは、信号を伝送するために使用されるケーブル又は導電体の特性インピーダンスで並列終端されている。一般に、全ての並列終端は、クライアントデバイス内に存在する。これは、順方向トラフィック（ホストからクライアントに送られたデータ）の場合の差分受信機に近いが、それは、逆方向トラフィック（クライアントからホストに送られたデータ）の場合のケーブル又はその他の導電体、又は転送要素の駆動端にある。逆方向トラフィックの場合、信号はクライアントによって駆動され、ホストにおいて高インピーダンス受信機によって反射され、クライアントにおいて終端される。上述したように逆方向リンクによるデータ又は逆方向データは、ケーブル内における往復遅延の逆数より大きいデータレートで転送または送られうる。ＭＤＤＩ＿Ｓｔｂ＋信号とＭＤＤＩ＿Ｓｔｂ−信号はホストによってのみ駆動される。

本発明のＭＤＤＩの一部として信号を転送するためのドライバ、受信機及び終端を達成するために有効な要素の例示的な構成は図４２Ａに示されている。この例示的なインタフェースは、１ボルト未満の脱調と低電力排出で低圧感知、ここでは２００ｍＶを使用する。各信号ペアのドライバは、差分電流出力を持つ。ＭＤＤＩパケットを受信している間、ＭＤＤＩ＿ＤａｔａとＭＤＤＩ＿Ｓｔｂとのペアは、ゼロボルトの差分電圧閾値を持つ従来式の差分受信機を用いる。ハイバーネーション状態では、ドライバ出力がディセーブルされ、並列終端抵抗が、各信号ペアにおける差分電圧をゼロボルトにする。ハイバーネーションの間、ＭＤＤＩ＿Ｄａｔａ０ペア上の特別の受信機は、正の１２５ｍＶのオフセット入力差分電圧閾値をもつ。これは、ハイバーネーションライン受信機に対して、駆動されていない信号ペアを、論理ゼロレベルとして解釈させる。

差分ペアの差分電圧は、正（＋）の信号についての電圧から、負（−）の信号についての電圧を引いた差として定義される。“＋”又は“−”の何れかを用いた差分ペア信号の名前は、ペアの正の信号、又は負の信号をそれぞれ示す。差分ペアのドライバの出力電流は、正（＋）の出力の電流フローとして定義される。差分ドライバの負（−）の出力を通る電流は、常に大きさが等しいが、同じ差分ドライバの正（＋）の出力を通る電流と反対方向である。

本発明の幾つかの実施形態に従って実施するために利用可能な差分電流モードドライバのブロック図の一例を図４２Ｂに示す。切り替えられた差分出力段階は、現在のソースを、正又は負の何れかのドライバ出力に経路付ける。０．３５ボルトの電圧ソースは、測定された出力電圧を、グランドに対して、常に０．３５ボルト以上に維持する。

しばしばホスト又はクライアントは、データ流れ方向が変わった時（ホストからクライアント、又はクライアントからホスト）に、ペア上の有効な論理レベルを保証するために、差分ペアを、論理１レベル又は論理ゼロレベルへ同時に駆動する。出力電圧範囲と出力仕様とは、同じ論理レベルに駆動された同時駆動された出力によって満足されている。あるシステムでは、ハイバーネーションの間、及びリンクがハイバーネーション状態からウェイクアップしたときのうちのある時間において、小さなオフセット電圧を生成するために、小電流を終端差分ペアへ駆動する必要がある。このような状態では、イネーブルされたオフセット電流バイアス回路が、Ｉ_{ＥＳＤ−ａｎｄ−Ｒｘ}、Ｉ_{Ｅｘ−Ｈｉ−Ｚ}、及びＩ_{ｅｘｔｅｒｎａｌ−ＥＳＤ}のように称される電流レベルを駆動する。Ｉ_{ＥＳＤ−ａｎｄ−Ｒｘ}は、内部ＥＤＳダイオード及び差分受信機入力であり一般にＩ_{ＥＳＤ−ａｎｄ−Ｒｘ}≦１μＡである。Ｉ_{Ｅｘ−Ｈｉ−Ｚ}は、高インピーダンス状態における差分ドライバ出力であり、一般にＩ_{Ｅｘ−Ｈｉ−Ｚ}≦１μＡである。Ｉ_{ｅｘｔｅｒｎａｌ−ＥＳＤ}は、外部ＥＳＤ保護ダイオードを通るリークであり、一般にＩ_{ｅｘｔｅｒｎａｌ−ＥＳＤ}≦３μＡである。

これらリーク電流の各々は、図４７に示されている。プルアップ及びプルダウン回路は、上述したように、全てが同時に起きる最悪ケースのリーク条件の場合、最小の差分電圧を達成しなければならない。合計リークは、外部ＥＳＤ保護ダイオードを持たない内部モードの場合≦４μＡであり、外部ＥＳＤ保護を持つ外部モードの場合≦１０μＡである。

差動ラインドライバとラインレシーバの電気的なパラメータと特性は表ＩＸａ−ＩＸｄ内に典型的な実施形態として記述されている。機能的に、ドライバは入力で直接的に論理レベルを正の出力に、入力の逆数を負の出力に転送する。入力から出力への遅延は差動的に駆動される差動線路に十分に整合されている。大部分のインプリメンテーションでは、出力での電圧振幅は、電力消費と電磁放射線を最小限に抑えるために入力での振幅より少ない。一つの実施形態では、最小電圧振幅は、約０．５Ｖである。しかしながら、当業者により知られるであろうように他の値が使用でき、発明者らは設計の制約に応じていくつかの実施形態ではさらに小さい値を意図する。

差動ラインレシーバは高速電圧コンパレータと同じ特性を有する。図４１では、バブルのない入力は正の入力であり、バブルのある入力は負の入力である。出力は、（Ｖｉｎｐｕｔ＋）−（Ｖｉｎｐｕｔ−）がゼロより大きい場合には、論理１である。これを説明する別の方法は、非常に大きな（実質的には無限の）利得を有する差動増幅器であり、出力は論理０電圧レベルと１電圧レベルでクリッピングされる。

様々な組の間の遅延歪みは、差動伝送システムを潜在的な最高の速度で動作するために最小限に抑えられなければならない。

図４２では、通信リンク４２０６上でパケットを転送しているホストコントローラ４２０２とクライアント又はディスプレイコントローラ４２０４が示されている。ホストコントローラは、転送されるクライアントデータ信号を受信するためだけではなく、転送されるホストＤＡＴＡ（データ）信号とＳＴＢ（ストローブ）信号を受信するためにも一連の３台のドライバ４２１０、４２１２、及び４２１４を利用する。一方、クライアントは、３つのドライバ４２３０，４２３２，４２３４を適用する。ホストデータ（４２１２）の通過に関与するドライバは、ホストからクライアントへの転送が所望されるときにだけ通常通信リンクの起動を可能にするために、イネーブル信号入力を利用する。ＳＴＢ（ストローブ）信号はデータの転送の一部として形成されるので、追加のイネーブル信号はそのドライバ（４２１２）に利用されない。クライアントＤＡＴＡ（データ）ドライバとＳＴＢ（ストローブ）ドライバ（４１３２，４２３０）のそれぞれの入力は、それぞれ間をあけて配置された終端インピーダンス又は抵抗器４２１８，４２２０を有している。クライアントコントローラ内のドライバ４２３４は、クライアントからホストへ転送されているデータ信号を準備するために使用される。ここでは、ドライバ４２１４が入力側にあり、データを処理する。

特別な受信機（ドライバ）４２１６，４２３６がデータ線路に結合又は接続され、他の箇所で説明されたハイバネーション制御の一部として、上述したように、１２５ｍＶ電圧オフセットを生成又は使用する。これらオフセットは、ハイバーネーションライン受信機に対して、駆動されていない信号ペアを論理ゼロレベルとして解釈させる。

前記ドライバ及びインピーダンスは離散構成要素として、あるいは回路モジュール又はさらに費用効果の高いエンコーダ又はデコーダ解決策として働く特定用途向け集積回路（ＡＳＩＣ）の一部として形成できる。

電力が、ＨＯＳＴ＿ＰｗｒとＨＯＳＴ＿Ｇｎｄと呼ばれる信号を１組の導線上で使用して、クライアントデバイス、つまりディスプレイに、ホストデバイスから転送されるのは容易に理解できる。信号のＨＯＳＴ＿Ｇｎｄ部分は、基準接地、及び電源戻り経路又は表示装置用の信号として働く。ＨＯＳＴ＿Ｐｗｒ信号はホストデバイスによって駆動されるクライアントデバイス電源として働く。例示的な構成では、低電力応用例の場合、クライアントデバイスは最高５００ｍＡまで引き出すことができる。ＨＯＳＴ＿Ｐｗｒ信号は、リチウムイオン型電池又はホストデバイス内に常駐する電池パック等を含むが、これらに限定されない携帯電源から提供でき、ＨＯＳＴ＿Ｇｎｄに関して３．２ボルトから４．３ボルトの範囲となってよい。

ＶＩＩ．タイミング特性
Ａ．概要
ハイバーネーション状態（何のサービスも要求されず、望まれず、必要とされない）に入り、ホストからクライアントのためのサービスを確保するために、ホスト又はクライアントの何れかによって開始されるために適用されるステップ及び信号レベルは、図４３Ａ、図４３Ｂ、及び図４３Ｃにそれぞれ示されている。図４３Ａ、図４３Ｂ、及び図４３Ｃでは、描かれている信号の第１の部分は、ホストから転送されているリンクシャットダウンパケットであり、データラインは次に高インピーダンスバイアス回路を使用して論理ゼロ状態に駆動される。データはクライアント、つまりそのドライバがディスエーブルされているホストによって送信されていない。ＭＤＤＩ＿Ｓｔｂはリンクシャットダウンパケットの間アクティブであるので、ＭＤＤＩ＿Ｓｔｂ信号線路のための一連のストローブパルスは下部に見ることができる。いったんこのパケットが終了すると、ホストがバイアス回路と論理回路をゼロに駆動するので、論理レベルがゼロに変化する。これは、ホストからの最後の信号転送又はサービスの終端を表し、過去におけるいかなる時点でも発生できたであろうし、サービスの過去の休止及びサービス開始前の信号の状態を示すために含まれている。信号が、「公知の」過去の通信がこのホストデバイスによって着手されずに、通信リンクを適切な状態に単にリセットするために信号を送信できる等所望される場合。

図４３Ａに示すように、そして、リンクシャットダウンパケットについて上述したように、低電力ハイバーネーション状態では、ＭＤＤＩ＿Ｄａｔａ０ドライバが、リンクシャットダウンパケット内の全ゼロフィールドの最後のビットの後、１６番目から４８番目のＭＤＤＩ＿Ｓｔｂサイクル又はパルス後に始まる高インピーダンス状態にディスエーブルされる。２型、３型、又は４型のリンクの場合、ＭＤＤＩ＿Ｄａｔａ１からＭＤＤＩ＿ＤａｔａＰｗｒ７までの信号もまた、ＭＤＤＩ＿Ｄａｔａ０ドライバがディスエーブルされるのと同時に、高インピーダンス状態に置かれる。全ゼロフィールドの定義において記載したように、ＭＤＤＩ＿Ｓｔｂは、リンクシャットダウンパケットのＣＲＣフィールドのＭＳＢの後に続く６４サイクルのために（又はシステム設計に望まれるように）トグルし、クライアントにより処理が完了するようにし、クライアントコントローラにおける規則的なシャットダウンを容易にする。１サイクルは低から高への遷移の後、高から低への遷移となる。あるいは、高から低への遷移の後、低から高への遷移となる。全ゼロフィールドが送られた後、ホスト内のＭＤＤＩ＿Ｓｔｂドライバ及びＭＤＤＩ＿Ｄａｔａ０ドライバがディスエーブルされ、ホストは、低電力ハイバーネーション状態に入る。いくらか時間が経過した後、ホストは、ＭＤＤＩ＿Ｄａｔａ０線路及びＭＤＤＩ＿Ｓｔｂ線路又はドライバ出力をイネーブルすることによって、図４３Ｂ及び図４３Ｃに示すように、リンク再起動シーケンスを開始し、ウェイクアップ要求を開始したクライアント又はホストの何れかの一部としてＭＤＤＩ＿Ｓｔｂのトグルを開始する。

図４３Ｂに示すように、ディスエーブルされたＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのためのドライバから出力された信号とともに時間が経過した後、ホストは、線路が論理ゼロに駆動されている間、ｔ_{ｓｔｂ−ｄａｇｔａ−ｅｎｂｌ}と指定された期間、ＭＤＤＩ＿Ｓｔｂドライバをイネーブルすることによって、それが完全にイネーブルされ、ＭＤＤＩ＿Ｄａｔａ０ドライバをイネーブルするまで、ハイバーネーションからウェイクアップするか、あるいはサービスを開始する。ホストは、ＭＤＤＩ＿Ｄａｔａ０が、ｔ_{ｃｌｉｅｎｔ−ｓｔａｒｔｕｐ}と指定された期間にわたって生じる論理１レベル又は高レベルに達した後、ＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに保つ。ｔ_{ｃｌｉｅｎｔ−ｓｔａｒｔｕｐ}期間の終わりに、ホストは、ＭＤＤＩ＿Ｓｔｂ信号又は線路をトグルする。ホストは、クライアントがＭＤＤＩ＿Ｄａｔａ０を駆動しない間、ｔ_{ｒｅｓｔａｒｔ−ｈｉｇｈ}と指定された期間、ＭＤＤＩ＿Ｄａｔａ０線路を高に、論理１レベルに駆動する。そして、ｔ_{ｒｅｓｔａｒｔ−ｌｏｗ}と指定された期間、ＭＤＤＩ＿Ｄａｔａ０線路を低、すなわち論理ゼロレベルに駆動する。この後、第１の転送トラフィックが、サブフレームヘッダパケットとともに始まり、転送トラフィックパケットが転送される。ＭＤＤＩ＿Ｓｔｂ信号は、ｔ_{ｒｅｓｔａｒｔ−ｌｏｗ}期間及び次のサブフレームヘッダパケットの間アクティブである。

図４３Ｃに示すように、ディスエーブルされたＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのためのドライバから出力された信号とともに時間が経過した後、クライアントは、ホストがそのＭＤＤＩ＿Ｓｔｂドライバをイネーブルする前、上述したように、ｔ_{ｓｔｂ−ｄａｇｔａ−ｅｎｂｌ}と指定された期間、出力信号又はＭＤＤＩ＿Ｓｔｂ受信機におけるオフセットをイネーブルすることによって、ハイバーネーションからのウェイクアップ、又はサービス要求を開始する。その後、クライアントは、ホストがＭＤＤＩ＿Ｓｔｂトグルを開始する前に、線路が論理ゼロレベルに駆動されている間、ｔ_{ｈｏｓｔ−ｄｅｔｅｃｔ}と指定された期間、そのＭＤＤＩ＿Ｄａｔａ０ドライバをイネーブルする。

ｔ_{ｒｅｓｔａｒｔ−ｈｉｇｈ}期間、ＭＤＤＩ＿Ｄａｔａ０を論理１又は高レベルに駆動することによって、ホストがリンク起動シーケンスを用いてＭＤＤＩ＿Ｓｔｂのトグルを開始する前、ｔ_{ｓｔｂ−ｓｔａｒｔｕｐ}と指定された期間、ＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに保持することによって応答した後、ｔ_{ｈｏｓｔ−ｄｅｔｅｃｔ}の間、ホストが要求を検出する前に一定量の時間が経過するか、あるいは必要とされる。クライアントは、ＭＤＤＩ＿Ｓｔｂ上の第１のパルスを認識したとき、そのＭＤＤＩ＿Ｓｔｂ受信機内のオフセットをディスエーブルする。クライアントは、線路を駆動しているホストを検出するまで、ＭＤＤＩ＿Ｄａｔａ０を論理１レベル又はｔ_{ｃｌｉｅｎｔ−ｄｅｔｅｃｔ}と指定された期間駆動し続ける。この点において、クライアントは、この要求を逆アサートし、クライアントからの出力が論理ゼロレベルに再び行き、ホストがＭＤＤＩ＿Ｄａｔａ０を駆動することができるようにＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルする。前述したように、ホストは、ＭＤＤＩ＿Ｄａｔａ０を、ｔ_{ｒｅｓｔａｒｔ−ｈｉｇｈ}の間、論理１レベルに駆動し続け、第１の転送トラフィックがサブフレームヘッダパケットを用いて始まった後、ｔ_{ｒｅｓｔａｒｔ−ｌｏｗ}の間、ＭＤＤＩ＿Ｄａｔａ０線路を低に駆動する。ＭＤＤＩ＿Ｓｔｂ信号は、ｔ_{ｒｅｓｔａｒｔ−ｌｏｗ}及び次のサブフレームヘッダパケットの間アクティブである。

表Ｘは、前述された多様の期間の長さの代表的な時間又は処理期間、及び例示的な最小データレートと最大データレートに対する関係性を示す。

ここで、Ｌｉｎｋ＿Ｄａｔａ＿Ｒａｔｅは、単一のデータペアのビットレートである。

当業者は、図４１と図４２に示されている個々の要素の機能が周知であり、図４２Ａの要素の機能が図４３Ａ、図４３Ｂ、及び図４３Ｃのタイミング図で確認されることを容易に理解する、図４２Ａに示されている直列終端及びハイバネーション抵抗器についての詳細は、その情報が、データ−ストローブ符号化を実行し、そこからクロックを回復する方法の説明には不必要であるため図４１から省略された。

Ｂ．データ−ストローブタイミング順方向リンク
ホストドライバ出力から順方向リンクでのデータ転送の切り替え特性は表ＸＩ−１に示されている。表ＸＩ−１は、表形式の所望される最小と最大対特定の信号遷移が発生するための典型的な時間を提示する。例えば、最小時間は約ｔ_ｔｂｉｔ−０．５ｎｓｅｃであり、最大は約ｔ_ｔｂｉｔ＋０．５ｎｓｅｃであるが、遷移がデータ値（「０」又は「１」の出力）の始まりから最後までに発生する典型的な時間の長さ、ｔ_ｔｄｄ−（ホスト−出力）と呼ばれるＤａｔａ０からＤａｔａ０遷移は、ｔ_ｔｂｉｔである。Ｄａｔａ０、他のデータライン（ＤａｔａＸ）、及びストローブ線路（Ｓｔｂ）での遷移間の相対的なスペーシングは、それぞれｔ_ｔｄｓ−（ホスト−出力）、ｔ_ｔｓｓ−（ホスト−出力）、ｔ_ｔｓｄ−（ホスト−出力）、ｔ_ｔｄｄｘ−（ホスト−出力）、ｔ_ｔｄｘ−（ホスト−出力）、ｔ_ｔｄｘｓ−（ホスト−出力）、及びｔ_ｔｓｄｘ−（ホスト−出力）と呼ばれているＤａｔａ０からストローブ、ストローブからストローブ、ストローブからＤａｔａ０、Ｄａｔａ０から非Ｄａｔａ０、非Ｄａｔａ０から非Ｄａｔａ０、非Ｄａｔａ０からストローブ、及びストローブから非Ｄａｔａ０遷移が示されている図４４に描かれている。

順方向リンクでデータを転送している同じ信号のクライアント受信機入力のための典型的なＭＤＤＩタイミング要件は表ＸＩ−２に示されている。同じ信号が説明されているが、時間は遅延しているので、当業者によって理解されるように、それぞれのラベルの信号特性又は意味を説明するために新しい図は必要とされない。

図４５と図４６は、ホストがそれぞれホストドライバをイネーブル又はディスエーブルするときに発生することがある応答の遅延の存在を図解する。逆方向リンクカプセル化パケット又は往復遅延測定パケット等の特定のパケットを転送しているホストの場合、転送されたとして図４５に示されているパラメータＣＲＣパケット、ストローブ位置合わせパケット、及び全ゼロパケット等、ホストは所望されるパケットが転送された後にラインドライバをディスエーブルする。しかしながら、図４５に示されているように、これはおそらく特定の制御素子又は回路素子が存在する状態では達成可能であるが、線路の状態は必ずしも「０」から所望されるさらに高い値に瞬時に切り替わらないが、応答にはホストドライバディスエーブル遅延期間と呼ばれている期間を要する。それはこの期間の長さが０ナノ秒（ｎｓｅｃ）であるように実質的に瞬時に発生できるが、それは、ガード時間１パケット期間又はターンアラウンド１パケット期間の間に発生する所望される最大期間長である１０ｎｓｅｃのさらに長い期間でさらに容易に広がるであろう。

図４６を見ると、ホストドライバが逆方向リンクカプセル化パケット又は往復遅延測定パケット等のパケットを転送するためにイネーブルされているときに信号レベル変化が起こったことがわかる。ここでは、ガード時間２パケット期間又はターンアラウンド２パケット期間の後、ホストドライバはイネーブルされ、レベル、ここでは「０」を駆動し始め、その値には、第１のパケットが送信される前に、ドライバ再イネーブル期間の間に発生するホストドライバイネーブル遅延期間と呼ばれる期間に近づく又は達する。

同様のプロセスは、ドライバについて、及びクライアントデバイス、ここではディスプレイのための信号転送について発生する。これらの期間の長さの一般的な指針及びそれぞれの関係性は以下の表ＸＩＩに示されている。

Ｃ．ホストとクライアントの出力イネーブル及びディセーブル時間
図４８には、ホスト出力とクライアント出力とのイネーブル時間及びディスエーブル時間の相対的なタイミング関係、又は逆方向リンクカプセル化パケット構造及び期間、及び切り替え特性を示す図である。ドライバ出力機能又は動作は、ホスト出力イネーブル時間の場合ｔ_{ｈｏｓｔ−ｅｎａｂｌｅ}と、ホスト出力ディスエーブル時間の場合ｔ_{ｈｏｓｔ−ｄｉｓａｂｌｅ}と、クライアント出力イネーブル時間の場合ｔ_{ｃｌｉｅｎｔ−ｅｎａｂｌｅ}と、クライアント出力ディスエーブル時間の場合ｔ_{ｃｌｉｅｎｔ−ｄｉｓａｂｌｅ}とそれぞれラベルされる。ある信号遷移に対する典型的な時間は以下に説明される。これら動作のための最小期間は、ゼロナノ秒となるであろう。インターフェースを適用したシステム設計から決定される一般的又は最大値は、おそらくは８ナノ秒あるいはそれ以上のオーダになるであろう。

これら期間の長さ（ホスト及びクライアントのイネーブル／ディセーブル時間）と、それぞれの関係の一般的なガイドラインは、表ＸＩＩＩに示されている。

ＶＩＩＩ．リンクコントロール（リンクコントローラ動作）のインプリメンテーション
Ａ．状態機械パケットプロセッサ
ＭＤＤＩリンク上で転送されているパケットは、所望されるようにさらに低い速度で確実に対処されるが、非常に迅速に、通常約３００Ｍｂｐｓ以上の速度でディスパッチされる。この種のバス又は転送リンクの速度は速すぎて、現在市販されている（経済的な）汎用マイクロプロセッサ等が制御することはできない。したがって、この種の信号転送を達成するための実用的なインプリメンテーションは、それらが意図されている適切な視聴覚サブシステムに転送される又はリダイレクトされるパケットを作成するために入力パケットストリームを解析するためにプログラマブル状態機械を活用することである。このような装置は周知であり、通常、所望される高速又は超高速の動作を達成するためには、限られた数の動作、機能又は状態に専用である回路を使用する。

汎用コントローラ、プロセッサ、又は処理要素は、さらに低い速度要件を有する制御パケット又はステータスパケット等のなんらかの情報により適切に作用する、あるいは操作するために使用できる。それらのパケット（制御、ステータス、又は他の所定のパケット）が受信されると、ステータス機械は、音声パケットと視覚パケットが処置のためにその適切な宛て先に転送される間に所望される結果（効果）を提供するために作用を受けることができるように、それらをデータバッファ又は類似する処理要素を通して汎用プロセッサに渡す必要がある。将来、マイクロプロセッサ又は他の汎用コントローラ、プロセッサ、又は処理要素がより速いデータレート処理機能を達成するために製造される場合には、通常は記憶要素又は媒体に記憶されているプログラムとして、状態、又は後述される状態機械もこのような装置のソフトウェア制御を使用して実現される可能性がある。

汎用プロセッサ機能は、コンピュータアプリケーションにおけるマイクロプロセッサ（ＣＰＵ）、又はコントローラ、プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特殊化した回路、又は無線装置で見つけられるＡＳＩＣ等のために使用可能な処理力又は過剰なサイクルを、いくつかのモデム又はグラフィックプロセッサが何らかの機能を実行するためにコンピュータで見られるＣＰＵの処理力を活用し、ハードウェアの複雑さとコストを削減するためにコンピュータの中で発見されるＣＰＵの処理能力を活用することによりいくつかの実施形態で実現できる。しかしながら、このサイクル共用又は使用は、このような素子の処理速度、タイミング、又は全体的な動作にマイナス影響を及ぼす可能性があるため、多くの応用例では、この汎用処理のために専用回路又は素子が好ましい。

画像データがディスプレイ（マイクロディスプレイ）に表示されるために、あるいはホストデバイスによって送信されるすべてのパケットを確実に受信するために、クライアント信号処理は順方向リンクチャネルタイミングと同期される。つまり、クライアントに到達する信号及びクライアント回路は、適切な信号処理のために実質的に時間同期される必要がある。一つの実施形態において、信号によって達成される高水準図は、図４９の図示されている。図４９では、１つのＡＳＹＮＣ ＦＲＡＭＥ（非同期フレーム状態）４９０４、２つの同期取得状態（ＡＣＱＵＩＲＩＮＧ ＳＹＮＣ ＳＴＡＴＥＳ）４９０２と４９０６、及び３つの同期中状態（ＩＮ−ＳＹＮＣ ＳＴＡＴＥＳ）４９０８、４９１０、及び４９１２として分類されている状態機械４９００の考えられる順方向同期「状態」が示されている。

ステップ又は状態４９０２を開始することによって示されているように、プレゼンテーション装置のようなディスプレイ又はクライアントは事前に選択された「同期なし」状態で開始し、検出される第１のサブフレームヘッダパケットの一意のワードを検索する。この同期なし状態が、最小通信設定、又は１型インタフェースが選択される「後退」設定を表すことが注記されなければならない。一意のワードが検索中に発見されると、クライアントはサブフレーム長フィールドを保存する。この第１のフレームに対する処理のための、あるいは同期が得られるまで、ＣＲＣビットのチェックはない。このサブフレーム長がゼロである場合は、同期状態処理はここで同期がまだ達成されていないことを示す「非同期フレーム」状態と呼ばれる状態４９０４に相応して進む。処理のこのステップは、図４９の遭遇ｃｏｎｄ３、つまり条件３を有すると名付けられる。それ以外の場合、フレーム長がゼロより大きい場合には、同期状態処理は、インタフェース状態が「１つの同期フレームを発見」として設定される状態４９０６に進む。処理のこのステップは、遭遇ｃｏｎｄ５、つまり図４９の条件５と名付けられている。さらに、状態機械が、ゼロより大きいフレーム長の間、フレームヘッダパケット及び良好なＣＲＣ決定を見る場合、処理は「１つの同期フレームを発見」に進む。これは会議ｃｏｎｄ６、つまり図４９の条件６と名付けられている。

システムが「同期なし」以外の状態にあるそれぞれの状況では、良好なＣＲＣ結果を持つパケットが検出されると、インタフェース状態は「同期中」状態４９０８に変更される。処理の中のこのステップはｃｏｎｄ１、つまり図４９の条件１に遭遇したとして名付けられている。他方、何れのパケットのＣＲＣも正しくない場合には、同期状態処理は、「同期なしフレーム（ＮＯ ＳＹＮＣ ＦＲＡＭＥ）」状態のインタフェース状態４９０２に進む、又は戻る。処理のこの部分は遭遇ｃｏｎｄ２、つまり条件２を図４９の状態図と名付けられている。

Ｂ．同期の獲得時間
インタフェースは、同期が失われたと決定し、「ＮＯ ＳＹＮＣ ＦＲＡＭＥ（同期なしフレーム）」状態に戻る前に特定数の「同期エラー」に対処するように構成できる。図４９では、いったん状態機械が「ＩＮ−ＳＹＮＣ ＳＴＡＴＥ（同期中状態）」に到達し、エラーが検出されないと、それは連続してｃｏｎｄ１結果に遭遇し、「ＩＮ−ＳＹＮＣ（同期中）」状態のままとなる。しかしながら、いったん１つのｃｏｎｄ２結果が検出されると、処理は「１同期エラー」状態４９１０に状態を変更する。この時点で、処理が別のｃｏｎｄ１結果を検出する結果となると、状態機械は「同期中」状態に戻り、それ以外の場合、それは別のｃｏｎｄ２結果に遭遇し、「ＴＷＯ−ＳＹＮＣ−ＥＲＲＯＲＳ（２同期エラー）」状態４９１２に移る。再びｃｏｎｄ１が発生すると、処理は状態機械を「ＩＮ−ＳＹＮＣ（同期中）」状態に戻す。それ以外の場合、別のｃｏｎｄ２に遭遇し、状態機械は「同期なし」状態に戻る。インタフェースが「リンクシャットダウンパケット」に遭遇すると、これによりリンクがデータ転送を終了し、図４９の状態図の中のｃｏｎｄ４、つまりミーティング条件４と呼ばれる、同期するものが何もないので「同期なしフレーム」状態に戻ることも理解可能である。

サブフレーム内のどこか固定されたロケーションに現れる可能性のある一意のワードの「偽のコピー」を繰り返すことができることが理解される。その状況では、サブフレームヘッダパケット上のＣＲＣは、ＭＤＤインタフェース処理が「ＩＮ ＳＹＮＣ（同期中）」状態に進むために処理されるときにも有効でなければならないため、状態機械がサブフレームに同期する可能性はきわめて低い。

サブフレームヘッダパケット内のサブフレーム長は、リンクがシャットダウンされる前にホストがただ１つのサブフレームを送信し、ＭＤＤＩが休止ハイバネーション状態に入れられる、又は構成されることを示すためにゼロに設定されてよい。この場合、クライアントはサブフレームヘッダパケットを検出後、ただ１つのサブフレームだけが、リンクがアイドル状態に遷移する前に送信されるため、順方向リンクで直ちにパケットを受信しなければならない。通常の、又は典型的な動作では、サブフレーム長は非ゼロであり、クライアントは、インタフェースが図４９に集合的に「ＩＮ−ＳＹＮＣ（同期中）」状態として示されているそれらの状態にある間に順方向リンクパケットを処理するに過ぎない。

外部モードクライアントデバイスは、ホストが既に順方向リンクデータシーケンスを送信している間、ホストに属している。この状況では、クライアントはホストに同期しなければならない。クライアントが順方向リンク信号に同期するのに要する時間は、サブフレームサイズと順方向リンクデータレートに応じて可変である。順方向リンク内で無作為な、又はさらに無作為なデータの一部として一意のワードの「偽のコピー」を検出する尤度は、サブフレームサイズがさらに大きいときより大きくなる。同時に、順方向リンクデータレートが低速化すると、偽検出から回復する能力は低くなり、そうするために要する時間は長くなる。

一つ又は複数の実施形態では、低電力モードに移行するために、あるいはリンクを完全にシャットダウンするために順方向リンク送信を停止する前に、ＭＤＤＩ逆方向リンクが安定であることを確証するために、ＭＤＤＩホストがある追加ステップを実施すべきであることが推奨又は理解される。

起こりうる一つの問題は、ホストが正しくない往復遅延の測定値を用いた場合、順方向リンクが良好に見えるにも関わらず、クライアントから引き続き受信された逆データ送信の全てをだめにすることである。これは、クライアントが順方向リンクと同期していない場合にホストが往復遅延測定パケットの送信を試みた場合、あるいは往復遅延に影響を及ぼす差分ドライバ及び受信機の伝搬遅延における大きな変化をもたらす極端な周囲温度変化によって起こりうる。断続ケーブル又はコネクタ接続欠陥はまた、クライアントに、一時的に同期を失わせ、その後、同期を再取得させる。この間、往復遅延測定パケットの受信を失敗するかもしれない。それに続く逆方向リンクパケットは、ホストによって適切に復元することはできないであろう。

起こりうる別のタイプの問題は、もしもクライアントが一時的に同期を失った場合、クライアントが同期を再取得できる前にホストがリンクシャットダウンパケットを送ることである。ホストは、クライアントがハイバーネーション状態に入ることができない間はハイバーネーションにある。なぜなら、リンクシャットダウンパケットを受信しておらず、リンクがハイバーネーションにあるためにクロックを持っていないからである。

このような問題に打ち勝つために利用可能な技術又は実施形態は、リンクをハイバーネーション状態に入れる前にクライアントが順方向リンクと同期していることをホストに保証させることである。もしもＭＤＤＩホストがこれをすることができないか、又は例えば電力喪失時のような機会を持たない場合、あるいは動作中のケーブル、導電体、又はコネクタの分離、破壊、又は断線によってリンクが急に切れた場合には、ホストは先ず、往復遅延測定プロセスを開始するか、又は逆方向リンクカプセル化パケットを送る前に、クライアントが同期していることの保証を試みるべきである。

ホストは、クライアントによって送られたステータスパケットとクライアント要求におけるＣＲＣエラーカウントフィールドを観察し、順方向リンク完全性を判定することができる。このパケットは、クライアントから、ホストによって要求される。しかしながら、大規模なリンク欠陥又は破断の事象では、クライアントは、パケットを適切に復号することができないためにほとんど応答されないであろう。あるいは完全に受信するであろう。逆方向リンクカプセル化パケット内で送られたステータスパケット及びクライアント要求を用いたＣＲＣエラーカウントに対する要求は、第１の完全性チェック、一種の第１の防御ラインとして作用する。更に、ホストは、同期から抜け出たクライアントに関する仮定が、有効であるか否かを確認するために、往復遅延測定パケットを送ることができる。クライアントが往復遅延測定パケットに対して応答しないのであれば、ホストは、このクライアントは、同期から脱し、同期に戻るプロセスを開始することができると結論するであろう。

逆方向リンクカプセル化パケットを、逆方向リンクフラグフィールドにビット１が１に設定されたクライアントに定期的に送ることによって、クライアントにおけるＣＲＣエラーカウントを連続監視し、クライアントがクライアント要求及びステータスパケットをホストに戻すことを要求ことが一般に推奨される。

クライアントが順方向リンクとの同期を間違いなく失ったと一旦ホストが結論すると、ホストは、フィラーパケット以外のあらゆるパケットの送信を試みる前に、次のサブフレームヘッダまで待つ。これは、サブフレームヘッダパケットに含まれる一つのユニークなワードを検出又は見つけるためにクライアントに十分な時間を与えるために行われる。これに続いて、ホストは、クライアントが自己をリセットしたであろうと仮定する。なぜなら、それは、ユニークなワードを正しい場所において見つけていないであろうからである。この点において、ホストは、往復遅延測定パケットを備えたサブフレームヘッダパケットを追う。もしもクライアントが、往復遅延測定パケットに未だに正しく応答しないのであれば、ホストは、再同期プロセスを繰り返す。正しい応答においては、クライアントが、特定されたシーケンスを、往復遅延測定パケットの測定周期でホストに送り返す。このシーケンスが受信されないのであれば、逆方向リンクカプセル化パケット内の逆方向データを受信する試みは失敗するであろう。この特性の連続した失敗は、別の手法で対処されねばならない他のシステムエラーを示し、この点において、リンク同期の一部ではない。

しかしながら、往復遅延測定パケットが成功した後、ホストが未だに、逆方向リンクカプセル化パケットにおいて何の応答も見ないか、破損したデータを見ているのであれば、往復遅延測定パケットを再送信することによって、逆方向データサンプリングが正しいことを確認すべきである。もしも何度も試みても成功しない場合には、一つの実施形態では、逆方向レート逆数値を増加させることによって、逆方向データレートを低減することが推奨される。

ホストは、ＭＤＤＩリンクをハイバーネーション状態に置く前に、リンク欠陥検出及び恐らくはリンク再同期ステップを実行すべきであることが推奨される。これは、一般に、後にリンクが再起動したときに実行される往復遅延測定パケットが成功したことを保証する。もしもホストがリンク欠陥を疑う理由も、逆方向リンクカプセル化パケットに対する正しい応答も持っておらず、ゼロ順方向リンクＣＲＣエラーがクライアントによって報告されているのであれば、ホストは、全てがそれに従って、あるいは適切（例えば、リンク欠陥が無い）に動作又は機能していると仮定し、パワーダウン／ハイバーネーションプロセスを進める。

ホストが同期のためにテストできる別の方法は、ホストが、往復遅延測定パケットを送り、クライアントからの適切な応答を確認することである。もしも適切な応答がホストによって受信されると、クライアントは、順方向リンクパケットを正しく解釈していると適切に想定することができる。

Ｃ．初期化
前述されたように、「起動」時に、ホストは順方向リンクを、１Ｍｂｐｓという最小の必須、つまり所望されるデータレートで、又は以下で動作するように構成し、、サブフレーム長とメディアフレームレートを既定の応用例のために適宜に構成する。つまり、順方向リンクと逆方向リンクの両方が１型インタフェースを使用して動作を開始する。これらのパラメータは通常、ホストがクライアントディスプレイ（又は他のタイプのクライアントデバイス）のための機能又は所望される構成を決定する間に一時的に使用されることになる。ホストは、ディスプレイ又はクライアントがクライアント機能パケットで応答することを要求するために、要求フラグのビット「０」を一（１）という値に設定させる逆方向リンクカプセル化パケットが後に続く順方向リンク上でサブフレームヘッダパケットを送信又は転送する。いったんディスプレイが順方向リンクで（又は順方向リンクと）同期を獲得すると、クライアント機能パケットとクライアント要求及びステータスパケットを逆方向リンク又はチャネル上で送信する。

ホストは、最適の、又は所望されるレベルの性能のリンクを再構成する方法を決定するために表示機能パケットの内容を調べる。ホストは、ホストとディスプレイが互いに互換性のあるプロトコルのバージョンを使用することを確認するためにプロトコルバージョンフィールドと最小プロトコルバージョンフィールドを調べる。プロトコルバージョンは、通常、他のプロトコルの要素が互換性がない、あるいは互換性があると完全に理解されないときにも互換性を決定できるように表示機能パケットの最初の２つのパラメータとして留まる。

内部モードでは、ホストは、クライアント機能パケットを受信する必要なく、前もってクライアントのパラメータを知ることができる。リンクは、ホストとクライアントとの両方が動作することができるあらゆるデータレートで起動することができる。多くの実施形態では、システム設計者は、データ転送を急ぐために、達成可能な最大データレートでリンクを開始することを最も選択するであろうが、これは、多くの状況では要求されず、使用されないかもしれない。内部モード動作の場合、ハイバーネーションシーケンスからのリンク再起動の間に使用されるストローブパルスの周波数は通常、望まれるレートと一致している。

Ｄ．ＣＲＣ処理
すべてのパケットタイプについて、パケットプロセッサ状態機械は、ＣＲＣチェッカが適切に又は正確に制御されることを保証する。それは、また、ＣＲＣ比較の結果、１つ又は複数のエラーが検出されるとＣＲＣエラーカウンタを増分し、それは処理されている各サブフレームの始まりでＣＲＣカウンタをリセットする。

Ｅ．同期チェックの代替損失
前記の一連のステップ又は状態はさらに高いデータレート又はスループット速度を生じさせるが、出願人は、ホストとの同期の損失があることを宣言するためにクライアントが使用する代替配列又は状態の変化は、事実上、なおさらに高いデータレート又はスループットを達成するために使用できることを発見した。新しい発明の実施形態は状態を変更するための状態が変更されているが、同じ基本構造を有する。さらに、新しいカウンタがサブフレーム同期のためにチェックを行うのに役立つために実現されている。これらのステップ及び状態は、方法の動作又は状態機械を確立する上で有効な一連の状態及び条件を示す状態機械図６３に関して提示されている。「ＡＣＱＵＩＲＩＮＧ−ＳＹＮＣ ＳＴＡＴＥＳ（同期状態獲得）」部分と「ＩＮ−ＳＹＮＣ ＳＴＡＴＥＳ（同期中状態）」部分だけが明確にするために示されている。加えて、結果として生じる状態は、状態機械自体と同様に、実質的には同じであるため、それらは同じ番号付けを使用する。しかしながら、状態を変更するための条件（及び状態機械の動作）はやや変化し、その結果、相違点を識別する上での都合を考えて２つの図（１、２、３、４、５及び６対６１、６２、６３、６４、６５）の間で明確にするためにすべてが番号を付け直される。ＡＳＹＮＣ ＦＲＡＭＥ（非同期フレーム）状態はこの説明では考慮されないために、１つの状態（４９０４）と条件（６）は図中では使用されない。

図６３では、図４９に示されているような事前に選択された「同期なし」状態４９０２で、（表示又はプレゼンテーション用の）システム又はクライアントが状態機械５０００で開始する。同期なし状態４９０２から状態を変更するための第１状態変化は、同期パターンの発見である条件６４にある。サブフレームヘッダのＣＲＣもこのパケットを順送りにすると仮定すると（条件６１を満たす）パケットプロセッサ状態機械の状態は同期中状態４９０８に変更できる。システムエラー、条件６２は、状態機械を状態４９１０に、第２の発生を状態４９１２にシフトさせる。しかしながら、ＭＤＤＩパケットのＣＲＣ故障により状態機械は同期状態４９０８から外れ、１同期エラー状態４９１０になることが発見された。ＭＤＤＩパケットの別のＣＲＣ故障により、２つの同期故障状態４９１２に動かされる。正しいＣＲＣ値で復号されるパケットにより、状態機械は同期中状態４９０８に戻る。

変更されたのは、「あらゆる」パケットについてＣＲＣ値又は決定を活用することである。つまり、単にサブフレームヘッダパケットを観察する代わりに、同期の損失を決定するために状態機械にパケットごとのＣＲＣ値を調べさせるのである。この構成又はプロセスでは、同期の損失は一意のワード及び単にサブフレームヘッダＣＲＣ値を使用して決定されない。

新しいインタフェースインプリメンテーションによりＭＤＤインタフェースリンクは、はるかに迅速に同期失敗を認識し、したがってそれらからさらに迅速に回復することもできるようになる。

このシステムをさらにロバストにするために、クライアントはサブフレームカウンタを追加又は活用する必要がある。クライアントは、一意のワードの存在がないか、それが到着又は信号内で発生することが予想されるときにチェックする。一意の野ワードが正しいときに発生しないと、クライアントは、それが複数（ここでは３）のパケット回数又はサブフレーム長を上回る期間待機しなければならなかった場合よりはるかに迅速に同期失敗が発生したことを認識できる。一意のワードのテストがそれが存在しない、言い換えるとタイミングが正しくないことを示すと、クライアントは直ちに同期のリンク損失を宣言し、同期なし状態に移ることができる。正確な一意のワードの存在がないかチェックするプロセスは、一意のワードが正しくないと述べて、状態機械に条件６５（ｃｏｎｄ６５）を追加する。サブフレームパケットがクライアントで受信されることを予想され、一致しない場合、クライアントはただちに同期なし状態４９０２に移動し、通常、状態４９１０と４９１２を通って行き来して遭遇される複数の同期エラー（条件６２）を待つ追加の時間を省くことができる。

この変化は、サブフレーム長をカウントするためにクライアントコア内で追加のカウンタ又はカウント機能を使用する。一実施形態では、カウントダウン機能が使用され、現在処理されていた任意のパケットの転送が、カウンタが時間切れになった場合にサブフレーム一意のワードがないかチェックするために中断される。代わりに、カウンタは数え上げることができ、カウントは所望される最大の、又は特定の所望される値に比較され、その時点で現在のパケットがチェックされる。このプロセスはクライアントを、異常に長いパケット長でクライアント上、誤って受信されるパケットを復号することから保護する。サブフレーム長カウンタが復号されていた他のなんらかのパケットを中断することを必要とした場合には、パケットはサブフレーム境界を越えてはならないので、同期の損失を決定できる。

ＩＸ．パケット処理
状態機械が受信する前述された各種パケットについて、それはインタフェースの動作を実現するために、特定の処理ステップ又は一連のステップに着手する。順方向リンクパケットは、通常、以下の表ＸＩＶに一覧表示される例示的な処理に従って処理される。

Ｘ．逆方向リンクデータレートの減速
発明者らにより、ホストリンクコントローラのために使用される特定のパラメータが、非常に望ましい最大又はさらに最適化された（スケール）逆方向リンクデータレートを達成するために特殊な方法で調整又は構成できることが観察された。例えば、逆方向リンクカプセル化パケットの逆方向データパケットフィールドを転送するために使用される時間中、ＭＤＤＩ＿Ｓｔｂ信号組は、順方向リンクデータレートの半分で周期的なデータクロックを作成するためにトグルする。これは、ホストリンクコントローラが、あたかも全ゼロを送信しているかのようにＭＤＤＩ＿Ｄａｔａ０信号に対応するＭＤＤＩ＿Ｓｔｂ信号を生成させるために発生する。ＭＤＤＩ＿Ｓｔｂ信号は、クライアントから逆方向リンクデータを転送するためのクロック信号を発生させるためにそれが使用される場合に、ホストからクライアントに転送され、逆方向データはホストに送り返される。ＭＤＤＩを利用するシステム内の順方向経路と逆方向経路での信号転送及び処理のために遭遇される遅延の典型的な量の図解は図５０に示されている。図５０では、一連の遅延値、１．５ｎｓｅｃ、８．０ｎｓｅｃ、２．５ｎｓｅｃ、２．０ｎｓｅｃ、１０ｎｓｅｃ、１５ｎｓｅｃ、８ｎｓｅｃ及び２５ｎｓｅｃは、それぞれＳｔｂ＋／−生成、表示用のケーブル転送、ディスプレイレシーバ、クロック作成、信号時間記録、Ｄａｔａ０＋／−生成、ケーブル転送からクライアントへ、及びクライアント受信機段のための処理部分近くに示されている。

順方向リンクデータ及び遭遇する信号処理遅延に応じて、この「往復」効果又はイベントのセットを完了するには、ＭＤＤＩ＿Ｓｔｂ信号での１つのサイクルより多くの時間を要する可能性があり、時間又はサイクル望ましくない量の時間又はサイクルの消費につながる。この問題を回避するために、逆方向レート除数が、逆方向リンク上の１ビット時間がＭＤＤＩ＿Ｓｔｂ信号の複数のサイクルに及ぶことが可能になる。つまり、逆方向リンクデータは順方向リンクレート未満である。

インタフェースを通る信号遅延の実際の長さが、それぞれの特定のホスト−クライアントシステム又は使用されているハードウェアに応じて異なる可能性があることが注記されなければならない。必要とされていないが、各システムは通常、逆方向レート除数を最適値に設定できるように、システム内での実際の遅延を測定するために往復遅延測定パケットを使用することによりさらによく機能させることができる。ホストは、より簡単だが低速で動作する基本データサンプリングか、より複雑だが高速な逆方向データレートをサポートする改良型データサンプリングかの何れか一方をサポートする。両方法をサポートするクライアント機能も同様に考慮される。

往復遅延は、ホストに往復遅延測定パケットをクライアントに送信させることにより測定される。クライアントは、測定期間フィールドと呼ばれるそのパケットの中の事前に選択された測定ウィンドウの内部で、あるいはその間に１のシーケンスをホストに送り返すことによってこのパケットに応答する。この測定の詳細なタイミングは前述された。往復遅延は、逆方向リンクデータが安全にサンプリングできる速度を決定するために使用される。

往復遅延測定は、０ｘｆｆ、０ｘｆｆ、０ｘ００応答シーケンスがクライアントからホストで受信し直されると、測定期間フィールドの始まりと時間期間の始まりの間で発生する順方向リンクデータクロック間隔の数を決定すること、検出すること、あるいはカウントすることからなる。クライアントからの応答が、測定カウントが増分しそうになる前に順方向リンククロック期間のほんの少し、受信できることに注記する。この未修正の値が逆方向レート除数を計算するために使用される場合、それは信頼できないデータサンプリングのために逆方向リンクでビットエラーを引き起こすであろう。この状況の一例は、ホストにおけるＭＤＤＩ＿Ｄａｔａ、ホストにおけるＭＤＤＩ＿Ｓｔｂ、ホストの内部の順方向リンクデータクロック、及び遅延カウントを表す信号を示し、得られるピクセルをグラフ形式で示された宛先ピクセル位置に書き込む図５１で示されている。図５１では、応答シーケンスは遅延カウントが６から７に増分する前に順方向リンククロック期間の一部、クライアントから受信された。遅延が６であると見なされる場合には、ホストは逆方向データをビット遷移の直後に、あるいはおそらくビット遷移の途中でサンプリングする。この結果、ホストで誤ったサンプリングが行われるであろう。この理由から、測定遅延は、通常、それが逆方向データ除数を計算するために使用される前に１、増分されなければならない。

逆方向レート除数は、逆方向リンクデータをサンプリングする前に、ホストが待機しなければならないＭＤＤＩ＿Ｓｔｂサイクルの数である。ＭＤＤＩ＿Ｓｔｂは順方向リンクレートの２分の１である速度で循環されるので、補正往復遅延測定は２で除算されてから次の整数に切り上げられる必要がある。公式として表すと、この関係性は以下のとおりである。

示されている例の場合、これは以下になる。

この例で使用される往復遅延測定が６と対照的に７であった場合、逆方向レート除数も４に等しくなるであろう。

逆方向リンクデータは、逆方向リンククロックの立ち上がりでホストによりサンプリングされる。逆方向リンククロックを作成するにはホストとクライアント（ディスプレイ）の両方に存在するカウンタ又は類似する公知の回路又は装置がある。カウンタは、逆方向リンククロックの第１の立ち上がりが、逆方向リンクカプセル化パケットの逆方向リンクパケットフィールドの第１のビットの始まりで発生するように初期化される。これは、後述の例について図５２Ａ及び図５２Ｂに示されている。カウンタはＭＤＤＩ＿Ｓｔｂ信号の各立ち上がで増分し、それらがラップアラウンドするまで発生するカウント数は、逆方向リンクカプセル化パケットの中の逆方向レート除数パラメータにより設定される。ＭＤＤＩ＿Ｓｔｂ信号は順方向リンクレートの２分の１でトグルするため、逆方向リンクレートは、逆方向レート除数で除算された順方向リンクレートの２分の１である。例えば、順方向リンクレートが２００Ｍｂｐｓであり、逆方向レート除数が４である場合は、逆方向リンクデータレートは以下のように表される。

逆方向リンクカプセル化パケット内のＭＤＤＩ＿Ｄａｔａ０信号線とＭＤＤＩ＿Ｓｔｂ信号線のタイミングを示す例は図５２Ａ及び図５２Ｂに示されており、図に使用されているパケットパラメータは以下の値を有する。

パケット長＝１０２４（０ｘ０４００） 方向転換１長＝１
パケットタイプ＝６５（０ｘ４１） 方向転換２長＝１
逆方向リンクフラグ＝０ 逆方向レート除数＝２
パラメータＣＲＣ＝０ｘｄｂ４３ 全ゼロは０ｘ００である
パケット長フィールドとパラメータＣＲＣフィールドの間のパケットデータは以下のとおりである。
０ｘ００、０ｘ０４、０ｘ４１、０ｘ００、０ｘ０２、０ｘ０１、０ｘ０１、０ｘ４３、０ｘｄｂ、０ｘ００、．．．
クライアントから返された第１の逆方向リンクパケットは、７というパケット長及び７０というパケットタイプを有するクライアント要求及びステータスパケットである。このパケットはバイト値０ｘ０７、０ｘ００、０ｘ４６、．．．等で開始する。しかしながら、第１のバイト（０ｘ０７）だけが図５２Ａ及び図５２Ｂで可視である。この第１の逆方向リンクパケットは、実際の逆方向リンク遅延を示すために、図中、ほぼ１逆方向リンククロック期間時間移動されている。ゼロホスト付きのクライアント往復遅延への理想的な波形は点線トレースとして示されている。

パラメータＣＲＣフィールドのＭＳバイトは転送され、パケットタイプが先行し、次に全ゼロフィールドが続く。ホストからのストローブは１からゼロに、及びホストからのデータがレベルを変更するにつれて１に切り替わり、さらに幅広いパルスを形成する。データがゼロになると、ストローブはさらに高いレートで切り替わり、データラインでのデータの変化だけが位置合わせフィールドの最後近くで変化を引き起こす。ストローブは長期間、データ信号の固定された０レベル又は１レベルのために図の残りの部分についてさらに高速で切り替わり、パルスパターン（端縁）に立ち下りで遷移する。

ホストの逆方向リンククロックは、クロックが逆方向リンクパケットに対処するために起動される方向転換１期間の最後までゼロである。図の下部の矢印は、開示の残りの部分から明らかとなるようにデータがいつサンプリングされるのかを示している。方向転換１の後に開始した、転送されているパケットフィールドの第１のバイト（ここでは１１００００００）が示されており、線路レベルはディスエーブルされているホストドライバから安定化している。第１のビットの通過の遅延は、ビット３について見られるように、データ信号のための点線から見られる。

図５３では、順方向リンクデータレートに基づいて逆方向レート除数の典型的な値を観察できる。実際の逆方向レート除数は適切な逆方向リンク動作を保証するために往復リンク測定の結果として求められる。第３の領域５３０６は、適切に機能する可能性が低い設定値を示し、第１の領域５３０２は、安全な動作の領域に相当し、第２の領域５３０４は限界性能の領域に相当する。

往復遅延測定及び逆方向レート除数設定値は、それらが送信される又は受信されるビット数よりむしろ実際のクロック期間の単位で表され、動作されるために順方向リンク又は逆方向リンクのどちらかでのインタフェースタイプ設定のどれかで動作している一方で同じである。

一般に、可能な最大の逆方向レート除数は、１型インタフェースを用いた往復遅延測定パケットの測定ウィンドウ内で送ることができるビット数の半分であり、この例では、以下のようになる。

また、改良された逆方向データサンプリング方法は、逆方向ビット時間が、往復遅延よりも小さくなることを可能にする代替例として適用することが可能である。この技術では、ホストは、往復遅延を測定するのみならず、ゼロ遅延のリンクとクライアントとからなる「理想的な」ビット境界に関するクライアントからの応答の位相を決定することができる。クライアントデバイス応答の位相を知ることによって、ホストは、クライアントから逆方向データビットをサンプルするのに比較的安全な時間を決定することができる。この往復遅延測定は、逆方向データパケットフィールドの初めに関して逆方向データの初めのビットの位置をホストに示す。

改良された逆方向データサンプリングの一例の実施形態を、図５２Ｂにグラフィック形式で示す。ゼロ往復遅延の理想的な逆方向データ信号を、点線波形で示す。３．５乃至４．５ ＭＤＤＩ＿Ｓｔｂサイクルの間である実際の往復遅延は、実線波形と理想との間の遅延の相違として示される。これは、往復遅延測定パケットを用いて測定されるものと同じ遅延であり、７順方向リンクビット時間に等しい、測定された往復遅延値となる。この実施形態では、逆方向データビットは、２ＭＤＤＩ＿Ｓｔｂパルス長である。これは４順方向リンクビット時間であり、２に等しい逆方向レート除数に対応する。改良された逆方向データサンプリングの場合、逆方向レート除数は、説明したようにして計算する代わりに、予め選択された２を用いるのが便利である。これは、改良された逆方向データサンプリングのために実質的に最適な選択に見える。なぜなら、理想的なサンプリングポイントは、前述した従来の測定を用いて、容易に決定することができるからである。

逆方向データのための理想的なサンプリングポイントは、往復遅延全体が、逆方向ビット毎の順方向リンククロックの数によって除された余り、すなわち、往復遅延の、逆方向ビット毎の順方向リンククロックによるモジュロを取ることによって容易に計算することができる。そして、１又は２を減じることによりデータ遷移から離れた安全なポイントを得る。この例では、７ｍｏｄ４＝３であるので３−１＝２、又は３−２＝１となる。この安全なサンプリングポイントは、ゼロ往復遅延の場合、「理想的な」ビット境界の端から１又は２の順方向リンクビット時間である。図面は、タイミング図の底部における一連の垂直の矢印によって示すように、理想的なビット境界から２順方向リンクビット時間におけるサンプリングポイントを示している。第一のサンプリングポイントは、測定された往復遅延後の第一の理想的なビット境界に、安全なサンプリングのためのオフセットを加えている。この例では、往復遅延測定値は７であり、次の理想的なビット境界は８番目のビット時間であるので、安全なサンプリングポイントのために１又は２を加える。これによって、最初のビットは、逆方向データパケットフィールドの開始後、９又は１０順方向リンクビット時間においてサンプルされるものとする。

ＸＩ．方向転換及びガード時間
逆方向リンクカプセル化パケットにおける方向転換１フィールドは、ホストドライバをディスエーブルし、クライアントドライバをイネーブルする時間を同時とする。往復遅延測定パケット内のガード時間１フィールドは、ホストとクライアントとのオーバラップを許すので、クライアントドライバは、ホストインタフェースドライバがディスエーブルされる前にイネーブルすることができる。逆方向リンクカプセル化パケット内の方向転換２フィールドは、ホストドライバがイネーブルされる前に、前のフィールド内のデータが、クライアントから完全に送信されるようにすることができる。ガード時間２フィールドは、クライアントドライバ及びホストドライバが論理ゼロレベルにおいて同時に駆動することを許す時間値又は期間を与える。ガード時間１フィールド及びガード時間２フィールドは、一般に、調整されることを意味しない長さについて予め設定されたか、あるいは予め選択された値で埋められる。使用されているインタフェースハードウェアに依存して、これらの値は、動作を改善するために、経験データを用いて発展されたり、あるいは調整される。

方向転換１
複数の要因が方向転換１の長さの決定に寄与し、これらは順方向リンクデータレート、ホスト内のＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間、及び一般にはホストディスエーブル時間と同じであるクライアントドライバのイネーブル時間である。方向転換１フィールドの長さは、２４・ｔ_ＢＩＴになるように選択される（表ＸＩＩＩ）。方向転換１フィールドの順方向リンクバイト数の長さは、インタフェースタイプ因数を用いて決定され、以下の関係を用いて計算される。

ここではインタフェースタイプ因数は１型の場合１であり、２型の場合２であり、３型の場合４であり、４型の場合８である。

方向転換２
方向転換２に通常使用される時間の長さを決定する要因は、通信リンクの往復遅延、クライアント内のＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間、及びクライアントドライバディセーブル時間と同じになるように指定されたホストドライバのイネーブル時間である。ホストドライバイネーブル時間と、クライアントドライバディスエーブル時間との最大は指定されている。往復遅延は、ｔ_ＢＩＴの単位で測定される。方向転換２の順方向リンクバイト数で規定されている最小長さは、以下の関係性に従って計算される。

例えば、１０順方向リンククロックという往復遅延のある３型順方向リンクは、通常、以下の規則による方向転換２遅延を使用する。

ＸＩＩ．代替逆方向リンクタイミング
前述されたタイミングと保護周波数帯は高データ転送速度インタフェースを達成するために努力するが、発明者らは、逆方向タイミング発見を変更することにより、往復時間より短い逆方向ビット長を可能にする技法を発見した。

前記に提示されたように、逆方向リンクのタイミングに対する過去の手法は、クロックサイクルの数が逆方向タイミングパケットのガード時間１の最後のビットから、最初のビットがＩＯクロックの立ち上がりでサンプリングされるまでカウントされるように構成されている。それはＭＤＤＩの入力と出力を計時するために使用されるクロック信号（複数の場合がある）である。したがって逆方向レート除数のための計算は以下により示される。

これは非常に信頼できる逆方向リンクを生じさせる往復遅延に等しいビット幅を提供する。しかしながら、逆方向リンクは、発明者らが利用を希望するさらに高速に、つまりさらに高いデータ転送速度で運転できることが示されてきた。新しい本発明の技法はインタフェースの追加の機能をさらに高速に達するために活用することを可能にする。

これは、ホストに、１がサンプリングされるまでクロックサイクル数をカウントさせることによって達成されるが、ホストは逆方向タイミングパケットの間立ち上がりと立ち下りの両方でデータラインをサンプリングする。これによりホストは、ビットが安定していることを確実にするために、逆方向ビットの中のもっとも有効な、あるいは最適でもあるサンプリング点を選ぶことができる。つまり、逆方向トラフィック逆方向カプセル化パケットにとってデータをサンプリングするためのもっとも有効又は最適な立ち上がりを発見することである。最適なサンプリング点は逆方向リンク除数と、第１のものが立ち上がりで検出されたのか、あるいは立ち下りで検出されたのかの両方に依存している。新しいタイミング方法により、ホストは逆方向カプセル化パケットにおいてどこでサンプリングするのかを決定するために、逆方向リンクタイミングのためにクライアントによって送信される０ｘＦＦ ０ｘＦＦ ０ｘ００パターンの第１の端縁を単に探すことができるようになる。

到着する逆方向ビット及びそのビットがどのようにして多様な逆方向レート除数を探すのかの例は、ガード時間１の最後のビット以来発生した多くのクロックサイクルと共に、図６４に示されている。図６４では、最初の端縁が立ち上がりと立ち下りの間で（立ち上がり／立ち下りと名付けられる）発生すると、それが逆方向ビットの期間内で発生する唯一の立ち上がりであるため、１という逆方向レート除数の最適サンプリング点、つまり最適サンプル点は「ｂ」と名付けられているクロックサイクル端縁である。２という逆方向レート除数の場合、サイクル端縁「ｃ」は「ｂ」よりビット端縁により近いので、最適サンプリング点はおそらく依然としてクロックサイクル前縁「ｂ」である。４という逆方向レート除数の場合、最適サンプリング点は、それは、値がおそらく安定化した逆方向ビットのバックエッジにさらに近いので、おそらくクロックサイクル端縁「ｄ」である。

図６４に戻ると、しかしながら、第１の端縁が立ち下りと立ち上がり（立ち下り／立ち上がりと名付けられた）の間で発生すると、１という逆方向レート除数の最適サンプリング点は、それは逆方向ビット期間内の唯一の立ち上がりであるため、サンプリング点クロックサイクル端縁「ａ」である。２という逆方向レート除数の場合、最適サンプリング点は端縁「ｂ」であり、４という逆方向レート除数の場合は最適サンプリング点は端縁「ｃ」である。

逆方向レート除数がどんどん大きくなるにつれて、真ん中にもっとも近いのは立ち上がりでなければならないので、最適サンプリング点も確かめる又は選択するのが容易になる。

ホストは、タイミングパケットデータの立ち上がりデータがデータラインで観察される前に立ち上がりクロックの数を見つけ出すためにこの技法を使用できる。その結果、それは、端縁が立ち上がりと立ち下りの間で発生するのか、あるいは立ち下りと立ち上がりの間で発生するのか、ならびに逆方向レート除数がいくつであるのか、番号カウンタを追加するためにいくつの追加クロックサイクルが加算されるのかに基づいて、ビットがつねに可能な限り真中近くでサンプリングされることを無理なく保証することを決定できる。

いったんホストがクロックサイクル数を選択又は決定すると、それは、特定の逆方向レート除数が働くかどうかを判断するためにクライアントと多様な逆方向レート除数を「検討」できる。ホスト（とクライアント）は１という除数で開始し、この逆方向レートがデータを転送するために適切に機能するかどうかを判断するために、クライアントから受信される逆方向ステータスパケットのＲＣをチェックできる。ＣＲＣが改悪されている場合、おそらくサンプリングエラーがあり、ホストは逆方向レート除数を高め、ステータスパケットの要求を再び試みることができる。第２の要求したパケットが改悪されている場合には、除数を再び増加でき、要求を再び行うことができる。このパケットが正しく復号されている場合、この逆方向レート除数はすべての将来の逆方向パケットについて使用できる。

この方法は、逆方向タイミングが初期の往復タイミング推定値から変化してはならないために効果的且つ有用である。順方向リンクが安定している場合、クライアントは、逆方向リンク障害があったとしても順方向リンクパケットを復号し続けなければならない。いうまでもなく、この方法は完全な逆方向リンクを保証しないため、リンクのための逆方向リンク除数を設定するのはホストの責任である。加えて、除数はＩＯクロックを作成するために使用されるクロックの質におもに左右される。そのクロックがかなりの量のジッタを有していると、サンプリングエラーの可能性は高くなる。このエラー確率は、往復遅延のクロックサイクル量と共に増加する。

このインプリメンテーションは、１型逆方向データに最善に働くと考えられるが、データライン間の歪みが大きすぎて、ただ１つのデータ組だけ最善に働く速度でリンクを実行できないために、２型から４型の逆方向データでは問題を呈する可能性がある。しかしながら、おそらくデータレートは動作のために２型から４型も用いる前記方法に従って減速される必要はない。この方法は、理想的な、又は最適なクロックサンプルロケーションを選択するために各データラインで重複される場合にも最善に働く可能性がある。それらがデータ組ごとに同じサンプル時間にある場合、この方法は作用し続けるであろう。それらが異なるサンプル期間にある場合には、２つの異なる手法が使用されてよい。第１は、たとえそれが各データ組にとって同じでないにしても、データポイントごとに所望される、あるいはさらに最適化されたサンプルロケーションを選択することである。次にホストはデータ組の集合からビットのすべてをサンプリングした後にデータストリームを再構築できる。つまり、２型に２ビット、３型に４ビット、及びＩＶ型に８ビットである。他方のオプションは、データ組ごとのデータビットを同じクロック端縁でサンプリングできるように、ホストが逆方向レート除数を増加させることである。

ＸＩＩＩ．リンク遅延及び歪みの影響
ＭＤＤＩ＿Ｄａｔａ組とＭＤＤＩ＿Ｓｔｂの間の順方向リンクでの遅延歪みは、遅延歪み補償が使用されない限り、考えられる最大データレートを制限できる。タイミング歪みを引き起こす遅延の差異は、コントローラ論理回路、ラインドライバとレシーバ、及び以下に概略されるようなケーブルとコネクタに起因している。

Ａ．歪みによって制限されるリンクタイミング分析（ＭＤＤＩ１型）
１．1型リンクの遅延及び歪みの例
図４１に示されているインタフェース回路に類似した典型的なインタフェース回路は、１型インタフェースリンクに対処するために図５７に示されている。図５７では、伝搬遅延と歪みの例示的な又は典型的な値は、ＭＤＤＩ１型順方向リンクの複数の処理又はインタフェース段のそれぞれに示される。ＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿Ｄａｔａ０の間の遅延の歪みは、図５８に示すように、出力クロックのデューティサイクルを変形させる。いくつかの場合、これは、ＲＸＦＦステージに対する設定時間を、非常に小さくする。フリップフロップ５７２８、５７３２を使用する受信機フリップフロップ（ＲＸＦＦ）ステージのＤ入力でのデータは、それが確実にサンプリングできるようにクロック端縁後にわずかに変化する。図は、このタイミング関係を生じさせることにまつわる２つの異なる問題点を解決するために使用されている２つのカスケード式遅延線路５７３２ａと５７３２ｂを示している。実際のインプリメンテーションでは、これらは単一の遅延要素に結合されてよい。

インタフェースを通した例示的な信号処理のための１型リンク上でのデータ、Ｓｔｂ（ストローブ）及びクロック回復タイミングは、図５８に示されている。

著しい総遅延歪みは通常、以下のステージの歪みの合計から発生する又は生じる。つまりフリップフロップ５７０４、５７０６付きの送信機フリップフロップ（ＴＸＦＦ）、ドライバ５７０８、５７１０付きの送信機ドライバ（ＴＸＤＲＶＲ）、ケーブル５７０２、受信機５７２２、５７２４付きの受信機ラインレシーバ（ＲＸＲＣＶＲ）、及び受信機ＸＯＲ論理回路（ＲＸＸＯＲ）である。遅延１ ５７３２ａは、以下の関係性によって決定されるＲＸＸＯＲステージでのＸＯＲゲート５７３６の遅延に一致、又は超えなければならない。

受信機フリップフロップ５７２８、５７３２のＤ入力が、そのクロック入力の前に変化しないようにこの要件を満たすことが望ましい。これはＲＸＦＦの保持時間がゼロである場合に有効である。

遅延２の目的又は機能は、以下の関係性に従ってＲＸＦＦフリップフロップの保持時間を補償することである。

多くのシステムでは、保持時間がゼロであるため、これはゼロとなり、いうまでもなくその場合遅延２の最大遅延もゼロとなる場合がある。

受信機ＸＯＲステージでの最悪のケースの歪みへの貢献は、遅延１が最大値であり、ＸＯＲゲートからのクロック出力が以下の関係性に従って可能な限り早期に起こるデータ−遅れ／ストローブ−早期ケースにある。

この状況では、データは、ビットｎ＋１が受信機フリップフロップの中に記録される時間に非常に近い２ビット期間、ｎとｎ＋１の間で変化する可能性がある。

ＭＤＤＩ １型リンクの最大データレート（最小ビット期間）は、ＲＸＦＦステージに合計データセットアップを加えたＭＤＤＩリンク内のすべてのドライバ、ケーブル、及び受信機を通して遭遇される最大歪みの関数である。ＲＸＲＣＶＲステージの出力までのリンクの総遅延歪みは以下のように表現でき、

ここで、「ケーブル」は、種々の導電体又は相互接続又は有線と、対応する遅延を表し、最小ビット期間は、

によって指定される。

図５７に示される例では、外部モードの場合、ｔ_{ＳＫＥＷ−ｍａｘ（ＬＩＮＫ）}＝１００ｐｓｅｃであり、最小ビット期間は以下のように表現できる。

ｔ_{ＢＩＴ−ｍｉｎ}＝１０００＋２．１２５＋６２５＋１２５＋２００＋０＋１００＝２３００ｐｓｅｃ、つまり約４３４Ｍｂｐｓとして述べられる。図５７に示される例では、内部モードの場合、ｔ_{ＳＫＥＷ−ｍａｘ（ＬＩＮＫ）}＝５００ｐｓｅｃであり、最小ビット期間は以下のように表現できる。

ｔ_{ＢＩＴ−ｍｉｎ}＝５００＋２．１２５＋６２５＋１２５＋２００＋０＋１００＝１８００ｐｓｅｃ、つまり約５５５Ｍｂｐｓとして述べられる。

ホストが、遅延歪み校正パケットを用いる場合、

からなる歪み校正を用いたホストのためのクロックジッタ要求及び最大遅延対称と、歪み校正を用いたホストのための最大遅延歪み要求

によって定義されるようなホストデバイスにおける遅延対称性、遅延歪み、クロックジッタの更なる要求がある。

Ｂ．ＭＤＤＩ２型、３型及び４型のリンクタイミング分析
図４１と図５７に示されるインタフェース回路に類似する典型的なインタフェース回路は、２型、ＩＩＩ型、ＩＶ型インタフェースリンクに対処するために図５９に示されている。追加の要素は、追加の信号処理に対処するためにＴＸＦＦ（５９０４）、ＴＸＤＲＶＲ（５９０８）、ＲＸＲＣＶＣＲ（５９２２）及びＲＸＦＦ（５９３２、５９２８、５９３０）段で使用される。図５９では、伝搬遅延と歪みの例示的な又は典型的な値が、ＭＤＤＩ２型順方向リンクの複数の処理段階又はインタフェース段階のそれぞれに示されている。出力クロックのデューティサイクルに影響を及ぼすＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿Ｄａｔａ０の間の遅延での歪みに加えて、これらの２つの信号と他のＭＤＤＩデータ信号の両方の間にも歪みがある。フリップフロップ５９２８と５９３０からなる受信機フリップフロップＢ（ＲＸＦＦＢ）段のＤ入力でのデータは、それが確実にサンプリングできるようにクロック端縁の後変更される。ＭＤＤＩ＿Ｄａｔａ１がＭＤＤＩ＿Ｓｔｂ又はＭＤＤＩ＿Ｄａｔａ０より早く到着すると、ＭＤＤＩ＿Ｄａｔａ１は少なくとも遅延歪みの量、サンプリングされるのを遅らされなければならない。これを達成するためには、データは遅延３遅延線路を使用して遅延されている。ＭＤＤＩ＿Ｄａｔａ１がＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿Ｄａｔａ０より後に到着し、それが遅延３分遅延する場合には、ＭＤＤＩ＿Ｄａｔａ１が変化する点が次のクロック端縁のより近くに移動する。このプロセスがＭＤＤＩ２型、３型又は４型リンクのデータレートの上限を決定する。２つのデータ信号とＭＤＤＩ＿Ｓｔｂの互いに関するタイミング又は歪み関係性に対するいくつかの例示的な異なる可能性は、図６０Ａ、図６０Ｂ及び図６０Ｃに示されている。

ＭＤＤＩ＿ＤａｔａＸが可能な限り早期に到着するときにＲＸＦＦＢで確実にデータをサンプリングするために、遅延３は以下に従って設定されている。

最大リンク速度は、最小許容ビット期間により決定される。これは、ＭＤＤＩ＿ＤａｔａＸが可能な限り遅れて到着すると最も影響を受ける。その場合、最小許容サイクル時間は以下によって示される。

したがって、リンク速度の上限は

であり、以下を考えれば

前記に示される例では、最小ビット期間の下限は以下の関係性により示される。

つまり約１７４Ｍｂｐｓである。

これは、１型リンクと共に使用できる最大データレートよりはるかに遅い。ＭＤＤＩの自動遅延歪み補償機能は、遅延歪みが、有効なデータ設定をしようとしている最大リンクレートファクタに対して及ぼす影響を大幅に削減する。ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂとの間で校正された歪みは、

であり、最小ビット期間は、

である。

ここで、“ＴＢ”すなわちｔ_ｂは、ビット境界から最小出力レベルへの信号ジターを表す。非対称は、単に、差分受信機を通った、又は差分受信機の内部遅延の非対称な性質を称している。“ＴＰ４”は、電気特性に関連付けられ、差分ラインドライバのための接続又はインタフェース（クライアントにおけるＭＤＤＩコントローラデバイスのピン）、及びクライアントのための受信機としての目的を試験するために効率的に定義されている。それは、便利な、又は予め定めたポイントを表す。ここから信号遅延が測定され、システムの残りにわたったリンクのために特徴付けられる。一つの実施形態では、ＴＰ４におけるパラメータｔ_Ｂの最大値は、外部モードについて、

であり、クライアント送信機の内部モードについて、

であり、クライアント受信機の外部モードについて、

である。

ラベルＴＰ４は、種々の試験ポイント（ＴＰ）をナンバリングするのに簡単であり役立ち、インタフェース及びリンクである。一つの実施形態では、この試験ポイントは、内部モードと外部モードとの両方に同じになるように定義される。差分ラインドライバ及び受信機を含むホスト内のＭＤＤＩコントローラデバイスの接続又はインタフェースピンのための、又は関連した対応する“ＴＰ０”が存在する。この実施形態では、ＴＰ０におけるパラメータＴ_Ｂの最大値は、内部モードの場合、

ホスト受信機の外部モードの場合、

ホスト送信機の場合、

の関係によって定義される。

図５９に示す例では、

であり、最小ビット期間は、

であり、約６０６Ｍｂｐｓである。

ＭＤＤＩ＿Ｄａｔａ１が到着したとき、可能な限り早くＲＸＦＦＢ内のデータを高い信頼性でサンプルするために、関連するプログラム可能な遅延が、一つのタップの精度を用いて最適な設定に調整され、追加のタップ遅延が安全のために追加される。最大リンク速度は、最小許容ビット期間によって決定される。これは、ＭＤＤＩ＿Ｄａｔａ１が可能な限り遅れて到着した場合に最も影響を受ける。この場合、最小許容サイクル時間は、

となる。ここで、“ＴＡ”すなわちｔ_Ａは、ビット境界から中心交点への信号ジターを表す。

図５９に示す例では、サンプリングＭＤＤＩ＿Ｄａｔａ１に基づく最小ビット期間の下部境界は、

である。

一つの実施形態では、内部モードのホストにおけるクロックジター、遅延非対称、及び遅延歪みのための典型的な合計遅延時間は、

のように定義され、外部モードの場合、

のように定義される。

一方、内部モードにおけるクライアントデバイス内の設定時間（ｔ_{Ｂ−ＴＰ４}）、遅延非対称、及び遅延歪みのための典型的な合計遅延時間は、

であり、外部モードの場合は、

である。ここで、項ＴＢＤは、外部モード接続に必要な良く知られた様々な特徴及び動作要求に依存した値に定められる将来のためのラベルを保持したフレキシブルな場所である。

図５９に類似しており、遅延歪み補償回路を備え、ＭＤＤＩ ２型順方向リンクの実施形態の典型的なインタフェース回路は、図６１に示されている。更なる要素、つまり選択可能な遅延素子６１０２，６１０４は、校正入力ドライバ６１０６，６１０８と共にＲＸＲＣＶＣＲステージの後に使用される。校正入力ドライバ６１０６，６１０８はそれぞれＡＮＤゲート６１１２，６１１４に結合されている。ＡＮＤゲート６１１２，６１１４の出力は、ＸＯＲゲート６１１６に接続されている。ＸＯＲゲート６１１６は、図示するように、ＲＸＦＦＡステージに入力を提供する。これら素子は、更なる信号処理に適応するために使用される。ドライバ６１０８，６１０６は、信号経路のための構成を許可する。一方、遅延素子６１０２，６１０４は、ドライバ５７２４，５９２４それぞれの出力のための信号転送経路のために使用又は入力される選択可能な遅延量を許可する。

この例では、データ及びストローブ信号の相対的な到着時間を精密に調整するために可変遅延６１０２，６１０４が使用される。これら信号の到着時間を並べることによって、受信機内のＤフリップフロップ（５７２８，５７３０，５９２８，５９３０）の入力におけるデータが、前もって良好に設定されるようになる。クライアントデバイスが、順方向リンク歪み校正パケットの校正データシーケンスフィールドを受信する場合、単純な状態機械が、差分ペア信号の全てに関する同時遷移を調べ、最適な調節可能な遅延設定が決定される。この状態機械は、逐次近似アルゴリズムを用いて可変遅延を調節し、データが安全にサンプルされるポイントを探索する。そして、最も安全な設定を１タップ進めることによって遅延を調節し、信頼できる動作（これは、ＭＤＤＩ＿Ｓｔｂ経路上の１少ないタップであり、ＭＤＤＩ＿Ｄａｔａ経路上の１多いタップとなる）を保障する。校正データシーケンスフィールドは、これを容易にするために、差分ペアの全てに関する極めて多い同時遷移を含む。

図６１で与えられた例では、サンプリングＭＤＤＩ＿Ｄａｔａ１に基づく最小ビット期間の下部境界は、

である。

これは、ＭＤＤＩ＿Ｄａｔａ１のための校正されないリンクタイミングに比べて著しい改良である。しかしながら、遅延歪み校正リンクに関する最大データレートのための１つの可能な決定因子は、通常は、上述した例に示すように、ＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿Ｄａｔａ０との間の遅延に一定させる能力によって制限される。例えば、図６１の遅延５に対する精密な調整を提供することのように、説明した歪み補償アーキテクチャに対する可能な改良は多数ある。

遅延歪み補償が用いられる場合、一般に、ホストドライバの出力において許可された、あるいは許可することが可能な差分歪み量に対する上限が存在する。この制限あるいは制約がないと、差分歪み量が極めて大きな範囲になってしまい、非常に低いデータレートで動作するホストデバイスのために、クライアントデバイスにおける補正が必要となる。歪み補償の主な用途は、デバイスが、高速で動作できるように、遅延歪みを低減することであるので、遅延歪みの最上限は、一般に、遅延歪み補償を使用するホストのために、システム又はデバイス設計者によって指定される。クライアントデバイスで使用される歪み補償の合計量は、以下の３つのパラメータの合計である。すなわち、図６１に示すＴＸＦＦ＋ＴＸＤＲＶＲステージの最大遅延歪みであるホストドライバ出力における最大差分歪みと、図６１におけるＣＡＢＬＥステージの最大遅延歪みであるＴＰＯからＴＰ４への相互接続サブシステムにおける最大差分歪みと、差分受信機入力とデータサンプリング回路との間のクライアントにおける最大差分歪みとである。後者のパラメータは、図６１のＲＸＲＣＶＲステージの入力から、ＲＸＦＦＡステージ及びＲＸＦＦＢステージの入力までの最大の遅延歪みである。

ＸＩＶ．物理層相互接続説明
本発明に従ってインタフェースを実現するために有効な物理接続は、ホスト側でヒロセ電機株式会社（Ｈｉｒｏｓｅ Ｅｌｅｃｔｒｉｃ Ｃｏｍｐａｎｙ Ｌｔｄ．）により製造されるパーツ番号３２６０−８Ｓ２（０１）、クライアントデバイス側でヒロセ電機株式会社（Ｈｉｒｏｓｅ Ｅｌｅｃｔｒｉｃ Ｃｏｍｐａｎｙ Ｌｔｄ．）により製造されるパーツ番号３２４０−８Ｐ−Ｃ等の市販されているパーツを使用して実現できる。１型／２型インタフェースと共に使用されるこのようなコネクタ向けの例示的なインタフェースピン割り当て、つまり「ピン配列」は、表ＸＶに一覧表示されている。

シールドは、ホストインタフェース内のＨＯＳＴ＿Ｇｎｄに接続され、ケーブルの中のシールドドレイン線はクライアントコネクタのシールドに接続されている。ただし、シールドとドレイン線はクライアントの内部の回路接地には接続されていない。

相互接続要素又は素子は、相対的な装置サイズに比べて邪魔にならず、悪趣味にならずにＰＤＡ及び無線電話、あるいは携帯ゲーム機等の移動体通信装置及び計算装置と使用するほど十分小型であるために選ばれる、あるいは設計されている。あらゆるコネクタ及びケーブル布線は、典型的な消費者環境で使用するのに十分なほど耐久性があり、特にケーブル布線のために小型に対処し、相対的に低コストでなければならない。転送要素は、１型と２型の場合、最高４５０Ｍｂｐｓ、８ビット並列４型バージョンの場合最高３．６Ｇｂｐｓの転送率を有する差動ＮＲＺデータであるデータ信号とストローブ信号に対処する必要がある。

内部モードの応用例の場合、使用されている導線に対して同じ向きのコネクタはないか、あるいはこのような接続要素は非常に小型化する傾向があるかのどちらかである。１つの例は、集積回路又はホスト又はクライアントデバイスのどちらかを収容している素子を受け入れるためのゼロ挿入力の「ソケット」である。別の例はホストとクライアントが多様な相互接続導線と共にプリント基板上で常駐し、集積回路の相互接続のために導線上での接点にはんだ付けされているハウジングから伸びる「ピン」又は「接点」を有する場合である。

例えば、前述した内部モードの場合、２つのクライアントを接続することに注目した場合、より適切なデータ転送及び通信のために主クライアントを配置する際に、ケーブリング、接続、及び一定の要因に対して注意が向けられるべきである。クライアントを接続するケーブルまたは接続は、図９９に例示される構成で例示されるような終端されていないスタブから本質的に構成される伝送ラインを形成する。図９９には、２つのスタブ、すなわちｓｔｕｂ_１とｓｔｕｂ_２に分岐する導線９９０４に接続されるホスト９９０２が示されている。ｓｔｕｂ_１及びｓｔｕｂ_２は、ホストから、位置Ｂ及び位置Ａに位置するクライアントへそれぞれ信号を供給又は転送する。また、単なる例示の目的であって、本発明のあらゆる実施例又は応用に関する限定ではなく、クライアントはここでは、ＬＣＤコントローラ又はＬＣＤディスプレイ素子又はパネルの一部として、これらに接続されて、これらに関連付けられて、あるいはこれらと通信して示されている。これら２つのクライアントデバイスが内部モードで接続されている場合、ＭＤＤＩ＿Ｄａｔａペアに関する送受信を行い、終端レジスタ（インピーダンス）とともに配置されている主クライアントデバイスは、ケーブルの「終端」に位置又は接続されるべきである。ケーブルの「終端」は、図９９では、「位置Ａ」として特定され、長さＬ_{ｓｔｕｂ１}は、長さＬ_{ｓｔｕｂ２}よりも短いかあるいは等しい。他のクライアント（あるいは、場合によっては複数の他のクライアント）は、ケーブルからの分岐の「終端」に位置又は接続されている。ケーブルは、終端とホストとの中間に位置する。ホストは、図９９では、「位置Ｂ」として示される。図９９は、一般に、このような送信ラインスタブが、実施形態の用途のために、当該技術における熟練者によってどのように定義されるかを示す。本発明の種々の実施形態の装置及び技術を利用する者は、ドライバ出力信号の最小立ち上がり時間と送信ラインの速度要因とを考慮しながら、一般に、信号品質があらゆる制約又は要件を満足することを保障して、適切な高速動作とエラーのない（あるいは最小な）通信を維持するように、送信ラインにおけるスタブの長さを制限することによって、このような構成を実施すべきである。

ＸＶ．動作
本発明の実施形態を使用するインタフェースの動作中にデータとパケットを処理する上で講じられる一般的なステップのまとめは、図５５のパケットを処理するインタフェース装置の概要と共に、図５４Ａと図５４Ｂに示されている。これらの図中、プロセスは、クライアント及びホストが通信経路、ここではケーブルを使用して接続されているかどうかに関する決定を行うステップ５４０２で開始する。これは、（ＵＳＢインタフェースについて見られているように）ホストへの入力でコネクタ又はケーブル又は信号の存在を検出するソフトウェア又はハードウェアを使用する、ホストによる周期的なポーリングを使用することによって、あるいは他の公知の技法で発生する場合がある。ホストに接続されているクライアントがない場合には、それは、応用例に応じて単に所定の長さの待機状態に入る、ハイバネーションモードに入る、あるいはユーザにホストを再アクティブ化するための処置を講じることを要求する可能性のある将来の使用に待機するために非活性化される場合がある。例えば、ホストがコンピュータタイプの装置に常駐するとき、ユーザは画面アイコンをクリックする、あるいはクライアントを探すためにホスト処理をアクティブ化するプログラムを要求しなければならない可能性がある。再び、ホスト又は常駐ホストソフトウェアの機能と構成に応じてＵＳＢ型接続の簡略なプラグインにより、ホスト処理をアクティブ化できるであろう。

いったんクライアントがホストに接続される、あるいはその逆の場合、又は存在しているとして検出される場合、クライアント又はホストのどちらかがステップ５４０４と５４０６でサービスを要求する適切なパケットを送信する。クライアントはステップ５４０４でクライアントサービス要求パケット又はステータスパケットのどちらかを送信できるであろう。前述されたように、リンクは、これが続く通信リンクの完全な初期化ではないように、過去にシャットダウンできた、あるいはハイバネーションモードであったことが注記される。いったん通信リンクが同期され、ホストがクライアントと通信しようとすると、クライアントはステップ５４０８でのように、ホストへクライアント機能パケットも提供する。ホストは、ここでクライアントが対処できる転送速度を含むサポートのタイプの決定を開始できる。

一般的には、ホストとクライアントは、ステップ５４１０で例えば１型、２方等の使用されるサービスモードのタイプ（速度／速度）も交渉する。いったんサービスタイプが確立されると、ホストは情報の転送を開始できる。加えて、ホストは、ステップ５４１１に図示されるように他の信号処理と並列に通信リンクのタイミングを最適化するために往復遅延測定パケットを使用してよい。

前述されたように、すべての転送は、データのタイプ、ここではビデオ及び音声ストリームパケット、及びステップ５４１４で転送されているのが示されるフィラーパケットが後に続く、ステップ５４１２で転送されているのが示されるサブフレームヘッダパケットで開始する。音声データとビデオデータは過去に作成された又はパケットの中にマッピングされ、フィラーパケットはメディアフレーム用の必要数のビットを記入するために必要に応じて、又は所望されるように挿入される。ホストは、サウンドデバイスをアクティブ化するために順方向音声チャネルイネーブルパケット等のパケットを送信できる。加えて、ホストは前述された他のパケットタイプ、ここではカラーマップの転送、ビットマップブロック転送、又はステップ５４１６の他のパケットを使用してコマンド及び情報を転送できる。さらに、ホストとクライアントは適切なパケットを使用してキーボード又はポインティングデバイスに関連するデータを交換できる。

動作中、インタフェースモードの別のデータレート又はタイプを所望するホスト又はクライアントにつながる複数の異なるイベントの１つが発生することがある。例えば、コンピュータ又はデータを通信する他の装置は、パケットの作成又はプレゼンテーションにおいて低速化を引き起こすデータを処理する際の荷重条件に遭遇するであろう。データを受信するクライアントデバイスは専用ＡＣ電源からさらに制限された電池電源に変更し、データを迅速に転送できない、容易にコマンドを処理できない、あるいはより限られた電力設定の元で同程度の解像度又はカラー階調を使用できないであろう。代わりに、制限条件は排除される、あるいは姿を消し、装置がさらに高速でデータを転送できるようにする。これはより望ましく、さらに高速の転送速度モードへの変更を要求できる。

これらのあるいは他の種類の公知の条件が発生する、あるいは変化する場合、ホスト又はクライアントのどちらかはそれらを検出し、インタフェースモードを再交渉しようとしてよい。これは、ホストが、別のモードへのハンドオフを必要とするクライアントにインタフェースタイプハンドオフ要求パケットを送信するステップ５４２０で示され、クライアントは変更が求められることを確認するインタフェースタイプ肯定応答パケットを送信し、ホストは、指定されたモードに変更するために実行型ハンドオフパケットを送信する。

このような要素はホスト側に存在してもよいが、処理の特定の順序を要求していないが、クライアントとホストはポインティングデバイス、キーボード、又はおもにクライアントと関連付けられる他のユーザ型入力装置向けの、あるいはそれらから受信されたデータに関連するパケットも交換できる。これらのパケットは、通常、状態機械（５５０２）ではなく、汎用プロセッサタイプの素子を使用して処理される。加えて、前述されたコマンドのいくつかは汎用プロセッサ（５５０４、５５０８）によっても処理されるであろう。

データとコマンドがホストとクライアントの間で交換された後で、なんらかの点で、追加データが転送されるべきかどうか、あるいはホスト又はクライアントが転送にサービスを提供するのをやめるかどうかに関して決定が下される。これはステップ５４２２に示されている。リンクがハイバネーション状態に入る、又は完全にシャットダウンされるのどちらかである場合、ホストはクライアントにリンクシャットダウンパケットを送信し、両方の側がデータの転送を終了する。

前記動作処理で転送されているパケットは、ホストコントローラとクライアントコントローラに関連して前述されたドライバと受信機を使用して転送される。これらのラインドライバ及び他の論理素子は図５５の概要に示されているように、前述された状態機械と汎用プロセッサに接続されている。図５５では、状態機械５５０２及び汎用プロセッサ５５０４と５５０８がさらに、専用のＵＳＢインタフェース、メモリ素子、又はビュー表示装置用のデータソースとビデオ制御チップを含むがこれらに限定されない、それらが対話するリンクコントローラの外部に常駐する他の構成部品等の図示されていない他の要素に接続されてよい。

プロセッサ及び状態機械は、通信リンクの効率的な確立又は終端、及びパケットの転送を保証するために、ガード時間に関して関連して前述されたようなドライバのイネーブルとディスエーブルに制御を提供する。

ＸＶＩ．ディスプレイフレームバッファ
ビデオデータバッファリング要件はコンピュータグラフィックと比較して、動画ビデオ画像について異なっている。ピクセルデータは、クライアント上の画像を局所的にリフレッシュできるように、ほとんどの場合クライアント内のローカルフレームバッファに記憶される。

フルモーションビデオが表示されている（ディスプレイ内のほぼすべてのピクセルが各メディアフレームを変更する）とき、ディスプレイ上の画像は第２のフレームバッファからリフレッシュされているが、通常、１つのフレームバッファの中に入信ピクセルデータを記憶することが好ましい。３つ以上のディスプレイバッファは後述されるように可視アーチファクトを排除するために使用されてよい。画像全体が１つのフレームバッファ内に受け入れられると、バッファの役割は交換でき、新規に受信された画像は次にディスプレイをリフレッシュするために使用され、他のバッファは画像の次のフレームで充填される。この概念は、ピクセルデータが、表示更新ビットを「０１」に設定することによりオフライン画像バッファに書き込まれる図８８Ａに示されている。

他の応用例では、ホストは画像全体を塗り直す必要なく、画像の小さな部分だけを更新する必要がある。この状況では、図８８Ｂに詳細に示されるように、新しいピクセルを、表示をリフレッシュするために使用されているバッファに直接的に書き込むことが望まれる。

小型ビデオウィンドウ付きの固定画像を有する応用例では、図８８Ｃに示されるように両方のバッファ（「１１」に等しい表示更新ビット）に固定された画像を書き込み、後に表示更新ビットを「０１」に設定することによりオフラインバッファに動画のピクセルを書き込むことが最も容易である。

以下の規則は、同時に新しい情報をクライアントに書き込み、表示をリフレッシュしながら、バッファポインタの有効な操作を記述している。３つのバッファポインタが存在する。つまり、ｃｕｒｒｅｎｔ＿ｆｉｌｌは、ＭＤＤＩリンク上でデータから現在充填されているバッファを指す。ｊｕｓｔ＿ｆｉｌｌｅｄは、最も最近充填されたバッファを指す。ｂｅｉｎｇ＿ｄｉｓｐｌａｙｅｄは表示をリフレッシュするために現在使用されているバッファを指す。すべての３つのバッファポインタは０からＮ−１の値を含んでよく、Ｎはディスプレイバッファの数であり、Ｎ≧２である。バッファポインタ上の演算はＮを係数としている。例えばＮ＝３及びｃｕｒｒｅｎｔ＿ｆｉｌｌ＝２のとき、ｃｕｒｒｅｎｔ＿ｆｉｌｌを増分すると、ｃｕｒｒｅｎｔ＿ｆｉｌｌは０に設定される。Ｎ＝２である単純な場合には、ｊｕｓｔ＿ｆｉｌｌｅｄはつねにｃｕｒｒｅｎｔ＿ｆｉｌｌの補数である。あらゆるＭＤＤＩメディアフレーム境界（サブフレームカウントフィールドがゼロに等しいサブフレームヘッダパケット）で、指定された順序で以下の演算を実行する。ｊｕｓｔ＿ｆｉｌｌｅｄをｃｕｒｒｅｎｔ＿ｆｉｌｌに等しく設定し、ｃｕｒｒｅｎｔ＿ｆｉｌｌをｃｕｒｒｅｎｔ＿ｆｉｌｌ＋１に設定する。

ＭＤＤＩビデオストリームパケットは、以下の構造又は方法論に従ってバッファ更新する。つまり表示更新ビットが「０１」に等しいとき、ピクセルデータはｃｕｒｒｅｎｔ＿ｆｉｌｌによって指定されるバッファに書き込まれる。表示更新ビットが「００」に等しいとき、ピクセルデータはｊｕｓｔ＿ｆｉｌｌｅｄによって指定されるバッファに書き込まれる。及び、表示更新ビットが「１１」に等しいときには、ピクセルデータはすべてのバッファに書き込まれる。表示はｂｅｉｎｇ＿ｄｉｓｐｌａｙｅｄポインタによって指定されるバッファからリフレッシュされる。表示が１つのフレームリフレッシュエポックの最後のピクセルをリフレッシュした後、及びそれが次のフレームリフレッシュエポックの中の最初のピクセルのリフレッシュを開始する前に、表示更新プロセスはｂｅｉｎｇ＿ｒｅｆｒｅｓｈｅｄをｊｕｓｔ＿ｆｉｌｌｅｄに等しく設定する動作を実行する。

ピクセルデータ属性フィールドを備えたパケットは、ピクセルデータが書き込まれるフレームバッファを指定する１組の表示更新ビットを含む。クライアント機能パケットは、表示更新ビットのどの組み合わせがクライアントでサポートされるのかを示す３つの追加ビットを有する。多くの場合、コンピュータにより作成される画像はユーザ入力に基づいて増分的に更新される、あるいはコンピュータネットワークから受信される情報から引き出される必要がある。表示更新ビット組み合わせ「００」と「１１」は、ピクセルデータを、表示されているフレームバッファに、あるいは両方のフレームバッファに書き込ませることによってこの運転モードをサポートする。

ビデオ画像に対処するとき、図８９は、ビデオデータが、表示更新ビットが「０１」に等しい状態でＭＤＤＩリンク上で送信されるときに１組のフレームバッファを使用してどのようにしてビデオ画像が表示されるのかを示す。メディアフレーム境界がＭＤＤＩリンクで検出されると、表示リフレッシュプロセスは、現在リフレッシュされているフレームのリフレッシュプロセスが完了すると次のフレームバッファからのリフレッシュを開始する。

図８９に関連する重要な仮定は、画像が、クライアントが表示をリフレッシュするためにフレームバッファからピクセルを読み取るのに使用するのと同じ順序で（通常、左上、行ごとに読み取り、画面の右下角へ）送信されるピクセルの連続ストリームとしてホストから受信されるという点である。これは、表示リフレッシュ動作と画像転送動作が同じフレームバッファを参照している場合に重要な詳細である。

部分的な画像を表示するのを回避するために、表示リフレッシュフレームレートが画像転送フレームレートを上回ることが必要である。図９０は、どのようにしてゆっくりとした表示リフレッシュ速度で画像フラグメンテーションが発生できるのか、つまりどのようにして表示リフレッシュが画像転送より低速なのかを示す。

コンピュータグラフィックス画像と動画ビデオ画像の組み合わせを含む画像では、ビデオピクセルデータはメディアフレームの小さい部分を含んでいる可能性がある。これは、表示リフレッシュ動作と画像転送が同じフレームバッファを参照する状況では重要になるであろう。これらの状況は、表示をリフレッシュするためにバッファから読み取られたピクセルが２コマ前のバッファに書き込まれたピクセルである可能性がある、あるいはそれらが同じフレームバッファに直ちに書き込まれているフレームに一致する可能性がある、図９１で斜行平行線の陰影により示されている。

３つのフレームバッファをクライアントで使用すると、図９２に示されているようなフレームバッファへのアクセスの競合のある小さなウィンドウの問題が解決される。

ただし、図９３に示されているように、表示リフレッシュレートがＭＤＤＩリンク上のメディアフレームレート未満である場合には依然として問題がある。

図９４に示されるように、単一バッファを動画ビデオ画像に使用することはやや問題がある。バッファへの画像転送より高速の表示リフレッシュの場合、リフレッシュされている画像が書き込まれているフレームの上部を示し、画像の下部は過去に転送されたフレームとなる。画像転送より高速の表示リフレッシュ（好ましい運転モード）の場合、類似する分割された画像を示すフレームの例がより頻繁になるであろう。

ＸＶＩＩ．マルチプルクライアントサポート
現在のプロトコルバージョンは、複数のクライアントデバイスを直接的にサポートしているように考えられない。しかしながら、大部分のパケットは、複数のクライアントがいるシステム内で特定のクライアントデバイスをアドレス指定するために使用できる予約クライアントＩＤフィールドを含んでいる。現在、多くの応用例の場合、このクライアントＩＤ又はこれらのクライアントＩＤはゼロに設定される。サブフレームヘッダパケットもホストが複数のクライアントシステムをサポートするか否かを示すためのフィールドを含む。したがって、複数のクライアントデバイスが、複数のクライアントホスト又はクライアントとの将来の互換性のためにシステム設計者が計画するのを支援するためにＭＤＤインタフェース又はプロトコルの将来の応用例で接続され、アドレス指定される可能性がある様式がある。

複数のクライアントを有するシステムでは、図９５に示されるように、クライアントのデイジーチェーンを使用して、又はハブを使用して、あるいは図９６に示されるようにこれらの技法の組み合わせを使用してクライアントがホストに接続されるのが有用である。また、例えば、アドレス０を要求する一人又は複数のクライアントが接続された場合のエラーメッセージのように、ホストが、あるエラーメッセージを表示して、接続されたクライアントを管理することは役に立つかもしれない。なお、この例は、ディスプレイが、唯一のクライアントとして動作するように期待あるいは設定されているようなマルチクライアントシステムの場合には当てはまらない。

ＶＸＩＩＩ．補遺
本発明の実施形態のためのアーキテクチャ及びプロトコルを実現するために使用される多様なパケットについて前述されたフォーマット、構造、及びコンテンツに加えて、さらに詳しいフィールドコンテンツ又は動作がここではパケットタイプのいくつかのために提示されている。これらは、ここで当業者が種々の応用例のために本発明をさらに容易に理解し、利用できるようにするために、そのそれぞれの使用又は動作をさらに明確にするためにここで提示されている。すでに説明されていないフィールドの内の数個しかここではさらに説明されない。さらに、これらのフィールドには、前記に提示された実施形態に関連した例示的な定義及び値が提示される。

しかしながら、このような値は本発明の制限として解釈されるべきではなく、インタフェースとプロトコルを実現するために有効な１つ又は複数の実施形態を表し、すべての実施形態がいっしょに又は同時に実践される必要はない。他の値は、当業者により理解されるように、データ又はデータレート転送結果の所望されるプレゼンテーションを達成するために、他の実施形態で使用できる。

Ａ．ビデオストリームパケットの場合
一実施形態では、ここでは２バイトであるピクセルデータ属性フィールドは、以下のように解釈される一連のビット値を有する。ビット１と０は、どのようにして表示ピクセルデータが送られるのかを選択する。「１１」というビット値の場合、ピクセルデータは両目に、又は両目用に展示され、ビット値「１０」の場合、ピクセルデータは左目だけに送られ、ビット値「０１」の場合、ピクセルデータは右目だけに送られ「００」というビット値の場合、データは後述されるようなビット８から１１によって指定されるように代替ディスプレイに送られる。クライアント内、又はクライアントによって操作されているか、又は使用されている主ディスプレイが、ステレオ画像又はある形式の画像をサポートしていないのであれば、コマンドは、ディスプレイによって望まれるようなインパクトを持つように効果的に埋め込むことはできない。この状態又は設定では、クライアントは、ビット値、すなわち、‘０１’、‘１０’、‘１１’のいかなるビット組み合わせにも関わらず、ピクセルデータを主ディスプレイに経路付けるべきである。なぜなら、結果として得られるコマンド又は制御は、このディスプレイによって実行されないからである。本実施形態では要求されないが、ステレオディスプレイ機能をサポートしないこれらクライアントにおける主ディスプレイに対処するために値‘１１’が使用されることが推奨される。

ビット２は、「０」という値がピクセルデータが標準漸次フォーマットであることを意味し、行番号（ピクセルＹ座標）が、ある行から次の行に進むときに１増分されることを意味する、ピクセルデータがインタレースフォーマットで提示されるかどうかを示す。ビットに「１」という値があるとき、ピクセルデータはインタレースフォーマットであり、行番号は、ある行から次の行に進むときに２で増分される。ビット３は、ピクセルデータが代替ピクセルフォーマットを取ることを示す。これはビット２でイネーブルされる標準インタレースモードに類似しているが、インタレースは水平の代わりに垂直である。ビット３が「０」であるとき、ピクセルデータは標準漸次フォーマットであり、列番号（ピクセルＸ座標）が、各連続ピクセルが受信されると１増分される。ビット３が「１」であるとき、ピクセルデータは代替ピクセルフォーマットを取り、列番号は書くピクセルが受信されると２増分される。

データは、無線電話又は類似した装置又はポータブルコンピュータ又は前述されたようなこのような他の装置用の内部ディスプレイに、又は内部ディスプレイから転送される、あるいはデータは装置に内蔵される、又は直接的に結合されるカメラに、又はカメラから転送されているので、ビット４は、ピクセルデータがディスプレイに関連するのか、あるいはカメラに関連するのかを示す。ビット４が「０」であるとき、ピクセルデータはディスプレイフレームバッファへ、又はディスプレイフレームバッファから転送されている。ビット４が「１」であるとき、ピクセルデータは何らかのタイプのカメラ又はビデオ装置へ、又はそれから転送されており、このような装置は技術で周知である。

ビット５は、ピクセルデータがいつディスプレイ内のピクセルの次の連続行を含むのかを示すために使用される。これは、ビット５が「１」に等しく設定されるケースと見なされる。ビット５が「１」に設定されるときには、Ｘ左端縁、Ｙ上部端縁、Ｘ右端縁、Ｙ下部端縁、Ｘ開始、Ｙ開始パラメータが定義されず、クライアントによって無視される。ビット１５が論理１レベルに設定されると、これは、このパケットの中のピクセルデータが画像の中のピクセルの最後の行であることを示す。クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット８は、この特徴がサポートされているかどうかを示す。

ビット７と６は、ピクセルデータが書き込まれなければならないフレームバッファを指定する表示更新ビットである。さらに具体的な効果は他の場所で説明される。「０１」というビット値の場合、ピクセルデータはオフライン画像バッファに書き込まれる。「００」というビット値の場合、ピクセルデータは、表示をリフレッシュするために使用される画像バッファに書き込まれる。「１１」というビット値の場合、ピクセルデータはすべての画像バッファに書き込まれる。「１０」というビット値又は組み合わせは無効値又は指定として処理され、ピクセルデータは無視され、画像バッファのどれにも書き込まれない。この値はインタフェースの将来の応用例のために使用される可能性がある。

ビット８から１１は、代替ディスプレイ、又はピクセルデータが経路付けられるディスプレイロケーションを指定するために使用される。ビット０と１は、ディスプレイクライアントが代替ディスプレイ数としてビット８から１１を解釈するために「００」に等しく設定される。ビット０と１が「００」に等しくない場合には、ビット８から１１は論理ゼロレベルに設定される。

ビット１３及び１２は、透明色及び透明マスクに関連しているので、宛先ピクセルが、宛先位置に書き込まれるか否かを指定するために使用される。ビット［１３：１２］が、００（２つとも論理ゼロレベル）の値を持つか、それに等しい場合、透明色は使用されない。結果として得られる宛先ピクセルは、透明色又は透明マスクの値を考慮することなく、宛先ピクセル位置に書き込まれる。透明色は、本明細書で説明している透明色イネーブルパケットによって定義される。０１（論理ゼロレベル、論理１レベル）の値であるビット[１３:１２]は、現在は将来の使用のために予約されており、使用されていない。ビット[１３:１２]が１０（論理１レベル、論理０レベル）の値を持つ場合、結果として得られる宛先ピクセルは、もしも透明マスクと論理的なＡＮＤを取られたソースイメージピクセルが、透明色に等しくないのであれば、宛先ピクセル位置に書き込まれ、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。ビット[１３：１２]が１１（２つとも論理１）の値を持つ場合、結果として得られる宛先ピクセルは、もしも透明マスクと論理的ＡＮＤを取られたソースイメージピクセルが透明色に等しくない場合には、宛先ピクセル位置に書き込まれない。この場合、結果として得られるピクセルは、宛先ピクセル位置に書き込まれる。

ビット１４は、将来の使用のために予約され、通常論理ゼロレベルに設定されている。ビット１５は、前述されたように、ビット５と共に使用される。ビット１５を論理１に設定すると、ピクセルデータフィールドの中のピクセル行がデータのフレームの最後の行であることが示される。ビット５が論理１に設定される次のビデオストリームパケットは、次のビデオフレームのピクセルの第１の行に相当する。

２バイトのＸ開始フィールドとＹ開始フィールドは、ピクセルデータフィールドの第１のピクセルの点（Ｘ開始、Ｙ開始）の絶対Ｘ座標と絶対Ｙ座標を指定する。Ｘ右端縁フィールドとＹ下部端縁フィールドは更新されているウィンドウの右端縁のＸ座標と下部端縁のＹ座表を指定するが、２バイトのＸ左端縁フィールドとＹ上部端縁フィールドは、ピクセルデータフィールドによって充填される画面ウィンドウの左端縁のＸ座標と上部端縁のＹ座標、上部端縁のＹ座標を指定する。

ピクセルカウントフィールド（２バイト）は、以下のピクセルデータフィールドの中のピクセル数を指定する。

パラメータＣＲＣフィールド（２バイト）は、パケット長からピクセルカウントまでのすべてのバイトのＣＲＣを含む。このＣＲＣがチェックできない場合、パケット全体が廃棄される。

ピクセルデータフィールドは、表示されなければならず、ビデオデータフォーマット記述子フィールドによって記述されるようにフォーマットされる未処理ビデオ情報を含む。データは他の箇所に説明されるように一度に一「行」送信される。ピクセルデータ属性フィールドのビット５が、論理レベル１に設定されたとき、このピクセルデータフィールドは、正確に一行のピクセルを含む。ここで、最初のピクセルは、最も左側のピクセルに従って送信され、最後のピクセルは、最も右側のピクセルに従って送信される。

ピクセルデータＣＲＣフィールド（２バイト）は、ピクセルデータだけの１６ビットＣＲＣをる含む。この値のＣＲＣ検証が失敗すると、ピクセルデータは依然として使用できるが、ＣＲＣエラーカウントが増分される。

Ｂ．音声ストリームパケットの場合
一実施形態では、音声チャネルＩＤフィールド（１バイト）が、音声データがクライアントデバイスによって送信される特定の音声チャネルを識別するために８ビットの符号なし整数値を使用する。物理音声チャネルは、それぞれ左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中央チャネル、サブウーファーチャネル、サラウンド左チャネル及びサラウンド右チャネルを示す、０、１、２、３、４、５、６又は７という値としてこのフィールドによって物理チャネルに指定される、あるいは物理チャネルにマッピングされる。２５４という音声チャネルＩＤ値は、デジタル音声サンプルの単一のストリームが左前チャネルと右前チャネルの両方に送信されることを示す。これにより、音声通信にステレオヘッドセットが使用される、生産性強化応用例がＰＤＡで使用される、あるいは単純なユーザインタフェースが警告音を生成する他の応用例のために使用される等の応用例のための通信を簡略化する。現在８から２５３の範囲及び２５５のＩＤフィールドのための値は、当業者によって予期されるように、新しい設計が追加の指定を所望する使用のために予約されている。

予約１フィールド（１バイト）は通常将来の使用のために予約されており、このフィールドのすべてのビットはゼロに設定される。このフィールドの１つの機能はすべての以後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールド２を３２ビットワードアドレスに位置合わせさせることである。

音声サンプルカウントフィールド（２バイト）は、このパケットの音声サンプル数を指定する。

サンプルあたりビット及びパッキングフィールドは音声データのパッキングフォーマットを指定する１バイトを含む。一実施形態では、通常利用されるフォーマットは、ビット４から０が、ＰＣＭ音声サンプルあたりのビット数を定義することである。次にビット５は、デジタル音声データサンプルがパックされているかどうかを指定する。前述されたように、図１２は、パッキングされたサンプルとバイト位置合わせされた音声サンプルの間の差異を示す。ビット５の「０」という値は、デジタル音声データフィールドの中の各ＰＣＭ音声サンプルがインタフェースバイト境界とバイト位置合わせされていることを示し、「１」という値は、各連続ＰＣＭ音声サンプルが過去の音声サンプルに対してパックされていることを示す。このビットは、ビット４から０（ＰＣＭ音声サンプルあたりのビット数）に定義される値が８の倍数ではないときにだけ有効である。ビット７から６は、システム設計が追加の指定を所望する用途に予約され、通常ゼロという値で設定される。

音声サンプルレートフィールド（１バイト）は、音声ＰＣＭサンプルレートを指定する。利用されるフォーマットは、それぞれ０という値が毎秒８，０００サンプル（ｓｐｓ）という速度を示し、１という値が１６，０００ｓｐｓ、２という値が２４，０００ｓｐｓ、３という値が３２，０００ｓｐｓ、４という値が４０，０００ｓｐｓ、５という値が４８，０００ｓｐｓ、６という値が１１，０２５ｓｐｓ、７という値が２２，０５０ｓｐｓ、及び８という値が４４，１００ｓｐｓを示し、９から２５５という値は将来の使用のために予約されており、それらは現在ゼロに設定されている。

パラメータＣＲＣフィールド（２バイト）は、パケット長から音声サンプルレートまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣが適切にチェックできないとき、パケット全体が廃棄される。デジタル音声データフィールドは再生される未処理音声サンプルを含み、通常、符号なし整数として線形フォーマットの形をとる。音声データＣＲＣフィールド（２バイト）は、音声データだけの１６ビットＣＲＣを含む。このＣＲＣがチェックできない場合、音声データは依然として使用できるが、ＣＲＣエラーカウントは増分される。

Ｃ．ユーザ定義ストリームパケット用
一実施形態では、２バイトのストリームＩＤ番号フィールドは、特定のユーザが定義したストリームを識別するために使用される。ストリームパラメータフィールドとストリームデータフィールドのコンテンツは、通常、ＭＤＤＩ装置製造メーカによって定義される。２バイトのストリームパラメータＣＲＣフィールドは、パケット長から始まり音声コーディングバイトまでのストリームパラメータのすべてのバイトの１６ビットのＣＲＣを含む。このＣＲＣがチェックできない場合、パケット全体が廃棄される。ＭＤＤＩの最終用途により必要とされない場合、つまりスそれらがオプションと考えられている場合、ストリームパラメータフィールドとストリームパラメータＣＲＣフィールドの両方とも廃棄されてよい。２バイトのストリームデータＣＲＣフィールドはストリームデータだけのＣＲＣを含む。このＣＲＣが適切にチェックできない場合には、ストリームデータの使用は、応用例の要件に応じてオプションとなる。ＣＲＣが良好であることを条件としたストリームデータの使用は、通常、ＣＲＣが良好であると確認されるまで、ストリームデータをバッファに入れることを必要とする。ＣＲＣエラーカウントは、ＣＲＣがチェックしない場合に増分される。

Ｄ．カラーマップパケットの場合
２バイトのｈＣｌｉｅｎｔＩＤフィールドは、過去に使用されたようにクライアントＩＤに予約される情報又は値を含む。このフィールドは通常将来の使用に予約されるので、現在の値はビットを「０」に設定することによってゼロに設定される。

２バイトのカラーマップアイテムカウントフィールドは、カラーマップデータフィールドに含まれる３バイトのカラーマップアイテム又はこのパケットの中のカラーマップデータに存在するカラーマップテーブルエントリの総数を指定するために値を使用する。この実施形態では、カラーマップデータのバイト数はカラーマップアイテムカウントの３倍である。カラーマップアイテムカウントは、カラーマップデータを送信しないためにゼロに等しく設定される。カラーマップサイズがゼロである場合には、カラーマップオフセット値は通常依然として送信されるが、それはディスプレイによって無視される。カラーマップオフセットフィールド（４バイト）は、クライアントデバイスのカラーマップテーブルの始まりからのこのパケット内のカラーマップデータのオフセットを指定する。

２バイトのパラメータＣＲＣフィールドは、パケット長から音声コーディングバイトまでのすべてのバイトのＣＲＣを含む。このＣＲＣがチェックできない場合、パケット全体が廃棄される。

カラーマップデータフィールドの場合、各カラーマップロケーションの幅はカラーマップアイテムサイズフィールドによって指定され、一実施形態では、第１の部分が青の規模を指定し、第２の部分が緑の規模を指定し、第３の部分が赤の規模を指定する。カラーマップサイズフィールドは、カラーマップデータフィールドに存在する３バイトのカラーマップテーブルアイテムの数を指定する。単一のカラーマップが１つのビデオデータフォーマットとカラーマップパケットの中に適合できない場合、カラーマップ全体が各パケット内に異なるカラーマップデータとカラーマップオフセットがある複数のパケットを送信することによって指定されてよい。各カラーマップデータアイテム内の青、緑及び赤のビット数は、表示機能パケットのカラーマップＲＧＢ幅フィールドに指定されるのと同じである。

２バイトのカラーマップデータＣＲＣフィールドは、カラーマップデータだけのＣＲＣを含む。このＣＲＣがチェックできない場合、カラーマップデータは依然として使用できるが、ＣＲＣエラーカウントは増分される。

各カラーマップデータアイテムは、以下の順序で送信されなければならない。つまり、青、緑、赤で、各成分の最下位ビットが最初に送信される。各カラーマップアイテムの個々の赤、緑及び青の成分はパックされ、各カラーマップアイテム（青の成分の最下位ビット）はバイト位置合わせされる必要がある。図９７は、６ビットの青、８ビットの緑、及び７ビットの赤のあるカラーマップデータアイテムの例を示す。この例の場合、カラーマップパケットのカラーマップアイテムサイズは２１に等しく、クライアント機能パケットのカラーマップＲＧＢ幅フィールドは０ｘ０７８６に等しい。

Ｅ．逆方向リンクカプセル化パケットの場合
パラメータＣＲＣフィールド（２バイト）は、パケット長から方向転換長までのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣがチェックできない場合、パケット全体が廃棄される。

一実施形態では、逆方向リンクフラグフィールド（１バイト）は、クライアントから情報を要求し、逆方向リンクタイプを指定するためにフラグのセットを含む。ビット（例えばビット０）が論理１レベルに設定される場合、ホストは、クライアントから指定された情報を要求するが、ビットが論理ゼロレベルに設定された場合、ホストはクライアントから情報を必要としない。ビット０（ゼロ）は、ホストがいつクライアント機能パケットを要求するかを示すために使用される。これは一般には、クライアントによって、逆方向データパケットフィールド内のホストへ送られる。ビット１は、ホストが、クライアント要求とステータスパケットとをいつ要求したかを示すために使用される。これは、クライアントによって、逆方向データパケットフィールド内のホストに送られる。残りのビット（ここではビット１から７）は将来の使用のために予約され、ゼロに設定されている。しかしながら、逆方向リンクのためにフラグを設定するために所望されるようにさらに多くのビットを使用できる。

逆方向レート除数フィールド（１バイト）は、逆方向リンクデータクロックに関連して発生するＭＤＤＩ＿Ｓｔｂサイクルの数を指定する。逆方向リンクデータクロックは、逆方向レート除数の２倍で除算される順方向リンクデータクロックに等しい。逆方向リンクデータレートは、逆方向リンクデータクロック関連し、逆方向リンクでのインタフェースタイプである。本実施形態では、１型インタフェースの場合、逆方向データレートは逆方向リンクデータクロックに等しく、２型、３型及び４型インタフェースの場合、逆方向データレートはそれぞれ逆方向リンクデータクロックの２倍、４倍及び８倍に等しい。

全ゼロフィールドは、論理ゼロレベルでビットを設定することによって値の中のゼロに等しく設定されるバイトのグループ、ここでは８を含み、すべてのＭＤＤＩ＿Ｄａｔａ信号が、クライアントが、方向転換１フィールドの間にホストのラインドライバをディスエーブルする前にＭＤＤＩ＝Ｓｔｂだけを使用してクロックの回復を開始できるほど十分な時間論理ゼロレベルにあることを保証するために使用される。一実施形態では、全ゼロ１フィールドの長さはケーブルの往復遅延における順方向リンクバイト伝送回数以上である。

方向転換１長フィールド（１バイト）は、方向転換１に割り当てられるバイト総数を指定し、第１の方向転換期間を確立する。方向転換１長パラメータは、ホスト内のラインドライバがディスエーブルされる前に、クライアント内のＭＤＤＩ＿Ｄａｔａラインドライバがイネーブルできるようにするために割り当てられた方向転換１長パラメータにより指定されるバイト数を適用する。クライアントは、方向転換１のビット０の間にそのＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルし、ホストは方向転換１の最後のビットの前に完全にディスーブルされるようにその出力をディスエーブルする。ＭＤＤＩ＿Ｓｔｂ信号は、あたかもＭＤＤＩ＿Ｄａｔａ０が方向転換１期間全体で論理ゼロレベルにあるかのように動作する。方向転換１の設定のさらに完全な説明は前記に示されている。

逆方向データパケットフィールドはクライアントからホストへ転送される一連のデータパケットを含む。クライアントは、ホストに送信するデータがないときには、フィラーパケットを送信してよい、あるいはＭＤＤＩ＿Ｄａｔａ線路を論理ゼロ状態又はレベルに駆動してよい。本実施形態では、ＭＤＤＩ＿Ｄａｔａ線路がゼロに駆動されると、ホストはこれをゼロ長（有効長ではない）のパケットとして解釈し、ホストは現在の逆方向リンクカプセル化パケットの持続期間中クライアントから追加のパケットを受け入れない。

方向転換２長フィールド（１バイト）は、第２の方向転換期間を確立するために方向転換２に割り当てられるバイトの総数を指定する。推奨される方向転換２の長さは、ホストがＭＤＤＩ＿Ｄａｔａドライバをイネーブルするために必要な時間に、往復遅延のための必要なバイト数を加えたものである。方向転換２の長さは、ホスト内の逆方向リンクパケットを処理するための十分な時間を可能にするように計算された値、又は必要な最小値よりも大きな値にもなりうる。

方向転換２フィールドは、方向転換長パラメータによって指定されたようなバイト数からなる。ホストは、方向転換２の間にＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルする前に、少なくとも往復遅延時間待つ。ホストは一般に、ＭＤＤＩ＿Ｄａｔａラインドライバを、方向転換２の最後のビットの前に完全にイネーブルされるようにイネーブルする。クライアントは一般に、その出力を、方向転換２の最後のビットの前に完全にディセーブルされるようにディセーブルする。方向転換２フィールドの目的は、逆方向データパケットフィールドからの残りのデータ量が、クライアントから送信又は転送されるようにすることである。割り当てられた安全マージンの量とインタフェースとを実施している異なるシステムにおける変化時には、ホスト内又はホストにおけるライン受信機でも説明したように、ホスト及びクライアントの何れも、方向転換２フィールド期間のある部分の間、ＭＤＤＩ＿Ｄａｔａ信号を論理ゼロレベルに駆動しないことが可能であろう。ＭＤＤＩ＿Ｓｔｂ信号は、方向転換２期間全体で実質的に、ＭＤＤＩ＿Ｄａｔａ０が論理ゼロレベルであるかのように動作する。方向転換２の設定の説明は前述されている。

逆データパケットフィールドは、クライアントからホストに転送される一連のデータパケットを含む。前述されたように、フィラーパケットは他のパケットタイプによって使用されていない残りの空間を充填するために送信される。

全ゼロ２フィールドは、論理ゼロレベルでビットを設定することによって値のゼロに等しく設定されるバイトのグループ（この実施形態では８）を含み、すべてのＭＤＤＩ＿Ｄａｔａ信号が、方向転換２フィールドの後にホストのラインドライバをイネーブルしてから、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩＳｔｂの両方を使用してクロックを回復できるほど十分な時間、論理ゼロレベルとなることを保証するために使用される。

Ｆ．クライアント機能パケット用
一実施形態のために説明されているように、プロトコルバージョンフィールドは、クライアントによって使用されるプロトコルバージョンを指定する。最小プロトコルバージョンフィールドが、クライアントが利用する又は解釈する最小プロトコルバージョンを指定するために２バイトを使用するが、現在、初期のバージョンは１に等しく設定され、知られているように、新たなバージョンが生成されると、時間によって変化する。この場合、ゼロ値もまた有効な値である。校正前データレート機能フィールド（２バイト）は、順方向リンク歪み構成を実行する前に、クライアントが順方向リンク上の各データペアで受信できる最大データレートを指定し、毎秒メガバイト（Ｍｂｐｓ）の形式で指定される。クライアントが、順方向リンク歪み校正パケットをサポートする場合、校正後データレート機能フィールドは、クライアントが、事後歪み校正を実行することができるデータレートを示す。

１つの実施形態では、インタフェースタイプ機能フィールド（１バイト）は、順方向リンクと逆方向リンクでサポートされているインタフェースタイプを指定する。‘１’に設定されたビットは、指定されたインタフェースタイプがサポートされていることを示し、‘０’に設定されたビットは、指定されたタイプがサポートされていないことを示す。ホスト及びクライアントは、順方向ライン及び逆方向ライン上で少なくとも１型をサポートすべきである。インタフェースタイプの隣接領域をサポートする必要はない。例えば、インタフェースにおいて１型と３型のみをサポートすることは完全に有効であるが、３型と４型とをサポートすることは有効ではないであろう。また、順方向リンクと逆方向リンクとが同じインタフェースタイプを用いて動作する必要もない。しかしながら、リンクがハイバーネーションから出た場合、ホストとクライアントとの両方による使用のために別のモードがネゴシエートされ、選択され、あるいは承認されるまで、順方向リンクと逆方向リンクとの両方が、１型モードで動作を開始すべきである。

サポートされているインタフェースは、一つの実施形態では、順方向リンクでそれぞれ２型（２ビット）、３型（４ビット）又は４型（８ビット）モードのうちのどれかを選択するためにビット０、ビット１、又はビット２を選択し、逆方向リンクでそれぞれ２型、３型又は４型モードのうちのどれかを選択するためにビット３、ビット４又はビット５を選択することによって現在示されており、ビット６と７は予約され、この時点ではゼロに設定されている。

１つの実施形態では、クライアント機能パケットの代替ディスプレイ数フィールドは、１バイトを使用する。この値は、０から１６の範囲にあり、１７から２５５の値は、将来の使用のために予約されており、現在使用されていない。これによって、１より多いディスプレイが結合され、代替ディスプレイ機能パケットが各代替ディスプレイの機能を報告することを示すか、報告する。代替ディスプレイ数フィールドは、１バイトを使用し、一般に数０に指定されている第１の代替ディスプレイと、（０値から開始された後）使用される最大値が代替ディスプレイの合計数から１を引いた数であるユニークな代替ディスプレイ数値で識別されるその他の代替ディスプレイとを用いて代替ディスプレイの識別表示を示す。

校正後データレート機能フィールドは、１つの実施形態では、２バイトを使用して、クライアントが、順方向リンク歪み校正を実行した後、順方向ＭＤＤＩリンクにおいて各データペア上で受信することができる最大のデータレートを指定する。このレートはまた、毎秒メガバイトの数として指定される。クライアントデバイスが順方向リンク歪み校正パケットをサポートしない場合、このフィールドは、ゼロ値に等しく設定される。

ビットマップ幅フィールド及びビットマップ高さフィールドは、ここではそれぞれ２バイトであり、ビットマップの幅及び高さをそれぞれピクセルで指定する。ディスプレイウィンドウ幅フィールドは、２バイトを使用し、ピクセル数として表されるディスプレイウィンドウの幅を指定する。ディスプレイウィンドウ高さフィールドは、２バイトを使用し、ピクセル数として表されるディスプレイウィンドウの高さを指定する。

カラーマップサイズフィールドは、４バイトを使用し、クライアント内のカラーマップテーブルに存在するテーブル項目の最大数を指定する。クライアントが、カラーマップフォーマットを使用することができないのであれば、この値は、ゼロに等しく設定される。

カラーマップＲＧＢ幅フィールドは、２バイトを使用し、カラーマップ（パレット）ディスプレイモードで表示される赤、緑、及び青からなる各色成分のビット数を指定する。各色成分（赤、緑、及び青）のために最大８ビットを使用することができる。たとえ各色成分について８ビットがカラーマップパケットに送られたとしても、このフィールドで定義される各色成分の最小桁ビットのみが使用される。ディスプレイクライアントが、このカラーマップ（パレット）フォーマットを使用することができないのであれば、この値はゼロとなる。

ＲＧＢ機能フィールド（２バイト）は、ＲＧＢフォーマットで表示できる解像度のビット数を指定する。ディスプレイがＲＧＢフォーマットを使用できない場合、この値はゼロである。ＲＧＢ機能ワードは３つの別々の無符号値から構成される。すなわち、ビット３から０は、各ピクセルの青の最大ビット数を定義する。ビット７から４は、各ピクセルの緑の最大ビット数を定義し、ビット１１乃至８は、各ピクセルの赤の最大ビット数を定義する。現在、ビット１４乃至１２は、将来の使用のために予約され、一般にゼロに設定される。ビット１５は、論理１レベルに設定されている場合、パックフォーマットあるいはアンパックフォーマットの何れかで、ＲＧＢピクセルデータを受け付けることができることを示す。ビット１５が論理ゼロレベルに設定されていれば、これは、クライアントが、アンパックフォーマットのみのＲＧＢピクセルデータを受け付けることができることを示す。

白黒機能フィールド（１バイト）は、一つの実施形態では、白黒フォーマットで表示できる解像度のビット数を指定するために使用される。ディスプレイが白黒フォーマットを使用できない場合は、この値はゼロで設定される。ビット７から４は将来の使用のために予約され、したがってゼロとして設定される。ビット３から０は、ピクセルごとに存在できるグレイスケールの最大ビット数を定義する。これらの４ビットにより、ピクセルごとに１から１５の値を指定できるようになる。値がゼロである場合には、白黒フォーマットはディスプレイによってサポートされていない。

Ｙ Ｃｒ Ｃｂ機能フィールド（２バイト）は、Ｙ Ｃｒ Ｃｂフォーマットで表示できる解像度のビット数を指定する。ディスプレイがＹ Ｃｒ Ｃｂフォーマットを使用できない場合、この値はゼロに等しく設定される。Ｙ Ｃｒ Ｃｂ機能ワードは３つの別々の無符号値から構成され、ビット３から０は、Ｃｂサンプルの最大ビット数を定義し、ビット７から４はＣｒサンプルの最大ビット数を定義し、ビット１１から８はＹサンプルの最大ビット数を定義し、ビット１５から１２は将来の使用のために予約され、ゼロに設定されている。

Ｂａｙｅｒ機能フィールドは、解像度、ピクセルグループ、及びＢａｙｅｒフォーマットで転送できるピクセル順序のビット数を指定するために１バイトを使用する。クライアントがＢａｙｅｒフォーマットを使用できない場合、この値はゼロである。Ｂａｙｅｒ機能フィールドは、以下の値から構成される。ビット５から４は必要とされるピクセルグループパターンを定義するが、ビット３から０は、各ピクセルに存在する輝度の最大ビット数を定義し、ビット８から６は必要とされるピクセル順序を定義し、ビット１４から１９は将来の使用ために予約されており、通常、当面ゼロに設定されている。ビット１５は、論理１レベルに設定されるとき、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでＢａｙｅｒピクセルデータを受け入れることができることを示す。ビット１５がゼロに設定されると、これはクライアントがアンパックフォーマットでのみＢａｙｅｒピクセルデータを受け入れることができることを示す。

１つの実施形態では、クライアント特徴機能フィールドは、サポートされているクライアントでの特定の特徴を示すフラグのセットを含む４バイトを使用する。論理１レベルに設定されるビットは、機能がサポートされていることを示し、論理ゼロレベルに設定されるビットは、機能がサポートされていないことを示す。この実施形態では、ビット０の値は、ビットマップブロック転送パケット（パケットタイプ７１）がサポートされているか否かを示す。ビット１、２、及び３の値は、ビットマップ領域塗りつぶしパケット（パケットタイプ７２）、ビットマップパターン塗りつぶしパケット（パケットタイプ７３）、又は通信リンクデータチャネルパケット（パケットタイプ７４）がそれぞれサポートされているかどうかを示す。ビット４の値は、透明色イネーブルパケットを用いて、クライアントに１つの色を透明にする機能があるかどうかを示す。ビット５と６の値は、クライアントがそれぞれパックフォーマットでビデオデータ又は音声データを受け入れることができるかどうかを示し、ビット７の値は、クライアントがカメラから逆方向リンクビデオストリームを送信できるかどうかを示している。ビット８の値は、クライアントがピクセルデータの完全行を受信し、ビデオストリームパケットのピクセルデータ属性のビット５によって指定されるディスプレイアドレス指定を無視する能力を有するかどうかを示し、クライアントはピクセルデータ属性フィールドのビット１５を用いてビデオフレームデータのフレーム同期又は最後も検出できる。

ビット９の値は、クライアントが、要求特有ステータスパケットを解釈し、有効ステータス応答リストパケットに応答する能力を持っているか否かを示す。クライアントは、上述したように、有効ステータス応答リストパケットの有効パラメータ応答リストフィールド内の追加ステータスを戻す能力を持っていることを示すことができる。ビット１０の値は、クライアントが、ディスプレイ電力状態０１をサポートする能力を持っているか否かを示す。ディスプレイ電力状態は、上述したディスプレイ電力ステータスパケットの電力状態フィールドのビット［３：２］を用いて設定される。ディスプレイ電力状態０１は、もしあれば、選択されたデイスプレイが照明されず、最低量の電力を消費している状態であり、この状態の間、フレームバッファの内容は、一般的に、保持されることが保証される。

ビット１１と１２の値は、いつクライアントがポインティングデバイスと通信中で、ポインティングデバイスデータパケットを送信、受信できるのか、あるいはキーボードを用いてそれぞれキーボードデータパケットを送信、受信できるのかを示す。ビット１３の値は、ＶＣＰ特徴パケットをサポートすることにより、クライアントが音声又はビデオパラメータの１つ又は複数を設定する能力を有するかどうかを示す。つまりＶＣＰ特徴要求パケット、ＶＣＰ特徴応答パケット、ＶＣＰ設定特徴パケット、有効パラメータ要求パケット、及び有効パラメータ応答パケットである。ビット１４の値は、クライアントがピクセルデータをオフラインのディスプレイフレームバッファに書き込む能力を有するかどうかを示す。これは図８８Ａに示されている。このビットが論理１レベルに設定されると、表示更新ビット（ビデオストリームパケットのピクセルデータ属性のビット７と６）は値「０１」に設定されてよい。

ビット１５の値は、クライアントが、ディスプレイイメージをリフレッシュするために現在使用されているディスプレイフレームバッファのみにピクセルデータを書き込む能力を持っている場合を示す。これは、図８８Ｂに示されている。もしもこのビットが、１に設定されていれば、表示更新ビット（ビデオストリームパケットのピクセルデータ属性の第６及び第７ビット）が値「００」に設定されるかもしれない。ビット１６の値は、クライアントが、単一のビデオストリームパケットからのピクセルデータを全てのディスプレイフレームバッファに書き込む能力を持っている場合を示す。これは、図８８Ｃに示されている。このビットが、論理１レベルに等しく設定されていれば、表示更新ビット（ビデオストリームパケットのピクセルデータ属性の第６及び第７ビット）が値「１１」に設定されるかもしれない。

一つの実施形態では、ビット１７の値は、クライアントが、要求特有ステータスパケットに対し応答する能力を持っている場合を示し、ビット１８の値は、クライアントが、往復遅延測定パケットに対し応答する能力を持っている場合を示し、ビット１９の値は、クライアントが、順方向リンク歪み校正パケットに対する能力を持っている場合に示す。一つの実施形態では、ビット２０の値は、クライアントが、表示電力ステータスパケットに応答する能力を持っている場合を示す。

一つの実施形態では、ブロック転送パケット（パケットタイプ７１）、ビットマップ領域塗りつぶしパケット（パケットタイプ７２）、及びビットマップパターン塗りつぶしパケット（パケットタイプ７３）が、ビット０，１，２又はラスタ動作フィールドによって特定されたクライアントによってサポートされている場合、ビット２１の値は、このクライアントが、ブロック転送パケット（パケットタイプ７１）、ビットマップ領域塗りつぶしパケット（パケットタイプ７２）、及びビットマップパターン塗りつぶしパケット（パケットタイプ７３）のラスタ動作フィールドを使用することができる時を示す。一つの実施形態では、ビット２１が論理ゼロレベル又は論理ゼロ値を持ち、パケットがサポートされていれば、クライアントは、ラスタ動作フィールドを使用する能力を持たず、クライアントは、これらパケットによって特定されたピクセル位置にコピー又は書き込みを行う能力のみを持つ。

ビット２２の値は、クライアントがレジスタアクセスパケットに応答する能力を有するかどうかを示す。ビット９から１０、２０及び２３から３１は、現在、システム設計者に有効な将来の使用又は代替指定のために予約され、通常はゼロに等しく設定される。

表示ビデオフレーム機能フィールド（１バイト）は、毎秒フレーム単位でディスプレイの最大ビデオフレーム更新機能を指定する。ホストは、このフィールドで指定される値より低速で画像の更新を選んでよい。

音声バッファ深度フィールド（２バイト）は、各音声ストリーム専用であるディスプレイ内の弾性バッファの深度を指定する。

音声チャネル機能フィールドは、この実施形態の場合、２バイトを使用し、どの音声チャネルがクライアント、又はクライアントに接続されたデバイスによってサポートされるのかを示すフラグのグループを含む。１に設定されるビットは、チャネルがサポートされていることを示し、ゼロに設定されているビットは、そのチャネルがサポートされていないことを示す。ビット位置は様々なチャネルに割り当てられる。例えば一つの実施形態では、ビット位置０、１、２、３、４、５、６、及び７は、左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中心チャネル、サブウーファーチャネル、サラウンド左チャネルとサラウンド右チャネルを示している。ビット８から１４は、将来の使用のために現在予約されており、通常ゼロに設定されている。一つの実施形態では、ビット１５は、クライアントが、順方向音声チャネルイネーブルパケットをサポートしているかを示すために使用される。サポートしている場合、ビット１５は、論理１レベルに設定される。しかしながら、クライアントが、順方向音声チャネルイネーブルパケットの結果として音声チャネルをディスエーブルすることができないか、クライアントが音声機能をサポートしていないのであれば、このビットは、論理ゼロレベル又は値に設定される。

順方向リンク用の２バイトの音声サンプルレート機能フィールドは、クライアントデバイスの音声サンプルレート機能を示すためにフラグのセットを含む。ビット位置は、さまざまな速度に相応して割り当てられ、例えばビット０、１、２、３、４、５、６、７及び８は、それぞれ８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０及び４４，１００毎秒サンプル（ＳＰＳ）であり、ビット９から１５は将来の又は代替レートの使用のために予約されているので、それらは現在「０」に設定されている。これらのビットの内の１つの値を「１」に設定すると、その特定のサンプルレートがサポートされていることを示し、ビットを「０」に設定すると、そのサンプルレートはサポートされていないことを示す。

２バイトの音声サンプル解像度フィールドは、順方向リンクの場合、音声ストリームパケットでクライアントへ送られる音声サンプル毎のビット数を指定する。

２バイトのマイク音声サンプル解像度フィールドは、逆方向リンクの場合、音声ストリームパケットでマイクによってホストへ送られる音声サンプル毎のビット数を指定する。

２バイトのマイクサンプルレート機能フィールドは、逆方向リンクの場合、クライアントデバイス内のマイクの音声サンプルレート機能を示すフラグのセットを含む。ＭＤＤＩのために、クライアントデバイスマイクは少なくとも毎秒８，０００サンプルレートを最小でサポートするように構成される。このフィールドのビット位置は、例えばそれぞれ８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、及び４４，１００毎秒サンプル（ＳＰＳ）を表すために使用されているビット位置０、１、２、３、４、５、６、７及び８の様々な速度に割り当てられ、ビット９から１５は、所望されるように将来又は代替レートの使用のために予約されているため、現在は「０」に設定されている。これらのビットの１つのビット値を「１」に設定すると、その特定のサンプルレートがサポートされていることを示し、ビットを「０」に設定すると、そのサンプルレートがサポートされていないことを示している。マイクが接続されていない場合、マイクサンプルレート機能ビットのそれぞれはゼロに等しく設定される。

キーボードデータフォーマットフィールド（ここでは１バイト）は、キーボードがクライアントシステムに接続されているか否かと、接続されているキーボードのタイプを特定する。一つの実施形態では、ビット６から０によって設定された値は、接続されているキーボードのタイプを定義するために使用される。もしもこの値がゼロ（０）であれば、キーボードタイプは未知であると考えられる。１の値の場合、キーボードデータフォーマットは、標準的なＰＳ−２スタイルであると考えられる。今のところ、２から１２５の範囲の値は、使用されておらず、システム設計者、インタフェース組込者、又は製品開発者が、ＭＤＤインタフェース及び対応するクライアント又はホストとの使用のために特定のキーボード又は入力デバイスを定義するために予約されている。キーボードデータフォーマットがユーザ定義されたことを示すために値１２６が使用される。一方、キーボードがクライアントに接続できないことを示すために値１２７が使用される。更に、ビット７は、キーボードがクライアントと通信できるか否かを示すために使用される。このビットの意図的な使用は、キーボードが無線リンクを使ってクライアントと通信できる時を示すためである。ビット７は、キーボードをクライアントに接続できないことをビット６から０が示すのであればゼロレベルに設定される。従って、一つの実施形態では、ビット７の値が０であれば、キーボードとクライアントは通信することができず、ビット７の値が１であれば、キーボードとクライアントとは、互いに通信できることを認める。

ポインティングデバイスデータフォーマットフィールド（ここでは１バイト）は、ポインティングデバイスがクライアントシステムに接続されているか否かと、接続されているポイントティングデバイスのタイプとを特定する。一つの実施形態では、ビット６から０によって設定されている値は、接続されているポインティングデバイスのタイプを定義するために使用される。もしも値がゼロ（０）であれば、このポインティングデバイスは、未知であると考えられる。値が１の場合、このポインティングデバイスデータフォーマットは、標準的なＰＳ−２スタイルであると考えられる。今のところ、２から１２５の範囲の値は、使用されておらず、システム設計者、インタフェース組込者、又は製品開発者が、ＭＤＤＩ及び対応するクライアント又はホストとの使用のために特定のポインティングデバイス又は入力デバイスを定義するために予約されている。ポインティングデバイスデータフォーマットがユーザ定義されたことを示すために値１２６が使用される。一方、ポインティングデバイスがクライアントに接続できないことを示すために値１２７が使用される。更に、ビット７は、ポインティングデバイスがクライアントと通信できるか否かを示すために使用される。このビットの意図的な使用は、キーボードが無線リンクを使ってクライアントと通信できる時を示すためである。ビット７は、ポインティングデバイスをクライアントに接続することができないことをビット６から０が示すのであればゼロレベルに設定される。従って、一つの実施形態では、ビット７の値が０であれば、ポインティングデバイスとクライアントは通信することができず、ビット７の値が１であれば、ポインティングデバイスとクライアントとは、互いに通信できることを認める。

コンテンツ保護タイプフィールド（２バイト）は、ディスプレイによってサポートされるデジタルコンテンツ保護のタイプを示すフラグのセットを含む。現在、ビット位置０は、いつＤＴＣＰがサポートされているのかを示すために使用され、ビット位置１はいつＨＤＣＰがサポートされているのかを示すために使用され、ビット位置２から１５は所望されるように、又は使用可能なように他の保護方式での使用のために予約されているため、それらは現在ゼロに設定されている。

Ｍｆｒネームフィールド（ここでは２バイト）は、製造者のＥＩＳＡ ３キャラクタＩＤを含み、ＶＥＳＡ ＥＤＩＤ仕様と同じ手法で３つの５ビットキャラクタにパックされる。キャラクタ‘Ａ’は、００００１バイナリとして表され、キャラクタ‘Ｚ’は、１１０１０バイナリとして表される。そして、‘Ａ’と‘Ｚ’の間の全ての文字は、‘Ａ’と‘Ｚ’の間のアルファベットシーケンスに対応したシーケンシャルなバイナリ値として表される。Ｍｆｒネームフィールドの最上位ビットは、将来の実装において使用されるまで使用されず、今のところ一般に論理ゼロに設定される。例：文字列“ＸＹＺ”によって表される製造者は、０ｘ６６３ａのＭｆｒネーム値を持つ。もしもこのフィールドがクライアントによってサポートされていないのであれば、一般にゼロに設定される。プロダクトコードフィールドは、２バイトを使い、ディスプレイ製造者によって割り当てられたプロダクトコードを含む。もしもこのフィールドがクライアントによってサポートされていないのであれば、一般にゼロに設定される。

予約１フィールド、予約２フィールド、及び予約３フィールド（ここでは、それぞれ２バイト）は、関連する情報における将来の使用のために予約されている。このフィールド内の全てのビットは、一般に論理ゼロレベルに設定される。このようなフィールドの目的は、続く全ての２バイトフィールドを、１６ビットワードアドレスに並べさせ、４バイトフィールドを、３２ビットワードアドレスに並べさせることである。

ファイルされたシリアル番号は、この実施形態では、数値形式によるディスプレイのシリアル番号を特定するために４バイトを用いる。このフィールドがクライアントによってサポートされていないのであれば、一般にゼロに設定される。製造フィールドの週は、ディスプレイの製造週を定義するために１バイトを用いる。この値は、クライアントによってサポートされているのであれば、典型的には、１から５３の範囲にある。このフィールドがクライアントによってサポートされていなければ、ゼロに設定される。製造フィールドの年は、ディスプレイの製造年を定義する１バイトである。この値は、１９９０年からのオフセットである。このフィールドによって、１９９１年から２２４５年の範囲が表現可能である。例：２００３年は、１３の値を持つ製造年に対応する。このフィールドがクライアントによってサポートされていないのであれば、ゼロに設定される。

ＣＲＣフィールド（ここでは２バイト）は、パケット長を含むパケット内の全バイトからなる１６ビットＣＲＣを含む。

Ｇ．クライアント要求及びステータスパケット
逆方向リンク要求フィールド（３バイト）は、クライアントが、ホストに情報を送信するために次のサブフレームの逆方向リンクで必要とするバイト数を指定する。

ＣＲＣエラーカウントフィールド（１バイト）は、メディアフレームの開始以来どのくらいの数のＣＲＣエラーが発生したのかを示す。ＣＲＣカウントは、ゼロというサブフレームカウントがついたブフレームヘッダパケットが送信されるとリセットされる。ＣＲＣエラーの実際の数が２５５を超えると、この値は通常２５５で飽和する。

機能変更フィールドは、クライアントの機能の変化を示すために１バイトを使用する。これは、ユーザが、マイク、キーボード、又はディスプレイ、あるいは何らかの他の理由から周辺装置を接続する場合に発生するであろう。ビット「７：０」が０に等しいときには、機能は最後のクライアント機能パケットが送信されて以来変化しなかった。しかしながら、ビット［７：０］が１から２５５に等しいとき、機能は変更した。クライアント機能パケットは、新しい表示特性を決定するために調べられる。

クライアントビジーフラグフィールドは、クライアントが特定の機能を実行しており、その機能に関する別のパケットを受け付ける準備ができていないことを示すために２バイトを使用する。論理１レベル又は論理１値に設定されたビットは、クライアントによって特定の機能が現在実行されており、クライアント内の関連する機能がビジーであることを示す。もしもクライアント内の関連する機能の準備ができていれば、ビットは、論理ゼロに設定される。クライアントは、クライアント内でサポートされていない全ての機能のために、ビジーステータス（１に設定されたビット）を返すべきである。

一つの実施形態では、これらのバイトは、次の関係に従って解釈される。すなわち、もしもビット０が‘１’であれば、ビットマップブロック転送機能がビジーとなる。一方、ビット１が‘１’であれば、ビットマップ領域塗りつぶし機能がビジーとなる。もしもビット２が‘１’であれば、ビットマップパターン塗りつぶし機能がビジーとなる。同時に、ビット３が‘１’であれば、グラフィックサブシステムはビジーであり、クライアント内のフレームバッファの利用を必要とする動作を実行する。フレームバッファの利用を必要とするその他のグラフィック機能は、ビットが論理１値に設定されるまで始まらない。

今のところ、ビット４から１５は、将来の使用のために予約され、これらのビットが将来割り当てられた場合に、ビジーステータスを示すために、一般に、論理１レベル又は状態に設定される。

Ｈ．ビットブロック転送パケットの場合
ウィンドウ左上座標Ｘ値フィールドとＹ値フィールドは、移動するウィンドウの左上角の座標のＸ値とＹ値を指定するために、それぞれ２バイトを使用する。ウィンドウ幅フィールドとウィンドウ高さフィールドは、移動するウィンドウの幅と高さを指定するためにそれぞれ２バイトを使用する。ウィンドウＸ移動フィールドとＹ移動フィールドは、ウィンドウがそれぞれ水平と垂直に移動されるピクセル数を指定するために、それぞれ２バイトを使用する。Ｙの正の値はウィンドウを下方に移動させ、負の値は上方に移動させるが、通常、これらの座標は、Ｘの正の値によりウィンドウが右に移動し、負の値により左に移動するように構成されている。

Ｉ．ビットマップ領域塗りつぶしパケット
１つの実施形態では、２バイトのピクセルデータ属性フィールドが、ピクセルデータがどこで更新されるかを特定する値を有している。ここで、ビット１及びビット０は、ピクセルデータが更新されるかディスプレイを選択する。クライアントにおける主ディスプレイが、ステレオイメージをサポートしないのであれば、クライアントは、ビット組み合わせ０１，１０，又は１１のうちの１つで主ディスプレイ内におけるピクセルデータに影響を与えることができる。値１１は、ステレオディスプレイ機能をサポートしないクライアントにおける主ディスプレイに対処するために使用されることが推奨される。ビット[１:０]が値１１（論理１、論理１）を持つ場合、ピクセルデータは、左目と右目の両方のフレームバッファ内で更新され、ビット[１:０]が値１０（論理１、論理０）を持つのであれば、ピクセルデータは、左目のみのフレームバッファ内で更新される。ビット[１:０]が値０１（論理０、論理１）を持つ場合、ピクセルデータは、右目のみのフレームバッファ内で更新される。ビット[１:０]が値００（２つとも論理０）の場合、ピクセルデータは、ビット８乃至１１で指定される代替ディスプレイのフレームバッファ内で更新される。

１つの実施形態では、ピクセルデータ属性フィールドのビット４は、動作のイメージのソースが、左目のバッファであるか、又は右目のバッファであるかを特定する。ビット４は、ビット[１:０]が００に等しくない場合に当てはまる。これは、一般に、イメージの宛先が代替ディスプレイのうちの１つである場合、メインイメージバッファからのソースデータをサポートしないことを意味するために実施される。ビット４は、左目フレームバッファと右目フレームバッファとの間をデータソースとして区別又は特定するために使用される。ビット４の用途はまた、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット２１、又は代替ディスプレイ機能パケットのディスプレイ特徴機能インジケータフィールドのビット２１によって示されるように特定されたディスプレイ上でクライアントがラスタ動作をサポートする場合に限定される。適用された場合、ビット４が０（論理０レベル）に等しいのであれば、左目フレームバッファがデータソースであり、ビット４が１（論理１レベル）に等しいのであれば、右目フレームバッファがデータソースである。

ピクセルデータ属性のビット５は、ラスタ動作のための宛先イメージとして、ラスタ動作のための入力となるのが、ディスプレイをリフレッシュするために使用されるバッファであるのか、又はオフラインイメージバッファであるかを特定する。ビット５はまた、代替ディスプレイがオフラインイメージバッファを利用するのであれば、代替ディスプレイに当てはまる。しかしながら、イメージの宛先が代替ディスプレイである場合、メインのイメージバッファからのソースデータをサポートしない。あるいは、その逆も可能である。適用された場合、ビット５が値０又は論理ゼロレベルに等しいのであれば、ディスプレイをリフレッシュするために使用されるイメージバッファがデータソースである。ビット５が値１又は論理１レベルに等しい場合、オフラインイメージバッファがデータソースである。

ピクセルデータ属性フィールドのビット７及びビット６は、ピクセルデータが更新又は書き込まれるフレームバッファを指定するディスプレイ更新ビットとして作用する。フレーム更新ビットの効果は、既に詳述されている。ビット[７：６]が‘０１’（論理ゼロ、論理１）である場合、ピクセルデータは、オフラインイメージバッファに書き込まれる。ビット[７:６]が‘００’（２つとも論理ゼロ）である場合、ディスプレイをリフレッシュするために使用されるイメージバッファにピクセルデータが書き込まれる。ビット[７：６]が‘１１’（２つとも論理１）である場合、ピクセルデータは、全てのイメージバッファに書き込まれる。ビット[７：６]が‘１０’である場合、無効な値として取り扱われる。これらのビットは将来の使用のために予約されている。この状況では、コマンド全体が無視され、フレームバッファは更新されない。

ピクセルデータ属性フィールドのビット１１乃至８は、ピクセルデータが更新される代替クライアント位置又は代替ディスプレイ位置を特定する。クライアントが、ビット１１乃至８を代替ディスプレイ数として解釈するために、ビット０及びビット１は値００（２つとも論理ゼロ）に等しく設定される。ビット１及びビット０が００に等しくないのであれば、ビット８乃至１１は一般に、論理ゼロ値又はレベルに等しく設定される。ビット２,３,１２乃至１５は、将来の使用のために予約され、一般に、論理ゼロレベル又は値に設定される。

１つの実施形態では、２バイトのラスタ動作フィールドは、宛先イメージ位置に書き込まれる新たなピクセル値を生成するために、ソース位置及び宛先位置における各ピクセルをどのように組み合わせるかを指定する。ラスタ動作は、フレームバッファ内の等しいサイズの２つの異なる長方形領域がどのように合成されるのかを定義する。宛先イメージ領域もまた、合成される２つのイメージのうちの１つである。２つのイメージのうちの第２のイメージはソースイメージと呼ばれる。クライアントが、ラスタ動作フィールドを、クライアント機能パケット内で指定されたものとしてサポートしない場合、ホストは一般に、このパケットを、３に等しいビット３乃至０とともに送り、クライアントは、ビット３から０を無視する。

１つの実施形態では、ビット３から０は、それらを以下に示す表ＸＶＩに示す値のうちの１つを用いるか、等しく設定することによって、実際のラスタ動作を特定し、その値の次に示される対応する動作が選択される。すなわち、第１カラムにリストされた各ビット[３：０]は、第２カラムで特定され、更に明確化のために第３カラムで定義された動作となる。

ビット９乃至８は、宛先ピクセルが、透明色に関連するものとして、宛先位置に書き込まれているか否かを指定するために使用される。クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット４は、透明色及び透明マスク機能が、クライアントによってサポートされているか否かを示す。同様に、代替ディスプレイ機能パケットのディスプレイ特徴機能インジケータフィールドのビット４は、透明色及び透明マスク機能が、指定された代替ディスプレイによってサポートされているかを示す。透明色及び透明マスクがサポートされていない場合、ラスタ動作は、ビット[９:８]があたかも００に設定されたかのように振る舞う。ビット[９:８]によって指定される動作は、ラスタ動作がクライアントデバイスによってサポートされているか否かに当てはまる。クライアントがラスタ動作をサポートしないのであれば、結果としてビット[９:８]によって定義される動作のために考慮される宛先ピクセル値は、ソースピクセル値にのみ等しくなる。この振る舞いは、ビット[３:０]を３に設定することと同じである。

ビット[９:８]の値が００に等しい場合、透明色は使用されない。結果的に得られる宛先ピクセルは、透明色又は透明マスクの値を考慮することなく、宛先ピクセル位置に書き込まれる。透明色は、透明色及びマスクセットアップパケットによって定義される。０１に等しいビット[５:４]の値は、現在、将来の使用のために予約されており、一般的に、使用されない。ビット[５:４]の値が１０に等しい場合、ラスタ動作によって計算された結果得られた宛先ピクセルと、透明マスクとＡＮＤを取られたソースピクセルとが透明色に等しい場合には、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。等しくない場合には、宛先ピクセル位置に書き込まれる。ビット［９：８］の値が１１に等しい場合、ラスタ動作によって計算された結果得られた宛先ピクセルが透明色に等しいのであれば、結果として得られるピクセルは、宛先ピクセル位置に書き込まれる。等しくない場合には、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。

ビット１５乃至１０及びビット７乃至４は、将来の使用のために予約され、一般に、論理ゼロ値又は論理ゼロレベルに等しく設定される。

Ｊ．ビットマップパターン塗りつぶしパケット
１つの実施形態では、ビットマップパターン塗り潰しパケットのウィンドウ左上座標Ｘ値フィールドとＹ値フィールドは、塗りつぶされるウィンドウの左上角の座標のＸ値とＹ値を指定するためにそれぞれ２バイトを使用する。ウィンドウ幅フィールドと高さフィールド（各２バイト）は、塗りつぶされるウィンドウの幅と高さを指定する。パターン幅フィールドとパターン高さフィールド（各２バイト）は塗りつぶしパターンの幅と高さをそれぞれ指定する。水平パターンオフセットフィールド（２バイト）は、塗りつぶされる特定のウィンドウの左端から、ピクセルデータパターンの水平オフセットを特定する。特定されている値は、パターン幅フィールド内の値よりも小さくなるであろう。垂直パターンオフセットフィールド（２バイト）は、塗りつぶされると特定のウィンドウの上端から、ピクセルデータパターンの垂直オフセットを特定する。特定されている値は、パターン高さフィールド内の値よりも小さくなるであろう。

１つの実施形態では、２バイトのピクセルデータ属性フィールドが、ピクセルデータがどこで更新されるかを特定する値を有している。ここで、ビット１及びビット０は、ピクセルデータが更新されるかディスプレイを選択する。クライアントにおける主ディスプレイが、ステレオイメージをサポートしないのであれば、クライアントは、ビット組み合わせ０１，１０，又は１１のうちの１つで主ディスプレイ内におけるピクセルデータに影響を与えることができる。値１１は、ステレオディスプレイ機能をサポートしないクライアントにおける主ディスプレイに対処するために使用されることが推奨される。ビット[１:０]が値１１（論理１、論理１）を持つ場合、ピクセルデータは、左目と右目の両方のフレームバッファ内で更新され、ビット[１:０]が値１０（論理１、論理０）を持つのであれば、ピクセルデータは、左目のみのフレームバッファ内で更新される。ビット[１:０]が値０１（論理０、論理１）を持つ場合、ピクセルデータは、右目のみのフレームバッファ内で更新される。ビット[１:０]が値００（２つとも論理０）の場合、ピクセルデータは、ビット８乃至１１で指定される代替ディスプレイのフレームバッファ内で更新される。

ビット３乃至２は、将来の使用のために予約され、ゼロに設定されているものとする。

ビット４は、動作のための宛先イメージとしてラスタ動作に入力されるのは、左目のバッファであるか、右目のバッファであるかを特定する。ビット４は、ビット[１:０]が００に等しくない場合に適合する。これは、イメージの宛先が代替ディスプレイのうちの１つである場合、メインイメージバッファからのソースデータをサポートしないことを意味する。ビット４は、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット２１、又は代替ディスプレイ機能パケットのディスプレイ特徴機能インジケータフィールドのビット２１によって示されるように特定されたディスプレイ上でクライアントがラスタ動作をサポートする場合にのみ適合する。ビット４が０に等しいのであれば、左目フレームバッファがデータソースであり、ビット４が１に等しいのであれば、右目フレームバッファがデータソースである。

ビット５は、ディスプレイをリフレッシュするために使用されるバッファ、又はオフラインバッファが、ラスタ動作のための宛先イメージとして、ラスタ動作への入力として作用するかを特定する。ビット５はまた、代替ディスプレイがオフラインイメージバッファを利用するのであれば、代替ディスプレイに適合する。イメージの宛先が代替ディスプレイのうちの１つである場合、メインのイメージバッファからのソースデータのためのサポートはなされない。あるいは、その逆も可能である。ビット５が値０に等しいのであれば、ディスプレイをリフレッシュするために使用されるイメージバッファがデータソースである。ビット５が値１に等しい場合、オフラインイメージバッファがデータソースである。

ピクセルデータ属性フィールドのビット７及びビット６は、ピクセルデータが更新又は書き込まれるフレームバッファを指定するディスプレイ更新ビットとして作用する。フレーム更新ビットの効果は、既に詳述されている。ビット[７：６]が‘０１’（論理ゼロ、論理１）である場合、ピクセルデータは、オフラインイメージバッファに書き込まれる。ビット[７:６]が‘００’（２つとも論理ゼロ）である場合、ディスプレイをリフレッシュするために使用されるイメージバッファにピクセルデータが書き込まれる。ビット[７：６]が‘１１’（２つとも論理１）である場合、ピクセルデータは、全てのイメージバッファに書き込まれる。ビット[７：６]が‘１０’である場合、無効な値として取り扱われる。これらのビットは将来の使用のために予約されている。この状況では、コマンド全体が無視され、フレームバッファは更新されない。

ピクセルデータ属性フィールドのビット１１乃至８は、ピクセルデータが更新される代替クライアント位置又は代替ディスプレイ位置を特定する。クライアントが、ビット１１乃至８を代替ディスプレイ数として解釈するために、ビット０及びビット１は値００（２つとも論理ゼロ）に等しく設定される。ビット１及びビット０が００に等しくないのであれば、ビット８乃至１１は一般に、論理ゼロ値又はレベルに等しく設定される。ビット２,３,１２乃至１５は、将来の使用のために予約され、一般に、論理ゼロレベル又は値に設定される。

１つの実施形態では、２バイトのラスタ動作フィールドは、宛先イメージ位置に書き込まれる新たなピクセル値を生成するために、ソース位置及び宛先位置における各ピクセルをどのように組み合わせるかを指定する。ラスタ動作は、フレームバッファ内の等しいサイズの２つの異なる長方形領域がどのように合成されるのかを定義する。宛先イメージ領域もまた、合成される２つのイメージのうちの１つである。２つのイメージのうちの第２のイメージはソースイメージと呼ばれる。クライアントが、ラスタ動作フィールドを、クライアント機能パケット内で指定されたものとしてサポートしない場合、ホストは一般に、このパケットを、３に等しいビット３乃至０とともに送り、クライアントは、ビット３から０を無視する。

１つの実施形態では、ビット３から０は、それらを以下に示す表ＸＶＩＩに示す値のうちの１つを用いるか、等しく設定することによって、実際のラスタ動作を特定し、その値の次に示される対応する動作が選択される。すなわち、第１カラムにリストされた各ビット[３：０]は、第２カラムで特定され、更に明確化のために第３カラムで定義された動作となる。

ビット９乃至８は、宛先ピクセルが、透明色に関連するものとして、宛先位置に書き込まれているか否かを指定するために使用される。クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット４は、透明色及び透明マスク機能が、クライアントによってサポートされているか否かを示す。同様に、代替ディスプレイ機能パケットのディスプレイ特徴機能インジケータフィールドのビット４は、透明色及び透明マスク機能が、指定された代替ディスプレイによってサポートされているかを示す。透明色及び透明マスクがサポートされていない場合、ラスタ動作は、ビット[９:８]があたかも００に設定されたかのように振る舞う。ビット[９:８]によって指定される動作は、ラスタ動作がクライアントデバイスによってサポートされているか否かに当てはまる。クライアントがラスタ動作をサポートしないのであれば、結果としてビット[９:８]によって定義される動作のために考慮される宛先ピクセル値は、ソースピクセル値にのみ等しくなる。この振る舞いは、ビット[３:０]を３に設定することと同じである。

ビット[９:８]の値が００に等しい場合、透明色は使用されない。結果的に得られる宛先ピクセルは、透明色又は透明マスクの値を考慮することなく、宛先ピクセル位置に書き込まれる。透明色は、透明色及びマスクセットアップパケットによって定義される。０１に等しいビット[５:４]の値は、現在、将来の使用のために予約されており、一般的に、使用されないが、当該技術における熟練者が、関連する用途を設定するために利用することが可能である。ビット[５:４]の値が１０に等しい場合、ラスタ動作によって計算された結果得られた宛先ピクセルと、透明マスクとＡＮＤを取られたソースピクセルとが透明色に等しい場合には、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。等しくない場合には、宛先ピクセル位置に書き込まれる。ビット［９：８］の値が１１に等しい場合、ラスタ動作によって計算された結果得られた宛先ピクセルが透明色に等しいのであれば、結果として得られるピクセルは、宛先ピクセル位置に書き込まれる。等しくない場合には、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。

ビット１５乃至１０及びビット７乃至４は、将来の使用のために予約され、一般に、論理ゼロ値又は論理ゼロレベルに等しく設定される。

１つの実施形態では、ビットマップパターン塗り潰しパケットにおける２バイトのパラメータＣＲＣフィールドは、パケット長からビデオフォーマット記述子までのすべてのバイトのＣＲＣを含む。このＣＲＣがチェックできない場合には、パケット全体が廃棄される。パターンピクセルデータフィールドはビデオデータフォーマット記述子により指定されるフォーマットの塗りつぶしパターンを指定する未処理ビデオ情報を含む。データはバイトにパックされ、各行の第１のピクセルはバイト位置合わせされる。塗りつぶしパターンデータは一度に一行ずつ送信される。ビットマップパターン塗り潰しパケットのためのパターンピクセルデータＣＲＣフィールドは、パターンピクセルデータだけのＣＲＣを含む２バイトを用いる。このＣＲＣがチェックできない場合、パターンピクセルデータは依然として使用できるが、ＣＲＣエラーコンテンツは増分される。

Ｋ．通信リンクデータチャネルパケット
パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣがチェックできない場合は、パケット全体が廃棄される。

通信リンクデータフィールドは、通信チャネルからの未処理データを含む。このデータは単にディスプレイのコンピュータデバイスに渡される。

通信リンクデータＣＲＣフィールド（２バイト）は、通信リンクデータだけの１６ビットＣＲＣを含む。このＣＲＣがチェックできない場合、通信リンクデータは依然として使用されるあるいは有効であるが、ＣＲＣエラーカウントは増分される。

Ｌ．順方向音声チャネルイネーブルパケット
音声チャネルイネーブルマスクフィールド（１バイト）は、どの音声チャネルがクライアントでイネーブルされなければならないのかを示すフラグのグループを含む。１に設定されるビットは、対応するチャネルをイネーブルし、ゼロに設定されるビットは対応するチャネルをディスエーブルする。ビット０から５は、それぞれ左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中心チャネル、及びサブウーファーチャネルをアドレス指定するチャネル０から５を指定する。ビット６と７は、将来の使用のために予約されており、当面は通常ゼロに等しく設定されている。

Ｍ．逆方向音声サンプルレートパッケージ
音声サンプルレートフィールド（１バイト）はデジタル音声サンプルレートを指定する。このフィールドの値は様々な速度に割り当てられ、０、１、２、３、４、５、６、７、及び８という値は８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、及び４４，１００毎秒サンプル（ＳＰＳ）を示すために使用され、９から２５４という値は、所望されるように代替速度と使用するために予約されているため、それらは現在は「０」に設定されている。２５５という値は逆方向リンク音声ストリームをディスエーブルするために使用される。

サンプルフォーマットフィールド（１バイト）は、デジタル音声サンプルのフォーマットを指定する。ビット［１：０］が［０］に等しいとき、デジタル音声サンプルは線形フォーマットを取り、それらが１に等しい時には、デジタル音声サンプルはμ法則フォーマットを取る。それらが２に等しいとき、デジタル音声サンプルはＡ−法則フォーマットである。ビット［７：２］は、所望されるように、音声フォーマットを指定する上での代替使用に予約されており、通常はゼロに等しく設定されている。

Ｎ．デジタルコンテンツ保護オーバヘッドパケット用
コンテンツ保護タイプフィールド（１バイト）は、使用されるデジタルコンテンツ保護方法を指定する。１という値は高帯域幅デジタルコンテンツ保護システム（ＨＤＣＰ）を示すが、「０」という値はデジタル伝送コンテンツ保護（ＤＴＣＰ）を示す。２から２５５という値は、現在指定されていいないが、所望されるように代替保護方式との使用のために予約されている。コンテンツ保護オーバヘッドメッセージフィールドは、ホストとクライアントの間で送信されるコンテンツ保護メッセージを含む可変長のフィールドである。

Ｏ．透明色イネーブルパケット
透明色イネーブルフィールド（１バイト）は、透明色モードがいつイネーブルされる、あるいはディスエーブルされるのかを指定する。ビット０が０に等しい場合、透明色モードはディスエーブルされ、それが１に等しい場合、透明色モードはイネーブルされ、透明色は以下の２つのパラメータによって指定される。このバイトのビット１から７は、将来の使用のために予約され、通常ゼロに等しく設定されている。

ビデオデータフォーマット記述子フィールド（２バイト）は、ピクセル領域塗りつぶし値のフォーマットを指定する。図１１は、ビデオデータフォーマット記述子がどのようにしてコーディングされるのかを示す。フォーマットは、通常ビデオストリームパケット内の同じフィールドと同じである。

ピクセル領域塗りつぶし値フィールドは、前記に指定されるウィンドウの中に充填されるピクセル値のために割り当てられる４バイトを使用する。このピクセルのフォーマットはビデオデータフォーマット記述子フィールドに指定されている。

Ｐ．往復遅延測定パケット
２バイトのパケット長フィールドは、パケット長フィールドを含まないパケット内のバイト総数を指定し、一実施形態では、１５９という固定長を有するように選択されている。このパケットタイプを８２という値で識別する２バイトのパケットタイプフィールドは、往復遅延測定パケットとしてパケットを識別する。ｈＣｌｉｅｎｔＩＤフィールドは、前記のように、クライアントＩＤとして将来使用するために予約されており、通常ゼロに設定されている。

一実施形態では、パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣがチェックできない場合、パケット全体が廃棄される。

ガード時間１フィールド（ここでは６４バイト）は、クライアントのＭＤＤＩ＿Ｄａｔａラインドライバが、ホストのラインドライバがディスエーブルされる前にイネーブルできるようにするために使用される。クライアントは、ガード時間１のビット０の間にそのＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルし、ホストはガード時間１の最後のビットの前に完全にディスエーブルされるようにそのラインドライバをディスエーブルする。ホストとクライアントは、それらがディスエーブルされていないとき、共にガード時間１の間に論理ゼロレベルを駆動する。このフィールドの別の目的は、すべてのＭＤＤＩ＿Ｄａｔａ信号が、クライアントが、ホストのラインドライバをディスエーブルする前にＭＤＤＩ＿Ｓｔｂだけを使用して、クロック又はクロック信号の回復を開始できるほど十分な時間論理ゼロレベルにあることを保証することである。

測定期間フィールドは、クライアントが、順方向リンクで使用されるデータレートの半分で、０ｘｆｆという２つのバイト、及び０ｘ００という３０バイトに応答できるようにするために使用される６４バイトのウィンドウである。このデータレートは１という逆方向リンクレート除数に相当する。クライアントは、それが測定期間の始まりであると知覚するとただちにこの応答を返す。このクライアントからの応答は、正確にリンクの往復遅延に、ホストでの測定期間の第１のビットの開始後のクライアントの論理遅延を加えたもので、ホストで受信される。

全ゼロフィールド（２バイト）は、ホストとクライアント内のＭＤＤＩ＿Ｄａｔａラインドライバが、ＭＤＤＩ＿Ｄａｔａが常に駆動されるように重複できるようにするためにゼロを含んでいる。ホストは全てゼロの１フィールドのビット０の間にＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルし、クライアントも測定期間の最後でそれが行ったように、論理ゼロレベルに信号を駆動し続ける。

ガード時間２フィールド（６４バイト）の値は、往復遅延が測定期間で測定できる最大量であるときにクライアントによって駆動される測定期間の重複を可能にする。クライアントはそのラインドライバをガード時間２のビット０の間にディスエーブルし、ホストはガード時間２の最後のビットの直後にそのラインドライバをイネーブルする。ホストとクライアントの両者とも、それらがディスエーブルされていないときガード時間２の間に論理ゼロレベルを駆動する。このフィールドの別の目的は、すべてのＭＤＤＩ＿Ｄａｔａ信号が、クライアントが、ホストのラインドライバをイネーブルした後に、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂの両方を使用してクロック信号の回復を開始できるほど十分な時間論理ゼロレベルにいることを保証することである。

Ｑ．順方向リンク歪み校正パケット
一実施形態では、パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣがチェックできないと、パケット全体が廃棄される。

全てゼロの１フィールドは、構成データシーケンスフィールドの始まりにおいて、ＭＤＤＩ＿Ｓｔｂ上の遷移があることを保証するために、８バイトを用いる。一般に、これらバイトは、ゼロに等しい８ビット符号なし整数を適用する。これはまた、クライアントコア論理が、ＭＤＤＩ＿Ｓｔｂ及びＭＤＤＩ＿０のＸＯＲを用いることから、ＭＤＤＩ＿Ｓｔｂ又は回復されたクロックとしてＭＤＤＩ＿Ｓｔｂ信号を単に用いることにクロック回復回路のモードを変更するための十分な時間を与える。

校正データシーケンスフィールドは、ＭＤＤＩ＿Ｄａｔａ信号をデータ期間ごとにトグルさせるデータシーケンスを含む。校正データシーケンスフィールドの長さは、順方向リンク上で使用されているインタフェースによって決定される。校正データシーケンスの処理中、ＭＤＤＩホストコントローラはすべてのＭＤＤＩ＿Ｄａｔａ信号をストローブ信号に等しく設定する。校正データシーケンスフィールドはクライアントによって受信されているが、クライアントクロック回復回路は、データクロックを回復するためにＭＤＤＩ＿Ｓｔｂ ＸｏｒＭＤＤＩ＿Ｄａｔａ０よりむしろＭＤＤＩ＿Ｓｔｂだけを使用するべきである。校正データシーケンスフィールドの始まりのＭＤＤＩ＿Ｓｔｂ信号の正確な位相に応じて、校正データシーケンスは通常、このパケットが送信されるときに使用されるインタフェースタイプに基づいて、以下の１つとなる。

１型−（６４バイトデータシーケンス）０ｘａａ，０ｘａａ，・・・又は０ｘ５５，０ｘ５５・・・
２型−（１２８バイトデータシーケンス）０ｘｃｃ，０ｘｃｃ，・・・又は０ｘ３３，０ｘ３３・・・
３型−（２５６バイトデータシーケンス）０ｘｆ０，０ｘｆ０，・・・又は０ｘ０ｆ，０ｘ０ｆ・・・
４型−（５１２バイトデータシーケンス）０ｘｆｆ，０ｘ００，０ｘｆｆ，０ｘ００・・・又は０ｘ００，０ｘｆｆ，０ｘ００，０ｘｆｆ・・・
全てゼロの２フィールドは、８バイトを使用して、クライアントコア論理が、クロック回復回路のモードをオリジナル状態に戻すのに、回復したクロックとしてのＭＤＤＩ＿Ｓｔｂ信号を用いることから、ＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿０とのＸＯＲを用いることに変更するのに十分な時間を与える。

１型インタフェースと２型インタフェース両方のためのＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形の例は、それぞれ図６２Ａと図６２Ｂに示されている。

ＸＶＩＩ．結論
本発明の多様な実施形態は前述されてきたが、それらが例証としてのみ提示され、制限ではないことが理解されるべきである。したがって、本発明の幅及び範囲は、前述された例示的な実施形態のいずれによっても制限されるべきではなく、添付請求項及びその同等物に従ってのみ定義されるべきである。

Claims (33)

1. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルプレゼンテーションデータを転送するためのデジタルデータインタフェースであって、
   前記通信経路上、ホストとクライアント間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するための通信プロトコルを形成するために、共にリンクされる複数のパケット構造と、
   前記通信経路を通って前記クライアントに結合され、前記通信プロトコルを形成するパケットを生成、送信、及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、前記ホストデバイスに常駐する少なくとも１台のリンクコントローラと、
   を備える、デジタルデータインタフェース。
2. 前記ホストとクライアントの間で通信され、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有する、メディアフレーム内で共にグループ化される前記パケットをさらに備える、請求項１に記載のインタフェース。
3. 前記ホストからのパケットの転送の始めに配置されるサブフレームヘッダパケットをさらに備える、請求項１に記載のインタフェース。
4. 具体的なクライアントに関連したハードウェアを低電力状態にするディスプレイ電力ステータスパケットを更に備えた請求項１に記載のインタフェース。
5. 前記リンクコントローラはホストリンクコントローラであって、前記通信経路を通って前記ホストに結合される前記クライアントデバイスに常駐する少なくとも１台のクライアントリンクコントローラをさらに備え、前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、請求項１に記載のインタフェース。
6. それぞれが既定の期間に並列でデータの異なる最大数のビットの転送を可能にする複数の転送モードであって、各モードが前記ホストリンクドライバとクライアントリンクドライバの間の交渉により選択可能である、複数の転送モードをさらに備え、
   前記転送モードはデータの転送中に前記モードの間で動的に調整可能である、
   請求項２に記載のインタフェース。
7. 前記通信経路上、どちらかの方向でデータの転送を終了するために、前記ホストによる前記クライアントに対する伝送のためのリンクシャットダウンタイプパケットをさらに備える、請求項１に記載のインタフェース。
8. 前記クライアントがハイバネーション状態から前記ホストをスリープ解除するための手段をさらに備える、請求項１に記載のインタフェース。
9. ユーザへのプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において高速でデジタルデータを転送する方法であって、
   複数の所定のパケット構造の内の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクすることと、
   前記通信プロトコルを使用して、前記通信経路上、前記ホストと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信することと、
   前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、前記ホストデバイスに常駐する少なくとも１台のホストリンクコントローラを、前記通信経路を通して前記クライアントデバイスに結合することと、
   前記リンクコントローラを使用して前記通信経路上でパケットの形を取るデータを転送することと、
   を備える、方法。
10. 前記ホストとクライアント間の通信のために、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有するメディアフレーム内で、前記パケットを共にグループ化することをさらに備える、請求項９に記載の方法。
11. サブフレームヘッダタイプパケットを用いる前記ホストからのパケットの転送を開始することをさらに備える、請求項９に記載の方法。
12. 前記通信経路を通して前記ホストデバイスに結合された前記クライアントデバイスに常駐する少なくとも１台のクライアントリンクコントローラを通じて前記通信プロトコルを形成するパケットを生成し、送信し、受信することをさらに備える、請求項９に記載の方法。
13. ホストリンクドライバとクライアントリンクドライバの間で、それぞれが既定の期間において並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つの使用を交渉することと、
    データの転送中、前記転送モードの間で動的に調整することと、
    をさらに備える、請求項１２に記載の方法。
14. 前記クライアントへの前記ホストによる伝送のために、リンクシャットダウンタイプのパケットを使用して前記通信経路においてどちらかの方向でデータの転送を終了することをさらに備える、請求項９に記載の方法。
15. 前記クライアントとの通信によりハイバネーション状態から前記ホストをスリープ解除することをさらに備える、請求項９に記載の方法。
16. 具体的なクライアントハードウェアを低電力状態にするディスプレイ電力ステータスパケットを生成することを更に備えた請求項９に記載の方法。
17. ユーザへのプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において高速でデジタルデータを転送するための装置であって、
    複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするために、及び前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するために、前記ホストデバイス内に配置される少なくとも１台のホストリンクコントローラと、
    前記クライアントデバイスに配置され、前記通信経路を通して前記ホストリンクコントローラに結合される、少なくとも１台のクライアントコントローラと、
    前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、各リンクコントローラと、
    を備える、装置。
18. 前記ホストコントローラは状態機械を備える、請求項１７に記載の装置。
19. 前記ホストコントローラは汎用信号プロセッサを備える、請求項１７に記載の装置。
20. 前記ホストからのパケットの転送の開始時にサブフレームヘッダタイプパケットをさらに備える、請求項１７に記載の装置。
21. 前記ホストコントローラは１台又は複数台の差動ラインドライバを備え、前記クライアントレシーバは前記通信経路に結合される１台又は複数台の差動ラインレシーバを備える、請求項１７に記載の装置。
22. 前記ホストリンクコントローラとクライアントリンクコントローラは、それぞれが既定の期間において、並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つを使用するように構成され、データの転送中、前記転送モードの間で動的に調整することができる、請求項１７に記載の装置。
23. 前記ホストコントローラは、前記通信経路上、どちらかの方向でデータの転送を終了するために、前記クライアント手段にリンクシャットダウンタイプのパケットを送信するように構成される、請求項１７に記載の装置。
24. 前記ホストコントローラは、具体的なディスプレイコントローラハードウェアを、低電力状態にするディスプレイ電力ステータスパケットを生成するように構成される請求項１７に記載の装置。
25. ユーザに対するプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための電子システムでの使用のために、
    アプリケーションプログラムを前記コンピュータシステム上で実行させるために、前記媒体で具現化されるコンピュータ読み取り可能プログラムコード手段を有するコンピュータ使用可能な媒体を備える、コンピュータプログラム製品であって、前記コンピュータ読み取り可能プログラムコード手段は、
    コンピュータシステムに複数の所定のパケット構造の１つ又は複数を生成させ、所定の通信プロトコルを形成するために、それらを共にリンクさせるためのコンピュータ読み取り可能第１プログラムコード手段と、
    前記コンピュータシステムに、前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信させるための、コンピュータ読み取り可能第２プログラムコード手段と、
    前記コンピュータシステムに、前記通信経路を通して、前記ホストデバイスに配置される少なくとも１台のホストリンクコントローラを、前記クライアントデバイスに配置される少なくとも１台のクライアントコントローラに結合させるようにするための、コンピュータ読み取り可能第３プログラムコード手段であって、前記リンクコントローラは、前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、コンピュータ読み取り可能第３プログラムコード手段と、
    前記リンクコントローラを使用して前記通信経路上、パケットの形をしたデータをコンピュータシステムに転送させるためのコンピュータ読み取り可能第４プログラムコード手段と、
    を備える、コンピュータプログラム製品。
26. 前記コンピュータシステムに対して、予め定義されたパケット構造を生成させ、それらを共に接続して予め定義された通信プロトコルを生成させるコンピュータ読み取り可能プログラムコード手段を備えた請求項２５に記載のコンピュータプログラム製品。
27. ユーザに対するプレゼンテーションのために、通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための装置であって、
    複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするための手段と、
    前記通信プロトコルを使用して前記通信経路で前記ホストデバイスと前記クライアントデバイスの間で、事前に選択されたデジタル制御データ及びデジタルプレゼンテーションデータを通信するための手段と、
    前記ホストとクライアントのそれぞれに１つ、それぞれが前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、少なくとも２台のリンクコントローラを、前記通信経路を通して共に結合するための手段と、
    前記リンクコントローラを使用して前記通信経路上、パケットの形をとるデータを転送するための手段と、
    を備える、装置。
28. サブフレームヘッダタイプパケットを用いて、前記ホストからパケットの転送を開始するための手段をさらに備える、請求項２７に記載の装置。
29. 具体的なハードウェアを、低電力状態にするように構成されたディスプレイ電力ステータスパケットを生成することを備える手段を更に備えた請求項２７に記載の装置。
30. 前記クライアントが前記インタフェースを通してどのようなタイプのデータとデータレートに対処できるのかを決定するために、ホストリンクコントローラによってクライアントから表示機能情報を要求するための手段をさらに備える、請求項２７に記載の装置。
31. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための電子システムで使用するためのプロセッサであって、複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクし、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成し、前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信し、前記通信経路上でパケットの形をしたデータを転送するように構成された、プロセッサ。
32. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送する電子システム内で同期を取る際に使用するための状態機械であって、少なくとも１つの非同期フレーム状態同期状態、少なくとも２つの同期状態獲得同期状態、及び少なくとも３つの同期中状態同期状態を有するように構成される、状態機械。
33. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送する電子システム内で同期を取る際に使用するための状態機械であって、少なくとも１つの同期状態獲得動機状態と、少なくとも２つの同期中状態同期状態とを有するように構成される、状態機械。

Images