JP2011066904A

JP2011066904A - さらに高速なデータレート用の信号インタフェース

Info

Publication number: JP2011066904A
Application number: JP2010230760A
Authority: JP
Inventors: Jon James Anderson; ジョン・ジェームス・アンダーソン; Brian Steele; ブライアン・スティール; George Alan Wiley; ジョージ・アラン・ウィレイ; Shashank Shekhar; シャシャンク・シェカー
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2003-08-13
Filing date: 2010-10-13
Publication date: 2011-03-31
Anticipated expiration: 2024-08-12
Also published as: EP2363992A1; JP5705901B2; JP2014195288A; CN101194482A; WO2005018191A2; JP5356353B2; JP2013158026A; JP2012217189A; EP2363989B1; KR101070209B1; JP2007507918A; TWI455539B; CA2535438C; US8705571B2; EP2393254A2; JP5575835B2; EP2363990A1; CN101194482B; KR101178080B1; TW200525964A

Abstract

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

Description

（関連出願の相互参照）
本特許出願は、本譲受人に委譲され、参照してここに明示的に組み込まれる、２００３年８月１３日に出願された「ＭＤＤＩ仕様促進策（ＭＤＤＩＳｐｅｃｉｆｉｃａｔｉｏｎＡｄｖａｎｃｅｍｅｎｔｓ）」と題される特許仮出願第６０／４９４，９８３号に対する優先権を主張する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

出願人は、本発明の譲受人に委譲され、参照してここに組み込まれる、現在許可されている、ともに「高速データレート信号転送のための通信プロトコル及びインタフェースを作成し、実現すること（ＧｅｎｅｒａｔｉｎｇＡｎｄＩｍｐｌｅｍｅｎｔｉｎｇＡＣｏｍｍｕｎｉｃａｔｉｏｎＰｒｏｔｏｃｏｌＡｎｄＩｎｔｅｒｆａｃｅＦｏｒＨｉｇｈＤａｔａＲａｔｅＳｉｇｎａｌＴｒａｎｓｆｅｒ）」と題される米国特許出願第１０／０２０，５２０号及び第１０／２３６，６５７号でこのような新しい転送機構を提案した。それらの出願で説明されている技法は、高速データ信号の中の大量のデータのための転送速度を大幅に改善できる。しかしながら、特にビデオプレゼンテーションに関して増加の一途を辿るデータレートに対する需要は伸び続ける。データ信号技術における他の継続中の開発をもってしても、依然としてなおさらに高速の転送速度、通信リンク効率の改善、より強力な通信リンクを目指して努力する必要がある。したがって、ホストデバイスとクライアントデバイスの間のデータスループットを高めるために必要とされる新しい、あるいは改善された転送機構を開発する継続するニーズがある。

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

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

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

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

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

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

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

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

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

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

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

本発明の多様な実施形態の構造及び動作だけではなく本発明の更なる特徴及び利点も、添付図面を参照して以下に詳細に説明する。図中、類似する参照番号は通常同一の、機能上類似した、及び／又は構造上類似した要素又は処理ステップを示し、要素が最初に表示される図面は参照番号の左端の数字（複数の場合がある）で示される。

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

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

本発明の実施形態の利点は、非常に柔軟である一方で複雑度が低く、低価格で、信頼性が高く、使用環境内によく適合し、非常にロバストであるデータ転送のための技法が提供される点である。

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

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

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

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

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

これにより、より複雑な又は「リッチ」なデータの表示は、決して有効又は楽しめる経験にはならない。したがって、業界は、エンドユーザに情報を提示するため、及び所望される楽しみの最小レベルつまり好ましい経験を与えるために、他の機構とデバイスを開発中である。

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

別のユーザに、又は代わりに信号を他のどこかに転送するか、それらを記憶する別のデバイスに出力を提示するための無線装置１０２又はコンピュータ１００の使用に関係がある、あるいは対応する追加の要素がある場合がある。例えば、データは後で使用するために、フラッシュメモリに、光形式で、例えば書き込み可能ＣＤ媒体を使用して、又は磁気テープレコーダと類似するデバイス内でのような磁気媒体上で記憶されてよい。

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

音声再生を支援するために、サブウーファー、つまりフロントサウンドプロジェクションとリアサウンドプロジェクション用の「サラウンドサウンド」スピーカなどの追加要素も付随できるであろう外部スピーカ１１４が図１ａに図示される。同時に、スピーカ又はイヤホン１０８が図１ｂのマイクロディスプレイデバイス１０６のサポートフレーム又は機構に内蔵されると示されている。理解されるように、電力増幅装置又は音声整形装置を含む他の音声又はサウンド再生要素が使用できる。

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

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

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

図１Ｃ及び図１Ｄでは、全体的な電子デバイス又は製品の小さい断面図が、今日のエレクトロニクス業界全体で使用されている何らかの公知のタイプの回転式ジョイントを横切って、対応するクライアントを有するビデオ表示要素又は画面にそれらを接続する、汎用通信リンク、ここではそれぞれ１３８と１４８のある、デバイスの一部分における１つ又は複数の内部ホスト及びコントローラの位置を示すために使用される。これらの転送に関与するデータの量は、多数の導体がリンク１３８と１４８を備えることを必要とすることが分かる。このような通信リンクが、並列又はこのようなデータを転送するために使用可能な他の公知のインタフェース技法のタイプのための、このようなデバイス上で高度な色とグラフィックインタフェース、表示要素を活用するために今日の高まりつつあるニーズを満たすために９０以上の導体に近づきつつあることが推定される。

残念なことに、単位時間あたりで転送されることを必要とするデータの未処理量に関して、信頼できる費用効果の高い物理的な転送機構を製造することに関しての両方で、より高速のデータレートはデータを転送するために使用できる現在の技術を越えている。

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

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

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

前述されたように、ホストは本発明を使用することから恩恵を得ることができる複数の種類のデバイスの内の１つを備える。例えば、ホスト２０２は、ハンドヘルド、ラップトップ、又は類似したモバイルコンピューティングデバイスの形を取るポータブルコンピュータであり、それはパーソナルデータアシスタント（ＰＤＡ）、ページングデバイス、又は多くの無線電話又はモデムの内の１つであろう。代わりにホスト２０２は、ポータブルＤＶＤ又はＣＤプレーヤ、又はゲーム機等のポータブルエンターテインメントデバイス又はプレゼンテーションデバイスであろう。

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

同時に、クライアント２０４はエンドユーザに情報を提示する、あるいはユーザからホストに情報を提示するために有効な種々のデバイスを備えることができるであろう。例えば、ゴーグル又は眼鏡に組み込まれるマイクロディスプレイ、帽子又はヘルメットの中に内蔵される映写装置、又はウィンドウ又はフロントガラスなどの車両に内蔵される小さい画面又はホログラフィック素子、又は高品質のサウンド又は音楽を提示するための多様なスピーカ、ヘッドフォン、又はサウンドシステム。別の例は、ユーザからの接触又はサウンド以外にほとんど実際の「入力」がない、相当量の情報をユーザから転送することを望む可能性があるタッチパッド又は敏感なデバイス、音声認識入力装置、セキュリティスキャナ等の使用であろう。

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

本発明のＭＤＤインタフェース及び通信信号プロトコルは、外部要素（外部モード）だけではなく、これらの接続の費用を削減し、信頼性を改善するために、ホストプロセッサとデバイス内のディスプレイ（内蔵モード）の間の相互接続をさらに簡略化するために使用されてよい。このインタフェース構造によって使用される各信号ペアの総計シリアルリンクデータレートは、何桁にも渡って変化することがあリ、システム又はデバイス設計者が、費用、電力、インプリメンテーションの複雑度、表示更新速度を容易に最適化できるようにする。ＭＤＤＩの属性は表示技術と無関係である。該インタフェースを介して転送されるデータパケットのタイミングは、特定の表示装置の特異性、又は音声−ビデオシステムの結合されたタイミング要件に適応するように容易に調整できる。これによりシステムは考えられる最小の電力消費を有することができるが、ＭＤＤＩを使用するためにフレームバッファを有することはディスプレイの要件ではない。

Ｂ．インタフェースのタイプ
ＭＤＤＩインタフェースは、通信業界とコンピュータ業界で見られる５つ又は６つ以上のいくぶん異なった物理的種類のインタフェースに対処するとして意図される。他のラベル又は名称は、それらが使用される応用例に応じて当業者によって適用されてよいが、これらは単にＩ型、ＩＩ型、ＩＩＩ型、ＩＶ型及びＵ型と呼ばれる。

Ｉ型インタフェースは携帯電話又は無線電話、ＰＤＡ、ｅ−ブック、電子ゲーム、及びＣＤプレーヤやＭＰ３プレーヤ等のポータブルメディアプレーヤ、及び類似するデバイス又は類似するタイプの消費財技術で使用されるデバイスにそれを適したものにする６線（導線）インタフェースとして構成される。ある実施形態では、Ｕ型インタフェースは、ラップトップ、ノートブック、デスクトップパーソナルコンピュータ、及びディスプレイを迅速に更新される必要がなく、内蔵ＭＤＤＩリンクコントローラを有さない類似するデバイス又はアプリケーションにより適している８線（導線）インタフェースとして構成される。このインタフェースタイプは、大部分のパーソナルコンピュータに見られる既存のオペレーティングシステム又はソフトウェアサポートに対処する上できわめて有効である、追加の２線ユニバーサルシリアルバス（ＵＳＢ）インタフェースを使用することによっても区別される。Ｕ型インタフェースは、コンピュータ又は類似するデバイス上、例えばデジタルカメラ又はビデオプレーヤなどのこのようなポートを備える消費財などの標準ＵＳＢポートに接続するＵＳＢコネクタを単に有するＵＳＢ専用モードでも使用できる。

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

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

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

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

ＭＤＤＩによって使用されるプロトコルは、通常、それぞれのＩ型、ＩＩ型、ＩＩＩ型又はＩＶ型のホストが、使用できる最高のデータレートが何であるのかを交渉することにより、Ｉ型、ＩＩ型、ＩＩＩ型又はＩＶ型のクライアントと通信できる。最も能力が低いデバイスと呼ぶことのできるものの能力又は使用可能な機能は、リンクの性能を設定するために使用される。一般に、ホストとクライアントの両方ともＩＩ型、ＩＩＩ型又はＩＶ型のインタフェースを使用できるシステムの場合でも、ともにＩ型インタフェースとして動作を開始する。次にホストはターゲットクライアントの能力を決定し、特定の応用例に対して適宜にＩＩ型モード、ＩＩＩ型モード、又はＩＶ型モードのどれかに従ってハンドオフ又は再構成動作を交渉する。

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

システムが、ある方向であるモードを、及び別の方向で別のモードを使用してデータを通信することも可能である。例えば、ＩＶ型インタフェースモードは表示にデータを高速で転送するときに使用され、Ｉ型又はＵ型のモードはキーボード又はポインティングデバイスなどの周辺装置からホストデバイスにデータを転送するときに使用される。当業者によって、ホスト及びクライアントがさまざまな速度で発信データを通信してよいことが理解されるであろう。

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

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

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

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

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

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

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

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

前記構造及び動作を実現するために使用されるケーブル布線は名目上長さ約１．５メートル、一般的には２メートル以下であり、３組のツイストペア導線を含み、それぞれは同様にマルチストランド３０ＡＷＧワイヤである。箔シールド被膜は、該３組のツイストペアに巻き付けられる、あるいはそれ以外の場合、追加ドレインワイヤとして、該３組のツイストペアの上に形成される。ツイストペア及びシールドドレイン導体はディスプレイコンテクタ内で成端し、該シールドはディスプレイ（クライアント）用のシールドに接続されており、技術で周知であるようにケーブル全体を覆う絶縁層がある。ワイヤはＭＤＤＩ＿ＧｎｄとＭＤＤＩ＿Ｐｗｒ、ＭＤＤＩ＿Ｓｔｂ＋とＭＤＤＩ＿Ｓｔｂ−、ＭＤＤＩ＿Ｄａｔａ０＋とＭＤＤＩ＿Ｄａｔａ０−、ＭＤＤＩ＿Ｄａｔａ１＋とＭＤＤＩ＿Ｄａｔａｌ−等として組にされる。

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

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

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

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

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

ヘッドマウントマイクロディスプレイなどの応用例と使用される可能性が高い等時性データストリームの場合に、調節可能又はプログラム可能である、一般的に１共通フレームあたりに必要とされるバイト数が表ＩＶに示されている。

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

異なるデータ転送速度及びデータタイプの影響を描く例示的な応用例はカラオケシステムである。カラオケの場合、エンドユーザつまり複数のユーザがミュージックビデオプログラムと合わせて歌うシステム。歌の歌詞は、画面のどこか、通常は下部に表示されるため、ユーザは歌われる言葉及び歌のタイミングを大まかに知っている。この応用例は、グラフィックスの更新が不定期なビデオディスプレイ及びユーザの声、つまり複数の声のステレオ音声ストリームとの混合を必要とする。

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

表Ｖは、データがカラオケの例について１つの共通フレームの中でどのように割り当てられるのかを示している。使用されている総レートは、約２２５Ｍｂｐｓとなるように選択される。２２６Ｍｂｐｓというわずかに高いレートは、偶発的な制御メッセージとステータスメッセージの使用を可能にする、転送される１サブフレームあたり約４００バイトの別のデータを転送できるようにする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文の中の他の説明から明らかである何かとは、逆方向カプセル化パケット、表示能力パケット及び表示要求及びステータスパケットがそれぞれ非常に重要とも見なされる、あるいは外部モード動作に必要であるとも見なされるが、それらは内部モード動作のオプションと見なすこともできる。これは、通信パケットのセットが削減され、制御とタイミングの対応する簡略化のある、非常に高速でのデータの通信を可能にするさらに別のタイプのＭＤＤＩインタフェースプロトコルを作成する。

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

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

一般的には、これらのフィールド幅及び編成は、偶数バイト境界で２バイトフィールドを整列させ、４バイト境界で４バイトフィールドを整列させておくように設計される。これによってパケット構造をメインメモリ空間内に容易に構築できる、あるいは大部分の遭遇する、あるいは典型的に使用されるプロセッサ又は制御回路データタイプ整列規則に違反せずにホスト及びクライアントとともに関連付けられる。

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

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

