JP2007512785A

JP2007512785A - 改良されたリンク同期を備えた高速データレートインタフェース

Info

Publication number: JP2007512785A
Application number: JP2006541453A
Authority: JP
Inventors: アンダーソン、ジョン・ジェームス; スティール、ブライアン; ウィレイ、ジョージ・エー．; シェカー、シャシャンク
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2003-11-25
Filing date: 2004-11-24
Publication date: 2007-05-17
Also published as: EP1690404A1; TW200529000A; WO2005053272A1; CN101053232A; US20050163116A1; CA2546971A1; US8687658B2; MXPA06006012A; BRPI0416895A; KR20060096161A; ZA200604195B; RU2006122542A; WO2005053272A9

Abstract

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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

３００Ｈｚという共通フレームレートを想定する場合には、各サブフレームはクライアント表示装置に対する順方向リンク上での（ステレオの１４７個の１６ビットのサンプルに基づき）９２，１６０バイトのビデオコンテンツと５８８バイトの音声コンテンツからなり、平均２６．６７（２６−２／３）バイトの音声がマイクから移動性カラオケ機械に送り返される。非同期パケットがホストとおそらくヘッドマウント式のディスプレイの間で送信される。これは多くても７６８バイトのグラフィックデータ（画面の４分の１の高さ）、及び他の制御コマンドとステータスコマンドのための約２００バイト（数）バイト未満を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前述された共通のフレーム概念は、音声バッファサイズを最小限に抑え、待ち時間を減少させるための効果的な方法である。しかしながら、ビデオデータの場合、メディアフレーム内で複数のビデオストリームパケット全体で１つのビデオフレームのピクセルを拡散することが必要な場合がある。単一のビデオストリームパケットのピクセルがディスプレイ上の完全に矩形のウィンドウに正確に一致しない可能性も高い。毎秒３０コマという例示的なビデオフレームレートの場合、毎秒３００サブフレームがあり、その結果メディアフレームあたり１０のサブフレームが生じる。各フレームに４８０行のピクセルがある場合、各サブフレーム内の各ビデオストリームパケットは４８行のピクセルを含むであろう。他の状況では、ビデオストリームパケットは整数のピクセル行を含まない可能性がある。これは、メディアフレームあたりのサブフレーム数が（ビデオラインとしても知られる）ビデオフレームあたりの行数に均等に分かれない他のビデオフレームサイズに当てはまる。効率的な動作のために、各ビデオストリームパケットは、たとえそれが整数行のピクセルを含まない可能性があるとしても、通常、整数のピクセルを含まなければならない。ピクセルがそれぞれ複数バイトである場合、あるいはそれらが図１２に示されるようなパックされたフォーマットである場合に重要である。

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

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

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

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

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

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

特定のディスプレイウィンドウのメディアフレームの第１のビデオストリームパケットの第１のピクセルはＸ左端端縁とＹ上部端縁により定められるストリームウィンドウの左上角に入り、次に受信されるピクセルは同じ行の次のピクセルロケーションに配置される等である。メディアフレームのこの第１のパケットでは、Ｘ開始値は通常Ｘ左端縁に等しく、Ｙ開始値は通常Ｙ上部端縁に等しい。同じ画面ウィンドウに対応する以後のパケットでは、Ｘ開始値とＹ開始値は、通常、過去のサブフレーム内で送信されたビデオストリームパケットで送信された最後のピクセルの後に通常は続くであろう画面ウィンドウ内のピクセル位置に設定される。

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

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

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

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

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

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

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

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

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

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

ホストは全ゼロ１フィールドの間にＭＤＤＩ＿Ｄａｔａ信号を論理ゼロレベルに駆動し、クライアントは方向転換２フィールドの開始前の少なくとも１つの逆方向リンククロック期間中、つまり全ゼロ２フィールド期間中にＭＤＤＩデータラインを論理ゼロレベルに駆動する。これによりデータラインは、方向転換１フィールド期間と方向転換２フィールド期間の間、決定性状態に保たれる。クライアントにそれ以上送信するパケットがない場合、ハイバネーションバイアス抵抗器（どこか他の箇所で説明される）が逆方向データパケットフィールドの残りの間、あるいは約１６順方向リンクバイト以上の期間、データラインを論理ゼロレベルに保つため、それは論理ゼロレベルにそれらを駆動した後にデータラインをディスエーブルすることさえある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１４．ビットブロック転送パケット
ビットブロック転送パケットは、任意の方向でディスプレイの領域をスクロールするための手段、構造、又は方法を提供する。この機能を有するディスプレイは、クライアント機能パケットの表示特徴機能インジケータフィールドのビット０で機能を報告する。ビットブロック転送パケットの、一つの実施形態のフォーマットは図２３に示されている。図２３に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、ウィンドウＸ移動フィールド、ウィンドウＹ移動フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは通常７１型パケットとして識別され、一つの実施形態では、１５バイトという事前に選択された固定長を使用する。

該フィールドは、移動されるウィンドウの左上角の座標のＸ値とＹ値、移動されるウィンドウの幅と高さ、及びウィンドウが水平に移動されなければならないピクセル数、及び垂直に移動されなければならないピクセル数をそれぞれ指定するために使用される。後者の２つのフィールドの正の値はウィンドウを右及び下方へ移動させ、それぞれ負の値は左と上に移動させる。

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

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

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

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

１７．通信リンクデータチャネルパケット
通信リンクデータチャネルパケットは、ＰＤＡ等の高水準計算機能を備えたクライアントが携帯電話、又は無線データポート装置等の無線トランシーバと通信するための構造、手段、又は方法を提供する。この状況では、ＭＤＤＩリンクは、通信装置とモバイルディスプレイ付きの計算装置の間の便利な高速インタフェースとして働いており、このパケットはデータを該装置のオペレーティングシステムのデータリンク層でトランスポートする。例えば、このパケットは、ウェブブラウザ、ｅメールクライアント、又はＰＤＡ全体がモバイルディスプレイの中に内蔵されている場合に使用できるであろう。この機能を有するディスプレイはクライアント機能パケットのクライアント特徴機能フィールドのビット３で該機能を報告する。

通信リンクデータチャネルパケットのための実施形態のフォーマットは図２６に示されている。図２６に示されているように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、パラメータＣＲＣフィールド、通信リンクデータフィールド、及び通信データＣＲＣフィールドを有するように構造化されている。一つの実施形態では、この種のパケットは、通常、タイプフィールドで７４型パケットとして識別される。

１８．インタフェースタイプハンドオフ要求パケット
インタフェースタイプハンドオフ要求パケットは、ホストが、クライアント又はディスプレイが既存のモード又はカレントモードから１型（シリアル）モード、２型（２−ビット並列）モード、３型（４ビット並列）モード、又は４型（８ビット並列）モードにシフトすることを要求することを可能にする手段、方法、又は構造を提供する。ホストがある特定のモードを要求する前に、それは、クライアント機能パケットの表示特徴機能インジケータフィールドのビット６と７を調べることによって、クライアントが所望されているモードで動作できることを確認しなければならない。インタフェースタイプハンドオフ要求パケットのフォーマットに対する一つの実施形態は図２７に示されている。図２７に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、インタフェースタイプフィールド、予約１フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常７５型パケットとして識別され、４バイトという事前に選択された固定長を使用する。

１９．インタフェースタイプ肯定応答パケット
インタフェースタイプ肯定応答パケットは、クライアントによって送信され、インタフェースタイプハンドオフパケットの受信をクライアントが確認できるようにする手段、方法、又は構造を提供する。要求されるモード、つまり１型（シリアル）モード、２型（２ビット並列）モード、３型（４ビット並列）モード又は４型（８ビット並列）モードは、このパケットでパラメータとしてホストにエコーバックされる。インタフェースタイプ肯定応答パケットのための一つの実施形態のフォーマットは図２８ｎ示されている。図２８に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、インタフェースタイプフィールド、予約１フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常７６型パケットとして識別され、４バイトという事前に選択された固定長を使用する。

