JP2014053920A

JP2014053920A - 高データレートインターフェース装置および方法

Info

Publication number: JP2014053920A
Application number: JP2013209726A
Authority: JP
Inventors: Jon James Anderson; ジョン・ジェームズ・アンダーソン; Steel Brian; ブライアン・スティール; A Wiley George; ジョージ・エー．・ウィレイ; Shashank Shekhar; シャシャンク・シェカー
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2004-03-24
Filing date: 2013-10-04
Publication date: 2014-03-20
Also published as: KR101019935B1; WO2005096594A1; CN1961560B; JP2011019255A; US8645566B2; CA2560744C; TW200620899A; US20050259670A1; CN1961560A; EP1735988A1; AU2005227500A1; JP5453197B2; IL178256A0; RU2006137364A; MXPA06010873A; KR20070026471A; BRPI0509147A; AU2005227500B2; JP5032301B2; JP2007531120A

Abstract

【課題】デジタル制御データとプレゼンテーションデータのあらかじめ選択されたセットを通信するための通信プロトコルを形成するために一緒にリンクされたパケット構造を用いて通信路を介してホストとクライアントとの間でデジタルデータを転送するためのデジタルインターフェースを提供する。
【解決手段】信号プロトコルは、通信プロトコルを形成するパケットを発生し、送信し、受信するように構成され、デジタルデータを１つ以上のデータパケットのタイプに形成するように構成されたリンクコントローラーにより使用され、リンクコントローラーの少なくとも１つはホスト装置に常駐し、通信路を介してクライアントと接続される。
【選択図】図３

Description

３５米国特許法第１１９条に基づく優先権の主張
この特許出願は、この出願の譲受人に譲渡され参照することにより明示的にここに組み込まれる、２００４年３月２４日に出願した「切替可能なしきい値差動インターフェース」(Switchable Threshold Differential Interface)というタイトルの米国仮出願第６０／５５６，３４５の優先権を主張する。

分野
この開示における発明の実施形態は、デジタルシグナルプロトコル、プロセス、および高データレートでホスト装置とクライアント装置との間で信号を通信または転送する集積回路およびコンポーネントを含む装置に関する。

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

技術背景

コンピューター、電子ゲーム関連製品及び多様なビデオ技術（例えばデジタルバーサタイルディスク（ＤＶＤ’ｓ）及び高解像度ＶＣＲ）は、いくつかの種類のテキストを含むときにもますます高解像度化する静止画像、ビデオ画像、ビデオオンデマンド画像、及びグラフィック画像をこのような装置のエンドユーザへのプレゼンテーションに備えるために過去数年間に著しく進歩した。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明の実施形態の更なる態様では、少なくとも１台のリンクコントローラー、受信機、装置、またはドライバーがクライアントデバイス内に配置され、通信路又はリンクを通じてホストデバイスに結合される。クライアントリンクコントローラーも通信プロトコルを形成するパケットを生成し、送信し、受信するように、及び１種類又は複数の種類のデータパケットにデジタルプレゼンテーションデータを形成するようにも構成される。

一般的には、ホスト又はリンクコントローラーはコマンド又は特定の種類の信号作成及び照会処理で使用されるデータパケットを処理するための状態機械を利用するが、通信プロトコルで使用されるデータ及びあまり複雑ではないパケットのいくつかを操作するためにより低速の汎用プロセッサを使用できる。ホストコントローラーは、１台又は複数台の差動ラインドライバーを備える。一方クライアントレシーバは通信路に結合される１台又は複数台の差動ラインレシーバを備える。

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

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

システム電力消費またはシステムリソース上のドレインを最小にするために、ディスプレイのようなクライアントが使用されていないときまたは現在の能動的使用にあるとき、特定のディスプレイコントローラーハードウェアを低電力状態にセットするための構造、手段、または方法を供給するためにディスプレイ電力状態パケットが発生される。一実施形態において、クライアントは、クライアント機能パケットのクライアントフューチャー機能インジケータフィールドのビット９を用いてディスプレイ電力状態パケットに応答する能力を示す。

ディスプレイ電力状態パケットの一実施形態のフォーマットにおいて、このタイプのパケットは、パケット長、パケットタイプ、ｈＣｌｉｅｎｔＩＤ、電力状態、および巡回冗長検査（ＣＲＣ）フィールドを有するように構成される。このタイプのパケットは一般的に２バイトタイプフィールドにおけるタイプ７５パケットとして識別される。２バイトｈＣｌｉｅｎｔＩＤフィールドは、ＣｌｉｅｎｔＩＤのために予約される情報または値を含む。電力状態フィールドは、あるあらかじめ選択されたビットの値に従って、特定のディスプレイを特定の電力状態にセットするために使用される情報を特定する。２バイトＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを特定するまたは含む。

通信路は一般的に４つ以上のコンダクタおよびシールドのシリーズを有するケーブルを含むまたは採用する。さらに、フレキシブル基板上に存在するいくつかと共に、所望に応じて、印刷配線またはコンダクタを使用することができる。

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

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

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

この発明のさらなる特徴と利点並びに種々の実施形態の構造と動作は、添付図面を参照して以下に詳細に記載される。図面において、類似の参照番号は一般的に同一の、機能的に類似の、および／または構造的に類似のエレメントまたは処理ステップを示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかしながら、当業者によって理解されるように、例えば何らかの種類の電力制御、同期又は相互接続の便利さを可能にするために、ＭＤＤＩを通して電力を配分できるようにすることは確かに可能である。通常、前記構造及び動作を実現するために使用されるケーブル布線の長さは約１．５メートル、通常２メートル以下であり、それぞれが同様にマルチストランドワイヤであり、公称的に３２アメリカワイヤゲージ（ＡＷＧ）と２８ＡＷＧとの間である３本のツイストペアの導線を含む。ワイヤサイズはこのレンジに制限されないけれども、当業者が理解するように、電気的仕様または制約は、最大の合計のエンドツーエンド抵抗、１フィートあたりの最大容量、各ペアのインピーダンスおよびクロストークを満足しなければならない。

フォイルシールド被覆は、全体の、ここでは３つのツイストペア上でおよびさらなるドレインワイヤとしてドレインワイヤ上で覆われ、そうでなければ形成される。ツイストペアとシールドドレイン導線は、技術で周知であるように、シールドがクライアント用のシールドに接続されるクライアントコネクタで終端し、ケーブル全体を覆う絶縁層がある。該ワイヤは、ＨＯＳＴ＿ＧｎｄとＨＯＳＴ＿Ｐｗｒ、ＭＤＤＩ＿Ｓｔｂ＋ＭＤＤＩ＿Ｓｔｂ−、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｄａｔａ０−、ＭＤＤＩ＿Ｄａｔａ＋とＭＤＤＩ＿Ｄａｔａ１−等のように組にされる。しかしながら、特定の応用に基づき本発明の実施形態を実施するために様々な導電体及びケーブルが利用可能であることはこの技術分野において理解されるであろう。例えば、ある応用例ではケーブルを保護するために外側を充分に被覆するかまたは金属層でさえ使用することができ、一方他の応用では、薄く平らな導電リボンタイプの構造が良く適合するかも知れない。

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

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

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

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

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

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

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

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

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

表Ｖは、カラオケ例のサブフレーム内でデータがどのように割り当てられるのかを示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ディスプレイウィンドウ自体は、それはビットマップの可視部分として定義されるに過ぎないためプロトコル内でアドレス指定可能ではない。

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

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

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

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

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

プロトコルバージョンフィールドは、ホストによって使用されるプロトコルバージョンを指定する２バイトを含む。プロトコルバージョンフィールドは、プロトコルの第１のバージョン又はカレントバージョンを使用されているとして指定するために「０」に設定される。この値は新しいバージョンが作成されると経時的に変化し、そしてこの値はいくつかのバージョンフィールドにおいてすでに「１」の値にアップグレードされつつある。バージョンの値は、多分または通常、周知のようにＭＤＤＩのようなインターフェースをカバーする認可された標準文書に関するカレントバージョン数に続く。

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

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

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

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

３．ビデオストリームパケット
ビデオストリームパケットは、表示装置の通常は矩形領域を更新するためにビデオデータを搬送する。この領域のサイズは、単一のピクセルと同程度に小さいか、ディスプレイ全体と同じ程度大きくてよい。ストリームを表示するために必要とされるすべてのコンテクストはビデオストリームパケット内に含まれるために、同時に表示され、システムリソースによって制限されるほぼ無制限な数のストリームがあってよい。

ビデオストリームパケット（ビデオデータフォーマットディスクリプタ）の一実施形態のフォーマットは図１１に示される。図１１で見られるように、一実施形態では、この種のパケットはパケット長（２バイト）フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、ビデオデータディスクリプタフィールド、ピクセル表示属性フィールド、Ｘ左端縁フィールド、Ｙ上部端縁フィールド、Ｘ右端縁フィールド、Ｙ下部端縁フィールド、Ｘ開始フィールドとＹ開始フィールド、ピクセルカウントフィールド、パラメーターＣＲＣフィールド、ピクセルデータフィールド及びピクセルデータＣＲＣフィールドを有するように構造化されている。この種のパケットは、通常、２バイトタイプフィールドに示されるタイプ１６として識別される。一実施形態では、クライアントはクライアント機能パケットの赤−緑−青（ＲＧＢ）フィールド、白黒フィールド、及びＹＣｒＣｂ機能フィールドを使用してビデオストリームパケットを受信する能力を示す。

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

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

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

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

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

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

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

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

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

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

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

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

６．ユーザ定義ストリームパケット
タイプ５６からタイプ６３として知られている８つのデータストリームタイプは、ＭＤＤＩリンクと使用するために装置製造メーカによって定義されてよい独自仕様の応用例で使用するために予約されている。これらはユーザ定義ストリームパケットとして知られている。

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

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

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

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

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

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

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

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

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

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

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

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

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

パケット長フィールドはパケット長フィールドを含まないパケット中のバイトの全数を特定するために２バイトを使用する。１実施形態において、このパケットのパケット長は、事実上リンクシャットダウンパケットが送信される時のインターフェースの型式またはリンクモードに従う。それ故に典型的なパケット長は、タイプ１モードについて２０バイトパケット中に合計２２バイト）に、タイプ２モードについて３６バイト（パケット中に合計３８バイト）に、タイプ３モードリンクについて６８バイト（パケット中に合計７０バイト）、そしてタイプ４モードについて１３２バイト（パケット中に合計１３４バイト）になる。

全ゼロフィールドは、ホストのラインドライバーを使用不能にする前に、ＭＤＤＩ＿データ信号がクライアントがＭＤＤＩ＿Ｓｔｂのみを使用してリカバリングクロックを開始するのを可能にするのに充分な時間ロジックゼロレベルにあることを確実にするために変化可能なバイト数を使用する。全ゼロフィールドの長さは実質的にリンクシャットダウンパケットが送信される時のインターフェースタイプまたはリンク動作モードに従う。全ゼロフィールドの長さはいかなるインターフェースタイプの設定に関してもＭＤＤＩ＿Ｓｔｂに６４パルスを生成することを意図する。それ故に、各インターフェースタイプに関する全ゼロの長さは、タイプ１については１６バイトに、タイプ２について３２バイトに、タイプ３については６４バイトに、タイプ４について１２８バイトになる。

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

低電力ハイバネーション状態では、ＭＤＤＩ＿Ｄａｔａ０ドライバーは、全ゼロフィールドの最後のビットの後で１６番目〜４８番目のＭＤＤＩ＿Ｓｔｂサイクルまたはパルスの後に開始する、高インピーダンス状態にディスエーブルされる。タイプ−２、タイプ−３、またはタイプ−４リンクに関し、ＭＤＤＩ＿ＤａｔａＰｗｒ７信号を介するＭＤＤＩ＿Ｄａｔａ１もまた、ＭＤＤＩ＿Ｄａｔａ０ドライバーがディスエーブルされるのと同じ時に、高インピーダンス状態に置かれる。ホストまたはクライアントのいずれかはＭＤＤＩリンクを他の箇所に説明されるようハイバネーション状態から「目覚め（wake up）」させることができる。それが本発明のための重要な進展であり、本発明の利点である。

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

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

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

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

１４．ビットマップブロック転送パケット
ビットマップブロック転送パケットは、任意の方向で、一般的には、１つの矩形領域から他の矩形領域にピクセルのブロックをコピーすることにより、ディスプレイの領域をスクロールするための手段、構造または方法を提供する。この能力を有するクライアントは、クライアント機能パケットのディスプレイフィーチャー能力インジケータのビット０でその能力を報告するであろう。ビットマップブロック転送パケットの１つの実施形態におけるフォーマットは図２４に示されている。図２４に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、データ属性フィールド、ラスター演算フィールド、左Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、ウィンドウＸ移動フィールド、ウィンドウＹ移動フィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットは通常タイプ７１パケットとして識別され、１つの実施形態においては１５バイトという事前に選択された固定長を使用する。２バイトｈＣｌｉｅｎｔＩＤフィールドは、どこかに記述されているように、ＣｌｉｅｎｔＩＤのために予約される情報または値を含む。一般的にこのフィールドは、将来の使用のために予約されているので、現在の値は、ビットをロジックゼロレベルに設定することにより、典型的にゼロに設定される。しかしながら、それは他の値に設定することができるし、または当業者によって所望の情報を転送するように使用される。

一実施形態において、２バイトピクセルデータ属性フィールドは、ピクセルデータが更新される場所を指定する値を有する。ビット１および０は、ピクセルデータが更新されるディスプレイを選択する。クライアント内の一次ディスプレイがステレオイメージをサポートしないなら、クライアントは、ビットの組み合わせ０１、１０、または１１の１つに対して一次ディスプレイ内のピクセルデータに影響を及ぼすことができる。値１１は、ステレオディスプレイ能力をサポートしないクライアント内の一次ディスプレイをアドレスするために使用されることが推奨される。ビット［１：０］が値１１（ダブルロジック１）を有するとき、左目と右目の両方のフレームバッファ内でピクセルデータが更新され、ビット［１：０］が値１０（ロジック１、ロジック０）を有するなら、ピクセルデータは、左目だけのフレームバッファ内で更新される。ビット［１：０］が値０１（ロジック０、ロジック１）を有するとき、ピクセルデータは、右目だけのフレームバッファ内で更新される。ビット［１：０］が値００（ダブルロジックゼロ）を有するとき、ピクセルデータは、以下のビット８乃至１１により指定される代替ディスプレイのフレームバッファ内で更新される。

一実施形態において、ピクセルデータ属性フィールドのビット２は、左目または右目のバッファがこの動作のための画像のソースであるか否かを指定する。ビット［１：０］が００に等しくないときビット２のみが適用する。これは、一般的に画像のデスティネーションが代替ディスプレイの１つであるときメイン画像バッファからのソースデータをサポートしないことを意味するために実施される。ビット２は、データソースとして、左目フレームバッファまたは右目フレームバッファの間を識別するまたは指定するために使用される。ビット２が０に等しいとき、左目フレームバッファは、データソースであるが、ビット２が１に等しいとき、右目フレームバッファがデータソースである。

ピクセルデータ属性フィールドのビット３は、ディスプレイまたはオフライン画像バッファをリフレッシュするために使用されるバッファは、この動作のための画像のソースとなる。代替ディスプレイがオフライン画像バッファならビット３はまた代替ディスプレイに適用してもよい。しかしながら、これは、画像の指定が代替ディスプレイであるとき、逆もまた同様のとき、メイン画像バッファからのソースデータをサポートしない。ビット３が０の値またはロジックゼロレベルであるとき、ディスプレイをリフレッシュするために使用される画像バッファはデータソースである。ビット３が１の値またはロジック１レベルに等しいとき、オフライン画像バッファはデータソースである。

ピクセルデータ属性フィールドのビット７および６は、フレームバッファを指定するディスプレイ更新ビットとして動作する。この場合、ピクセルデータは、更新されるかまたは書かれることになる。フレーム更新ビットの効果、以下に詳述する。ビット［７：６］が「０１」（ロジックゼロ、ロジック１）であるとき、ピクセルデータは、オフライン画像バッファに書かれる。ビット［７：６］が「００」（ダブルロジックゼロ）であるとき、ピクセルデータは、ディスプレイをリフレッシュするために使用される画像バッファに書かれる。ビット［７：６］が「１１」（ダブルロジック１）であるとき、ピクセルデータは、すべての画像バッファに書かれる。ビット［７：６］が「１０」であるとき、これは、無効値として取り扱われる。これらのビットは、現在は、将来の使用のために予約されている。この状況において、全体のコマンドは無視され、フレームバッファは更新されない。

ピクセルデータ属性フィールドのビット１１乃至８は、代替ディスプレイまたは代替クライアントロケーションを指定する４ビットの符号なしの整数を形成する。この場合、ピクセルデータが更新される。クライアントがビット１１乃至８を代替ディスプレイ番号として解釈するように、ビット０および１は、００の値（ダブルロジックゼロ）に等しく設定される。ビット１および０が００に等しくないなら、ビット８乃至１１は、一般的にロジックゼロ値またはレベルに等しく設定される。ビット４乃至５およびビット１２乃至１５は、将来の使用のために予約され、一般的にロジックゼロレベルまたは値に設定される。

一実施形態において、２バイトラスタ演算フィールドは、どのようにしてソースおよびデスティネーションロケーション内のピクセルを結合して、デスティネーション画像ロケーションに書かれる新しいピクセル値を形成するかを指定する。ラスタ演算は、どのようにして、等しいサイズの２つの異なる矩形領域が一緒にマージされるかを定義する。また、デスティネーション画像エリアは、一緒にマージされる２つの画像の１つである。２つの画像の２番目はソース画像と呼ばれる。クライアントが、クライアント機能パケット内で指定されるラスタ演算フィールドをサポートしないなら、ホストは一般的に３に等しいビット３乃至０を有するパケットを送信し、クライアントは、ビット３乃至０を無視する。

一実施形態において、ビット３乃至０が使用され、以下に示す表ＶＩＩに示される値を用いてまたはその値の１つに等しくなるようにビット３乃至０を設定することにより実際のラスタ演算を指定し、その値の次に示される対応する動作を選択する。すなわち、第１列にリストアップされた各指定されたビット［３：０］は、第２列で指定される動作を生じ、さらに、第３列に説明のためにさらなる定義がなされる。

ビット５乃至４は、デスティネーションピクセルが、透明色に関連するデスティネーションロケーションに書かれるか否かを指定する。ビット５乃至４により指定される演算は、ラスタ演算がクライアント装置によりサポートされるか否かに適用する。クライアントがラスタ演算をサポートしないなら、ビット５乃至４により定義される動作に対して考慮すべき結果として生じるデスティネーションピクセル値は、ソースピクセル値のみに等しい。