ディスプレイウィンドウは、ビットマップの可視部分、つまり物理的な表示媒体上でユーザが見ることができる、ビットマップの中のピクセルの部分である。多くの場合、ディスプレイウィンドウとビットマップが同じサイズになる。ディスプレイウィンドウの左上角はつねにビットマップピクセルロケーション０，０を表示する。ディスプレイウィンドウの幅がビットマップのＸ軸に一致し、ディスプレイウィンドウの幅は対応するビットマップの幅未満又は幅に等しくなるものとする。ウィンドウの高さはビットマップのＹ軸に相当し、ディスプレイウィンドウの高さは対応するビットマップの高さ未満又は高さに等しくなるものとする。ディスプレイウィンドウ自体は、ビットマップの可視部分として定義されるに過ぎないため、プロトコルでアドレス指定可能ではない。ビットマップとディスプレイウインドウの関係は図示される。

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

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

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

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

プロトコルバージョンフィールドは、ホストによって使用されるプロトコルバージョンを指定する２バイトを含む。プロトコルバージョンフィールドは、プロトコルの第１の又はカレントバージョンを、使用されているとして指定するために「０」に設定される。この値は、新しいバージョンが作成されるにつれて経時的に変化する。サブフレームカウントフィールドは、メディアフレームの開始以来送信されたサブフレーム数を示すシーケンス番号を指定する２バイトを含む。メディアフレームの第１のサブフレームは、ゼロというサブフレームカウントを有する。メディアフレームの最後のサブフレームはｎ−１という値を有し、ｎはメディアフレームあたりのサブフレーム数である。サブフレーム長が（周期的ではないサブフレームを示す）ゼロに等しく設定される場合には、サブフレームカウントもゼロに等しく設定されなければならないことに注意する。

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

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

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

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

一実施形態では、ｂＣｌｉｅｎｔＩＤフィールドはクライアントＩＤに確保される２バイトの情報を含む。これは新規に開発された通信プロトコルであるので、実際のクライアントＩＤはまだ知られていないか、あるいは十分に容易に伝達できない。従って、このフィールド内のビットは、当業者に明らかとなるように、このようなＩＤ値が知られ、その時点でＩＤ値を挿入又は使用できるようになるまで通常ゼロに等しく設定される。

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

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

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

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

Ｙｎ、Ｙｎ＋１、Ｙｎ＋２、及びＹｎ＋３は、左から右へ単一行で４個の連続ピクセルの輝度値である。本発明はこのフォーマットに制限されないが、色成分の順序付けは通常マイクロソフト社（ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎ）によってそのソフトウェアで使用されるＵＹＶＹＦＯＵＲＣＥフォーマットと同じフォーマットで選ばれる。ビデオストリーム亜Ｐケットによって参照されるウィンドウ内の行（Ｘ右端縁−Ｘ左端縁＋１）に奇数のピクセルがある場合、各行の最後のピクセルに相当するＹ値の後には次の行の最初のピクセルのＣｂ値が続き、Ｃｒ値は行の中の最後のピクセルのために送信されない。ＹＣｂＣｒフォーマットを使用するウィンドウが偶数のピクセルである幅を有することが勧められる。パケット内のピクセルデータは偶数のピクセルを含まなければならない。ピクセルデータの最後のピクセルがビデオストリームパケットヘッダ内で指定されるウィンドウの中の行の最後のピクセルに一致する場合には、つまりピクセルデータの中の最後のピクセルのＸロケーションがＸ右端縁に等しいときにはそれは奇数又は偶数のピクセルを含んでよい。

ビット［１５：１３］が代わりに「１００」に等しいとき、ビデオデータは１ピクセルあたりのビット数がビデオデータフォーマット記述子ワードのビット３から０によって定められるバイヤー（Ｂａｙｅｒ）ピクセルのアレイからなる。ピクセルパターンはＥｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ（エラー！参照ソースが検出されない）（バイヤー）に図示されるように、ビット５と４で定義される。ピクセルデータの順序は水平又は垂直であってよく、行又は列の中のピクセルは順方向又は逆方向の順序で送信されてよく、Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ（エラー！参照ソースが検出されない）に示されるようにビット８から６で定められる。ビット１１から９はゼロに設定されなければならない。

図に示される４つのすべてのフォーマットの場合、「Ｐ」として示されるビット１２はピクセルデータサンプルがパックされるかどうか、又はバイト位置合わせされたピクセルデータであるかどうかを指定する。このフィールドの「０」という値は、ピクセルデータフィールドの各ピクセルがＭＤＤインタフェースバイト境界とバイト位置合わせされることを示す。「１」という値は、ピクセルデータの各ピクセル及び各ピクセル内の各色が未使用のビットを残していないピクセルの中の過去のピクセル又は色と対照して詰め込まれる（ｐａｃｋｅｄｕｐ）ことを示す。

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

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

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

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

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

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

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

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

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

ＭＤＤＩリンクコントローラは、逆方向リンクカプセル化パケットを送信中に特別に動作する。ＭＤＤＩインタフェースはつねにリンクのコントローラであるホストによって駆動されるストローブ信号を有する。ホストは、それが逆方向リンクカプセル化パケットのターンアラウンドパケット又は逆方向データパケットの部分のビットごとにゼロを送信するかのように動作する。ホストは、各ビット境界で、２回のターンアラウンドの間、及び逆方向データパケットに割り当てられる時間の間、ＭＤＤＩ＿Ｓｔｒｏｂｅ信号をトグルする。（これは、あたかもそれが全ゼロデータを送信しているかと同じ動作である）。ホストはそのＭＤＤＩデータ信号線ドライバを、ターンアラウンド１で指定される期間の間にディスエーブルし、クライアントがターンアラウンド２フィールドによって指定される期間の後に続くドライバ再イネーブルフィールドの間でそのラインドライバを再イネーブルする。クライアントは、ターンアラウンド長パラメータを読み取り、ターンアラウンド１フィールドの最後のビットの直後にホストに向かってデータ信号を駆動する。つまり、クライアントは以下のパケットコンテンツ説明、及び他のどこかで指定されるようなＭＤＤＩストローブの特定の立ち上がりでリンクに新しいデータを記録する（ｃｌｏｃｋｓ）。クライアントは、それがホストにパケットを送信するために使用できる時間の長さを知るためにパケット長パラメータとターンアラウンド長パラメータ長を使用する。クライアントは、ホストに送信するデータがない場合には、フィラーパケットを送信するか、あるいはデータラインをゼロ状態に駆動してよい。データラインがゼロに駆動されると、ホストはこれをゼロ長（有効ではない長さ）のパケットとして解釈し、ホストは現在の逆方向リンクカプセル化パケットの期間中クライアントからこれ以上パケットを受け入れない。

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

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

９．表示能力パケット
ホストは、一般的に最適な又は所望される方法でホスト対クライアントリンクを構成するためにそれが通信しているクライアント（ディスプレイ）の機能を知る必要がある。ディスプレイが、順方向リンク同期が取得された後にホストに表示能力パケットを送信することが勧められる。このようなパケットの伝送は、逆方向リンクカプセル化パケットで逆方向リンクフラグを使用するホストによって要求されるときに必要と見なされる。表示能力パケットは、ホストにディスプレイの機能を知らせるために使用される。外部モードの場合、あらゆるホストはこのパケットを受信できなければならず、あらゆるディスプレイはこのインタフェースとプロトコルを完全に活用するためにこのパケットを送信できなければならない。このパケットのインプリメンテーションは、製造又は何らかの種類の単一の構成部品又はユニットに組み込まれる時点でディスプレイの機能はすでに明確でなければならず、ホストに公知でなければならないため、内部モードにとってはオプションである。

一実施形態における表示能力パケットのフォーマットは、図１８に描かれている。図１８に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、プロトコルバージョンフィールド、最小プロトコルバージョンフィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、白黒機能フィールド、カラーマップ機能フィールド、ＲＧＢ機能フィールド、ＹＣｒＣｂ機能フィールド、表示特徴能力フィールド、データレート機能フィールド、フレームレート機能フィールド、音声バッファ深度フィールド、音声ストリーム機能フィールド、音声レート機能フィールド、最小サブフレームレートフィールド、及びＣＲＣフィールドを有するように構造化される。例示的な実施形態では、この種のパケットは通常、６６型タイプとして認識される。

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

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

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

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

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

低電力ハイバネーション状態では、ＭＤＤＩ＿Ｄａｔａドライバが高インピーダンス状態にディスエーブルされ、ＭＤＤＩ＿Ｄａｔａ信号が、ディスプレイによって無効にできる高インピーダンスバイアスネットワークを使用して論理ゼロ状態に引かれる。インタフェースによって使用されるストローブ信号は、電力消費を最小限に抑えるためにハイバネーション状態で論理ゼロレベルに設定される。ホスト又はクライアントのどちらかによって、ＭＤＤＩリンクは、他の個所に説明されるような、本発明にとっての重要な進歩であり、本発明の利点であるハイバネーション状態から「ウェークアップ」する。

１３．表示要求及びステータスパケット
ホストは、一般的に最適にホスト対ディスプレイリンクを構成できるように、ディスプレイから少量の情報を必要とする。ディスプレイが１つのディスプレイステータスパケットをホストの各サブフレームに送信することが勧められる。ディスプレイは、逆方向リンクカプセル化パケット内の第１のパケットとして、それが確実にホストに配信されることを確実にするためにこのパケットを送信する必要がある。ディスプレイステータスパケットのフォーマットは図２２に示されている。図２２に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、逆方向リンク要求フィールド、ＣＲＣエラーカウントフィールド及びＣＲＣフィールドを有するように構造化される。この種のパケットは一般的には１バイトタイプフィールドのタイプ７０パケットとして通常識別され、８バイトの事前に選択された固定長を使用する。

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

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

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

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

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

ビットマップパターン塗りつぶしパケットのフォーマットは図２５に図示される。図２５に示されるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、上部左Ｘ値フィールド、上部左Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、パターン幅フィールド、パターン高さフィールド、データフォーマット記述子フィールド、パラメータＣＲＣフィールド、パターンピクセルデータフィールド、及びピクセルデータＣＲＣフィールドを有するように構造化される。この種のパケットは通常１バイトタイプフィールドでタイプ７３パケットとして識別される。

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

通信リンクデータチャネルパケットのフォーマットは図２６に示されている。図２６に示されるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、パラメータＣＲＣフィールド、通信リンクデータフィールド、及び通信データＣＲＣフィールドを有するように構造化される。この種のパケットは通常タイプフィールドでタイプ７４パケットとして識別される。

１８．インタフェースタイプハンドオフ要求パケット
インタフェースタイプハンドオフ要求パケットによって、ホストはクライアント又はディスプレイが既存のモード又はカレントモードからＩ型（直列）、ＩＩ型（２ビット並列）、ＩＩＩ型（４ビット並列）、又はＩＶ型（８ビット並列）モードにシフトすることを要求できるようにする。ホストは、特定のモードを要求する前に、表示能力パケットの表示特徴能力インジケータフィールドのビット６と７を調べることによって、ディスプレイが所望されるモードで動作できることを確認する必要がある。インタフェースタイプハンドオフ要求パケットのフォーマットは図２７に示される。図２７に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、インタフェースタイプフィールド、及びＣＲＣフィールドを有するように構造化される。この種のパケットは、通常タイプ７５パケットとして識別され、４バイトという事前に選択された固定長を使用する。

１９．インタフェースタイプ肯定応答パケット
インタフェースタイプ肯定応答パケットは、インタフェースタイプハンドオフパケットの受領を確認するためにディスプレイによって送信される。要求されるモード、Ｉ型（直列）、ＩＩ型（２ビット並列）、ＩＩＩ型（４ビット並列）、又はＩＶ型（８ビット並列）モードはこのパケットの中のパラメータとしてホストにエコーバックされる。インタフェースタイプ肯定応答パケットのフォーマットは図２８に示される。図２８に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、インタフェースタイプフィールド、及びＣＲＣフィールドを有するように構造化される。この種のパケットは、一般的にはタイプ７６パケットとして識別され、４バイトという事前に選択された固定長を使用する。

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

２１．順方向音声チャネルイネーブルパケット
このパケットにより、ホストはディスプレイ内の音声チャネルをイネーブル又はディスエーブルできる。この機能は有効であるため、ディスプレイ（クライアント）はホストによって出力される音声がない時には電力を節約するために音声増幅器又は類似する回路要素をオフに切り替えることができる。これは、インジケータとして音声ストリームの存在又は不在を使用するだけで暗示的に実現するためには著しく困難である。ディスプレイシステムの電源投入時のデフォルト状態は、すべての音声チャネルがイネーブルされることである。順方向音声チャネルイネーブルパケットのフォーマットは図３０に示される。図３０に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、音声チャネルイネーブルマスクフィールド、及びＣＲＣフィールドを有するように構造化される。この種のパケットは通常１バイトタイプフィールドでタイプ７８パケットとして識別され、４バイトという事前に選択された長さを使用する。

２２．逆方向音声サンプルレートパケット
このパケットにより、ホストは、逆方向リンク音声チャネルをイネーブル又はディスエーブルし、このストリームの音声データサンプルレートを設定できる。ホストは表示能力パケットで有効であると定められるサンプルレートを選択する。ホストが無効サンプルレートを選択すると、ディスプレイは音声ストリームをホストに送信しないであろう。ホストはサンプルレートを２５５に設定することにより逆方向リンク音声ストリームをディスエーブルしてよい。ディスプレイシステムが初期に電源投入される、又は接続されるトきに想定されるデフォルト状態では、逆方向リンク音声ストリームはディスエーブルされている。逆方向音声サンプルレートパケットのフォーマットは図３１に示される。図３１に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、音声サンプルレートフィールド、及びＣＲＣフィールドを有するように構造化される。この種のパケットは普通タイプ７９パケットとして識別され、４バイトという事前に選択された固定長を使用する。

２３．デジタルコンテンツ保護オーバヘッドパケット
このパケットにより、ホストとディスプレイは使用されているデジタルコンテンツ保護方法に関連するメッセージを交換できる。現在では、２種類のコンテンツ保護、つまりデジタル伝送コンテンツ保護（ＤＴＣＰ）又は広帯域幅デジタルコンテンツ保護システム（ＨＤＣＰ）が意図され、将来の代替保護方式指定のために余地が確保されている。使用されている方法は、このパケットのコンテンツ保護タイプパラメータによって指定される。デジタルコンテンツ保護オーバヘッドパケットのフォーマットは、図３２に示される。図３２に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、コンテンツ保護タイプフィールド、コンテンツ保護オーバヘッドメッセージフィールド、及びＣＲＣフィールドを有するように構造化される。この種のパケットは通常タイプ８０パケットとして識別される。