２０．実行型ハンドオフパケット
実行型ハンドオフパケットは、ホストがこのパケットで指定されるモードにハンドオフするようにクライアントに命令するための手段、構造、又は方法である。これは、過去にインタフェースタイプハンドオフ要求パケットとインタフェースタイプ肯定応答パケットにより要求され、肯定応答されたのと同じモードでなければならない。ホストとクライアントは、このパケットが送信された後に合意されたモードに切り替わる必要がある。クライアントはモード変更の間にリンク同期を失い、再取得してよい。実行型ハンドオフパケットの一つの実施形態のフォーマットは図２９に示されている。図２９に示されているように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、パケットタイプフィールド、予約１フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常１バイトタイプのフィールドで７７型パケットとして識別され、４バイトという事前に選択された固定長を使用する。

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

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

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

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

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

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

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

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

クライアントに、及びクライアントから行き来する信号のために往復遅延時間を正確に決定するために、ホストは、測定期間の開始後、０ｘｆｆ、０ｘｆｆ、及び３０バイトの０ｘ０シーケンスの始まりが到着時に検出されるまでに発生する順方向リンクビット時間期間の数をカウントする。この情報は、往復遅延信号がホストからクライアント、及び再び逆に通過する時間量を求めるために使用される。したがって、この量の約２分の１はクライアントへの信号の一方向の通過のために生じる遅延を原因とする。

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

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

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

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

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

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

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

ｈＣｌｉｅｎｔＩＤフィールドは、将来の実施においてクライアントＩＤとして使用するために予約され、一般にゼロに設定されるＭＣＣＳＶＣＰコードフィールドは、ＭＣＣＳＶＣＰ制御コードパラメータを指定する２バイトの情報を備える。０から２５５の範囲の値は、ＶＣＰ特徴応答パケットを指定されたＭＣＣＳコードに対応するＶＣＰ特徴応答リスト内の単一のアイテムと共に返させる。６５５３５（０ｘｆｆｆ）というＭＣＣＳＶＣＰコードは、クライアントによってサポートされる制御ごとに特徴応答リストアイテムを含むＶＣＰ特徴応答リスト付きのＶＣＰ特徴応答パケットを要求する。このフィールドのための２５６から６５５３４までの値は、将来の使用のために予約され、現在は使用されていない。

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

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

ｃＣｌｉｅｎｔＩＤフィールドはクライアントＩＤに予約される情報を含む。このフィールドは将来の使用のために予約され、通常はゼロに設定されている。ＭＣＣＳバージョンフィールドは、クライアントによって実現されるＶＥＳＡＭＣＣＳ仕様のバージョンを指定する２バイトの情報を含む。

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

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

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

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

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

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

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

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

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

２バイトのパケット長フィールドに示されているようにパケット長は、通常、８というパケット長フィールドを含まずにパケット内のバイトの総数を有するために設定される。ｈＣｌｉｅｎｔＩＤは再びクライアントＩＤを指定するが、当業者に明らかとなるように現在は将来の使用のために予約されており、ゼロに設定されている。２バイトのＭＣＣＳＶＣＰコードフィールドは、照会される非連続ＭＣＣＳＶＣＰ制御コードパラメータを指定する値を含む。このフィールドの値はクライアントで実現される非連続制御に相当する。値２５６から６５５３５（０ｘｆｆｆｆ）は通常、予約されるか、あるいは有効と見なされ、エラー応答の中で実現される制御として見なされている。

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

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

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

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

３バイトＭＣＣＳＶＣＰコードパケットはこのパケットによって記述される非連続ＭＣＣＳＶＣＰ制御コードパラメータを指定する値を含むが、ｃＣｌｉｅｎｔＩＤフィールドは、前述の説明から公知であるように、将来のクライアントＩＤのために予約されている。無効ＭＣＣＳＶＣＰ制御コードが有効パラメータ要求パケットによって指定される場合には、応答コードフィールドに適切な値を備える、同じ無効パラメータ値がこのフィールドに指定される。ＭＣＣＳ制御コードが無効である場合には、ＶＣＰパラメータ応答リストはゼロ長を有するであろう。

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

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

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

アルファ−カーソル画像
ＭＤＤインタフェース及び通信リンク上でデータを通信するための関連する本発明のプロトコルと機構は、互いに重複し、様々な透明度を有することがある複数の画像平面に対するサポートを提供する。ハードウェアカーソルは、可変Ｘ−Ｙオフセットを有する重複する画像を使用して実現できる。アルファ−カーソル機能性及び関連プロトコルサポートの概要は以下に後述される。アルファ−カーソル画像パケットをサポートする能力は、特殊ステータス要求パケットに応じて送信されるアルファ−カーソル画像機能パケットに定義される。

３２．アルファ−カーソル画像機能パケット
アルファ−カーソル画像機能パケットは、アルファカーソル画像の特性及び関連する透明度マップをクライアントで定義するために使用される。一実施形態では、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リスト内で１３３というパラメータ値を使用してアルファ−カーソル画像機能パケットをサポートする能力を示す。パケット長フィールドに指定されるパケット長は、パケット長フィールドを含まずに、一実施形態の場合２０という固定値に設定される。

一実施形態のアルファ−カーソル画像機能パケットのフォーマットは図７５に示されている。図７５で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、アルファ−カーソル識別子フィールド、アルファ−カーソルビットマップ幅フィールド、アルファ−カーソルビットマップ高さフィールド、ＲＧＢ機能フィールド、白黒機能フィールド、予約１フィールド、ＹＣｒＣｂ機能フィールド、透明度マップＲｅｓ．フィールド、機能ビットフィールド、及びＣＲＣフィールドを有するように構造化されている。ｃＣｌｉｅｎｔＩＤフィールドは通常将来のクライアントＩＤの使用のために予約され、現在はゼロに設定されている。

アルファ−カーソル識別子フィールド（２バイト）は、特殊なアルファ−カーソル平面を識別する値を含む。クライアントがｎ個のアルファ−カーソル画像平面をサポートする場合には、アルファ−カーソル識別子は０からｎ−１という有効な範囲を有する。一実施形態では、値ｎは、クライアント機能パケットのアルファカーソル画像平面フィールドによって指定される。クライアントは、アルファカーソル画像平面ごとに一意のアルファカーソル画像機能パケットを返す。

２バイトのアルファ−カーソルビットマップ高さフィールド値はピクセルの数として表されるアルファ−カーソルビットマップ画像の高さを指定するが、２バイトのアルファ−カーソルビットマップ幅フィールド値は、ピクセルの数として表されるアルファ−カーソルビットマップ画像の幅を指定する。

ＲＧＢ機能フィールドは、ＲＧＢフォーマットで表示できる解像度のビット数を指定するために２バイトを使用する。クライアントがＲＧＢフォーマットを使用できない場合、この値はゼロである。ＲＧＢ機能ワードは３つの別々の値から構成され、一実施形態では以下のように実現される。ビット３から０が各ピクセルの青の最大ビット数（青輝度）を定義する。ビット７から４が各ピクセルの緑の最大ビット数（緑輝度）を定義し、ビット１１から８は、各ピクセルの赤（赤輝度）の最大ビット数を定義する。ビット１５から１２は、それらが通常とりあえずゼロになるようにＲＧＢ機能情報を提示する上で将来の使用のために予約される。

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

１バイトの予約１フィールドは将来の使用のために通常予約される値を含み、このようにしてこのフィールドのすべてのビットはゼロに設定される。これにより、以後の２バイトフィールドは１６ビットワードアドレスに位置合わせされ、４バイトフィールドは３２ビットワードアドレスに位置合わせされる。