ビット［５：４］の値が００であるとき、透明色は使用されない。結果として生じるデスティネーションピクセルは、透明色カラーイネーブルパケットにより定義される透明色の値を考慮せずにデスティネーションピクセルロケーションに書かれる。０１に等しいビット［５：４］の値は現在、将来の使用のために予約されており、典型的に使用されない。しかし、当業者が関連する使用を確立するために利用可能である。ビット［５：４］の値が１０に等しいとき、ラスタ演算により計算された結果として生じるデスティネーションピクセルが透明色に等しいなら結果として生じるピクセルは、デスティネーションピクセルロケーションに書かれない。そうでなければ、それは、デスティネーションピクセルロケーションに書かれる。ビット［５：４］の値が１１に等しいとき、ラスタ演算により計算された結果として生じるデスティネーションピクセルが透明色に等しいなら結果として生じるピクセルは、デスティネーションピクセルロケーションに書かれない。そうでなければ、結果として生じるピクセルは、デスティネーションピクセルロケーションに書かれる。

ビット１５乃至６は、将来の使用のために予約され、それゆえ、一般的にロジックゼロ値またはレベルに等しく設定される。

残りのフィールドを用いて移動すべきウィンドウの左上隅の座標のＸおよびＹの値、移動すべきウィンドウの幅と高さ、およびそれぞれ水平および垂直にウィンドウが移動するピクセルの数を指定する。後者の２つのフィールドの肯定的な値は、ウィンドウを右にそして下に移動させ、否定的な値は、移動を左そして上に、それぞれ移動させる。ＣＲＣフィールド（ここでは、２バイト）は、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

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

２バイトｈＣｌｉｅｎｔＩＤフィールドは、どこかに記述したように、ＣｌｉｅｎｔＩＤのために予約される情報または値を含む。このフィールドは、一般的に将来の使用のために予約されるので、現在の値は典型的にゼロに設定される。この設定は、ビットをロジックゼロレベルに設定することにより行われる。しかし、所望の情報を転送するために当業者により他の値に設定することができまたは使用することができる。

２バイトを使用するこの実施形態におけるビデオデータフォーマットディスクリプタは、ピクセル塗りつぶし値のフォーマットを指定する。このフォーマットは、ビデオストリームパケット内のフィールドと同じフィールドであり、これは、上に説明し図解した。ピクセルエリア塗りつぶし値フィールド（４バイト）は、上述したフィールドにより指定されたウィンドウに塗りつぶされるピクセル値を含む。このピクセルのフォーマットは、ビデオデータフォーマットディスクリプタフィールドで指定される。

ピクセルデータ属性およびラスタ演算フィールドは、上述したビットマップブロック転送パケット内の同じフィールドに類似して機能し、以下にさらに詳細に提示される。

残りのフィールドは、移動すべきウィンドウの左上隅の座標のＸおよびＹ値を指定するために使用される。ウィンドウ左上座標Ｘ値およびＹ値フィールドは２バイトを使用し、各バイトは、塗りつぶすウィンドウの左上隅の座標のＸおよびＹ値を指定する。

ウィンドウ幅および高さフィールド（各々２バイト）は、塗りつぶすウィンドウの幅および高さを指定する。ＣＲＣフィールド（ここでは２バイト）は、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

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

水平パターンオフセットがノン−ゼロの場合、続いてウィンドウの左側及び左側プラス水平パターンオフセットの間のピクセルはパターンの最も右側のピクセル（right-most pixel）で満たされる。水平パターンオフセットはパターン幅よりも小さくすべきである。同様に垂直パターンオフセットがノン−ゼロの場合、続いてウィンドウの上側及び側部の上部プラス垂直パターンオフセットの間のピクセルはパターンの最下位ピクセル（lower-most pixel）で満たされる。垂直パターンオフセットはパターンの高さよりも小さくすべきである。

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

２バイトｈＣｌｉｅｎｔＩＤフィールドは、どこかに記載したように、ＣｌｉｅｎｔＩＤのために予約される情報または値を含む。このフィールドは一般的に将来の使用のために予約されるので、現在の値は、ビットをロジックゼロレベルに設定することにより典型的にゼロに設定される。

２バイトビデオデータフォーマットディスクリプタフィールドは、ピクセルエリア塗りつぶし値のフォーマットを指定する。図１１は、どのようにしてビデオデータフォーマットディスクリプタがコード化されるかを図解する。そのフォーマットは、ビデオストリームパケット内の同じフィールドと同じである。

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

１７．リードフレームバッファパケット
リードフレームバッファは、逆方向リンクを介してホストに返送されるクライアント内のフレームバッファの矩形領域を選択し、決定し、指定するための構造、手段および方法を提供する。返送されたピクセルデータのフォーマットは、ディスプレイのネイティブフォーマット内にあり、そのフォーマットは、一般的に、逆方向リンクを介してホストに送信されたビデオストリームパケットのデータフォーマットディスクリプタフィールドで指定される。ホストに戻されるピクセルデータは、現在表示されている画像バッファからのものである。クライアントは、一般的に、リードフレームバッファパケットにより指定された表示領域に戻すために必要な多くの逆方向リンクカプセル化パケット内の多くのビデオストリームパケットを使用する。この能力を有するクライアントはそのように示すことができまたはクライアント機能パケットのクライアントフィーチャー能力インジケータのビット３を用いて能力を報告することができる。

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

２バイトパケット長フィールドは、パケット長フィールドを含まないパケット内の合計バイト数を指定する。一実施形態において、このパケット長は１６で固定される。以前に使用されたように、２バイトｈＣｌｉｅｎｔＩＤフィールドは、ＣｌｉｅｎｔＩＤのために予約される情報または値を含む。このフィールドは一般的に将来の使用のために予約されるので、ビットを「０」（ロジックゼロレベルまたは状態）に設定することにより、現在の値はゼロに設定される。しかし、それは、当業者により所望の情報を転送するために使用することができる。

一実施形態において、２バイトディスプレイデータ属性フィールドは、どこで、ピクセルデータが読まれるかを指定する値を有する。ビット０は、ピクセルデータが読まれるフレームバッファを選択する。ビット０が０（ロジックゼロ）の値に等しいとき、ピクセルデータは、以下のビット８乃至１１により指定される代替ディスプレイのフレームバッファから読まれる。ビット０が１（ロジック１）の値と等しいとき、ピクセルデータは、一次ディスプレイのフレームバッファから読まれる。

一実施形態において、ディスプレイデータ属性フィールドのビット２は、左目または右目フレームバッファのためのバッファが読むべきデータのソースであるか否かを指定する。一般に、ビット２は、一次ディスプレイがステレオ画像をサポートするときに適用することができるのみである。ビット２が０（ロジックゼロレベル）に等しいとき、左目フレームバッファはデータソースであるが、ビット２が１（ロジック１レベル）に等しいとき、右目バッファはデータソースである。

ディスプレイデータ属性フィールドのビット３は、ディスプレイをリフレッシュするために使用されるバッファまたはオフライン画像バッファがこの演算のための画像のソースになるかどうかを指定する。代替ディスプレイがオフライン画像バッファを利用するなら、ビット３はまた代替ディスプレイに適用してもよい。しかしながら、画像のデスティネーション先が代替ディスプレイまたは逆の場合も同様であるとき、これは、メイン画像バッファからのソースデータをサポートしない。ビット３が０の値またはロジックゼロレベルに等しいとき、ディスプレイをリフレッシュするために使用される画像バッファはデータソースである。ビット３が１またはロジック１レベルの値に等しいとき、オフライン画像バッファはデータソースである。

ディスプレイデータ属性フィールドのビット１１乃至８は、ピクセルデータが読まれるディスプレイまたは代替クライアントロケーションを指定する。ビット０は、クライアントがビット１１乃至８を代替ディスプレイ番号として解釈するために０（ロジックゼロ）の値に等しく設定される。ビット０が０に等しくないなら、ビット８乃至１１は一般的にロジックゼロ値またはレベルに等しく設定される。ビット１、４乃至７、および１２乃至１５は、将来の使用のために予約され、一般的にロジックゼロレベルまたはゼロ値に設定される。

一実施形態において、２バイトＸ左端フィールドおよびＹ上端フィールドは、ピクセルデータフィールドにより塗りつぶされるスクリーンウィンドウの左端のＸ座標および上端のＹ座標を指定し、Ｘ右端フィールドおよびＹ底縁フィールドは、右端のＸ座標と、更新されるウィンドウの底縁のＹ座標を指定する。

一実施形態において、２バイトＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを指定するかまたは含む。

１８．ディスプレイ電力状態パケット
システム電力消費またはシステムリソース上のドレインを最小にするために、ディスプレイのようなクライアントが使用されていないときまたは現在アクティブな使用でないとき、特定のクライアント制御されたまたはクライアント関連された、クライアント接続された、またはコントローラーハードウェアを低電力状態にセットするための構造、手段または方法をディスプレイ電力状態パケットは提供する。このタイプのパケットは、インターフェースまたはインターフェース構造およびプロトコルを外部モード構成または動作に適用するのにもっとも有用である。そのような適用において、外部装置がバッテリのような限られた電力リソース上で動作している、または他の電力制約および懸案事項を有している可能性がより高い。例えば、最小電力条件が期間のためにまたは不動作のためにまたは不使用のために所望されるように限られた空間内のオーバーヒートその他である。一実施形態において、クライアントは、クライアント機能パケットのクライアント特徴能力インジケータフィールドのビット９を用いてディスプレイ電力状態パケットに応答するための能力を示す。

ディスプレイ電力状態パケットのための一実施形態のフォーマットは図２８に示される。図２８に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、電力状態フィールドおよびＣＲＣフィールドを有するように構造化されている。このタイプのパケットは一般的に２バイトタイプフィールドのタイプ７５パケットとして識別され、あらかじめ選択された８バイトの固定長を使用する。以前に使用されたように、２バイトｈＣｌｉｅｎｔＩＤフィールドはＣｌｉｅｎｔＩＤのために予約される情報または値を含む。このフィールドは一般的には、将来の使用のために予約されるので、ビットを「０」（ロジックゼロレベルまたは状態）に設定することにより、現在の値はゼロに設定される。だけれども、当業者により、所望の情報を転送するように使用することができる。

電力状態フィールド、ここでは２バイトは、特定の装置、ハードウェアの一部、ディスプレイのようなクライアントに関連する機器を特定の電力状態にセットするために使用される情報を指定する。ディスプレイのために使用されるとき、このフィールドのビット０は、パケットがメインディスプレイまたは代替ディスプレイに適用するか否かを指定する。ビット０が１に等しいなら、パケットは、メインディスプレイに適用する。ビット０が０に等しいなら、パケットは、ビット１１乃至８により指定される代替ディスプレイに適用する。ビット１は、将来の使用のために予約され、一般的にゼロにセットされる。

電力状態フィールドのビット３乃至２は、ビット１１乃至８およびビット０により選択されたディスプレイの電力状態を指定する。ビット［３：２］が「００」の値を有するとき、選択されたディスプレイは、照射されず、最小の電力量を消費しなければならない。そして、フレームバッファの内容は、この状態の期間中に保持されるようには保証されない。ビット［３：２］が「０１」の値を有するとき、選択されたディスプレイは照射されず、相対的な最小の電力量を消費しており、フレームバッファの内容は、この状態の期間中に保持されるように保証される。ディスプレイは、状態００におけるよりもこの状態でより多くの電力を消費してもよい。クライアントは、クライアント機能パケットのクライアント特徴能力インジケータフィールドのビット１０を使用して、状態０１を支援する能力を示すことができる。電力状態フィールドのビット［３：２］が「１０」の値を有するとき、選択されたディスプレイは照射され、その関連するフレームバッファからの画像を表示している。ビット「３：２」のための「１１」の値は、予約された値または将来の使用のための状態であり使用されない。

当業者は、ディスプレイアプリケーションに対してもっとも有用であるけれども、このパケットの使用はこの発明によりディスプレイに限定されず、他のアプリケーション、構成、または状況があってもよいことを認識するであろう。この場合、ＭＤＤＩが使用されている、またはクライアントが制御しているまたは通信している他のハードウェアエレメントに関連して電力制御が必要となるかもしれないまたは所望されるかもしれない。これらの状況において、上に開示されたビットは、類似した機能を有してもよいが、理解されるように、そのようなエレメントのメインエレメントおよび二次エレメントをアクティブにすることができるまたは電力レベル等を設定することができる。

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

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

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

ディスプレイ電力状態の要約は、一般的にインターフェース構造によりサポートされるかまたはプロトコルは下記の表ＶＩＩＩに提示される。表ＶＩＩＩに示すように、クライアント特徴能力ビット１０および９の種々の組み合わせは、所望の電力状態の種々の状態を確立し、セットアップし、またはトリガするために使用される。与えられた行および列位置に提示されたマークは、その列の一番上で指定されたディスプレイ電力状態がクライアント特徴能力インジケータの規定された組み合わせに対してサポートされることを示す。表ＶＩＩＩの第１行および第３行は、クライアントがディスプレイ電力状態パケットをサポートするための能力を有さないとき、電力状態「１０」のみが許可されることを示すことがわかる。たとえ、ディスプレイにディスプレイ電力状態が送信することができなくても、単一のマークは、ディスプレイが「常にオン状態」にあることを示しており、このビットのセットを使用して低電力状態にセットすることはできない。

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

図２９に示すように、一実施形態において、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、インターフェースタイプフィールド、リザーブ１フィールド、ディレイフィラー(Delay Filler)フィールドおよびＣＲＣフィールドを有するように構成されている。このタイプのパケットは一般的に２バイトタイプフィールドにおけるタイプ７７パケットとして識別され、６バイトのあらかじめ選択された固定長を使用する。なぜなら、ディレイフィラーフィールドの長さは、パケット長フィールド内の値に影響を及ぼさないからである。

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

ディレイフィラーフィールドは、実行インターフェースタイプハンドオフパケットの直後のパケットの始まりにおいて新しいインターフェースタイプ設定を使用するためにまたは設定するためにクライアントが切り替わるように作るまたは構成されるためにシステムの一部に十分な時間を許容するための手段、構造、または方法として作られた。このフィールドはロジックゼロレベルまたは値にすべて設定されるまたは等しいバイトまたは８ビット値のグループを含む。このフィールドで使用されるバイトの数は、６４ＭＤＤＩ＿Ｓｔｂサイクルに等価な長さであるフィールドを生ぜしめるように選択される。ディレイフィラーフィールドの長さは、タイプ１順方向リンクインターフェースタイプの場合には１６バイト、タイプ２インターフェースタイプの場合には３２バイト、タイプ３インターフェースタイプの場合には６４バイト、およびタイプ４順方向リンクインターフェースを指定するまたは使用するとき１２８バイトである順方向リンクのインターフェースタイプ設定にもとづいている。

予約された１フィールド（ここでは１バイト）は情報を知らせる際に将来の使用のために予約される。このフィールドにおけるすべてのビットは一般的にロジックゼロレベルに設定される。そのようなフィールドの目的は現在、すべての次の２バイトフィールドを１６ビットワードアドレスに合わさせ、４バイトフィールドを３２ビットワードアドレスに合わさせることである。ＣＲＣフィールド（ここでは２バイト）は、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

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

２２．逆方向音声サンプルレートパケット
このタイプのパケットは、クライアント内の音声チャネルをホストがイネーブルまたはディスエーブルできる構造、方法、または手段を提供する。この機能は有用であり、従って、ホストにより出力すべき音声がないとき、クライアントは電力を節約するために音声増幅器をパワーオフすることができる。音声ストリームの有無を用いて暗黙のうちに実施することは極めて困難である。クライアントシステムがパワーアップされるとき、またはホストに接続されるとき、デフォルト状態は、すべての音声チャネルがイネーブルである。ゼロから１の状態または値への遷移を行わせた音声チャネルイネーブルマスクフィールド内のビットの最下位ビットを有する順方向音声チャネルイネーブルパケットをクライアントが受信した後で、ホストおよびクライアントに接続された音声システムは、約１００ｍｓｅｃ未満以内に意図された方法または所望の方法で音声信号を出力する準備をしなければならないまたは出力できなければならない。クライアントは、クライアント機能パケットの音声チャネル能力フィールドのビット１５のための値セットを用いて順方向音声チャネルイネーブルパケットに応答する能力を示す。

このパケットは、ホストが逆方向リンク音声チャネルをイネーブルまたはディスエーブルすることを可能にし、このストリームの音声データサンプルレートを設定することを可能にする。ホストは、クライアント機能パケット内で有効であると定義されるサンプルレートを選択する。ホストが無効なサンプルレートを選択するなら、クライアントはホストへの音声ストリームを送信しないであろう。そして、適切なエラー、エラー値、またはエラー信号をクライアントエラー報告パケットでホストに送信してもよい。ホストは、サンプルレートを２５５の値に設定することにより逆方向リンク音声ストリームをディスエーブルにしてもよい。クライアントシステムが最初にパワーアップされるときまたは接続されるときに仮定されるデフォルト状態は、逆方向リンク音声ストリームがディスエーブルされることである。逆方向オーディオサンプルレートパケットのための一実施形態のフォーマットは図３１に示される。図３１に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、音声サンプルレートフィールド、予約１フィールドおよびＣＲＣフィールドを有するように構造化される。このタイプのパケットは一般的にタイプ７９パケットとして識別され、あらかじめ選択された４バイトの固定長を使用する。

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

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

クライアントＩＤフィールドは、将来の実施において、クライアントＩＤとして使用するために予約され、典型的には、ゼロ値（ロジックゼロビット）に設定される。

一実施形態において、２バイトディスプレイデータ属性フィールドは、どこに透明ピクセル色が適用されるかを指定する値を有する。ビット０は透明ピクセル色が適用されるディスプレイを選択する。ビット０が０（ロジックゼロ）の値に等しいとき、透明ピクセル色は、下記のビット８乃至１１により指定される代替ディスプレイに適用される。ビット０が１（ロジック１）の値に等しいとき、透明ピクセル色が一次ディスプレイに適用される。

ディスプレイデータ属性フィールドのビット１１乃至８は、透明ピクセル色が適用されるディスプレイまたは代替クライアントロケーションを指定する。ビット０は、クライアントがビット１１乃至８を代替ディスプレイ番号として解釈するように０（ロジックゼロ）の値に等しく設定される。ビット０が０に等しくないなら、ビット８乃至１１は一般的にロジックゼロ値またはレベルに等しく設定され、無視される。

ディスプレイデータ属性フィールドのビット１乃至７およびビット４乃至１２乃至１４は将来の使用のために予約され、一般的には、ロジックゼロレベルまたはゼロ値に設定される。

ディスプレイデータ属性フィールドのビット１５が０に等しいなら、透明色モードはディスエーブルされる。他方、ビット１５が１に等しいなら、透明色モードはイネーブルになり、透明色は以下の２つのパラメーターにより指定される。

２バイトの予約された１フィールドは将来の使用のために予約される。このフィールドにおけるすべてのビットは、一般的にゼロ（ロジックゼロレベルまたは状態）に設定される。一実施形態において、このフィールドの１つの目的は、すべての次の２バイトフィールドを１６ビットワードアドレスに合わせ、４バイトフィールドを３２ビットワードアドレスに合わせることである。