２４．透明色イネーブルパケット
透明色イネーブルパケットは、ディスプレイにおいてどの色が透明であるのかを指定するため、及び画像を表示するために透明色の使用をイネーブルする又はディスエーブルするために使用される。この機能を有するディスプレイは、表示能力パケットの表示特徴能力インジケータフィールドのビット４でその機能を報告する。透明色の値を持つピクセルがビットマップに書き込まれると、色は過去の値から変化しない。透明色イネーブルパケットのフォーマットは図３３に示される。図３３に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、透明色イネーブルフィールド、データフォーマット記述子フィールド、透明ピクセル値フィールド、及びＣＲＣフィールドを有するように構造化される。この種のパケットは、通常１バイトタイプフィールドのタイプ８１パケットとして識別され、１０バイトの事前に選択された固定長を使用する。

２５．往復遅延測定パケット
往復遅延測定パケットは、クライアント（ディスプレイ）からホストに戻るまでの遅延を加えた、ホストからクライアント（ディスプレイ）までの伝搬遅延を測定するために使用される。この測定値は本来ラインドライバとラインレシーバ、及び相互接続サブシステムに存在する遅延を含む。この測定値は、一般的に前述されたように、逆方向リンクカプセル化パケットの中のターンアラウンド遅延パラメータ及び逆方向リンクレート除数パラメータを設定するために使用される。このパケットは、特定の応用例向けにＭＤＤＩリンクが最大速度で実行しているときに最も有効である。ＭＤＤＩ＿Ｓｔｂ信号は、全ゼロデータが以下のフィールドの間に送信されているかのように動作する。つまり、全ゼロ、ガード回数と測定期間の両方である。これによりＭＤＤＩ＿Ｓｔｂは、それが測定期間中のディスプレイの周期クロックとして使用できるようにデータレートの半分でトグルする。

往復遅延測定パケットのフォーマットは図３４に示される。図３４に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、パラメータＣＲＣフィールド、全ゼロフィールド、ガード時間１フィールド、測定期間フィールド、ガード時間２フィールド、及びドライバ再イネーブルフィールドを有するように構造化される。この種のパケットは、通常、タイプ８２パケットとして識別され、５３３ビットという事前に選択された固定長を使用する。

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

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

ディスプレイは、そのラインドライバを実質的に０ｘｆｆ、０ｘｆｆ、０ｘ０パターンの最後のビットを送信した直後にディスエーブルする。ガード時間２によりディスプレイのラインドライバが、ホストが次のパケットのパケット長を送信する前の高インピーダンス状態に完全になるための時間を可能にする。ハイバネーションプルアップ抵抗とプルダウン抵抗（図４２を参照されたい）は、ＭＤＤＩ＿Ｄａｔａ信号が、ラインドライバがホストとディスプレイの両方でディスエーブルされる間隔で有効な低レベルに保持されることを確実にする。

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

順方向リンク歪み構成パケットのフォーマットは図５６に示される。図５６に示されるように、この種のパケットはパケット長（２バイト）フィールドと、パケットタイプフィールドと、パラメータＣＲＣフィールドと、校正データシーケンスフィールドとＣＲＣフィールドを有するように構造化される。この種のパケットは通常タイプフィールドでタイプ８３パケットとして識別され、５１５という事前に選択された長さを有する。

仮想制御パネル
仮想制御パネル（ＶＣＰ）によって、ホストはクライアントにおいて特定のユーザ制御を設定できる。これらのパラメータがホストによって調整されるのを可能にすることによって、クライアントのユーザインタフェースは簡略化できる。ユーザが、音量又は表示輝度などのパラメータを調整できるようにする画面は、クライアントの１台又は複数台のマイクロプロセッサによってよりむしろホストソフトウェアによって生成できるためである。ホストは、クライアントのパラメータ設定値を読み取り、各コントロールごとに有効な値の範囲を決定する能力を有する。クライアントはホストに、どの制御パラメータを調整できるのかを報告し返す機能を有する。

一般的に指定されるコントロールコード（ＶＣＰコード）と関連付けられたデータ値は、クライアントでコントロールと設定値を指定するために活用される。ＭＤＤＩ仕様のＶＣＰコードは、パケット定義の中で適切なデータフィールド位置合わせを保ち、将来にはこのインタフェース又は将来のエンハンスメントに一意である補足値をサポートするために１６ビットに拡大される。

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

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

ｈＣｌｉｅｎｔＩＤフィールドはクライアントＩＤによって確保される１６ビット符号なし整数を含む。このフィールドは将来の使用のために確保され、通常ゼロに設定される。ＭＣＣＳＶＣＰコードフィールドは、ＭＣＣＳＶＣＰ制御コードパラメータを指定する２バイトの情報を備える。０から２５５の範囲の値により、ＶＣＰ機能応答パケットを、指定されたＭＣＣＳコードに対応するＶＣＰ機能応答リストの中の単一のアイテムととも返させる。６５５３５（０ｘｆｆｆｆ）というＭＣＣＳＶＣＰコードは、クライアントによってサポートされるコントロールごとに機能回答項目を含むＶＣＰ機能応答リストとともにＶＣＰ特徴応答パケットを要求する。このフィールドのための２５６から６５５３４までの値は、将来の使用のために確保され、現在使用されていない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アルファ−カーソル画像
通信リンク上でデータを通信するためのＭＤＤインタフェース及び関連（ａｓｓｏｃｉａｔｅ）発明プロトコル及び機構が、互いに重複し、さまざまな透明度を有することがある複数の画像平面にサポートを提供する。ハードウェアカーソルは、可変Ｘ−Ｙオフセットを有する重複画像を使用して実現できる。アルファ−カーソル機能性及び関連付けられたプロトコルサポートの概要が以下に示される。アルファ−カーソル画像パケットをサポートする能力は、特定ステータス要求パケットに応えて個体得て送信されるアルファ−カーソル画像機能パケットに指定される。

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

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

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

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

ＲＧＢ機能フィールド−ＲＧＢフォーマットで表示できる解像度のビット数を指定する１６ビットの整数の符号なしを含む２バイト。クライアントがＲＧＢフォーマットを使用できない場合には、この値はゼロである。ＲＧＢ機能ワードは、一実施形態においてビット３から０が各ピクセルの青（青い輝度）最大ビット数を定め、ビット７から４が各ピクセルの緑（緑の輝度）の最大ビット数を定め、ビット１１から８が各ピクセルの赤（赤い輝度）の最大ビット数を定め、ビット１５から１２がＲＧＢ機能情報を提示する上で将来の使用のために確保され、現在はゼロに設定されるように実現される３つの別々の値から構成されている。

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

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

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

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

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

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

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

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

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

２バイトのトランスペアレンシーマップＸ開始フィールドとＹ開始フィールドは、それぞれ絶対Ｘ座標とＹ座標を指定し、点（トランスペアレンシーマップＸ開始、トランスペアレンシーマップＹ開始）は、後述されるトランスペアレンシーマップデータフィールド内の第１のピクセルである。

トランスペアレンシーマップ解像度フィールド（１バイト）は、トランスペアレンシーマップの解像度、及びデータがパックされるかどうかを指定する値を含む。このフィールドの一実施形態では、ビット３から０がすべてのトランスペアレンシーマップテーブル項目に存在する解像度のビット数を定める。有効値は１ビットから８ビットである幅を指定する。値０と９から１５は無効と見なされる。この値は、アルファ−カーソル画像機能パケットのトランスペアレンシーマップ解像度フィールドの中でクライアントによって返される値に一致する必要がある。ビット６から４は将来の使用のために確保されているため、この時点では通常論理ゼロに設定されるものとする。このバイトのビット７は、トランスペアレンシーマップデータがパック形式であるのか、バイト位置合わせ形式であるのかどうかを指定する。ビット７が１に等しい場合には、トランスペアレンシーマップはパック形式であり、「０」の場合、データはバイト位置あわせされている。パックされるトランスペアレンシーマップとバイト位置合わせトランスペアレンシーマップデータの一例は、Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）に示される。このビットの値はアルファ−カーソル画像機能パケットの機能ビットフィールドのビット１の値に一致しなければならない。

１ｂｕｔｅ確保１フィールドは将来の使用のために確保されるため、このフィールドのすべてのビットは通常論理ゼロレベルに設定される。このフィールドの１つの目的とは、すべての以後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。

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

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

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

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

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

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

２バイトビデオデータフォーマット記述子フィールドは、本パケットの本ストリームの中でピクセルデータの各ピクセルのフォーマットを指定する情報又は値を含む。ピクセルデータフォーマットは、アルファ−カーソル画像機能パケットで定められるようにアルファカーソル画像平面のための有効なフォーマットの少なくとも１つと準拠しなければならない。ビデオデータフォーマット記述子フィールドは、カレントパケットだけのためのピクセルフォーマットを定義し、一定のフォーマットがある特定のビデオストリームの存続期間の間使用し続けられることを暗示しない値を含む。Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）は、ビデオデータフォーマット記述子がどのようにしてコード化されるのかを描く。フォーマットは以下のとおりである。

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

ビット［１５：１３］が「０１１」であるときには、ビデオデータは輝度及びクロミナンス情報とともに４：２：２のＹＣｂＣｒフォーマットのビデオデータのアレイからなる。輝度（Ｙ）の１ピクセルあたりのビット数は、ビット１１から８で定められ、Ｃｂ成分のビット数はビット７から４で定められ、Ｃｒ成分のビット数はビット３から０で定められる。Ｃｂ成分とＣｒ成分はＹの半分の速度で送信される。このパケットのピクセルデータ部分内のビデオサンプルは、以下のように編成される。Ｃｂｎ、Ｙｎ、Ｃｒｎ、Ｙｎ＋１、Ｃｂｎ＋２、Ｙｎ＋２、Ｃｒｎ＋２、Ｙｎ＋３．．．であり、ＣｂｎとＣｒｎはＹｎとＹｎ＋１に関連し、Ｃｂｎ＋２とＣｒｎ＋２はＹｎ＋２とＹｎ＋３に関連付けられる等である。Ｙｎ、Ｙｎ＋１、Ｙｎ＋２及びＹｎ＋３は左から右へ単一行の４個の連続ピクセルの輝度値である。カラー成分の順序付けはＭｉｃｒｏｓｏｆｔＵＹＶＹＦＯＵＲＣＣフォーマットと同じである。ビデオストリームパケットにより参照されるウィンドウの一行に奇数のピクセル（Ｘ．右端縁−Ｘ左端縁＋１）がある場合、各行の最後のピクセルに対応するＣｂ値の後には次の行の第１のピクセルのＹ値が続く。ＹＣｂＣｒフォーマットを使用するウィンドウが偶数のピクセルである幅を有することが勧められる。パケット内のピクセルデータは、偶数のピクセルを含むものとする。それは、ピクセルデータの最後のピクセルがビデオストリームパケットヘッダに指定されるウィンドウ内の行の最後のピクセルに対応する場合、つまりピクセルデータの最後のピクセルのＸロケーションがＸ右端縁に等しいとき、奇数又は偶数のピクセルを含んでよい。４つすべてのフォーマットについて、（図中「Ｐ」で示される）ビット１２が、ピクセルデータサンプルがパックされるかどうかを指定する。ビット１２の値が「０」であるときには、ピクセルデータフィールド内の各ピクセルと各色がＭＤＤＩインタフェースバイト境界でバイト位置合わせされる。ビット１２の値が「１」であるときには、ピクセルデータの各ピクセル中の各ピクセルと各色がピクセル内の各ピクセル又は色に照らし合わせてパックされ、未使用のビットを残さない。

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

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

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

ビット５は、ＭＤＤＩインタフェースの将来の使用又は応用例のために確保されているため、一般的にはゼロ値つまり「０」に設定される。

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

ビット８から１５は、将来の使用のために確保されているため、通常はゼロとして設定される。

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

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

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

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

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

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

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

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

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

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

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

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

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

１バイトの機能ビットフィールドは、スケーリング済みビデオストリームと関連付けられる機能を指定するフラグの集合を含む８ビットの符号なし整数を含む。フラグは以下のとおりに定義される。ビット０はスケーリング済みビデオストリームパケットの中のピクセルデータをカバーし、パックされた形式となる。パックされたピクセルデータとバイト位置合わせされたピクセルデータの例がＥｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）に示される。ビット１は、将来の使用のために確保され、ゼロに設定されるものとする。ビット２は将来の使用のために確保され、ゼロに設定されるものとする。ビット３はカラーマップデータフォーマットに指定できるスケーリング済みビデオストリームをカバーする。同じカラーマップテーブルは、メイン画像バッファとアルファ−カーソル画像平面に使用されるようにスケーリング済みビデオストリームに使用される。カラーマップは他の個所で説明されるカラーマップパケットを使用して構成され、ビット７から４が将来の使用に確保され、通常ゼロに設定される。

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

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

パケット定義はＥｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）に描かれている。

パケット図１

パケットコンテンツ：
パケット長−パケット長フィールドを含まない、パケット内のバイト総数を指定する１６ビット符号なし整数を含む２バイト。このパケットのパケット長はつねに２４である。

パケットタイプ−１６ビット符号なし整数を含む２バイト。１３６というパケットタイプはスケーリング済みビデオストリームセットアップパケットとしてパケットを識別する。

ｈＣｌｉｅｎｔＩＤ−クライアントＩＤのために確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用のために確保され、ゼロに設定されるものとする。

ストリームＩＤ−ストリームＩＤに一意の識別子を指定する１６ビット符号なし整数を含む２バイト。この値はホストによって割り当てられ、ゼロから表示能力パケットに指定される最大ストリームＩＤ値までとする。ホストは、各アクティブストリームに一意の値が割り当てられ、もはやアクティブではないストリームは割り当て解除される、又は割り当てし直されることを確実にするために注意深くストリームＩＤ値の使用を管理しなければならない。

ビデオデータフォーマット記述子−本パケット内の本ストリーム内のピクセルデータの各ピクセルのフォーマットを指定する１６ビットの符号なし整数を含む２バイト。ピクセルデータフォーマットは、アルファ−カーソル画像機能パケットに定義されるようにアルファ−カーソル画像平面のための有効なフォーマットの少なくとも１つに準拠しなければならない。ビデオデータフォーマット記述子は、現在のパケット専用のピクセルフォーマットを定め、一定のフォーマットがある特定のビデオストリームの存続期間中使用され続けることを暗示しない。Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）は、ビデオデータフォーマット記述子がどのようにしてコード化されるのかを描く。フォーマットは以下のとおりである。

ビット［１５：１３］＝０００の場合には、ビデオデータは、１ピクセルあたりのビット数がビデオデータフォーマット記述子ワードの３から０ビットによって定義される白黒ピクセルのアレイからなる。ビット１１から４はゼロに設定されるものとする。