２バイトのＹＣｂＣｒ機能フィールドは、ＹＣｂＣｒフォーマットで表示できる解像度のビット数を指定する値又は情報を含む。クライアントがＹＣｒＣｂフォーマットを使用できない場合には、この値はゼロである。一般的には、一実施形態では、ＹＣｂＣｒ機能ワードは、以下の３つの別々の値から構成されている。つまり、Ｃｒサンプルを指定する最大ビット数を定義するビット３から０、Ｃｂサンプルを指定する最大ビット数を定義するビット７から４、Ｙサンプルを指定する最大ビット数を定義するビット１１から８、及びＹＣｂＣｒ機能情報又は値を提示する上で将来の使用のために予約されているが、現在はゼロに設定されているビット１５から１２である。

１バイトの透明度マップ解像度フィールドはアルファ−カーソル画像透明度マップの各ピクセルロケーションのビット数（深度）を指定する値又は情報を含む。この値は１から８の範囲となる可能性がある。値がゼロである場合、透明度マップはこのアルファ−カーソル画像バッファにサポートされていない（アルファ−カーソル識別子フィールドによって指定されるバッファ）。

１バイトの機能ビットフィールドは、アルファ−カーソル画像バッファと関連付けられる機能を指定するフラグのセットを含む値又は情報を提供する。一実施形態では、フラグは以下のように定義される。ビット０はアルファ−カーソルビデオストリームパケットのピクセルデータをパックフォーマットで選択するために働く。ビット１は、アルファ−カーソル透明度パケットの透明度マップデータがパケットフォーマットであることを示すために働く。バイト位置合わせされ、パックされた透明度マップデータの例は図７６に示されている。ビット２は、アルファ−カーソル画像平面がアルファカーソル画像オフセットパケットを使用して画像オフセット機能をサポートすることを示すために動作する。ビット３は、アルファ−カーソル画像平面がカラーマップデータフォーマットをサポートできることを示すために働く。同じカラーマップ表は、メイン画像バッファ及びスケーリング済みのビデオストリームのために使用されるように、アルファカーソル画像平面に使用される。カラーマップは、他の箇所に説明されるカラーマップパケットを使用して構成されている。

ビット７から４は将来の使用のために予約されるため、通常はゼロ値又は論理レベルに設定される。

３３．アルファ−カーソル透明度マップパケット
アルファ−カーソル透明度マップパケットは、指定されたアルファ−カーソル画像平面のために画像透明度マップのコンテンツを定義する。いくつかのアプリケーションは、単一パケットで送信できるデータ量より多い透明度マップを必要とする可能性がある。これらのケースでは、それぞれが後述される透明度マップＸ開始フィールドとＹ開始フィールドを使用することによって透明度マップの異なる部分集合を備える、複数のアルファ−カーソル透明度マップパケットが送信されてよい。これらのフィールドは、ビデオストリームパケットのＸ開始フィールドとＹ開始フィールドと同様に動作する。クライアントは、アルファ−カーソル画像機能パケットのアルファ−カーソル識別子フィールドによって指定されるそれぞれの特定のアルファ−カーソル平面にアルファ−カーソル画像機能パケットの透明度マップ解像度フィールドを使用して一実施形態でアルファ−カーソル透明度マップパケットをサポートする能力を示す。パケット長及びクライアントＩＤフィールドは、前述された他のパケットについて前記のように動作する。一実施形態では、パケットタイプフィールドでの１３４という値はアルファ−カーソル透明度マップパケットとしてパケットを識別するために使用される。

一実施形態のアルファ−カーソル透明度マップパケットのフォーマットは図７６に示されている。図７６で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、アルファ−カーソル識別子フィールド、透明度マップＸ開始フィールド、透明度マップＹ開始フィールド、透明度マップ解像度フィールド、予約１フィールド、パラメータＣＲＣフィールド、透明度マップ媒体フィールド、及び透明度マップデータＣＲＣフィールドを有するように構造化されている。

２バイトアルファ−カーソル識別子フィールドは、特定のアルファ−カーソル平面を識別する値を有する。クライアントがｎ個のアルファ−カーソル画像平面をサポートする場合には、アルファ−カーソル識別子は０からｎ−１の有効範囲を有する。

２バイト透明度マップＸ開始フィールドとＹ開始フィールドは、それぞれ絶対Ｘ座標とＹ座標を指定し、点（透明度マップＸ開始、透明度マップＹ開始）は、以下の透明度マップデータフィールドで最初のピクセルである。

透明度マップ解像度フィールド（１バイト）は、透明度マップの解像度、及びデータがパックされているかどうかを指定する値を含む。このフィールドの一実施形態では、ビット３から０はすべての透明度マップ表アイテムに存在する解像度のビット数を定める。有効値は、１ビットから８ビットとなるように幅を指定する。値０及び９から１５は無効と見なされる。この値はアルファ−カーソル画像機能パケットの透明度マップ解像度フィールドにおいてクライアントにより返される値に一致しなければならない。ビット６から４は将来の使用のために予約され、したがって通常今度は論理ゼロに設定される。このバイトのビット７は透明度マップデータがパケットないにあるか、あるいはバイト位置合わせされた形式となるかどうかを指定する。ビット７が「１」に等しい場合には、透明度マップデータはパックされた形式であり、「０」の場合、データはバイト位置合わせされている。パックされた、及びバイト位置合わせされた透明度マップデータの例は、どこか他の箇所に示されている。このビットの値は、アルファ−カーソル画像機能パケットの機能ビットフィールドのビット１の値に一致しなければならない。

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

パラメータＣＲＣフィールドは、パケット長から予約１フィールドまでのすべてのバイトの１６ビットのＣＲＣを含む。このＣＲＣがチェックできない場合には、パケット全体が廃棄されなければならない。

透明度マップデータフィールドの場合、各透明度マップロケーションは幅が１ビットから８ビットである。単一の透明度マップが１つのアルファ−カーソル透明度マップパケットに適合できない場合には、透明度マップ全体が、各パケットの中に異なる透明度マップデータと透明度マップＸ開始値とＹ開始値のついた複数のパケットを送信することによって指定されてよい。

２バイトの伝送マップデータＣＲＣフィールドは唯一の透明度マップデータの１６ビットＣＲＣを含む。ＣＲＣがチェックできない場合には、透明度マップデータが依然として使用できるが、ＣＲＣエラーカウントが増分される。

３４．アルファ−カーソル画像オフセットパケット
アルファ−カーソル画像オフセットパケットは、メイン表示画像の左上角からのカーソルのＸオフセットとＹオフセットを指定する。アルファ−カーソル画像オフセットパケットは図７７に示されている。図７７に示されているように、一実施形態では、アルファ−カーソル画像オフセットパケットがパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、アルファ−カーソルＸオフセットフィールド、アルファ−カーソルＹオフセットフィールド、及びＣＲＣフィールドで構造化されている。一実施形態では、クライアントは、アルファ−カーソル画像機能パケットのアルファ−カーソル識別子フィールドによって指定されるそれぞれの特殊なアルファ−カーソル平面にアルファ−カーソル画像機能パケットの機能ビットフィールドのビット２を使用してアルファ−カーソル画像オフセットパケットをサポートする能力を示す。一実施形態では、パケット長は、２バイトパケット長フィールドに示されているように１０で固定されている。一実施形態では、１３５というパケットタイプが、パケットをアルファ−カーソル画像オフセットパケットとして識別する。

２バイトアルファ−カーソルＸオフセットフィールドとＹオフセットフィールドは、それぞれメイン画像の左側と上部からのカーソル画像のピクセルのそれぞれ、一番左の列と一番上の行の水平と垂直のオフセットを指定する値を含む。ｈＣｌｉｅｎｔＩＤ−クライアントＩＤのために予約される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用のために予約され、通常は、これらビットについて論理ゼロのレベル又は値に設定される。