一実施形態において、透明色イネーブルパケットのビデオデータフォーマットディスクリプタフィールドは、２バイトを用いて、ピクセルエリア塗りつぶし値のフォーマットを指定する。図１１は、ビデオデータフォーマットディスクリプタがどのようにコード化されるかを図解する。そのフォーマットは一般的にビデオストリームパケット内の同じフィールドと同じである。

一実施形態において、透明ピクセル値フィールドは、透明色の値として使用されるピクセル値に対して４バイトを使用するまたは割り当てる。このピクセルのフォーマットは、ビデオデータフォーマットディスクリプタフィールドで指定される。

ＣＲＣフィールドは２バイトを用いてパケット長を含むパケット内のすべてのバイトのＣＲＣを含むまたは表現する。

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

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

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

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

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

ホストとクライアントの両方とも、ＭＤＤＩ＿ＤＡＴＡラインを定められた状態に保つために、両方のガード時間中にラインをロジックゼロレベルに駆動する。ホストとクライアントの両方のガード時間が経過する期間のエネーブルおよびディスエーブル時間は、いずれかの適正な往復遅延時間における、ＭＤＤＩ＿データ信号が適正な低レベルにある時間である。

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

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

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

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

２６．ＶＣＰ特徴要求パケット法。

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

一実施形態におけるＶＣＰ特徴要求パケットのフォーマットは図６９に示されている。

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

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

一実施形態において、ＶＣＰ特徴応答パケット内の２バイトディスプレイ選択フィールドは、ＶＣＰパケットを適用するディスプレイを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットが適用されるディスプレイを選択する。ビット０が０に等しいとき、ＶＣＰパケットは、下記のビット１１乃至８により指定される代替ディスプレイに適用する。他方、ビット０が１、ロジック１レベルに等しいなら、ＶＣＰパケットは一次ディスプレイに適用する。現在、ディスプレイセレクタフィールドのビット７乃至１は、将来の使用のために予約され、一般的にゼロ値に等しく設定され、またはビットはロジックゼロレベルに設定される。

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

一実施形態において、ＭＣＣＳＶＣＰコードフィールドは、ＭＣＣＳＶＣＰコードパラメーターを指定する２バイトの情報を含む。０乃至２５５の範囲の値は、指定されたＭＣＣＳコードに対応するＶＣＰ特徴応答リスト内の単一アイテムを用いてＶＣＰ特徴応答パケットを戻させる。６５５３５（Ｏｘｆｆｆｆ）のＭＣＣＳＶＣＰコードは、クライアントにサポートされた各制御のための特徴応答リストを含むＶＣＰ特徴応答リストを有したＶＣＰ特徴応答パケットを要求する。このフィールドのための２５６乃至６５５３４の値は、将来の使用のために予約され、現在使用されていない。

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

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

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

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

一実施形態において、ＶＣＰ特徴応答パケット内の２バイトディスプレイセレクタフィールドは、ＶＣＰパケットを適用するディスプレイを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットを適用するディスプレイを選択する。ビット０が０に等しいとき、ＶＣＰパケットは、下記のビット１１乃至８により指定される代替ディスプレイに適用する。他方、ビット０が１、ロジック１レベルに等しいなら、ＶＣＰパケットは一次ディスプレイに適用する。現在ディスプレイセレクタフィールドのビット７乃至１は将来の使用のために予約されており、一般的にゼロ値に等しく設定され、またはビットはロジックゼロレベルに設定される。

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

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

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

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

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

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

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

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

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

一実施形態において、セットＶＣＰ特徴パケット内の２バイトディスプレイセレクタフィールドは、ＶＣＰパケットをどこに適用するかを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットが適用されるディスプレイを選択する。ビット０が０に等しいとき、ＶＣＰパケットは下記のビット１１乃至８により指定される代替ディスプレイに適用される。他方、ビット０が１、ロジック１レベルに等しいなら、ＶＣＰパケットは一次ディスプレイに適用される。現在、ディスプレイセレクタフィールドのビット７乃至１は、将来の使用のために予約され、一般的にゼロ値に等しく設定されるかまたはビットは、ロジックゼロレベルに設定される。

ディスプレイセレクタフィールドのビット１１乃至８は、ＶＣＰパケットが適用されるであろう代替ディスプレイを指定する。ディスプレイセレクタフィールドのビット０が０（ロジックゼロレベル）に等しいとき、クライアントは、ビット１１乃至８を代替ディスプレイ番号として解釈する。ビット０が０に等しくないなら、ビット１１乃至８は、ゼロに設定され、無視されるであろう。ビット１５乃至１２は将来の使用のために予約され、一般的にゼロ値に設定されるかまたは各ビットはロジックゼロレベルに設定される。

セットＶＣＰ特徴パケットのためのＭＣＣＳＶＣＰコードは、２バイトの情報または値を用いて、調整されるＭＣＣＳＶＣＰ制御コードパラメーターを指定する。２バイトのリスト中の値数フィールドは、制御値リストに存在する１６ビット値の数を指定する情報又は値を含む。制御値リストは、ＭＣＣＳ制御コードがクライアント内のテーブルに関連しない限り通常１つのアイテムを含む。非テーブル関連制御の場合、制御値リストはＭＣＣＳＶＣＰコードフィールドにより指定される制御パラメーターに書き込まれる新しい値を指定する値を含むであろう。テーブル関連制御の場合、制御値リスト中のデータのフォーマットは指定されたＭＣＣＳＶＣＰコードのパラメーター説明によって指定される。

リストが１バイトより大きい値を含む場合には、どこか他の箇所に定義される方法に一貫して最下位ビットが最初に送信される。最後に２バイトのＣＲＣフィールドが、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。

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

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

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

一実施形態において、有効パラメーター要求パケット内の２バイトディスプレイセレクタフィールドは、ＶＣＰパケットをどこに適用するかを指定する。ディスプレイセレクタフィールドのビット０は、ＶＣＰパケットが適用されるディスプレイを選択する。ビット０が０に等しいとき、ＶＣＰパケットは、下記のビット１１乃至８により指定される代替ディスプレイに適用される。他方、ビット０が１、ロジック１レベルに等しいなら、ＶＣＰパケットは一次ディスプレイに適用される。現在、ディスプレイセレクタフィールドのビット７乃至１は将来の使用のために予約され、一般的にゼロ値に設定されるかまたはビットはロジックゼロレベルに設定される。

ディスプレイセレクタフィールドのビット１１乃至８は、ＶＣＰパケットが適用されるであろう代替ディスプレイを指定する。ディスプレイセレクタフィールドのビット０が０（ロジックゼロレベル）に等しいとき、クライアントは、ビット１１乃至８を代替ディスプレイ番号として解釈する。ビット０が０に等しくないなら、ビット１１乃至８はゼロに設定され、無視されるであろう。ビット１５乃至１２は将来の使用のために予約され、一般的にゼロ値に設定されるかまたは各ビットはロジックゼロレベルに設定される。

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

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

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

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

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

ｃＣｌｉｅｎｔＩＤフィールドは、上述の記載から周知のように将来のＣｌｉｅｎｔＩＤのために予約される。

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

ディスプレイセレクタフィールドのビット１１乃至８は、ＶＣＰパケットが適用されるであろう代替ディスプレイを指定する。ビット０が０（ロジックゼロレベル）に等しいなら、クライアントは、ビット１１乃至８を代替ディスプレイ番号として解釈する。ビット０が０に等しくないならば、ビット１１乃至８はゼロに設定され無視されるであろう。ビット１５乃至１２は将来の使用のために予約され、一般的にゼロ値に設定されるかまたは各ビットは、ロジックゼロレベルに設定される。

一実施形態において、３バイトＭＣＣＳＶＣＰコードパケットは、このパケットにより記載される非連続的なＭＣＣＳＶＣＰ制御コードパラメーターを指定する値を含む。無効のＭＣＣＳＶＣＰ制御コードが有効パラメーター要求パケットにより指定されるなら、同じ無効パラメーター値がこのフィールドにおいて、応答コードフィールド内の適切な値とともに指定されるであろう。ＭＣＣＳ制御コードが無効ならＶＣＰパラメーター応答リストはゼロレングスを有するであろう。

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

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

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

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

以下に記載されるスケーリングされたビデオストリームパケットのヘッダーは、ヘッダーが画像を表示するのに必要な全体のコンテクストを含むより簡単なビデオストリームパケットとわずかに異なる。スケーリングされたビデオストリームパケットはセットアップパケットを使用して、ソースおよびデスティネーションウィンドウサイズおよび位置のパラメーター、およびピクセルデータを送信するために別個のスケーリングされたビデオストリームパケットを定義する。クライアントは、セットアップパケットからのストリームパラメーターおよび各ストリームに関連するピクセルデータの一部を記憶するために各ストリームに関連する内部記録を割り当てる。各ストリームが変化するのに必要な記憶量は、ソース画像およびデスティネーション画像のサイズおよびセットアップパケットにおいて指定された値に依存する。従って、プロトコルは、クライアントが、各スケーリングされたビデオストリームに関連する記憶装置の割り当てのためのダイナミックなメモリアロケーションを実施可能にするように設計される。

プログラムソースに固有のサイズを有するディスプレイにビデオストリームを送り、特定のエンドアプリケーションに適切な方法で画像の表示スケールおよび位置を有することは有用である。複数のビデオ画像のリアルタイムスケーリングのための実施は、この特徴のサポートをクライアントにおいてオプションにさせるために十分複雑である。

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

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

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

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

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

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

２バイトのＹＣｂＣｒ機能フィールドは、ＹＣｂＣｒフォーマットで表示できる解像度のビット数を指定する値を含む。スケーリングされたビデオストリームがＹＣｂＣｒフォーマットを使用できない場合には、この値はゼロである。

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

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

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

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

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

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

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

例えば、図１２Ａ乃至１２Ｄに見られるように、および一実施形態で使用するように、ビット［１５：１３］が「０００」に等しいとき、ビデオデータは白黒ピクセルのアレイで構成される。この場合、ピクセルあたりのビット数は、ビデオデータフォーマットディスクリプタワードのビット３乃至０により定義される。ビット１１乃至４は一般的に将来の使用またはアプリケーションのために予約され、この状況においてゼロに設定される。その代わりに、ビット［１５：１３］が「００１」に等しいとき、ビデオデータは、各々がカラーマップ（パレット）を介して色を指定するカラーピクセルのアレイを構成する。この状況において、ビデオデータフォーマットディスクリプタワードのビット５乃至０はピクセルあたりのビット数を定義し、ビット１１乃至６は一般的に将来の使用またはアプリケーションのために予約され、ゼロに等しく設定される。その代わりにビット「１５：１３」が値「０１０」に等しいとき、ビデオデータはカラーピクセルのアレイで構成され、赤のピクセルあたりのビット数は、ビット１１乃至８により定義され、緑のピクセルあたりのビット数は、ビット７乃至４により定義され、青のピクセルあたりのビット数は、ビット３乃至０により定義される。この状況において、各ピクセル内のビットの合計数は、赤、緑、青に使用されるビット数の和である。

しかしながら、その代わりに、図１２Ｄに示すようにビット「１５：１３」が値またはストリング「０１１」に等しいとき、ビデオデータは、輝度情報とクロミナンス情報を有した４：２：２ＹＣｂＣｒフォーマットのビデオデータのアレイで構成され、輝度（Ｙ）のピクセルあたりのビット数は、ビット１１乃至８により定義され、Ｃｂ成分のビット数は、ビット７乃至４により定義され、Ｃｒ成分のビット数は、ビット３乃至０により定義される。各ピクセルにおけるビットの合計数は、赤、緑、青のビット数の和である。ＣｂおよびＣｒ成分は、Ｙとして半分のレートで送信される。さらに、このパケットのピクセルデータ部分におけるビデオサンプルは、以下のように組織される。Ｃｂｎ、Ｙｎ、Ｃｒｎ、Ｙｎ＋１、Ｃｂｎ＋２、Ｙｎ＋２、Ｃｒｎ＋２、Ｙｎ＋３．．．この場合ＣｂｎとＣｍがＹｎとＹｎ＋１に関連づけられ、Ｃｂｎ＋２とＣｒｎ＋２はＹｎ＋２およびＹｎ＋３と関連づけられる等である。Ｙｎ、Ｙｎ＋１、Ｙｎ＋２およびＹｎ＋３は、上に議論された単一行において左から右に４つの連続するピクセルの輝度値である。上述したすべての４つのフォーマットの場合、図では、「Ｐ」として指定されるビット１２は、ピクセルデータサンプルがパックされているか否かまたはバイト合わせされたピクセルデータか否かを指定する。このフィールドにおける「０」の値は、ピクセルデータフィールドの各ピクセルがＭＤＤＩバイト境界とバイト合わせされることを示す。「１」の値は、各ピクセルおよびピクセルデータ内の各ピクセル内の各色は、以前のピクセルまたは未使用ビットを残さないピクセル内の色に対してパックされる。

一実施形態において、２バイトピクセルデータ属性フィールドは、以下のように解釈される値を有する。ビット１および０は、将来の使用のために予約され、現在一般的には、ロジックゼロに設定され、ビット２は、ピクセルデータがインタレースフォーマットであるか否かを示す。ビット２が０であるとき、ピクセルデータは標準の進歩的なフォーマットにある。１つの行から次の行に進むとき行数（ピクセルＹ座標）は１だけインクリメントされる。ビット２が１であるとき、ピクセルデータはインタレースフォーマットにある。１つの行から次の行に進むとき行数（ピクセルＹ座標）は２だけインクリメントされる。

一実施形態において、ビット３は、ピクセルデータが代替ピクセルフォーマットにあるか否かを示す。これは、ビット２によりイネーブルにされる標準インタレースモードに類似するが、インタレースは水平よりもむしろ垂直である。ビット３が０であるとき、ピクセルデータは発生されるかまたは標準の進歩的なフォーマットに配置される。各連続するピクセルを受信するごとに、列番号（ピクセルＸ座標）は１だけインクリメントされる。ビット３が１であるとき、ピクセルデータは発生されるかまたは代替ピクセルフォーマットに配置される。各ピクセルが受信されるごとに列番号（ピクセルＸ座標）は２だけインクリメントされる。

また、ビット４乃至１５は将来の使用のために予約され、一般的にロジックゼロレベルまたは現在のアプリケーションまたは設計のための値に設定される。

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

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

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

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

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

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

２−すでに割り当てられているストリームＩＤを割り当てようとする無効な試行
３−すでに割り当て解除されているストリームＩＤを割り当て解除しようとする無効な試行
４−クライアントはスケーリングビデオストリームをサポートしない
５−ストリームパケットはクライアントの機能と一貫していない。

６−ストリームＩＤ値はクライアントによって許可される最大値より大きい。

７−指定されたストリームを割り当てるには不十分なクライアント内で入手可能なリソース
２バイトのＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを含む。

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

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

一実施形態において、２バイトピクセルデータ属性フィールドは、ピクセルデータルーチンおよび表示更新またはバッファロケーションを指定する値を有する。これらの値は、一実施形態において、以下のように解釈される。ビット１および０は、ピクセルデータが送られるディスプレイを選択する。「１１」または「００」のビット値の場合、ピクセルデータは両方の目に対してまたは目のために表示され、「１０」の値の場合、ピクセルデータは、左目だけに送られ、「０１」の値の場合、ピクセルデータは右目だけに送られる。

ビット７および６は、ピクセルデータが書かれるフレームバッファを指定するディスプレイ更新ビットである。フレーム更新ビットの作用は、より詳細にほかの場所に記載される。ビット「７：６」が「０１」であるとき、ピクセルデータはオフライン画像バッファに書かれる。ビット「７：６」が「００」であるとき、ピクセルデータは、ディスプレイをリフレッシュするために使用される画像バッファに書かれる。ビット［７：６］が「１１」であるとき、ピクセルデータは、すべての画像バッファに書かれる。ビット［７：６」が「１０」なら、これは無効値として取り扱われる。これらのビットは、現在将来の使用のために予約される。この状況において、ピクセルデータは無視され、画像バッファのいずれにも書かれないであろう。ビット２乃至５および８乃至１５は、将来の使用のために予約され、一般的にロジックゼロレベルまたはロジックゼロ値に設定される。

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

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

３５．特殊ステータス要求パケット
特殊ステータス要求パケットは、このパケットに指定されるように、クライアントが機能又はステータスパケットをホストに送り返すことをホストが要求するための手段、機構又は方法を提供する。クライアントは、次の逆方向リンクカプセルかパケット内に指定されるタイプのパケットを返す。クライアントは、クライアントが特殊ステータス要求パケットに応答する機能を有する場合、クライアント機能パケットのクライアント特徴機能フィールドでビット１７を一般に設定する。クライアントが返送することができるまたは転送することができるステータスパケットの全てのタイプを決定するために使用するホストにとって都合の良い方法は他で記載されているバリッドステータスリプレイリストパケット（Valid Status Reply List Packet）を使用することである。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット２１を使用してバリッドステータスリプレイリストパケットに応答する能力を示すことができる。

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

６６−クライアント機能パケットはクライアントにより送信される。

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

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

１４１−個人クライアント機能パケットはクライアントによって送信される。

１４２−クライアントエラーレポート表示パケットはクライアントによって送信される。

１４３−スケーリングビデオストリーム機能パケットがクライアントによって送信される。

１４４−クライアント識別パケットがクライアントによって送信される。

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

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

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

有効ステータス応答リストパケットの一実施形態のフォーマットは概して図８０に示されている。図８０で分かるように、有効ステータス応答リストパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、リスト中の値数フィールド、有効パラメーター応答リストフィールド、及びＣＲＣフィールドを有するように構造化されている。この種のパケットのパケット長は通常１０という値に固定され、１３９というタイプ値は有効ステータス応答パケットとしてパケットを識別する。

ｃＣｌｉｅｎｔＩＤフィールドはクライアントＩＤとしての将来の使用のために予約され、通常ゼロに設定されている。リストフィールド内の２バイトの値の数は、以下の有効パラメーター応答リスト内で項目の数を指定する。

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

６６−クライアント機能パケット
１３３−アルファ−カーソル画像機能パケット
１３９−クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス応答リストパケット
１４１−パーソナルディスプレイ機能パケット
１４２−クライアントエラーレポートパケット
１４３−スケーリング済みビデオストリーム機能パケット
１４４−クライアント識別パケット
１４５−代わりの表示機能パケット
パケットタイプ５６から６３−製造メーカに特殊な機能及びステータス識別子のために使用できる。

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

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

他方、クライアントは有効ステータス応答リストパケットの有効パラメーター応答リストの対応するパラメーターを使用することによってパーソナルディスプレイ機能パケットを送信する能力を示す。

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

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

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

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

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

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

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

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

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

ビット１５から５は将来の使用のために受信され、一般にロジック−ゼロ状態に設定されるものとする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