ビット［１５：１３］＝００１の場合、ビデオデータは、それぞれがカラーマップ（パレット）によって色を指定するカラーピクセルのアレイからなる。ビデオデータフォーマット記述子ワードのビット５から０は１ピクセルあたりのビット数を定める。ビット１１から６はゼロに設定されるものとする。

ビット［１５：１３］＝０１０の場合、ビデオデータは、赤の１ピクセルあたりビット数がビット１１から８によって定義され、緑の１ピクセルあたりのビット数がビット７から４によって定義され、青のピクセルあたりのビット数がビット３から０によって定義される未処理ＲＧＢフォーマットのカラーピクセルのアレイからなる。各ピクセルのビットの総数は、赤、緑、及び青に使用されるビット数の合計である。

［１５：１３］＝０１１、ビデオデータは輝度とクロミナンス情報のある４：２：２ＹＣｂＣｒフォーマットのビデオデータのアレイからなる。輝度（Ｙ）のピクセルあたりのビット数はビット１１から８によって定義され、Ｃｂ成分のビット数はビット７から４で定義され、Ｃｒ成分のビット数はビット３から０で定義される。Ｃｂ成分とＣｒ成分はＹのようなレートの半分で送信される。このパケットのピクセルデータ部分のビデオサンプルは以下のように編成されるであろう。Ｃｂｎ、Ｙｎ、Ｃｒｎ、Ｙｎ＋１、Ｃｂｎ＋２、Ｙｎ＋２、Ｃｒｎ＋２、Ｙｎ＋３．．．この場合、ＣｂｎとＣｒｎはＹｎとＹｎ＋１と関連付けられ、Ｃｂｎ＋２とＣｒｎ＋２はＹｎ＋２とＹｎ＋３と関連付けられる等である。Ｙｎ、Ｙｎ＋１、Ｙｎ＋２、及びＹｎ＋３は左から右への単一行の４個の連続するピクセルの輝度値である。色成分の順序付けはＭｉｃｒｏｓｏｆｔＵＹＶＹＦＯＵＲＣＣフォーマットと同じである。ビデオストリームパケットによって参照されるウィンドウ内の行（Ｘ右端縁−Ｘ左端縁＋１）に奇数のピクセルがある場合には、各行の最後のピクセルに対応するＣｂ値の後に次の行の第１のピクセルのＹ値が続く。ＹＣｂＣｒフォーマットを使用するウィンドウが、偶数のピクセルである幅を有することが勧められる。パケットのピクセルデータは偶数のピクセルを含むものとする。ピクセルデータの最後のピクセルがビデオストリームパケットヘッダ内に指定されるウィンドウの中の行の最後のピクセルに相当する場合、つまりピクセルデータの最後のピクセルのＸロケーションがＸ右端縁に等しいとき、それは奇数又は偶数のピクセルを含んでよい。

４つすべてのフォーマットに対して、（Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）で「Ｐ」と示される）ビット１２は、ピクセルデータサンプルがパックされるかどうかを指定する。Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）は、パックされたデータとバイト位置合わせされたピクセルデータの差異を描く。

０−ピクセルデータフィールドの各ピクセルの中の各ピクセルと各色は、ＭＤＤＩインタフェースバイト境界とバイト位置合わせされる。

１−ピクセルデータの各ピクセルの中の各ピクセルと各色は、前のピクセル又はピクセルの中の色に照らし合わせてパックされ、未使用ビットを残さない。

ピクセルデータ属性−以下のとおりに解釈される１６ビット符号なし整数を含む２バイト。

ビット１と０は、ピクセルデータが送られるものとするディスプレイを選択する。

ビット「１：０」＝１１又は００−データは両目に表示される。

ビット［１：０］＝１０−データは左目だけに送られる。

ビット［１：０］＝０１−データは右目だけに送られる。

ビット２は、ピクセルデータがインタレースフォーマットであることを示す。

ビット２は０である−ピクセルデータは標準漸次フォーマットである。行番号（ピクセルＹ座標）は、ある行から次の行に進むときに、１、増分されるものとする。

ビット２は１である−ピクセルデータはインタレースフォーマットである。行番号（ピクセルＹ座標）は、ある行から次の行に進むときに２、増分されるものとする。

ビット３は、ピクセルデータが代替ピクセルフォーマットであることを示す。これは、ビット２によってイネーブルされる標準インタレースモードに類似しているが、インタレースは水平の代わりに垂直である。

ビット３は０である―ピクセルデータは標準漸次フォーマットである。列番号（ピクセルＸ座標）は、各継続ピクセルが受信されると１、増分されるものとする。

ビット３は１である―ピクセルデータは代替ピクセルフォーマットである。列番号（ピクセルＸ座標）は、各ピクセルが受信されると２、増分されるものとする。

ビット４は、ピクセルデータがディスプレイに関するのか、カメラに関するのかを示す。

ビット４は０である―ピクセルデータはディスプレイフレームバッファへ、又はディスプレイフレームバッファからである。

ビット４は１である―ピクセルデータはカメラへ、又はカメラからである。

ビット５は、将来の使用のために確保され、ゼロに設定されるものとする。

ビット７と６は、ピクセルデータが書き込まれるものとするフレームバッファを指定する表示更新ビットである。フレーム更新ビットの効果は項、Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）とＥｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）にさらに詳しく説明される。

ビット［７：６］＝０１―ピクセルデータがオフライン画像バッファに書き込まれる。

ビット［７：６］＝００―ピクセルデータが表示をリフレッシュするために使用される画像バッファに書き込まれる。

ビット［７：６］＝１１―ピクセルデータが全画像バッファに書き込まれる。

ビット［７：６］＝１０−無効。将来の使用のために確保。ピクセルデータは無視され、画像バッファのどれにも書き込まれない。

ビット８から１５は将来の使用のために確保され、ゼロに設定されるものとする。

Ｘ左端縁―宛て先画像の左端縁のＸ座標を指定する１６ビット符号なし整数を含む２バイト。

Ｙ上端縁―宛て先画像の上端縁のＹ座標を指定する１６ビット符号なし整数を含む２バイト。

Ｘ右端縁―宛て先画像の右端縁のＸ座標を指定する１６ビット符号なし整数を含む２バイト。

Ｙ下端縁―宛て先画像の下端縁のＹ座標を指定する１６ビット符号なし整数を含む２バイト。

Ｘ画像サイズ―ソース画像の幅を指定する１６ビット符号なし整数を含む２バイト。

Ｙ画像サイズ―ソース画像の高さを指定する１６ビット符号なし整数を含む２バイト。

ＣＲＣ―パケット長を含むパケットのすべてのバイトの１６ビットＣＲＣを含む２バイト。

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

パケット定義は、以下に描かれる。

パケット図２

パケットコンテンツ：
パケット長―パケット長フィールドを含まないパケット内の総バイト数を指定する１６ビット符号なし整数を含む２バイト。このパケットのパケット長はつねに１０である。

パケットタイプ―１３７というパケットタイプは、スケーリング済みビデオストリーム肯定応答パケットとしてパケットを識別する。

ｃＣｌｉｅｎｔＩＤ―クライアントＩＤのために確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用のために確保され、ゼロに設定されるものとする。

ストリームＩＤ―ストリームＩＤのための一意の識別子を指定する１６ビット符号ない整数を含む２バイト。これは、スケーリング済みビデオストリームセットアップパケット内のホストによって割り当てられるのと同じ値である。

２バイトＡｃｋ（肯定応答コード）フィールドは、指定されたスケーリング済みビデオストリームを更新する試みの結果を説明するコードを含む値を提供する。該コードは以下のように定義される。

０―ストリーム割り当て試行が成功した。

１―ストリーム割り当て解除試行が成功した。

２―すでに割り当てられているストリームＩＤを割り当てようとする無効な試み。

３―すでに割り当て解除されているストリームＩＤを割り当て解除しようとする無効な試み。

４―クライアントはスケーリング済みのビデオストリームをサポートしない。

５―ストリームパラメータはクライアントの機能と一貫性がない。

６―クライアントにより許可される最大値より大きなストリームＩＤ値。

７―指定されたストリームを割り当てるためにクライアント内で使用可能な不十分な資源。

ＣＲＣ―パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む２バイト。

スケーリング済みビデオストリームパケット
スケーリング済みビデオストリームパケットは、特定のスケーリング済みビデオストリームと関連付けられるピクセルデータを送信するために使用される。このパケットによる領域基準の（ｔｈｅｒｅｇｉｏｎｒｅｆｅｒｅｎｃｅｂｙ）サイズはスケーリング済みビデオストリームセットアップパケットによって定義される。クライアントは、有効ステータス回答リストパケットの有効パラメータ回答リスト内の１４３というパラメータ値を介して、及びスケーリング済みビデオストリーム肯定応答パケットのＡｃｋコードフィールドの成功したスケーリング済みビデオストリーム割り当て応答を介してスケーリング済みビデオストリームパケットをサポートするその能力を示すものとする。

パケット定義は図１に描かれている。

パケット図３

図１、スケーリング済みビデオストリームパケット
パケットコンテンツ：
パケット長―パケット長フィールドを含まないパケット内のバイト総数を指定する１６ビット符号なし整数を含む２バイト。

パケットタイプ―１６ビット符号なし整数を含む２バイト。１８というパケットタイプは、スケーリング済みのビデオストリームパケットとしてパケットを識別する。

ｈＣｌｉｅｎｔＩＤ―クライアントＩＤに確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用ために確保され、ゼロに設定されるものとする。

ストリームＩＤ―ストリームＩＤの一意の識別子を指定する１６ビット符号なし整数を含む２バイト。この値は、スケーリング済みビデオストリームセットアップパケットの中のホストによって指定され、スケーリング済みビデオストリーム肯定応答パケットで確認される。

ピクセルカウント―以下のピクセルデータフィールドの中のピクセル数を指定する１６ビット符号なし整数を含む２バイト。

パラメータＣＲＣ―パケット長からピクセルカウントまでの全バイトの１６ビットＣＲＣを含む２バイト。このＣＲＣがチェックできない場合には、パケット全体を廃棄するものとする。

ピクセルデータ―スケーリングされてから、表示される未処理ビデオ情報。データは、ビデオデータフォーマット記述子フィールドによって記述される方法でフォーマットされる。データは、項Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）に定義されるように一度に１行ずつ送信される。

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

特殊ステータス要求パケット
特殊ステータス要求パケットは、クライアントがこのパケットに指定されるようにホストに機能パケット又はステータスパケットを送信することをホストが要求するための手段となる。クライアントは、次の逆方向リンクカプセル化パケットで指定されるタイプのパケットを戻すものとする。クライアントは特殊ステータス要求パケットに応答する能力がある場合は、表示能力パケットの表示特徴能力インジケータフィールドにビット１７を設定する。クライアントは、表示能力パケットの表示特徴能力インジケータフィールドのビット２１を介して特殊ステータス要求パケットをサポートするその能力を示すものとする。

パケット図４

図、特殊ステータス要求パケット
パケットコンテンツ：
パケット長―パケット長フィールドを含まないパケット内の総バイト数を指定する１６ビット符号なし整数を含む２バイト。このパケットのパケット長はつねに１０である。

パケットタイプ―１６ビット符号なし整数を含む２バイト。１３８というパケットタイプは特殊ステータス要求パケットとしてパケットを識別する。

ｈＣｌｉｅｎｔＩＤ―クライアントＩＤに確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用に確保され、ゼロに設定されるものとする。

ステータスパケットＩＤ―以下のとおりにホストにクライアントが送信するものとする機能パケット又はステータスパケットのタイプを指定する１６ビット符号なし整数を含む２バイト。

６６―表示能力パケットはクライアントにより送信されるものとする。

１３３―アルファ−カーソル画像機能パケットはクライアントにより送信されるものとする。

１３９―クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス回答リストパケットが送信されるものとする。

１４０―パケット処理遅延パラメータパケットはクライアントによって送信されるものとする。

１４１―パーソナルディスプレイ機能パケットはクライアントにより送信されるものとする。

１４２―エラーレポート表示パケットはクライアントにより送信されるものとする。

１４３―スケーリング済みビデオストリーム機能パケットはクライアントにより送信されるものとする。

１４４―表示識別パケットはクライアントにより送信されるものとする。

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

ＣＲＣ―パケット長を含むパケットの全バイトの１６ビットＣＲＣを含む２バイト。

有効ステータス回答リストパケット
有効ステータス回答リストパケットは、ホストに、クライアントが応答する機能を有するステータスパケットと機能パケットのリストを提供する。クライアントは、表示能力パケットの表示特徴能力インジケータフィールドのビット２１を介して有効ステータス回答リストパケットをサポートするその能力を示すものとする。

パケット図５

パケットタイプ―１６ビット符号なし整数を含む２バイト。１３９というパケットタイプが有効ステータス回答パケットとしてパケットを識別する。

ｃＣｌｉｅｎｔ−ＩＤ―クライアントＩＤに確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用に確保され、ゼロに設定されるものとする。

リスト内の値数―次の有効パラメータ回答リストの中のアイテム数を指定する１６ビット符号なし整数を含む２バイト。

有効パラメータ回答リスト―クライアントがホストに送信できる機能パケット又はステータスパケットのタイプを指定する２バイトパラメータのリスト。クライアントが、（表示能力パケットの中の表示特徴能力インジケータフィールドのビット２１を介して）ステータス要求パケットに応答できることを示した場合、それはつねに少なくとも表示能力パケット（パケットタイプ＝＝６６）と有効ステータス回答リストパケット（パケットタイプ＝１３９）を送信できるものとする。このリスト及びその意味に含まれてよいパケットタイプは、以下のとおりである。

６６―表示能力パケットはクライアントによって送信されるものとする。

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

パケット図６

パケットタイプ―１６ビット符号なし整数を含む２バイト。１４０というパケットタイプは、パケット処理遅延パラメータパケットとしてパケットを識別する。

ｃＣｌｉｅｎｔＩＤ―クライアントＩＤに確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来に確保され、ゼロに設定されるものとする。

リストアイテム数―以下の有効パラメータ回答リスト内の項目数を指定する１６ビット符号なし整数を含む２バイト。

有効パラメータ回答リスト―１つ又は複数の遅延パラメータリスト項目を含むリスト。単一遅延パラメータリスト項目のフォーマットは、Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）に示される。

ＣＲＣ―パケット長を含むパケット内の全バイトの１６ビットＣＲＣを含む２バイト。

パケット図７

各遅延パラメータリスト項目の長さは正確に６バイトであり、以下のように定義される。