３５．アルファカーソルビデオストリームパケット
アルファ−カーソルビデオストリームパケットはアルファ−カーソル画像平面の矩形領域を更新するためにビデオデータを搬送する。この領域のサイズは単一のピクセルほど小さくてよい、あるいはディスプレイ全体ほど大きくてよい。アルファ−カーソルビデオストリームパケットのフォーマットは図７８に示されている。図７８に示されているように、一実施形態では、アルファ−カーソルビデオストリームパケットは、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、ビデオデータフォーマット属性フィールド、Ｘ左端縁フィールド、Ｙ上部端縁フィールド、Ｘ右端縁フィールド、Ｙ下部端縁フィールド、Ｘ開始フィールド、Ｙ開始フィールド、ピクセルカウントフィールド、パラメータＣｒｃピクセルデータフィールド、及びピクセルデータＣＲＣフィールドで構造化されている。一実施形態では、クライアントは、アルファ−カーソル画像機能パケットのアルファカーソル識別子フィールドによって指定されるそれぞれの特殊なアルファ−カーソル平面のためのアルファ−カーソル画像機能パケットを使用することにより、アルファカーソルビデオストリームパケットとその関連パラメータをサポートする能力を示し、パケットタイプフィールドの１７という値はアルファ−カーソルビデオストリームパケットであるとしてパケットを示す又は識別する。ｈＣｌｉｅｎｔＩＤフィールド（２バイト）はクライアントＩＤとしての将来の使用のために予約され、技術で十分に理解されるように当面は概してゼロに設定される。

２バイトビデオデータフォーマット記述子フィールドは、本パケットの本ストリームにピクセルデータの中の各ピクセルのフォーマットを指定する情報又は値を含む。ピクセルデータフォーマットは、アルファ−カーソル画像機能パケットに定義されるようにアルファ−カーソル画像平面の有効なフォーマットの少なくとも１つと準拠しなければならない。ビデオデータフォーマット記述子フィールドは、現在のパケット専用のピクセルフォーマットを定義する値を含み、一定のフォーマットがある特定のビデオストリームの存続期間の間使用され続けることを暗示しない。前記の図１１は、ビデオデータフォーマット記述子がどのようにしてコード化されるのかを示す。フォーマットは以下のとおりである。

一実施形態では、ビット［１５：１３］が「０００」であるときには、ビデオデータは、ピクセルあたりのビット数がビデオデータフォーマット記述子ワードのビット３から０によって定義される白黒ピクセルのアレイからなる。ビット１１から４は次にゼロに設定される。ビット［１５：１３］が「００１」であるときには、ビデオデータは、カラーマップ（パレット）を通してそれぞれが色を指定するカラーピクセルのアレイからなる。ビデオデータフォーマット記述子ワードのビット５から０はピクセルあたりのビット数を定義し、ビット１１から６はゼロに設定される。ビット［１５：１３］が「０１０」であるときには、ビデオデータは、赤のビット数がビット１１から８で定義され、緑のピクセルあたりビット数がビット７から４により定義され、青のピクセルあたりビット数がビット３から０によって定義される、未処理ＲＧＢフォーマットのカラーピクセルのアレイからなる。各ピクセルの中のビット総数は、赤、緑及び青に使用されるビット数の合計である。

ビット［１５：１３］が「０１１」であるときには、ビデオデータは、輝度とクロミナンス情報を伴う４：２：２のＹＣｂＣｒフォーマットのビデオデータのアレイからなる。輝度（Ｙ）のピクセルあたりビット数はビット１１から８で定義され、Ｃｂ成分のビット数はビット７から４で定義され、Ｃｒ成分のビット数はビット３から０で定義される。Ｃｂ成分とＣｒ成分はＹの半分の速度で送信される。このパケットのピクセルデータ部分の中のビデオサンプルはＣｂｎ、Ｙｎ、Ｃｒｎ、Ｙｎ＋１、Ｃｂｎ＋２、Ｙｎ＋２、Ｃｒｎ＋２、Ｙｎ＋３．．．のように編成され、ＣｂｎとＣｒｎはＹｎとＹｎ＋１と関連付けられ、Ｃｂｎ＋２とＣｒｎ＋２はＹｎ＋２とＹｎ＋３と関連付けられる等である。Ｙ、Ｙｎ＋１、Ｙｎ＋２、及びＹｎ＋３は、左から右へ単一行の中の４個の連続ピクセルの輝度値である。ビデオストリームパケットにより参照されるウィンドウ内の行（Ｘ右端縁−Ｘ左端縁＋１）に奇数のピクセルがある場合には、各行の中の最後のピクセルに対応するＣｂ値の後には次の行の第１のピクセルのＹ値が続く。

ＹＣｂＣｒフォーマットを使用するウィンドウは、偶数のピクセルである幅を有することが勧められる。パケットの中のピクセルデータは偶数のピクセルを含む。それは、ピクセルデータの最後のピクセルがビデオストリームパケットヘッダに指定されるウィンドウの行の最後のピクセルに相当する場合に、つまりピクセルデータの最後のピクセルのＸロケーションがＹ右端縁に等しいときに奇数又は偶数のピクセルを含んでよい。

５つすべてのフォーマットの場合、（図中「Ｐ」として示される）ビット１２は、ピクセルデータサンプルがパッキングされるかどうかを指定する。ビット１２の値が「０」であるときには、ピクセルデータフィールドの中の各ピクセルと各ピクセル内の各色がＭＤＤＩインタフェースバイト境界とバイト位置合わせされる。ビット１２の値が「１」であるときには、ピクセルデータの中の各ピクセルと各ピクセル内の各色は、ピクセル内の過去のピクセル又は色に対照してパッキングされ、未処理のビットを残さない。

一実施形態では、ピクセルデータ属性フィールド（２バイト）は、以下に示すように解釈される一連のビット値を有する。ビット１と０は、表示ピクセルデータがどのようにして送られるのかを選択する。「１１」というビット値の場合、データは両目に、又は両目のために表示され、ビット値「１０」の場合、データは左目だけに送られ、ビット値「０１」の場合、データは右目だけに送られる。

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

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

ピクセルデータ属性フィールドにおけるビット５は、ＭＤＤインタフェースの将来の使用又は応用例のために予約されているため、通常はゼロ値つまり「０」に設定されている。

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

一実施形態では、２バイトのＸ開始フィールドとＹ開始フィールドがピクセルデータフィールドの第１のピクセルのための点（Ｘ開始、Ｙ開始）の絶対Ｘ座標とＹ座標を指定する。Ｘ右端縁フィールドとＹ下部端縁フィールドが更新中のアルファ−カーソル画像ウィンドウの右端縁のＸ座標と、下部端縁のＹ座標を指定するが、２バイトのＸ左端縁フィールドとＹ上部端縁フィールドはピクセルデータフィールドによって充填されるアルファ−カーソル画像ウィンドウの左端縁のＸ座標と上端縁のＹ座標を指定する。

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

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

ピクセルデータフィールドは、表示されなければならない、及びビデオデータフォーマット記述子フィールドによって説明されるようにフォーマットされる未処理のビデオ情報を含む。データは、他の箇所で説明されるように、一度に１「行」ずつ送信される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一つの実施形態では、２バイトのピクセルデータ属性フィールドは、以下のとおりに解釈される値を有する。ビット１とビット０は、ピクセルデータが送られるディスプレイを選択する。「１１」又は「００」のビット値の場合、ピクセルデータは両目に又は両目のために表示される。ビット値「１０」の場合、ピクセルデータは左目だけに送られる。ビット値「０１」の場合、ピクセルデータは右目だけに送られる。