４０．代替ディスプレイ機能パケット
代替ディスプレイ機能パケットは、ＭＤＤＩクライアントコントローラーに取り付けられた代替ディスプレイの機能を示すために手段、構造または方法として使用される。それは特殊ステータス要求パケットに応えて送信される。プロンプトを出されると、クライアントデバイスは、サポートされている代替ディスプレイごとに代替ディスプレイ機能パケットを送信する。クライアントが２つ以上の代替ディスプレイを有するなら、クライアントは、単一特定ステータス要求パケットに応答して、各ディスプレイに１つの割合で、複数の代替ディスプレイ機能パケットを送信し、発生し、または供給しなければならない。だけれども、いくつかの構成は、所望に応じて複数の特定ステータス要求パケットを使用することができる。しかしながら、これは、それほど効率的でない。クライアントはＡｌｔディスプレイ番号フィールドの値に基づいて、「非シーケンシャルオーダー」と呼ぶことができるものの内の代替ディスプレイ機能パケットを送信してもよい。クライアントは、有効ステータス応答リストパケットの有効パラメーター応答リスト内の１４５のパラメーター値を介して代替ディスプレイ機能パケットを送信するための能力を示すことができる。

内部モードで動作されるＭＤＤＩシステムの場合、ＭＤＤＩクライアントコントローラーに接続された２以上のディスプレイを有することは、一般的であってよい。一例としてのアプリケーションは、フリップ(flip)の内部に大きなディスプレイを有し外側により小さなディスプレイを有する携帯電話である。２つの潜在的な理由のために代替ディスプレイ機能パケットを戻すことは内部モードのために必要ではない。第１に、ホストは既にプログラムされているかもしれず、また、それらは一般的な装置またはハウジングにおいて使用されるため、別途製造期間中の能力の情報を知らされているかもしれないからである。第２に、２つのアッセンブリに基づき、クライアントはホストに対する接続について容易に接続を断ちまたは引き離すことができず、そしてホストはクライアント機能についてプログラム中に固定されたコピー（hard-coded copy）を含むことができ、または少なくともこれらは、別の場合に起こるように、クライアントにおける変更について変更することができないからである。

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

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

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

予約１フィールド（１バイト）は、将来の使用のために予約されている。

それゆえ、このフィールド内のすべてのビットは、現在ゼロまたはロジックゼロレベルに等しくし設定される。一実施形態において、パケット内にこのフィールドを存在させる１つの目的は、すべての次の２バイトフィールドを１６ビットワードアドレスに合わさせ、４バイトフィールドを３２ビットワードアドレスに合わさせることである。

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

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

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

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

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

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

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

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

予約された３フィールド、ここでは２バイトは、将来の使用のために予約される。

それゆえ、このフィールド内のすべてのビットは、典型的にロジックゼロレベルまたはゼロ値に設定されるかまたは等しい。一実施形態において、パケット内にこのフィールドを持たせる１つの目的は、次の２バイトフィールドを１６ビットワードアドレスと位置合わせさせ、４バイトフィールドを３２ビットワードアドレスと位置合わせさせることである。

ディスプレイ特徴機能インジケータ、ここでは４バイトは、代替ディスプレイ内の特定の特徴がサポートされるかどうかを示すフラッグのセットを含む。１に設定されたビットは、特定のまたはあらかじめ設定された機能がサポートされることを示し、ゼロに設定されたビットは、機能がサポートされないことを示す。

一実施形態において、ディスプレイ特徴機能フィールドは、サポートされる代替ディスプレイ内の特定の特徴を示すフラッグのセットを含む４バイトを使用する。ロジック１レベルに設定されるビットは、機能がサポートされることを示し、一方ロジックゼロレベルに設定されるビットは、機能がサポートされないことを示す。一実施形態において、ビット０のための値は、ビットマップブロック転送パケット（タイプ７１パケット）がサポートされるかどうかを示す。ビット１、２、および３のための値は、それぞれビットマップエリア塗りつぶしパケット（タイプ７２パケット）、ビットマップパターン塗りつぶしパケット（７３型パケット）またはリードフレームバッファパケット（タイプ７４パケット）がサポートされるか否かを示す。ビット４のための値は、透明色イネーブルパケットを用いて１つの色を透明にさせる機能を代替ディスプレイが有するか否かを示す。

この実施形態において、ディスプレイ特徴機能フィールドのビット１０の値は、代替ディスプレイがディスプレイ電力状態０１をサポートするための能力を有するか否かを示す。ディスプレイ電力状態は、上述したディスプレイ電力状態パケットの電力状態フィールドのビット［３：２］を用いて設定される。ディスプレイ電力状態０１は、選択されたディスプレイが照射されず、もしあれば最小の電力量を消費する状態であり、フレームバッファの内容は一般的にこの状態の期間中に維持されるように保証されるかまたは合理的に保証される。

ディスプレイ特徴機能フィールドのビット１３の値は、ＶＣＰ特徴パケット、すなわち、ＶＣＰ特徴要求パケット、ＶＣＰ特徴応答パケット、ＶＣＰ特徴設定パケット、有効パラメーター要求パケットおよび有効パラメーター応答パケットをサポートすることにより１つ以上のビデオパラメーターを設定する能力を代替ディスプレイが有しているか否かを示す。ビット１４のための値は、代替ディスプレイが、図８８Ａに示すオフラインディスプレイフレームバッファにピクセルデータを書き込む能力を有するか否かを示す。このビットがロジック１レベルに設定されるなら、ディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性フィールドのビット７および６）は、値「０１」に設定されてもよい。

ディスプレイ特徴機能フィールドのビット１５の値は、図８８Ｂに示される、表示画像をリフレッシュするために現在使用されているディスプレイフレームバッファにのみピクセルデータを書き込む能力を代替ディスプレイが有するときを示す。このビットがロジック１に設定されるなら、ディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性フィールドのビット７および６）「００」の値に設定されてもよい。ビット１６のための値は、単一ビデオストリームパケットからのピクセルデータを、図８８Ｃに示すすべてのディスプレイフレームバッファに書き込む能力を代替ディスプレイが有するときを示す。このビットがロジック１レベルに設定されるなら、ディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性フィールドのビット７および６）は、値「１１」に設定されてもよい。

一実施形態において、ディスプレイ機能特徴フィールドのビット２１のための値は、これらのパケットがビット０、１、２またはこのフィールドにより指定される代替ディスプレイによりサポートされるなら、ビットマップブロック転送パケット（タイプ７１パケット）のラスターオペレーションフィールド、ビットマップエリア塗りつぶしパケット（タイプ７２パケット）、およびビットマップパターン塗りつぶしパケット（タイプ７３パケット）を使用する能力を代替ディスプレイが有するときを示す。一実施形態において、ビット２１がロジックゼロレベルまたは値を有するなら、およびパケットがサポートされるなら、代替ディスプレイは、ラスターオペレーションフィールドを使用する能力を有さず、代替ディスプレイは典型的に、これらのパケットにより指定されるピクセルロケーションにコピーするかまたは書き込む能力を有するのみてある。

一実施形態において、ディスプレイ特徴機能フィールドのビット９乃至５、１１、１２、２０乃至１７、および３１乃至２２は、現在、将来の使用のため、またはシステム設計者により有用な代替指定のために予約され、一般的にゼロ値またはロジックゼロレベルに等しく設定される。

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

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

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

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

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

ビット１３：０はレジスタデータリストフィールドで送信される３２ビットのレジスタデータアイテムの数を指定するために１４ビットの符号なし整数を使用する。ビット１５：１４が「００」に等しい場合には、ビット１３：０はレジスタアドレスフィールドにより指定されるレジスタで開始するレジスタに書き込まれるレジスタデータリストフィールドに含まれる３２ビットのレジスタデータアイテムの数を指定する。ビット１５：１４が「１０」に等しい場合には、ビット１３：０は、受信側装置がそのレジスタが読み取られるのを要求する装置に送信する３２ビットのレジスタデータアイテムの数を指定する。

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

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

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

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

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

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

パケットが複数のビットエラーを含み良好なＣＲＣを生成するというありそうもないことがある。エラーを備えたパケットに関して良好なＣＲＣを検出する確率は、多くのエラーを含む非常に長いパケット上の７．６×１０-6にほぼ等しい。設計によって、ＭＤＤＩリンクは、非常に低いまたはゼロエラーレートを有するであろう。ＣＲＣはリンクの調子を監視するために使用されることを意図しており、パケット再送信すべきかどうかを決定するために特定のパケットに関してエラーを検出することを意図していない。

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｖ．リンクハイバネーション
ＭＤＤＩリンクは素早くハイバネーション状態に入ることができ、そして素早くハイバネーションからウェイクアップする。この応答性は通信システムまたは装置電力が消費を低減するためにＭＤＤＩリンクを無理やりハイバネーション周波数にさせることを可能にする。それが使用のために非常に速く再度ウェイクアップすることが可能だからである。一実施の形態において、外部モードクライアントはハイバネーションから早い時間でウェイクアップするので、１Ｍｂｐｓからなるデータレートでそしてストローブパルスタイミングでそれを実行し、つまり、ＭＤＤＩ＿Ｓｔｂ対は５００ｋＨｚレートでトグルすべきである。一度クライアントの特徴がホストによりまたは通信において発見されると、続いてホストはリンクを一般的には１Ｍｂｐｓからクライアントが動作可能な最大レートの如何なるレートにおいてもウェイクアップすることができる。内部モードクライアントは、ホストおよびクライアントの双方が動作可能な如何なるレートにおいてもウェイクアップすることができる。このことはまた速い時間の内部モードウェイクアップについて一般的に適用可能である。

一実施の形態では、リンクが休止状態からウェイクアップするとき、ホストとクライアントは、パルスのシーケンスを交換する。これらのパルスは、最大リンク動作速度における信号を受信するのに必要とされるディファレンシャルレシーバとして電流の小部分のみを消費する低速ラインレシーバを使用して検出することができる。ホストまたはクライアントのいずれか一方はリンクをウェイクアップすることができ、この場合ウェイクアッププロトコルはホストとクライアントの双方が同時にウェイクアップしようと試みる場合に起りうるコンテンションを処理するために設計される。

ハイバネーション状態が継続する期間にＭＤＤＩ＿ＤａｔａおよびＭＤＤＩ＿Ｓｔｂ差動ドライバーは機能を無効にされ、そして全てのディファレンシャルペアにかかるディファレンシャル電圧はゼロボルトである。ハイバネーションからウェイクアップする期間においてパルスのシーケンスを検出するために使用されるディファレンシャルレシーバは意図的な電圧オフセットを有する。一実施の形態では、これらのレシーバにおけるロジック１とロジックゼロレベル間の閾値は約１２５ｍＶである。このことは非−駆動ディファレンシャルペアがリンクがウェイクアップする期間においてロジックゼロレベルと判断される原因となる。

ハイバネーション状態に入るためにホストはリンクシャットダウンンパケットのＣＲＣの後６４ＭＤＤＩ＿Ｓｔｂサイクルを送信する。ホストはＣＲＣの後１６〜５６ＭＤＤＩ＿Ｓｔｂサイクルの範囲のホストのＭＤＤＩ＿Ｄａｔａ０の出力について機能を無効にする（出力無効伝播遅延を含む）。ホストはリンク終了パケットのＣＲＣの後、それがウェイクアップシーケンスを開始する前に、６４ＭＤＤＩ＿Ｓｔｂサイクルを送信することを終了する。一実施の形態において、ウェイクアップが開始されたホストは、パルスをＭＤＤＩ＿Ｓｔｂ上で駆動する前に、ＭＤＤＩ＿Ｄａｔａ０が適正なロジック１レベルに達した後、少なくとも１００ｎｓｅｃ待たなければならないホストとして規定される。一実施の形態において、クライアントはリンク終了パケットのＣＲＣの後、ホストをウェイクアップすることを試みるためにそれがＭＤＤＩ＿Ｄａｔａ０をロジック１レベルに駆動する前、少なくとも６０ＭＤＤＩ＿Ｓｔｂサイクル待つ。

ハイバネーション状態から"ウェイクアップする"ためにいくつかの処理または工程が着手される。クライアント、ここではディスプレイ、がホストからのデータまたは通信、サービスを必要とする場合、それはＭＤＤＩ＿Ｄａｔａ０ラインを７０〜１０００μｓｅｃ前後の間ロジック１状態に駆動し、ここでＭＤＤＩ＿Ｓｔｂは非活動状態にあり、そして、例え所望により他の期間が使用できるとしても、ＭＤＤＩ＿Ｓｔｂが活動状態になった後、ＭＤＤＩ＿Ｄａｔａ０が約７０ＭＤＤＩ＿Ｓｔｂサイクル（６０〜８０の範囲にわたる）の間ロジック１レベルに駆動されるように保つ。クライアントは続いてＭＤＤＩ＿Ｄａｔａ０ドライバーの機能を、それを高インピーダンス状態に置くことにより、無効にする。

もし休止状態の継続する間においてＭＤＤＩ＿Ｓｔｂが実行可能な状態にある場合、たとえありそうでなくとも、続いてクライアントはＭＤＤＩ＿Ｄａｔａ０のみを約７０ＭＤＤＩ＿Ｓｔｂサイクル（６０〜８０の範囲にわたる）の間、ロジック１状態に駆動するであろう。この動作はホストがデータトラフィックを順方向リンク（２０８）において起動または再起動し、そしてクライアントにその状態に関し調査する原因となる。

ホストは要求パルスの存在を検出しなければならず、そして少なくとも２００ｎｓｅｃ前後の間ＭＤＤＩ＿Ｓｔｂをロジック−ゼロレベルにそしてＭＤＤＩ＿Ｄａｔａ０をロジック−ハイレベルに駆動するスタートアップシーケンスを開始する。そしてトグルする間、ＭＤＤＩ＿Ｓｔｂは、ＭＤＤＩ＿Ｄａｔａ０を約１５０ＭＤＤＩ＿Ｓｔｂサイクル（１４０〜１６０の範囲）の間ロジック１レベルに駆動し、そして約５０ＭＤＤＩ＿Ｓｔｂサイクル（４０〜６０の範囲）の間ロジックゼロレベルに駆動することを続ける。クライアントは、ロジック１状態において８０ＭＤＤＩ＿Ｓｔｂサイクルよりも多い間に、ＭＤＤＩ＿Ｄａｔａ０を検出した場合、サービス要求パルスを送信すべきではない。クライアントが６０〜８０のＭＤＤＩ＿Ｓｔｂサイクルの間にロジック１レベルにおいてＭＤＤＩ＿Ｄａｔａ０を検出した場合、それはこの間隔の間に何処でホストがＭＤＤＩ＿Ｓｔｂサイクルに関しＭＤＤＩ＿Ｄａｔａ０をロジックゼロレベルに駆動するかの探索を開始する。ホストがＭＤＤＩ＿Ｄａｔａ０を５０ＭＤＤＩ＿Ｓｔｂサイクルの期間においてロジックゼロレベルに駆動した後、ホストはリンク上にパケットの送信を開始する。送信される最初のパケットはサブフレームヘッダーパケットである。クライアントは、ＭＤＤＩ＿Ｄａｔａ０が５０サイクル間隔の４０ＭＤＤＩ＿Ｓｔｂサイクルの間ロジックゼロレベルにおける後、サブフレームヘッダーパケットを探すことを開始する。休止処理および開始シーケンスに関する時間間隔の時間および許容度の選択の特徴はさらに以下で議論される（図６８Ａ〜Ｃを参照されたい）。

ホストは最初にＭＤＤＩ＿Ｓｔｂを動作可能にし、そして同時にそれをロジックゼロレベル駆動することによりウェイクアップを始動することができる。ＭＤＤＩ＿Ｓｔｂはパルスが下に記載のように出力されるまではロジック１レベルに駆動されるべきではない。ＭＤＤＩ＿Ｓｔｂがロジックゼロレベルに達した後、ホストはＭＤＤＩ＿Ｄａｔａ０を動作可能にし、同時にそれをロジック１レベルに駆動する。ＭＤＤＩ＿Ｄａｔａ０はインターバルまでウェイクアップ処理の期間ロジックゼロレベルに駆動されるべきではない。ＭＤＤＩ＿Ｄａｔａ０は、以下に記載するように５０ＭＤＤＩ＿Ｓｔｂパルスの期間に対してロジックゼロレベルに駆動される。ホストは、パルスをＭＤＤＩ＿Ｓｔｂに駆動する前、ＭＤＤＩ＿Ｄａｔａ０が適正なロジック１レベルに達した後、少なくとも２００ｎｓｅｃ待つべきである。このタイミングの関係は最悪の事態の出力エネーブル遅延を考慮する場合に生ずる。このことは、ホストによって駆動されたＭＤＤＩ＿Ｄａｔａ０についてロジック１レベルによって起動された後、クライアントがそのＭＤＤＩ＿Ｓｔｂレシーバを完全に動作可能にするのに充分な時間をもつことを実質的に補償する。

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

次に、クライアントはサービス要求パルスをアサートしようとするのをやめ、クライアントは点Ｅで見られるように、そのドライバーを高インピーダンス状態にする。ホストは、点Ｆで示されるように５０μｓｅｃの間ＭＤＤＩ＿Ｄａｔａ０をロジックゼロレベルに駆動し、ＭＤＤＩ＿Ｄａｔａ０のロジックゼロレベルと一貫した方法でＭＤＤＩ＿Ｓｔｂを作成し始める。クライアントは、ＭＤＤＩ＿Ｄａｔａ０が４０ＭＤＤＩ＿Ｓｔｂサイクルの間ロジックゼロレベルの後、サブフレームヘッダーパケットを探索することを開始する。ＭＤＤＩ＿Ｄａｔａ０をロジックゼロレベルにアサートし、ＭＤＤＩ＿Ｓｔｂを５０μｓｅｃの間駆動した後に、ホストは点Ｇで示されるようにサブフレームヘッダーパケットを送信することにより順方向リンクでデータの送信を開始する。

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

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

出願者は、ホストが信号トグルのためにクロックサイクルベースのタイミングを使用するウェイクアップ処理及びタイミングに対する新しい発明の手法を発見した。この構成では、ホストは、ホストがウェイクアップシーケンスの始まりにＭＤＤＩ＿Ｄａｔａ０信号を高に駆動してから０から１０μｓｅｃ、ＭＤＤＩ＿Ｓｔｂのトグルを開始し、信号が低に駆動されるまで待機しない。ウェイクアップシーケンスの間、ホストは、ＭＤＤＩ＿Ｄａｔａ０信号が常にロジックゼロレベルであるかのようにＭＤＤＩ＿Ｓｔｂをトグルする。

これは事実上クライアント側から時間の概念を排除し、ホストは、最初の２つの状態のための過去の１５０μｓの期間と５０μｓの期間から、これらの期間の間の１５０クロックサイクルと５０クロックサイクルに変化する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明のＭＤＤインターフェースの一部として信号を転送するためのドライバー、受信機及び終端を達成するために有効な要素の例示的な構成は図４２に示されている。この例示的なインターフェースは、１Ｖパワースイングより小さくそして低パワードレインを有する低電圧センシング、ここでは２００ｍＶ、を使用する。各信号対のドライバーは差動電流出力を有する。ＭＤＤＩパケットを受信する間、ＭＤＤＩ＿ＤａｔａおよびＭＤＤＩ＿Ｓｔｂ対は０Ｖの電圧閾値を有する普通の差動レシーバを使用する。ハイバネーション状態においてドライバーの出力は使用不能にされ、並列終端抵抗器は各信号対の差動電圧を０Ｖに引き付ける。ハイバネーションの間、ＭＤＤＩ＿Ｄａｔａ０対上の特定のレシーバは正の１２５ｍＶのオフセット入力閾値を有し、これはハイバネーションラインレシーバに非駆動信号対をロジックゼロレベルとして解釈させる。