遅延用パケットタイプ―以下の遅延パラメータが適用するパケットタイプを指定する１６ビット符号なし整数を含む２バイト。

ピクセル遅延―遅延値に対する指数である８ビット符号なし整数を含む１バイト。テーブルから読み取られる値は、パケットの宛て先フィールドの総ピクセル数で乗算される。総ピクセル数は幅にパケットによって参照されるビットマップの宛て先領域の高さをかける。方程式０から１は総遅延を計算するために使用される。

水平ピクセル遅延―遅延値テーブル（ＤＰＶＬと同じ表）に対する指数である８ビット符号なし整数を含む１バイト。テーブルから読み取られる値は、パケットの宛て先フィールドの（ピクセル単位の）幅で乗算される。方程式０から１は総遅延を計算するために使用される。

垂直ピクセル遅延―遅延値テーブル（ＤＰＶＬと同じ表）に対する指数である８ビット符号なし整数を含む１バイト。テーブルから読み取られる該値は、パケットの宛て先フィールドの（ピクセル単位の）高さで乗算される。方程式０から１は総遅延を計算するために使用される。

固定遅延―遅延値テーブル（ＤＰＶＬと同じ表）に対する指数である８ビット符号なし整数を含む１バイト。テーブルから読み取られる値は、パケット内に指定されるあらゆるパラメータ値に関係のないパケットを処理するために要する時間を表す固定遅延パラメータである。方程式０から１は総遅延を計算するために使用される。

遅延＝(PacketProcessingDelay(PixelDelay)・TotalPixels)+
(PacketProcessingDelay(HorizontalPixelDelay)・Width)+
(PacketProcessingDelay(VerticalPixelDelay)・Height)+
PacketProcessingDelay(FixedDelay)
方程式０から１、パケット処理完了時間遅延
いくつかのパケットの場合、それらのパラメータは対応するパケットで参照されないため、ＴｏｔａｌＰｉｘｅｌｓ、幅、又は高さは適用しない。それらのケースでは、対応するピクセル遅延パラメータはゼロになるものとする。

パーソナルディスプレイ機能パケット
パーソナルディスプレイ機能パケットは、ヘッドマウント式ディスプレイ又はディスプレイめがね（ｄｉｓｐｌａｙｇｌａｓｓｅｓ）などのパーソナルディスプレイデバイスの機能を記述するパラメータのセットを提供する。これによりホストはクライアントの特定の機能に従って表示情報をカスタマイズできる。他方、クライアントは、有効ステータス回答リストパケットの有効パラメータ回答リストに対応するパラメータを使用することによってパーソナルディスプレイ機能パケットを送信する能力を示す。

パケット図８

パケットコンテンツ
パケット長―パケット長フィールドを含まないパケット内の総バイト数を指定する１６ビット符号なし整数を含む２バイト。このパケットのパケット長はつねに６８である。

パケットタイプ―１６ビット符号なし整数を含む２バイト。１４１のパケットタイプはパーソナルディスプレイ機能パケットとしてパケットを識別する。

サブピクセルレイアウトフィールドは、以下の値を使用して、上から下へ及び左から右へサブピクセルの物理的なレイアウトを指定する８ビット符号なし整数を含む。つまり、０は、サブピクセルレイアウトが画定されていないことを示し、１は赤、緑、青の縞を示し、２は青、緑、赤の縞を示し、３は、左上に赤、右下に青の２×２のサブピクセル、及び左下に一方、右上に他方の２つの緑のサブピクセルの配列を有する４倍ピクセルを示し、４は左下に赤、右上に青の２×２のサブピクセル配列、及び左上に一方、右下に他方の２つの緑のサブピクセルの配列を有する４倍ピクセルを示し、５は、デルタ（トライアド）を示し、６は（フィールドシーケンシャルカラーのＬＣＯＳディスプレイなど）赤、緑、及び青がオーバレイされたモザイクを示し、７から２５５は通常将来の使用に確保される。

ピクセル形状フィールドは、以下の値を使用して特定の構成のサブピクセルから構成される各ピクセルの形状を指定する８ビット符号なし整数を含む。つまり、０はサブピクセル形状が画定されていないことを示し、１は円形を示し、２は正方形を示し、３は矩形を示し、４は小判形を示し、５は楕円系を示し、値６から２５５は当業者が理解されるように所望される形状を示す上で将来の使用に確保されている。

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

垂直視野（ＶＦＯＶ）フィールド―０．５度の増分で垂直視野を指定する８ビット符号なし整数を含む１バイト（例えば、ＨＦＯＶが３０度である場合、この値は６０である）。この値がゼロである場合には、ＶＦＯＶは指定されない。

視軸交差フィールド―０．０１ジオプター（１／ｍ）増分で、視軸交差を指定する８ビット符号なし整数を含む１バイト（例えば、視軸交差が２．２２メートルである場合、この値は４５である）。この値がゼロである場合、視軸交差は指定されない｛注意：本パラメータの仕様は大部分の用途での所望される範囲に適切か｝。

左／右画像重複フィールド―左画像と右画像の重複のパーセンテージを指定する８ビット符号なし整数を含む１バイト。画像重複のパーセント単位の許容範囲は１から１００である。１０１から２５５という値は無効であり、使用されないものとする。この値がゼロである場合には、画像重複は指定されない。

シースルーフィールド―画像のシースルーパーセンテージを指定する８ビット符号なし整数を含む１バイト。シースルーのパーセント単位の許容範囲は０から１００である。１０１から２５４という値は無効であり、使用されないものとする。この値が２５５である場合には、シースルーパーセンテージは指定されない。

最大輝度フィールド―２０ｎｉｔｓの増分で最大輝度を指定する８ビット符号なし整数を含む１バイト（例えば最大輝度が１００ｎｉｔｓの場合、この値は５である）。この値がゼロである場合には、最大輝度は指定されない。

光学機能フラグフィールド―ディスプレイの光学機能を指定する多様なフィールドを含む１６ビット符号なし整数を含む２バイト。

ビット１５から５―将来の使用に確保され、ゼロに設定されるものとする。

ビット４―眼鏡焦点調整
０―ディスプレイは眼鏡焦点調整を有さない。

１―ディスプレイは眼鏡焦点調整を有する。

ビット３から２―両眼機能
０―ディスプレイは双眼であり、二次元（２Ｄ）画像だけを表示できる。

１―ディスプレイは双眼であり、三次元（３Ｄ）画像を表示できる。

２―ディスプレイは単眼である。

３―将来の使用に確保される。

ビット１から０―左−右視野湾曲対称
０―視野湾曲は定義されていない。このフィールドがゼロである場合には、Ａ１からＥ５までのすべての視野湾曲値は、ディスプレイの焦点距離を指定する、あるいは焦点距離が指定されていないことを示すためにゼロに設定されるものとする点Ｃ３を除いてゼロに設定されるものとする。

１―左ディスプレイと右ディスプレイは同じ対称性を有する。

２―左ディスプレイと右ディスプレイは、垂直軸（列Ｃ）でミラーリングされる。

３―将来の使用に確保される。

瞳孔間距離（ＩＰＤ）最小―ミリメートル（ｍｍ）単位で最小瞳孔間距離を指定する８ビット符号なし整数を含む１バイト。この値がゼロである場合には、最小瞳孔間距離は指定されない。

瞳孔間距離（ＩＰＤ）最大―ミリメートル（ｍｍ）単位で最大瞳孔間距離を指定する８ビット符号なし整数を含む１バイト。この値がゼロである場合には、最大瞳孔間距離は指定されない。

視野湾曲点リスト―焦点距離を、１から６５５３５の範囲（例えば、１は０．００１ジオプターであり、６５５３５は６５．５３５ジオプターである）でジオプターの１０００分の１（１／ｍ）で指定する２５の２バイトのパラメータのリスト。視野湾曲点リストの中の２５の要素は、以下のＥｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）に示されるようにＡ１からＥ５と呼ばれる。点は、ディスプレイのアクティブ領域で均等に分散されるものとする。列Ｃはディスプレイの垂直軸に相当し、行３はディスプレイの水平軸に相当する。列ＡとＥは、それぞれディスプレイの左端縁と右端縁に相当する。そして行１と５は、それぞれディスプレイの上端縁と下端縁に相当する。リスト中の該２５の点の順序は以下のとおりである。Ａ１、Ｂ１、Ｃ１、Ｄ１、Ｅ１、Ａ２、Ｂ２、Ｃ２、Ｄ２、Ｅ２、Ａ３、Ｂ３、Ｃ３、Ｄ３、Ｅ３、Ａ４、Ｂ４、Ｃ４、Ｄ４、Ｅ４、Ａ５、Ｂ５、Ｃ５、Ｄ５、Ｅ５
ＣＲＣ―パケット長を含むパケット内の全バイトの１６ビットＣＲＣを含む２バイト。

パケット図９

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

パケット図１０

パケットコンテンツ
パケット長―パケット長フィールドを含まないパケットの総バイト数を指定する１６ビット符号なし整数を含む２バイト。

パケットタイプ―１６ビット符号なし整数を含む２バイト。１４２というパケットタイプはエラーレポート表示パケットとしてパケットを識別する。

ｃＣｌｉｅｎｔＩＤ―クライアントＩＤに確保される２バイト。このフィールドは将来の使用に確保され、ゼロに設定されるものとする。

リストアイテム数―以下のエラーコードリストのアイテム数を指定する１６ビット符号なし整数を含む２バイト。

エラーコードリスト―１つ又は複数のエラーレポートリストアイテムを含むリスト。単一エラーレポートリストのフォーマットは、Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）に示される。

パケット図１１

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

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

パケット図１２

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

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

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

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

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

内部モードで動作されるＭＤＤＩシステムの場合、ＭＤＤＩクライアントコントローラに複数のディスプレイが接続されることは共通である場合がある。例の応用例は、フリップの内側に大型ディスプレイを備え、外側に小型のディスプレイを備える携帯電話である。表示能力パケットの代替表示番号フィールドは、複数のディスプレイが取り付けられていることを報告するために使用され、代替表示能力パケットは各代替ディスプレイの能力を報告する。ビデオストリームパケットは、クライアントデバイス内の各代替ディスプレイをアドレス指定するためにピクセルデータ属性フィールドの４ビットを含む。

パケット図１３

パケットコンテンツ
パケットタイプ―１６ビット符号なし整数を含む２バイト。１４５というパケットタイプは、代替表示能力パケットとしてパケットを識別する。

ｃＣｌｉｅｎｔＩＤ―クライアントＩＤに確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用に確保され、ゼロに設定されるものとする。

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

確保１―将来の使用に確保される８ビット符号なし整数を含む１バイト。このフィールドのすべてのビットはゼロに設定されるものとする。このフィールドの目的は、以後すべての２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。

ビットマップ幅―ピクセルの数として表されるビットマップの幅を指定する１６ビット符号なし整数を含む２バイト。

ビットマップ高さ―ピクセルの数として表されるビットマップの高さを指定する１６ビット符号なし整数を含む２バイト。

表示ウィンドウ幅―ピクセル数として表されるディスプレイウィンドウの幅を指定する１６ビット符号なし整数を含む２バイト。

表示ウィンドウ高さ―ピクセル数として表されるディスプレイウィンドウの高さを指定する１６ビット符号なし整数を含む２バイト。

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

ビット３から０は、各ピクセルの中の青の最大ビット数を定義する。０から８が有効である。

ビット７から４が各ピクセルの中の緑の最大ビット数を定義する。０から８が有効である。

ビット１１から８は、各ピクセルの中の赤の最大ビット数を定義する。０から８が有効である。

ビット１５から１２は、将来の使用に確保され、ゼロに設定されるものとする。

ＲＧＢ能力―ＲＧＢフォーマットで表示できる解像度のビット数を指定する１６ビット符号なし整数を含む２バイト。クライアントがＲＧＢ形式を使用できない場合には、この値はゼロである。ＲＧＢ機能ワードは３つの別々の符号なし値から構成される。

ビット３から０は、各ピクセルの中の青（青い輝度）の最大ビット数を定義する。

ビット７から４は、各ピクセルの中の緑（緑の輝度）の最大ビット数を定義する。

ビット１１から８は、各ピクセルの中の赤（赤の輝度）の最大ビット数を定義する。

ビット１５から１２は将来の使用に確保され、ゼロに設定されるものとする。

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

確保２―将来の使用に確保される８ビット符号なし整数を含む１バイト。このフィールド内のすべてのビットはゼロに設定されるものとする。このフィールドの目的は、以後のすべての２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。

ＹＣｂＣｒ機能―ＹＣｂＣｒフォーマットで表示できる解像度のビット数を指定する１６ビット符号なし整数を含む２バイト。クライアントがＹＣｂＣｒフォーマットを使用できない場合、この値はゼロである。ＹＣｂＣｒ機能ワードは、３つの別々の符号なし値から構成される。

ビット３から０は、Ｃｂサンプルを指定する最大ビット数を定義する。

ビット７から４は、Ｃｒサンプルを指定する最大ビット数を定義する。

ビット１１から８は、Ｙサンプルを指定する最大ビット数を定義する。

表示特徴能力インジケータ―クライアントの特定の特徴がサポートされているかどうかを示すフラグのセットを含む８ビット符号なし整数を含む１バイト。１に設定されるビットは能力がサポートされていることを示し、ゼロに設定されるビットは能力がサポートされていないことを示す。

ビット０―クライアントはパックされたフォーマットのビデオデータを受け入れることができる。

ビット１から７―将来の使用に確保され、ゼロに設定されるものとする。

確保３―将来の使用に確保される８ビット符号なし整数を含む１バイト。このフィールドのすべてのビットはゼロに設定されるものとする。このフィールドの目的は、以後すべての２バイトフィールドを１６ビットワードアドレスと位置合わせさせ、４バイトフィールドを３２ビットワードアドレスと位置合わせさせることである。

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

パケット図１４

レジスタアクセスパケット
２バイトのパケット長フィールドは、パケット長フィールドを含まないパケット内の総バイト数を指定する１６ビット符号なし整数を含む。

パケットタイプ―１６ビット符号なし整数を含む２バイト。１４６というパケットタイプはパケットをレジスタアクセスパケットとして識別する。

ｂＣｌｉｅｎｔＩＤ―クライアントＩＤに確保される１６ビット符号なし整数を含む２バイト。このフィールドは将来の使用に確保され、ゼロに設定されるものとする。

読み取り／書き込み情報―特定のパケットを書き込み又は読み取り又は読み取りに対する応答のどれかとして指定し、データ値のカウントを提供する１６ビット符号なし整数を含む２バイト。