ビット２は、ピクセルデータがインタレースフォーマットを取っているかどうかを示す。ビット２が０であるときには、ピクセルデータは標準漸次フォーマットを取っている。行番号（ピクセルＹ座標）は、ある行から次の行に進むと１増分される。ビット２が１であるときには、ピクセルデータはインタレースフォーマットとなる。行番号（ピクセルＹ座標）は、ある行から次の行に進むと２増分される。

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

ビット４は、ピクセルデータがディスプレイに関係するのか、あるいはカメラに関係するのかを示す。ビット４が０であるとき、ピクセルデータはディスプレイフレームバッファへ、又はディスプレイフレームバッファからである。ビット４が１であるとき、ピクセルデータはカメラへ、又はカメラからである。ビット５は、将来の使用のために予約されているため、通常はゼロに設定される。

ビット７と６は、ピクセルデータが書き込まれるべきフレームバッファを指定する表示更新ビットである。フレーム更新ビットの効果は他の箇所にさらに詳しく説明されている。ビット［７：６］が「０１」であるとき、ピクセルデータはオフライン画像バッファに書き込まれる。ビット［７：６］が「００」であるとき、ピクセルデータはディスプレイをリフレッシュするために使用される画像バッファに書き込まれる。ビット［７］６］が「１１」であるとき、ピクセルデータはすべての画像バッファに書き込まれる。ビット［７：６］が「１０」であるとき、これは無効値として処理される。これらのビットは現在将来の使用のために予約されている。この状況では、ピクセルデータは無視され、画像バッファのどれにも書き込まれないであろう。

ビット８から１５は、将来の使用のために予約されており、一般に、論理ゼロのレベル又は値に設定される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

４２．パケット処理遅延パラメータパケット
パケット処理遅延パラメータパケットは、ホストが特定のパケットタイプの受信に関連した処理を完了するために要する時間を計算できるようにするためのパラメータのセットを提供する。ホストにより送信されるいくつかのコマンドはゼロ時間内にクライアントによって完了することはできない。ホストは特定の機能がクライアントによって完了されたかどうかを判断するためにクライアント要求及びステータスパケットでステータスビットをポーリングしてよいか、あるいはホストはパケット処理遅延パラメータパケットでクライアントにより返されるパラメータを使用して完了時間を計算してよい。クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの１４０というパラメータ値を使用してパケット処理遅延パラメータパケットをサポートする能力を示すことができる。

パケット処理遅延パラメータパケットの一実施形態のフォーマットは図８５Ａに一般的に示されている。図８５Ａで分かるように、パケット処理遅延パラメータパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、リストアイテム数フィールド、遅延パラメータリストフィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットのパケット長は通常１０という値で固定され、１４０というタイプ値はパケット処理遅延パラメータパケットとしてパケットを識別する。ｃＣｌｉｅｎｔＩＤフィールドはクライアントＩＤとしての将来の使用に予約されており、通常ゼロに設定されている。２バイトのリストアイテム数フィールドは続く有効パラメータ応答リストの中のアイテムの数を指定する。

遅延パラメータリストフィールドは１つ又は複数の遅延パラメータリストアイテムを含むリストである。単一の遅延パラメータリストアイテムの一実施形態のためのフォーマットは図８５Ｂに示されており、遅延のためのパケットタイプフィールド、ピクセル遅延フィールド、水平ピクセル遅延フィールド、垂直ピクセル遅延フィールド、及び固定遅延フィールドが示されている。

各遅延パラメータリストアイテムは、通常、長さが６バイトになるように制限されており、以下に示すようにさらに定義されている。２バイトの遅延のためのパケットタイプフィールドは以下の遅延パラメータが適用するパケットタイプを指定する。ピクセル遅延フィールド（１バイト）は遅延値に対するインデックスを備える。表から読み取られる該値は、パケットの宛先フィールドのピクセル総数で乗算される。ピクセル総数はパケットによって参照されるビットマップの宛先領域の幅×高さである。１バイトの水平ピクセル遅延フィールドは、遅延値表（ＤＰＶＬと同じ表）に対するインデックスである値を含む。表から読み取られる値はパケットの宛先フィールドの（ピクセル単位の）幅で乗算される。１バイトの垂直ピクセル遅延フィールドは、遅延値表（一般に、ＤＰＶＬと同じ表を用いる）に対するインデックスである値を含む。表から読み取られる値はパケットの宛先フィールドの（ピクセル単位の）高さで乗算される。

固定遅延フィールドは、遅延値表（ＤＰＶＬと同じ表）に対するインデックスとして１バイトを使用する。表から読み取られる値は、パケットに指定されているあらゆるパラメータ値に無関係であるパケットを処理するために要する時間を表す固定遅延パラメータである。総遅延、つまりパケット処理完了時間遅延は以下の関係性に従って求められる。

遅延＝（ＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＤｅｌａｙ（ＰｉｘｅｌＤｅｌａｙ）・ＴｏｔａｌＰｉｘｅｌｓ）＋
（ＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＤｅｌａｙ（ＨｏｒｉｚｏｎｔａｌＰｉｘｅｌＤｅｌａｙ）・Ｗｉｄｔｈ）＋
（ＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＤｅｌａｙ（ＶｅｒｔｉｃａｌＰｉｘｅｌＤｅｌａｙ）・Ｈｅｉｇｈｔ）＋ＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＤｅｌａｙ（ＦｉｘｅｄＤｅｌａｙ）
いくつかのパケットの場合、ピクセル合計、幅又は高さは、それらのパラメータが対応するパケットで参照されないために適用しない。それらのケースでは対応するピクセル遅延パラメータは通常ゼロに設定されている。

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

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

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

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

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

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

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

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

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

２バイト光学機能フラグフィールドはディスプレイの光学機能を指定する多様なフィールドを含む。これらのビット値は、通常、以下に従って割り当てられている。

ビット１５から５は将来の使用のために受信され、一般に、論理ゼロ状態に設定される。

ビット４はメガネ焦点調整を選択し、「０」という値はディスプレイにメガネ焦点調整がないことを意味し、「１」という値はディスプレイがメガネ焦点調整を有することを意味する。

ビット３から２は、以下に従って両眼機能を選択する。０という値は、ディスプレイが両眼用であり、２次元（２Ｄ）画像だけを表示できることを意味し、１は、ディスプレイが両眼用であり、３次元（３Ｄ）画像を表示できることを意味し、２は、ディスプレイが単眼用であることを意味し、３は将来の使用のために予約されている。

ビット１から０は、左右像面湾曲対称を選択し、０という値は像面湾曲が定義されていないことを意味する。このフィールドがゼロである場合には、Ａ１からＥ５までのすべての像面湾曲値は、点Ｃ３を除きゼロに設定され、ディスプレイの焦点距離を指定するか、あるいはゼロに設定され、焦点距離が指定されていないことを示す。１という値は左右のディスプレイが同じ対称性を有することを意味する。２は、左右のディスプレイが垂直軸（列Ｃ）でミラーリングされていることを意味し、３は将来の使用のために予約されている。

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

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

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

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

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

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

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

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

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

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

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

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

４６．代替ディスプレイ機能パケット
代替ディスプレイ機能パケットは、ＭＤＤＩクライアントコントローラに取り付けられる代替ディスプレイの機能を示す。それは特殊ステータス要求パケットに応えて送信される。プロンプトを出されると、クライアントデバイスは、サポートされている代替ディスプレイごとに代替ディスプレイ機能パケットを送信する。クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４５というパラメータ値を介して代替ディスプレイ機能パケットを送信する能力を示すことができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