差動対の差動電圧は、正（+）信号上の電圧マイナス負（−）信号上の電圧の差分として定義される。その差動対信号の名前は、「＋」または「−」で終了する。これは、それぞれ対の正信号または負信号を示す。差動対のドライバーの出力電流は、正（+）出力から流れる電流として定義される。差動ドライバーの負（−）出力を通過する電流は常に大きさが等しいが、同じ差動ドライバーの正（+）の出力を通過する電流と比べて方向が反対である。

時々ホスト又はクライアントは、データの流れの方向が変化（ホストからクライアントへ、またはクライアントからホストへ）する場合、対について適切なロジックレベルを保証するためにロジック１レベルまたはロジックゼロレベルに差動対を同時に駆動する。出力電圧範囲および出力基準は同じロジックレベルに同時に駆動された出力によって満たされるであろう。いくつかのシステムにおいて、ハイバネーション期間中およびハイバネーション状態からウェイクアップしたときに、小電流を終端された作動対に駆動して、ある時期において小さなオフセット電圧を作る必要があるかもしれない。これらの状態において、動作可能にされたオフセット−電流バイアス回路は以下のリーケージを駆動しなければならない。

Ｉ_ESD-and-RX−内部ＥＳＤダイオードおよび差動レシーバ入力
Ｉ_ESD-and-RX≦１μＡＩ_Tx-Hi-Z−高インピーダンス状態での差動ドライバー出力
Ｉ_Tx-Hi-Z≦１μＡＩ_external-ESD−外部ＥＳＤ保護ダイオードを通るリーケージＩ_external-ESD≦３μＡ。

これらのリーケージ電流の各々は図４７に示されている。プルアップおよびプルダウン回路は、上に記載された全てが同時に起こる場合の、最悪の状態のリーケージ状況において、最小差動電圧に到達しなければならない。外部ＥＳＤ保護ダイオードの無い内部モードにおいて合計のリーケージは≦４μＡであり、そして外部ＥＳＤ保護ダイオードを有する外部モードにおいて≦１０μＡである。

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

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

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

注１：最大立ち上がり時間および立下り時間は、１つの差動対上の１ビットを送信するための間隔の３０％または１００ｎｓｅｃのどちらか小さいほうである。

図４２では、通信リンク４２０６上でパケットを転送しているホストコントローラー４２０２とクライアント又はディスプレイコントローラー４２０４が示されている。クライアントが３つのドライバー４２３０、４２３２、および４２３４を採用する一方で、ホストコントローラーは、伝送されるクライアントＤａｔａ信号を受信するのと同様に、ホストＤＡＴＡおよび伝送されるＳＴＢ信号を受信するために３つのドライバー４２１０、４２１２、および４２１４のシリーズを採用する。ホストＤＡＴＡ（４２１２）の通過に責任を負うドライバーは、ホストからクライアントへの伝送が望まれる場合のみ通信リンクの起動を一般的に可能にする、動作可能な信号入力を採用する。データ伝送の一部としてＳＴＢ信号が形成されるので、このドライバー（４２１２）に関し追加の動作可能な信号は採用されない。クライアントＤＡＴＡおよびＳＴＢレシーバ（４１３２、４２３０）夫々の入力は、それぞれ横切るように配置される終結インピーダンスまたは抵抗４２１８および４２２０を有する。クライアントからホストへ伝送されるデータ信号を準備するためにクライアント制御器のドライバー４２３４が使用され、ここで入力側のドライバー４２１４がデータを処理する。

特別のレシーバ（ドライバー）４２１６および４２３６がＤＡＴＡラインに結合または接続され、そして他で議論される中止制御の一部として、前に議論した１２５ｍＶ電圧オフセットを生成または使用する。オフセットはロジックゼロレベルとして休止ラインレシーバが非−駆動信号を解釈する原因となる。

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

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

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

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

図４３Ｂに示すように、ＭＤＤＩ＿Ｄａｔａ０およびＭＤＤＩ＿Ｓｔｂのためのドライバーからの信号出力がディスエーブルの状態である時間が経過した後、指定された期間ｔ_{stb-dagta-enbl}ＭＤＤＩ＿Ｓｔｂドライバーをイネーブルすることによりホストはサービスを開始するまたはハイバネーションからウェイクアップする。その期間、ラインが完全にイネーブルにされ、次にＭＤＤＩ＿Ｄａｔａ０ドライバーをイネーブルにするまで、ラインはロジックゼロレベルに駆動される。指定された期間ｔ_{client-startup}に対して生じるハイレベルまたはロジック１レベルにＭＤＤＩ＿Ｄａｔａ０が到達した後にホストは、ＭＤＤＩ＿Ｓｔｂをロジックゼロレベルにホールドする。ｔ_{client-startup}期間の終わりでホストは、ＭＤＤＩ＿Ｓｔｂ信号またはラインをトグルする。ホストは、ＭＤＤＩ＿Ｄａｔａ０ラインを高く、すなわちロジック１レベルに駆動し、クライアントは、指定された期間ｔ_{restart-highMDDI}＿Ｄａｔａ０を駆動せず、指定された期間ｔ_restart-lowＭＤＤＩ＿Ｄａｔａ０ラインを低く、すなわち、ロジックゼロレベルに駆動する。この後、サブフレームヘッダーパケットを用いて第１のフォワードトラヒックが開始し、次にフォワードトラヒックパケットが転送される。ｔ_restart-lowの期間および次のサブフレームヘッダーパケットの期間、ＭＤＤＩ＿Ｓｔｂ信号はアクティブである。

図４３ｃに示すように、ＭＤＤＩ＿Ｄａｔａ０およびＭＤＤＩ＿Ｓｔｂのためのドライバーからの信号出力がディスエーブルされた状態である時間が経過した後に、ホストがＭＤＤＩ＿Ｓｔｂドライバーをイネーブルにする前に、ＭＤＤＩ＿Ｓｔｂ受信機内のオフセットをイネーブルにするかまたは上述したように、指定された期間ｔ_{stb-dagta-enbl}出力信号をイネーブルにすることによりクライアントはサービス要求を開始するかまたはハイバネーションからウェイクアップする。次に、クライアントは指定された期間ｔ_host-detectＭＤＤＩ＿Ｄａｔａ０ドライバーをイネーブルにする。その期間、ホストがＭＤＤＩ＿Ｓｔｂトグリングを始める前にラインはロジックゼロレベルに駆動される。

期間ｔ_host-detect中にホストが要求を検出する前にある時間量が経過しまたは必要かもしれない。その後で、ｔ_restart-high期間中にＭＤＤＩ＿Ｄａｔａ０をロジック１またはハイレベルに駆動することによりリンクスタートアップシーケンスを用いてホストがＭＤＤＩ＿Ｓｔｂをトグルする前に、指定された期間ｔ_stb-startupＭＤＤＩ＿Ｓｔｂをロジックゼロレベルに保持することによりホストが応答する。クライアントがＭＤＤＩ＿Ｓｔｂ上の第１のパルスを認識すると、クライアントはＭＤＤＩ＿Ｓｔｂ受信機内のオフセットをディスエーブルにする。クライアントは、ホストラインをドライブするのを検出するまで指定された期間ｔ_{client-detect}、ＭＤＤＩ＿Ｄａｔａ０をロジック１レベルに駆動し続ける。この時点で、クライアントは、要求をデアサートしＭＤＤＩ＿Ｄａｔａ０ドライバーをディスエーブルするので、クライアントからの出力は再びロジックゼロレベルになり、ホストはＭＤＤＩ＿Ｄａｔａ０を駆動している。上述したように、ホストは、ＭＤＤＩ＿Ｄａｔａ０をｔ_restart-highの期間ロジック１レベルに駆動し続け、ｔ_restart-lowの期間ＭＤＤＩ＿Ｄａｔａ０ラインを低く駆動する。その後で、サブフレームヘッダーパケットを用いて第１のフォワードトラヒックが開始する。ＭＤＤＩ＿Ｓｔｂ信号はｔ_restart-low期間、及び以後のサブフレームヘッダーパケットの間アクティブである。

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

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

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

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

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

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

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

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

Ｃ．ホストおよびクライアントイネーブルおよびディスエーブル時間
ホストおよびクライアントの出力イネーブルおよびディスエーブル時間のための切替特性および相対的なタイミング関係または逆方向リンクカプセル化パケット構造に対する動作は、図４８に示される。ドライバー出力機能または動作は、ホスト出力イネーブル時間のためのｔ_host-enable、ホスト出力ディスエーブルのためのｔ_host-disable、クライアント出力イネーブル時間のためのｔ_{client-enable}、クライアント出力ディスエーブル時間のためのｔ_{client-disable}としてラベルが付けられる。ある信号遷移のための典型的な時間は以下に記載される。これらの動作の最小期間は、ゼロナノ秒であろう。インターフェースを採用するシステム設計から決定された典型値または最大値は、恐らく８ナノ秒またはそれ以上のオーダーである。

これらの期間の長さのための一般的なガイドライン、（ホストおよびクライアントイネーブル／ディスエーブル時間）およびそれらの相対的な関係は以下のＸＩＩＩに示される。

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

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

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

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

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

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

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

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

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

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

１つ以上の実施形態の場合に、ＭＤＤＩ逆方向リンクが低電力モードになるために順方向リンク送信を停止する前またはリンクを完全に遮断する前にＭＤＤＩ逆方向リンクが安定であることを保証するためにＭＤＤＩホストは、あるさらなるステップを実行しなければならないことが推奨されるまたは理解される。

生じる可能性のある１つの問題は、ホストが、往復遅延値の正しくない測定値を使用するなら、これにより、順方向リンクが良いように見えてもクライアントからのすべての次に受信される逆方向データ送信は失敗するということである。これは、クライアントが順方向リンクに同期していないときに、ホストが往復遅延測定パケットを送信しようと試みるなら起こり得る。または往復遅延に影響を及ぼす差動ドライバーおよび受信機の伝搬遅延に対応する大きな変化を生じさせる極端な周囲温度変化により起こり得る。断続的なケーブルまたはコネクタの接触不良も、クライアントが一時的に同期を損なわせ、同期を取り戻させる。その期間クライアントは、往復遅延測定パケットを受信し損なうかもしれない。次の逆方向リンクパケットは、ホストにより正しくデコードできないであろう。

生じる可能性のある他のタイプの問題は、クライアントが一時的に同期を損ない、クライアントが同期を取り戻す前にホストがリンクシャットダウンパケットを送信することである。ホストはハイバネーションにはいるであろうが、クライアントは、ハイバネーション状態に入ることはできない。なぜなら、クライアントは、リンクシャットダウンパケットを受信していなかったし、リンクはハイバネーション状態にあるのでクロックを持たないからである。

そのような問題を克服するための１つの技術または実施形態は、リンクをハイバネーション状態にする前にクライアントが順方向リンクと同期していることをホストに保証させることである。ＭＤＤＩホストがこれをできないならまたはそのような機会を持たないなら、たとえば、ＭＤＤＩホストが電力を損失しているときまたは動作中に生じるケーブル、導体、またはコネクタの分離、切断、断線によりリンクが不意に破壊されるかまたは故障するなら、ホストは第１に、クライアントが往復遅延測定プロセスを開始する前または逆方向リンクカプセル化パケットを送信する前に同期することをホストが保証しなければならない。

ホストは、順方向リンクの完全性を決定するためにクライアントにより送信されたクライアント要求およびステータスパケット内のＣＲＣエラーカウントフィールドを観察することができる。このパケットはクライアントからのホストにより要求される。しかしながら、主要リンクの故障または崩壊の場合には、この要求はたぶん応答されないであろう。なぜならクライアントは、パケットを正しくデコードできないであろうし、またはパケットを全く受信できないかもしれないからである。逆方向リンクカプセル化パケットで送信されたクライアント要求およびステータスパケットを用いたＣＲＣエラーカウントのための要求は、一種の防御の第１線である第１の完全性チェックとして作用する。ホストは、クライアントが同期をやめたことについての仮説が正しいものか否かを確認するために往復遅延測定パケットを送信することができる。クライアントが往復遅延測定パケットに応答しないなら、ホストは、クライアントが同期をはずれ同期を取り戻す処理を開始したと結論づけるであろう。

クライアントがクライアント要求およびステータスパケットをホストに返送することを要求するために、逆方向リンクフラッグフィールドのビット１を１にセットして、ホストは、クライアントに逆方向リンクカプセル化パケットを周期的に送信することによりクライアント内のＣＲＣエラーカウントを連続的に監視しなければならない。

クライアントが順方向リンクとの同期を損失している可能性がより高いとホストが結論づけると、ホストは、フィラーパケット以外の任意のパケットを送信しようとする前に次のサブフレームヘッダまで待つ。これは、クライアントが十分な時間でサブフレームヘッダーパケットに含まれる１つの固有のワードを検出または探すことを可能にするために行われる。これに続いて、クライアントは正しいロケーションにおいて固有のワードを発見しないであろうからクライアントは、自身をリセットしたであろうとホストは仮定してもよい。この時点で、ホストは、往復遅延測定パケットを有したサブフレームヘッダーパケットを追跡してもよい。クライアントが依然として往復遅延測定パケットに正しく応答していないなら、ホストは再同期処理を反復してもよい。正しい応答は、往復遅延測定パケットの測定期間にクライアントが指定されたシーケンスをホストに返送するものである。このシーケンスが受信されないなら、逆方向リンクカプセル化パケット内で逆方向データを受信する試みは失敗するであろう。この性質の連続した失敗は、ある他のシステムエラーを示しているかもしれない。このエラーは、ある別の方法で解決されなければならないであろう。そして、この時点でリンク同期の一部ではない。

しかしながら、成功した往復遅延測定パケットの後で、ホストが依然として損傷したデータを見るならまたは逆方向リンクカプセル化パケットで応答がないなら、ホストは、往復遅延測定パケットを再送信することにより逆方向データサンプリングが正しいことを確認しなければならない。多くの試みの後でこれが成功しないなら、一実施形態の場合、ホストは、逆方向除数値を増加させることにより逆方向データを低減することが推奨される。

ホストは、ＭＤＤＩリンクをハイバネーション状態に設定する前にリンク故障検出そしておそらくは上述したリンク再同期化ステップを実行しなければならない。これは、一般的に、リンクが後に再開されたときに実行される往復遅延測定パケットが成功することを保証するであろう。ホストがリンク故障を疑う理由がなく、逆方向リンクカプセル化パケットに対する正しい応答およびゼロ順方向リンクＣＲＣエラーがクライアントにより報告されるなら、ホストは、すべてがしかるべく適切に（例えばリンク故障がない）動作または機能していると仮定してもよく、電力ダウン／ハイバネーションプロセスに進んでもよい。

同期に対してホストがテストすることができる他の方法は、ホストが往復遅延測定パケットを送信し、クライアントからの適切な応答を確認することである。適切な応答がホストにより受信されるなら、ホストは、合理的に、クライアントが成功裏に順方向リンクパケットを解釈していると仮定することができる。

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

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

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

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

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

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

変更されたのは、「あらゆる」パケットについてＣＲＣ値又は決定を活用することである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パケット長＝１０２４（０ｘ０４００）方向転換１長＝１
パケットタイプ＝６５（０ｘ４１）方向転換２長＝１
逆方向リンクフラグ＝０逆方向レート除数＝２
パラメーターＣＲＣ＝０ｘｄｂ４３全ゼロは０ｘ００であるパケット長フィールドとパラメーターＣＲＣフィールドの間のパケットデータは以下のとおりである。０ｘ００、０ｘ０４、０ｘ４１、０ｘ００、０ｘ０２、０ｘ０１、０ｘ０１、０ｘ４３、０ｘｄｂ、０ｘ００、．．．
クライアントから返された第１の逆方向リンクパケットは、７というパケット長及び７０というパケットタイプを有するクライアント要求及びステータスパケットである。

このパケットはバイト値０ｘ０７、０ｘ００、０ｘ４６、．．．等で開始する。しかしながら、第１のバイト（０ｘ０７）だけが図５２で可視である。この第１の逆方向リンクパケットは、実際の逆方向リンク遅延を示すために、図中、ほぼ１逆方向リンククロック期間時間移動されている。クライアント往復遅延に対するゼロホスト付きの理想的な波形は点線トレースとして示されている。

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

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

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

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

典型的に、最大の可能な逆方向レート除数は、タイプ１インターフェースを用いて往復遅延測定パケットの測定窓に送信することができるビットの数の半分である。すなわち、この場合（５１２バイト・８ビット／バイト）／２＝２０４８である。

逆方向ビット時間を往復遅延よりも小さくすることができる代替として進歩した逆方向データサンプリング方法も採用することができる。この技術の場合、ホストは、往復遅延を測定するだけでなく、クライアントの「理想」ビット境界およびゼロ遅延とのリンクに対してクライアントからの応答の位相も決定することができる。クライアント装置応答の位相を知ることにより、ホストは、クライアントから逆方向のデータビットをサンプルするために相対的に安全な時間を決定することができる。往復遅延測定は、逆方向データパケットフィールドの開始に対して逆方向データの第１ビットのロケーションをホストに示す。

進歩したデータサンプリングの一例の一実施形態は図５２Ｂにグラフの形式で示される。

ゼロ往復遅延を有する理想的な逆方向データ信号は、破線の波形として示される。３．５と４ＭＤＤＩ＿Ｓｔｂサイクルとの間の実際の往復遅延は、実線の波形と理想との間の遅延における差分として観察することができる。これは、往復遅延測定パケットを用いて測定されるであろう同じ遅延であり、７の順方向リンクビット時間に等しい測定された往復遅延値であろう。この実施形態において、逆方向データビットは、２ＭＤＤＩＳｔｂパルスの長さであり、これは、４の順方向リンクビット時間であり、２に等しい逆方向レート除数に対応する。進歩した逆方向データサンプリングの場合、どこかに記載したように計算するかわりに２のあらかじめ選択された逆方向レート除数を使用するほうが便利である。これは、進歩した逆方向データサンプリングに対して実質的に最適な選択のようにみえる。なぜならば、理想的なサンプリングポイントは、上述した一般的な測定を用いて容易に決定することができるからである。

逆方向データのための理想的なサンプリングポイントは、逆方向ビットあたりの順方向リンククロックの数または逆方向ビットあたりの往復遅延モジュロ順方向リンククロックの数により除算される合計往復遅延のリマインダ(reminder)をとることにより容易に計算することができる。次に、データ遷移から離れた安全なポイントを得るために１または２を減算する。この例では、７ｍｏｄ４＝３、従って３−１＝２または３−２＝１である。