ＢｉｔＢｉｔｓ１５から１４―読み取り／書き込みフラグ
ＢｉｔＢｉｔｓ［１５：１４］＝１０―ホストこれは（Ｈｏｓｔｔｈｉｓ）レジスタアドレスフィールドによりアドレス指定される１台又は複数台のレジスタからのデータに対する要求である。

ＢｉｔＢＩｔｓ［１５：１４］＝００―ｗｒｉｔｅｔｈｉｓパケットは、レジスタアクセスフィールドによってアドレス指定されるレジスタに書き込まれるデータを含む。指定されたレジスタに書き込まれるデータはレジスタデータフィールドに含まれる。

ＢｉｔＢｉｔｓ［１５：１４］＝１１―ｔｈａｔｃｏｎｔａｉｎｈｉｓパケットは、読み取り／書き込みフラグを１０に設定させるレジスタアクセスパケットに応えて要求されたデータを含む。レジスタアクセスフィールドは、第１のレジスタデータアイテムに対応するレジスタのアドレスを含むものとし、レジスタデータフィールドは１つ又は複数のアドレスから読み取られたデータを含むものとする。

ＢｉｔＢｉｔｓ［１５：１４］＝１０―この値は、将来の使用に確保され、使用されないものとする。

ビット１３：０―レジスタデータリストフィールドで転送される３２ビットレジスタデータアイテムの数を指定する１４ビット符号なし整数。

ビット１５がホストにより送信されるパケットの中で０である場合には、ビット１３：０は、レジスタアドレスフィールドによって指定されるレジスタで開始するクライアントレジスタに書き込まれるパケットのレジスタデータリストフィールドに含まれるレジスタデータアイテムの数を指定する。

ビット１５がホストにより送信されるパケット内で１である場合、ビット１３：０はクライアントがホストに送信するものとするレジスタデータアイテム数を指定する。ホストによって送信されるレジスタデータフィールドは、アイテムを含まないものとし、ゼロ長である。

ビット１５がクライアントにより送信されるパケット内で１である場合には、ビット１３：０はレジスタデータリストフィールドに含まれるレジスタデータアイテム数を指定する。

ビット１５はクライアントによって送信されるパケットの０に設定されないものとする。これは有効な値ではない。

レジスタアドレス―書き込まれる、又は読み取られるレジスタアドレスを含む３２ビット符号なし整数を含む４バイト。そのアドレス指定が３２ビット未満である、アドレス指定の場合、上部ビットがゼロに設定されるものとする。

レジスタデータリスト―クライアントデバイスレジスタから読み取られたクライアントレジスタ又は値に書き込まれる４バイトのレジスタデータ値のリスト。

フレーム同期パケット
フレーム同期パケットとは、ホストにラスタ画像の開始を示す能力を与え、クライアントがビデオストリームパケット内のピクセル及びウィンドウアドレス指定能力を使用するのを回避できるようにする。これは、画像の各フレームの開始時にフレーム同期パケットを送信することによって達成され、その結果（ビット５がピクセルデータ属性フィールドに設定された）１つのビデオストリームパケットが画像データの各行について送信される。一実施形態においては、クライアントは表示能力パケットの表示特徴能力インジケータのフィールドのビット２３を使用してフレーム同期パケットをサポートする能力を示す。

フォーマット

パケット図１５

パケットタイプ―１６ビット符号なし整数を含む２バイト。１４７というパケットタイプはフレーム同期パケットとしてパケットを識別する。

ｂＣｌｉｅｎｔＩＤ―クライアントＩＤに確保される１６ビット符号なし整数を含む２バイト。

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

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

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

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

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

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

ある実施形態で使用するために、パケットのＣＲＣ部分がエラーコード情報を転送するために使用される新しい技法が開発された。これは全体的に図６５に示されている。つまり、１つ又は複数のエラーコードが通信処理又はリンク内で発生する可能性のある特定の所定のラー又は欠陥を示すデータ転送を処理するプロセス又はデバイスによって生成される。エラーに遭遇すると、その適切なエラーコードが生成され、パケットのＣＲＣのためのビットを使用して転送され、つまり、ＣＲＣ値は、ＣＲＣフィールドの値を監視するエラーモニタ又はチェッカによって受信端で検出できる所望されるエラーコードでオーバロードされ、又は上書きされる。エラーコードが何らかの理由からＣＲＣ値に一致するそれらのケースでは、エラーのコンプリメントが混乱を防止するために転送される。

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

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

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

選択された１つ又は複数のエラーコードが転送されるＣＲＣ値と同じであるかどうかを確かめるためにチェックするためのＣＲＣ値コンパレータ又は比較手段６６０６が示される。それが当てはまる場合には、コードコンプリメントジェネレータ又は作成手段又はデバイスが、オリジナルのＣＲＣパターン又は値として間違われず、検出方式を混乱させる又は複雑化することなくエラーコードのコンプリメントを提供するために使用される。エラーコードセレクタ又は選択手段エレメント又はデバイス６６１０は、次に、挿入する又は上書きすることが所望されるエラーコード又は値、又はそのそれぞれのコンプリメントを適宜に選択する。エラーコードＣＲＣ上書き器（ｏｖｅｒ−ｗｒｉｔｅｒ）又は上書き機構又は手段６６１２は、デーアストリーム、パケット及び挿入される所望されるコードを受け取り、所望されるエラーコードを受信装置に転送するために、対応する又は適切なＣＲＣ値を上書きするデバイスである。

言及されたように、エラーコードは、一連のパケットを使用して複数回転送されてよく、したがって上書き器６６１２は処理中にコードのコピーを維持する、あるいはその値を必要に応じて、あるいは所望されるように記憶する、又は保持するために使用できる前記エレメント又は他の公知の記憶場所からこれらのコードをリコールするために記憶装置要素を活用してよい。

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

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

Ｖ．ハイバネーションからのリンク再開
ホストは、ハイバネーション状態から順方向リンクを再開すると、約１５０μｓｅｃの間論理１状態にＭＤＤＩ＿Ｄａｔａを駆動してから、ＭＤＤＩ＿Ｓｔｂをアクティブ化し、同時にＭＤＤＩ＿Ｄａｔａを５０μｓｅｃの間論理ゼロ状態に駆動してから、サブフレームヘッダパケットを送信することによって順方向リンクトラフィックを開始する。これによって、通常、信号間に十分な整定時間を提供することによってサブフレームヘッダパケットが送信される前にバス競合を解決できる。

クライアント、ここではディスプレイがホストからのデータ又は通信を必要とするとき、それは、他の期間も所望されるように使用できるが、約７０μｓｅｃの間、ＭＤＤＩ＿Ｄａｔａ０ラインを論理１状態に駆動し、次にそれを高インピーダンス状態にすることによってドライバをディスエーブルする。このアクションによって、ホストは順方向リンク（２０８）でデータトラフィックを開始又は再開させ、そのステータスについてクライアントをポーリングさせる。ホストは、５０μｓｅｃの間に要求パルスの存在を検出し、次にＭＤＤＩ＿Ｄａｔａ０を１５０μｓｅｃの間論理１に、及び５０μｓｅｃの間論理ゼロに駆動する起動シーケンスを開始しなければならない。ディスプレイは、それが５０μｓｅｃを超えて論理１状態のＭＤＤＩ＿Ｄａｔａ０を検出すると、サービス要求パルスを送信してはならない。ハイバネーション処理及び起動シーケンスに関する時間の選択及び時間間隔の公差が後述される。

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

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

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

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

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

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

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

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

ウェークアップ処理のこの新しいインプリメンテーションの利点は、それが時間測定装置に対するニーズを削除する点である。これが発振器であるのか、あるいはコンデンサ放電回路であるのか、あるいは他のこのような公知のデバイスであるのかに関係なく、クライアントは起動状態を決定するためにこのような外部装置を必要としていない。これによりコントローラ、カウンタ等をクライアントデバイス基板上に実現するときに金額と回路面積が削減される。これはクライアントにとって有利ではない可能性があるが、ホストにとっては、この技法はコア回路網に使用されている超高密度ロジック（ｖｅｒｙｈｉｇｈｄｅｎｓｉｔｙｌｏｇｉｃ）（ＶＨＤＬ）に関してホストを潜在的に簡略化するだろう。データラインとストローブラインをウェークアップ通知測定ソースとして使用することの電力消費量も、ホストベースのウェークアップを待機するコア要素のために外部回路を実行する必要がないため、さらに低くなるであろう。

使用されるサイクル数又はクロック期間は例示的であり、当業者に明らかになるように他の期間を使用することもできる。

ウェークアップ処理のこの新しいインプリメンテーションの利点は、それが時間測定装置に対する必要性を削除するという点である。これが発振器であるのか、あるいはコンデンサ放電回路であるのか、あるいは他のこのような公知のデバイスであるのかに関係なく、クライアントは起動状態を決定するためにこのような外部装置の必要がなくなった。これによりコントローラ、カウンタ等をクライアントデバイス基板上に実現するときに金額と回路面積が削減される。これはクライアントにとって有利ではない可能性があるが、ホストにとっては、この技法はコア回路網に使用されている超高密度ロジック（ｖｅｒｙｈｉｇｈｄｅｎｓｉｔｙｌｏｇｉｃ）（ＶＨＤＬ）に関してホストを潜在的に簡略化するだろう。データラインとストローブラインをウェークアップ通知測定ソースとして使用することの電力消費量も、ホストベースのウェークアップを待機するコア要素のために外部回路を実行する必要がないため、さらに低くなるであろう。

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

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

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

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

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

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

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

しばらくしてから、クライアントは、ホストがそのＭＤＤＩ＿Ｓｔｂドライバをイネーブルする前にＭＤＤＩ＿Ｓｔｂの受信されたバージョンの状態がクライアント内で論理ゼロレベルであることを保証するために、ＭＤＤＬ＿Ｓｔｂ受信機をイネーブルし、ＭＤＤＩ＿Ｓｔｂ受信機のオフセットもイネーブルすることによって、点Ｄでリンク再起動シーケンスを開始する。クライアントが、受信機が有効な差動信号の受信を確実にし、所望されるように誤った信号を抑制することができるようにするわずかに前に、オフセットをイネーブルすることが望ましい場合がある。クライアントは、ＭＤＤＩ＿Ｄａｔａ０ラインを論理１レベルに駆動する間に、ＭＤＤＩ＿Ｄａｔａ０ドライバをイネーブルする。

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

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

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

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

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

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

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

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

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

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

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

ＭＤＤＩデータ組、ＭＤＤＩ＿Ｓｔｂ＋信号とＭＤＤＩ＿Ｓｔｂ−信号は、雑音のマイナス影響からの免疫性を最大限にするために差動モードで操作される。差動信号経路の各部はソース終端され、ケーブル又は導線の特性インピーダンスの２分の１は信号を転送するために使用される。ＭＤＤＩデータ組は、ホスト端部とクライアント端部の両方で終端する。これらの２つのドライバの内の一方だけしか既定のときにアクティブでないため、終端は転送リンクのためのソースに継続的に存在する。ＭＤＤＩ＿Ｓｔｂ＋信号とＭＤＤＩ＿Ｓｔｂ−信号はホストによってだけ駆動される。

ＭＤＤＩ＿ＤａｔａとＭＤＤＩ＿Ｓｔｂの対応するＤＣ電気仕様は表ＩＩに示されているが、本発明のＭＤＤインタフェースの一部として信号を転送するためのドライバ、受信機、及び終端を達成するために有効な要素の例示的な構成は図４２に示されている。例示的なインタフェースは、ここでは２００ｍＶ、１ボルト未満の脱調、及び低電力排出の低圧検知を使用する。

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

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

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

図４２では、ホストコントローラ４２０２とクライアントコントローラ又はディスプレイコントローラ４２０４が、通信リンク４２０６上でパケットを転送していると示されている。ホストコントローラは、転送されるクライアントデータ信号を受信するためだけではなく、転送されるホストＤＡＴＡ信号とＳＴ信号を受信するためにも、一連の３台のドライバ４２１０、４２１２、４２１４を利用する。ホストＤＡＴＡの通過に関与するドライバは、通常ホストからクライアントへの転送が所望されるときにだけ通信リンクの活性化を可能にするイネーブル信号入力を利用する。ＳＴＢ信号はデータの転送の一部として形成されるため、追加のケーブル信号はそのドライバ（４２１２）について利用されない。ＤＡＴＡドライバとＳＴＢドライバのそれぞれの出力は、それぞれ終端インピーダンスつまり抵抗器４２１６ａ、４２１６ｂ、４２１６ｃ及び４２１６ｄに接続される。

追加の終端抵抗４２１６ｅと４２１６ｆはクライアントデータ処理受信機４２２２の入力でそれぞれ抵抗器４２１６ｃと４２１６ｄと直列で配置されるが、終端抵抗４２１６ａと４２１６ｂも、ＳＴＢ信号処理のためのクライアント側受信機４２２０の入力でインピーダンスとして作用する。クライアントコントローラの第６のドライバ４２２６は、クライアントからホストに転送されるデータ信号を作製するために使用され、ドライバ４２１４は、終端抵抗４２１６ｃと４２１６ｄを通して、入力側で、処理のためのホストへの転送のためにデータを処理する。

２つの追加抵抗器４２１８ａと４２１８ｂは、他の個所で説明されるハイバネーション制御の一部として、それぞれ終端抵抗と接地と電圧ソース４２２０の間に配置される。電圧源は、データの流れを管理するために前述された高レベル又は低レベルとなるように転送ラインを駆動するために使用される。

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

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

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

図４３に示されるように、クライアントからの信号出力は当初ゼロという論例レベルで設定される。言い換えると、クライアント出力が高インピーダンスにあり、ドライバはディスエーブルされている。サービスが要求されているとき、クライアントはそのドライバをイネーブルし、ホストに、ラインがその間に論理１レベルに駆動される期間、指定ｔｓｅｒｖｉｃｅであるサービス要求を送信する。それからホストがｔｈｏｓｔ−ｄｅｔｅｃｔと呼ばれる要求を検出する前に、特定の時間が経過する、あるいは必要とされる場合があり、その後ホストは信号を論理１レベルに駆動することによってリンク起動シーケンスで応答する。この時点で、クライアントは要求をアサート停止し、クライアントからの出力ラインが再びゼロ論理レベルになるようにサービス要求ドライバをディスエーブルする。この時間の間、ＭＤＤＩ＿Ｓｔｂ信号は論理ゼロレベルにある。