２バイトの読み取り／書き込みフラグフィールドは、書き込み又は読み取り、あるいは読み取りに対する応答のどちらかとして特定のパケットを指定し、データ値のカウントを提供する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ハイバーネーション状態の間、ＭＤＤＩ＿ＤａｔａとＭＤＤＩ＿Ｓｔｂとの差分ドライバがディスエーブルされ、全ての差分ペアの間の差分電圧はゼロボルトである。ハイバーネーションからのウェイクアップの間にパルスのシーケンスを検出するために使用される差分ライン受信機は、意図的な電圧オフセットを持っている。一つの実施形態では、これら受信機における論理１レベルと論理０レベルとの間の閾値は、約１２５ｍＶである。これは、リンクウェイクアップシーケンスの間、論理ゼロレベルとして見られる駆動されない差分ペアをもたらす。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｃ．データ−ストローブタイミング逆方向リンク
クライアントドライバ出力から逆方向リンクでデータを転送するために使用されるデータ信号とストローブ信号の切り替え特性及びタイミング関係は、図４７と図４８に示されている。特定の信号遷移のための適切な時間は後述される。図４７は、転送されているデータのタイミングとストローブパルスの前縁と後縁の間のホストレシーバ入力での関係性を示している。すなわち、ストローブ信号の立ち上がり又は前縁のためのセットアップ時間、ｔ_{ｓｕ−ｓｒ}、及びストローブ信号の立ち下り又は後縁のためのセットアップ時間、ｔ_{ｓｕ−ｓｆ}と呼ばれるものである。これらのセットアップ期間の典型的な時間の長さは最小約８ナノ秒である。

図４８は、切り替え特性、及び逆方向データタイミングにより展開される対応するクライアント出力遅延を示す。図４８では、転送されているデータのタイミングと、誘発された遅延の説明をするストローブパルスの前縁と後縁との間の関係性を見ることができる。つまり、ストローブ信号の立ち上がり又は前縁とデータ（有効）の間の伝搬遅延、ｔｐｄ−ｓｒと、データと後縁又は立ち下がりの間の伝搬遅延、ｔｐｄ−ｓｆと呼ばれるものである。これらの伝搬遅延期間の典型的な最大時間長は、約８ナノ秒である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＸＩ．方向転換及びガード時間
前述されたように、逆方向リンクカプセル化パケットの中の方向転換１フィールドと往復遅延測定パケットの中のガード時間１フィールドは、クライアントインタフェースドライバがイネーブルされる前に、ホストインタフェースドライバをディスエーブルできる時間の長さの値を指定する。方向転換２フィールドとガード時間２フィールドは、ホストドライバがイネーブルされる前にクライアントドライバをディスエーブルできるようにする時間値を提供する。ガード時間１フィールドとガード時間２フィールドは、通常、調整されるように意図されていない長さの事前に設定された又は事前に選択された値で充填されている。使用されているインタフェースハードウェアに応じて、これらの値は経験的データを使用して作成され、いくつかの例では動作を改善するために調整されてよい。

複数の要因が方向転換１の長さの決定に寄与し、これらは順方向リンクデータレート、及びホスト内のＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間である。最大ホストドライバディスエーブル時間は、それがドライバがディスエーブルするための最大約１０ｓｅｃを要し、イネーブルするのに約２ｎｓｅｃを要することを示している表ＸＩに指定されている。ホストドライバがディスエーブルされるために必要とされる順方向リンククロックの最小数は、以下の関係性に従って表現される。

方向転換１の許可された値範囲は、以下の関係性に従って表現され、

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

前記から２つの方程式を結合すると、インタフェースタイプ因数の項は相殺し、方向転換１は以下のように定義される。

例えば、１５００Ｍｂｐｓの３型の順方向リンクは以下の方向転換１遅延を使用するであろう。

往復遅延が増加するにつれて、タイミングマージンは、ホストがディスエーブルされる時点から、クライアントがイネーブルされる点まで改善する。

方向転換２に通常使用される時間の長さを決定する要因は順方向リンクデータレート、クライアント内のＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間、及び通信リンクの往復遅延である。クライアントドライバをディスエーブルするために必要とされる時間の計算は、本来前述されたホストドライバと同じであり、以下の関係性に従って定められ、

方向転換２の許容される値範囲は以下のように表される。

例えば、１０順方向リンククロックという往復遅延のある１５００ＭＢｐｓ３型順方向リンクは、通常、ほぼ以下の方向転換２遅延を使用する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

によって指定される。

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

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

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

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

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

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

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

であり、以下を考えれば

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

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

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

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

である。

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

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

図５９に示す例では、

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

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

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

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

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

である。

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

のように定義される。一方、内部モードのクライアントデバイスにおける設定時間、遅延非対称、及び遅延歪みのための典型的な合計遅延時間は、

である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＸＶＩＩ．遅延値表
パケット処理遅延パラメータパケットは、クライアント内で特定のコマンドを処理するために予測される遅延を計算するためにテーブルルックアップ機能を使用する。表の中の値は遅延値の非常に幅広い動的範囲を提供するために対数的に増加する。本発明の実施形態を実現するために有効な遅延値の例示的な表は、対応する指数値対遅延値と共に以下の表ＸＸに記載される。

遅延は、指定されたパラメータを表のインデックスとして使用してテーブルルックアップを実行することにより計算される。つまり、遅延はＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＴａｂｌｅ（ｉｎｄｅｘ）に等しい。例えば、遅延パラメータリストアイテムからのパラメータの１つが１３４に等しい８ビット値である場合には、遅延は１６μｓｅｃであるＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＴａｂｌｅ（１３４）に等しい。値２５５は、コマンド完了時間を計算で求めることができず、ホストがクライアント要求及びステータスパケットのグラフィックスビジーフラグ、又はＭＣＣＳＶＣＰ制御パラメータＢ７ｈをチェックするであろうことを示している。

いくつかの場合には、この遅延は、宛先画像の高さ、幅又はピクセル数で乗算され、全体的なパケット処理遅延を計算するために他の遅延に加算される。

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

複数のクライアントを有するシステムでは、図９８に示されるように、クライアントのデイジーチェーンを使用して、又はハブを使用して、あるいは図９９に示されるようにこれらの技法の組み合わせを使用してクライアントがホストに接続されるのが有用である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

方向転換２長フィールド（１バイト）は、第２の方向転換期間を確立するために方向転換２に割り当てられるバイトの総数を指定する。方向転換長パラメータにより指定されたバイト数は、クライアントのラインドライバがディスエーブルされる前に、ホストのＭＤＤＩ＿Ｄａｔａラインドライバがイネーブルできるようにするために割り当てられる。ホストは、方向転換２の第１のバイトのビット０の間にそのＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルし、クライアントは方向転換２の最後のビットの前にそれらが一般に完全にディスエーブルされるようにその出力をディスエーブルする。クライアントドライバをディスエーブルし、ホストドライバプロセスをイネーブルするタイミングは、ホストのラインレシーバによって見られるように、方向転換２を通して、あるいは実質的に方向転換２全体の間、ＭＤＤＩ＿Ｄａｔａ信号を論理ゼロレベルの１つ又は両方を駆動するほどである。ＭＤＤＩ＿Ｓｔｂ信号は、方向転換２期間全体でＭＤＤＩ＿Ｄａｔａ０が論理ゼロレベルであるかのように動作する。方向転換２の設定の説明は前述されている。

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

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

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

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

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

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

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

カラーマップ機能フィールド（３バイト）は、ディスプレイのカラーマップテーブルに存在するテーブルアイテムの最大数を指定する。ディスプレイがカラーマップフォーマットを使用できない場合は、この値はゼロに設定される。

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

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

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

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

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

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

ビット２１の値は、クライアントが、要求特有ステータスパケットを解釈し、有効ステータス応答リストパケットを用いて応答する能力を持っている場合を示す。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストフィールドの追加ステータスへ戻る能力を示す。

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

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

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

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

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