安全なサンプリングポイントは、ゼロ往復遅延のための「理想的」ビット境界の端から１または２の順方向リンクビット時間である。図は、タイミング図の底部における連続した垂直矢印により示されるように、理想的なビット境界から２の順方向リンクビット時間におけるサンプリングポイントを示す。第１のサンプリングポイントは、測定された往復遅延の後の第１の理想的なビット境界プラス安全サンプリングのためのオフセットである。この例において、往復遅延測定値は７である。従って次の理想的なビット境界は８番目のビット時間であり、従って安全サンプリングポイントに対して１または２を加算し、従って、第１のビットは、逆方向データパケットフィールドの後の９または１０の順方向リンクビット時間でサンプルされなければならない。

ＸＩ．方向転換及びガード時間
逆方向リンクカプセル化パケット内の方向転換１フィールドは、ホストドライバーのための時間をディスエーブルにしクライアントドライバーのための時間を同時にイネーブルにすることができる。往復遅延測定パケット内のガード時間１フィールドはホストとクライアントの重畳を可能にし、ホストインターフェースドライバーがディスエーブルされる前にクライアントドライバーがイネーブルになることができる。逆方向リンクカプセル化パケット内の方向転換２フィールドはクライアントからの以前のフィールド内のデータを、ホストドライバーがイネーブルになる前に完全に送信することを可能にする。ガード時間２フィールドは、クライアントとホストドライバーをロジックゼロレベルで同時に駆動可能にする時間値または期間を提供する。ガード時間１フィールドおよびガード時間２フィールドは、調節するように意図されていない長さのためのあらかじめ設定されたまたはあらかじめ選択された値で一般的に充填される。使用されているインターフェースハードウェアに応じて、これらの値は、経験によって得られるデータを用いて開発してもよいし、ある場合には、動作を改良するために調節してもよい。

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

ただし、インターフェースタイプ因子はタイプ１の場合１、タイプ２の場合２、タイプ３の場合４、およびタイプ４の場合８である。

方向転換２
方向転換２のために一般的に使用される時間の長さを決定する因子は、通信リンクの往復遅延、クライアント内のＭＤＤＩデータドライバーの最大ディスエーブル時間、およびクライアントドライバーディスエーブル時間と同じであるように指定されるホストドライバーのイネーブル時間である。最大ホストドライバーイネーブル時間およびクライアントドライバーディスエーブル時間はどこかで指定される。往復遅延はｔBITの単位で測定される。方向転換２フィールドの順方向リンクバイトの数において指定される最小の長さは以下の関係に従って計算される。

例えば、１０の順方向リンククロックの往復遅延を有するタイプ３の順方向リンクは典型的に、

のオーダーの方向転換２遅延を使用する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「ケーブル」は、さまざまな導体、相互接続、ワイヤおよび対応する遅延を表し、最小ビット期間は、

によって指定される。

外部モードの場合、図５７に示す例において、

であり、最小ビット期間は以下のように表すことができる。

またはほぼ４３４Ｍｂｐｓとして記載することができる。内部モードの場合、図５７に示す例において、

または、ほぼ５５５Ｍｂｐｓとして記載することができる。

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

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

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

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

であり、以下を考えれば

である。

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

これは、ほぼ１７４Ｍｂｐｓである。

これは、タイプ１リンクと共に使用できる最大データレートよりはるかに遅い。ＭＤＤＩの自動遅延スキュー補償機能は、遅延スキューが有効なデータセットアップのまさに端部である最大リンクレートファクタに対して及ぼす影響を大幅に削減する。ＭＤＤＩ＿Ｄａｔａ０およびＭＤＤＩ＿Ｓｔｂとの間の較正されたスキューは、

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

である。ＭＤＤＩ＿ＤａｔａＯおよびＭＤＤＩ＿Ｓｔｂの間の正確に測定されたスキューは次のとおりである：
「ＴＢ」またはｔｂはビット境界から最小出力レベルまでの信号ジッターを表す。非対称は、差動受信機を介したまたは差動受信機の内部遅延の非対称性質を指す。「ＴＰ４」は、クライアントのための差動ラインドライバーおよび受信機のための接続またはインターフェース（クライアント内のＭＤＤＩコントローラー装置のピン）として電気的特徴および試験目的のために関連づけられるまたは効率的に定義される。それは、便宜的または所定のポイントを表す。そのポイントから信号遅延は測定され、システムの残りの全体にわたってリンクに対して特徴づけられる。一実施形態において、ＴＰ４においてパラメーターｔBの最大値は、クライアント送信機の場合、外部モードに対して関係

によって定義され、内部モードに対して関係

により定義される。

クライアント受信機の場合、外部モードに対して関係

により定義される。

ラベルＴＰ４は、インターフェースとリンクにおいてさまざまなテストポイント（ＴＰ）を番号づけするのに単に有用である。一実施形態において、このテストポイントロケーションは内部モードと外部モードの両方に対して同じであるように定義される。差動ラインドライバーおよび受信機を含むホスト内のＭＤＤＩコントローラー装置の接続またはインターフェースピンのためのまたは関連する対応する「ＴＰＯ」テストポイントがある。この実施形態において、ＴＰ０におけるパラメーターＴBの最大値は、ホスト受信機の場合、内部モードに対して関係

により定義され、外部モードに対して関係

により定義される。そしてホスト送信機の場合

により定義される。

図５９に示す例において

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

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

ＭＤＤＩ＿Ｄａｔａ１ができるだけ早く到着するとき、ＲＸＦＦＢにおいてデータを確実にサンプルするために、関連するプログラム可能な遅延は１タップの精度を有する最善の設定に調整され、そして追加のタップ遅延が安全のために追加される。最大リンクスピードが最小の許容可能なビット期間により決定される。これはＭＤＤＩ＿Ｄａｔａ１が可能な限り遅く到着する場合に最も影響を受ける。この場合、最小の許容可能なサイクルタイムは、

である。但し、「ＴＡ」またはｔ_Aはビット境界から中央交差までの信号ジッターを表す。

図５９において示される実施形態において、標本のＭＤＤＩ＿Ｄａｔａ１に基づく最小ビット期間の下限境界は、次の通りである。

一実施形態において、内部モードの場合のホスト送信機内の遅延スキュー、遅延非対称、およびクロックジッターのための典型的な合計遅延時間は以下のように定義されるであろう。

一実施形態において、ＩｎｔｅｒｎａｌＮｒｏｄｅのためのホスト送信機の中の遅れスキュー、遅れ非対称およびクロックジッターのための典型的な総遅延時間は、次のように定義されるだろう：そして、外部モードの場合、

のように定義されるであろう。一方、内部モードの場合のクライアント装置（ｔ_B-TP4）における遅延スキュー、遅延非対称、およびセットアップ時間のための典型的な合計遅延時間は、

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

である。但し、ＴＢＤという用語は、外部モード接続のためのさまざまな良く理解された特徴および動作要件に依存するであろう決定された値になるように将来のための柔軟な場所を維持するラベルである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ピクセルデータフィールドは、表示されなければならず、ビデオデータフォーマットディスクリプタフィールドによって記述されるようにフォーマットされる未処理ビデオ情報を含む。データは他の箇所に説明されるように一度に一「行」送信される。ピクセルデータアトリビュートフィールドのビット５がロジックレベル１に設定された場合、ピクセルデータフィールドは、最も左側のピクセルに対応する伝送された最初のピクセルおよび最も右側のピクセルに対応する伝送された最後のピクセルを有す、ピクセルの１つの行を正確に含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｆ．クライアント機能パケット用
一実施形態のために説明されているように、プロトコルバージョンフィールドは、クライアントによって使用されるプロトコルバージョンを指定する２バイトを使用する。最小プロトコルバージョンフィールドはクライアントが利用する又は解釈する最小プロトコルバージョンを指定するために２バイトを使用するが、初期のバージョンは現在１に等しく設定され、そして周知のように新しいバージョンが生成された場合、その時間にわたって変更されるであろう。この場合、０値はまた有効な値である。データレート機能フィールド（２バイト）は、クライアントがインターフェースの順方向リンクの各データ対上で受信できる最大データレートを指定し、毎秒メガバイト（Ｍｂｐｓ）の形式で指定される。インターフェースタイプ機能フィールド（１バイト）は、順方向リンクと逆方向リンクでサポートされているインターフェースタイプを指定する。ビットを'１'に設定することは特定されたインターフェースタイプがサポートされることを示し、ビットを'０'に設定することは特定されたインターフェースタイプがサポートされないことを示す。ホストおよびクライアントは順方向および逆方向リンクにおいて少なくともタイプ１をサポートするであろう。インターフェースタイプの接続範囲をサポートする必要はない。例えばインターフェースにおいてタイプ３およびタイプ４ではなく、タイプ１およびタイプ３のみをサポートすることは完全に有効である。順方向および逆方向リンクについて、同じインターフェースタイプによって動作させることは必要としない。しかしながら、リンクはハイバネーションから出る場合、ホストおよびクライアントの両方により使用するために他のモードがネゴシエートされ、選択され、またはそうでなければ承認されるまでは、順方向および逆方向リンクの双方はタイプ１モードで動作を開始すべきである。

サポートされたインターフェースは一実施の形態において、順方向リンクにおいてそれぞれタイプ２（２ビット）、タイプ３（４ビット）またはタイプ４（８ビット）モードのいずれかを選択するために、ビット０、ビット１またはビット２を選択することにより、そして逆方向リンクにおいてそれぞれタイプ２、タイプ３またはタイプ４モードのいずれかを選択するためにビット３、ビット４またはビット５を選択することにより指示され、ビット６およびビット７は留保されそしてこの時点では通常０に設定される。ＢｉｔｍａｐＷｉｄｔｈＨｅｉｇｈｔフィールドはここではそれぞれ２バイトであり、ピクセル内のビットマップの幅と高さがそれぞれ特定される。

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

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

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

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

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

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

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

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

ビット１５の値は、クライアントがピクセルデータをディスプレイ画像を更新するために現在使用されているディスプレイフレームバッファにのみ書き込む能力を有する場合を示す。これは図８８Ｂに示されている。このビットが１に設定された場合には、続いてＤｉｓｐｌａｙＵｐｄａｔｅＢｉｔ（ビデオストリームパケットのピクセルデータアトリビュートフィールドのビット７および６）は値'００'に設定することができる。ビット１６に係る値は、何時クライアントが単一のビデオストリームパケットから図８８Ｃに示す全てのディスプレイフレームバッファにピクセルデータを書き込む能力を有するかについて示す。このビットが１に設定された場合、ＤｉｐｌａｙＵｐｄａｔｅＢｉｔ（ビデオストリームパケットのピクセルデータアトリビュートフィールドのビット７および６）を値'１１'に設定することができる。

一実施形態において、ビット１７の値は何時クライアントが要求特定状態パケットに応答する能力を有するかについて示し、ビット１８の値は何時クライアントが往復遅延測定パケットに応答する能力を有するかについて示し、ビット１９の値は何時クライアントが順方向リンクスキュー較正パケットに応答する能力を有するかについて示し、そしてビット１９の値は何時クライアントがＶＥＳＡＭＣＣＳバーチャル制御パネル（ＶＣＰ）パケットに応答する能力を有するかについて示す。一実施形態において、ビット２０の値は、クライアントがディスプレイ電力状態パケットに応答する能力を持つときを示す。

一実施形態において、ビット２１の値は、ビット０、１、および２またはこのフィールドにより指定されるクライアントによりこれらのパケットがサポートされるなら、ビットマップブロック転送パケット（パケットタイプ７１）、ビットマップ塗りつぶしパケット（パケットタイプ７２）およびビットマップパターン塗りつぶしパケット（パケットタイプ７３）のラスタ演算を使用する能力を有するときを示す。一実施形態において、ビット２１がロジックゼロレベルまたはゼロ値を有し、パケットがサポートされているなら、クライアントは、ラスタ演算を使用する能力を有しておらず、クライアントは、これらのパケットにより指定されるピクセルロケーションにコピーするまたは書き込む能力を有するにすぎない。

ビット２２の値は、クライアントが登録アクセスパケットに応答する能力を有するか否か示す。ビット２３乃至３１は将来の使用またはシステム設計者に有用な代替指定の現在予約され、一般的にゼロ値またはロジックゼロレベルに等しく設定されている。

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

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

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

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

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

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

キーボードデータフォーマットフィールド（ここでは１バイト）はキーボードがクライアントシステムに接続されているか否かおよび接続されているキーボードの型式について指定する。一実施の形態において、ビット６乃至０によって設定された値は接続されているキーボードの型式を規定するために使用される。値がゼロ（０）の場合キーボードの型式は知られていないと考えられる。１の値に関しては、キーボードデータフォーマットは標準のＰＳ−２スタイルと考えられる。現時点において２乃至１２５の範囲の値は使用されておらず、ＭＤＤＩおよび対応するクライアントまたはホストの使用のための特有のキーボードまたは入力装置について規定するため、システム設計者およびインターフェース設立者または製品開発者の使用のために留保される。１２６の値はキーボードデータフォーマットが使用者によって定義されることを示すために使用され、一方１２７の値はキーボードがこのクライアントに接続することができないことを示すために使用される。加えて、ビット７はキーボードがクライアントと通信することができるか否かを示すために使用することができる。このビットについて意図される使用は、何時キーボードは無線リンクを使用するクライアントと通信可能であるかを示すことにある。ビット６乃至０がキーボードがクライアントに接続できないことを示す場合、ビット７は０レベルに設定されるであろう。それ故に、一実施の形態において、ビット７の値が０のとき、キーボードとクライアントは通信できず、一方、ビット７の値が１のとき、キーボードとクライアントはこれらが互いに通信できることを確認する。

ポインティングデバイスデータフォーマットフィールド（ここでは１バイト）はポインティングデバイスがクライアントシステムに接続されるか否か、および接続されるポインティングデバイスの型式を規定する。一実施の形態において、ビット６によって設定される値は接続されるポインティングデバイスの型式を規定するために使用される。値がゼロ（０）の場合、ポインティングデバイスの型式は知られていないと考えられる。１の値に関し、ポインティングデバイスデータフォーマットは標準のＰＳ−２スタイルであると考えられる。現時点において２乃至１２５の範囲の値は使用されておらず、ＭＤＤインターフェースおよび対応するクライアントまたはホストの使用のための特有のポインティングデバイスまたは入力装置について規定するため、システム設計者およびインターフェース設立者または製品開発者の使用のために留保される。１２６の値はポインティングデバイスデータフォーマットが使用者によって定義されることを示すために使用され、一方１２７の値はポインティングデバイスはこのクライアントに接続することができないことを示すために使用される。加えて、ビット７は、ポインティングデバイスがクライアントと通信できるか否かを示すために使用することができる。このビットの意図する使用は何時キーボードはクライアントと無線リンクを使用して通信できるかを示すことにある。ビット６乃至０がポインティングデバイスがクライアントに接続できないことを示す場合、ビット７はゼロレベルに設定されるであろう。それ故に一実施の形態において、ビット７の値が０の場合、ポインティングデバイスとクライアントは通信することができず、一方ビット７の値が１の場合、ポインティングデバイスとクライアントはこれらが互いに通信できることを確認する。

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

ＭｆｒＮａｍｅ−２バイトは、ＶＥＳＡＥＤＩＤ仕様と同様の方法で、３つの５ビットキャラクタにパックされた製品のＥＩＳＡ３−キャラクタＩＤを含む。キャラクタ'Ａ'は００００１バイナリとして表現される。キャラクタ'Ｚ'は１１０１０バイナリとして表現される。そして'Ａ'と'Ｚ'との間の全ての文字は'Ａ'および'Ｚ'間のアルファベットのシーケンスに対応する連続する２進値として表現される。ＭｆｒＮａｍｅフィールドの最上位のビットは使用されず、そして一般に将来の実施において使用がなされるまでロジック−０に設定される。例えば、ストリング"ＸＹＺ"によって表現される製造業者は０ｘ６３３ａのＭｆｒＮａｍｅ値を有するであろう。このフィールドがクライアントによってサポートされていない場合は、これはゼロに設定されるであろう。製品コードフィールドはディスプレイ製造業者によって割り当てられた製品コードを含むため２バイトを使用する。このフィールドがクライアントによってサポートされない場合、これは一般にロジック−ゼロレベルに設定される。

留保された１、留保された２、そして留保された３フィールド（ここではそれぞれ２バイト）は情報を伝えるための将来の使用のために設定される。このフィールドの全てのビットは一般にゼロに設定される。かかるフィールドの目的は一般に、全ての後で生ずる２バイトフィールドを１６−ビットワードアドレスに位置合わせさせることであり、そして４−バイトフィールドを３２−ビットワードアドレスに位置合わせさせることである。

この実施形態において、連続番号フィールドは４バイトを使用し、これはディスプレイの連続番号を数字の形式で特定する。このフィールドがクライアントによってサポートされない場合、これは一般にゼロに設定される。製造の週フィールドは、ディスプレイの製造の週を特定するために１バイトを使用する。これがクライアントによってサポートされた場合、この値は１乃至５３の範囲とされる。もしこれがクライアントによってサポートされない場合、この値はゼロに設定される。製造の年フィールドは１バイトであり、これはディスプレイの製造の年を規定する。この値は１９９０年からのオフセットである。１９９１乃至２２４５の範囲の年はこのフィールドによって表現できる。例：２００３年は製造値１３年に対応する。このフィールドがクライアントによってサポートされない場合は、これはゼロに設定される。

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

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

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

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

クライアントビジーフラッグフィールドは、２バイトを用いて、クライアントが特定の機能を実行しており、その機能に関連する別のパケットを受け入れるための準備がまだできていないことを示す。ロジック１レベルまたは値に設定されるビットは、特定の機能が現在実行されており、クライアント内の関連する機能はビジーであることを示す。クライアント内の関連機能がレディ状態なら、ビットはロジックゼロに設定される。クライアントは、クライアント内でサポートされていないすべての機能に対してビジー状態（１に設定されたビット）を戻さなければならない。

一実施形態において、これらのバイトは、以下の関係に従って解釈される。ビット０が「１」なら、ビットマップブロック転送機能はビジーであり、一方、ビット１が「１」であるなら、ビットマップエリア塗りつぶし機能はビジーであり、ビット２が「１」であるなら、ビットマップパターン塗りつぶし機能はビジーである。同時にビット３が「１」なら、グラフィックサブシステムは、ビジーであり、クライアント内のフレームバッファの使用を必要とする動作を実行する。フレームバッファの使用を必要とする他のグラフィック機能は、このビットがロジック１に設定されるまで開始しないかもしれない。

現在ビット４乃至１５は、将来の使用のために予約され、一般的にロジック１レベルまたは状態に設定され、これらのビットが将来割り当てられる場合にビジー状態を示す。

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