ホストは、ｔｒｅｓｔａｒｔ−ｈｉｇｈと呼ばれる期間、「１」レベルとしてホストデータ出力を駆動し、その後、ホストは論理レベルをゼロに駆動し、ｔｒｅｓｔａｒｔ−ｌｏｗと呼ばれる期間、ＭＤＤＩ＿Ｓｔｂをアクティブ化し、その後、第１の順方向トラフィックがサブフレームヘッダパケットで開始し、順方向トラフィックパケットが次に転送される。ＭＤＤＩ＿Ｓｔｂ信号はｔｒｅｓｔａｒｔ−ｌｏｗと以後のサブフレームヘッダパケットの期間中アクティブである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

システムが「非同期」以外の状態にある各状況では、一意のワードが検出され、良好なＣＲＣ結果がサブフレームヘッダパケットに対して決定され、サブフレーム長がゼロより大きいときには、インタフェース状態が「同期中」状態４９０８に変更される。処理のこのステップは、図４９でｃｏｎｄ１つまり条件１に遭遇したと呼ばれる。他方、サブフレームヘッダパケットの中の一意のワード又はＣＲＣのどちらかが正しくないと、同期状態処理は「ＮＯＳＹＮＣＦＲＡＭＥ（同期フレームなし）」状態のインタフェース状態４９０２に進む、又は戻る。処理のこの部分は、図４９の状態図のｃｏｎｄ２、つまり条件２に遭遇したと呼ばれる。

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

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

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

ディスプレイが順方向リンク信号に同期するために要する時間は、サブフレームサイズと順方向リンクデータレートに応じて可変である。一意のワードの「偽のコピー」を順方向リンクの無作為な、あるいはさらに無作為なデータの一部として検出する尤度は、サブフレームサイズが大きくなるにつれて高くなる。同時に、順方向リンクデータレートが低速化すると、偽検出から回復する能力は低くなり、そのようにするのに要する時間は長くなる。

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

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

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

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

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

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

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

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

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

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

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

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

インタフェースを通した信号遅延の実際の長さは、使用されているそれぞれの特定のホストクライアントシステム又はハードウェアに応じて異なってよいことに注意されたい。必要とされないが、逆方向レート除数が最適値に設定できるように、システム内の実際の遅延を測定するために往復遅延測定パケットを使用することによって、各システムはさらによく実行させることができる。

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

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

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

既定の例の場合、これは以下になる。

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

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

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

パケット長＝１０２４（０ｘ０４００）ターンアラウンド１長＝１
パケットタイプ＝６５（０ｘ４１）ターンアラウンド２長＝１
逆方向リンクフラグ＝０逆方向レート除数＝２
パラメータＣＲＣ＝０ｘｄｂ４３全ゼロは０ｘ００である
パケット長フィールドとパラメータＣＲＣフィールドの間のパケットデータは以下のとおりである。

０ｘ００，０ｘ０４，０ｘ４１，０ｘ００，０ｘ０２，０ｘ０１，０ｘ０１，０ｘ４３，０ｘｄｂ，０ｘ００，．．．
ディスプレイから戻される第１の逆方向リンクパケットは、パケット長が７、パケットタイプが７０の表示要求ステータスパケットである。このパケットはバイト値０ｘ０７、０ｘ００、０ｘ４６．．．等で開始する。しかしながら、最初のバイト（０ｘ０７）だけが図５４で可視である。この第１の逆方向リンクパケットは、実際の逆方向リンク遅延を示すために図中ほぼ１逆方向リンククロックで時分割される。ホストからディスプレイ往復遅延がゼロの理想的な波形は点線のトレースで示されている。

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

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

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

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

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

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

ターンアラウンド１の許容値範囲は以下の関係性に従って表され、

インタフェース型係数は、Ｉ型の場合１、ＩＩ型の場合２、ＩＩＩ型の場合４、及びＩＶ型の場合８である。

前記からの２つの方程式を結合すると、インタフェース型係数の項が無効になり、ターンラウンド１が以下のように定義される。

例えば、１５００ＭｂｐｓＩＩＩ型順方向リンクは以下のターンアラウンド１遅延を使用するであろう。

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

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

ターンアラウンド２の許容値範囲は、以下のように表される。

例えば、１０順方向リンククロックという往復遅延のある１５００ＭｂｐｓＩＩＩ型順方向リンクは、通常、以下に似通ったターンアラウンド２遅延を使用する。

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

前記に提示されたように、逆方向リンクに対するタイミングについての前記の手法は、クロックサイクルの数が、第１のビットがＩＯクロックの立ち上がりでサンプリングされるまで、クロックサイクル数が逆方向タイミングパケットのガードタイム１の最後のビットからカウントされるように構成される。これが、ＭＤＤインタフェースについての入力および出力の時間を計ることに使われるクロックシグナルである。逆方向レート除数のための計算は以下によって示される。

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

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

到着する逆方向ビットと、そのビットが多様な逆方向レート除数をどのようにして探すのかの例が、ガードタイム１の最後のビット以来発生したクロックサイクル数とともに、図６４に描かれる。図６４では、（上昇／下降と呼ばれる）立ち上がりと立下りの間で第１のエッジが発生すると、それは逆方向ビットの期間内に発生するただ１つの立ち上がりであるため、１という逆方向レート除数のための最適サンプリング点が「ｂ」と呼ばれるクロックサイクルエッジであることが分かる。２という逆方向レート除数の場合、サイクルエッジ「ｃ」は「ｂ」よりビットエッジに近いため、最適サンプリング点はおそらく依然としてクロックサイクル前縁「ｂ」である。４という逆方向レート除数の場合、それは、値がおそらく安定化した逆方向ビットの後端により近いため、最適サンプリング点はおそらくクロックサイクルエッジ「ｄ」である。

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

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

ホストは、データラインでタイミングパケットデータのデータ立ち上がりが観測されるまでクロック立ち上がりの数を発見するためにこの技法を使用できる。したがって、ホストは、エッジが立ち上がりと立ち下がりの間で発生するのか、それとも立下りと立ち上がりの間で発生するのか及び逆方向レート除数がいくつであるのかに基づいて、ビットがつねに可能な限り真中近くでサンプリングされることを無理なく確実にするために、番号カウンタにいくつの追加クロックサイクルを追加するのかを決定できる。

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

この方法は、逆方向タイミングが初期の往復タイミング推定値から変化してはならないため効果的且つ有用である。順方向リンクが安定している場合には、クライアントは、逆方向リンクの失敗があるとしても、順方向リンクパケットの復号を続ける必要がある。言うまでもなく、この方法は完全な逆方向リンクを保証しないため、リンクに逆方向リンク除数を設定することは依然としてホストの責任である。加えて、除数はおもにＩＯクロックを生成するために使用されるクロックの品質に依存する。そのクロックに十分な量のジッタがある場合には、サンプリングエラーの可能性は大きくなる。このエラーの蓋然性は、往復遅延でのクロックサイクル量とともに上昇する。

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

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

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

インタフェースを通る例示的な信号処理のためのＩ型リンクでのデータ、Ｓｔｂ及びクロック回復タイミングは、図５８に描かれる。

大きい層遅延歪みは、以下の段階での歪みの合計から生じる、又は由来する。つまり、フリップフロップ５７０４、５７０６付きの送信機フリップフロップ（ＴＸＦＦ）、ドライバ５７０８、５７１０付きの送信機ドライバ（ＴＸＤＲＶＲ）、ケーブル５７０２、受信機５７２２、５７２４付きの受信機ラインレシーバ（ＲＸＲＣＶＲ）、受信機ＸＯＲ論理（ＲＸＸＯＲ）である。Ｄｅｌａｙ１５７３２ａは、以下の関係性により決定されるＲＸＸＯＲ段階でのＸＯＲゲート５７３６の遅延に一致する、又は超える必要がある。

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

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

多くのシステムでは、保持時間がゼロであるためゼロになり、言うまでもなくそのケースではＤｅｌａｙ２の最大遅延もゼロである場合がある。

受信機ＸＯＲ段階での歪みに対する最悪の場合の寄与は、Ｄｅｌａｙ１が最大値となり、ＸＯＲゲートからのクロック出力が以下の関係性に従って可能な限り早期に出現するデータ−遅延／ストローブ−早期のケースである。

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

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

最小ビット期間は以下によって示される。

図５７に示される例では、ｔ_{ＳＫＥＷ−ｍａｘ（ＬＩＮＫ）}＝１．４ｎｓｅｃであり、最小ビット期間は以下のように表すことができる。

あるいは約４１６Ｍｂｐｓと述べられる。

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

ＭＤＤＩ＿ＤａｔａＸが可能な限り早く到達するときにＲＸＦＦＢで確実にデータをサンプリングするために、Ｄｅｌａｙ３は以下の関係性に従って設定される。

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

リンク速度の上限は以下のとおりであり、

以下の仮定を考慮する。

前述の例では、最小ビット期間の下限は以下の関係性によって示され、

約２０８Ｍｂｐｓである。

これは、Ｉ型リンクで使用できる最大データレートよりはるかに低速である。ＭＤＤＩの自動遅延歪み補償能力は、遅延歪みが最大リンクレートに及ぼす影響を著しく削減する。

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

シールドは、ホストインタフェース内でＭＤＤＩ＿Ｇｎｄに接続され、ケーブル内のシールドドレインワイヤはディスプレイコネクタのシールドに接続される。しかしながら、シールドとドレインワイヤはディスプレイ内部の回路接地に接続されない。

相互接続要素又はデバイスは、相対的なデバイスサイズと比較してひどく目立ったり、趣味が悪くなることなく、ＰＤＡと無線電話、又は携帯ゲーム機などのモバイル通信及びコンピュータデバイスと使用するために十分に小型となるために選ばれる、又は設計される。あらゆるコネクタとケーブル布線は典型的な消費者環境での使用に十分に耐久性があり、特にケーブル布線のために小さいサイズに対処し、相対的に低価格でなければならない。転送要素は、Ｉ型とＩＩ型の場合約４５０Ｍｂｐｓまで、８ビット並列ＩＶ型バージョンの場合３．６Ｇｂｐｓまでの転送レートを有する差動ＮＲＺデータであるデータ信号とストローブ信号に対処しなければならない。

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

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

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

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

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

動作中、インタフェースモードの異なるデータレート又はタイプを所望するホスト又はクライアントにつながる複数の異なるイベントの１つが発生する場合がある。例えば、コンピュータ又はデータを通信する他のデバイスは、パケットの作成又は提示において減速を引き起こすデータを処理する上での荷重条件に遭遇することがあるであろう。データを受信するディスプレイは、専用ＡＣ電源からさらに制限されたバッテリ電源に変更することができ、迅速にデータを転送し、コマンドを容易に処理することはできない、あるいはさらに制限された電力設定値の下で同じ程度の解像度又はカラー階調を使用することはできないであろう。代わりに、制限条件は和らげられるあるいは消滅し、どちらかのデバイスがさらに高速でデータを転送できるようになる。これがより望ましく、より高速の転送速度モードに変更するように要求できる。

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

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

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

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

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

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

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

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

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

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

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

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

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

パケット図１６

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

部分的な画像を表示するのを回避するために、表示リフレッシュフレームレートが画像転送フレームレートより大きくなることが必要である。図９３は、低速表示リフレッシュ速度で画像断片化がどのようにして発生するのか、つまり表示リフレッシュが画像転送より遅いことを示す。

パケット図１７

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

パケット図１８

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

パケット図１９

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

パケット図２０

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

パケット図２１

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

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

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

ＸＶＩＩＩ．複数のクライアントサポート
現在のプロトコルバージョンは、複数のクライアントデバイスを直接的にサポートしていないように見える。しかしながら、大部分のパケットは、複数のクライアントがいるシステムの中で特定のクライアントデバイスに対処するために使用できる確保されたクライアントＩＤフィールドを含む。現在、多くの応用例では、この１つの又はこれらの複数のクライアントＩＤがゼロになるように設定される。サブフレームヘッダパケットは、ホストが複数クライアントシステムをサポートするかどうかを示すためのフィールドも含む。したがって、複数のクライアントデバイスが、複数のクライアントホストとクライアントとの将来の互換性についてシステム設計者が計画するのを支援するために、ＭＤＤインタフェース又はプロトコルの将来の応用例で接続され、対処されるであろう方法がある。

複数のクライアントを有するシステムでは、クライアントのデイジーチェーンを介して、又はハブを使用してクライアントがホストに接続されるのが有効である。

ＸＶＩＩＩ．補遺
本発明の実施形態のためのアーキテクチャ及びプロトコルを実現するために使用される多様なパケットのために前述されたフォーマット、構造及びコンテンツに加えて、パケットタイプのいくつかについて、さらに詳細なフィールドコンテンツ又は動作がここに提示される。これらは、当業者が種々の応用例のために本発明をさらに容易に理解し、利用できるようにするためにそのそれぞれの用途又は動作をさらに明確にするためにここに提示される。すでに説明されていないフィールドの数個だけがここでさらに説明される。加えて、これらのフィールドには、前記に提示された実施形態に関連して、例示的な定義と値が提示される。しかしながら、このような値は本発明の制限として解釈されるべきではなく、インタフェースとプロトコルを実現するために有効な１つ又は複数の実施形態を表し、すべての実施形態がともに、あるいは同時に実践される必要はない。当業者によって理解されるように、データ又はデータレート転送結果の所望される提示を達成するために他の値を他の実施形態で使用することができる。

Ａ．ビデオストリームパケット用
ある実施形態では、ピクセルデータ属性フィールド（２バイト）は、以下のように解釈される一連のビット値を有する。ビット１とビット０は、表示ピクセルデータがどのように送信されるのかを選択する。「１１」というビット値の場合、データは両目に対して、又は両目のために表示され、ビット値「１０」の場合は、データは左眼だけに送られ、ビット値「０１」の場合、データは右目だけに送られ、「００」というビット値の場合、データは、後述されるビット８から１１によって指定されてよいように代替ディスプレイに送られる。

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

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

ビット５は、ピクセルデータが、いつディスプレイの中のピクセルの次の連続行を含むのかを示すために使用される。これは、ビット５が「１」に等しく設定されるときのケースと考えられる。ビット５が「１」に設定されると、Ｘ左端縁パラメータ、Ｙ上端縁パラメータ、Ｘ右端縁パラメータ、Ｙ下端縁パラメータ、Ｘ開始パラメータ、及びＹ開始パラメータは定義されず、クライアントによって無視される。フレーム同期パケットは、画像の一番上の行となるように次の行を定義する。

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

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

ビット１２から１５は将来の使用に確保され、通常ゼロとして設定される。

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

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

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

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

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

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

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

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