最小サブフレームレートフィールド（２バイト）は、毎秒フレーム単位で最小サブフレームレートを指定する。最小サブフレームレートは、クライアントステータス更新レートをクライアント内の特定のセンサ又はポインティングデバイスを読み取るのに十分に保つ。

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

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

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

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

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

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

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

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

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

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

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

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

一つの実施形態では、これらのバイトは、次の関係に従って解釈される。すなわち、もしもビット０が‘１’であれば、ビットマップブロック転送機能がビジーとなる。一方、ビット１が‘１’であれば、ビットマップ領域塗りつぶし機能がビジーとなる。もしもビット２が‘１’であれば、ビットマップパターン塗りつぶし機能がビジーとなる。今のところ、ビット３から１５は、将来の使用のために予約され、これらのビットが将来割り当てられた場合に、ビジーステータスを示すために、一般に、論理１レベル又は状態に設定される。

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

Ｉ．ビットマップ領域塗りつぶしパケット
ウィンドウ左上座標Ｘ値フィールドとＹ値フィールドは、塗りつぶすウィンドウの左上角の座標のＸ値とＹ値を指定するためにそれぞれ２バイトを使用する。ウィンドウ幅フィールドとウィンドウ高さフィールド（各２バイト）は、塗りつぶされるウィンドウの幅と高さを指定する。ビデオデータフォーマット記述子フィールド（２バイト）は、ピクセル領域塗りつぶし値のフォーマットを指定する。フォーマットはビデオストリームパケット内の同じフィールドと同じである。ピクセル領域塗りつぶし値フィールド（４バイト）は、前述されたフィールドによって指定されたウィンドウの中に充填されるピクセル値を含む。このピクセルのフォーマットは、ビデオデータフォーマット記述子フィールドに指定される。

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

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

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

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

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

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

Ｌ．インタフェースハンドオフ要求パケットの場合
インタフェースタイプフィールド（１バイト）は使用する新しいインタフェースタイプを指定する。このフィールドの値は以下のようにインタフェースタイプを指定する。ビット７の値が「０」に等しい場合、タイプハンドオフ要求は順方向リンク向けであり、それが「１」に等しい場合は、タイプハンドオフ要求は逆方向リンク向けである。ビット６から３は、将来の使用のために予約されており、通常はゼロに設定されている。ビット２から０は、使用されるインタフェースタイプを定義するために使用され、１という値は、１型モードへのハンドオフ、２という値は２型モードへのハンドオフ、３という値は３型モードへのハンドオフ、及び４という値は４型モードへのハンドオフを意味する。「０」及び５から７という値は代替モード又はモードの組み合わせの将来の指定のために予約されている。

Ｍ．インタフェースタイプ肯定応答パケット
インタフェースタイプフィールド（１バイト）は、使用する新しいインタフェースタイプを確認する値を有する。このフィールドの値は、以下のようにインタフェースタイプを指定する。ビット７が「０」に等しい場合、タイプハンドオフ要求は順方向リンク向けであり、変わりにそれが「１」に等しい場合は、タイプハンドオフ要求は逆方向リンク向けである。ビット位置６から３は現在所望されるように他のハンドオフタイプを指定する際に使用するために予約されており、通常ゼロに設定されている。ただし、ビット位置２から０は、負の肯定応答、あるいは要求されたハンドオフが実行できないことを示す「０」という値と共に使用するためのインタフェースタイプを定義するために使用され、「１」、「２」、「３」及び「４」という値は、それぞれ１型モード、２型モード、３型モード及び４型モードへのハンドオフを示す。５から７という値は所望されるようにモードの代替指定と使用するために予約されている。

Ｎ．実行型ハンドオフパケット
１バイトのインタフェースタイプフィールドは、使用する新しいインタフェースタイプを示す。このフィールドに存在する値は、タイプハンドオフが順方向リンク向けであるのか、それとも逆方向リンク向けであるのかを判断するために、最初にビット７という値を使用することによってインタフェースタイプを指定する。「０」という値は、タイプハンドオフ要求が順方向リンク向けであることを示し、「１」という値は逆方向リンクを示す。ビット６から３は、将来の使用のために予約され、通常はゼロという値に設定されている。ただし、ビット２から０は、使用されるインタフェースタイプを定義するために使用され、値１、２、３及び４はそれぞれ１型モード、２型モード、３型モード、及び４型モードへのハンドオフの使用を指定する。これらのビットに対する値０と５から７の使用は将来の使用に予約されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全てゼロの１フィールドは、パラメータＣＲＣフィールドの終わりにおいて、ＭＤＤＩ＿Ｓｔｂ上の遷移があることを保証するために、１バイトを用いる。

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

１型−（６４バイトデータシーケンス）０ｘａａ，０ｘａａ，・・・又は０ｘ５５，０ｘ５５・・・
２型−（１２８バイトデータシーケンス）０ｘｃｃ，０ｘｃｃ，・・・又は０ｘ３３，０ｘ３３・・・
３型−（２５６バイトデータシーケンス）０ｘｆ０，０ｘｆ０，・・・又は０ｘ０ｆ，０ｘ０ｆ・・・
４型−（５１２バイトデータシーケンス）０ｘｆｆ，０ｘ００，０ｘｆｆ，０ｘ００・・・又は０ｘ００，０ｘｆｆ，０ｘ００，０ｘｆｆ・・・
１型インタフェースと２型インタフェース両方のためのＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形の例は、それぞれ図６２Ａと図６２Ｂに示されている。

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

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

Claims