Ｉ．ビットマップ領域塗りつぶしパケット
一実施形態において、２バイトピクセルデータ属性フィールドは、ピクセルデータが更新される場所を指定する値を有する。ビット１および０は、ピクセルデータが更新されるディスプレイを選択する。クライアント内の一次ディスプレイがステレオ画像をサポートしないなら、クライアントは、ビットの組み合わせ０１、１０、または１１の１つに対して一次ディスプレイ内のピクセルデータに影響を及ぼすことができる。ステレオ表示機能をサポートしないクライアント内の一次ディスプレイをアドレスするために値１１を使用することが推奨される。ビット「１：０」が値１１（ロジック１、ロジック１）を有するとき、ピクセルデータは、左目および右目の両方のフレームバッファ内で更新される。ビット「１：０」値１０（ロジック１、ロジックゼロ）を有するなら、左目だけのフレームバッファ内でピクセルデータが更新される。ビット「１：０」が値０１（ロジックゼロ、ロジック１）を有するとき、右目だけのフレームバッファにおいてピクセルデータが更新される。ビット［１：０］が値００（ダブルロジックゼロ）を有するとき、以下のビット８乃至１１により指定される代替ディスプレイのフレームバッファにおいてピクセルデータが更新される。

一実施形態において、ピクセルデータ属性フィールドのビット２は、左目または右目のためのバッファがこの演算のための画像のソースであるか否かを指定する。ビット「１：０」が００に等しくないとき、ビット２のみが適用される。これは、画像のデスティネーションが代替ディスプレイの１つであるときこれは、メイン画像からのソースデータをサポートしないことを意味するように一般的に実施される。ビット２は、データソースとして左目フレームバッファまたは右目フレームバッファ間で区別化または指定するために使用される。ビット２がロジック０（ロジックゼロレベル）に等しいとき、左目フレームバッファは、データソースであるが、ビット２が１（ロジック１レベル）に等しいとき、右目フレームバッファはデータソースである。

ピクセルデータ属性フィールドのビット３は、ディスプレイをリフレッシュするために使用されるバッファまたはオフライン画像バッファがこの演算のための画像のソースになるかどうかを指定する。代替ディスプレイがオフライン画像バッファを利用するなら、ビット３はまた代替ディスプレイに適用されてもよい。しかしながら、これは、画像のデスティネーションが代替ディスプレイであるとき、逆の場合も同じであるとき、メイン画像バッファからのソースデータをサポートしない。ビット３が０の値またはロジックゼロレベルであるとき、ディスプレイをリフレッシュするために使用される画像バッファは、データソースである。ビット３が１の値またはロジック１レベルに等しいとき、オフライン画像バッファはデータソースである。

ピクセルデータ属性フィールドのビット７および６は、ピクセルデータが更新されるまたは書かれるフレームバッファを指定するディスプレイ更新ビットとして作用する。フレーム更新ビットの効果は、上により詳細に記載されている。ビット「７：６」が「０１」（ロジックゼロ、ロジック１）であるとき、ピクセルデータは、オフライン画像バッファに書かれる。ビット［７：６］が「００」（ダブルロジックゼロ）であるとき、ピクセルデータは、ディスプレイをリフレッシュするために使用される画像バッファに書かれる。ビット「７：６」が「１１」（ダブルロジック１）であるとき、ピクセルデータは、すべての画像バッファに書かれる。ビット「７：６」が「１０」なら、これは無効な値として取り扱われる。これらのビットは現在、将来の使用のために予約される。この状況で、全体のコマンドは無視され、フレームバッファは更新されない。

ピクセルデータ属性フィールドのビット１１乃至８は、ピクセルデータが更新される代替ディスプレイまたは代替クライアントロケーションを指定する４ビットの符号なしの整数を形成する。ビット０および１は、クライアントがビット１１乃至８を代替ディスプレイ番号として解釈するために００（ダブルロジックゼロ）の値に等しく設定される。ビット１およびビット０が００に等しくないなら、ビット８乃至１１は、一般的にロジックゼロ値またはロジックゼロレベルに等しく設定される。ビット４乃至５およびビット１２乃至１５は、将来の使用のために予約され、一般的にロジックゼロレベルまたはロジックゼロ値に設定される。

一実施形態において、２バイトラスタ演算フィールドは、どのようにしてソースおよびデスティネーションロケーションにおけるピクセルを結合してデスティネーショ画像ロケーションに書かれる新しいピクセル値を形成する。ラスタ演算は、どのようにしてフレームバッファ内における等しいサイズの２つの異なる矩形領域が一緒にマージされるのかを定義する。また、デスティネーション画像領域は、一緒にマージされる２つの画像の１つでもある。２つの画像の２番目は、ソース画像と呼ばれる。クライアントが、クライアント機能パケット内で指定されたラスタ演算フィールドをサポートしないなら、ホストは一般的に３に等しいビット３乃至０を有したパケットを送信し、クライアントはビット３乃至０を無視する。

一実施形態において、ビット３乃至０は、その値の次に示される対応する演算を選択するために以下の表ＸＶＩに示される値の１つに等しいビット３乃至０を用いてまたは設定することにより実際のラスタ演算を指定するために使用される。すなわち、第１列にリストアップされた各指定されたビット［３：０］は、第２列で指定された演算を結果として生じる。さらにここでは、明確化のために第３列に定義される。

ビット５乃至４は、デスティネーションピクセルが、透明色に関連するデスティネーションロケーションに書かれるか否かを指定するために使用される。ビット５乃至４により指定される演算は、ラスタ演算がクライアント装置によりサポートされるか否かに適用される。クライアントがラスタ演算をサポートしないなら、ビット５乃至４により定義される演算に対して考慮される結果として生じるデスティネーションピクセル値は、ソースピクセル値のみに等しい。

ビット「５：４」の値が００に等しいなら、透明色は使用されない。結果として生じるデスティネーションピクセルは、透明色イネーブルパケットにより定義される透明色の値を考慮することなしに、デスティネーションピクセルロケーションに書かれる。０１に等しいビット［５：４］の値は、現在、将来の使用のために予約され、典型的には、使用されていない。だけれども、そのための関連した使用を確立することは当業者に利用可能である。ビット［５：４］の値が１０に等しいとき、ラスタ演算により計算された結果として生じるデスティネーションピクセルが透明色に等しいなら、結果として生じるピクセルは、デスティネーションピクセルロケーションに書かれない。さもなければ、それはデスティネーションピクセルロケーションに書かれる。ビット［５：４］の値が１１に等しいとき、ラスタ演算により計算された結果として生じるデスティネーションピクセルが透明色に等しいなら、結果として生じるピクセルはデスティネーションピクセルロケーションに書かれない。さもなければ、結果として生じるピクセルはデスティネーションピクセルロケーションに書かれない。

ビット１５乃至１６は将来の使用のために予約され、それゆえ一般的には、ロジックゼロ値またはレベルに等しく設定される。

Ｊ．ビットマップパターン塗りつぶしパケットの場合
一実施形態において、ビットマップパターン塗りつぶしパケット内の左上座標Ｘ値とＹ値は２バイトを使用し、各バイトは、塗りつぶすウィンドウの左上隅の座標のＸおよびＹ値を指定する。ウィンドウ幅フィールドおよびウィンドウ高さフィールド（各々２バイト）は、塗りつぶすウィンドウの幅と高さを指定する。パターン幅フィールドおよびパターン高さフィールド（各々２バイト）は、それぞれ塗りつぶしパターンの幅と高さを指定する。水平パターンオフセットフィールド（２バイト）は、塗りつぶす指定されたウィンドウの左端縁からのピクセルデータパターンの水平オフセットを指定する。指定されている値は、パターン幅フィールド内の値未満である。垂直パターンオフセットフィールド（２バイト）は、塗りつぶす指定されたウィンドウの上端縁からのピクセルデータパターンの垂直オフセットを指定する。指定されている値はパターン高さフィールド内の値未満である。

一実施形態において、２バイトピクセルデータ属性フィールドは、ピクセルデータが更新される場所を指定する値を有し、ビット１および０はピクセルデータが更新されるディスプレイを選択する。クライアント内の一次ディスプレイはステレオ画像をサポートしないなら、クライアントは、ビットの組み合わせ０１、１０または１１の１つのための一次ディスプレイ内のピクセルデータに影響を及ぼすことができる。ステレオ表示能力をサポートしないクライアント内の一次ディスプレイをアドレスするために値１１を使用することが推奨される。ビット［１：０］が値１１（ロジック１、ロジック１）を有するとき、左目と右目の両方のフレームバッファ内でピクセルデータが更新され、ビット［１：０］は値１０（ロジック１、ロジック０）を有するなら、ピクセルデータは、左目のみのフレームバッファ内で更新される。ビット［１：０］が値０１（ロジックゼロ、ロジック１）を有するとき、ピクセルデータは右目のみのフレームバッファ内で更新される。ビット［１：０］が値００（ダブルロジックゼロ）を有するとき、ピクセルデータは、以下のビット８乃至１１により指定される代替ディスプレイのフレームバッファ内で更新される。

一実施形態において、ピクセルデータ属性フィールドのビット２は、左目または右目のためのバッファがこの演算のための画像のソースであるか否かを指定する。ビット［１：０］が００に等しくないとき、ビット２のみが適用される。これは一般的に、画像のデスティネーションが代替ディスプレイの１つであるとき、これは、メイン画像からのソースデータをサポートしないことを意味するために実施される。ビット２は、データソースとして、左目フレームバッファおよび右目フレームバッファの間として区別するまたは指定するために使用される。ビット２が０（ロジックゼロレベル）に等しいとき、左目フレームバッファがデータソースであるが、ビット２が１（ロジック１レベル）に等しいとき、右目フレームバッファがデータソースである。

ピクセルデータ属性フィールドのビット３は、ディスプレイをリフレッシュするために使用されるディスプレイまたはオフライン画像バッファがこの演算のための画像のソースであるかどうかを指定する。また、ビット３は、代替ディスプレイがオフライン画像バッファを利用するなら代替ディスプレイに適用される。しかしながら、これは、画像のデスティネーションが代替ディスプレイであるときまたはその逆も同様のとき、メイン画像バッファからのソースデータをサポートしない。ビット３が０の値またはロジックゼロレベルに等しいとき、ディスプレイをリフレッシュするために使用される画像バッファはデータソースである。ビット３が１の値またはロジック１レベルに等しいとき、オフライン画像バッファはデータソースである。

ピクセルデータ属性フィールドのビット７および６は、ピクセルデータが更新されるまたは書かれるフレームバッファを指定するディスプレイ更新ビットとして作用する。フレーム更新ビットの効果は、より詳細に上に記載されている。ビット［７：６］が「０１」（ロジックゼロ、ロジック１）であるとき、ピクセルデータは、オフライン画像バッファに更新される。ビット「７：６］が（ダブルロジックゼロ）であるとき、ピクセルデータはディスプレイをリフレッシュするために使用される画像バッファに書かれる。ビット［７：６］が「１１」（ダブルロジック１）であるとき、ピクセルデータは、すべての画像バッファにおいて更新される。ビット［７：６］が「１０」なら、これは無効値として取り扱われる。これらのビットは現在、将来の使用のために予約される。この状況において、全体のコマンドは無視されフレームバッファは更新されない。

ピクセルデータ属性フィールドのビット１１乃至８は、ピクセルデータが更新されるディスプレイまたは代替クライアントロケーションを指定する。ビット０と１は、クライアントがビット１１乃至８を代替ディスプレイ番号として解釈するように００（ダブルロジックゼロ）の値に等しく設定される。ビット１および０が００に等しくないなら、ビット８乃至１１は、一般的にロジックゼロ値またはレベルに等しく設定される。ビット４乃至５および１２乃至１５は、将来のために予約され、一般的には、ロジックゼロレベルまたは値に設定される。

一実施形態において、２バイトラスタ演算フィールドは、どのようにしてソースロケーションおよびデスティネーションロケーションにおいてピクセルを結合し、デスティネーション画像ロケーションに書かれる新しいピクセル値を形成するかを指定する。ラスタ演算は、どのようにしてフレームバッファ内の等しいサイズの２つの異なる矩形の領域を一緒にマージするかを定義する。また、デスティネーション画像領域は、一緒にマージされた２つの画像の一方である。

２つの画像の２番目はソース画像と呼ばれる。クライアントが、クライアント機能パケットで指定されるラスタ演算をサポートしないなら、ホストは３に等しいビット３乃至０を有するこのパケットを一般的に送信し、クライアントはビット３乃至０を無視する。

一実施形態において、その値の次に示される対応する演算を選択するために表ＸＶＩＩに示される値の１つに等しくビット３乃至０を用いてまたは設定することにより実際のラスタ演算を指定するためにビット３乃至０が使用される。すなわち、第１列にリストアップされたビット［３：０］は、第２列で指定される演算を生じ、第３列において明確化のためにさらに定義される。

ビット５乃至４は、透明色に関連しているので、デスティネーションピクセルがデスティネーションロケーションに書かれるか否かを指定するために使用される。ビット５乃至４により指定される演算は、ラスタ演算がクライアント装置によりサポートされるにせよされないにせよ適用される。クライアントがラスタ演算をサポートしないなら、ビット５乃至４により定義される演算に対して考慮される結果として生じるデスティネーションピクセル値はソースピクセル値のみに等しい。

ピクセルデータ属性フィールドのビット［５：４］の値が００に等しいとき、透明色は使用されない。結果として生じるデスティネーションピクセルは、透明色イネーブルパケットにより定義される透明色の値を考慮せずにデスティネーションピクセルロケーションに書かれる。０１に等しいビット［５：４］の値は現在、将来の使用のために予約され、典型的に使用されていない。しかし、関連する使用を確立するために当業者により利用可能である。ビット［５：４］の値が１０に等しいとき、ラスタ演算により計算された結果として生じたデスティネーションピクセルが透明色に等しいなら、結果として生じるピクセルはデスティネーションピクセルロケーションに書かれない。さもなければ、それはデスティネーションピクセルロケーションに書かれる。ビット［５：４］の値が１１に等しいとき、ラスタ演算により計算された結果として生じるデスティネーションピクセルが透明色に等しいなら、結果として生じるピクセルはデスティネーションピクセルロケーションに書かれない。さもなければ、結果として生じるピクセルは、デスティネーションピクセルロケーションに書かれない。

ビット１５乃至６は将来の使用のために予約され、それゆえ、一般的には、ロジックゼロ値またはレベルに等しく設定される。

一実施形態において、ビットマップ塗りつぶしパケット内の２バイトパラメーターＣＲＣフィールドは、パケット長からビデオフォーマットディスクリプタまでのすべてのバイトのＣＲＣを含む。このＣＲＣがチェックに失敗するなら、全体のパケットが破棄される。パターンピクセルデータフィールドは、ビデオデータフォーマットディスクリプタにより指定されるフォーマットで塗りつぶしパターンを指定する生のビデオ情報を含む。データはバイトにパックされ、各行の第１ピクセルはバイト合わせされている。塗りつぶしパターンデータは一度に１行の割合で送信される。ビットマップパターン塗りつぶしパケットのためのパターンピクセルデータＣＲＣフィールドは、パターンピクセルデータのみのＣＲＣを含む２バイトを使用する。このＣＲＣがチェックに失敗するなら、パターンピクセルデータは、依然として使用することができるが、ＣＲＣエラーカウントはインクリメントされる。

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

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

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

Ｍ．デジタルコンテンツ保護オーバヘッドパケット用
コンテンツ保護タイプフィールド（１バイト）は、使用されるデジタルコンテンツ保護方法を指定する。１という値は高帯域幅デジタルコンテンツ保護システム（ＨＤＣＰ）を示すが、「０」という値はデジタル伝送コンテンツ保護（ＤＴＣＰ）を示す。２から２５５という値は、現在指定されていいないが、所望されるように代替保護方式との使用のために予約されている。コンテンツ保護オーバヘッドメッセージフィールドは、ホストとクライアントの間で送信されるコンテンツ保護メッセージを含む可変長のフィールドである。Ｎ．往復遅延測定パケット２バイトのパケット長フィールドは、パケット長フィールドを含まないパケット内のバイト総数を指定し、一実施形態では、１５９という固定長を有するように選択されている。このパケットタイプを８２という値で識別する２バイトのパケットタイプフィールドは、往復遅延測定パケットとしてパケットを識別する。ｈＣｌｉｅｎｔＩＤフィールドは、前記のように、クライアントＩＤとして将来使用するために予約されており、通常ゼロに設定されている。

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

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

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

測定期間フィールドは、クライアントが、順方向リンクで使用されるデータレートの半分で、０ｘｆｆという２つのバイト、及び０ｘ０という３０バイトに応答できるようにするために使用される６４バイトのウィンドウである。

このデータレートは１という逆方向リンクレート除数に相当する。クライアントは、それが測定期間の始まりであると知覚するとただちにこの応答を返す。このクライアントからの応答は、正確にリンクの往復遅延に、ホストでの測定期間の第１のビットの開始後のクライアントのロジック遅延を加えたもので、ホストで受信される。

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

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

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

オールゼロ１フィールドは８バイトを使用して、較正データシーケンスフィールドの始めでＭＤＤＩＳｔｂ上に遷移があることを保証する。一般に、これらのバイトは８ビットの符号なしのゼロに等しい整数を採用する。それはまた、クライアントコアロジックがＭＤＤＩ＿０およびＭＤＤＩ＿ＳｔｂのＸＯＲを使用することからクロックリカバリ回路のモードを変化させる、または他のリカバーされたクロックとしてＭＤＤＩ＿ＳｔｂまたはＭＤＤＩ＿Ｓｔｂ信号を用いるための十分な時間を提供する。

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

タイプＩ−（６４バイトデータシーケンス）０ｘａａ，ｏｘａａ．．．ｏｒ０ｘ５５，０ｘ５５．．．
タイプＩＩ−（１２８バイトデータシーケンス）０ｘｃｃ，０ｘｃｃ．．．ｏｒ０ｘ３３，０ｘ３３．．．
タイプＩＩＩ−（２５６バイトデータシーケンス）０ｘｆ０，０ｘｆ０．．．ｏｒ０ｘ０ｆ，０ｘｆ０．．．
タイプＩＶ−（５１２バイトデータシーケンス）０ｘｆｆ，０ｘ００，０ｘｆｆ，０ｘ００．．．０ｒ０ｘ００，０ｘｆｆ，０ｘ００，０ｘｆｆ
オールゼロ２フィールドは８バイトを用いて、クライアントコアロジックが、リカバーされたクロックとしてＭＤＤＩ＿Ｓｔｂ信号を使用することから、ＭＤＤＩ＿０とＭＤＤＩ＿ＳｔｂのＸＯＲを使用することまで、クロックリカバリ回路のモードをオリジナルの状態に戻すのに十分な時間を提供する。一般的に、これらのバイトは、８ビットの符号なしのゼロに等しい整数を採用する。

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

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

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

