ビデオディスプレイデータのデイジーチェイン方式のシリアル配信の能力を有するシステム
ディスプレイモニタを次々にデイジーチェイン接続できるようにＶＥＳＡ−ＤｉｓｐｌａｙＰｏｒｔインタフェース等のシリアルディスプレイインタフェースを拡張する。デイジーチェイン式に接続可能な各ディスプレイモニタは、自らに関連付けられたローカルのデイジーチェイン送受信デバイスを備え、ローカル送受信デバイスは、埋め込まれたＭＤＩＤ識別信号に応じてパススルーされるビデオデータストリームを選択的に取り出し、選択的に取り出したデータをローカルモニタに転送する。また、ローカル送受信デバイスは、パススルーされるビデオデータストリームを、デイジーチェインのよりダウンストリームのデバイスに中継する。一実施の形態においては、デイジーチェイン式に接続可能なディスプレイモニタは、ホットプラグ及びホットアンプラグに対応する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の開示は、ビデオディスプレイ及び配信システムに関する。詳しくは、この開示は、ソースデバイスから１つ以上のシンクデバイスへの高精細度ビデオ信号のシリアル送信に関する。
【０００２】
関連出願への相互参照
以下に示す同時係属中の米国特許出願は、本出願の譲受人と同じ譲受人に譲受されており、その開示は、引用によって本願に援用される。
【０００３】
（Ａ）２００８年１月１５日に出願された、Ｊｅｃｈａｎ Ｋｉｍによる米国特許出願番号第１２／０１４，３４１号、元の発明の名称「System Having Capability for Daisy-Chained Serial Distribution of Video Display Data」
【背景技術】
【０００４】
近年、ビデオディスプレイ技術が向上し、ホームユーザが、高精細度ディスプレイモニタを、ホームコンピュータ又はホームシアターエンターテインメントセンタ（home theatre entertainment center）に接続できるようになるまでになった。より新しいディスプレイ技術（例えば、高精細度ディスプレイ）が利用可能になるに従って、ユーザが、自らのディスプレイモニタを、低解像度のモニタから高解像のモニタにアップグレードさせることができる幾つかの再構成可能な相互接続方式が提案されている。
【０００５】
例えば、ビデオエレクトロニクススタンダーズアソシエーション（Video Electronics Standards Association：ＶＥＳＡ）は、２００７年４月に、ＤｉｓｐｌａｙＰｏｒｔとして知られるシリアル送信ベースのインタフェースのバージョン１．１（ＶＥＳＡ−ＤＰ１．１規格）を承認した。初期のプロトコル及びＶＥＳＡ−ＤＰバージョン１．１のプロトコルは、何れも、ビデオソースデバイスからビデオシンクデバイスへの最大４レーンのシリアルデータ送信をサポートするケーブルと、一対の相互接続（プラグ）とを要求する。更に、双方向制御データのシリアル送信をサポートする第５のチャネルである所謂補助チャネルが存在する。４つのビデオデータレーンのそれぞれは、少なくとも１５メートルのケーブル長に亘って、少なくとも１．６２ギガビット毎秒の帯域幅をサポートする必要があり、又はオプションとして、より高い解像度のために、１レーンあたり２．７Ｇビット／秒にアップグレードされ、この場合、長さが３メートルのより短いケーブルをサポートすればよい。
【０００６】
ビデオ信号が単一のレーンのみを介して送信される場合、この送信は、１画素あたり２４ビット及び１秒あたり５０又は６０フレームで、１走査線あたり１０８０画素（８００水平ライン）の中解像度ビデオシンクデバイスを十分にサポートできればよい。シンクデバイスのビデオ解像度が垂直方向及び水平方向に倍にされ、１水平ラインあたりの画素が２５６０画素になり、１フレームあたり１６００水平ラインになると、ビデオデータをデジタル的に転送するために、ＶＥＳＡ−ＤＰ相互接続の４つの送信レーンの全てが使用される。５番目の補助チャネルは、最初の４つのチャネルのインタレース又は他の混合を調整するための制御データを搬送する。時間分配に基づいて６．１４４メガビット毎秒で送信される最大８チャネルの圧縮されていないオーディオ信号のための帯域幅を更に設ける。一実施の形態においては、各レーンのために差動駆動信号が使用される。２０ピンの外部コネクタが設けられており、そのうち１０ピンは、４つのレーン及び補助チャネルの差分駆動信号対のサポート専用である。残りのピンは、グラウンドシールド、ホットプラグ検出、コネクタ供給電力及びコネクタ電力戻り（connector power return）を提供する。
【０００７】
ビデオデータのシリアル送信をサポートするプロトコルは、ＶＥＳＡ／ＤＰ１．１プロトコルだけではない。業界で用いられている他のプロトコルには、ユニファイドディスプレイインタフェース（Unified Display Interface：ＵＤＩ）、デジタルビデオインタフェース（Digital Video Interface：ＤＶＩ）及び高精細度メディアインタフェース（High Definition Media Interface：ＨＤＭＩ）が含まれる。ＶＥＳＡ／ＤＰプロトコルを含むこれらの多くのプロトコルは、様々な暗号化方式を使用して、コンテンツコピー保護（copy protection：ＣＰ）をサポートしている。ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔコンテンツ保護（Display Port Content Protection：ＤＰＣＰ）方式は、１２８ビットＡＥＳ暗号化技術を使用している。ＨＤＭＩプロトコルは、ＨＤＣＰとして知られる僅かに異なる保護技術を使用している。
【０００８】
近年、業界内の多くの大企業が、コンピュータ又はホームシアターエンターテインメントセンタから、高精細度ディスプレイモニタ又はより低性能のモニタに、高精細度ビデオ又は低解像度ビデオを送信するメインのプロトコルとしてＶＥＳＡ／ＤＰプロトコルをサポートし始めた。本明細書では、ＶＥＳＡ／ＤＰプロトコルを中心に説明を行う。但し、この説明は、この１つのプロトコルのみに限定されるわけではなく、この教示は、他のマルチレーンシリアルビデオ配信システムにも適用できることは明らかである。
【０００９】
新たなビデオコネクタプロトコル（例えば、ＶＥＳＡ−ＤＰ）の導入とは別の、この業界における最近の傾向は、ある用途における複数のビデオモニタの使用である。例えば、コンピュータのパワーユーザは、それらのソフトウェアプログラムのために、大きなアプリケーションデスクトップ表示空間を要求することがある。ラップトップコンピュータを含む様々なコンピュータは、通常、内部のビデオ接続又はプライマリビデオジャックによってサポートされるメインモニタに加えて、外部又は補助モニタをサポートする少なくとも１つの外部ビデオジャックを備える。メインモニタと同時に、他の又は補助モニタを同時に使用するために、ソフトウェアを利用でき、これにより、補助モニタの表示空間は、メインモニタが提供する限定的な表示空間を補うことができる。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
但し、幾つかの特別な用途では、２つのモニタだけでは不十分であることもある。所謂パワーユーザは、それらの専用ソフトウェアによって駆動される通常の２台以外に、より多くのディスプレイモニタを望むことがある。ラップトップ（又はデスクトップ）コンピュータのマザーボード上で使用できるコネクタ空間には限りがあり、及び更なるビデオコネクタ及びこれをサポートする回路の追加は、比較的高価になるので、ディスプレイ領域を更に広げる要求を満たすことは、特にラップトップコンピュータの場合、実現が難しい。全てのユーザが、更なるビデオジャック及びハードウェアを使用するパワーユーザというわけではない。一般のユーザにとっては、ビデオジャック及び関連するハードウェアの追加は、無益なコストである。したがって、（パワーユーザのみからなる集合ではなく）不特定多数のユーザに製品を供給する製造業者は、経済的観点から、製品に不要なコストを追加しないように、１つの補助モニタジャックのみの提供を継続することを強く望んでいる。
【課題を解決するための手段】
【００１１】
本発明の開示に基づき、複数のディスプレイモニタのそれぞれに異なる画像の表示を可能にすることに関する上述した問題を改善する構造及び方法が提供される。
【００１２】
詳しくは、本発明の１つの側面では、２つのＶＥＳＡ−ＤＰコネクタを有するデジタルディスプレイモニタを提供し、その一方は、プラグ式に複数のシリアルビデオレーン信号を受信し、他方は、第１のモニタにデイジーチェイン方式でプラグ式に取りはずし可能に接続された更なるモニタに、受信したビデオ信号の全てを転送（中継）する。
【００１３】
詳しくは、一実施の形態では、従来のＶＥＳＡ−ＤＰシンク回路として第１のモードで動作する動的にプログラミング可能な中継回路として、ＶＥＳＡ−ＤＰ互換送受信回路（例えば、モノリシック集積回路チップ）を提供する。但し、これは、プログラムによって選択可能な第２のモードで、シリアルデータルータとしても動作し、（マルチデバイス／データ識別又はＭＤＩＤ値が一致した場合）パススルーされるデータの一部に選択的に応答してこれをローカルで表示し、また、パススルーされるデータを、チェイン内の次のＶＥＳＡ−ＤＰ互換送受信回路に中継し、次の位置における表示及び／又はデイジーチェインに沿った更に他のディスプレイモニタへのビデオ信号の更なる中継を可能にする。一実施の形態においては、このように中継される信号は、デイジーチェインに沿ってダウンストリームに中継される際、４個のシリアルレーンに亘ってパックされ、これにより、ＶＥＳＡ−ＤＰケーブルの完全な帯域幅が常に使用される。
【００１４】
上述した第２のモードが採用される場合、時間領域多重化を用いて、異なるディスプレイモニタに向けられた信号バーストを時間的にインタレースしてもよく、ターゲットのモニタは、ビデオ信号バーストに埋め込まれているＭＤＩＤ識別信号によって特定される。次々に連続的にデイジーチェイン接続された複数のモニタのそれぞれには、個別の一意的なＭＤＩＤ識別値を割り当てることができる。これに代えて又はこれに加えて、デイジーチェイン接続された２つ以上のモニタに同じＭＤＩＤ識別値を割り当ててもよく、この場合、これらは何れも、デイジーチェインに沿ってダウンストリームに中継され、そのＭＤＩＤ識別値がバーストに埋め込まれている同じビデオデータバーストに応答する。
【００１５】
上述のここに援用される米国特許出願番号第１２／０１４，３４１号は、上で定義した第２のモードにおいて用いられる時間的多重化スキームの代わりに、空間的多重化を用いる代替的な方法を開示している。第１の従来のモード、第２のワイドパイプ及び時間多重化スキームモード、並びに米国特許出願第１２／０１４，３４１号のナローパイプ及び空間多重化スキームが採用される第３のプログラムにより選択可能なモードに基づく動作にプログラミング可能に構成できるシンクデバイス及び／又はソースデバイスを提供することも本発明の範囲に含まれる。したがって、ここでは、３つのモードのどれでも選択できる拡張ＤＰＣＤアドレス指定スキームを開示している。
【００１６】
本発明の他の側面は、以下の詳細な説明から明らかになる。
【００１７】
以下の詳細な説明では、以下のような添付の図面を参照する。
【図面の簡単な説明】
【００１８】
【図１Ａ】ユーザが、メインディスプレイユニットに加えて補助ディスプレイユニットを使用することを望む例示的な環境のブロック図である。
【図１Ｂ】ＶＥＳＡ−ＤＰシリアル送信スキームを用いて、図１の補助ディスプレイユニットにビデオ信号を供給する環境を示す概略図である。
【図２】マルチレーンシリアル入力ポートと、デイジーチェイン接続対応マルチレーンシリアル出力及び信号中継ポートと、ローカルディスプレイ出力ポートとを有するＶＥＳＡ−ＤＰ互換送受信チップを含む本発明に基づくＶＥＳＡ−ＤＰ互換ディスプレイユニットを示すブロック図である。
【図３】ＶＥＳＡ−ＤＰ互換ソースチップと、複数のデイジーチェイン対応ＶＥＳＡ−ＤＰ互換送受信チップとの組合せを示す概略図である。
【図４】図３のシステム内でＭＤＩＤアドレス指定されたモニタによって、画像データがどのように取り出されるかを説明する信号フロー図である。
【図５Ａ】図３に示すシステム内の１つ以上の特定されたディスプレイユニットに応じて、ビデオ信号の４つのレーンをどのようにパックし、デイジーチェイン方式で中継するかを説明するシグナリングタイミングチャートである。
【図５Ｂ】本発明に基づいて、二次データのパックをどのように行うかを説明する第２のシグナリングタイミングチャートである。
【発明を実施するための形態】
【００１９】
図１Ａは、例示的なマルチディスプレイコンピュータシステム１００のブロック図であり、ここでは、ユーザ１０５は、何れもデスクトップコンピュータ１２０に接続されているメインディスプレイユニット１１０及び補助ディスプレイユニット１５０を使用する。
【００２０】
本例を具体的にするために、第１の例では、ユーザ１０５は、証券アナリストであり、コンピュータ１２０内でスプレッドシートプログラムを実行していると仮定する。メインディスプレイユニット１１０は、有限のサイズの第１のディスプレイ領域１１１を有し、この中には、詳細なスプレッドシート１２１の１つ以上のタブが表示されている。ユーザ１０５がスプレッドシート１２１の特定のセクションを研究するにあたり、スプレッドシート１２１の１つの特定のサブセクションに属する結果を円グラフ（又は他のフォーカスされた）表現１２３として、新たなウィンドウに独立して表示することを望んだとする。残念ながら、メインモニタの有限のディスプレイ領域１１１は、ユーザ１０５が見たがっている拡大されたフォーカスされたビュー１２３と、表示が消えることをユーザが望まない既に表示されているスプレッドシート１２１との両方を収めるには不十分である。適切なスクリーン上のアイコン１２２上でマウス（１４０）をクリックすることによって、ユーザ１０５は、補助ディスプレイユニット１５０のディスプレイ領域１５１内に拡大された円グラフビュー１２３を表示することをコンピュータ１２０に命令する。これにより、ユーザ１０５は、スプレッドシート１２１と、拡大された円グラフビュー１２３とを同時に見ることができる。
【００２１】
ユーザのコマンドに応じて、コンピュータ１２０は、補助イメージ１２３のための所望のグラフィックデータを生成し、このイメージデータを、補助ビデオポートを介して、ポートのケーブル１５６を経由して、補助ディスプレイユニット１５０に送信する。補助ディスプレイユニット１５０は、そのディスプレイ領域１５１に拡大された円グラフビュー１２３を表示することによって受信したビデオデータ（１５６）に応答する。この結果、ユーザ１０５は、スプレッドシート１２１の詳細をメインディスプレイユニット１１０上に表示したまま研究を続けながら、同時に、補助ディスプレイユニット１５０上に表示したグラフィック補助結果１２３を研究することができる。
【００２２】
ここで、ユーザ１０５が、大きいスプレッドシート１２１をメインディスプレイユニット１１０上に表示したまま、更に他の補助モニタに、１２３と同様の更なる拡大ビューを表示することを望んだ場合に問題が生じる。第１に、従来のコンピュータ１２０上のビデオ出力ポートの数は、通常、２個に限定されている。コンピュータ１２０がデスクトップユニットである場合、メインビデオケーブル１２６のジャックが挿入されるメインビデオポートプラグと、補助ビデオケーブル１５６のジャックが挿入される１つの補助ビデオポートプラグのみしかない。プラグアンドプレイ検出回路は、補助モニタ１５０のオプションの接続を検出し、（例えば、補助モニタ上に表示すべきグラフィクスのためのＤＲＡＭ記憶域を確保することによって）補助モニタ１５０とインタラクトするようにコンピュータ内部のソフトウェアを自動的に構成する。
【００２３】
他のケース（図示せず）では、ユーザのコンピュータ１２０及びキーボード１３０、並びにメインディスプレイユニット１１０は、ラップトップコンピュータとして一体化されている。このような場合、メインビデオポート１２６は、通常、ラップトップ内で内部的に設けられており、ユーザは、これにアクセスできず、一方、補助ディスプレイユニット１５０をオプションで接続するための補助ビデオコネクタ１５６が１つだけ設けられる。したがって、このようなラップトップコンピュータ又は更に小さいコンピュータで使用できるコネクタ空間が限定的であるため、更なるディスプレイモニタをサポートするために更なるパラレルビデオポートを追加することは、実用的ではない。更に、追加的なビデオ出力ポート１２６、１５６のそれぞれをサポートするための回路は、比較的高価である。したがって、ユーザ１０５が必ず使用するわけではない場合、更なるビデオ出力ポートを追加することは、通常、非実用的である。（１０５ではない）一部のコンピュータユーザは、補助ディスプレイユニット１５０を殆ど又は全く使用しない。したがって、このような、高度な機能を必要としないユーザにとっては、使用されることなく、単に空間を無駄に消費し、不要なコストをシステムに追加する複数のビデオ出力ポートを設けることは、経済的に非実用的である。
【００２４】
更に他のケース（図示せず）では、コンピュータユーザ１０５は、多数の会議参加者（例えば、２０人）と共に会議用テーブルの前に座り、会議参加者は、自らのモニタ又は自らのラップトップコンピュータを有し、図示されたコンピュータユーザ１０５は、そのユーザのモニタ１１０、１５０に表示されている画像１１１、１５１の１つを、テーブルを囲んで座る全ての会議参加者（例えば、２０人、図示せず）の個々のモニタ又はラップトップコンピュータに同時に表示させることを望む。これまでは、このようなことを経済的に容易に実現する手法がなく、これに代えて、ユーザ１０５は、大規模光学プロジェクタを用いて、会議参加者の全てに同時に見せたい画像を大きな共通のスクリーン（例えば、反射式投射器スクリーン）に投射していた。但し、グループで使用するためのこのような大規模光学プロジェクタが容易に利用できないことがあり、この場合、グループは、プレゼンテーションを行うユーザ１０５が、多数の会議参加者（例えば、テーブルの周りに座る２０人、図示せず）と共有することを望む画像（例えば、１１１、１５１）を共有して容易に見る利益を享受することなく、会議を進めなくてはならない。
【００２５】
図１Ｂに示すシステム１８０は、ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔインタフェースを採用している。コンピュータ１２０’は、ＶＥＳＡプロトコルに基づき、ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔ標準インタフェースプラグ１２７に接続するＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔソース回路又はソースチップ１２５を含む。ＶＥＳＡ−ＶＥＳＡのコネクタケーブル（明示的には示していない）は、第１のＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔインタフェースプラグ１２７から同様の第２のＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔインタフェースプラグ１５７に接続し、そして、後者のインタフェースプラグ１５７は、補助ディスプレイユニット１５０’内に設けられているＶＥＳＡ−ＤＰデータシンクチップ又は回路１５５に接続する（１５６’）。
【００２６】
ＶＥＳＡ ＤＰプロトコル１．１に基づき、ソース側ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔ外部インタフェースプラグ１２７には、以下のピンアウトが要求されている。
【表１】
【００２７】
なお、上の表１は、ソース側コネクタ（１２７）のピンアウトを示している。シンク側コネクタ（１５７）のピンアウトは、レーン０〜３の順序が逆になり、すなわち、レーン３がピン１、３に対応し、レーン０がピン１０、１２に対応する。
【００２８】
図２は、本発明の開示に基づくビデオ信号生成及びディスプレイシステム２００のブロック図である。図２の要素には、「２００」番台の参照シンボル及び参照符号を用い、これらは、図１Ｂに示す「１００」番台の同様の参照シンボル及び参照符号によって表されている要素に対応するが、必ずしも同じである必要はない。そこで、図２に示す全ての要素の導入的な説明は省略し、違いについてのみ説明する。
【００２９】
１つのビデオシンクコネクタ１５７のみが設けられている図１Ｂの補助モニタ１５０とは異なり図２の補助モニタ２５０には、ビデオシンク及び受信コネクタ２５７と、ビデオ出力及び中継コネクタ２５９との２つのＶＥＳＡ−ＤＰ互換コネクタが設けられている。また、補助モニタ２５０内では（拡大鏡シンボル２５４によって示すように）、モニタ２５０のＶＥＳＡ−ＤＰ互換コネクタ２５７、２５９の間に、第１のＶＥＳＡ−ＤＰ互換送受信回路（又はモノリシック集積回路）２５５が挿入されている。ＶＤＰ互換送受信回路／チップ２５５は、（例えば、図１Ｂの１５５と同様の）従来のＶＥＳＡ−ＤＰシンク回路として第１のモードで動作するように、動的にプログラミング可能である。更に、ＶＤＰ互換送受信回路／チップ２５５は、これに代えて、送受信回路／チップ２５５が受信したビデオデータストリームを（ビデオ出力及び中継コネクタ２５９を介して）第２の補助モニタ２６０に中継する中継器として第２のモードで動作するように動的にプログラミングすることもできる。なお、完全には示していないが、第１の送受信回路／チップ２５５は、ポート２５５ａ、２５５ｂ、２５５ｃを有する３ポートデータルータとして動作する。これは、その第１のポート２５５ａを介して、入力ビデオデータのマルチレーンＶＤＰ互換ストリームを受信し、ここに宛てられた入力ビデオデータを選択的にデシリアライズし、受信したビデオ及びデシリアライズされたビデオデータを、その第２のポート２５５ｂに（例えば、コンポジットＲＧＢビデオ信号として）出力し、関連するモニタ２５０に表示させ、また、（ポート２５５ａからの）受信ビデオデータを中継し、その第３のポート２５５ｃ介して、チェイン内の次のＶＤＰ互換送受信回路／チップ２６５の対応する第１のＶＤＰ互換受信ポート２６５ａに出力し、チェイン内の次のＶＤＰ互換送受信回路／チップ２６５は、２５５と同様に構成されているが、チェイン内の次の送受信回路／チップ２６５は、チェイン内の次の送受信回路／チップ２６５を宛先として特定するビデオデータに応じるように別様にプログラミングされていてもよい。なお、チェイン内の次の送受信回路／チップ２６５は、接続２６８を介して、チェイン内の次の送受信回路／チップ（図示せず）に更に接続してもよく、以下同様に接続を繰り返してもよい。
【００３０】
なお、図２では、各３ポートＶＤＰ互換送受信回路／チップ２５５、２６５（その配置は、拡大鏡シンボル２６４によって示している。）等が各ディスプレイユニット２５０、２６０の内部に搭載されている構成を示しているが、この構成は、本発明の必要条件ではない。これに代えて、各３ポートＶＤＰ互換送受信回路／チップ２５５、２６５等は、他の場所、例えば、３コネクタジャンクションボックス（図示せず）の内部に搭載してもよく、ここで、少なくとも３つのコネクタのうち２つは、それぞれＶＥＳＡ−ＤＰ互換ビデオシンク及び受信コネクタ（２５７と同様）、並びにＶＥＳＡ−ＤＰ互換ビデオ出力及び中継コネクタ（２５９と同様）である。ジャンクションボックス（図示せず）の第３のコネクタは、関連するローカルモニタ（２５０）に互換性があるコネクタであってもよく、これは、ＶＥＳＡ−ＤＰ互換ビデオ出力コネクタであってもよく、ＶＥＳＡ−ＤＰ互換ビデオ出力コネクタではなくてもよい。例えば、ジャンクションボックス（図示せず）の第３のコネクタは、ＲＧＢビデオコンポジット出力コネクタであってもよい。
【００３１】
更に、図２に関して、例示的に示したバス及び／又はケーブル２２６、２５６、２５８、２６６、２６８は、正確にここに示す通りではなくてもよい。図を簡略化しなければ、５つの全てのＶＥＳＡ−ＤＰコネクタを詳細に示す必要があるが、ここでは、これを回避し、図式的表現は、できるだけ簡潔に描かれている。なお、コンピュータ２２０には、少なくとも１つのＶＥＳＡ−ＤＰソースコネクタ２２７があり、第１のモニタユニット２５０には、少なくとも１つのＶＥＳＡ−ＤＰシンク及び中継コネクタ２５７、並びに少なくとも１つのＶＥＳＡ−ＤＰソース及び中継コネクタ２５９があり、第２のモニタユニット２６０には、少なくとも１つのＶＥＳＡ−ＤＰシンク及び中継コネクタ２６７、並びに少なくとも１つのＶＥＳＡ−ＤＰソース及び中継コネクタ（２６８として表されている）がある。したがって、コネクタ２２７、２５７の間には、１つのＶＥＳＡ−ＤＰ互換ケーブル２２６−２５６が接続されている。コネクタ２５９、２６７の間には、第２のＶＥＳＡ−ＤＰ互換ケーブル２５８−２６６が接続されている。オプションとして、第２のモニタ２６０からデイジーチェイン内の次の信号受信及び／又は中継デバイスに第３のＶＥＳＡ−ＤＰ互換ケーブル２６８を接続してもよい。２５９、２６８等の各ソース及び中継コネクタは、ホットプラグ検出（hot-plug detection：ＨＰＤ）をサポートし、これにより、デイジーチェインは、ユーザの意向に応じて、オンザフライ方式で拡張又は短縮することができる。一実施の形態においては、このような数珠つなぎのデイジーチェイン方式で最大２５４個のモニタが接続される。（より一般化して言えば、比較的多数、例えば、５つ以上のモニタを同時にサポートできる。ＭＤＩＤフィールドの長さが８ビットである場合、最大値は、２５６であるが、このアドレス空間の一部、例えば、２つ以上のアドレスは、特定の用途で使用するための予備にすることができる。）
図３は、本発明に基づくシステム３００のより詳細な構成を示している。システム３００は、ＶＥＳＡ−ＤＰ互換ビデオ出力回路／チップ３２５（ソースデバイス）及び２つのＶＥＳＡ−ＤＰ互換ビデオ送受信回路／チップ３５５、３６５（シンクデバイス）を含み、これらは、ここに示すように、デイジーチェイン方式で接続されている。各ＶＤＰ互換送受信回路／チップ（３５５又は３６５）は、４個のシリアルビデオデータ受信ユニット（３５１ａ〜３５４ａ又は３５１ｂ〜３５４ｂ）を内部に有し、及び１つの補助制御データ送受信ユニット（３５５ａ又は３５５ｂ）を内部に有する。４個のシリアルビデオデータ受信ユニット３５１ａ〜３５４ａ（又は３５１ｂ〜３５４ｂ）は、それぞれ、シリアルリンク３４１〜３４４（３９１〜３９４）の１つを介して、シリアライズされたレーンデータを受信し、受信したレーンデータを内部データ処理ユニット（３６９ａ又は３６９ｂ）に供給し、及び受信したレーンデータを対応するフィードフォワード型バッファ／アンプ（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）に中継する。なお、明示的には示していないが、バッファ／アンプ（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、内部データ処理ユニット（３６９ａ又は３６９ｂ）のためにある程度の量のデータ遅延バッファリングを提供でき、これにより、内部データ処理ユニットは、後述するＭＤＩＤ挿入フラグ及びＭＤＩＤ信号（図５Ａ、５１５、５２０参照）を含むある制御信号に応答することができる。
【００３２】
各内部データ処理ユニット（例えば、３６９ａ、３６９ｂ）は、特に、４つのシリアルデータリンク（３４１〜３４４又は３９１〜３９４）のそれぞれを介して受信したシリアライズされたビデオデータを自動的にデシリアライズして、パックされているビデオデータをアンパックし、デシリアライズされ、アンパックされたビデオデータを、ローカルの相互接続バス３７０Ａ（又は３７０Ｂ）を介して、ローカルディスプレイモニタで使用可能なフォーマットで、関連するローカルディスプレイモニタ２５０’又は２６０’に供給するようにプログラミング可能である。このように関連するローカルディスプレイモニタにビデオデータをルーティングする際、内部プロセッサ（例えば、３６９ａ、３６９ｂ）は、複数のレーン（予め整列されているレーン）からのデータを結合及び／又は混合することによってデータをアンパックし、出力用のコンポジットビデオ信号を生成し、垂直バス３７０Ａ（又は３７０Ｂ）に沿ってローカル出力ポート（図２の２５５ｂ又は２６５ｂ）に、及びここからローカルディスプレイモニタに出力するようにしてもよい。図４に示す一実施の形態においては、シリアルデータリンクレーン０〜４は、隣接するビデオ画素又は副画素（subpixel）を搬送し、内部プロセッサ（例えば、３６９ａ又は３６９ｂ）は、レーンに亘って分散されている画素／副画素をアンパックして、ローカルディスプレイモニタ（例えば、２５０’又は２６０’）による表示のためにフォーマットされたコンポジットビデオストリームを生成する。
【００３３】
この通過するレーンデータをローカルディスプレイモニタ（例えば、２５０’又は２６０’）によるオプションのディスプレイのために選択的に取り出すことと同時に、フィードフォワード型バッファ／増幅器（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、物理インタフェース送信機３８１ａ〜３８４ａを介して、次の一組の４つのシリアルデータリンク（例えば、３９１〜３９４）に沿って、チェイン内の次のシリアルビデオデータ受信ユニット（例えば、３６５）による受信のために、同じ４つのレーンのデータを出力する。なお、フィードフォワード型バッファ／増幅器（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、後に詳細に説明するように、クロックデスキュー（clock deskewing）及びレーン整列機能を提供する可変遅延モジュールを含んでいてもよい。なお、フィードフォワード型バッファ／増幅器（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、内部データプロセッサのための信号遅延サポートを提供でき（図５Ａの時間遅延ＴＩ及びＴ２参照）、これにより、内部データプロセッサは、一致するＭＤＩＤ値を検出し、関連するビデオバーストデータ（例えば、図５Ａの５３０）及び／又は関連するオーディオのバーストデータ（例えば、図５Ａの５２２）及び／又は関連する二次データバースト（例えば、図５Ｂの５８０）のコピーを取り出す時間を有する。
【００３４】
送受信回路／チップ３５５、３６５の補助制御データ送受信ユニット（３５５ａ又は３５５ｂ）のそれぞれは、チップ内のそれぞれのシンク側ポリシメーカ（policy-maker）ユニット（３６５ａ又は３６５ｂ）に接続し、これは、チップのローカル垂直バス（３７０Ａ又は３７０Ｂ）を介して、内部データプロセッサ（３６９ａ又は３６９ｂ）に動作的に接続している。
【００３５】
ＶＤＰ互換送受信チップ（３５５、３６５）のそれぞれは、ＤｉｓｐｌａｙＰｏｒｔ構成データ（Display Port Configuration Data：ＤＰＣＤ）レジスタ及びＥＤＩＤ（拡張ディスプレイ識別データ：Display Identification Data）レジスタのローカルセットを含む。詳しくは、ローカルモニタ、例えばモニタ２５０’のローカルＤｉｓｐｌａｙＰｏｒｔ構成データは、対応するＶＥＳＡ−ＤＰ互換ビデオ送受信回路チップ（例えば、３５５）のポリシメーカ３６５ａ内のローカルの（シンク側）ＤＰＣＤレジスタ３６５ｃ、及びローカルＥＤＩＤレジスタ３６５ｄに保存される。このローカルプログラミングは、ローカルモニタ（例えば、２５０’）の製造業者の責任の下で行われる。ＶＥＳＡ−ＤＰ技術における当業者に理解されるように、ＶＥＳＡ準拠ＥＤＩＤデータは、ローカルモニタの物理的属性、例えば、製造元及びモデル、及び再構成可能な特徴（例えば、現在の画面解像度）の許容範囲及びそれぞれのデフォルト値を示す。ＶＥＳＡ準拠ＤＰＣＤデータは、モニタの現在の再構成可能な構成を示す。同様に、第２のＶＥＳＡ−ＤＰ互換ビデオ送受信回路／チップ３６５のポリシメーカ３６５ｂは、ローカルモニタ２６０’に対応する情報によってプログラミングされた、ローカルでプログラミングされた自らのローカルＤＰＣＤレジスタ３６５ｅ及びローカルＥＤＩＤレジスタ３６５ｆの組を含む。
【００３６】
システムリブート又はリセットの間、又はモニタのホットプラグが検出されると、ローカルＤＰＣＤデータ（例えば、３６５ｃ、３６５ｅ）及びＥＤＩＤデータ（例えば、３６５ｄ、３６５ｆ）は、ローカルポリシメーカ（例えば、３６５ａ、３６５ｂ）からソース回路／チップ３２５のコピー保持記憶域３０１〜３ＦＥにコピーされる。ここでは、これらのコピー保持記憶域３０１〜３ＦＥをソースＥＤＩＤレジスタ及びソースＤＰＣＤレジスタと呼ぶ。一実施の形態においては、ソースＥＤＩＤレジスタデータ及びソースＤＰＣＤレジスタデータを保存するメモリモジュール３１０は、それぞれアドレス値００ｈｅｘ〜０ＦＥｈｅｘを有する２５５組の固有のこのようなレジスタセットを格納する十分な容量を有し、ここで、値０ＦＦｈｅｘは、無効のソースＥＤＩＤ及び無効のソースＤＰＣＤレジスタ領域を示すために予約されている。最大２５５個の各ソースＥＤＩＤレジスタ領域及びソースＤＰＣＤレジスタ領域は、対応する数の仮想ビデオ生成器３３１、３３２…３３Ｅによって選択的にアクセス可能である。各仮想ビデオ生成器（例えば、３３１〜３３Ｅ）は、ソースＥＤＩＤレジスタデータ及びソースＤＰＣＤレジスタデータのそれぞれの１つにアクセスし、そこにコピーされているデータを用いて、対応するＶＥＳＡ−ＤＰ互換ビデオデータを生成することができる。コピーされたＥＤＩＤデータ及びコピーされたＤＰＣＤデータは、アポストロフィの添字で示す。例えば、仮想ユニット３０１内のＤＰＣＤ’及びＥＤＩＤ’は、チップ３５５内のローカルユニット３６５ｃ、３６５ｄからコピーされたものである。仮想ユニット３０２内のＤＰＣＤ”及びＥＤＩＤ”は、チップ３６５内のローカルユニット３６５ｅ、３６５ｆからコピーされたものであり、以下同様である。仮想ユニット３ＦＥ内のＤＰＣＤ”’及びＥＤＩＤ”’は、更に他の送受信チップ（図示せず）内のローカルレジスタユニットからコピーされたものであってもよい。図３に特別に示す通り、第１のローカルＤＰＣＤ及びＥＤＩＤレジスタセット（３６５ｃ、３６５ｄ）は、送受信回路／チップ３５５のポリシメーカ３６５ａ内に格納されている。第２のローカルＤＰＣＤ及びＥＤＩＤレジスタセット（３６５ｅ、３６５ｆ）は、送受信回路／チップ３６５のポリシメーカ３６５ｂ内に格納されており、以下同様である。一旦、ローカルＤＰＣＤ及びＥＤＩＤレジスタデータがソースチップ３２５にコピーされると、仮想ビデオ生成器３３１〜３３Ｅは、ソースチップ３２５内で内部的にデータにアクセスできるようになる。
【００３７】
仮想ビデオ生成器３３１〜３３Ｅの１つが、対応するビデオモニタへのストリーミング出力のためにビデオデータの各バースト（図５Ａの５３０参照）を生成するとき、仮想ビデオ生成器は、シリアルリンク３４１〜３４４から利用可能な送信帯域幅の全てを利用するように、シリアルリンクレーン３４１〜３４４の全てに亘って実質的に同時に出力バーストを分散（spread）させる（パックする）。一実施の形態においては、各リンクは、少なくとも約２．７ギガビット毎秒の帯域幅を提供する。他の実施の形態では、各リンクは、２．７ＧＨｚより高い、例えば、３．５ＧＨｚ、５．０ＧＨｚ又はこれ以上の帯域幅を提供する。ビデオ出力バーストの収集及びシリアルリンクレーン３４１〜３４４に亘るその配信は、４レーンデータ再パッカユニット（4-lane data repacker unit）３４０によって行われる。データ再パッカユニット３４０は、４つのレーンに亘る所与の仮想ビデオ生成器のビデオ出力バースト（例えば、図５Ａの５３０）の再パックに加えて、シリアルレーン３４１〜３４４のビットストリームバーストにＭｕｌｔｉＤｅｖｉｃｅ識別番号信号又はＭＤＩＤ信号３３９を挿入する。より詳しくは、図５Ａの行５２０は、４つのレーンのそれぞれにおいて、行５１４に位置するＭＤＩＤ挿入フラグからＴ１遅れた時刻において８ビットＭＤＩＤ信号が複製されることを示している。このＭＤＩＤ信号３３９／５２０は、データプロセッサユニット３６９ａ、３６９ｂ等によってサンプリングされ、データプロセッサユニット３６９ａ、３６９ｂ等は、関連するパススルーされるビデオ出力バースト（例えば、５３０図５Ａ）が対応するローカルモニタ（例えば、２５０’、２６０’）に表示することを目的とするものであるかを判定する。バーストがこのように対応するローカルモニタに向けられている場合、送受信回路／チップ（例えば、３５５、３６５等）内のデータプロセッサユニット（例えば、３６９ａ、３６９ｂ等）は、パススルーされるデータのコピーをキャプチャし、パススルーされるビデオ出力バーストのキャプチャされたコピー（バッファリングされたコピー）から、対応するローカルコンポジット信号を生成し、コンポジット信号を、表示又は他の適切な使用のために、関連するローカルモニタ（例えば、２５０’、２６０’等）に向けて送り出す。
【００３８】
一実施の形態においては、パススルーされるＭＤＩＤ値（例えば、図５Ａの５２０）と、ローカルＭＤＩＤ値（例えば、Ｍｙ＿ＭＤＩＤ）との照合は、例えば、以下のような比較的単純な手法でローカルシンクプロセッサ（例えば、図３の３６９ａ）においてインプリメントされる。
【００３９】
ＩＦ （ＭＤＩＤ＿Ｉｎｓｅｒｔ＿Ｆｌａｇ＿Ｂｉｔ ＝ Ｔｒｕｅ） ＡＮＤ （Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝ Ｍｙ＿ＭＤＩＤ） ＴＨＥＮ Ｃａｐｔｕｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ ＥＬＳＥ Ｉｇｎｏｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ
この簡単なインプリメンテーションでは、変数ＭＤＩＤ＿Ｉｎｓｅｒｔ＿Ｆｌａｇ＿Ｂｉｔは、図５ＡのＶＢＩＤバイト５１５又は図５ＢのＶＢＩＤバイト５６５のビット７：７に対応する。Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ変数は、図５Ａの行５２０又は図５Ｂの行５７０内のバイトに対応している。コピーされ（ローカルバッファ内にキャプチャされ）、ローカルで処理されるＰａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａは、図５Ａでは、対応する４つのレーンのそれぞれのオーディオのブロックデータ５２２及び対応する４つのレーンのそれぞれのビデオブロックデータ５３０の一方又は両方に対応しており、図５Ｂでは、二次ブロックデータ５８０対応する４つのレーンのそれぞれのビデオブロックデータ５１０’及び対応する４つのレーンのそれぞれの一方又は両方に対応している。
【００４０】
他の実施の形態では、パススルーされるＭＤＩＤ値（例えば、図５Ａの５２０）は、例えば、以下のように、所定数のローカルＭＤＩＤ値の何れとも照合することができる。
【００４１】
ＩＦ （ＭＤＩＤ＿Ｉｎｓｅｒｔ＿Ｆｌａｇ＿Ｂｉｔ ＝ Ｔｒｕｅ） ＡＮＤ （Ｃｕｒｒｅｎｔ＿Ｌｉｎｅ＿Ｃｏｕｎｔ≦Ｍｙ＿ＭＡｘ＿Ｌｉｎｅ＿Ｃｏｕｎｔ） ＡＮＤ （（Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝Ｍｙ＿ＭＤＩＤ） ＯＲ （Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝２５４） ＯＲ （Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝２５０）） ＴＨＥＮ Ｃａｐｔｕｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ ＥＬＳＥ Ｉｇｎｏｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ
ここで、Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤバイト（例えば、図５Ａの行５２０）がローカルに設定された（又はホットプラグインの後にソースデバイスによって設定された）２５４、２５０及びＭｙ＿ＭＤＩＤの値の何れかに一致した場合、キャプチャが行われ、ここで、Ｍｙ＿ＭＤＩＤは、通常、２５４及び２５０以外の値である。Ｍｙ＿ＭＡｘ−Ｌｉｎｅ＿Ｃｏｕｎｔ値は、ローカルモニタにおいて１フレームで表示できるビデオラインの最大数を定義し、Ｃｕｒｒｅｎｔ＿Ｌｉｎｅ＿Ｃｏｕｎｔ変数は、現フレームについて既に蓄積されているラインの番号のカウントを維持する。このような場合、ソースデバイスは、デイジーチェイン接続された複数のモニタに同時に共通のビデオデータ又は他のデータをマルチキャストでき、この結果、デイジーチェインで使用可能な有限の帯域幅をより効率的に利用できる。マルチキャストビデオデータは、通常、連続するビデオラインの組として提供され、表示されるピクチャ全体内のピクチャバンド（帯状領域）を形成する。一実施の形態においては、このような動作は、複数台のカメラを備えるセキュリティシステムの集中映像表示ステーション（central video displaying station）で使用される。各モニタは、その上部のバンドに現在の日付及び時刻を表示する必要がある。したがって、ソースデバイスは、包括的に共有されたＭＤｌＤ値の下で、例えば、上述の具体例の値２５４の下で、このデータをマルチキャストする。そして、各モニタは、表示画像内の次の下側のピクチャバンドにカメラの包括的な建物内の位置（例えば、「駐車場３階」）を表示する必要がある。したがって、ソースデバイスは、サブセットで共有されたＭＤＩＤ値、例えば、上述の具体例の値２５０の下でこのデータをマルチキャストする。最後に、各モニタは、表示画像の次の下側のピクチャバンド内に、特定のカメラ番号及びそのカメラからの関連するライブビデオを表示する必要がある。したがって、ソースデバイスは、一意的に割り当てられた特定のローカル識別番号、すなわちその１つのカメラに割り当てられたＭｙ＿ＭＤＩＤの下で、このデータユニキャストする。これは、単なる一例に過ぎない。他の具体例では、デイジーチェイン接続された複数のモニタに亘って、スプレッドシートの行を表示し、複数の行からなる１つバンドは、全てのモニタ又は２つ以上のモニタのサブセットに共通である。
【００４２】
図３に示すように、一実施の形態では、仮想ビデオストリーム生成器（３３１〜３３Ｆ）のそれぞれは、マルチタスクグラフィックプロセッサユニット（ＧＰＵ３３０ａ）及び関連するビデオＳＲＡＭメモリブロック（例えば、３３０ｂ）によって、時間共有されたマルチタスキングベースでインプリメントされる。ビデオＳＲＡＭメモリブロック（例えば、３３０ｂ）には、バス３２０を介して、ホストコンピュータ２２０’から生のビデオデータが供給される。対応するＧＰＵタイムスライス（例えば、３３０ａ）は、対応するソースＥＤＩＤ／ＤＰＣＤレジスタセット（例えば、３０１）を参照し、このレジスタセットは、ＭＤＩＤ信号３３９によって特定され、そして、対応するＧＰＵタイムスライスは、参照したＥＤＩＤ／ＤＰＣＤデータを用いて、データ再パッカユニット３４０の補助によって、シリアルリンク３４１〜３４４に亘るバーストとして出力するためのモニタ互換ビデオデータを生成するために、生のビデオデータをどのように変形（例えば、再パック）するかを判定する。ソースチップの保存ユニット３１０は、対応するソース側のコピーされたＤＰＣＤ及びＥＤＩＤデータ３０１〜３ＦＥを保存することに加えて、更に、対応するＧＰＵタイムスライス（例えば、３３０ａ）に予め定義されたプログラムのうちの所望の１つのプログラムを実行させるためのマシン命令を保存できる。これに代えて又はこれに加えて、ＶＤＰソース回路３２５の共有された他のメモリスペース（図示せず）及び／又はホストコンピュータ２２０’にＧＰＵ実行ソフトウェアを保存してもよい。上述のように、ホストコンピュータ２２０’は、１つ以上のアクティブモニタ（例えば、２５０’、２６０’）に表示する予定のビデオデータを生成器ユニット３３０の各ＶＲＡＭブロックエリア（例えば、３３０ｂ）にダウンロードし、そして、対応するＧＰＵタイムスライス（３３１〜３３Ｅ）は、ダウンロードされたビデオデータを受け取って、関連するＭＤＩＤ信号３３９によって特定される関連するＤＰＣＤ及びＥＤＩＤ保存領域（例えば、３０１）に提供されている現在の構成情報に基づいて、ビデオデータを更に処理し、これにより、処理済みのビデオデータは、宛先のモニタ（例えば、２５０’又は２６０’）の特定のプロトコルに互換性を有するようになる。そして、再パッカ３４０は、処理済のビデオデータのそれぞれをシリアル化し、出力リンク３４１〜３４４の全てに、４レーン幅のシリアルバーストとして送り出す。各出力バーストのスケジューリング（どのモニタに宛てていつ出力するか）は、ソースチップポリシメーカユニット３３５によって行われる。本発明の範囲として、ビデオデータバーストを出力するためのリンク３４１〜３４４の全てがアクティブでなければならないというわけではない。リンクの１つがダウンした場合、再パッカ３４０は、４レーンではなく、３レーンで処理を間に合わせるように試みてもよい。また、このような場合には、対応する帯域幅又は受信モニタの解像度を低減する必要があることもある。これに代えて、デイジーチェイン内のモニタが高解像度モニタではなく低解像度であり、したがって、最大の送信帯域幅が必要でない場合、４レーン幅のバーストモードから３レーン幅のバーストモードへの（又は３レーン幅のバーストモード以下への）低減を実行して、電力消費量を削減してもよい。
【００４３】
更に、図３の具体例は、ソースチップ３２５から、ダウンストリームの送受信回路／チップ３５５、３６５等へ、及びこれらを介して、デイジーチェイン方式で、シリアルバーストとして送り出されるビデオデータのための４個のシリアルレーンの同時の使用を示しており、ここで、出力バーストは、現在のＶＥＳＡ−ＤＰプロトコル要求に概ね適合するが（例外は、図５Ａの５１５、５２０を参照）、本発明の範囲として、システム設計者による適切な判断に基づき、同時に使用されるシリアルレーンの数を変更し、各チップ３２５、３５５及び３６５において、より多くの（例えば、６個、８個、１０個等の）ビデオストリーミングレーンを提供してもよく、より少ない数（例えば、３個のみ）のビデオストリーミングレーンを提供してもよい。例えば、ソースチップ３２５は、例示した４レーンのパッカ３４０に代えて、８レーン幅の再パッカを含むように設計してもよい。このような８レーン再パッカ（図示せず）は、ビデオデータのバースト出力のために、４つのレーンのそれぞれの２つのＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔを同時にサポートする（又は８レーンポートプロトコルをサポートする）ものであってもよい。同時に、シンク側送受信チップ３５５〜３６５は、多くの潜在的ターゲットを区別するために十分な幅を有するＭＤＩＤアドレス指定手段及びパケットアドレス指定手段があれば、４つのレーンのそれぞれの受信したバーストデータをサポートするために十分な回路のみを含むという点は、変更しなくてもよい。このような代替例では、ソースチップは、それぞれが４レーン幅の２つのデイジーチェインを駆動する。（パケットアドレス指定手段の意味は、図４に示すＡＵＸ ＣＨＡＮパケット４５０の宛先ＩＤフィールド４５２の説明によって後に明らかになる。）更に、図３では、各仮想ビデオストリーム生成器（例えば、３３１）がマルチタスクＧＰＵ３３０ａからのタイムスライスを使用できることを示しているが、各ビデオストリーム生成器（例えば、３３１、３３２等）が自らの専用のＧＰＵ及び自らの専用のＶＲＡＭブロックを有する場合も、本発明の範囲内にある。共用又は専用のビデオデータ処理リソースは、汎用ＧＰＵ（例えば、ＡＳＩＣ型ビデオプロセッサ回路）以外のものであってもよく、ビデオデータストレージリソースは、ＳＲＡＭスタイルビデオメモリ（例えば、ビデオ速度ＤＲＡＭメモリ）以外のものであってもよい。
【００４４】
システムリブート、リセット又は再構成の間、デイジーチェイン内の更にダウンストリームの第２のローカルモニタ２６０’の存在及びそのＶＤＰ送受信チップ３６５の存在が、ホットプラグ検出ライン３９６によって、第１のＶＤＰ送受信チップ３５５内のポリシメーカ３６５ａにシグナリングされる。ＶＤＰプロトコルに基づき、ＨＰＤライン３４６は、所定の期間（例えば、２ｍｓ以上）ローに切り替わり（toggle）、そして、通常、ハイに戻ることによって、３つのイベント、すなわち、ホットプラグインイベント、ホットアンプラグイベント、及びシンクデバイスによる割込み要求（interrupt request：ＩＲＱ）の何れかをシグナリングする。起動（boot-up）の間、第１のＶＤＰ送受信チップ３５５は、ＨＰＤライン３４６を切り替える（toggling）ことによって、デイジーチェイン内のその存在をシグナリングする。同様に、第２のＶＤＰ送受信チップ３６５は、ＨＰＤライン３９６を切り替えることによって、デイジーチェイン内のその存在をシグナリングする。これに応じて、第１のＶＤＰ送受信チップ３５５は、再びＨＰＤライン３４６を切り替えることによって、ＶＤＰソースチップ３２５内にあるアップストリームのソースポリシメーカ３３５に切り替えられた信号を自動的に中継する。ホットプラグという表現が含意するように、更なるＶＤＰ送受信チップ（例えば、３６５の後の第３のＶＤＰ送受信チップ）のそれぞれは、デイジーチェインのダウンストリームの端部にホットプラグ接続してもよく、又はデイジーチェインから切り離してもよく、ＶＤＰ送受信チップのチェイン内の次のアップストリームのＶＤＰ送受信チップを介して、切替信号（toggle signal）がソースデバイス３２５上のＨＰＤ入力ライン３４６に達するまで、ローカルのホットプラグ検出ライン（hot plug detection line：ＨＰＤ）のそれぞれの切替（toggling）を中継することによって、電源投入され、アクティブになったデイジーチェインのメンバとして追加された存在をシグナリングでき、又はデバイスが切り離されたことをシグナリングできる。そして、ＨＰＤ入力ライン３４６のこのような切替に応じて、ソースデバイス３２５は、ダウンストリームのＶＤＰ送受信チップのうち、アドレス指定されたものへの中継のために（図４の宛先フィールド４５２参照）、補助チャネルライン（ＡＵＸ ＣＨ）３４５を介して、状態問合せパケット（status inquiry packet）を送信する（図４の４５０参照）。新たなＶＤＰ送受信チップがホットプラグによってデイジーチェインに追加された場合、このＶＤＰ送受信チップは、応答パケット（図４の４６０参照）内でローカルＤＰＣＤ（例えば、３６５ｅ）及びローカルＥＤＩＤ（例えば、３６５ｆ）データを返すことによって状態問合せに応答し、応答パケットは、情報がソースポリシメーカ３３５に到着するまで、補助チャネルラインを介して、アップストリームへ中継される。例示しているソースチップ３２５には、デイジーチェイン接続方式で最大２５５個のＶＤＰ送受信チップを接続することができ、２５５個のＶＤＰ送受信チップ（図示せず）は、２５５個の一意的なＭＤＩＤ値の１つをそれぞれ消費する。図３に例示した具体例３００では、２つのＶＤＰ送受信チップのみがアクティブ化され、デイジーチェイン接続方式でソースチップ３２５に接続されている。第１のＶＤＰ送受信チップ３５５は、タイムスライスの第１の組のためにソースシリアルリンクレーン０〜４を消費し、一方、第２のＶＤＰ送受信チップ３６５は、交互になる第２の時間スライスの間に同じソースシリアルリンクレーン０〜４を消費する。送受信チップ３５５対３６５に割り当てられるタイムスライスの長さは、対応するローカルモニタ２５０’、２６０’の現在の解像度の要求に基づいて変化してもよい。
【００４５】
上述したＤＰＣＤデータ及びＥＤＩＤデータのコピー及び中継をサポートするために、標準のＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔ規格を補足的に変更する必要がある。
【００４６】
２．１ 補足的ＤｉｓｐｌａｙＰｏｒｔ構成データ（Display Port Configuration Data：ＤＰＣＤ）レジスタ
ＶＥＳＡ−ＤＰ１．１規格は、幾つかの制御レジスタアドレスの機能を定義し、他のものを未使用又は将来の拡張のための予備として残している。本発明では、予備のレジスタスペースアドレスのうち、本明細書及び上で引用した（及びここに援用される）２００８年１月１５日に出願されたＪｅｃｈａｎ Ｋｉｍによる米国特許出願番号第１２／０１４，３４１号の両方に説明されているビデオデータのデイジーチェイン動作をサポートするために、アドレス００３００（ｈｅｘ）−００３０３（ｈ）及び００４００（ｈｅｘ）−００４１１（ｈ）を、適応化することを提案する。なお、これらのレジスタアドレスの幾つかは、各レーンを個別に操作できる米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションのためのみに用いられ、これらのレジスタアドレスの幾つかは、４つの全てのレーン（例えば、１つのレーンがダウンしている場合、より少ない数のレーン）に亘るパックされたバーストとして、デイジーチェインでビデオデータを送信する本出願に基づくインプリメンテーションのためのみに用いられ、これらのレジスタアドレスの幾つかは、両方のインプリメンテーションで共有される。もちろん、特定のアドレスは、変更してもよい。なお、本発明が提案する予備のアドレスの割当てが業界で採用された又は他の割当に衝突する場合、ここで提案するレジスタアドレスは、衝突を回避するために、適切に変更してもよい。一実施の形態においては、オプションのデイジーチェインをサポートして、米国特許出願第１２／０１４，３４１号及び本発明の両方の特徴を実現するために、変更されたソースデバイス（３２５）のソースの特定のＤＰＣＤフィールド（３０１〜３ＦＥ）、及び送受信ユニット（３５５、３６５）のシンク側の特定のＤＰＣＤフィールド（３６５ｃ、３６５ｅ）において、以下の新たなＤＰＣＤレジスタ定義を使用する。
【００４７】
表２：追加されたＤＰＣＤソース特定フィールド
【表２】
【００４８】
表３：追加されたＤＰＣＤシンク特定フィールド
【表３】
【００４９】
更なる説明
ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴモード：ＤＰＣＤ００３０３ｈ及び００４０３ｈのビット１：０
この２ビットのユーザプログラマブルフィールド（０３０３ｈ又は０４０３ｈのレジスタ内）は、ソースデバイス又はシンクデバイスのそれぞれのデイジーチェインサポート機能がオンにされているか、オフにされているかを示し、オンの場合、米国特許出願第１２／０１４，３４１号の空間多重化スキームが用いられているか、ここに開示する時間多重、ＭＤＩＤターゲット化スキームが用いられているかを示す。ソースデバイスのこの２ビットフィールドが論理値「１０」に設定されている場合、対応するソースデバイス（例えば、３２５）は、ソースユニット（例えば、３２５）からダウンストリームに向けて、（ＭＤＩＤフィールド長が８ビットであるとすれば）最大２５５個の個別の時間的にインタレースされたＤｉｓｐｌａｙＰｏｒｔビデオデータバーストをサポートできるモードに切り替えられ、各ビデオバーストは、所定の時間スライスにおいて、例えば、４つのレーン（３４１〜３４４）の全てを占め、ビデオ及び二次データを含み、これは、一致するＭＤＩＤ識別子を有するダウンストリームシンクデバイスにおいて取り出すことができ、データは、デイジーチェイン、転送中継方式で送信される。また、ソースデバイス（例えば、３２５）は、このモードに切り替えられると、後述するセクション２．２に開示されているような拡張ＡＵＸ＿ＣＨトランザクションをサポートする。
【００５０】
シンク側デバイスにおいて、ＤＰＣＤアドレス００４０３ｈのビット１：０が論理値「１０」に設定されている場合、シンクデバイスは、後述する拡張ＡＵＸ＿ＣＨトランザクションを用いて、時間的にインタレースされたＤｉｓｐｌａｙＰｏｒｔビデオデータバーストモードのシンク回路部分をサポートするモードに切り替えられる。
【００５１】
ＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤ：ＤＰＣＤ位置００４０３ｈのビット５：４
このレジスタは、米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションで使用されるが、本発明のバーストモード時間多重スキーム（ＭＤＩＤスキーム）がアクティブの場合、全て０のままにされる。後に詳細に説明するように、デイジーチェインサポートモードがオンになっている場合、補助チャネルメッセージは、宛先指示情報を含むパケットとして送信される。例えば、図４を参照すると、ソースユニット４２５によるパケット出力の構造は、４５０に示されており、応答シンクデバイスによる応答パケット出力の構造は、４６０に示されている。米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションでは、シンク側デバイス（例えば、４５５、４６５又は４７５）内のＤＰＣＤ位置００４０３ｈのビット５：４は、０〜３の範囲のみで、所与のデイジーチェイン内のシンクデバイス識別情報を定義する。チェイン内で最大４個の一意的なシンク側デバイスが許容されている場合、ＩＤ値は、０〜３の範囲に亘る。米国特許出願第１２／０１４，３４１号に基づく実施の形態が使用されているとき、シンク側デバイスは、このシンクデバイスＩＤフィールドを用いて、ＡＵＸ＿ＣＨチャネル４４５を介して、ソースデバイス（例えば、４２５）によって発行されたトランザクション要求パケット４５０に応答するかを判定することができる。このような場合において、識別値の一致が検出されると、シンクデバイスは、応答し、ローカルＤＰＣＤレジスタの位置００４０３ｈに格納されているシンクデバイス識別値を、応答パケット４６０のＩＤフィールド４６２にコピーする。応答パケット４６０は、ＡＵＸ＿ＣＨチャネル４４５を介して、デイジーチェイン内に存在する任意の数の介在する送受信デバイス（例えば、４５５、４６５、４７５）を経由して、要求を出したソースデバイス（例えば、４２５）に中継によって戻される。
【００５２】
ＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤ：ＤＰＣＤ位置００４１０ｈのビット７：０
このレジスタは、本発明に基づくＭＤＩＤをキーにするインプリメンテーションで使用され、米国特許出願第１２／０１４，３４１号に基づく構成では、全て０のままにされる。ここで詳細に説明しているように、最大２５５個の個別の送受信回路／チップ（４５５〜４７５等）がサポートされ、それぞれには、異なる８ビットＭＤＩＤ識別値が割り当てられ、又はオプションとして、これらの１つ以上は、同じＭＤＩＤ値を共有してもよい。
【００５３】
ＤＰＣＤ位置００４０４ｈのＩＮ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ及びＯＵＴ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ：このレジスタは、米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションで使用され、本発明に基づくＭＤＩＤをキーにするスキームでは、全て０のままにされる。各シンク側デバイス（例えば、４５５、４６５又は４７５）のＤＰＣＤ位置００４０４ｈに保存されているデータは、個別の入口レーン（ingress lanes）のどれがアクティブであり、及びシンク側デバイスの個別の出口レーン（egress lanes）のどれがアクティブであるかを定義する。一実施の形態においては、入口−出口のレーンマッピング（このようなマッピングは、米国特許出願第１２／０１４，３４１号に開示されている。）は、アクティブな入口レーン及びアクティブな出口レーンの数に基づいて定義される。一例として、図４では、シンクデバイス４６５（Ｂ）は、その最初の３つの入口レーンがアクティブであり及びその最初の２つの出口レーンのみがアクティブであることを示すようにプログラミングしてもよい。この結果、レーン毎のビデオストリームは、米国特許出願第１２／０１４，３４１号のマッピングスキームに基づき、デバイス４６５（ｂ）を介して、ルーティング（再マッピング）される。
【００５４】
ＤＰＣＤ位置００４１１ｈのＩＮ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ及びＯＵＴ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ：このレジスタは、本発明に基づくＭＤＩＤをキーにする構成で使用され、米国特許出願第１２／０１４，３４１号に基づく構成では、全て０のままにされる。典型的には、利用可能なシリアルリンクの最大帯域幅においてバーストモードデータを中継するために４つの全てのレーンが使用されるように、ビット７：４は、１１１１ｈに設定され、また、ビット３：０も、１１１１ｈに設定される。但し、シリアルリンクに欠陥があってもよく、システム設計者は、オプションとして、１つのレーンを選択的にシャットダウンすることによって、消費電力を削減することを望んでもよく、これらも、本発明の範囲内に含まれる。したがって、幾つかの実施の形態では、このレジスタは、レーンの選択的な非アクティブ化を可能にする。例えば、各４個の制御ビットの０１１１ｈの設定は、レーン０、１及び２がビデオデータの受信／出力にアクティブであり、レーン３は、非アクティブである（例えば、電源がダウンされている）ことを意味してもよい。
【００５５】
２．２ 拡張ＡＵＸ＿ＣＨ要求／応答トランザクションシンタクス
更に図４を参照して説明すると、ソースデバイス（４２５）は、デイジーチェイン内で最大２５５個の異なるシンクデバイスに（本発明に基づいて、及び米国特許出願第１２／０１４，３４１号に基づいて最大２５５の異なるシンクデバイスに）異なるビデオストリームを送信することができるので、標準ＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨハンドシェイクプロトコルは、補足的な拡張モードがアクティブの場合、出力トランザクション要求４５０内に宛先指定バイト４５２を含ませる（挿入する）ように変更される。図４は、このように変更されたパケット４５０を示している。一実施の形態においては、宛先バイト４５２の８ビットの全ては、その宛先バイト４５２に対応するＭＤＩＤ値をコピーすることによってトランザクション要求パケット４５０に応答する予定のターゲットのシンクデバイスを特定するために使用される。トランザクション要求信号の残りの部分は、標準のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨハンドシェイクと同様のままである。バイト４５１は、送信同期フィールドであり、クロック復元及びトランザクション要求信号の開始のシグナリングのために用いられる。一実施の形態においては、各送受信デバイス（４５５、４６５、４７５）には、一意的な同期シンボルが割り当てられるが、レーン０（４４１）上で使用されている同期シンボル（４５１）だけが、基準クロック信号を生成するために使用され、全ての送受信デバイス（例えば、４５５、４６５、４７５等）は、これにローカルクロックを同期させる。そして、基準クロック信号は、複数のシリアルリンクレーンの共にパックされたビデオ信号の時間的な整列に使用される。
【００５６】
拡張トランザクション信号４５０のバイト４５３は、その最下位ビット３：０及びバイトの前半のターゲットアドレスビット１９：１６内に符号化されたコマンドを含む。フィールド４５４は、２バイト長であり、その前半及び後半にそれぞれのターゲットアドレスビット１５：８及び０：７を含む。レングスバイト４５６のビット７：０は、ペイロード長を特定する。ペイロードデータは、フィールド４５７に格納され、パケットの終了又は停止バイトは、４５９で示される。
【００５７】
応答シンクデバイスからの対応する応答パケット４６０においては、１つのバイト、すなわちレーン固有の同期バイト４６１の後にＳｉｎｋ＿ＩＤフィールド４６２が加えられる。一実施の形態においては、ｓｉｎｋ＿ＩＤバイト４６２の８ビットの全ては、トランザクション要求パケットに応答する応答シンクデバイスを特定するために使用され、ここで、ｓｉｎｋ＿ＩＤは、シンクデバイスに割り当てられたＭＤＩＤ値と同じである。２つ以上のシンクデバイスに同じＭＤＩＤ値が割り当てられている場合、ＭＤＩＤを共有するシンクデバイスのうち、最もアップストリーム側のシンクデバイスが、ＭＤＩＤを共有するシンクデバイスの全てを代表して応答する責任を有する。１つ以上のＤＰＣＤビットを予約し、ＭＤＩＤを共有するシンクデバイスのどれが最もアップストリーム側にあるかを示すために使用してもよい。
【００５８】
３．０ ソースデバイス要求：デイジーチェイン拡張機能をサポートするために、本発明に基づくソースデバイス（例えば、４２５）は、以下の側面をサポートするように設計する必要がある。（１）（上述のセクション２．１に定義したような）新たなＤＰＣＤソース特定フィールドに適合する。（２）本来のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨシンタクスに加えて、（上述のような）拡張ＡＵＸ＿ＣＨシンタクスをサポートする。（３）所与の仮想の又は非仮想のビデオバースト生成器（例えば、４３２）からの少なくとも４つのパックされたシリアルリンクのバースト出力をサポートする。（４）対応する最大２５５個のデイジーチェイン接続可能なシンクデバイスについて、最大２５５個のローカルのＥＤＩＤ及びＤＰＣＤレジスタセット（図３の３６５ｃ、３６５ｄ参照）を自らにコピーでき又は他の手法で応答的に管理できる。（５）後述するように、拡張ＡＵＸ＿ＣＨトランザクションを扱うためにプログラミング可能なタイマを含む。
【００５９】
４．０ シンクデバイス要求：ここに説明したデイジーチェイン特徴をサポートするために、一実施の形態において、各シンクデバイス（例えば、４５５）は、以下に列挙する側面をサポートできる必要がある。（１）手動で（例えば、ローカルモニタ上のロータリ又はパネルボタンで）及び自動的に（例えば、プレロードされたＥＤＩＤデータに応じて）確立された仕様の何れかに応じて、所定のＭＤＩＤ値に一致するシンクデバイスＩＤを設定することができる。（２）（上述のセクション２．１に定義したような）新たなＤＰＣＤシンク特定フィールドに適合する。（２）本来のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨシンタクスに加えて、（上述のような）拡張ＡＵＸ＿ＣＨシンタクスをサポートする。（３）パススルーデバイスとして機能するよう指示された場合、共にパックされたビデオデータの少なくとも４個のパラレルストリームのパススルーをサポートし、及び／又はストリームが、添付のＭＤＩＤ信号（図５Ａの５２０）によって、当該シンクに宛てられている場合、パススルーされているビデオストリームの取り出し及びローカル表示をサポートする。（４）デイジーチェイン内の次のダウンストリームのシンクデバイスとインタラクトするための拡張された及び本来のＡＵＸ＿ＣＨトランザクション生成器／プロセッサ（ポリシメーカ）を提供する。（５）ダウンストリームのシンクデバイスから、アップストリームのシンクデバイス又はアップストリームのソースデバイス（４２５）に向けて生成されたＨＰＤトグル信号を中継する。
【００６０】
５．０ トランザクションの詳細
５．１ ＡＵＸ＿ＣＨトランザクション
一旦、ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴフィールドが設定されると、ソースデバイス（例えば、４２５）は、ＤＥＳＴ＿ＩＤフィールドを含む拡張ＡＵＸ＿ＣＨシンタクスを用いて、標準の本来のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨシンタクスに代わるトランザクションを生成する。一実施の形態においては、デイジーチェインに沿って、ダウンストリーム方向に連続するＭＤＩＤ値（例えば、０、１、２、３…２５４）が連続的に割り当てられ、以下の処理が採用される。
【００６１】
ステップ１：ソースデバイス（例えば、４２５）が、そのＡＵＸ＿ＣＨライン（例えば、４４５）からＤＥＳＴ＿ＩＤ＝１を用いて、ＡＵＸ＿ＣＨ書込／読出要求トランザクションを生成及び出力し、内部の応答タイムアウトタイマを開始し、このタイムアウト値は、本来のＡＵＸ＿ＣＨ交換のためのタイマによって用いられるタイムアウト値より大きい（これは、トランザクション要求信号４６０をターゲットの送受信デバイス（例えば、４８５）に向けてダウンストリームに中継するためにより多くの時間がかかる可能性があり、及び介在する送受信デバイスを介して、応答をアップストリームに中継するためにより多くの時間がかかる可能性があるためである）。
【００６２】
ステップ２：デイジーチェインに沿った第１のシンクデバイス（例えば、Ｓｉｎｋ ＩＤ又はＭＤＩＤが０である４５５）が、このトランザクション要求パケット（４５０）を受信し、ＤＥＳＴ＿ＩＤフィールド（４５２）をチェックし、このパケットが当該シンクデバイスに宛てられているか、他のシンクデバイスに宛てられているかを判定する。ＤＥＳＴ＿ＩＤがそのＩＤとは異なる場合、当該シンクデバイス（例えば、４５５）は、新たなＡＵＸ＿ＣＨ書込／読出トランザクション要求パケットを生成及び出力することによって、要求をダウンストリームに中継し、及び内部のタイムアウトタイマを開始する。
【００６３】
ステップ３：デイジーチェインに沿った次のシンクデバイス（例えば、Ｓｉｎｋ ＩＤが１である４６５）が、アップストリーム側のシンクデバイス（４５５）によって出力されたトランザクション要求パケットを受信し、この第２のトランザクション要求パケット内のＤＥＳＴ＿ＩＤフィールド４５２が、ＩＤに一致するかを確認する。これがそのＩＤに一致すると、次のシンクデバイス（例えば、４６５）は、その対応するローカルＤＰＣＤレジスタの命令された書込又は読出を実行し、Ｓｉｎｋ＿ＩＤフィールド４６２を応答シンクデバイス（例えば、４６５）のＤＥＳＴ＿ＩＤと同じになるように設定して、ＡＵＸ ＣＨチェインに沿ってアップストリーム方向にＡＵＸ＿ＣＨ応答トランザクションパケット４６０を送り戻す。
【００６４】
ステップ４：アップストリーム方向の次のシンクデバイス（例えば、４５５）は、応答シンクデバイス（例えば、４６５）から応答トランザクションパケットを受信し、ステップ３を繰り返し、同時に、内部のタイムアウトタイマを停止する。そして、アップストリームのシンクデバイス（例えば、シンクＩＤ０を有する４５５）は、応答トランザクションをソースデバイス４２５に転送し、同様に内部のタイムアウトタイマを停止する。
【００６５】
ステップ５：ソースデバイス（４２５）は、中継された応答トランザクションパケット４６０を受信し、これに応答して、内部のタイムアウトタイマを停止する。そして、ソースデバイスは、対応する内部ＧＰＵ（例えば、４３１〜４３４）による使用及び／又はホストコンピュータ（例えば、図３の２２０’）へのアップロードのために、ソースデバイス内の適切なＤＰＣＤ／ＥＤＩＤ保存メモリ領域（例えば、４１１〜４１４）に受信データ４６７を中継する。
【００６６】
５．２ ホットプラグ検出
５．２．１ 単一のソースデバイス及び単一のシンクデバイス：この場合、ＨＤＰ検出処理は、例えば、図４のＨＤＰライン４４６上で直接的にＨＤＰライントグルが検出される本来のＶＥＳＡ−ＤＰ ＨＰＤ処理と同じである。
【００６７】
５．２．２ 単一のソースデバイス及び２つのシンクデバイス：この場合、以下のようなＨＤＰトグル中継処理が実行される。
【００６８】
ステップ０：チェイン内の２つのシンクデバイスのＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤは、パネルボタンを介して手動で、又はＥＤＩＤを介して自動的に、異なる値に設定する必要がある。ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴフィールドも「１」に設定する必要がある。
【００６９】
ステップ１：ソースデバイスのブートアップの後に、ＨＤＰライントグルのために、ホットプラグイベント（hot plug true event）が最初に検出されると、ソースデバイス（４２５）は、そうでない場合であっても、ＨＤＰトグルが、デイジーチェインにおける最もアップストリームのシンクデバイス（例えば、シンク０）から発せられたと仮定し、そして、ソースデバイス（４２５）は、本来のＡＵＸ＿ＣＨトランザクションシンタクスを用いて、シンク０の受信能力フィールド（ＤＰＣＤの０００００ｈから００００Ｂｈ）、そのシンク／リンクステータスフィールド（ＤＰＣＤの００２００ｈから００２０５ｈ）及びそのシンク特定フィールド（ＤＰＣＤの００４００ｈから００４１１ｈ）を応答的に読み出す。
【００７０】
ステップ２：ソースデバイス（４２５）が、ダウンストリームのローカルＤＰＣＤレジスタ（例えば、３６５ｃ）内で、真のＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴビット（ＤＰＣＤ００４０３のビット１：０における「１０」＝ここに開示するワイドパイプＭＤＩＤターゲット化スキームに基づくデイジーチェインに拡張されたＡＵＸ＿ＣＨシンタクスをサポートする。）を検出すると、ソースデバイスは、まず、本来のＡＵＸ＿ＣＨトランザクションプロセスを用いながら、ソース特定フィールド（ＤＰＣＤ００３０３ｈ）のビット１：０を「１０」に設定する。そして、ソースデバイス及びシンクデバイスは、何れも、ここに開示するワイドパイプＭＤＩＤターゲット化スキームのためのそれぞれの拡張ＡＵＸ＿ＣＨトランザクション機能をイネーブルにする。この後、全てのＡＵＸ＿ＣＨトランザクションは、トランザクション要求信号４５０内にＤＥＳＴ＿ＩＤフィールド４５２を含む拡張ＡＵＸ＿ＣＨトランザクションシンタクスを用いて実行される。
【００７１】
ステップ３：ソースデバイスが、Ｉ２Ｃ−ｏｖｅｒ−ｅｘｔ ＡＵＸ＿ＣＨトランザクションを用いて、新たに追加された（ホットプラグインされた）シンクデバイスのＥＤＩＤデータを読み出し、これは、トランザクション要求信号におけるＤＥＳＴ＿ＩＤフィールド４５２の使用も含む。
【００７２】
ステップ４：ソースデバイスがホットプラグ検出された新たなシンクデバイス（この時点では、４５５のみであるが、後に４６５等も含まれる。）のそれぞれについてリンクトレーニング（link training）を開始する。このリンクトレーニングは、共にパックされるレーン（通常、４つのレーン全て）の整列及びエラーレートのクリア（error rate clearing）を含む。各送受信デバイスは、レーン整列を目的として、各ビデオレーンに関連する遅延を微調整する可変信号遅延手段（明示的には示していない）を含み、これにより、各レーンのケーブルが異なる長さであっても、同じローカルモニタのビデオ情報を搬送するレーン間のタイミングスキューが最小化される。共にパックされるレーンは、１つのビデオフレームのビデオストリームデータを搬送するレーンであり、タイミングスキューを許容可能な公差内に低減しないと、タイミングスキューがビデオモニタ上の顕著な歪みを引き起こすおそれがある。
【００７３】
ステップ５：一旦、全てのアクティブレーンについてレーン整列が完了すると、ソースデバイス（４２５）は、これまでにデイジーチェイン内で発見されたホットプラグ検出されたシンクデバイスへのアクティブなメインリンクの一部を構成するものとして、整列されたレーンをアクティブ化する。標準ＶＤＰプロトコルでは、アクティブなメインリンクを定義するレーンの数は、１個、２個又は４個にすることができ、３個にすることはできない。一方、本発明では、このような規格に制限される必要はなく、所与のソースデバイスの現在のメインリンクセット内のアクティブレーンとして、適切な如何なる数のアクティブレーンを含ませても、本発明の範囲内である。
【００７４】
ステップ６：ソースと、チェイン内の最初のシンクデバイス（シンク０）との間の通常のネイティブモードのインプリメンテーションの間に、現在の、よりアップストリームのデイジーチェインデバイス（例えば、４５５）が、次のダウンストリームのデバイス（例えば、４６５）からホットプラグイベントを検出した場合、シンク０デバイスは、自らがソースデバイスであるかのように、上述したステップ１、２を繰返し、これによって、自ら（シンク０デバイス）と、次のダウンストリームのシンクデバイス（４６５）との間の拡張ＡＵＸ＿ＣＨ接続をイネーブルにする。
【００７５】
ステップ７：ステップ６の後に、シンク０デバイスは、ＨＤＰライン４４６上のソースデバイスへの更なるホットプラグイベントを生成する（ＨＤＰラインを２ｍｓ以上、０に遷移させ、再び１に戻す）。
【００７６】
ステップ８：ステップ７に応じて、ソースデバイスは、上述したステップ１を繰り返す。シンク／リンクステータスフィールドが全て正常（all okay）である場合、例えば、レーンの整列が成功したことが示された場合、ソースデバイス４２５は、ＤＥＳＴ＿ＩＤ＝１を含む拡張ＡＵＸ＿ＣＨトランザクション要求４５０を発行し、シンク１デバイスのためにステップ２を繰り返す。
【００７７】
ステップ９：シンク１（４６５）のシンク／リンクステータスフィールドが正常ではない（not okay）場合、ソースデバイス４２５は、ステップ４を繰り返し、そのメインリンク（アクティブなシリアルリンク）を新たに追加されたシンク１デバイス（４６５）に拡張するための再初期化を試みる。
【００７８】
ステップ１０：一旦、レーン整列が完了すると、ソースデバイスは、ソースデバイスとシンク１デバイスとの間でメインリンクをアクティブ化し、これらのアクティブ化されたメインリンクは、シンクデバイス０をパススルーする。（例えば、図４の黒い矢印は、４レーン幅データバーストのデバイス４５５を通過するパススルー及びこれに続くデバイス４６５におけるキャプチャを示している。図４のデバイス４７５内に示すパススルーの黒い矢印は、バーストをキャプチャするデバイス４６５が、キャプチャしたデータバーストを、ＭＤＩＤ値が一致すればダウンストリームの他のシンクデバイスでもキャプチャできるように、デイジーチェインに沿ってダウンストリームに転送もしていることを示している。）
５．２．３ 単一のソースデバイス及び２個より多いシンクデバイス：単一のソースデバイス（４２５）及びチェイン上に２個より多いシンクデバイス（例えば、図４の４５５、４６５、４７５）がある場合、以下のようなＨＤＰ中継処理が行われる。
【００７９】
ステップ０：全てのシンクデバイスのＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤは、パネルボタンを介して手動で、又はＥＤＩＤを介して自動的に設定する必要がある。また、ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴフィールドも「１０」に設定する必要がある。
【００８０】
ステップ１：ソースデバイスは、シンクデバイス間の全てのメインリンクが整列され、アクティブ化されるまで、上のセクション５．１．２のステップ１〜５を繰返し実行する。
【００８１】
ステップ２：ソースデバイス（４２５）において、ソースデバイス（４２５）に中継されるＨＤＰトグルによってホットアンプラグイベントが検出され、及びそのローカルＤＰＣＤ及びＥＤＩＤレジスタ（例えば、３６５ｅ、３６５ｆ）を読み出すことができないために、以前にチェイン内にあった１つ以上のデバイスがチェイン内にないことをソースデバイスが発見すると、ソースデバイスは、残っている全てのダウンストリームメインリンクが再整列され、アクティブ化されるまでステップ１を繰り返す。例えば、シンク１が切断（unplugged）され、再接続（re-plugged）されると、ソースとシンク１、２、３等との間の全てのメインリンクが壊れる。ソースデバイスは、全てのダウンストリームシンクデバイス間の全てのメインリンクがアクティブ化されるまで、ステップ１を繰り返す。したがって、ホットアンプラグ及び再プラグは、最もダウンストリームの端部だけではなく、デイジーチェイン内のどこで発生してもよい。
【００８２】
５．３ メインリンク
標準ＶＤＰプロトコルでは、所与のソースデバイスのアクティブ化されたメインリンクセットは、デイジーチェイン内のシンクデバイスの数に応じて、トップの１個、２個又は４個のレーンとして構成できる。なお、上述したように、本発明では、アクティブレーンの数は、好ましくは、４個に設定されるが、必ずしもこの規格に制限されるわけではなく、この結果、他の環境においては、所与のソースデバイスのアクティブ化されたメインリンクセットは、期待される最高のビデオ解像度及びデイジーチェイン内のモニタの予想される最大数（例えば、最大２５５）をサポートするのに必要な最大帯域幅に応じて、所与の用途において適切となるように、アクティブな整列されたリンクの他の数値的及び空間的な構成に構成できる。
【００８３】
図３から、一実施の形態では、各Ｐｈｙ Ｒｘユニット（例えば、３５１ａ〜３５４ａ）又は対応するデータプロセッサ３６９ａ内に設けられた信号デシリアライザに加えて、各送受信可能シンクデバイスは、ダウンストリーム側の次のシンクデバイスにメインリンクビデオ及び／又は他のバーストデータを中継するために、例えば、それぞれＰｈｙ Ｔｘユニット（例えば、３８１ａ〜３８４ａ）の一部として設けられた微調整可能な遅延器と共に、４個のシリアル信号増幅バッファ３６１ａ〜３６４ａを有することができることがわかる。送受信可能シンクデバイス（例えば、３５５、３６５）のそれぞれは、よりダウンストリーム又はよりアップストリームの送受信可能シンクデバイス、若しくは最もアップストリームのソースデバイス（３２５）にシリアルＡＵＸ ＣＨデータを双方向に中継するために更に２対の補助チャネルデシリアイザ及びシリアライザを有する。アクティブなシンクデバイスのそれぞれは、そのローカルのアクティブな数（通常４個）の入力レーンを内部のローカルバス（例えば、３７０Ａ、３７０Ｂ）に、及びここから、それぞれのローカルモニタ（例えば、２５０’、２６０’）に接続する。図４は、このような接続を行っているデバイス４６５を示している。各シンクデバイスのデータ処理ユニット（例えば、３６９ａ、３６９ｂ）は、ローカルポリシメーカ（例えば、３６５ａ、３６５ｂ）から送信されたコマンドに基づいて動作し、対応するＰｈｙ Ｒｘユニット（例えば、３５１ａ〜３５４ａ）が受信したビデオデータを、共通のルーティングバス（例えば、３７０Ａ）を介してローカルモニタに接続するか、及びその場合、どのようなデシリアライズ規則に基づいて動作するかを判定する。例えば、（以下に説明する）図５Ａのフィールド５３０の場合、連続する画素が、４つのレーンに亘って、ラウンドロビン方式で連続的に配信されていることがわかる。
【００８４】
図５Ａには、本発明に基づき、４レーン幅シリアルデータストリーム５０１にＭＤＩＤビット（フィールド５２０）を選択的に埋め込む１つのスキーム５００を示している。４つのレーンは、通常、ここに示すように同期されるが、これは必ずしも必要ではない。レーンが互いに厳密に同期されていない場合、送受信デバイスのデータプロセッサが、シリアル送信されたストリームから、ビデオ又はオーディオデータブロックの構築を開始する前に、図に示すようにストリームを同期させるために、送受信デバイスデータプロセッサ（例えば、３６９ａ、３６９等）内に適切なデータバッファリング及びシリアルストリーム再同期手段を設ける必要がある。図５Ａの行５０９に示すように、ビデオブランク期間（例えば、水平帰線消去期間又は１Ｈ）の最後に、各レーンにおいて、ＶＤＰによって定義されたキャラクタ（ブランクエンド（Blank End）キャラクタ）を送信する。これに続いて、予め定義されたＭＤＩＤ値を有するモニタの表示ライン番号Ｎ−１のビデオ画素が供給される。行番号Ｎ−１のビデオ画素の送信が完了すると、オプションとして、データブロック５１０の最後を全て０バイトでパディングし、５１２に示すように、４つのレーンに亘って、４つのＶＤＰ ＢＳキャラクタ（ブランク開始（Blank Start）キャラクタ）が出力される。
【００８５】
次に、同期された行５１４に沿って、ＶＤＰプロトコルに基づいて、対応するビデオブランキング識別バイト（ＶＢ−ＩＤ）が出力され、ここで、このようなＶＢ−ＩＤバイトのそれぞれのビット０：５は、対応するＩＤ値を提供する。なお、ビット７：７が常にゼロである従来の手法とは異なり、本発明では、ビット７：７が論理値「１」である場合（ボックス５１５参照）、これは、従来のＭａｕｄバイト５１８の後にＭＤＩＤバイトが挿入されることをシグナリングしている。ビット７：７が論理値「０」である場合、オプションのＭＤＩＤバイト５２０は、挿入されず、従来のＶＤＰプロトコルに基づき、各レーンにおいて、Ｍａｕｄバイト５１８の直後にオーディオデータブロック５２２が続く。ＶＢ−ＩＤバイト５１４内にＭＤＩＤ挿入フラグ（ビット７：７）を設けることによって、送受信デバイスのプロセッサ（例えば、３６９ａ）に、オプションのＭＤＩＤバイト５２０が出現する前にＶＢ−ＩＤバイト５１４を処理するためのＴ１の時間遅延を与えることができる。オプションのＭＤＩＤバイト５２０内の識別値がローカルモニタのディスプレイモニタＩＤ値に一致する場合、送受信デバイスのプロセッサ（例えば、３６９ａ）は、これに続くオーディオ（５２２）及びビデオ（５３０）シリアルデータを、処理及びローカルモニタ（例えば、２５０’）への転送のために、そのローカルバッファ内にコピーする。ＭＤＩＤバイト５２０がローカルモニタのディスプレイモニタＩＤ値（又はローカルモニタを含むマルチキャストグループ値）に一致しない場合、送受信デバイスのプロセッサ（例えば、３６９ａ）は、パススルーされるオーディオ（５２２）及びビデオ（５３０）シリアルデータを無視する。図５Ａの行５２９に示すように、ビデオブランク期間（例えば、水平帰線消去期間又は１Ｈ）の最後に、各レーンにおいて、ＶＤＰによって定義されたキャラクタ（ブランクエンド（Blank End）キャラクタ）を再び送信する。これに続いて、行５２０のＭＤＩＤ信号によって定義される予め定義されたＭＤＩＤ値を有するモニタ（又はモニタのマルチキャストグループ）の表示ライン番号Ｎのビデオ画素が供給される。行番号Ｎのビデオ画素の送信が完了すると、オプションとして、データブロック５３０の最後を全て０バイトでパディングし、５３２に示すように、４つのレーンに亘って、４つのＶＤＰ ＢＳキャラクタ（ブランク開始（Blank Start）キャラクタ）が出力される。そして、処理は、４つのシリアル送信レーンに亘って現れる５１４と同様の他の行について繰り返してもよい。
【００８６】
図５Ｂに示すように、二次データを対応するＭＤＩＤ値に論理的に関連付けるために、同様のスキーム５５０を用いてもよい。行５６４のＶＢ−ＩＤバイトのそれぞれのビット７：７が論理値「１」である場合、オプションとして、行５７０にＭＤＩＤバイトが挿入される。この他の場合、オプションのレーン０〜３（５５１）のシリアル送信ストリーム内にＭＤＩＤバイト行５７０は、出現しない。一致するＭＤＩＤ値を有する送受信デバイスのプロセッサ（例えば、３６９ａ）による処理のために宛てられた二次データは、行５７９の二次データ開始フラグキャラクタ（Start of Secondary data flag character：ＳＳ）の後に開始され、行５８２の二次データ終了フラグキャラクタ（End of Secondary data flag character：ＳＥ）で終了する。行５７９〜５８２は、ダミーのキャラクタが埋められたブロック５７２、５８４によって挟み込んでもよい。行５０９’の後に行５７０のＭＤＩＤに一致するモニタのためのビデオ画素データ５１０’が始まる。このように、二次データ５８０は、ビデオラインデータ５１０’にインタレースして、一致するＭＤＩＤ値を有する１つ以上のモニタに宛てることができる。
【００８７】
この説明は、例示的なものであり、特許請求する主題の範囲、性質又は思想を制限するものではない。この説明の開示によって、様々な修正及び変更は、当業者にとって明らかであり、これらには、ここに開示した要素と同等な機能的及び／又は構造的均等物の使用、ここに開示した組合せと均等な機能的組合せの使用、及び／又はここに開示したステップと均等な機能的ステップの使用が含まれる。このような実質的ではない変更は、ここで説明した発明の範囲に含まれる。更に、特定の手段又はステップについて複数の具体例を提示している場合、及びこの開示から、このような具体例の間の及び／又はこのような具体例を越える類推が自明である場合、本明細書は、少なくともこのような類推を効果的に開示し、したがって包含しているものとみなされる。
【００８８】
一例として、本発明に基づくソースデバイス（例えば、図３の３２５）及び／又は送受信デバイス（例えば、図３の３５５）の構成は、コンピュータ（例えば、図３の２２０’）又は他の外部の命令デバイスを使用して、様々なビデオストリーム生成器（例えば、３３１〜３３Ｅ）のアクティブ化又は非アクティブ化を選択的に制御すること、及び／又は各送受信デバイスのローカルデータ処理デバイス（例えば、３６９ａ、３６９ｂ）のそれぞれによる、シリアル受信ビットのマッピングを望まれるように選択的に制御することを含んでもよいことは明らかである。コンピュータが読取可能な媒体（図示せず）又は他の形式のソフトウェア製品又はマシン命令手段（以下に限定されるものではないが、ハードディスク、コンパクトディスク、フラッシュメモリスティック、製品としての命令信号のネットワークを介するダウンロード及びこれらに類するもの）を用いて、命令可能なマシン（例えば、２２０’）に命令して、このような選択的なアクティブ化及び非アクティブ化プロセスを望まれるように実行させてもよい。例えば、図３では、アップストリームのデバイスが、欠陥があるレーンがあり、したがって、そのレーンを介して次のダウンストリームデバイスにビデオデータをパススルーしない場合、欠陥があるレーンをシャットオフし、又は所与のデイジーチェイン内の送受信デバイスのそれぞれのＰｈｙ Ｔｘユニットの１つをパワーダウンすることによって消費電力を最小化することが望ましい場合があり、この結果、全体の消費電力を低減できる。すなわち、ホストコンピュータ内のソフトウェアが、ある時点で、デイジーチェインを構成するレーンの１つ以上を介して、ビデオデータが有効に送信されていないことを示した場合、ホストコンピュータは、現在サービスが必要でないビデオデータ出力回路のパワーダウンを選択的に命令することができ、これによって電力を節約することができる。このため、上述したデフォルトの４レーン幅バーストモードから変形されたマシン実装方法を命令可能なマシン（例えば、２２０’）に実行させ、及び／又は命令可能なマシンにマシン実装方法を実行させる補助的なソフトウェアを提供することは、本発明の範囲内にある。
【００８９】
付加的な特許権の留保、矛盾の解決及び用語の解釈
本明細書が法律に則って公開された後、本出願の譲受人は、他者がここに含まれる文章及び図面の素材を複製することについて、このような複製が本明細書の発明を理解し、これによって、有用な技術及び科学の発展を促進することを目的とする限りにおいて、異論を唱えない。但し、譲受人は、ここに開示した素材に法的に関連する可能性がある他の如何なる権利も放棄せず、このような権利には、以下に限定されるものではないが、あらゆるコンピュータプログラムリスティング、図表又はここに提示したこの他の記載に関する著作権、ここに提示した造語又は図表に関連する可能性がある商標又はトレードドレス権、及びここに含まれ又はここから導出可能な、この他の保護可能な主題に関する権利が含まれる。
【００９０】
何らかの開示が引用によってここに援用されており、このような援用された開示が、本開示と部分的又は全体的に矛盾する場合、矛盾する範囲、及び／又はより広い開示、及び／又はより広い用語の定義は、本明細書を基準とする。このような援用された開示が互いに部分的又は全体的に矛盾する場合、矛盾する範囲は、日付が新しい開示を基準とする。
【００９１】
ここに明示的に述べていない限り、通常の用語は、それぞれが使用されているそれぞれの文脈内で対応する通常の意味を有し、通常の技術用語は、関連する技術分野内で、及びここでそれぞれが使用されているそれぞれの文脈内で対応する通常の意味を有する。関連技術に関する上述の記述は、本明細書が最も密接に関係する技術分野の当業者が技術又は可能な技術間の関係を想到できたことを認めるものではない。
【００９２】
上述した一般概念及び特定の実施の形態の開示に基づき、要求される保護の範囲は、添付の特許請求の範囲によって定義される。発行された特許請求の範囲は、出願人の権利を、開示した特許請求の範囲のみに限定するものではなく、出願人の権利は、米国特許法第１２０条及び／又は米国特許法第２５１条に従って出願される更なる１つ以上の出願によって、ここでは文言として請求していない主題にも及ぶ。
【技術分野】
【０００１】
本発明の開示は、ビデオディスプレイ及び配信システムに関する。詳しくは、この開示は、ソースデバイスから１つ以上のシンクデバイスへの高精細度ビデオ信号のシリアル送信に関する。
【０００２】
関連出願への相互参照
以下に示す同時係属中の米国特許出願は、本出願の譲受人と同じ譲受人に譲受されており、その開示は、引用によって本願に援用される。
【０００３】
（Ａ）２００８年１月１５日に出願された、Ｊｅｃｈａｎ Ｋｉｍによる米国特許出願番号第１２／０１４，３４１号、元の発明の名称「System Having Capability for Daisy-Chained Serial Distribution of Video Display Data」
【背景技術】
【０００４】
近年、ビデオディスプレイ技術が向上し、ホームユーザが、高精細度ディスプレイモニタを、ホームコンピュータ又はホームシアターエンターテインメントセンタ（home theatre entertainment center）に接続できるようになるまでになった。より新しいディスプレイ技術（例えば、高精細度ディスプレイ）が利用可能になるに従って、ユーザが、自らのディスプレイモニタを、低解像度のモニタから高解像のモニタにアップグレードさせることができる幾つかの再構成可能な相互接続方式が提案されている。
【０００５】
例えば、ビデオエレクトロニクススタンダーズアソシエーション（Video Electronics Standards Association：ＶＥＳＡ）は、２００７年４月に、ＤｉｓｐｌａｙＰｏｒｔとして知られるシリアル送信ベースのインタフェースのバージョン１．１（ＶＥＳＡ−ＤＰ１．１規格）を承認した。初期のプロトコル及びＶＥＳＡ−ＤＰバージョン１．１のプロトコルは、何れも、ビデオソースデバイスからビデオシンクデバイスへの最大４レーンのシリアルデータ送信をサポートするケーブルと、一対の相互接続（プラグ）とを要求する。更に、双方向制御データのシリアル送信をサポートする第５のチャネルである所謂補助チャネルが存在する。４つのビデオデータレーンのそれぞれは、少なくとも１５メートルのケーブル長に亘って、少なくとも１．６２ギガビット毎秒の帯域幅をサポートする必要があり、又はオプションとして、より高い解像度のために、１レーンあたり２．７Ｇビット／秒にアップグレードされ、この場合、長さが３メートルのより短いケーブルをサポートすればよい。
【０００６】
ビデオ信号が単一のレーンのみを介して送信される場合、この送信は、１画素あたり２４ビット及び１秒あたり５０又は６０フレームで、１走査線あたり１０８０画素（８００水平ライン）の中解像度ビデオシンクデバイスを十分にサポートできればよい。シンクデバイスのビデオ解像度が垂直方向及び水平方向に倍にされ、１水平ラインあたりの画素が２５６０画素になり、１フレームあたり１６００水平ラインになると、ビデオデータをデジタル的に転送するために、ＶＥＳＡ−ＤＰ相互接続の４つの送信レーンの全てが使用される。５番目の補助チャネルは、最初の４つのチャネルのインタレース又は他の混合を調整するための制御データを搬送する。時間分配に基づいて６．１４４メガビット毎秒で送信される最大８チャネルの圧縮されていないオーディオ信号のための帯域幅を更に設ける。一実施の形態においては、各レーンのために差動駆動信号が使用される。２０ピンの外部コネクタが設けられており、そのうち１０ピンは、４つのレーン及び補助チャネルの差分駆動信号対のサポート専用である。残りのピンは、グラウンドシールド、ホットプラグ検出、コネクタ供給電力及びコネクタ電力戻り（connector power return）を提供する。
【０００７】
ビデオデータのシリアル送信をサポートするプロトコルは、ＶＥＳＡ／ＤＰ１．１プロトコルだけではない。業界で用いられている他のプロトコルには、ユニファイドディスプレイインタフェース（Unified Display Interface：ＵＤＩ）、デジタルビデオインタフェース（Digital Video Interface：ＤＶＩ）及び高精細度メディアインタフェース（High Definition Media Interface：ＨＤＭＩ）が含まれる。ＶＥＳＡ／ＤＰプロトコルを含むこれらの多くのプロトコルは、様々な暗号化方式を使用して、コンテンツコピー保護（copy protection：ＣＰ）をサポートしている。ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔコンテンツ保護（Display Port Content Protection：ＤＰＣＰ）方式は、１２８ビットＡＥＳ暗号化技術を使用している。ＨＤＭＩプロトコルは、ＨＤＣＰとして知られる僅かに異なる保護技術を使用している。
【０００８】
近年、業界内の多くの大企業が、コンピュータ又はホームシアターエンターテインメントセンタから、高精細度ディスプレイモニタ又はより低性能のモニタに、高精細度ビデオ又は低解像度ビデオを送信するメインのプロトコルとしてＶＥＳＡ／ＤＰプロトコルをサポートし始めた。本明細書では、ＶＥＳＡ／ＤＰプロトコルを中心に説明を行う。但し、この説明は、この１つのプロトコルのみに限定されるわけではなく、この教示は、他のマルチレーンシリアルビデオ配信システムにも適用できることは明らかである。
【０００９】
新たなビデオコネクタプロトコル（例えば、ＶＥＳＡ−ＤＰ）の導入とは別の、この業界における最近の傾向は、ある用途における複数のビデオモニタの使用である。例えば、コンピュータのパワーユーザは、それらのソフトウェアプログラムのために、大きなアプリケーションデスクトップ表示空間を要求することがある。ラップトップコンピュータを含む様々なコンピュータは、通常、内部のビデオ接続又はプライマリビデオジャックによってサポートされるメインモニタに加えて、外部又は補助モニタをサポートする少なくとも１つの外部ビデオジャックを備える。メインモニタと同時に、他の又は補助モニタを同時に使用するために、ソフトウェアを利用でき、これにより、補助モニタの表示空間は、メインモニタが提供する限定的な表示空間を補うことができる。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
但し、幾つかの特別な用途では、２つのモニタだけでは不十分であることもある。所謂パワーユーザは、それらの専用ソフトウェアによって駆動される通常の２台以外に、より多くのディスプレイモニタを望むことがある。ラップトップ（又はデスクトップ）コンピュータのマザーボード上で使用できるコネクタ空間には限りがあり、及び更なるビデオコネクタ及びこれをサポートする回路の追加は、比較的高価になるので、ディスプレイ領域を更に広げる要求を満たすことは、特にラップトップコンピュータの場合、実現が難しい。全てのユーザが、更なるビデオジャック及びハードウェアを使用するパワーユーザというわけではない。一般のユーザにとっては、ビデオジャック及び関連するハードウェアの追加は、無益なコストである。したがって、（パワーユーザのみからなる集合ではなく）不特定多数のユーザに製品を供給する製造業者は、経済的観点から、製品に不要なコストを追加しないように、１つの補助モニタジャックのみの提供を継続することを強く望んでいる。
【課題を解決するための手段】
【００１１】
本発明の開示に基づき、複数のディスプレイモニタのそれぞれに異なる画像の表示を可能にすることに関する上述した問題を改善する構造及び方法が提供される。
【００１２】
詳しくは、本発明の１つの側面では、２つのＶＥＳＡ−ＤＰコネクタを有するデジタルディスプレイモニタを提供し、その一方は、プラグ式に複数のシリアルビデオレーン信号を受信し、他方は、第１のモニタにデイジーチェイン方式でプラグ式に取りはずし可能に接続された更なるモニタに、受信したビデオ信号の全てを転送（中継）する。
【００１３】
詳しくは、一実施の形態では、従来のＶＥＳＡ−ＤＰシンク回路として第１のモードで動作する動的にプログラミング可能な中継回路として、ＶＥＳＡ−ＤＰ互換送受信回路（例えば、モノリシック集積回路チップ）を提供する。但し、これは、プログラムによって選択可能な第２のモードで、シリアルデータルータとしても動作し、（マルチデバイス／データ識別又はＭＤＩＤ値が一致した場合）パススルーされるデータの一部に選択的に応答してこれをローカルで表示し、また、パススルーされるデータを、チェイン内の次のＶＥＳＡ−ＤＰ互換送受信回路に中継し、次の位置における表示及び／又はデイジーチェインに沿った更に他のディスプレイモニタへのビデオ信号の更なる中継を可能にする。一実施の形態においては、このように中継される信号は、デイジーチェインに沿ってダウンストリームに中継される際、４個のシリアルレーンに亘ってパックされ、これにより、ＶＥＳＡ−ＤＰケーブルの完全な帯域幅が常に使用される。
【００１４】
上述した第２のモードが採用される場合、時間領域多重化を用いて、異なるディスプレイモニタに向けられた信号バーストを時間的にインタレースしてもよく、ターゲットのモニタは、ビデオ信号バーストに埋め込まれているＭＤＩＤ識別信号によって特定される。次々に連続的にデイジーチェイン接続された複数のモニタのそれぞれには、個別の一意的なＭＤＩＤ識別値を割り当てることができる。これに代えて又はこれに加えて、デイジーチェイン接続された２つ以上のモニタに同じＭＤＩＤ識別値を割り当ててもよく、この場合、これらは何れも、デイジーチェインに沿ってダウンストリームに中継され、そのＭＤＩＤ識別値がバーストに埋め込まれている同じビデオデータバーストに応答する。
【００１５】
上述のここに援用される米国特許出願番号第１２／０１４，３４１号は、上で定義した第２のモードにおいて用いられる時間的多重化スキームの代わりに、空間的多重化を用いる代替的な方法を開示している。第１の従来のモード、第２のワイドパイプ及び時間多重化スキームモード、並びに米国特許出願第１２／０１４，３４１号のナローパイプ及び空間多重化スキームが採用される第３のプログラムにより選択可能なモードに基づく動作にプログラミング可能に構成できるシンクデバイス及び／又はソースデバイスを提供することも本発明の範囲に含まれる。したがって、ここでは、３つのモードのどれでも選択できる拡張ＤＰＣＤアドレス指定スキームを開示している。
【００１６】
本発明の他の側面は、以下の詳細な説明から明らかになる。
【００１７】
以下の詳細な説明では、以下のような添付の図面を参照する。
【図面の簡単な説明】
【００１８】
【図１Ａ】ユーザが、メインディスプレイユニットに加えて補助ディスプレイユニットを使用することを望む例示的な環境のブロック図である。
【図１Ｂ】ＶＥＳＡ−ＤＰシリアル送信スキームを用いて、図１の補助ディスプレイユニットにビデオ信号を供給する環境を示す概略図である。
【図２】マルチレーンシリアル入力ポートと、デイジーチェイン接続対応マルチレーンシリアル出力及び信号中継ポートと、ローカルディスプレイ出力ポートとを有するＶＥＳＡ−ＤＰ互換送受信チップを含む本発明に基づくＶＥＳＡ−ＤＰ互換ディスプレイユニットを示すブロック図である。
【図３】ＶＥＳＡ−ＤＰ互換ソースチップと、複数のデイジーチェイン対応ＶＥＳＡ−ＤＰ互換送受信チップとの組合せを示す概略図である。
【図４】図３のシステム内でＭＤＩＤアドレス指定されたモニタによって、画像データがどのように取り出されるかを説明する信号フロー図である。
【図５Ａ】図３に示すシステム内の１つ以上の特定されたディスプレイユニットに応じて、ビデオ信号の４つのレーンをどのようにパックし、デイジーチェイン方式で中継するかを説明するシグナリングタイミングチャートである。
【図５Ｂ】本発明に基づいて、二次データのパックをどのように行うかを説明する第２のシグナリングタイミングチャートである。
【発明を実施するための形態】
【００１９】
図１Ａは、例示的なマルチディスプレイコンピュータシステム１００のブロック図であり、ここでは、ユーザ１０５は、何れもデスクトップコンピュータ１２０に接続されているメインディスプレイユニット１１０及び補助ディスプレイユニット１５０を使用する。
【００２０】
本例を具体的にするために、第１の例では、ユーザ１０５は、証券アナリストであり、コンピュータ１２０内でスプレッドシートプログラムを実行していると仮定する。メインディスプレイユニット１１０は、有限のサイズの第１のディスプレイ領域１１１を有し、この中には、詳細なスプレッドシート１２１の１つ以上のタブが表示されている。ユーザ１０５がスプレッドシート１２１の特定のセクションを研究するにあたり、スプレッドシート１２１の１つの特定のサブセクションに属する結果を円グラフ（又は他のフォーカスされた）表現１２３として、新たなウィンドウに独立して表示することを望んだとする。残念ながら、メインモニタの有限のディスプレイ領域１１１は、ユーザ１０５が見たがっている拡大されたフォーカスされたビュー１２３と、表示が消えることをユーザが望まない既に表示されているスプレッドシート１２１との両方を収めるには不十分である。適切なスクリーン上のアイコン１２２上でマウス（１４０）をクリックすることによって、ユーザ１０５は、補助ディスプレイユニット１５０のディスプレイ領域１５１内に拡大された円グラフビュー１２３を表示することをコンピュータ１２０に命令する。これにより、ユーザ１０５は、スプレッドシート１２１と、拡大された円グラフビュー１２３とを同時に見ることができる。
【００２１】
ユーザのコマンドに応じて、コンピュータ１２０は、補助イメージ１２３のための所望のグラフィックデータを生成し、このイメージデータを、補助ビデオポートを介して、ポートのケーブル１５６を経由して、補助ディスプレイユニット１５０に送信する。補助ディスプレイユニット１５０は、そのディスプレイ領域１５１に拡大された円グラフビュー１２３を表示することによって受信したビデオデータ（１５６）に応答する。この結果、ユーザ１０５は、スプレッドシート１２１の詳細をメインディスプレイユニット１１０上に表示したまま研究を続けながら、同時に、補助ディスプレイユニット１５０上に表示したグラフィック補助結果１２３を研究することができる。
【００２２】
ここで、ユーザ１０５が、大きいスプレッドシート１２１をメインディスプレイユニット１１０上に表示したまま、更に他の補助モニタに、１２３と同様の更なる拡大ビューを表示することを望んだ場合に問題が生じる。第１に、従来のコンピュータ１２０上のビデオ出力ポートの数は、通常、２個に限定されている。コンピュータ１２０がデスクトップユニットである場合、メインビデオケーブル１２６のジャックが挿入されるメインビデオポートプラグと、補助ビデオケーブル１５６のジャックが挿入される１つの補助ビデオポートプラグのみしかない。プラグアンドプレイ検出回路は、補助モニタ１５０のオプションの接続を検出し、（例えば、補助モニタ上に表示すべきグラフィクスのためのＤＲＡＭ記憶域を確保することによって）補助モニタ１５０とインタラクトするようにコンピュータ内部のソフトウェアを自動的に構成する。
【００２３】
他のケース（図示せず）では、ユーザのコンピュータ１２０及びキーボード１３０、並びにメインディスプレイユニット１１０は、ラップトップコンピュータとして一体化されている。このような場合、メインビデオポート１２６は、通常、ラップトップ内で内部的に設けられており、ユーザは、これにアクセスできず、一方、補助ディスプレイユニット１５０をオプションで接続するための補助ビデオコネクタ１５６が１つだけ設けられる。したがって、このようなラップトップコンピュータ又は更に小さいコンピュータで使用できるコネクタ空間が限定的であるため、更なるディスプレイモニタをサポートするために更なるパラレルビデオポートを追加することは、実用的ではない。更に、追加的なビデオ出力ポート１２６、１５６のそれぞれをサポートするための回路は、比較的高価である。したがって、ユーザ１０５が必ず使用するわけではない場合、更なるビデオ出力ポートを追加することは、通常、非実用的である。（１０５ではない）一部のコンピュータユーザは、補助ディスプレイユニット１５０を殆ど又は全く使用しない。したがって、このような、高度な機能を必要としないユーザにとっては、使用されることなく、単に空間を無駄に消費し、不要なコストをシステムに追加する複数のビデオ出力ポートを設けることは、経済的に非実用的である。
【００２４】
更に他のケース（図示せず）では、コンピュータユーザ１０５は、多数の会議参加者（例えば、２０人）と共に会議用テーブルの前に座り、会議参加者は、自らのモニタ又は自らのラップトップコンピュータを有し、図示されたコンピュータユーザ１０５は、そのユーザのモニタ１１０、１５０に表示されている画像１１１、１５１の１つを、テーブルを囲んで座る全ての会議参加者（例えば、２０人、図示せず）の個々のモニタ又はラップトップコンピュータに同時に表示させることを望む。これまでは、このようなことを経済的に容易に実現する手法がなく、これに代えて、ユーザ１０５は、大規模光学プロジェクタを用いて、会議参加者の全てに同時に見せたい画像を大きな共通のスクリーン（例えば、反射式投射器スクリーン）に投射していた。但し、グループで使用するためのこのような大規模光学プロジェクタが容易に利用できないことがあり、この場合、グループは、プレゼンテーションを行うユーザ１０５が、多数の会議参加者（例えば、テーブルの周りに座る２０人、図示せず）と共有することを望む画像（例えば、１１１、１５１）を共有して容易に見る利益を享受することなく、会議を進めなくてはならない。
【００２５】
図１Ｂに示すシステム１８０は、ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔインタフェースを採用している。コンピュータ１２０’は、ＶＥＳＡプロトコルに基づき、ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔ標準インタフェースプラグ１２７に接続するＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔソース回路又はソースチップ１２５を含む。ＶＥＳＡ−ＶＥＳＡのコネクタケーブル（明示的には示していない）は、第１のＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔインタフェースプラグ１２７から同様の第２のＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔインタフェースプラグ１５７に接続し、そして、後者のインタフェースプラグ１５７は、補助ディスプレイユニット１５０’内に設けられているＶＥＳＡ−ＤＰデータシンクチップ又は回路１５５に接続する（１５６’）。
【００２６】
ＶＥＳＡ ＤＰプロトコル１．１に基づき、ソース側ＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔ外部インタフェースプラグ１２７には、以下のピンアウトが要求されている。
【表１】
【００２７】
なお、上の表１は、ソース側コネクタ（１２７）のピンアウトを示している。シンク側コネクタ（１５７）のピンアウトは、レーン０〜３の順序が逆になり、すなわち、レーン３がピン１、３に対応し、レーン０がピン１０、１２に対応する。
【００２８】
図２は、本発明の開示に基づくビデオ信号生成及びディスプレイシステム２００のブロック図である。図２の要素には、「２００」番台の参照シンボル及び参照符号を用い、これらは、図１Ｂに示す「１００」番台の同様の参照シンボル及び参照符号によって表されている要素に対応するが、必ずしも同じである必要はない。そこで、図２に示す全ての要素の導入的な説明は省略し、違いについてのみ説明する。
【００２９】
１つのビデオシンクコネクタ１５７のみが設けられている図１Ｂの補助モニタ１５０とは異なり図２の補助モニタ２５０には、ビデオシンク及び受信コネクタ２５７と、ビデオ出力及び中継コネクタ２５９との２つのＶＥＳＡ−ＤＰ互換コネクタが設けられている。また、補助モニタ２５０内では（拡大鏡シンボル２５４によって示すように）、モニタ２５０のＶＥＳＡ−ＤＰ互換コネクタ２５７、２５９の間に、第１のＶＥＳＡ−ＤＰ互換送受信回路（又はモノリシック集積回路）２５５が挿入されている。ＶＤＰ互換送受信回路／チップ２５５は、（例えば、図１Ｂの１５５と同様の）従来のＶＥＳＡ−ＤＰシンク回路として第１のモードで動作するように、動的にプログラミング可能である。更に、ＶＤＰ互換送受信回路／チップ２５５は、これに代えて、送受信回路／チップ２５５が受信したビデオデータストリームを（ビデオ出力及び中継コネクタ２５９を介して）第２の補助モニタ２６０に中継する中継器として第２のモードで動作するように動的にプログラミングすることもできる。なお、完全には示していないが、第１の送受信回路／チップ２５５は、ポート２５５ａ、２５５ｂ、２５５ｃを有する３ポートデータルータとして動作する。これは、その第１のポート２５５ａを介して、入力ビデオデータのマルチレーンＶＤＰ互換ストリームを受信し、ここに宛てられた入力ビデオデータを選択的にデシリアライズし、受信したビデオ及びデシリアライズされたビデオデータを、その第２のポート２５５ｂに（例えば、コンポジットＲＧＢビデオ信号として）出力し、関連するモニタ２５０に表示させ、また、（ポート２５５ａからの）受信ビデオデータを中継し、その第３のポート２５５ｃ介して、チェイン内の次のＶＤＰ互換送受信回路／チップ２６５の対応する第１のＶＤＰ互換受信ポート２６５ａに出力し、チェイン内の次のＶＤＰ互換送受信回路／チップ２６５は、２５５と同様に構成されているが、チェイン内の次の送受信回路／チップ２６５は、チェイン内の次の送受信回路／チップ２６５を宛先として特定するビデオデータに応じるように別様にプログラミングされていてもよい。なお、チェイン内の次の送受信回路／チップ２６５は、接続２６８を介して、チェイン内の次の送受信回路／チップ（図示せず）に更に接続してもよく、以下同様に接続を繰り返してもよい。
【００３０】
なお、図２では、各３ポートＶＤＰ互換送受信回路／チップ２５５、２６５（その配置は、拡大鏡シンボル２６４によって示している。）等が各ディスプレイユニット２５０、２６０の内部に搭載されている構成を示しているが、この構成は、本発明の必要条件ではない。これに代えて、各３ポートＶＤＰ互換送受信回路／チップ２５５、２６５等は、他の場所、例えば、３コネクタジャンクションボックス（図示せず）の内部に搭載してもよく、ここで、少なくとも３つのコネクタのうち２つは、それぞれＶＥＳＡ−ＤＰ互換ビデオシンク及び受信コネクタ（２５７と同様）、並びにＶＥＳＡ−ＤＰ互換ビデオ出力及び中継コネクタ（２５９と同様）である。ジャンクションボックス（図示せず）の第３のコネクタは、関連するローカルモニタ（２５０）に互換性があるコネクタであってもよく、これは、ＶＥＳＡ−ＤＰ互換ビデオ出力コネクタであってもよく、ＶＥＳＡ−ＤＰ互換ビデオ出力コネクタではなくてもよい。例えば、ジャンクションボックス（図示せず）の第３のコネクタは、ＲＧＢビデオコンポジット出力コネクタであってもよい。
【００３１】
更に、図２に関して、例示的に示したバス及び／又はケーブル２２６、２５６、２５８、２６６、２６８は、正確にここに示す通りではなくてもよい。図を簡略化しなければ、５つの全てのＶＥＳＡ−ＤＰコネクタを詳細に示す必要があるが、ここでは、これを回避し、図式的表現は、できるだけ簡潔に描かれている。なお、コンピュータ２２０には、少なくとも１つのＶＥＳＡ−ＤＰソースコネクタ２２７があり、第１のモニタユニット２５０には、少なくとも１つのＶＥＳＡ−ＤＰシンク及び中継コネクタ２５７、並びに少なくとも１つのＶＥＳＡ−ＤＰソース及び中継コネクタ２５９があり、第２のモニタユニット２６０には、少なくとも１つのＶＥＳＡ−ＤＰシンク及び中継コネクタ２６７、並びに少なくとも１つのＶＥＳＡ−ＤＰソース及び中継コネクタ（２６８として表されている）がある。したがって、コネクタ２２７、２５７の間には、１つのＶＥＳＡ−ＤＰ互換ケーブル２２６−２５６が接続されている。コネクタ２５９、２６７の間には、第２のＶＥＳＡ−ＤＰ互換ケーブル２５８−２６６が接続されている。オプションとして、第２のモニタ２６０からデイジーチェイン内の次の信号受信及び／又は中継デバイスに第３のＶＥＳＡ−ＤＰ互換ケーブル２６８を接続してもよい。２５９、２６８等の各ソース及び中継コネクタは、ホットプラグ検出（hot-plug detection：ＨＰＤ）をサポートし、これにより、デイジーチェインは、ユーザの意向に応じて、オンザフライ方式で拡張又は短縮することができる。一実施の形態においては、このような数珠つなぎのデイジーチェイン方式で最大２５４個のモニタが接続される。（より一般化して言えば、比較的多数、例えば、５つ以上のモニタを同時にサポートできる。ＭＤＩＤフィールドの長さが８ビットである場合、最大値は、２５６であるが、このアドレス空間の一部、例えば、２つ以上のアドレスは、特定の用途で使用するための予備にすることができる。）
図３は、本発明に基づくシステム３００のより詳細な構成を示している。システム３００は、ＶＥＳＡ−ＤＰ互換ビデオ出力回路／チップ３２５（ソースデバイス）及び２つのＶＥＳＡ−ＤＰ互換ビデオ送受信回路／チップ３５５、３６５（シンクデバイス）を含み、これらは、ここに示すように、デイジーチェイン方式で接続されている。各ＶＤＰ互換送受信回路／チップ（３５５又は３６５）は、４個のシリアルビデオデータ受信ユニット（３５１ａ〜３５４ａ又は３５１ｂ〜３５４ｂ）を内部に有し、及び１つの補助制御データ送受信ユニット（３５５ａ又は３５５ｂ）を内部に有する。４個のシリアルビデオデータ受信ユニット３５１ａ〜３５４ａ（又は３５１ｂ〜３５４ｂ）は、それぞれ、シリアルリンク３４１〜３４４（３９１〜３９４）の１つを介して、シリアライズされたレーンデータを受信し、受信したレーンデータを内部データ処理ユニット（３６９ａ又は３６９ｂ）に供給し、及び受信したレーンデータを対応するフィードフォワード型バッファ／アンプ（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）に中継する。なお、明示的には示していないが、バッファ／アンプ（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、内部データ処理ユニット（３６９ａ又は３６９ｂ）のためにある程度の量のデータ遅延バッファリングを提供でき、これにより、内部データ処理ユニットは、後述するＭＤＩＤ挿入フラグ及びＭＤＩＤ信号（図５Ａ、５１５、５２０参照）を含むある制御信号に応答することができる。
【００３２】
各内部データ処理ユニット（例えば、３６９ａ、３６９ｂ）は、特に、４つのシリアルデータリンク（３４１〜３４４又は３９１〜３９４）のそれぞれを介して受信したシリアライズされたビデオデータを自動的にデシリアライズして、パックされているビデオデータをアンパックし、デシリアライズされ、アンパックされたビデオデータを、ローカルの相互接続バス３７０Ａ（又は３７０Ｂ）を介して、ローカルディスプレイモニタで使用可能なフォーマットで、関連するローカルディスプレイモニタ２５０’又は２６０’に供給するようにプログラミング可能である。このように関連するローカルディスプレイモニタにビデオデータをルーティングする際、内部プロセッサ（例えば、３６９ａ、３６９ｂ）は、複数のレーン（予め整列されているレーン）からのデータを結合及び／又は混合することによってデータをアンパックし、出力用のコンポジットビデオ信号を生成し、垂直バス３７０Ａ（又は３７０Ｂ）に沿ってローカル出力ポート（図２の２５５ｂ又は２６５ｂ）に、及びここからローカルディスプレイモニタに出力するようにしてもよい。図４に示す一実施の形態においては、シリアルデータリンクレーン０〜４は、隣接するビデオ画素又は副画素（subpixel）を搬送し、内部プロセッサ（例えば、３６９ａ又は３６９ｂ）は、レーンに亘って分散されている画素／副画素をアンパックして、ローカルディスプレイモニタ（例えば、２５０’又は２６０’）による表示のためにフォーマットされたコンポジットビデオストリームを生成する。
【００３３】
この通過するレーンデータをローカルディスプレイモニタ（例えば、２５０’又は２６０’）によるオプションのディスプレイのために選択的に取り出すことと同時に、フィードフォワード型バッファ／増幅器（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、物理インタフェース送信機３８１ａ〜３８４ａを介して、次の一組の４つのシリアルデータリンク（例えば、３９１〜３９４）に沿って、チェイン内の次のシリアルビデオデータ受信ユニット（例えば、３６５）による受信のために、同じ４つのレーンのデータを出力する。なお、フィードフォワード型バッファ／増幅器（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、後に詳細に説明するように、クロックデスキュー（clock deskewing）及びレーン整列機能を提供する可変遅延モジュールを含んでいてもよい。なお、フィードフォワード型バッファ／増幅器（３６１ａ〜３６４ａ又は３６１ｂ〜３６４ｂ）は、内部データプロセッサのための信号遅延サポートを提供でき（図５Ａの時間遅延ＴＩ及びＴ２参照）、これにより、内部データプロセッサは、一致するＭＤＩＤ値を検出し、関連するビデオバーストデータ（例えば、図５Ａの５３０）及び／又は関連するオーディオのバーストデータ（例えば、図５Ａの５２２）及び／又は関連する二次データバースト（例えば、図５Ｂの５８０）のコピーを取り出す時間を有する。
【００３４】
送受信回路／チップ３５５、３６５の補助制御データ送受信ユニット（３５５ａ又は３５５ｂ）のそれぞれは、チップ内のそれぞれのシンク側ポリシメーカ（policy-maker）ユニット（３６５ａ又は３６５ｂ）に接続し、これは、チップのローカル垂直バス（３７０Ａ又は３７０Ｂ）を介して、内部データプロセッサ（３６９ａ又は３６９ｂ）に動作的に接続している。
【００３５】
ＶＤＰ互換送受信チップ（３５５、３６５）のそれぞれは、ＤｉｓｐｌａｙＰｏｒｔ構成データ（Display Port Configuration Data：ＤＰＣＤ）レジスタ及びＥＤＩＤ（拡張ディスプレイ識別データ：Display Identification Data）レジスタのローカルセットを含む。詳しくは、ローカルモニタ、例えばモニタ２５０’のローカルＤｉｓｐｌａｙＰｏｒｔ構成データは、対応するＶＥＳＡ−ＤＰ互換ビデオ送受信回路チップ（例えば、３５５）のポリシメーカ３６５ａ内のローカルの（シンク側）ＤＰＣＤレジスタ３６５ｃ、及びローカルＥＤＩＤレジスタ３６５ｄに保存される。このローカルプログラミングは、ローカルモニタ（例えば、２５０’）の製造業者の責任の下で行われる。ＶＥＳＡ−ＤＰ技術における当業者に理解されるように、ＶＥＳＡ準拠ＥＤＩＤデータは、ローカルモニタの物理的属性、例えば、製造元及びモデル、及び再構成可能な特徴（例えば、現在の画面解像度）の許容範囲及びそれぞれのデフォルト値を示す。ＶＥＳＡ準拠ＤＰＣＤデータは、モニタの現在の再構成可能な構成を示す。同様に、第２のＶＥＳＡ−ＤＰ互換ビデオ送受信回路／チップ３６５のポリシメーカ３６５ｂは、ローカルモニタ２６０’に対応する情報によってプログラミングされた、ローカルでプログラミングされた自らのローカルＤＰＣＤレジスタ３６５ｅ及びローカルＥＤＩＤレジスタ３６５ｆの組を含む。
【００３６】
システムリブート又はリセットの間、又はモニタのホットプラグが検出されると、ローカルＤＰＣＤデータ（例えば、３６５ｃ、３６５ｅ）及びＥＤＩＤデータ（例えば、３６５ｄ、３６５ｆ）は、ローカルポリシメーカ（例えば、３６５ａ、３６５ｂ）からソース回路／チップ３２５のコピー保持記憶域３０１〜３ＦＥにコピーされる。ここでは、これらのコピー保持記憶域３０１〜３ＦＥをソースＥＤＩＤレジスタ及びソースＤＰＣＤレジスタと呼ぶ。一実施の形態においては、ソースＥＤＩＤレジスタデータ及びソースＤＰＣＤレジスタデータを保存するメモリモジュール３１０は、それぞれアドレス値００ｈｅｘ〜０ＦＥｈｅｘを有する２５５組の固有のこのようなレジスタセットを格納する十分な容量を有し、ここで、値０ＦＦｈｅｘは、無効のソースＥＤＩＤ及び無効のソースＤＰＣＤレジスタ領域を示すために予約されている。最大２５５個の各ソースＥＤＩＤレジスタ領域及びソースＤＰＣＤレジスタ領域は、対応する数の仮想ビデオ生成器３３１、３３２…３３Ｅによって選択的にアクセス可能である。各仮想ビデオ生成器（例えば、３３１〜３３Ｅ）は、ソースＥＤＩＤレジスタデータ及びソースＤＰＣＤレジスタデータのそれぞれの１つにアクセスし、そこにコピーされているデータを用いて、対応するＶＥＳＡ−ＤＰ互換ビデオデータを生成することができる。コピーされたＥＤＩＤデータ及びコピーされたＤＰＣＤデータは、アポストロフィの添字で示す。例えば、仮想ユニット３０１内のＤＰＣＤ’及びＥＤＩＤ’は、チップ３５５内のローカルユニット３６５ｃ、３６５ｄからコピーされたものである。仮想ユニット３０２内のＤＰＣＤ”及びＥＤＩＤ”は、チップ３６５内のローカルユニット３６５ｅ、３６５ｆからコピーされたものであり、以下同様である。仮想ユニット３ＦＥ内のＤＰＣＤ”’及びＥＤＩＤ”’は、更に他の送受信チップ（図示せず）内のローカルレジスタユニットからコピーされたものであってもよい。図３に特別に示す通り、第１のローカルＤＰＣＤ及びＥＤＩＤレジスタセット（３６５ｃ、３６５ｄ）は、送受信回路／チップ３５５のポリシメーカ３６５ａ内に格納されている。第２のローカルＤＰＣＤ及びＥＤＩＤレジスタセット（３６５ｅ、３６５ｆ）は、送受信回路／チップ３６５のポリシメーカ３６５ｂ内に格納されており、以下同様である。一旦、ローカルＤＰＣＤ及びＥＤＩＤレジスタデータがソースチップ３２５にコピーされると、仮想ビデオ生成器３３１〜３３Ｅは、ソースチップ３２５内で内部的にデータにアクセスできるようになる。
【００３７】
仮想ビデオ生成器３３１〜３３Ｅの１つが、対応するビデオモニタへのストリーミング出力のためにビデオデータの各バースト（図５Ａの５３０参照）を生成するとき、仮想ビデオ生成器は、シリアルリンク３４１〜３４４から利用可能な送信帯域幅の全てを利用するように、シリアルリンクレーン３４１〜３４４の全てに亘って実質的に同時に出力バーストを分散（spread）させる（パックする）。一実施の形態においては、各リンクは、少なくとも約２．７ギガビット毎秒の帯域幅を提供する。他の実施の形態では、各リンクは、２．７ＧＨｚより高い、例えば、３．５ＧＨｚ、５．０ＧＨｚ又はこれ以上の帯域幅を提供する。ビデオ出力バーストの収集及びシリアルリンクレーン３４１〜３４４に亘るその配信は、４レーンデータ再パッカユニット（4-lane data repacker unit）３４０によって行われる。データ再パッカユニット３４０は、４つのレーンに亘る所与の仮想ビデオ生成器のビデオ出力バースト（例えば、図５Ａの５３０）の再パックに加えて、シリアルレーン３４１〜３４４のビットストリームバーストにＭｕｌｔｉＤｅｖｉｃｅ識別番号信号又はＭＤＩＤ信号３３９を挿入する。より詳しくは、図５Ａの行５２０は、４つのレーンのそれぞれにおいて、行５１４に位置するＭＤＩＤ挿入フラグからＴ１遅れた時刻において８ビットＭＤＩＤ信号が複製されることを示している。このＭＤＩＤ信号３３９／５２０は、データプロセッサユニット３６９ａ、３６９ｂ等によってサンプリングされ、データプロセッサユニット３６９ａ、３６９ｂ等は、関連するパススルーされるビデオ出力バースト（例えば、５３０図５Ａ）が対応するローカルモニタ（例えば、２５０’、２６０’）に表示することを目的とするものであるかを判定する。バーストがこのように対応するローカルモニタに向けられている場合、送受信回路／チップ（例えば、３５５、３６５等）内のデータプロセッサユニット（例えば、３６９ａ、３６９ｂ等）は、パススルーされるデータのコピーをキャプチャし、パススルーされるビデオ出力バーストのキャプチャされたコピー（バッファリングされたコピー）から、対応するローカルコンポジット信号を生成し、コンポジット信号を、表示又は他の適切な使用のために、関連するローカルモニタ（例えば、２５０’、２６０’等）に向けて送り出す。
【００３８】
一実施の形態においては、パススルーされるＭＤＩＤ値（例えば、図５Ａの５２０）と、ローカルＭＤＩＤ値（例えば、Ｍｙ＿ＭＤＩＤ）との照合は、例えば、以下のような比較的単純な手法でローカルシンクプロセッサ（例えば、図３の３６９ａ）においてインプリメントされる。
【００３９】
ＩＦ （ＭＤＩＤ＿Ｉｎｓｅｒｔ＿Ｆｌａｇ＿Ｂｉｔ ＝ Ｔｒｕｅ） ＡＮＤ （Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝ Ｍｙ＿ＭＤＩＤ） ＴＨＥＮ Ｃａｐｔｕｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ ＥＬＳＥ Ｉｇｎｏｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ
この簡単なインプリメンテーションでは、変数ＭＤＩＤ＿Ｉｎｓｅｒｔ＿Ｆｌａｇ＿Ｂｉｔは、図５ＡのＶＢＩＤバイト５１５又は図５ＢのＶＢＩＤバイト５６５のビット７：７に対応する。Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ変数は、図５Ａの行５２０又は図５Ｂの行５７０内のバイトに対応している。コピーされ（ローカルバッファ内にキャプチャされ）、ローカルで処理されるＰａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａは、図５Ａでは、対応する４つのレーンのそれぞれのオーディオのブロックデータ５２２及び対応する４つのレーンのそれぞれのビデオブロックデータ５３０の一方又は両方に対応しており、図５Ｂでは、二次ブロックデータ５８０対応する４つのレーンのそれぞれのビデオブロックデータ５１０’及び対応する４つのレーンのそれぞれの一方又は両方に対応している。
【００４０】
他の実施の形態では、パススルーされるＭＤＩＤ値（例えば、図５Ａの５２０）は、例えば、以下のように、所定数のローカルＭＤＩＤ値の何れとも照合することができる。
【００４１】
ＩＦ （ＭＤＩＤ＿Ｉｎｓｅｒｔ＿Ｆｌａｇ＿Ｂｉｔ ＝ Ｔｒｕｅ） ＡＮＤ （Ｃｕｒｒｅｎｔ＿Ｌｉｎｅ＿Ｃｏｕｎｔ≦Ｍｙ＿ＭＡｘ＿Ｌｉｎｅ＿Ｃｏｕｎｔ） ＡＮＤ （（Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝Ｍｙ＿ＭＤＩＤ） ＯＲ （Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝２５４） ＯＲ （Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤ ＝２５０）） ＴＨＥＮ Ｃａｐｔｕｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ ＥＬＳＥ Ｉｇｎｏｒｅ＿Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿Ｄａｔａ
ここで、Ｐａｓｓｉｎｇ−ｔｈｒｏｕｇｈ＿ＭＤＩＤバイト（例えば、図５Ａの行５２０）がローカルに設定された（又はホットプラグインの後にソースデバイスによって設定された）２５４、２５０及びＭｙ＿ＭＤＩＤの値の何れかに一致した場合、キャプチャが行われ、ここで、Ｍｙ＿ＭＤＩＤは、通常、２５４及び２５０以外の値である。Ｍｙ＿ＭＡｘ−Ｌｉｎｅ＿Ｃｏｕｎｔ値は、ローカルモニタにおいて１フレームで表示できるビデオラインの最大数を定義し、Ｃｕｒｒｅｎｔ＿Ｌｉｎｅ＿Ｃｏｕｎｔ変数は、現フレームについて既に蓄積されているラインの番号のカウントを維持する。このような場合、ソースデバイスは、デイジーチェイン接続された複数のモニタに同時に共通のビデオデータ又は他のデータをマルチキャストでき、この結果、デイジーチェインで使用可能な有限の帯域幅をより効率的に利用できる。マルチキャストビデオデータは、通常、連続するビデオラインの組として提供され、表示されるピクチャ全体内のピクチャバンド（帯状領域）を形成する。一実施の形態においては、このような動作は、複数台のカメラを備えるセキュリティシステムの集中映像表示ステーション（central video displaying station）で使用される。各モニタは、その上部のバンドに現在の日付及び時刻を表示する必要がある。したがって、ソースデバイスは、包括的に共有されたＭＤｌＤ値の下で、例えば、上述の具体例の値２５４の下で、このデータをマルチキャストする。そして、各モニタは、表示画像内の次の下側のピクチャバンドにカメラの包括的な建物内の位置（例えば、「駐車場３階」）を表示する必要がある。したがって、ソースデバイスは、サブセットで共有されたＭＤＩＤ値、例えば、上述の具体例の値２５０の下でこのデータをマルチキャストする。最後に、各モニタは、表示画像の次の下側のピクチャバンド内に、特定のカメラ番号及びそのカメラからの関連するライブビデオを表示する必要がある。したがって、ソースデバイスは、一意的に割り当てられた特定のローカル識別番号、すなわちその１つのカメラに割り当てられたＭｙ＿ＭＤＩＤの下で、このデータユニキャストする。これは、単なる一例に過ぎない。他の具体例では、デイジーチェイン接続された複数のモニタに亘って、スプレッドシートの行を表示し、複数の行からなる１つバンドは、全てのモニタ又は２つ以上のモニタのサブセットに共通である。
【００４２】
図３に示すように、一実施の形態では、仮想ビデオストリーム生成器（３３１〜３３Ｆ）のそれぞれは、マルチタスクグラフィックプロセッサユニット（ＧＰＵ３３０ａ）及び関連するビデオＳＲＡＭメモリブロック（例えば、３３０ｂ）によって、時間共有されたマルチタスキングベースでインプリメントされる。ビデオＳＲＡＭメモリブロック（例えば、３３０ｂ）には、バス３２０を介して、ホストコンピュータ２２０’から生のビデオデータが供給される。対応するＧＰＵタイムスライス（例えば、３３０ａ）は、対応するソースＥＤＩＤ／ＤＰＣＤレジスタセット（例えば、３０１）を参照し、このレジスタセットは、ＭＤＩＤ信号３３９によって特定され、そして、対応するＧＰＵタイムスライスは、参照したＥＤＩＤ／ＤＰＣＤデータを用いて、データ再パッカユニット３４０の補助によって、シリアルリンク３４１〜３４４に亘るバーストとして出力するためのモニタ互換ビデオデータを生成するために、生のビデオデータをどのように変形（例えば、再パック）するかを判定する。ソースチップの保存ユニット３１０は、対応するソース側のコピーされたＤＰＣＤ及びＥＤＩＤデータ３０１〜３ＦＥを保存することに加えて、更に、対応するＧＰＵタイムスライス（例えば、３３０ａ）に予め定義されたプログラムのうちの所望の１つのプログラムを実行させるためのマシン命令を保存できる。これに代えて又はこれに加えて、ＶＤＰソース回路３２５の共有された他のメモリスペース（図示せず）及び／又はホストコンピュータ２２０’にＧＰＵ実行ソフトウェアを保存してもよい。上述のように、ホストコンピュータ２２０’は、１つ以上のアクティブモニタ（例えば、２５０’、２６０’）に表示する予定のビデオデータを生成器ユニット３３０の各ＶＲＡＭブロックエリア（例えば、３３０ｂ）にダウンロードし、そして、対応するＧＰＵタイムスライス（３３１〜３３Ｅ）は、ダウンロードされたビデオデータを受け取って、関連するＭＤＩＤ信号３３９によって特定される関連するＤＰＣＤ及びＥＤＩＤ保存領域（例えば、３０１）に提供されている現在の構成情報に基づいて、ビデオデータを更に処理し、これにより、処理済みのビデオデータは、宛先のモニタ（例えば、２５０’又は２６０’）の特定のプロトコルに互換性を有するようになる。そして、再パッカ３４０は、処理済のビデオデータのそれぞれをシリアル化し、出力リンク３４１〜３４４の全てに、４レーン幅のシリアルバーストとして送り出す。各出力バーストのスケジューリング（どのモニタに宛てていつ出力するか）は、ソースチップポリシメーカユニット３３５によって行われる。本発明の範囲として、ビデオデータバーストを出力するためのリンク３４１〜３４４の全てがアクティブでなければならないというわけではない。リンクの１つがダウンした場合、再パッカ３４０は、４レーンではなく、３レーンで処理を間に合わせるように試みてもよい。また、このような場合には、対応する帯域幅又は受信モニタの解像度を低減する必要があることもある。これに代えて、デイジーチェイン内のモニタが高解像度モニタではなく低解像度であり、したがって、最大の送信帯域幅が必要でない場合、４レーン幅のバーストモードから３レーン幅のバーストモードへの（又は３レーン幅のバーストモード以下への）低減を実行して、電力消費量を削減してもよい。
【００４３】
更に、図３の具体例は、ソースチップ３２５から、ダウンストリームの送受信回路／チップ３５５、３６５等へ、及びこれらを介して、デイジーチェイン方式で、シリアルバーストとして送り出されるビデオデータのための４個のシリアルレーンの同時の使用を示しており、ここで、出力バーストは、現在のＶＥＳＡ−ＤＰプロトコル要求に概ね適合するが（例外は、図５Ａの５１５、５２０を参照）、本発明の範囲として、システム設計者による適切な判断に基づき、同時に使用されるシリアルレーンの数を変更し、各チップ３２５、３５５及び３６５において、より多くの（例えば、６個、８個、１０個等の）ビデオストリーミングレーンを提供してもよく、より少ない数（例えば、３個のみ）のビデオストリーミングレーンを提供してもよい。例えば、ソースチップ３２５は、例示した４レーンのパッカ３４０に代えて、８レーン幅の再パッカを含むように設計してもよい。このような８レーン再パッカ（図示せず）は、ビデオデータのバースト出力のために、４つのレーンのそれぞれの２つのＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔを同時にサポートする（又は８レーンポートプロトコルをサポートする）ものであってもよい。同時に、シンク側送受信チップ３５５〜３６５は、多くの潜在的ターゲットを区別するために十分な幅を有するＭＤＩＤアドレス指定手段及びパケットアドレス指定手段があれば、４つのレーンのそれぞれの受信したバーストデータをサポートするために十分な回路のみを含むという点は、変更しなくてもよい。このような代替例では、ソースチップは、それぞれが４レーン幅の２つのデイジーチェインを駆動する。（パケットアドレス指定手段の意味は、図４に示すＡＵＸ ＣＨＡＮパケット４５０の宛先ＩＤフィールド４５２の説明によって後に明らかになる。）更に、図３では、各仮想ビデオストリーム生成器（例えば、３３１）がマルチタスクＧＰＵ３３０ａからのタイムスライスを使用できることを示しているが、各ビデオストリーム生成器（例えば、３３１、３３２等）が自らの専用のＧＰＵ及び自らの専用のＶＲＡＭブロックを有する場合も、本発明の範囲内にある。共用又は専用のビデオデータ処理リソースは、汎用ＧＰＵ（例えば、ＡＳＩＣ型ビデオプロセッサ回路）以外のものであってもよく、ビデオデータストレージリソースは、ＳＲＡＭスタイルビデオメモリ（例えば、ビデオ速度ＤＲＡＭメモリ）以外のものであってもよい。
【００４４】
システムリブート、リセット又は再構成の間、デイジーチェイン内の更にダウンストリームの第２のローカルモニタ２６０’の存在及びそのＶＤＰ送受信チップ３６５の存在が、ホットプラグ検出ライン３９６によって、第１のＶＤＰ送受信チップ３５５内のポリシメーカ３６５ａにシグナリングされる。ＶＤＰプロトコルに基づき、ＨＰＤライン３４６は、所定の期間（例えば、２ｍｓ以上）ローに切り替わり（toggle）、そして、通常、ハイに戻ることによって、３つのイベント、すなわち、ホットプラグインイベント、ホットアンプラグイベント、及びシンクデバイスによる割込み要求（interrupt request：ＩＲＱ）の何れかをシグナリングする。起動（boot-up）の間、第１のＶＤＰ送受信チップ３５５は、ＨＰＤライン３４６を切り替える（toggling）ことによって、デイジーチェイン内のその存在をシグナリングする。同様に、第２のＶＤＰ送受信チップ３６５は、ＨＰＤライン３９６を切り替えることによって、デイジーチェイン内のその存在をシグナリングする。これに応じて、第１のＶＤＰ送受信チップ３５５は、再びＨＰＤライン３４６を切り替えることによって、ＶＤＰソースチップ３２５内にあるアップストリームのソースポリシメーカ３３５に切り替えられた信号を自動的に中継する。ホットプラグという表現が含意するように、更なるＶＤＰ送受信チップ（例えば、３６５の後の第３のＶＤＰ送受信チップ）のそれぞれは、デイジーチェインのダウンストリームの端部にホットプラグ接続してもよく、又はデイジーチェインから切り離してもよく、ＶＤＰ送受信チップのチェイン内の次のアップストリームのＶＤＰ送受信チップを介して、切替信号（toggle signal）がソースデバイス３２５上のＨＰＤ入力ライン３４６に達するまで、ローカルのホットプラグ検出ライン（hot plug detection line：ＨＰＤ）のそれぞれの切替（toggling）を中継することによって、電源投入され、アクティブになったデイジーチェインのメンバとして追加された存在をシグナリングでき、又はデバイスが切り離されたことをシグナリングできる。そして、ＨＰＤ入力ライン３４６のこのような切替に応じて、ソースデバイス３２５は、ダウンストリームのＶＤＰ送受信チップのうち、アドレス指定されたものへの中継のために（図４の宛先フィールド４５２参照）、補助チャネルライン（ＡＵＸ ＣＨ）３４５を介して、状態問合せパケット（status inquiry packet）を送信する（図４の４５０参照）。新たなＶＤＰ送受信チップがホットプラグによってデイジーチェインに追加された場合、このＶＤＰ送受信チップは、応答パケット（図４の４６０参照）内でローカルＤＰＣＤ（例えば、３６５ｅ）及びローカルＥＤＩＤ（例えば、３６５ｆ）データを返すことによって状態問合せに応答し、応答パケットは、情報がソースポリシメーカ３３５に到着するまで、補助チャネルラインを介して、アップストリームへ中継される。例示しているソースチップ３２５には、デイジーチェイン接続方式で最大２５５個のＶＤＰ送受信チップを接続することができ、２５５個のＶＤＰ送受信チップ（図示せず）は、２５５個の一意的なＭＤＩＤ値の１つをそれぞれ消費する。図３に例示した具体例３００では、２つのＶＤＰ送受信チップのみがアクティブ化され、デイジーチェイン接続方式でソースチップ３２５に接続されている。第１のＶＤＰ送受信チップ３５５は、タイムスライスの第１の組のためにソースシリアルリンクレーン０〜４を消費し、一方、第２のＶＤＰ送受信チップ３６５は、交互になる第２の時間スライスの間に同じソースシリアルリンクレーン０〜４を消費する。送受信チップ３５５対３６５に割り当てられるタイムスライスの長さは、対応するローカルモニタ２５０’、２６０’の現在の解像度の要求に基づいて変化してもよい。
【００４５】
上述したＤＰＣＤデータ及びＥＤＩＤデータのコピー及び中継をサポートするために、標準のＶＥＳＡ ＤｉｓｐｌａｙＰｏｒｔ規格を補足的に変更する必要がある。
【００４６】
２．１ 補足的ＤｉｓｐｌａｙＰｏｒｔ構成データ（Display Port Configuration Data：ＤＰＣＤ）レジスタ
ＶＥＳＡ−ＤＰ１．１規格は、幾つかの制御レジスタアドレスの機能を定義し、他のものを未使用又は将来の拡張のための予備として残している。本発明では、予備のレジスタスペースアドレスのうち、本明細書及び上で引用した（及びここに援用される）２００８年１月１５日に出願されたＪｅｃｈａｎ Ｋｉｍによる米国特許出願番号第１２／０１４，３４１号の両方に説明されているビデオデータのデイジーチェイン動作をサポートするために、アドレス００３００（ｈｅｘ）−００３０３（ｈ）及び００４００（ｈｅｘ）−００４１１（ｈ）を、適応化することを提案する。なお、これらのレジスタアドレスの幾つかは、各レーンを個別に操作できる米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションのためのみに用いられ、これらのレジスタアドレスの幾つかは、４つの全てのレーン（例えば、１つのレーンがダウンしている場合、より少ない数のレーン）に亘るパックされたバーストとして、デイジーチェインでビデオデータを送信する本出願に基づくインプリメンテーションのためのみに用いられ、これらのレジスタアドレスの幾つかは、両方のインプリメンテーションで共有される。もちろん、特定のアドレスは、変更してもよい。なお、本発明が提案する予備のアドレスの割当てが業界で採用された又は他の割当に衝突する場合、ここで提案するレジスタアドレスは、衝突を回避するために、適切に変更してもよい。一実施の形態においては、オプションのデイジーチェインをサポートして、米国特許出願第１２／０１４，３４１号及び本発明の両方の特徴を実現するために、変更されたソースデバイス（３２５）のソースの特定のＤＰＣＤフィールド（３０１〜３ＦＥ）、及び送受信ユニット（３５５、３６５）のシンク側の特定のＤＰＣＤフィールド（３６５ｃ、３６５ｅ）において、以下の新たなＤＰＣＤレジスタ定義を使用する。
【００４７】
表２：追加されたＤＰＣＤソース特定フィールド
【表２】
【００４８】
表３：追加されたＤＰＣＤシンク特定フィールド
【表３】
【００４９】
更なる説明
ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴモード：ＤＰＣＤ００３０３ｈ及び００４０３ｈのビット１：０
この２ビットのユーザプログラマブルフィールド（０３０３ｈ又は０４０３ｈのレジスタ内）は、ソースデバイス又はシンクデバイスのそれぞれのデイジーチェインサポート機能がオンにされているか、オフにされているかを示し、オンの場合、米国特許出願第１２／０１４，３４１号の空間多重化スキームが用いられているか、ここに開示する時間多重、ＭＤＩＤターゲット化スキームが用いられているかを示す。ソースデバイスのこの２ビットフィールドが論理値「１０」に設定されている場合、対応するソースデバイス（例えば、３２５）は、ソースユニット（例えば、３２５）からダウンストリームに向けて、（ＭＤＩＤフィールド長が８ビットであるとすれば）最大２５５個の個別の時間的にインタレースされたＤｉｓｐｌａｙＰｏｒｔビデオデータバーストをサポートできるモードに切り替えられ、各ビデオバーストは、所定の時間スライスにおいて、例えば、４つのレーン（３４１〜３４４）の全てを占め、ビデオ及び二次データを含み、これは、一致するＭＤＩＤ識別子を有するダウンストリームシンクデバイスにおいて取り出すことができ、データは、デイジーチェイン、転送中継方式で送信される。また、ソースデバイス（例えば、３２５）は、このモードに切り替えられると、後述するセクション２．２に開示されているような拡張ＡＵＸ＿ＣＨトランザクションをサポートする。
【００５０】
シンク側デバイスにおいて、ＤＰＣＤアドレス００４０３ｈのビット１：０が論理値「１０」に設定されている場合、シンクデバイスは、後述する拡張ＡＵＸ＿ＣＨトランザクションを用いて、時間的にインタレースされたＤｉｓｐｌａｙＰｏｒｔビデオデータバーストモードのシンク回路部分をサポートするモードに切り替えられる。
【００５１】
ＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤ：ＤＰＣＤ位置００４０３ｈのビット５：４
このレジスタは、米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションで使用されるが、本発明のバーストモード時間多重スキーム（ＭＤＩＤスキーム）がアクティブの場合、全て０のままにされる。後に詳細に説明するように、デイジーチェインサポートモードがオンになっている場合、補助チャネルメッセージは、宛先指示情報を含むパケットとして送信される。例えば、図４を参照すると、ソースユニット４２５によるパケット出力の構造は、４５０に示されており、応答シンクデバイスによる応答パケット出力の構造は、４６０に示されている。米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションでは、シンク側デバイス（例えば、４５５、４６５又は４７５）内のＤＰＣＤ位置００４０３ｈのビット５：４は、０〜３の範囲のみで、所与のデイジーチェイン内のシンクデバイス識別情報を定義する。チェイン内で最大４個の一意的なシンク側デバイスが許容されている場合、ＩＤ値は、０〜３の範囲に亘る。米国特許出願第１２／０１４，３４１号に基づく実施の形態が使用されているとき、シンク側デバイスは、このシンクデバイスＩＤフィールドを用いて、ＡＵＸ＿ＣＨチャネル４４５を介して、ソースデバイス（例えば、４２５）によって発行されたトランザクション要求パケット４５０に応答するかを判定することができる。このような場合において、識別値の一致が検出されると、シンクデバイスは、応答し、ローカルＤＰＣＤレジスタの位置００４０３ｈに格納されているシンクデバイス識別値を、応答パケット４６０のＩＤフィールド４６２にコピーする。応答パケット４６０は、ＡＵＸ＿ＣＨチャネル４４５を介して、デイジーチェイン内に存在する任意の数の介在する送受信デバイス（例えば、４５５、４６５、４７５）を経由して、要求を出したソースデバイス（例えば、４２５）に中継によって戻される。
【００５２】
ＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤ：ＤＰＣＤ位置００４１０ｈのビット７：０
このレジスタは、本発明に基づくＭＤＩＤをキーにするインプリメンテーションで使用され、米国特許出願第１２／０１４，３４１号に基づく構成では、全て０のままにされる。ここで詳細に説明しているように、最大２５５個の個別の送受信回路／チップ（４５５〜４７５等）がサポートされ、それぞれには、異なる８ビットＭＤＩＤ識別値が割り当てられ、又はオプションとして、これらの１つ以上は、同じＭＤＩＤ値を共有してもよい。
【００５３】
ＤＰＣＤ位置００４０４ｈのＩＮ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ及びＯＵＴ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ：このレジスタは、米国特許出願第１２／０１４，３４１号に基づくインプリメンテーションで使用され、本発明に基づくＭＤＩＤをキーにするスキームでは、全て０のままにされる。各シンク側デバイス（例えば、４５５、４６５又は４７５）のＤＰＣＤ位置００４０４ｈに保存されているデータは、個別の入口レーン（ingress lanes）のどれがアクティブであり、及びシンク側デバイスの個別の出口レーン（egress lanes）のどれがアクティブであるかを定義する。一実施の形態においては、入口−出口のレーンマッピング（このようなマッピングは、米国特許出願第１２／０１４，３４１号に開示されている。）は、アクティブな入口レーン及びアクティブな出口レーンの数に基づいて定義される。一例として、図４では、シンクデバイス４６５（Ｂ）は、その最初の３つの入口レーンがアクティブであり及びその最初の２つの出口レーンのみがアクティブであることを示すようにプログラミングしてもよい。この結果、レーン毎のビデオストリームは、米国特許出願第１２／０１４，３４１号のマッピングスキームに基づき、デバイス４６５（ｂ）を介して、ルーティング（再マッピング）される。
【００５４】
ＤＰＣＤ位置００４１１ｈのＩＮ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ及びＯＵＴ＿ＡＣＴＩＶＥ＿ＬＡＮＥＳ：このレジスタは、本発明に基づくＭＤＩＤをキーにする構成で使用され、米国特許出願第１２／０１４，３４１号に基づく構成では、全て０のままにされる。典型的には、利用可能なシリアルリンクの最大帯域幅においてバーストモードデータを中継するために４つの全てのレーンが使用されるように、ビット７：４は、１１１１ｈに設定され、また、ビット３：０も、１１１１ｈに設定される。但し、シリアルリンクに欠陥があってもよく、システム設計者は、オプションとして、１つのレーンを選択的にシャットダウンすることによって、消費電力を削減することを望んでもよく、これらも、本発明の範囲内に含まれる。したがって、幾つかの実施の形態では、このレジスタは、レーンの選択的な非アクティブ化を可能にする。例えば、各４個の制御ビットの０１１１ｈの設定は、レーン０、１及び２がビデオデータの受信／出力にアクティブであり、レーン３は、非アクティブである（例えば、電源がダウンされている）ことを意味してもよい。
【００５５】
２．２ 拡張ＡＵＸ＿ＣＨ要求／応答トランザクションシンタクス
更に図４を参照して説明すると、ソースデバイス（４２５）は、デイジーチェイン内で最大２５５個の異なるシンクデバイスに（本発明に基づいて、及び米国特許出願第１２／０１４，３４１号に基づいて最大２５５の異なるシンクデバイスに）異なるビデオストリームを送信することができるので、標準ＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨハンドシェイクプロトコルは、補足的な拡張モードがアクティブの場合、出力トランザクション要求４５０内に宛先指定バイト４５２を含ませる（挿入する）ように変更される。図４は、このように変更されたパケット４５０を示している。一実施の形態においては、宛先バイト４５２の８ビットの全ては、その宛先バイト４５２に対応するＭＤＩＤ値をコピーすることによってトランザクション要求パケット４５０に応答する予定のターゲットのシンクデバイスを特定するために使用される。トランザクション要求信号の残りの部分は、標準のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨハンドシェイクと同様のままである。バイト４５１は、送信同期フィールドであり、クロック復元及びトランザクション要求信号の開始のシグナリングのために用いられる。一実施の形態においては、各送受信デバイス（４５５、４６５、４７５）には、一意的な同期シンボルが割り当てられるが、レーン０（４４１）上で使用されている同期シンボル（４５１）だけが、基準クロック信号を生成するために使用され、全ての送受信デバイス（例えば、４５５、４６５、４７５等）は、これにローカルクロックを同期させる。そして、基準クロック信号は、複数のシリアルリンクレーンの共にパックされたビデオ信号の時間的な整列に使用される。
【００５６】
拡張トランザクション信号４５０のバイト４５３は、その最下位ビット３：０及びバイトの前半のターゲットアドレスビット１９：１６内に符号化されたコマンドを含む。フィールド４５４は、２バイト長であり、その前半及び後半にそれぞれのターゲットアドレスビット１５：８及び０：７を含む。レングスバイト４５６のビット７：０は、ペイロード長を特定する。ペイロードデータは、フィールド４５７に格納され、パケットの終了又は停止バイトは、４５９で示される。
【００５７】
応答シンクデバイスからの対応する応答パケット４６０においては、１つのバイト、すなわちレーン固有の同期バイト４６１の後にＳｉｎｋ＿ＩＤフィールド４６２が加えられる。一実施の形態においては、ｓｉｎｋ＿ＩＤバイト４６２の８ビットの全ては、トランザクション要求パケットに応答する応答シンクデバイスを特定するために使用され、ここで、ｓｉｎｋ＿ＩＤは、シンクデバイスに割り当てられたＭＤＩＤ値と同じである。２つ以上のシンクデバイスに同じＭＤＩＤ値が割り当てられている場合、ＭＤＩＤを共有するシンクデバイスのうち、最もアップストリーム側のシンクデバイスが、ＭＤＩＤを共有するシンクデバイスの全てを代表して応答する責任を有する。１つ以上のＤＰＣＤビットを予約し、ＭＤＩＤを共有するシンクデバイスのどれが最もアップストリーム側にあるかを示すために使用してもよい。
【００５８】
３．０ ソースデバイス要求：デイジーチェイン拡張機能をサポートするために、本発明に基づくソースデバイス（例えば、４２５）は、以下の側面をサポートするように設計する必要がある。（１）（上述のセクション２．１に定義したような）新たなＤＰＣＤソース特定フィールドに適合する。（２）本来のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨシンタクスに加えて、（上述のような）拡張ＡＵＸ＿ＣＨシンタクスをサポートする。（３）所与の仮想の又は非仮想のビデオバースト生成器（例えば、４３２）からの少なくとも４つのパックされたシリアルリンクのバースト出力をサポートする。（４）対応する最大２５５個のデイジーチェイン接続可能なシンクデバイスについて、最大２５５個のローカルのＥＤＩＤ及びＤＰＣＤレジスタセット（図３の３６５ｃ、３６５ｄ参照）を自らにコピーでき又は他の手法で応答的に管理できる。（５）後述するように、拡張ＡＵＸ＿ＣＨトランザクションを扱うためにプログラミング可能なタイマを含む。
【００５９】
４．０ シンクデバイス要求：ここに説明したデイジーチェイン特徴をサポートするために、一実施の形態において、各シンクデバイス（例えば、４５５）は、以下に列挙する側面をサポートできる必要がある。（１）手動で（例えば、ローカルモニタ上のロータリ又はパネルボタンで）及び自動的に（例えば、プレロードされたＥＤＩＤデータに応じて）確立された仕様の何れかに応じて、所定のＭＤＩＤ値に一致するシンクデバイスＩＤを設定することができる。（２）（上述のセクション２．１に定義したような）新たなＤＰＣＤシンク特定フィールドに適合する。（２）本来のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨシンタクスに加えて、（上述のような）拡張ＡＵＸ＿ＣＨシンタクスをサポートする。（３）パススルーデバイスとして機能するよう指示された場合、共にパックされたビデオデータの少なくとも４個のパラレルストリームのパススルーをサポートし、及び／又はストリームが、添付のＭＤＩＤ信号（図５Ａの５２０）によって、当該シンクに宛てられている場合、パススルーされているビデオストリームの取り出し及びローカル表示をサポートする。（４）デイジーチェイン内の次のダウンストリームのシンクデバイスとインタラクトするための拡張された及び本来のＡＵＸ＿ＣＨトランザクション生成器／プロセッサ（ポリシメーカ）を提供する。（５）ダウンストリームのシンクデバイスから、アップストリームのシンクデバイス又はアップストリームのソースデバイス（４２５）に向けて生成されたＨＰＤトグル信号を中継する。
【００６０】
５．０ トランザクションの詳細
５．１ ＡＵＸ＿ＣＨトランザクション
一旦、ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴフィールドが設定されると、ソースデバイス（例えば、４２５）は、ＤＥＳＴ＿ＩＤフィールドを含む拡張ＡＵＸ＿ＣＨシンタクスを用いて、標準の本来のＶＥＳＡ−ＤＰ ＡＵＸ＿ＣＨシンタクスに代わるトランザクションを生成する。一実施の形態においては、デイジーチェインに沿って、ダウンストリーム方向に連続するＭＤＩＤ値（例えば、０、１、２、３…２５４）が連続的に割り当てられ、以下の処理が採用される。
【００６１】
ステップ１：ソースデバイス（例えば、４２５）が、そのＡＵＸ＿ＣＨライン（例えば、４４５）からＤＥＳＴ＿ＩＤ＝１を用いて、ＡＵＸ＿ＣＨ書込／読出要求トランザクションを生成及び出力し、内部の応答タイムアウトタイマを開始し、このタイムアウト値は、本来のＡＵＸ＿ＣＨ交換のためのタイマによって用いられるタイムアウト値より大きい（これは、トランザクション要求信号４６０をターゲットの送受信デバイス（例えば、４８５）に向けてダウンストリームに中継するためにより多くの時間がかかる可能性があり、及び介在する送受信デバイスを介して、応答をアップストリームに中継するためにより多くの時間がかかる可能性があるためである）。
【００６２】
ステップ２：デイジーチェインに沿った第１のシンクデバイス（例えば、Ｓｉｎｋ ＩＤ又はＭＤＩＤが０である４５５）が、このトランザクション要求パケット（４５０）を受信し、ＤＥＳＴ＿ＩＤフィールド（４５２）をチェックし、このパケットが当該シンクデバイスに宛てられているか、他のシンクデバイスに宛てられているかを判定する。ＤＥＳＴ＿ＩＤがそのＩＤとは異なる場合、当該シンクデバイス（例えば、４５５）は、新たなＡＵＸ＿ＣＨ書込／読出トランザクション要求パケットを生成及び出力することによって、要求をダウンストリームに中継し、及び内部のタイムアウトタイマを開始する。
【００６３】
ステップ３：デイジーチェインに沿った次のシンクデバイス（例えば、Ｓｉｎｋ ＩＤが１である４６５）が、アップストリーム側のシンクデバイス（４５５）によって出力されたトランザクション要求パケットを受信し、この第２のトランザクション要求パケット内のＤＥＳＴ＿ＩＤフィールド４５２が、ＩＤに一致するかを確認する。これがそのＩＤに一致すると、次のシンクデバイス（例えば、４６５）は、その対応するローカルＤＰＣＤレジスタの命令された書込又は読出を実行し、Ｓｉｎｋ＿ＩＤフィールド４６２を応答シンクデバイス（例えば、４６５）のＤＥＳＴ＿ＩＤと同じになるように設定して、ＡＵＸ ＣＨチェインに沿ってアップストリーム方向にＡＵＸ＿ＣＨ応答トランザクションパケット４６０を送り戻す。
【００６４】
ステップ４：アップストリーム方向の次のシンクデバイス（例えば、４５５）は、応答シンクデバイス（例えば、４６５）から応答トランザクションパケットを受信し、ステップ３を繰り返し、同時に、内部のタイムアウトタイマを停止する。そして、アップストリームのシンクデバイス（例えば、シンクＩＤ０を有する４５５）は、応答トランザクションをソースデバイス４２５に転送し、同様に内部のタイムアウトタイマを停止する。
【００６５】
ステップ５：ソースデバイス（４２５）は、中継された応答トランザクションパケット４６０を受信し、これに応答して、内部のタイムアウトタイマを停止する。そして、ソースデバイスは、対応する内部ＧＰＵ（例えば、４３１〜４３４）による使用及び／又はホストコンピュータ（例えば、図３の２２０’）へのアップロードのために、ソースデバイス内の適切なＤＰＣＤ／ＥＤＩＤ保存メモリ領域（例えば、４１１〜４１４）に受信データ４６７を中継する。
【００６６】
５．２ ホットプラグ検出
５．２．１ 単一のソースデバイス及び単一のシンクデバイス：この場合、ＨＤＰ検出処理は、例えば、図４のＨＤＰライン４４６上で直接的にＨＤＰライントグルが検出される本来のＶＥＳＡ−ＤＰ ＨＰＤ処理と同じである。
【００６７】
５．２．２ 単一のソースデバイス及び２つのシンクデバイス：この場合、以下のようなＨＤＰトグル中継処理が実行される。
【００６８】
ステップ０：チェイン内の２つのシンクデバイスのＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤは、パネルボタンを介して手動で、又はＥＤＩＤを介して自動的に、異なる値に設定する必要がある。ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴフィールドも「１」に設定する必要がある。
【００６９】
ステップ１：ソースデバイスのブートアップの後に、ＨＤＰライントグルのために、ホットプラグイベント（hot plug true event）が最初に検出されると、ソースデバイス（４２５）は、そうでない場合であっても、ＨＤＰトグルが、デイジーチェインにおける最もアップストリームのシンクデバイス（例えば、シンク０）から発せられたと仮定し、そして、ソースデバイス（４２５）は、本来のＡＵＸ＿ＣＨトランザクションシンタクスを用いて、シンク０の受信能力フィールド（ＤＰＣＤの０００００ｈから００００Ｂｈ）、そのシンク／リンクステータスフィールド（ＤＰＣＤの００２００ｈから００２０５ｈ）及びそのシンク特定フィールド（ＤＰＣＤの００４００ｈから００４１１ｈ）を応答的に読み出す。
【００７０】
ステップ２：ソースデバイス（４２５）が、ダウンストリームのローカルＤＰＣＤレジスタ（例えば、３６５ｃ）内で、真のＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴビット（ＤＰＣＤ００４０３のビット１：０における「１０」＝ここに開示するワイドパイプＭＤＩＤターゲット化スキームに基づくデイジーチェインに拡張されたＡＵＸ＿ＣＨシンタクスをサポートする。）を検出すると、ソースデバイスは、まず、本来のＡＵＸ＿ＣＨトランザクションプロセスを用いながら、ソース特定フィールド（ＤＰＣＤ００３０３ｈ）のビット１：０を「１０」に設定する。そして、ソースデバイス及びシンクデバイスは、何れも、ここに開示するワイドパイプＭＤＩＤターゲット化スキームのためのそれぞれの拡張ＡＵＸ＿ＣＨトランザクション機能をイネーブルにする。この後、全てのＡＵＸ＿ＣＨトランザクションは、トランザクション要求信号４５０内にＤＥＳＴ＿ＩＤフィールド４５２を含む拡張ＡＵＸ＿ＣＨトランザクションシンタクスを用いて実行される。
【００７１】
ステップ３：ソースデバイスが、Ｉ２Ｃ−ｏｖｅｒ−ｅｘｔ ＡＵＸ＿ＣＨトランザクションを用いて、新たに追加された（ホットプラグインされた）シンクデバイスのＥＤＩＤデータを読み出し、これは、トランザクション要求信号におけるＤＥＳＴ＿ＩＤフィールド４５２の使用も含む。
【００７２】
ステップ４：ソースデバイスがホットプラグ検出された新たなシンクデバイス（この時点では、４５５のみであるが、後に４６５等も含まれる。）のそれぞれについてリンクトレーニング（link training）を開始する。このリンクトレーニングは、共にパックされるレーン（通常、４つのレーン全て）の整列及びエラーレートのクリア（error rate clearing）を含む。各送受信デバイスは、レーン整列を目的として、各ビデオレーンに関連する遅延を微調整する可変信号遅延手段（明示的には示していない）を含み、これにより、各レーンのケーブルが異なる長さであっても、同じローカルモニタのビデオ情報を搬送するレーン間のタイミングスキューが最小化される。共にパックされるレーンは、１つのビデオフレームのビデオストリームデータを搬送するレーンであり、タイミングスキューを許容可能な公差内に低減しないと、タイミングスキューがビデオモニタ上の顕著な歪みを引き起こすおそれがある。
【００７３】
ステップ５：一旦、全てのアクティブレーンについてレーン整列が完了すると、ソースデバイス（４２５）は、これまでにデイジーチェイン内で発見されたホットプラグ検出されたシンクデバイスへのアクティブなメインリンクの一部を構成するものとして、整列されたレーンをアクティブ化する。標準ＶＤＰプロトコルでは、アクティブなメインリンクを定義するレーンの数は、１個、２個又は４個にすることができ、３個にすることはできない。一方、本発明では、このような規格に制限される必要はなく、所与のソースデバイスの現在のメインリンクセット内のアクティブレーンとして、適切な如何なる数のアクティブレーンを含ませても、本発明の範囲内である。
【００７４】
ステップ６：ソースと、チェイン内の最初のシンクデバイス（シンク０）との間の通常のネイティブモードのインプリメンテーションの間に、現在の、よりアップストリームのデイジーチェインデバイス（例えば、４５５）が、次のダウンストリームのデバイス（例えば、４６５）からホットプラグイベントを検出した場合、シンク０デバイスは、自らがソースデバイスであるかのように、上述したステップ１、２を繰返し、これによって、自ら（シンク０デバイス）と、次のダウンストリームのシンクデバイス（４６５）との間の拡張ＡＵＸ＿ＣＨ接続をイネーブルにする。
【００７５】
ステップ７：ステップ６の後に、シンク０デバイスは、ＨＤＰライン４４６上のソースデバイスへの更なるホットプラグイベントを生成する（ＨＤＰラインを２ｍｓ以上、０に遷移させ、再び１に戻す）。
【００７６】
ステップ８：ステップ７に応じて、ソースデバイスは、上述したステップ１を繰り返す。シンク／リンクステータスフィールドが全て正常（all okay）である場合、例えば、レーンの整列が成功したことが示された場合、ソースデバイス４２５は、ＤＥＳＴ＿ＩＤ＝１を含む拡張ＡＵＸ＿ＣＨトランザクション要求４５０を発行し、シンク１デバイスのためにステップ２を繰り返す。
【００７７】
ステップ９：シンク１（４６５）のシンク／リンクステータスフィールドが正常ではない（not okay）場合、ソースデバイス４２５は、ステップ４を繰り返し、そのメインリンク（アクティブなシリアルリンク）を新たに追加されたシンク１デバイス（４６５）に拡張するための再初期化を試みる。
【００７８】
ステップ１０：一旦、レーン整列が完了すると、ソースデバイスは、ソースデバイスとシンク１デバイスとの間でメインリンクをアクティブ化し、これらのアクティブ化されたメインリンクは、シンクデバイス０をパススルーする。（例えば、図４の黒い矢印は、４レーン幅データバーストのデバイス４５５を通過するパススルー及びこれに続くデバイス４６５におけるキャプチャを示している。図４のデバイス４７５内に示すパススルーの黒い矢印は、バーストをキャプチャするデバイス４６５が、キャプチャしたデータバーストを、ＭＤＩＤ値が一致すればダウンストリームの他のシンクデバイスでもキャプチャできるように、デイジーチェインに沿ってダウンストリームに転送もしていることを示している。）
５．２．３ 単一のソースデバイス及び２個より多いシンクデバイス：単一のソースデバイス（４２５）及びチェイン上に２個より多いシンクデバイス（例えば、図４の４５５、４６５、４７５）がある場合、以下のようなＨＤＰ中継処理が行われる。
【００７９】
ステップ０：全てのシンクデバイスのＳＩＮＫ＿ＤＥＶＩＣＥ＿ＩＤは、パネルボタンを介して手動で、又はＥＤＩＤを介して自動的に設定する必要がある。また、ＤＡＩＳＹ＿ＣＨＡＩＮ＿ＳＵＰＰＯＲＴフィールドも「１０」に設定する必要がある。
【００８０】
ステップ１：ソースデバイスは、シンクデバイス間の全てのメインリンクが整列され、アクティブ化されるまで、上のセクション５．１．２のステップ１〜５を繰返し実行する。
【００８１】
ステップ２：ソースデバイス（４２５）において、ソースデバイス（４２５）に中継されるＨＤＰトグルによってホットアンプラグイベントが検出され、及びそのローカルＤＰＣＤ及びＥＤＩＤレジスタ（例えば、３６５ｅ、３６５ｆ）を読み出すことができないために、以前にチェイン内にあった１つ以上のデバイスがチェイン内にないことをソースデバイスが発見すると、ソースデバイスは、残っている全てのダウンストリームメインリンクが再整列され、アクティブ化されるまでステップ１を繰り返す。例えば、シンク１が切断（unplugged）され、再接続（re-plugged）されると、ソースとシンク１、２、３等との間の全てのメインリンクが壊れる。ソースデバイスは、全てのダウンストリームシンクデバイス間の全てのメインリンクがアクティブ化されるまで、ステップ１を繰り返す。したがって、ホットアンプラグ及び再プラグは、最もダウンストリームの端部だけではなく、デイジーチェイン内のどこで発生してもよい。
【００８２】
５．３ メインリンク
標準ＶＤＰプロトコルでは、所与のソースデバイスのアクティブ化されたメインリンクセットは、デイジーチェイン内のシンクデバイスの数に応じて、トップの１個、２個又は４個のレーンとして構成できる。なお、上述したように、本発明では、アクティブレーンの数は、好ましくは、４個に設定されるが、必ずしもこの規格に制限されるわけではなく、この結果、他の環境においては、所与のソースデバイスのアクティブ化されたメインリンクセットは、期待される最高のビデオ解像度及びデイジーチェイン内のモニタの予想される最大数（例えば、最大２５５）をサポートするのに必要な最大帯域幅に応じて、所与の用途において適切となるように、アクティブな整列されたリンクの他の数値的及び空間的な構成に構成できる。
【００８３】
図３から、一実施の形態では、各Ｐｈｙ Ｒｘユニット（例えば、３５１ａ〜３５４ａ）又は対応するデータプロセッサ３６９ａ内に設けられた信号デシリアライザに加えて、各送受信可能シンクデバイスは、ダウンストリーム側の次のシンクデバイスにメインリンクビデオ及び／又は他のバーストデータを中継するために、例えば、それぞれＰｈｙ Ｔｘユニット（例えば、３８１ａ〜３８４ａ）の一部として設けられた微調整可能な遅延器と共に、４個のシリアル信号増幅バッファ３６１ａ〜３６４ａを有することができることがわかる。送受信可能シンクデバイス（例えば、３５５、３６５）のそれぞれは、よりダウンストリーム又はよりアップストリームの送受信可能シンクデバイス、若しくは最もアップストリームのソースデバイス（３２５）にシリアルＡＵＸ ＣＨデータを双方向に中継するために更に２対の補助チャネルデシリアイザ及びシリアライザを有する。アクティブなシンクデバイスのそれぞれは、そのローカルのアクティブな数（通常４個）の入力レーンを内部のローカルバス（例えば、３７０Ａ、３７０Ｂ）に、及びここから、それぞれのローカルモニタ（例えば、２５０’、２６０’）に接続する。図４は、このような接続を行っているデバイス４６５を示している。各シンクデバイスのデータ処理ユニット（例えば、３６９ａ、３６９ｂ）は、ローカルポリシメーカ（例えば、３６５ａ、３６５ｂ）から送信されたコマンドに基づいて動作し、対応するＰｈｙ Ｒｘユニット（例えば、３５１ａ〜３５４ａ）が受信したビデオデータを、共通のルーティングバス（例えば、３７０Ａ）を介してローカルモニタに接続するか、及びその場合、どのようなデシリアライズ規則に基づいて動作するかを判定する。例えば、（以下に説明する）図５Ａのフィールド５３０の場合、連続する画素が、４つのレーンに亘って、ラウンドロビン方式で連続的に配信されていることがわかる。
【００８４】
図５Ａには、本発明に基づき、４レーン幅シリアルデータストリーム５０１にＭＤＩＤビット（フィールド５２０）を選択的に埋め込む１つのスキーム５００を示している。４つのレーンは、通常、ここに示すように同期されるが、これは必ずしも必要ではない。レーンが互いに厳密に同期されていない場合、送受信デバイスのデータプロセッサが、シリアル送信されたストリームから、ビデオ又はオーディオデータブロックの構築を開始する前に、図に示すようにストリームを同期させるために、送受信デバイスデータプロセッサ（例えば、３６９ａ、３６９等）内に適切なデータバッファリング及びシリアルストリーム再同期手段を設ける必要がある。図５Ａの行５０９に示すように、ビデオブランク期間（例えば、水平帰線消去期間又は１Ｈ）の最後に、各レーンにおいて、ＶＤＰによって定義されたキャラクタ（ブランクエンド（Blank End）キャラクタ）を送信する。これに続いて、予め定義されたＭＤＩＤ値を有するモニタの表示ライン番号Ｎ−１のビデオ画素が供給される。行番号Ｎ−１のビデオ画素の送信が完了すると、オプションとして、データブロック５１０の最後を全て０バイトでパディングし、５１２に示すように、４つのレーンに亘って、４つのＶＤＰ ＢＳキャラクタ（ブランク開始（Blank Start）キャラクタ）が出力される。
【００８５】
次に、同期された行５１４に沿って、ＶＤＰプロトコルに基づいて、対応するビデオブランキング識別バイト（ＶＢ−ＩＤ）が出力され、ここで、このようなＶＢ−ＩＤバイトのそれぞれのビット０：５は、対応するＩＤ値を提供する。なお、ビット７：７が常にゼロである従来の手法とは異なり、本発明では、ビット７：７が論理値「１」である場合（ボックス５１５参照）、これは、従来のＭａｕｄバイト５１８の後にＭＤＩＤバイトが挿入されることをシグナリングしている。ビット７：７が論理値「０」である場合、オプションのＭＤＩＤバイト５２０は、挿入されず、従来のＶＤＰプロトコルに基づき、各レーンにおいて、Ｍａｕｄバイト５１８の直後にオーディオデータブロック５２２が続く。ＶＢ−ＩＤバイト５１４内にＭＤＩＤ挿入フラグ（ビット７：７）を設けることによって、送受信デバイスのプロセッサ（例えば、３６９ａ）に、オプションのＭＤＩＤバイト５２０が出現する前にＶＢ−ＩＤバイト５１４を処理するためのＴ１の時間遅延を与えることができる。オプションのＭＤＩＤバイト５２０内の識別値がローカルモニタのディスプレイモニタＩＤ値に一致する場合、送受信デバイスのプロセッサ（例えば、３６９ａ）は、これに続くオーディオ（５２２）及びビデオ（５３０）シリアルデータを、処理及びローカルモニタ（例えば、２５０’）への転送のために、そのローカルバッファ内にコピーする。ＭＤＩＤバイト５２０がローカルモニタのディスプレイモニタＩＤ値（又はローカルモニタを含むマルチキャストグループ値）に一致しない場合、送受信デバイスのプロセッサ（例えば、３６９ａ）は、パススルーされるオーディオ（５２２）及びビデオ（５３０）シリアルデータを無視する。図５Ａの行５２９に示すように、ビデオブランク期間（例えば、水平帰線消去期間又は１Ｈ）の最後に、各レーンにおいて、ＶＤＰによって定義されたキャラクタ（ブランクエンド（Blank End）キャラクタ）を再び送信する。これに続いて、行５２０のＭＤＩＤ信号によって定義される予め定義されたＭＤＩＤ値を有するモニタ（又はモニタのマルチキャストグループ）の表示ライン番号Ｎのビデオ画素が供給される。行番号Ｎのビデオ画素の送信が完了すると、オプションとして、データブロック５３０の最後を全て０バイトでパディングし、５３２に示すように、４つのレーンに亘って、４つのＶＤＰ ＢＳキャラクタ（ブランク開始（Blank Start）キャラクタ）が出力される。そして、処理は、４つのシリアル送信レーンに亘って現れる５１４と同様の他の行について繰り返してもよい。
【００８６】
図５Ｂに示すように、二次データを対応するＭＤＩＤ値に論理的に関連付けるために、同様のスキーム５５０を用いてもよい。行５６４のＶＢ−ＩＤバイトのそれぞれのビット７：７が論理値「１」である場合、オプションとして、行５７０にＭＤＩＤバイトが挿入される。この他の場合、オプションのレーン０〜３（５５１）のシリアル送信ストリーム内にＭＤＩＤバイト行５７０は、出現しない。一致するＭＤＩＤ値を有する送受信デバイスのプロセッサ（例えば、３６９ａ）による処理のために宛てられた二次データは、行５７９の二次データ開始フラグキャラクタ（Start of Secondary data flag character：ＳＳ）の後に開始され、行５８２の二次データ終了フラグキャラクタ（End of Secondary data flag character：ＳＥ）で終了する。行５７９〜５８２は、ダミーのキャラクタが埋められたブロック５７２、５８４によって挟み込んでもよい。行５０９’の後に行５７０のＭＤＩＤに一致するモニタのためのビデオ画素データ５１０’が始まる。このように、二次データ５８０は、ビデオラインデータ５１０’にインタレースして、一致するＭＤＩＤ値を有する１つ以上のモニタに宛てることができる。
【００８７】
この説明は、例示的なものであり、特許請求する主題の範囲、性質又は思想を制限するものではない。この説明の開示によって、様々な修正及び変更は、当業者にとって明らかであり、これらには、ここに開示した要素と同等な機能的及び／又は構造的均等物の使用、ここに開示した組合せと均等な機能的組合せの使用、及び／又はここに開示したステップと均等な機能的ステップの使用が含まれる。このような実質的ではない変更は、ここで説明した発明の範囲に含まれる。更に、特定の手段又はステップについて複数の具体例を提示している場合、及びこの開示から、このような具体例の間の及び／又はこのような具体例を越える類推が自明である場合、本明細書は、少なくともこのような類推を効果的に開示し、したがって包含しているものとみなされる。
【００８８】
一例として、本発明に基づくソースデバイス（例えば、図３の３２５）及び／又は送受信デバイス（例えば、図３の３５５）の構成は、コンピュータ（例えば、図３の２２０’）又は他の外部の命令デバイスを使用して、様々なビデオストリーム生成器（例えば、３３１〜３３Ｅ）のアクティブ化又は非アクティブ化を選択的に制御すること、及び／又は各送受信デバイスのローカルデータ処理デバイス（例えば、３６９ａ、３６９ｂ）のそれぞれによる、シリアル受信ビットのマッピングを望まれるように選択的に制御することを含んでもよいことは明らかである。コンピュータが読取可能な媒体（図示せず）又は他の形式のソフトウェア製品又はマシン命令手段（以下に限定されるものではないが、ハードディスク、コンパクトディスク、フラッシュメモリスティック、製品としての命令信号のネットワークを介するダウンロード及びこれらに類するもの）を用いて、命令可能なマシン（例えば、２２０’）に命令して、このような選択的なアクティブ化及び非アクティブ化プロセスを望まれるように実行させてもよい。例えば、図３では、アップストリームのデバイスが、欠陥があるレーンがあり、したがって、そのレーンを介して次のダウンストリームデバイスにビデオデータをパススルーしない場合、欠陥があるレーンをシャットオフし、又は所与のデイジーチェイン内の送受信デバイスのそれぞれのＰｈｙ Ｔｘユニットの１つをパワーダウンすることによって消費電力を最小化することが望ましい場合があり、この結果、全体の消費電力を低減できる。すなわち、ホストコンピュータ内のソフトウェアが、ある時点で、デイジーチェインを構成するレーンの１つ以上を介して、ビデオデータが有効に送信されていないことを示した場合、ホストコンピュータは、現在サービスが必要でないビデオデータ出力回路のパワーダウンを選択的に命令することができ、これによって電力を節約することができる。このため、上述したデフォルトの４レーン幅バーストモードから変形されたマシン実装方法を命令可能なマシン（例えば、２２０’）に実行させ、及び／又は命令可能なマシンにマシン実装方法を実行させる補助的なソフトウェアを提供することは、本発明の範囲内にある。
【００８９】
付加的な特許権の留保、矛盾の解決及び用語の解釈
本明細書が法律に則って公開された後、本出願の譲受人は、他者がここに含まれる文章及び図面の素材を複製することについて、このような複製が本明細書の発明を理解し、これによって、有用な技術及び科学の発展を促進することを目的とする限りにおいて、異論を唱えない。但し、譲受人は、ここに開示した素材に法的に関連する可能性がある他の如何なる権利も放棄せず、このような権利には、以下に限定されるものではないが、あらゆるコンピュータプログラムリスティング、図表又はここに提示したこの他の記載に関する著作権、ここに提示した造語又は図表に関連する可能性がある商標又はトレードドレス権、及びここに含まれ又はここから導出可能な、この他の保護可能な主題に関する権利が含まれる。
【００９０】
何らかの開示が引用によってここに援用されており、このような援用された開示が、本開示と部分的又は全体的に矛盾する場合、矛盾する範囲、及び／又はより広い開示、及び／又はより広い用語の定義は、本明細書を基準とする。このような援用された開示が互いに部分的又は全体的に矛盾する場合、矛盾する範囲は、日付が新しい開示を基準とする。
【００９１】
ここに明示的に述べていない限り、通常の用語は、それぞれが使用されているそれぞれの文脈内で対応する通常の意味を有し、通常の技術用語は、関連する技術分野内で、及びここでそれぞれが使用されているそれぞれの文脈内で対応する通常の意味を有する。関連技術に関する上述の記述は、本明細書が最も密接に関係する技術分野の当業者が技術又は可能な技術間の関係を想到できたことを認めるものではない。
【００９２】
上述した一般概念及び特定の実施の形態の開示に基づき、要求される保護の範囲は、添付の特許請求の範囲によって定義される。発行された特許請求の範囲は、出願人の権利を、開示した特許請求の範囲のみに限定するものではなく、出願人の権利は、米国特許法第１２０条及び／又は米国特許法第２５１条に従って出願される更なる１つ以上の出願によって、ここでは文言として請求していない主題にも及ぶ。
【特許請求の範囲】
【請求項１】
受信したビデオ信号によって表現される画像を表示するためのビデオディスプレイ装置において、
（ａ）対応する第１の複数のレーンを介してシリアル送信された、前記ビデオディスプレイ装置によって表示され、又は表示されないビデオ画像の少なくとも一部を表す第１の複数のデジタル信号を受信するように構成された第１のポートと、
（ｂ）対応する第２の複数のレーンを介してシリアル送信された、ビデオ画像の少なくとも一部を表す第２の複数のデジタル信号を出力するように構成された第２のポートと、
（ｃ）前記第１のポート及び前記第２のポートに接続され、パススルーバッファを含み、前記シリアル送信されたデジタル信号を、前記第１のポートから前記第２のポートに中継する中継回路と、
（ｄ）前記パススルーされるシリアル送信されたデジタル信号のそれぞれに埋め込まれているマルチデバイス識別（multi-device identification：ＭＤＩＤ）信号に応じて、前記パススルーされるシリアル送信されたデジタル信号を選択的に処理する選択的データ処理手段とを備えるビデオディスプレイ装置。
【請求項２】
前記第１のポートは、ＶＥＳＡ−ＤｉｓｐｌａｙＰｏｒｔに互換性がある第１のインタフェースプラグを含み、
前記第２のポートは、ＶＥＳＡ−ＤｉｓｐｌａｙＰｏｒｔに互換性がある第２のインタフェースプラグを含む請求項１記載のビデオディスプレイ装置。
【請求項３】
前記選択的データ処理手段に動作的に接続され、前記データ処理手段によって選択的に処理される前記シリアル送信された第１の複数のデジタル信号を表す前記ビデオ画像の少なくとも一部を表示するローカルモニタを更に備える請求項２記載のビデオディスプレイ装置。
【請求項４】
前記中継回路は、前記ビデオディスプレイ装置と同様の第２のビデオディスプレイ装置が、前記第２のポートにデイジーチェイン方式で接続されたことを検出できるホットプラグ検出器を含む請求項１記載のビデオディスプレイ装置。
【請求項５】
前記中継回路は、シリアル補助チャネルデータを双方向に中継できる補助チャネルリレーを含み、前記中継される補助チャネルデータは、前記補助チャネルリレーによって定義されるデイジーチェイン通信回路に動作的に接続することができる１つ以上のローカルモニタの少なくとも１つの物理的属性を示すＥＤＩＤデータを含む請求項１記載のビデオディスプレイ装置。
【請求項６】
少なくともビデオ画像の一部を表す第１の複数のシリアル送信されたデジタル信号を対応する第１の複数のレーンを介して出力できるビデオソースデバイスに、複数のビデオディスプレイユニットをデイジーチェイン接続するデイジーチェイン接続方法において、
（ａ）前記ビデオソースデバイスが駆動するビデオ信号中継回路に第１のビデオシンクデバイスがデイジーチェイン方式で接続されたことを検出するステップと、
（ｂ）前記第１のビデオシンクデバイスの接続の検出に応じて、前記第１のビデオシンクデバイスから、前記第１のビデオシンクデバイスに関連するローカルディスプレイ機能の特性を暗示するローカル特徴付けデータを自動的にフェッチするステップとを有するデイジーチェイン接続方法。
【請求項７】
前記ローカル特徴付けデータをフェッチするステップは、
前記第１のビデオシンクデバイスに関連する、少なくとも１つのローカルディスプレイモニタの物理的属性を示す、前記第１のビデオシンクデバイス内のローカルＥＤＩＤデータを自動的に読み出すステップを含む請求項６記載のデイジーチェイン接続方法。
【請求項８】
前記ローカル特徴付けデータをフェッチするステップは、
前記第１のビデオシンクデバイスに関連する、少なくとも１つのローカルディスプレイモニタの現在の再構成可能な構成を示す、前記第１のビデオシンクデバイス内のローカルＤＰＣＤデータを自動的に読み出すステップを含む請求項６記載のデイジーチェイン接続方法。
【請求項９】
（ａ）対応する入口シリアルデータリンクを介して、シリアル送信されてきたビデオストリームデータを受信するようにそれぞれ構成された第１の複数のビデオストリームデータ受信機と、
（ｂ）前記第１の複数のビデオストリームデータ受信機に接続され、前記第１の複数のビデオストリームデータ受信機の前記受信したビデオストリームデータのオンザフライで選択された部分をデシリアライズするように構成されたローカルデータプロセッサと、
（ｂ）前記ビデオストリームデータ受信機の対応する１つによって出力されたビデオストリームデータを受信し、前記ビデオストリームデータをバッファリングするようにそれぞれ接続及び構成された第２の複数のビデオストリームデータバッファと、
（ｃ）前記ビデオストリームデータバッファの対応する１つから、バッファリングされたシリアルデータを受信し、対応する出口シリアルデータリンクを介して、前記バッファリングされたシリアルデータを中継するようにそれぞれ接続及び構成された第３の複数のビデオストリームデータ送信機と、
（ｄ）前記ローカルデータプロセッサに接続され、前記パススルーされるビデオデータのオンザフライで選択及びデシリアライズされた部分をローカルディスプレイモニタに転送するように構成されたローカル出力ポートとを備えるデイジーチェイン送受信デバイス。
【請求項１０】
（ｅ）ローカルＤＰＣＤデータ及びローカルＥＰＩデータを保存するように構成されたローカルポリシメーカと、
（ｆ）前記ローカルポリシメーカに接続され、前記デイジーチェイン送受信デバイスのアップストリーム及びダウンストリームに補助チャネルデータを中継するように構成された補助チャネルデータ送受信機とを更に備える請求項９記載のデイジーチェイン送受信デバイス。
【請求項１１】
（ｅ．１）前記ローカルポリシメーカは、前記デイジーチェイン送受信デバイスが拡張ＡＵＸ＿ＣＨシンタクスを現在実装しているか否かを示す拡張シンタクスフラグを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１２】
（ｅ．１）前記ローカルポリシメーカは、前記デイジーチェイン送受信デバイスがシンクデバイスとして接続されているデイジーチェインに沿って、前記デイジーチェイン送受信デバイスを他のシンクデバイスから識別する一意的なデバイス識別情報を前記デイジーチェイン送受信デバイスに提供できるシンクデバイス識別フィールドを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１３】
前記シンクデバイス識別フィールドは、少なくとも５つの一意的に識別可能なシンクデバイス又はビデオデータの少なくとも５つの一意的に識別可能なバンドをサポートできる請求項１２記載のデイジーチェイン送受信デバイス。
【請求項１４】
（ｅ．１）前記ローカルポリシメーカは、前記デイジーチェイン送受信デバイスを、他の一意的に識別可能なユニットの予め定義された組織内の組織的なユニットとして一意的に識別するための２４ビットユニット識別フィールドを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１５】
（ｆ．１）前記補助チャネルデータ送受信機は、ホットプラグ検出信号を、ダウンストリームシンクデバイスから、前記デイジーチェイン送受信デバイスが含まれるデイジーチェインに沿って、アップストリームのデバイスに中継するように更に構成されている請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１６】
（ｅ．１）前記ローカルポリシメーカは、コマンドパケットに応答して、前記コマンドパケットが、コマンドのターゲットとして、前記デイジーチェイン送受信デバイスを宛先とする宛先識別フィールドを含んでいる場合、１つ以上の補助チャネルデータ送受信機を介して、前記コマンドパケットを中継するように構成されている請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１７】
（ｅ．１）前記ローカルポリシメーカは、その補助チャネルデータ送受信機の１つを介して、前記コマンド応答パケットのソースとして前記デイジーチェイン送受信デバイスを指定するシンクデバイス識別フィールドを含むコマンド応答パケットを出力するように構成されている請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１８】
（ａ）シリアル送信のためのビデオストリームデータを、対応する複数の出口シリアルデータリンクを介する複数のシリアル信号のバーストとして編成するようにそれぞれ構成された第１の複数の現実又は仮想のビデオストリームデータ生成器と、
（ｂ）前記複数のシリアル信号のバーストとして編成された前記シリアル送信のためのビデオストリームデータを、対応する複数の出口シリアルデータリンクに亘ってパックするデータパッカと、
（ｃ）前記現実又は仮想のビデオストリームデータ生成器の１つにそれぞれ接続され、前記シリアル送信のためのビデオストリームデータの編成を制御するように構成された第２の複数のビデオデータストリーム制御ユニットであって、前記編成は、前記ビデオデータストリームによって表される画像又は画像の一部を表示することを意図するターゲットディスプレイモニタと互換性があり、前記ビデオデータストリーム制御ユニットは、異なるターゲットディスプレイモニタをサポートするようにプログラミング可能である第２の複数のビデオデータストリーム制御ユニットと、
（ｄ）複数のデイジーチェイン接続されたモニタユニットからローカルＤＰＣＤデータ及びローカルＥＰＩデータを読み出し、前記読み出したＤＰＣＤデータ及びＥＰＩデータを、前記第２の複数のビデオデータストリーム制御ユニットに保存するように構成されたソース側ポリシメーカとを備えるデイジーチェインサポートソースデバイス。
【請求項１９】
（ｅ）前記ソース側ポリシメーカ及び前記第１の複数のビデオストリームデータ生成器に動作的に接続され、外部ホストデバイスが、前記ビデオストリームデータ生成器にビデオデータをダウンロードでき、前記ソース側ポリシメーカとインタラクトできるようにするホストインタフェースポートを更に備える請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２０】
前記ビデオストリームデータ生成器の少なくとも１つは、グラフィックデータプロセッサ及びビデオデータストレージメモリの組合せによって実現されている請求項１９記載のデイジーチェインサポートソースデバイス。
【請求項２１】
（ｃ．１）前記ソース側ポリシメーカは、前記デイジーチェインサポートソースデバイスが拡張ＡＵＸ＿ＣＨシンタクスを現在実装しているか否かを示す拡張シンタクスフラグを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２２】
（ｃ．１）前記ソース側ポリシメーカは、前記デイジーチェインサポートソースデバイスを、他の一意的に識別可能なユニットの予め定義された組織内の組織的なユニットとして一意的に識別するための２４ビットユニット識別フィールドを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２３】
（ｃ．１）前記ソース側ポリシメーカは、補助データチャネルを介して、コマンドパケットに応答することを意図するデイジーチェイン接続されたデバイスを指定する宛先機器識別フィールドをそれぞれ含むコマンドパケットを出力するように構成されている請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２４】
（ｃ．２）前記ソース側ポリシメーカは、前記補助データチャネルを介して、コマンド応答パケットのソースであるデイジーチェイン接続されたデバイスを指定する応答側識別フィールドを含むコマンド応答パケットを受信するように構成されている請求項２３記載のデイジーチェインサポートソースデバイス。
【請求項１】
受信したビデオ信号によって表現される画像を表示するためのビデオディスプレイ装置において、
（ａ）対応する第１の複数のレーンを介してシリアル送信された、前記ビデオディスプレイ装置によって表示され、又は表示されないビデオ画像の少なくとも一部を表す第１の複数のデジタル信号を受信するように構成された第１のポートと、
（ｂ）対応する第２の複数のレーンを介してシリアル送信された、ビデオ画像の少なくとも一部を表す第２の複数のデジタル信号を出力するように構成された第２のポートと、
（ｃ）前記第１のポート及び前記第２のポートに接続され、パススルーバッファを含み、前記シリアル送信されたデジタル信号を、前記第１のポートから前記第２のポートに中継する中継回路と、
（ｄ）前記パススルーされるシリアル送信されたデジタル信号のそれぞれに埋め込まれているマルチデバイス識別（multi-device identification：ＭＤＩＤ）信号に応じて、前記パススルーされるシリアル送信されたデジタル信号を選択的に処理する選択的データ処理手段とを備えるビデオディスプレイ装置。
【請求項２】
前記第１のポートは、ＶＥＳＡ−ＤｉｓｐｌａｙＰｏｒｔに互換性がある第１のインタフェースプラグを含み、
前記第２のポートは、ＶＥＳＡ−ＤｉｓｐｌａｙＰｏｒｔに互換性がある第２のインタフェースプラグを含む請求項１記載のビデオディスプレイ装置。
【請求項３】
前記選択的データ処理手段に動作的に接続され、前記データ処理手段によって選択的に処理される前記シリアル送信された第１の複数のデジタル信号を表す前記ビデオ画像の少なくとも一部を表示するローカルモニタを更に備える請求項２記載のビデオディスプレイ装置。
【請求項４】
前記中継回路は、前記ビデオディスプレイ装置と同様の第２のビデオディスプレイ装置が、前記第２のポートにデイジーチェイン方式で接続されたことを検出できるホットプラグ検出器を含む請求項１記載のビデオディスプレイ装置。
【請求項５】
前記中継回路は、シリアル補助チャネルデータを双方向に中継できる補助チャネルリレーを含み、前記中継される補助チャネルデータは、前記補助チャネルリレーによって定義されるデイジーチェイン通信回路に動作的に接続することができる１つ以上のローカルモニタの少なくとも１つの物理的属性を示すＥＤＩＤデータを含む請求項１記載のビデオディスプレイ装置。
【請求項６】
少なくともビデオ画像の一部を表す第１の複数のシリアル送信されたデジタル信号を対応する第１の複数のレーンを介して出力できるビデオソースデバイスに、複数のビデオディスプレイユニットをデイジーチェイン接続するデイジーチェイン接続方法において、
（ａ）前記ビデオソースデバイスが駆動するビデオ信号中継回路に第１のビデオシンクデバイスがデイジーチェイン方式で接続されたことを検出するステップと、
（ｂ）前記第１のビデオシンクデバイスの接続の検出に応じて、前記第１のビデオシンクデバイスから、前記第１のビデオシンクデバイスに関連するローカルディスプレイ機能の特性を暗示するローカル特徴付けデータを自動的にフェッチするステップとを有するデイジーチェイン接続方法。
【請求項７】
前記ローカル特徴付けデータをフェッチするステップは、
前記第１のビデオシンクデバイスに関連する、少なくとも１つのローカルディスプレイモニタの物理的属性を示す、前記第１のビデオシンクデバイス内のローカルＥＤＩＤデータを自動的に読み出すステップを含む請求項６記載のデイジーチェイン接続方法。
【請求項８】
前記ローカル特徴付けデータをフェッチするステップは、
前記第１のビデオシンクデバイスに関連する、少なくとも１つのローカルディスプレイモニタの現在の再構成可能な構成を示す、前記第１のビデオシンクデバイス内のローカルＤＰＣＤデータを自動的に読み出すステップを含む請求項６記載のデイジーチェイン接続方法。
【請求項９】
（ａ）対応する入口シリアルデータリンクを介して、シリアル送信されてきたビデオストリームデータを受信するようにそれぞれ構成された第１の複数のビデオストリームデータ受信機と、
（ｂ）前記第１の複数のビデオストリームデータ受信機に接続され、前記第１の複数のビデオストリームデータ受信機の前記受信したビデオストリームデータのオンザフライで選択された部分をデシリアライズするように構成されたローカルデータプロセッサと、
（ｂ）前記ビデオストリームデータ受信機の対応する１つによって出力されたビデオストリームデータを受信し、前記ビデオストリームデータをバッファリングするようにそれぞれ接続及び構成された第２の複数のビデオストリームデータバッファと、
（ｃ）前記ビデオストリームデータバッファの対応する１つから、バッファリングされたシリアルデータを受信し、対応する出口シリアルデータリンクを介して、前記バッファリングされたシリアルデータを中継するようにそれぞれ接続及び構成された第３の複数のビデオストリームデータ送信機と、
（ｄ）前記ローカルデータプロセッサに接続され、前記パススルーされるビデオデータのオンザフライで選択及びデシリアライズされた部分をローカルディスプレイモニタに転送するように構成されたローカル出力ポートとを備えるデイジーチェイン送受信デバイス。
【請求項１０】
（ｅ）ローカルＤＰＣＤデータ及びローカルＥＰＩデータを保存するように構成されたローカルポリシメーカと、
（ｆ）前記ローカルポリシメーカに接続され、前記デイジーチェイン送受信デバイスのアップストリーム及びダウンストリームに補助チャネルデータを中継するように構成された補助チャネルデータ送受信機とを更に備える請求項９記載のデイジーチェイン送受信デバイス。
【請求項１１】
（ｅ．１）前記ローカルポリシメーカは、前記デイジーチェイン送受信デバイスが拡張ＡＵＸ＿ＣＨシンタクスを現在実装しているか否かを示す拡張シンタクスフラグを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１２】
（ｅ．１）前記ローカルポリシメーカは、前記デイジーチェイン送受信デバイスがシンクデバイスとして接続されているデイジーチェインに沿って、前記デイジーチェイン送受信デバイスを他のシンクデバイスから識別する一意的なデバイス識別情報を前記デイジーチェイン送受信デバイスに提供できるシンクデバイス識別フィールドを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１３】
前記シンクデバイス識別フィールドは、少なくとも５つの一意的に識別可能なシンクデバイス又はビデオデータの少なくとも５つの一意的に識別可能なバンドをサポートできる請求項１２記載のデイジーチェイン送受信デバイス。
【請求項１４】
（ｅ．１）前記ローカルポリシメーカは、前記デイジーチェイン送受信デバイスを、他の一意的に識別可能なユニットの予め定義された組織内の組織的なユニットとして一意的に識別するための２４ビットユニット識別フィールドを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１５】
（ｆ．１）前記補助チャネルデータ送受信機は、ホットプラグ検出信号を、ダウンストリームシンクデバイスから、前記デイジーチェイン送受信デバイスが含まれるデイジーチェインに沿って、アップストリームのデバイスに中継するように更に構成されている請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１６】
（ｅ．１）前記ローカルポリシメーカは、コマンドパケットに応答して、前記コマンドパケットが、コマンドのターゲットとして、前記デイジーチェイン送受信デバイスを宛先とする宛先識別フィールドを含んでいる場合、１つ以上の補助チャネルデータ送受信機を介して、前記コマンドパケットを中継するように構成されている請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１７】
（ｅ．１）前記ローカルポリシメーカは、その補助チャネルデータ送受信機の１つを介して、前記コマンド応答パケットのソースとして前記デイジーチェイン送受信デバイスを指定するシンクデバイス識別フィールドを含むコマンド応答パケットを出力するように構成されている請求項１０記載のデイジーチェイン送受信デバイス。
【請求項１８】
（ａ）シリアル送信のためのビデオストリームデータを、対応する複数の出口シリアルデータリンクを介する複数のシリアル信号のバーストとして編成するようにそれぞれ構成された第１の複数の現実又は仮想のビデオストリームデータ生成器と、
（ｂ）前記複数のシリアル信号のバーストとして編成された前記シリアル送信のためのビデオストリームデータを、対応する複数の出口シリアルデータリンクに亘ってパックするデータパッカと、
（ｃ）前記現実又は仮想のビデオストリームデータ生成器の１つにそれぞれ接続され、前記シリアル送信のためのビデオストリームデータの編成を制御するように構成された第２の複数のビデオデータストリーム制御ユニットであって、前記編成は、前記ビデオデータストリームによって表される画像又は画像の一部を表示することを意図するターゲットディスプレイモニタと互換性があり、前記ビデオデータストリーム制御ユニットは、異なるターゲットディスプレイモニタをサポートするようにプログラミング可能である第２の複数のビデオデータストリーム制御ユニットと、
（ｄ）複数のデイジーチェイン接続されたモニタユニットからローカルＤＰＣＤデータ及びローカルＥＰＩデータを読み出し、前記読み出したＤＰＣＤデータ及びＥＰＩデータを、前記第２の複数のビデオデータストリーム制御ユニットに保存するように構成されたソース側ポリシメーカとを備えるデイジーチェインサポートソースデバイス。
【請求項１９】
（ｅ）前記ソース側ポリシメーカ及び前記第１の複数のビデオストリームデータ生成器に動作的に接続され、外部ホストデバイスが、前記ビデオストリームデータ生成器にビデオデータをダウンロードでき、前記ソース側ポリシメーカとインタラクトできるようにするホストインタフェースポートを更に備える請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２０】
前記ビデオストリームデータ生成器の少なくとも１つは、グラフィックデータプロセッサ及びビデオデータストレージメモリの組合せによって実現されている請求項１９記載のデイジーチェインサポートソースデバイス。
【請求項２１】
（ｃ．１）前記ソース側ポリシメーカは、前記デイジーチェインサポートソースデバイスが拡張ＡＵＸ＿ＣＨシンタクスを現在実装しているか否かを示す拡張シンタクスフラグを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２２】
（ｃ．１）前記ソース側ポリシメーカは、前記デイジーチェインサポートソースデバイスを、他の一意的に識別可能なユニットの予め定義された組織内の組織的なユニットとして一意的に識別するための２４ビットユニット識別フィールドを含むデイジーチェインサポートレジスタを有する拡張ＤＰＣＤレジスタセットを含む請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２３】
（ｃ．１）前記ソース側ポリシメーカは、補助データチャネルを介して、コマンドパケットに応答することを意図するデイジーチェイン接続されたデバイスを指定する宛先機器識別フィールドをそれぞれ含むコマンドパケットを出力するように構成されている請求項１８記載のデイジーチェインサポートソースデバイス。
【請求項２４】
（ｃ．２）前記ソース側ポリシメーカは、前記補助データチャネルを介して、コマンド応答パケットのソースであるデイジーチェイン接続されたデバイスを指定する応答側識別フィールドを含むコマンド応答パケットを受信するように構成されている請求項２３記載のデイジーチェインサポートソースデバイス。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【公表番号】特表２０１１−５２４９９２（Ｐ２０１１−５２４９９２Ａ）
【公表日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願番号】特願２０１１−５０８５０３（Ｐ２０１１−５０８５０３）
【出願日】平成２１年５月５日（２００９．５．５）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００２８１１
【国際公開番号】ＷＯ２００９／１３７０６１
【国際公開日】平成２１年１１月１２日（２００９．１１．１２）
【出願人】（５０８２４９６９７）インテグレーテッド・デバイス・テクノロジー・インコーポレーテッド (6)
【Ｆターム（参考）】
【公表日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願日】平成２１年５月５日（２００９．５．５）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００２８１１
【国際公開番号】ＷＯ２００９／１３７０６１
【国際公開日】平成２１年１１月１２日（２００９．１１．１２）
【出願人】（５０８２４９６９７）インテグレーテッド・デバイス・テクノロジー・インコーポレーテッド (6)
【Ｆターム（参考）】
[ Back to top ]