通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルプレゼンテーションデータを転送するためのデジタルデータインタフェースであって、
前記通信経路上、ホストとクライアント間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するための通信プロトコルを形成するために、共にリンクされる複数のパケット構造と、
前記通信経路を通って前記クライアントに結合され、前記通信プロトコルを形成するパケットを生成、送信、及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、前記ホストデバイスに常駐する少なくとも１台のリンクコントローラと、
を備える、デジタルデータインタフェース。
前記ホストとクライアントの間で通信され、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有する、メディアフレーム内で共にグループ化される前記パケットをさらに備える、請求項１に記載のインタフェース。
前記ホストからのパケットの転送の始めに配置されるサブフレームヘッダパケットをさらに備える、請求項１に記載のインタフェース。
前記リンクコントローラはホストリンクコントローラであって、前記通信経路を通って前記ホストに結合される前記クライアントデバイスに常駐する少なくとも１台のクライアントリンクコントローラをさらに備え、前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、請求項１に記載のインタフェース。
それぞれが既定の期間に並列でデータの異なる最大数のビットの転送を可能にする複数の転送モードであって、各モードが前記ホストリンクドライバとクライアントリンクドライバの間の交渉により選択可能である、複数の転送モードをさらに備え、
前記転送モードはデータの転送中に前記モードの間で動的に調整可能である、
請求項２に記載のインタフェース。
前記通信経路上、どちらかの方向でデータの転送を終了するために、前記ホストによる前記クライアントに対する伝送のためのリンクシャットダウンタイプパケットをさらに備える、請求項１に記載のインタフェース。
前記クライアントがハイバネーション状態から前記ホストをスリープ解除するための手段をさらに備える、請求項１に記載のインタフェース。
ユーザへのプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において高速でデジタルデータを転送する方法であって、
複数の所定のパケット構造の内の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクすることと、
前記通信プロトコルを使用して、前記通信経路上、前記ホストと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信することと、
前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、前記ホストデバイスに常駐する少なくとも１台のホストリンクコントローラを、前記通信経路を通して前記クライアントデバイスに結合することと、
前記リンクコントローラを使用して前記通信経路上でパケットの形を取るデータを転送することと、
を備える、方法。
前記ホストとクライアント間の通信のために、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有するメディアフレーム内で、前記パケットを共にグループ化することをさらに備える、請求項８に記載の方法。
サブフレームヘッダタイプパケットを用いる前記ホストからのパケットの転送を開始することをさらに備える、請求項８に記載の方法。
前記通信経路を通して前記ホストデバイスに結合された前記クライアントデバイスに常駐する少なくとも１台のクライアントリンクコントローラを通じて前記通信プロトコルを形成するパケットを生成し、送信し、受信することをさらに備える、請求項８に記載の方法。
ホストリンクドライバとクライアントリンクドライバの間で、それぞれが既定の期間において並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つの使用を交渉することと、
データの転送中、前記転送モードの間で動的に調整することと、
をさらに備える、請求項１１に記載の方法。
前記クライアントへの前記ホストによる伝送のために、リンクシャットダウンタイプのパケットを使用して前記通信経路においてどちらかの方向でデータの転送を終了することをさらに備える、請求項８に記載の方法。
前記クライアントとの通信によりハイバネーション状態から前記ホストをスリープ解除することをさらに備える、請求項８に記載の方法。
ユーザへのプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において高速でデジタルデータを転送するための装置であって、
複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするために、及び前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するために、前記ホストデバイス内に配置される少なくとも１台のホストリンクコントローラと、
前記クライアントデバイスに配置され、前記通信経路を通して前記ホストリンクコントローラに結合される、少なくとも１台のクライアントコントローラと、
前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、各リンクコントローラと、
を備える、装置。
前記ホストコントローラは状態機械を備える、請求項１５に記載の装置。
前記ホストコントローラは汎用信号プロセッサを備える、請求項１５に記載の装置。
前記ホストからのパケットの転送の開始時にサブフレームヘッダタイプパケットをさらに備える、請求項１５に記載の装置。
前記ホストコントローラは１台又は複数台の差動ラインドライバを備え、前記クライアントレシーバは前記通信経路に結合される１台又は複数台の差動ラインレシーバを備える、請求項１５に記載の装置。
前記ホストリンクコントローラとクライアントリンクコントローラは、それぞれが既定の期間において、並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つを使用するように構成され、データの転送中、前記転送モードの間で動的に調整することができる、請求項１５に記載の装置。
前記ホストコントローラは、前記通信経路上、どちらかの方向でデータの転送を終了するために、前記クライアント手段にリンクシャットダウンタイプのパケットを送信するように構成される、請求項１５に記載の装置。
ユーザに対するプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための電子システムでの使用のために、
アプリケーションプログラムを前記コンピュータシステム上で実行させるために、前記媒体で具現化されるコンピュータ読み取り可能プログラムコード手段を有するコンピュータ使用可能な媒体を備える、コンピュータプログラム製品であって、前記コンピュータ読み取り可能プログラムコード手段は、
コンピュータシステムに複数の所定のパケット構造の１つ又は複数を生成させ、所定の通信プロトコルを形成するために、それらを共にリンクさせるためのコンピュータ読み取り可能第１プログラムコード手段と、
前記コンピュータシステムに、前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信させるための、コンピュータ読み取り可能第２プログラムコード手段と、
前記コンピュータシステムに、前記通信経路を通して、前記ホストデバイスに配置される少なくとも１台のホストリンクコントローラを、前記クライアントデバイスに配置される少なくとも１台のクライアントコントローラに結合させるようにするための、コンピュータ読み取り可能第３プログラムコード手段であって、前記リンクコントローラは、前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、コンピュータ読み取り可能第３プログラムコード手段と、
前記リンクコントローラを使用して前記通信経路上、パケットの形をしたデータをコンピュータシステムに転送させるためのコンピュータ読み取り可能第４プログラムコード手段と、
を備える、コンピュータプログラム製品。
ユーザに対するプレゼンテーションのために、通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための装置であって、
複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするための手段と、
前記通信プロトコルを使用して前記通信経路で前記ホストデバイスと前記クライアントデバイスの間で、事前に選択されたデジタル制御データ及びデジタルプレゼンテーションデータを通信するための手段と、
前記ホストとクライアントのそれぞれに１つ、それぞれが前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、少なくとも２台のリンクコントローラを、前記通信経路を通して共に結合するための手段と、
前記リンクコントローラを使用して前記通信経路上、パケットの形をとるデータを転送するための手段と、
を備える、装置。
サブフレームヘッダタイプパケットを用いて、前記ホストからパケットの転送を開始するための手段をさらに備える、請求項２３に記載の装置。
前記クライアントが前記インタフェースを通してどのようなタイプのデータとデータレートに対処できるのかを決定するために、ホストリンクコントローラによってクライアントから表示機能情報を要求するための手段をさらに備える、請求項２３に記載の装置。
通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための電子システムで使用するためのプロセッサであって、複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクし、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成し、前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信し、前記通信経路上でパケットの形をしたデータを転送するように構成された、プロセッサ。
通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送する電子システム内で同期を取る際に使用するための状態機械であって、少なくとも１つの非同期フレーム状態同期状態、少なくとも２つの同期状態獲得同期状態、及び少なくとも３つの同期中状態同期状態を有するように構成される、状態機械。
通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送する電子システム内で同期を取る際に使用するための状態機械であって、少なくとも１つの同期状態獲得動機状態と、少なくとも２つの同期中状態同期状態とを有するように構成される、状態機械。
同期状態獲得と第１同期中状態の間でシフトするための１つの条件が、前記通信リンク内で同期パターンの存在を検出することである、請求項２８に記載の状態機械。
同期状態獲得と第１同期中状態の間でシフトするための第２の条件が、サブフレームヘッダパケットの存在及びフレーム境界での良好なＣＲＣ値を検出することである、請求項２８に記載の状態機械。
第１同期中状態と同期状態獲得の間でシフトするための１つの条件が、同期パターンなしの存在及びサブフレーム境界での不良なＣＲＣ値を検出することである、請求項２８に記載の状態機械。
第１の同期中状態と第２の同期中状態の間でシフトするための１つの条件が、同期パターンなしの存在及びサブフレーム境界での不良なＣＲＣ値を検出することである、請求項２８に記載の状態機械。
前記ホストにより、少なくとも１０クロックサイクルの間、データラインを高状態に駆動し、前記データラインがゼロであるかのようにストローブ信号の送信を開始することによって、通信リンクをスリープ解除することをさらに備える、請求項１２に記載の方法。
ホストが１５０クロックサイクルの間、前記データラインを高に駆動した後に、ストローブ信号の送信を続けながら、前記ホストにより予め定めたクロックサイクルの間、前記データラインを低に駆動することをさらに備える、請求項３３に記載の方法。
前記ホストにより、前記第１のサブフレームヘッダパケットの送信を開始することをさらに備える、請求項３３に記載の方法。
前記クライアントにより、低である前記データラインの少なくとも５０の連続クロックサイクルが後に続く、高である前記データラインの少なくとも１５０の連続クロックサイクルをカウントすることをさらに備える、請求項３４に記載の方法。
前記クライアントが、高である前記データの７０の連続クロックサイクルをカウントした後、前記クライアントによって前記データラインを高に駆動することを停止することをさらに備える、請求項３４に記載の方法。
前記クライアントにより高である前記データラインの前記１５０クロックサイクルに到達するために、高である前記データラインの別の８０の連続クロックサイクルをカウントすることと、低である前記データラインの５０クロックサイクルを探すことと、前記一意のワードを探すこととをさらに備える、請求項３７に記載の方法。
前記逆方向タイミングパケットの間に立ち上がりと立ち下り両方で前記データラインをサンプリングすることによって、前記ホストにより１つがサンプリングされるまで発生するクロックサイクルの数をカウントすることとをさらに備える、請求項１２に記載の方法。