ＸＩＸ．結論
本発明の多様な実施形態は前述されてきたが、それらが例証としてのみ提示され、制限ではないことが理解されるべきである。したがって、本発明の幅及び範囲は、前述された例示的な実施形態のいずれによっても制限されるべきではなく、添付請求項及びその同等物に従ってのみ定義されるべきである。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
通信路を介してホスト装置とクライアント装置との間で高レートでデジタルプレゼンテーションデータを転送するためのデジタルデータインターフェースにおいて、
前記通信路を介してホストとクライアントとの間であらかじめ選択されたデジタル制御およびプレゼンテーションデータのセットを通信するための通信プロトコルを形成するために一緒にリンクされた複数のパケット構造と、
前記通信路を介して前記クライアントに接続された前記ホスト装置内に常駐する少なくとも１つのリンクコントローラーであって、前記通信プロトコルを形成するパケットを発生し、送信し、受信するように、およびプレゼンテーションデータを１つ以上のタイプのデータパケットに形成するように構成された少なくとも１つのリンクコントローラーと、
を備えたデジタルデータインターフェース。
［Ｃ２］
前記ホストとクライアントの間で通信され、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有する、メディアフレーム内で共にグループ化される前記パケットをさらに備える、Ｃ１に記載のインターフェース。
［Ｃ３］
前記ホストからのパケットの転送の始めに配置されるサブフレームヘッダーパケットをさらに備える、Ｃ１に記載のインターフェース。
［Ｃ４］
特定のクライアントに関連するハードウェアを低電力状態に設定するためのディスプレイ電力状態パケットをさらに備えた、Ｃ１のインターフェース。
［Ｃ５］
前記リンクコントローラーはホストリンクコントローラーであって、前記通信路を介して前記ホストに接続される前記クライアントデバイスに常駐する少なくとも１つのクライアントリンクコントローラーであって、前記通信プロトコルを形成するパケットを生成し、送信し及び受信し、デジタルプレゼンテーションデータを１つ以上のタイプのデータパケットに形成するように構成される少なくとも１つのクライアントリンクコントローラーをさらに備えた、Ｃ１に記載のインターフェース。
［Ｃ６］
それぞれが既定の期間に並列でデータの異なる最大数のビットの転送を可能にする複数の転送モードであって、各モードが前記ホストリンクドライバーとクライアントリンクドライバーの間の交渉により選択可能である、複数の転送モードをさらに備え、
前記転送モードはデータの転送中に前記モードの間で動的に調整可能である、Ｃ２に記載のインターフェース。
［Ｃ７］
前記通信路上、どちらかの方向でデータの転送を終了するために、前記ホストによる前記クライアントに対する伝送のためのリンクシャットダウンタイプパケットをさらに備える、Ｃ１に記載のインターフェース。
［Ｃ８］
前記クライアントがハイバネーション状態から前記ホストをウェイクアップするための手段をさらに備える、Ｃ１に記載のインターフェース。
［Ｃ９］
ユーザへのプレゼンテーションのために通信路上、ホストデバイスとクライアントデバイスの間において高レートでデジタルデータを転送する方法であって、
複数の所定のパケット構造の内の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクすることと、
前記通信プロトコルを使用して、前記通信路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信することと、
前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、前記ホストデバイスに常駐する少なくとも１台のホストリンクコントローラーを、前記通信路を介して前記クライアントデバイスに接続することと、
前記リンクコントローラーを使用して前記通信路上でパケットの形を取るデータを転送することと、
を備える方法。
［Ｃ１０］
前記ホストとクライアント間の通信のために、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有するメディアフレーム内で、前記パケットを共にグループ化することをさらに備える、Ｃ９に記載の方法。
［Ｃ１１］
サブフレームヘッダタイプパケットを用いる前記ホストからのパケットの転送を開始することをさらに備える、Ｃ９に記載の方法。
［Ｃ１２］
前記通信路を介して前記ホスト装置に接続された前記クライアント装置に常駐する少なくとも１つのクライアントリンクコントローラーを介して前記通信プロトコルを形成するパケットを生成し、送信し、受信することをさらに備えた、Ｃ９の方法。
［Ｃ１３］
前記ホストリンクドライバーと前記クライアントリンクドライバーの間で、それぞれが既定の期間において並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つの使用を交渉することと、
データの転送中、前記転送モードの間で動的に調整することと、
をさらに備える、Ｃ１２に記載の方法。
［Ｃ１４］
前記クライアントへの前記ホストによる伝送のために、リンクシャットダウンタイプのパケットを使用して前記通信路においてどちらかの方向でデータの転送を終了することをさらに備える、Ｃ１２に記載の方法。
［Ｃ１５］
前記クライアントとの通信によりハイバネーション状態から前記ホストをウェイクアップすることをさらに備える、Ｃ９に記載の方法。
［Ｃ１６］
特定のクライアントハードウェアを低電力状態に設定するためにディスプレイ電力状態パケットを生成することをさらに備えた、Ｃ９の方法。
［Ｃ１７］
ユーザへのプレゼンテーションのために通信路上、ホストデバイスとクライアントデバイスの間において高レートでデジタルデータを転送するための装置において、
複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするために、及び前記通信プロトコルを使用して前記通信路上、前記ホストデバイスと前記クライアントデバイスの間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するために、前記ホストデバイス内に配置される少なくとも１つのホストリンクコントローラーと、
前記クライアントデバイスに配置され、前記通信路を介して前記ホストリンクコントローラーに接続される、少なくとも１つのクライアントコントローラーと、
前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、各リンクコントローラーと、
を備える、装置。
［Ｃ１８］
前記ホストコントローラーは状態機械を備える、Ｃ１７に記載の装置。
［Ｃ１９］
前記ホストコントローラーは汎用信号プロセッサを備える、Ｃ１７に記載の装置。
［Ｃ２０］
前記ホストからのパケットの転送の開始時にサブフレームヘッダタイプパケットをさらに備える、Ｃ１７に記載の装置。
［Ｃ２１］
前記ホストコントローラーは１台又は複数台の差動ラインドライバーを備え、前記クライアントレシーバは前記通信路に接続される１台又は複数台の差動ラインレシーバを備える、Ｃ１７に記載の装置。
［Ｃ２２］
前記ホストリンクコントローラーとクライアントリンクコントローラーは、それぞれが既定の期間において、並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つを使用するように構成され、データの転送中、前記転送モードの間で動的に調整することができる、Ｃ１７に記載の装置。
［Ｃ２３］
前記ホストコントローラーは、前記通信路上、どちらかの方向でデータの転送を終了するために、前記クライアント手段にリンクシャットダウンタイプのパケットを送信するように構成される、Ｃ１７に記載の装置。
［Ｃ２４］
前記ホストコントローラーは、特定のディスプレイコントローラーハードウェアを低電力状態に設定するためにディスプレイ電力状態パケットを生成するように構成される、Ｃ１７の装置。
［Ｃ２５］
ユーザに対するプレゼンテーションのために通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムでの使用のために、
アプリケーションプログラムを前記コンピューターシステム上で実行させるために、前記媒体で具現化されるコンピューター読み取り可能プログラムコード手段を有するコンピューター使用可能な媒体を備える、コンピュータープログラム製品であって、前記コンピューター読み取り可能プログラムコード手段は、
コンピューターシステムに複数の所定のパケット構造の１つ又は複数を生成させ、所定の通信プロトコルを形成するために、それらを共にリンクさせるためのコンピューター読み取り可能第１プログラムコード手段と、
前記コンピューターシステムに、前記通信プロトコルを使用して前記通信路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信させるための、コンピューター読み取り可能第２プログラムコード手段と、
前記コンピューターシステムに、前記通信路を通して、前記ホストデバイスに配置される少なくとも１台のホストリンクコントローラーを、前記クライアントデバイスに配置される少なくとも１台のクライアントコントローラーに結合させるようにするための、コンピューター読み取り可能第３プログラムコード手段であって、前記リンクコントローラーは、前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、コンピューター読み取り可能第３プログラムコード手段と、
前記リンクコントローラーを使用して前記通信路上、パケットの形をしたデータをコンピューターシステムに転送させるためのコンピューター読み取り可能第４プログラムコード手段と、
を備える、コンピュータープログラムプロダクト。
［Ｃ２６］
コンピューターシステムに所定のパケット構造を生成させ、それらを一緒にリンクさせ所定の通信プロトコルを形成させるためのコンピューター読み取り可能プログラムコード手段を備えた、Ｃ２５のコンピュータープログラムプロダクト。
［Ｃ２７］
ユーザに対するプレゼンテーションのために、通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための装置において、
複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするための手段と、
前記通信プロトコルを使用して前記通信路で前記ホストデバイスと前記クライアントデバイスの間で、事前に選択されたデジタル制御データ及びデジタルプレゼンテーションデータを通信するための手段と、
前記ホストとクライアントのそれぞれに１つ、それぞれが前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、少なくとも２台のリンクコントローラーを、前記通信路を介して共に接続するための手段と、
前記リンクコントローラーを使用して前記通信路上、パケットの形をとるデータを転送するための手段と、
を備える、装置。
［Ｃ２８］
サブフレームヘッダタイプパケットを用いて、前記ホストからパケットの転送を開始するための手段をさらに備えた、Ｃ２７に記載の装置。
［Ｃ２９］
特定のハードウェアを低電力状態に設定するように構成されたディスプレイ電力状態パケットを生成する手段をさらに備えた、Ｃ２７の装置。
［Ｃ３０］
前記クライアントが前記インターフェースを介してどのようなタイプのデータとデータレートに対処できるのかを決定するために、ホストリンクコントローラーによってクライアントから表示機能情報を要求するための手段をさらに備えた、Ｃ２７に記載の装置。
［Ｃ３１］
通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムで使用するためのプロセッサであって、複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクし、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成し、前記通信プロトコルを使用して前記通信路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信し、前記通信路上でパケットの形をしたデータを転送するように構成された、プロセッサ。
［Ｃ３２］
通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムで使用するための状態機械であって、前記状態機械は、少なくとも１つのAsync Frames State同期化状態と、少なくとも２つのAcquiring Sync State同期状態と、少なくとも３つのIn-Sync States同期状態を有するように構成される状態機械。
［Ｃ３３］
通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムで使用するための状態機械であって、前記状態機械は、少なくとも１つのAcquiring Sync States同期状態と、少なくとも２つのIn-Sync States同期状態を有するように構成される状態機械。

Claims

通信路を介してホスト装置とクライアント装置との間で高レートでデジタルプレゼンテーションデータを転送するためのデジタルデータインターフェースにおいて、
前記通信路を介してホストとクライアントとの間であらかじめ選択されたデジタル制御およびプレゼンテーションデータのセットを通信するための通信プロトコルを形成するために一緒にリンクされた複数のパケット構造と、
前記通信路を介して前記クライアントに接続された前記ホスト装置内に常駐する少なくとも１つのリンクコントローラーであって、前記通信プロトコルを形成するパケットを発生し、送信し、受信するように、およびプレゼンテーションデータを１つ以上のタイプのデータパケットに形成するように構成された少なくとも１つのリンクコントローラーと、
を備えたデジタルデータインターフェース。
前記ホストとクライアントの間で通信され、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有する、メディアフレーム内で共にグループ化される前記パケットをさらに備える、請求項１に記載のインターフェース。
前記ホストからのパケットの転送の始めに配置されるサブフレームヘッダーパケットをさらに備える、請求項１に記載のインターフェース。
特定のクライアントに関連するハードウェアを低電力状態に設定するためのディスプレイ電力状態パケットをさらに備えた、請求項１のインターフェース。
前記リンクコントローラーはホストリンクコントローラーであって、前記通信路を介して前記ホストに接続される前記クライアントデバイスに常駐する少なくとも１つのクライアントリンクコントローラーであって、前記通信プロトコルを形成するパケットを生成し、送信し及び受信し、デジタルプレゼンテーションデータを１つ以上のタイプのデータパケットに形成するように構成される少なくとも１つのクライアントリンクコントローラーをさらに備えた、請求項１に記載のインターフェース。
それぞれが既定の期間に並列でデータの異なる最大数のビットの転送を可能にする複数の転送モードであって、各モードが前記ホストリンクドライバーとクライアントリンクドライバーの間の交渉により選択可能である、複数の転送モードをさらに備え、
前記転送モードはデータの転送中に前記モードの間で動的に調整可能である、請求項２に記載のインターフェース。
前記通信路上、どちらかの方向でデータの転送を終了するために、前記ホストによる前記クライアントに対する伝送のためのリンクシャットダウンタイプパケットをさらに備える、請求項１に記載のインターフェース。
前記クライアントがハイバネーション状態から前記ホストをウェイクアップするための手段をさらに備える、請求項１に記載のインターフェース。
ユーザへのプレゼンテーションのために通信路上、ホストデバイスとクライアントデバイスの間において高レートでデジタルデータを転送する方法であって、
複数の所定のパケット構造の内の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクすることと、
前記通信プロトコルを使用して、前記通信路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信することと、
前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、前記ホストデバイスに常駐する少なくとも１台のホストリンクコントローラーを、前記通信路を介して前記クライアントデバイスに接続することと、
前記リンクコントローラーを使用して前記通信路上でパケットの形を取るデータを転送することと、
を備える方法。
前記ホストとクライアント間の通信のために、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有するメディアフレーム内で、前記パケットを共にグループ化することをさらに備える、請求項９に記載の方法。
サブフレームヘッダタイプパケットを用いる前記ホストからのパケットの転送を開始することをさらに備える、請求項９に記載の方法。
前記通信路を介して前記ホスト装置に接続された前記クライアント装置に常駐する少なくとも１つのクライアントリンクコントローラーを介して前記通信プロトコルを形成するパケットを生成し、送信し、受信することをさらに備えた、請求項９の方法。
前記ホストリンクドライバーと前記クライアントリンクドライバーの間で、それぞれが既定の期間において並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つの使用を交渉することと、
データの転送中、前記転送モードの間で動的に調整することと、
をさらに備える、請求項１２に記載の方法。
前記クライアントへの前記ホストによる伝送のために、リンクシャットダウンタイプのパケットを使用して前記通信路においてどちらかの方向でデータの転送を終了することをさらに備える、請求項１２に記載の方法。
前記クライアントとの通信によりハイバネーション状態から前記ホストをウェイクアップすることをさらに備える、請求項９に記載の方法。
特定のクライアントハードウェアを低電力状態に設定するためにディスプレイ電力状態パケットを生成することをさらに備えた、請求項９の方法。
ユーザへのプレゼンテーションのために通信路上、ホストデバイスとクライアントデバイスの間において高レートでデジタルデータを転送するための装置において、
複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするために、及び前記通信プロトコルを使用して前記通信路上、前記ホストデバイスと前記クライアントデバイスの間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するために、前記ホストデバイス内に配置される少なくとも１つのホストリンクコントローラーと、
前記クライアントデバイスに配置され、前記通信路を介して前記ホストリンクコントローラーに接続される、少なくとも１つのクライアントコントローラーと、
前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、各リンクコントローラーと、
を備える、装置。
前記ホストコントローラーは状態機械を備える、請求項１７に記載の装置。
前記ホストコントローラーは汎用信号プロセッサを備える、請求項１７に記載の装置。
前記ホストからのパケットの転送の開始時にサブフレームヘッダタイプパケットをさらに備える、請求項１７に記載の装置。
前記ホストコントローラーは１台又は複数台の差動ラインドライバーを備え、前記クライアントレシーバは前記通信路に接続される１台又は複数台の差動ラインレシーバを備える、請求項１７に記載の装置。
前記ホストリンクコントローラーとクライアントリンクコントローラーは、それぞれが既定の期間において、並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの１つを使用するように構成され、データの転送中、前記転送モードの間で動的に調整することができる、請求項１７に記載の装置。
前記ホストコントローラーは、前記通信路上、どちらかの方向でデータの転送を終了するために、前記クライアント手段にリンクシャットダウンタイプのパケットを送信するように構成される、請求項１７に記載の装置。
前記ホストコントローラーは、特定のディスプレイコントローラーハードウェアを低電力状態に設定するためにディスプレイ電力状態パケットを生成するように構成される、請求項１７の装置。
ユーザに対するプレゼンテーションのために通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムでの使用のために、
アプリケーションプログラムを前記コンピューターシステム上で実行させるために、前記媒体で具現化されるコンピューター読み取り可能プログラムコード手段を有するコンピューター使用可能な媒体を備える、コンピュータープログラム製品であって、前記コンピューター読み取り可能プログラムコード手段は、
コンピューターシステムに複数の所定のパケット構造の１つ又は複数を生成させ、所定の通信プロトコルを形成するために、それらを共にリンクさせるためのコンピューター読み取り可能第１プログラムコード手段と、
前記コンピューターシステムに、前記通信プロトコルを使用して前記通信路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信させるための、コンピューター読み取り可能第２プログラムコード手段と、
前記コンピューターシステムに、前記通信路を通して、前記ホストデバイスに配置される少なくとも１台のホストリンクコントローラーを、前記クライアントデバイスに配置される少なくとも１台のクライアントコントローラーに結合させるようにするための、コンピューター読み取り可能第３プログラムコード手段であって、前記リンクコントローラーは、前記通信プロトコルを形成するパケットを生成、送信及び受信し、１つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、コンピューター読み取り可能第３プログラムコード手段と、
前記リンクコントローラーを使用して前記通信路上、パケットの形をしたデータをコンピューターシステムに転送させるためのコンピューター読み取り可能第４プログラムコード手段と、
を備える、コンピュータープログラムプロダクト。
コンピューターシステムに所定のパケット構造を生成させ、それらを一緒にリンクさせ所定の通信プロトコルを形成させるためのコンピューター読み取り可能プログラムコード手段を備えた、請求項２５のコンピュータープログラムプロダクト。
ユーザに対するプレゼンテーションのために、通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための装置において、
複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするための手段と、
前記通信プロトコルを使用して前記通信路で前記ホストデバイスと前記クライアントデバイスの間で、事前に選択されたデジタル制御データ及びデジタルプレゼンテーションデータを通信するための手段と、
前記ホストとクライアントのそれぞれに１つ、それぞれが前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される、少なくとも２台のリンクコントローラーを、前記通信路を介して共に接続するための手段と、
前記リンクコントローラーを使用して前記通信路上、パケットの形をとるデータを転送するための手段と、
を備える、装置。
サブフレームヘッダタイプパケットを用いて、前記ホストからパケットの転送を開始するための手段をさらに備えた、請求項２７に記載の装置。
特定のハードウェアを低電力状態に設定するように構成されたディスプレイ電力状態パケットを生成する手段をさらに備えた、請求項２７の装置。
前記クライアントが前記インターフェースを介してどのようなタイプのデータとデータレートに対処できるのかを決定するために、ホストリンクコントローラーによってクライアントから表示機能情報を要求するための手段をさらに備えた、請求項２７に記載の装置。
通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムで使用するためのプロセッサであって、複数の所定のパケット構造の１つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクし、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成し、前記通信プロトコルを使用して前記通信路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信し、前記通信路上でパケットの形をしたデータを転送するように構成された、プロセッサ。
通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムで使用するための状態機械であって、前記状態機械は、少なくとも１つのAsync Frames State同期化状態と、少なくとも２つのAcquiring Sync State同期状態と、少なくとも３つのIn-Sync States同期状態を有するように構成される状態機械。
通信路上、ホストデバイスとクライアントデバイスの間において、高レートでデジタルデータを転送するための電子システムで使用するための状態機械であって、前記状態機械は、少なくとも１つのAcquiring Sync States同期状態と、少なくとも２つのIn-Sync States同期状態を有するように構成される状態機械。