サンプルあたりビット及び圧縮フィールドは、音声データの圧縮フォーマットを指定する１バイトを含む。一実施形態では、概して利用されるフォーマットは、ＰＣＭ音声サンプルあたりのビット数を定めるためのビット４から０用である。ビット５は、次にデジタル音声データサンプルが圧縮されるかどうかを指定する。前述されたように、図１２は圧縮された音声サンプルとバイト位置合わせされた音声サンプルの差異を描く。ビット５の「０」という値は、デジタル音声データフィールドの中の各ＰＣＭ音声サンプルがインタフェースバイト境界とバイト位置合わせされることを示し、「１」という値が、各連続ＰＣＭ音声サンプルが前の音声サンプルに照らし合わせて圧縮されることを示す。このビットは、ビット４から０に定められる値（ＰＣＭ音声サンプルあたりのビット数）が８の倍数ではないときにのみ効果的である。ビット７から６は、システム設計が追加の指定を所望する場合に使用するために確保され、通常ゼロという値に設定される。

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

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

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

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

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

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

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

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

各カラーマップデータアイテムは次の順序で送信されなければならない。つまり、青、緑、赤で、各成分の最下位ビットが最初に送信される。各カラーマップアイテムの個々の赤、緑及び青の成分は圧縮されるものとするが、各カラーマップアイテム（青の成分の最下位ビット）はバイト位置合わせされる必要がある。Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅｓｏｕｒｃｅｎｏｔｆｏｕｎｄ．（エラー！情報源が検出されない）（新しいＺ）は、６ビットの青、８ビットの緑及び７ビットの赤のあるカラーマップデータアイテムの一例を示す。この例の場合、カラーマップパケットのカラーマップアイテムサイズは２１に等しく、表示能力パケットのカラーマップＲＧＢ幅フィールドは０ｘ０７８６に等しい。

パケット図２２

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

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

逆方向レート除数フィールド（１バイト）は、逆方向リンクデータクロックに関して発生するＭＤＤＩ＿Ｓｔｂサイクル数を指定する。逆方向リンクデータクロックは、２倍された逆方向レート除数（ｔｗｏｔｉｍｅｓｔｈｅＲｅｖｅｒｓｅＲａｔｅＤｉｖｉｓｏｒ）で除算された順方向リンクデータクロックに等しい。逆方向リンクデータレートは、逆方向リンクでの逆方向リンクデータクロックとインタフェースタイプに関連する。Ｉ型インタフェースの場合、逆方向データレートは、逆方向リンクデータクロックに等しく、ＩＩ型、ＩＩＩ型、及びＩＶ型のインタフェースの場合、逆方向データレートは、それぞれ逆方向リンクデータクロックの２倍、４倍及び８倍に等しい。

全ゼロ１フィールドは、論理ゼロレベルでビットを設定することによって値のゼロに等しく設定されるバイトのグループを含み、すべてのＭＤＤＩ＿Ｄａｔａ信号が、第１のガード時間期間の間にラインドライバをディスエーブルする前にゼロ状態にあり、反映された論理１レベルが、ターンアラウンド１フィールドの間にホストのラインドライバをディスエーブルする前に消失できることを確実にするために使用される。一実施形態では、全ゼロ１フィールドの長さはケーブルの往復遅延の順方向リンクバイト伝送回数より大きい、又は等しい。

ターンアラウンド１長フィールド（１バイト）はターンアラウンド１に割り当てられ、第１のターンアラウンド期間を確立するバイト総数を指定する。ターンアラウンド長パラメータにより指定されるバイト数は、ホスト内のＭＤＤＩ＿Ｄａｔａラインドライバが、クライアント内のラインドライバがイネーブルされる前にディスエーブルできるようにするために割り当てられる。ホストは、ターンアラウンド１のビット０の間にそのＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブルし、クライアントはその出力をイネーブルし、ターンアラウンド１の最後のビットの間にＭＤＤＩ＿Ｄａｔａ０を論理０に駆動する。ＭＤＤＩ＿Ｓｔｂ信号は、ターンアラウンド１期間がすべてゼロであるかのように動作する．ターンアラウンド１の推奨される長さは、ホスト内のＭＤＤＩ＿Ｄａｔａドライバが出力をディスエーブルさせるために必要とされるバイト数である。これは、前述された出力ディスエーブル時間、順方向リンクデータレート及び使用されている順方向リンクインタフェースタイプ選択に基づいている。ターンアラウンド１の設定値のさらに完全な説明は前述される。

全ゼロ２フィールドは、ビットを論理ゼロレベルで設定することによってゼロに等しく設定されるバイトのグループを含み、すべてのＭＤＤＩ＿Ｄａｔａ信号がゼロ状態にあり、ターンアラウンド１フィールドの間にホストのラインドライバをディスエーブルする前に反映された論理１レベルが消失できることを確実にするために使用される。一実施形態では、全ゼロ２フィールドの長さは、ケーブルの往復遅延の順方向リンクバイト伝送回数より大きい又は等しい。

ターンアラウンド２長フィールド（１バイト）は第２のターンアラウンド期間を確立するためにターンアラウンド２に割り当てられるバイトの総数を指定する。バイト数はターンアラウンド長パラメータによって指定されクライアントの中のＭＤＤＩ＿Ｄａｔａラインドライバがホスト内のラインドライバがイネーブルされる前にディスエーブルできるために割り当てられる。クライアントはターンアラウンド２のビット０の間にそのＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブルし、ホストはその出力をイネーブルし、ターンアラウンド２の最後のビットの間にＭＤＤＩ＿Ｄａｔａ０を論理０に駆動する。ＭＤＤＩ＿Ｓｔｂ信号は、ＭＤＤＩ＿Ｄａｔａ０があたかもターンアラウンド２期間全体で論理ゼロレベルにあるかのように動作する。ターンアラウンド２の推奨される長さは、ディスプレイのＭＤＤＩ＿Ｄａｔａドライバが、往復遅延が加えられたその出力をディスエーブルするのに要するバイト数である。ターンアラウンド２の設定値の説明は前述される。

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

ドライバ再イネーブルフィールドは、すべてのＭＤＤＩ＿Ｄａｔａ信号が、次のパケットのパケット長フィールドの前に再イネーブルされることを確実にするために論理ゼロに等しい１バイトを使用する。

Ｆ．表示能力パケット用
一実施形態では、プロトコルバージョンフィールドが、クライアントによって使用されるプロトコルバージョンを指定するために２バイトを使用する。最小プロトコルバージョンフィールドは、クライアントが利用する又は解釈することができる最小のプロトコルバージョンを指定するために２バイトを使用するが、初期バージョンはゼロに等しく設定される。表示データレート能力フィールド（２バイト）は、インタフェースの順方向リンクでディスプレイが受信できる最大データレートを指定し、毎秒メガビット（Ｍｂｐｓ）の形で指定される。インタフェースタイプ能力フィールド（１バイト）は、順方向リンクと逆方向リンクでサポートされるインタフェースタイプを指定する。これは、それぞれ順方向リンク上でＩＩ型モード、ＩＩＩ型モード、又はＩＶ型モードのどれかを選択するためにビット０、ビット１、ビット２を、及びそれぞれ逆方向リンクでＩＩ型、ＩＩＩ型、又はＩＶ型モードのどれかを選択するためにビット３、ビット４又はビット５を選択することによって現在示される。ビット６と７は確保され、ゼロに設定されている。ビットマップ幅高さフィールド（２バイト）は、ピクセル単位でビットマップの幅と高さを指定する。

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

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

ＲＧＢ能力フィールド（２バイト）は、ＲＧＢフォーマットで表示できる解像度のビット数を指定する。ディスプレイがＲＧＢフォーマットを使用できない場合は、この値はゼロに等しい。ＲＧＢ能力ワードは３つの別々の符号なし値から構成される。つまり、各ピクセルにおいて、ビット３から０は青の最大ビット数を定め、ビット７から４は緑の最大ビット数を定め、ビット１１から８は赤の最大ビット数を定める。現在、ビット１５から１２は将来の使用に確保され、通常ゼロに設定される。

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

ディスプレイ機能能力インジケータフィールドは、サポートされるディスプレイの特定の機能を示すフラグのセットを含む４バイトを使用する。１に設定されるビットは、能力がサポートされていることを示し、ゼロに設定されるビットは能力がサポートされていないことを示す。ビット０の値は、ビットマップブロック転送パケット（パケットタイプ７１）がサポートされているかどうかを示す。ビット１、２、３の値は、ビットマップ領域塗りつぶしパケット（パケットタイプ７２）、ビットマップパターン塗りつぶしパケット（パケットタイプ７３）、又は通信リンクデータチャネルパケット（パケットタイプ７４）がそれぞれサポートされているか否かを示す。ビット４はディスプレイに１つの色を透明にする能力があるかどうかを示し、ビット５と６の値は、ディスプレイがそれぞれ圧縮形式のビデオデータそれとも音声データを受け入れることができるのか示し、ビット７の値は、ディスプレイがカメラから逆方向リンクビデオストリームを送信できるかどうかを示す。ビット１１と１２の値は、それぞれ、クライアントがいつポインティングデバイスと通信しており、ポインティングデバイスデータパケットを送受できるのか、あるいはキーボードを用いてキーボードデータパケットを送受できるのかを示す。ビット１３から３１は、現在、将来の使用又はシステム設計者にとって有効な代替の指定に確保され、通常ゼロに等しく設定される。

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

音声バッファ深度フィールド（２バイト）は、各音声ストリームに専用であるディスプレイのエラスティックバッファ（ｅｌａｓｔｉｃｂｕｆｆｅｒ）の深度を指定する。

音声チャネル能力フィールド（２バイト）は、ディスプレイ（クライアント）によってどの音声チャネルがサポートされているのかを示すフラグのグループを含む。１に設定されるビットは、チャネルがサポートされていることを示し、ゼロに設定されるビットは、チャネルがサポートされていないことを示す。ビット位置はさまざまなチャネルに割り当てられている。例えば、ビット位置０、１、２、３、４、５、６、７は、左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中心チャネル、サブウーファチャネル、サラウンド左チャネル、及びサラウンド右チャネルを示す。ビット８から１５は現在は将来の使用に確保され、通常ゼロに設定される。

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

最小サブフレームレートフィールド（２バイト）は、毎秒コマで最小サブフレーム速度を指定する。最小サブフレーム速度は、表示ステータスを、ディスプレイの特定のセンサ又はポインティングデバイスを読み取るのに十分な更新レートに保つ。

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

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

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

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

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

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

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

Ｊ．ビットマップパターン塗りつぶしパケット
ウィンドウ左上座標Ｘ値とＹ値フィールドは、塗りつぶされるウィンドウの左上角の座標のＸ値とＹ値を指定するためにそれぞれ２バイトを使用する。ウィンドウ幅フィールドと高さフィールド（各２バイト）は、塗りつぶされるウィンドウの幅と高さを指定する。パターン幅フィールドとパターン高さフィールド（各２バイト）は、塗りつぶしパターンのそれぞれ幅と高さを指定する。２バイトのビデオデータフォーマット記述子フィールドは、ピクセル領域塗りつぶし値のフォーマットを指定する。図１１は、ビデオデータフォーマット記述子がどのようにしてコード化されるのかを描く。フォーマットは、ビデオストリームパケットの同じフィールドと同じである。

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

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

通信リンクデータフィールドは、通信チャネルから未処理データを含む。このデータは、単にディスプレイ内でコンピュータデバイスに渡されるだけである。
通信リンクデータＣＲＣフィールド（２バイト）は、通信リンクデータだけの１６ビットＣＲＣを含む。ＣＲＣがチェックできない場合、通信リンクデータは依然として使用される又は有効であるが、ＣＲＣエラーカウントが増分される。

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

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

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

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

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

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

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

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

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

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

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

全ゼロフィールド（１バイト）は、第１のガードタイム期間中にラインドライバをディスエーブルする前にすべてのＭＤＤＩ＿Ｄａａ信号がゼロ状態にあることを確実にするためにゼロを含む。

ガードタイム１フィールド（８バイト）は、ホスト内のＭＤＤＩ＿Ｄａｔａラインドライバが、クライアント（ディスプレイ）内のラインドライバがイネーブルされる前にディスエーブルできるようにするために使用される。ホストは、ガードタイム１のビット０の間にそのＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブルし、ディスプレイは、ガードタイム１の最後のビットの直後にそのラインドライバをイネーブルする。

測定期間フィールドは、ディスプレイが順方向リンクで使用されるデータレートの半分で、０ｘｆｆ、０ｘｆｆ、０ｘ０で応答できるようにするために使用される５１２バイトのウィンドウである。この速度は、１という逆方向リンクレート除数に相当する。ディスプレイはこの応答を測定期間の始まりに即座に返す。この応答はホストでの測定期間の第１のビットの開始後に正確にリンクの往復遅延でホストで受信される。ディスプレイのＭＤＤＩ＿Ｄａｔａラインドライバは、ディスプレイからの０ｘｆｆ、０ｘｆｆ、０Ｘ００応答の直前と直後にディスエーブルされる。

ガードタイム２フィールド（８バイト）の値により、クライアントＭＤＤＩ＿Ｄａｔａラインドライバは、ホスト内のラインドライバがイネーブルされる前にディスエーブルできる。ガードタイム２は、つねに存在するが、往復遅延が、測定期間で測定できる最大量にあるときにだけ必要とされる。クライアントは、ガードタイム２のビット０の間にそのラインドライバをディスエーブルし、ホストはガードタイム２の最後のビットの直後にそのラインドライバをイネーブルする。

ドライバ再イネーブルフィールド（１バイト）は、すべてのＭＤＤＩ＿Ｄａｔａ信号が、次のパケットのパケット長フィールドの前に再イネーブルされることを確実にするために、ゼロに等しく設定される。

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

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

Ｉ型−０ｘａａ，０ｘａａ．．．または０ｘ５５，０ｘ５５．．．
ＩＩ型−０ｘｃｃ，０ｘｃｃ．．．または０ｘ３３，０ｘ３３．．．
ＩＩＩ型−０ｘｆ０，０ｘｆ０．．．または０ｘ０ｆ，０ｘ０ｆ．．．
ＩＶ型−０ｘｆｆ，０ｘ００，０ｘｆｆ，０ｘ００．．．または０ｘ００，０ｘｆｆ，０ｘ００，０ｘｆｆ．．．
Ｉ型インタフェースとＩＩ型インタフェースの両方の考えられるＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形の例は、それぞれ図６２Ａと図６２Ｂに示される。

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

Claims

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