JP4927348B2 - ビデオ表示ネットワーク管理 - Google Patents

Description

この技術分野は、ビデオ表示アダプタ（コンピュータビデオカードなど）の構成(configuration)に関する。

複数のモニタを使用するコンピュータシステムが普及してきている。例えば、いまや、１台のコンピュータがＬＣＤパネルと映写装置の両方を駆動することは普通である。さらに、コンピュータユーザは、いまや、自分のコンピュータを使用して、日常的にビデオ上映（ＤＶＤなど）を見る。そのような場合、コンピュータは、従来方式のモニタとテレビの両方を駆動することになる。

需要に応えて、ビデオアダプタハードウェア製造者らは、いまや、ビデオアダプタ上に複数の出力を含める。このように、ユーザは、単一出力でのケーブルを切り換えてその出力を再構成することなく、より簡単にコンピュータを使用して所望のデバイスを駆動することができる。

そのようなマルチモニタビデオアダプタは様々な機能を持つが、利用可能な構成は通常限られている。したがって、マルチモニタコンピュータシステムの構成に関連する改善された機能が求められている。

複数の出力を備えるビデオ表示ネットワークを構成することは、可能な構成の絶対数およびリソース間の構成相互依存性のために、困難な問題となり得る。

本明細書で説明する様々な技術を用いて、複数の出力を備えるビデオ表示ネットワークのリソースが構成され得る。例えば、暫定的構成(provisional configuration)がサポートされ得る。入力の構成は、出力の構成とは別に実行され得る。提供されるオプションを暫定的構成と共に動作可能(co-functional with)なものに限定するためにネットワークリソース間の相互依存性が考慮され得る。クライアントは、サービスによって提供される関数の集合を使用して構成解空間(configuration solution space)を行き来する(トラバース：traverse)することができる。可能な構成解のトラバースはバックトラックを含み得る。例えば、バックトラックは、選択された構成オプションが別の所望の構成オプションを無効化するときに使用され得る。暫定的構成機能はトランザクショナル構成手法をサポートすることができ、各リソースは別々に構成され得る。エニュメレーション関数(enumeration function)は、ネットワークリソース間の相互依存性に基づき、暫定的構成と共に動作可能なオプションだけを提供することができる。エニュメレーション(enumeration)されたオプションの妥当性は、ピンニング(ピン設定：pinning)後に保証され得る。

関数(function)は、構成（暫定的構成と共に動作可能な構成など）をエニュメレーションし、リソースをピンニングすることを求める呼び出しを含むインタフェースにグループ化され得る。構成を作成し、その構成をコミット(commit)するための他の呼び出しも設定され得る。関数は、構成へのトランザクショナル手法をサポートすることができる。

構成目標に最も適合するトポロジが相互依存性を考慮して見出され得る。例えば、ターゲットが、それらに接続された表示装置上の優先モードをサポートしなければならないと仮定して、ソース上のサポートされるソースモード集合を最大にするように利用可能なコーデックを介してターゲットからソースまで経路指定する最善の方法が見出され得る。他の目標もサポートされ得る。優先順序付けもサポートされ得る。目標により適合するトポロジの追跡時に、エニュメレーションおよびピンニング機能が使用され得る。

暫定的構成は、異なるリソースを構成することを求める別々のデバイスドライバインタフェース呼び出し（ある呼び出しはビデオ出力を、別の呼び出しはビデオ入力を求めるなど）を介して増分構成をサポートすることができる。呼び出しの間に、エニュメレーションは、残りのピンニングされていない（例えば、まだ暫定的に構成されていない）リソースでの共に動作可能なリソースを指示することができる。

相互依存性を考慮する役割は、ビデオミニポートなどのビデオドライバに委ねる（例えば、それによって実行する）ことができる。クライアントは、様々な手法を使用して所望の構成を見出すことができる。所望の構成は、ＮＰ完全グラフ問題への解(solution)として扱われ得る。

上記その他の特徴および利点は、添付の図面を参照して進められる開示の実施形態の以下の詳細な説明を読めばより明白になるであろう。

（実施例１）
（ビデオ表示ネットワークの例）
図１に、構成可能なビデオ表示ネットワーク１００を示す。本明細書の各例のいずれかで説明する技術を用いてビデオ表示ネットワーク１００が構成され得る。

本明細書で説明する技術と共に使用するためのビデオ表示ネットワーク１００は、１つまたは複数の入力１１０Ａ〜１１０Ｎ（合計Σ個の入力、σなど）、２つ以上の出力１２０Ａ〜１２０Ｎ（合計Τ個の入力、τなど）、および１つまたは複数のディジタルビデオ入力表現／ビデオ出力信号変換器(digital-video-input-representation-to-video-output-signal converters)１３０Ａ〜１３０Ｎ（合計Κ個の変換器、κなど）を備えることができる。

入力１１０Ａ〜１１０Ｎは、「ソース」(sources)または「サーフェス」(surfaces)とも呼ばれる。出力１２０Ａ〜１２０Ｎは、「ターゲット」(targets)とも呼ばれる。ディジタルビデオ入力表現／ビデオ出力信号変換器は、「変換器」(converters)とも呼ばれる。

入力、変換器、および出力以外に、ビデオ表示ネットワークは他のリソース１４０（ビデオメモリ、帯域幅、メモリ容量など）を含むこともできる。その他のリソース１４０は、入力、変換器、および出力によってビデオ表示機能を実現するのに使用され得る。

ビデオ表示ネットワーク１００はビデオ表示アダプタ（例えばビデオカード）などのハードウェアとして実施され得る。場合によっては、いくつかのリソースはアダプタの外部に存在し得る。

例示的コンピュータシステムは、（例えばコンピュータシステムのアプリケーションによって書き込まれる）ディジタル形式の１つまたは複数のビデオビューを含むことができ、それらが入力１１０Ａ〜１１０Ｎによって使用される。結果として複数の出力１２０Ａ〜１２０Ｎから生じる信号を用いて複数のビデオ表示装置が駆動され得る。

（実施例２）
（代替のビデオ表示ネットワークの例）
図２に、別の構成可能なビデオ表示ネットワーク２００を示す。本明細書の各例のいずれかで説明する技術を用いてビデオ表示ネットワーク２００が構成され得る。

この例では、単一のディジタルビデオ入力表現／ビデオ出力信号変換器に複数の入力が使用され得る（例えば、入力２１０Ｂおよび２１０Ｎが変換器２３０Ｎへの入力として使用される）。そのような構成は、第１の入力が１次コンテンツであり第２の入力がオーバーレイされるコンテンツである２つの入力を持つビデオ出力コーデックを用いることによって、１つのビデオ信号を別のビデオ信号上にオーバーレイする際に役立ち得る。そのような状況では、オーバーレイの位置およびサイズが、オーバーレイされるコンテンツを表すビデオ表示ネットワークソースでのビデオ表示ソースモードの一部として指定され得る。

ビデオ表示ネットワークは、任意の数の入力、変換器、および複数の出力を備える他の多くの形を取ることができる。

（実施例３）
（ビデオ表示ネットワークリソースの例）
本明細書の各例のいずれにおいても、リソースは、ビデオ表示ネットワーク入力（ソースまたはサーフェスなど）、ビデオ表示ネットワーク出力（ターゲットなど）、変換器、ビデオメモリ、帯域幅、メモリ容量などを含み得る。

ビデオ表示ネットワークのトポロジはリソースと呼ばれることもある。例えば、リソースを構成することは、そのトポロジに関与する個々のリソースでの構成オプションの選択を考慮せずに単にあるトポロジを選択することを含み得る。

（実施例４）
（ビデオ表示ネットワークにおけるビデオパスの例）
ビデオ表示ネットワーク１００は複数のビデオパスを備えることができる。例えば、図１に示すように、１つのパスは入力１１０Ａから、変換器１３０Ａを介して出力１２０Ａに至ることができる。別のパスは、入力１１０Ａから変換器１３０Ａを介して出力１２０Ｂに至ることができ、以下同様である。

ビデオ表示ネットワーク１００のトポロジは、その構成に従った異なるパスが存在するように構成され得る。例えば、変換器１３０Ｎの出力をビデオ出力１２０Ｎに送る代わりに、構成設定を変更することによってそれを異なるビデオ出力（１２０Ｂなど）に経路指定することもできる。

（実施例５）
（ビデオ表示ネットワーク入力の例）
本明細書で説明する各例のいずれにおいても、ビデオ入力（または「ソース」）は、ディジタルサーフェスを提供するものなど、様々な形のいずれかを取ることができる。実際には、それらの入力は、様々なソースモードを使用するように構成され得る。そのようなモードは、幅、高さ、単位形式、ラスタライズされたグラフィックスフィルタリング技法、１次サーフェスチェーン長さ(primary surface chain length)など、またはそれらの組合せといったパラメータを含み得る。

（実施例６）
（ビデオ表示ネットワーク出力の例）
本明細書で説明する各例のいずれにおいてもビデオ出力（または「ターゲット」）は、出力信号を提供するものなど、様々な形のいずれかを取ることができる。出力に記述子を関連付けることができる。この記述子は、形式（ＤＶＩ、ＨＤＭＩ、ＨＤ−１５、ＢＮＣ、Ｓビデオ、ＲＦ、ＲＣＡなど）およびＨＰＤ認識を指示することができる。出力は、ビデオ符号化タイプとも関連付けられ得る。さらに、ある出力は、別の出力と同期するようにも構成され得る。

実際には、出力は、様々なターゲットモードを使用するように構成され得る。そのようなモードは、アクティブ領域（幅および高さなど）、総領域（幅および高さなど）、アクティブ領域変位(active region displacement)、画素符号化形式、垂直帰線周波数、水平帰線周波数、画素クロック速度、コンテンツ順序、原色、白色点基準、色空間変換マトリクスなど、またはそれらの組合せといったパラメータを含み得る。

（実施例７）
（変換器の例）
本明細書の各例のいずれにおいても、ディジタルビデオ入力表現／ビデオ出力信号変換器は、ビデオコーデックやディジタル／アナログ変換器などの形をとることができる。いくつかの変換器は共用可能である。例えば、クローン（ミラーなど）モードでは、１つのコーデックがその信号を２つの出力に送ることができる。

（実施例８）
（リソースの相互依存性の例）
理論的には、いくつのビデオ表示ネットワーク１００の構成でも可能であるが、限られた数の理論的構成だけが動作可能な構成である。実際には、ビデオ表示ネットワーク１００のリソースは、構成の相互依存性の影響を受ける。

例えば、ビデオ入力１１０Ａを特定のタイプのものとするように構成すると、大量のビデオメモリを消費し得る。そのような場合、別のビデオ入力（１１０Ｎなど）を同じタイプのものとするのに十分な残りのメモリがないことがある。例えば、それは、よりメモリ消費の少ないタイプにしか構成され得ないこともある。

多種多様な他の相互依存性も存在する。例えば、変換器は、特定のビデオ入力タイプだけしか受け入れず、あるいは特定のビデオ出力タイプだけしか生成しないこともある。そのため、特定の入力が特定の変換器との組合せでは動作できない場合などもある。

ゆえに、実際には、所望の構成の実施を阻む１つの障害は、それが動作しない可能性があることである。さらに、（様々な仕方で相互接続され得る）複数のビデオ入力、複数の変換器、および複数のビデオ出力を備えるビデオ表示ネットワークでの無数の理論的に可能な組合せのうちからどの組合せが動作可能であるか決定することは容易ではない。

図３は、ビデオ表示ネットワークでの構成可能なリソースの組合せを示すブロック図である。この例では、理論的に可能な構成３００は、構成された第１のリソース３０２（ビデオ表示ネットワーク入力など）の１つまたは複数を、構成された第３のリソース３０６（ビデオ表示ネットワーク出力など）の１つまたは複数と接続された、構成された第２のリソース３０４（ビデオ表示ネットワーク変換器など）の１つまたは複数と接続することによって組み立てられ得る。結果として生じる理論的に可能な構成の集合３１０を、そこに含まれるリソースの構成に応じて、一部は動作可能であり、一部は動作不能である、可能な構成の膨大な集合体として示す。

そのような膨大な解空間において最適な構成の解を見出すことは、３者間グラフマッチング問題(tri-partite graph matching problem)であり、それはＮＰ完全問題である。したがって、リソースでの可能な構成の数が妥当な数を上回るとき、強引な手法を用いることは問題となる可能性がある。

（実施例９）
（構成の例）
本明細書で説明する各例のいずれにおいても、リソースの構成は、ビデオ表示ネットワークのリソースの集合でのトポロジを選択することや、ネットワーク中の１つまたは複数のリソースでの構成オプション（モードなど）を選択すること（ネットワークが相互接続されるか否か）を含めて、多種多様な形を取ることができる。

（実施例１０）
（構成方法の例）
図４に、本明細書で説明するビデオ表示ネットワークのいずれかで構成を実現するために使用され得る構成方法の一例４００を示す。この方法も、本明細書で説明するその他の方法のいずれも、１つまたは複数のコンピュータ可読媒体上のコンピュータ実行可能命令によって実施され得る。

４１０で、ビデオ表示ネットワークの第１のリソースの構成の指示が受け取られる。例えば、ビデオ表示ネットワークの特定のビデオ入力での構成が受け取られ得る。

４２０で、第１のリソース構成の指示とは別に、ビデオ表示ネットワークの第２のリソースの構成の指示が受け取られる。例えば、ビデオ表示ネットワークの複数の出力の特定のビデオ出力の構成が受け取られ得る。

次いで、４３０で、構成の指示に従ってビデオ表示ネットワークが構成される。

実際には、ビデオ表示ネットワークの任意のリソース（例えば、２つの異なる入力、２つの異なる出力、２つの異なる変換器、１つの変換器および１つの出力など）についてその他の構成の指示が別個に受け取られ得る。

別個に受け取られる指示は、プログラマチックインタフェースへの呼び出し（例えば、デバイスドライバインタフェース呼び出し）など、２つの異なる呼び出しを使用して受け取られるものを含み得る。例えば、１つのデバイスドライバへの２つの異なる呼び出しが使用され得る。あるいは、同じ呼び出しで２つの異なるパラメータが使用され得る。あるいは、リソースでの別個の値を指示する１つまたは複数のデータ構造が使用され得る。そのような呼び出しは、オペレーティングシステムなどのクライアントからもたらされ得る。

そのようにして、ビデオ表示ネットワークのリソースは、独立に構成され得る。そのような構成は、ビデオ表示ネットワークのトポロジ（例えば、各リソースがどのように相互接続されるかなど）を指示することもできる。

（実施例１１）
（暫定的構成の例）
暫定的構成手法を用いれば、無数の可能な動作可能構成の中から望ましい構成を見出すことを含めて、様々な機能を円滑に行うことができる。図５に、図１に示すものなどのビデオ表示ネットワークのリソースの暫定的構成を指示する表５００を示す。

この例では、リソースσ_１は暫定的に構成されている（例えば、ビデオ表示ネットワークのリソースの構成パラメータは格納されているが、その構成が完全に動作可能である必要はないなど）。そのような暫定的構成は、部分構成（例えば、ビデオ表示ネットワークリソースのうちの１つのリソースの構成や、ビデオ表示ネットワークでのトポロジの１つの指示など）の受け取りに基づくものとすることができる。暫定的構成ではすべてのリソースの構成が受け取られる必要はない。というのは、完全な構成パラメータセットを伴わない構成は、通常、まだ動作可能ではなく、暫定的構成は、「半動作可能」(semi-functional)ともいわれるからである。あるリソースの部分構成の提供は、そのリソースの「ピンニング」(pinning)とも呼ばれる。必要に応じて、その部分構成は除去され（または指定変更され）得る。部分構成の除去は、「アンピンニング」(ピン解除：unpinning)とも呼ばれる。

（実施例１２）
（トランザクショナル構成の例）
ビデオ表示ネットワークの構成を実現するトランザクショナル手法は、前述の暫定的構成に基づくものとすることができる。図６に、トランザクショナル手法によりビデオ表示ネットワーク６３０（図１に示すビデオ表示ネットワークなど）の構成を実現するための例示的な構成６００を示す。

構成例６００では、クライアント６１０はビデオ表示ネットワークでの部分構成情報をサーバ６２０に送ることができる。コミットを受け取ると、次いで、サーバ６２０は、部分構成の指示に従ってビデオ表示ネットワーク６３０を構成することができる。

図７に、トランザクショナル手法によって構成を実行する方法の一例７００を示す。７１０で、ビデオ表示ネットワークでの一連の部分構成が（例えば、サーバによってクライアントから）受け取られる。それらの部分構成を用いて暫定的動作可能構成が構築され得る。

７２０で、暫定的動作可能構成がコミットされる。コミットすることによって、ビデオ表示ネットワーク（ネットワーク６３０など）において暫定的動作可能構成を実施することができる。

暫定的動作可能構成は、実施されずに格納されることもある。例えば、構成は、ビデオ表示ネットワークのリソースを構成せずに（例えば、構成コミット指示が処理されるまで）格納され得る。

（実施例１３）
（共に動作可能な構成オプション決定の例）
ビデオ表示ネットワークのリソース間の相互依存性のために、一部の理論的に可能な構成オプションは、すでに組み立てられている暫定的動作可能構成に照らしてみると動作可能でないことがある。例えば、リソースσ_１が（例えば図５に示すように）暫定的に構成されていると仮定すると、そのビデオ表示ネットワークの別のリソース（σ_Σなど）に利用可能な構成オプションは限定され得る。

図８Ａに、リソースσ_Σでの構成オプションの例示的な集合８５０を示す。別のリソースσ_１が暫定的にどのように構成されているかに照らしてみると、そのうちの構成オプションの部分集合８６０だけが利用可能である（例えば、動作可能構成になるはずである）。そのような構成では、利用可能な構成オプションは、（暫定的動作可能構成などの）その他の構成オプションと「共に動作可能である」、または暫定的構成を「無効化しない」ものとして説明されることがある。

あるリソースでの共に動作可能な構成オプションの集合８６０は、「エニュメレーション」とも呼ばれるプロセスにおいて暫定的構成時のフィードバックとして提供され得る。その場合、そのようなフィードバックを用いて、さらなる構成に関する決定（例えば、暫定的動作可能構成をさらに構築する、あるいは以前の暫定的動作可能構成に引き返すなど）が行われ得る。

場合によっては、暫定的動作可能構成から部分構成を除去することが望ましいこともある。例えば、その暫定的動作可能構成が、まだ構成されていないリソースの所望の仕方での構成を許容しないことが発見され得る。したがって、本明細書で説明する構成方法のいずれも、暫定的動作可能構成から部分構成を除去する指示を受け取ることを含み、その指示（または、単に、古いものを指定変更する新しい部分構成）を受け取ったことに応答してその部分構成を除去することができる。このようにして、方法は、（例えば、その暫定的動作可能構成をコミットする前に）以前の暫定的動作可能構成に引き返す（例えば、リソースをアンピンニングする）ことができる。

（実施例１４）
（複数のリソースでの共に動作可能な構成オプションの決定の例）
実際には、複数のリソースでの共に動作可能な構成オプションを一度に決定することが望ましいことがある。例えば、所与のトポロジが部分構成の一部として選択された後で、選択されたトポロジと共に動作可能なビデオ表示ネットワークソースでの構成オプションをエニュメレーションすることが望ましいことがある。

図８Ｂに、それぞれのリソース（σ_１、σ_２、σ_３など）での共に動作可能な構成オプション８８０Ａ、８８０Ｂ、８８０Ｃが指示され、複数のリソースでの構成オプションが一度に指示される構成を示す。図示の共に動作可能な構成オプションは、選択されたトポロジに関して共に動作可能である。これらのオプションは、相互には共に動作可能ではないことがある。例えば第１のリソースでの共に動作可能なオプションの１つを選択すると、別のリソースの共に動作可能なオプションの別の１つを無効化する（それと共に動作可能でなくなるなど）ことがある。

この例では、元のオプション（８７０Ａ、８７０Ｂ、８７０Ｃなど）の少なくとも一部は、選択されたトポロジに照らして利用可能で（例えば、共に動作可能で）はなくなる。オプションが他のリソース（ターゲットなど）にエニュメレーションされるときにも類似の構成が可能である。

そのようなオプションは、ソフトウェア（ビデオドライバなど）によってエニュメレーションされ得る。本明細書で説明する各例のいずれにおいても、エニュメレーションされたオプションのいずれかが１つのリソースに選択された場合、そのような選択が、その他のリソースのいずれかでのオプションの少なくとも１つと共に動作可能になる（例えば、そのすべてを無効化しない）ことを保証することが望ましい。

（実施例１５）
（ピンニング時の共に動作可能なオプション無効化の例）
実際には、複数のリソースでのトポロジと共に動作可能な（例えば複数のリソースでの）構成オプションをエニュメレーションした後、そのような構成オプションは、部分的な暫定的構成に含み得る。しかしながら、第１のリソースでの構成オプションの１つをピンニングする（例えば暫定的に選択する）と、別のリソースでの別のオプションを無効化する（例えばそれと共に動作可能でなくなる）ことがある。

図９Ａ〜Ｃに、あるリソースでの構成オプションを選択することが別のリソースでの構成オプションを無効化する例を示す。１つのトポロジが選択され得る。図９Ａに、トポロジを選択した後にエニュメレーションされた共に動作可能なオプション９２０Ａ、９２０Ｂ、９２０Ｃ（それぞれ、例えば理論的に可能なオプション９１０Ａ、９１０Ｂ、９１０Ｃの部分集合など）を示す。次いで、図９Ｂに、特定のオプション９２１が第１のリソースに選択されている（ピンニングされている）ことを示す。その結果、その他のリソースでの構成オプションの一部が利用できなくなる（それらが無効化される）ことがある。この例では、１つのオプションが９２０Ｂ’に現れなくなる。場合によっては、他のオプションも無効化される。あるいはおそらく、どれも無効化されないこともある。

図９Ｃに、特定のオプション９２２が別のリソースに選択されている（例えばピンニングされている）ことを示す。その結果、残りのリソースでの構成オプションの一部が利用できなくなることがある。この例では、１つのオプションが９２０Ｃ”に現れなくなる。場合によっては、第１のリソースでのオプションの一部も無効化され得る（例えば、集合９２０Ａ’（図示せず）を生じるなど）。しかしながら、実際には、１つのリソースがピンニングされた（例えば１つの構成オプションがそのリソースに選択された）後、ピンニングされた構成オプションは、エニュメレーションされた構成オプションの別の１つを選択することによって無効化されない。

図９Ａ〜９Ｃに示す現象のため、複数のリソースでエニュメレーションを行うときには、あるリソースをピンニングした後に無効化されるオプションの有無をチェックすることが必要になり得る。それは、再エニュメレーションによって実行され得る。

（実施例１６）
（別のピンニングシナリオ時の共に動作可能なオプション無効化の例）
図１０Ａ〜Ｃに、あるリソースの構成オプションを選択することが別のリソースの構成オプションを無効化する別の例を示す。１つのトポロジが選択され得る。図１０Ａに、トポロジを選択した後にエニュメレーションされた共に動作可能なオプション１０２０Ａ、１０２０Ｂ、１０２０Ｃ（それぞれ、例えば理論的に可能なオプション１０１０Ａ、１０１０Ｂ、１０１０Ｃの部分集合など）を示す。次いで、図１０Ｂに、特定のオプション１０２１が第１のリソースに選択されている（例えばピンニングされている）ことを示す。その結果、その他のリソースでの構成オプションの一部が利用できなくなる（例えばそれらが無効化される）ことがある。この例では、１つのオプションが１０２０Ｂ’に現れなくなる。場合によっては、他のオプションも無効化される。あるいはおそらく、どれも無効化されないこともある。

図１０Ｃに、特定のオプション１０２２が別のリソースに選択されている（例えばピンニングされている）ことを示す。その結果、残りのリソースでの構成オプションの一部が利用できなくなることがある。この例では、１つのオプションが１０２０Ｃ”に現れなくなる。場合によっては、第１のリソースでのオプションの一部も無効化され得る（集合１０２０Ａ’（図示せず）を生じるなど）。しかしながら、実際には、あるリソースがピンニングされた（例えば構成オプションがそのリソースに選択された）後、そのピンニングされた構成オプションは、エニュメレーションされた構成オプションの別の１つを選択することによって無効化されない。他の多くのシナリオが可能である。

（実施例１７）
（フィードバックを用いたトランザクショナル手法の例）
図１１に、フィードバックを用いたトランザクショナル手法によってビデオ表示ネットワーク１１３０（図１に示すビデオ表示ネットワークなど）の構成を実現する構成例１１００を示す。

この構成例１１００では、クライアント１１１０は、サーバ１１２０にビデオ表示ネットワークでの部分構成情報を送ることができる。部分構成情報は、そのビデオ表示ネットワークのリソースのいずれのものとすることもできる。部分構成は、そのビデオ表示ネットワークの１つのトポロジを指示することができる。

構成情報（例えば、第１のリソースでの部分構成）を受け取った後で、（例えば第２のリソースでの）共に動作可能な構成オプションが提供され得る。これらの共に動作可能な構成オプションは、その部分構成とは異なるリソースでのものや、異なるパスにあるリソースでのものなどとすることができる。共に動作可能なオプションは、構成情報に基づいて制限され得る（例えば、少なくとも１つの共に動作可能ではないオプションが除去されるなど）。本明細書で説明するように、これらのオプションはエニュメレーションによって提供することができ、エニュメレーションは、複数のリソースについて一度に行うことができる。

その他のリソースでの共に動作可能な構成オプションは、そのビデオ表示ネットワークのリソース間の相互依存性に基づくものとすることができる。クライアントは、共に動作可能な構成オプションの中から選択し、暫定的動作可能構成を構築し続けることができる。

コミットを受け取ると、サーバ１１２０は、次いで、部分構成の指示にしたがってビデオ表示ネットワーク１１３０を構成することができる。

図１２に、サーバから見た、フィードバックを用いて構成を実行する方法の一例１２００を示す。この方法は、図１１に示す構成によって動作し得る。１２１０で、部分ビデオ表示ネットワーク構成の指示が受け取られる。例えば、この部分構成は、ビデオ表示ネットワークの第１のリソースでの構成を指示することができる。

１２２０で、（先に図１１Ａまたは１１Ｂについて説明したように）共に動作可能な構成オプションが指示される。代替として、各オプションが指示される前に指示されるオプションから除去されるはずの１つまたは複数の共に動作可能ではない構成オプションを除いて、すべての構成オプションを指示することもできる。この方法は、その構成をビデオ表示ネットワークにコミットするためのコミット（図示せず）を含むこともできる。

図１３に、クライアントから見た、フィードバックを用いた構成を実行する例示的な方法１３００を示す。この方法は、図１１に示す構成によって動作し得る。図１３１０で、部分ビデオ表示ネットワーク構成の指示が送られる。例えば、この部分構成は、そのビデオ表示ネットワークの第１のリソースでの構成を指示することができる。

１３２０で、（先に図１１Ａまたは１１Ｂについて説明したように）共に動作可能な構成オプションの集合が指示される。この場合もやはり、この方法は、その構成をビデオ表示ネットワークにコミットするためのコミット（図示せず）を含むこともできる。

（実施例１８）
（ビデオドライバにおけるサーバ実装の例）
共に動作可能な構成オプションを決定することは、ビデオドライバに委ねられ得る。本明細書で説明する各例のいずれにおいても、サーバによって実行されるアクションは、ビデオドライバ（ビデオミニポートなど）によって実行され得る。

図１４に、フィードバックを用いた暫定的構成が実施され得るアーキテクチャの一例１４００を示す。この例は、クライアント１４１０（例えば、グラフィックスサブシステムといったオペレーティングシステム、アプリケーションなど）、相互依存論理１４２５を伴うドライバ１４２０（カーネルモードで動作するデバイス固有のビデオドライバなど）、および複数の表示装置１４４０Ａ〜１４４０Ｎにビデオ出力を提供するビデオアダプタ１４３０を含む。

ビデオドライバ１４２０は、本明細書で説明する各例のいずれにおいてもサーバとして働くことができる。相互依存論理１４２５は、部分構成を受け入れる関数、共に動作可能な構成オプションをエニュメレーションする関数、および構成をコミットする関数を含み得る。

このように、表示アダプタのハードウェアベンダは、望ましいビデオ表示ネットワーク構成を決定するのに役立つ適当な相互依存論理１４２５を組み込んだ適当なドライバ１４２０を開発することができる。

（実施例１９）
（利点の例）
実施例１８で論じたように、ビデオドライバに相互依存論理を実装すると、一定の制限事項のセットを用いて所与のハードウェア実装形態での適用範囲を狭めることによって、適当な構成の決定を簡単にすることができる。この論理が、そうではなく、オペレーティングシステムにあった場合、そのタスクはより複雑になり得る（例えば、完全に包括的であり、可能なあらゆる相互依存性をサポートすることが必要になる）。

（実施例２０）
（ビデオ表示ネットワーク構成の例）
図１５に、部分構成によるビデオ表示ネットワークの構成方法の一例１５００を示す。１５０４で、ビデオ表示ネットワークでのトポロジが選択される。１５０６で、ソースでの構成オプションがエニュメレーションされ、ピンニングされる。１５０８で、ターゲットの構成オプションがエニュメレーションされ、ピンニングされる。コミット（図示せず）を用いてその構成が実施され得る。

本明細書の各例のいずれにおいても、ソースはターゲットの前にピンニングされるものと示されるが、常にそうする必要はない。例えば、ターゲットはソースの前にピンニングされ得る。

（実施例２１）
（動作可能な構成に収束する解空間のトラバースの例）
図１６に、可能な動作可能複数ビデオ出力構成の組合せのグラフをトラバースする例示的方法１６００の流れ図を示す。そのような方法は、サーバ（ビデオドライバ１４２０など）と対話するクライアント（クライアント１４１０など）によって使用され得る。この例ではビデオミニポートを示すが、別のビデオドライバ（ビデオドライバ１４２０など）も使用され得る。

この例は、固定されたトポロジの動作可能ビデオ表示ネットワーク構成のサーチも含むが、他の例は、そのサーチの間にトポロジを変更するオプションを含むこともできる。例えば、トポロジは、ビデオ表示ネットワークソース上のビデオ表示ソースモードのピンニングが、別のビデオ表示ネットワークソースでの少なくとも１つの他のビデオ表示ソースモードを無効化した後で、変更されるように求められることがある。

１６０２で、所望のビデオ表示ネットワークトポロジが選択されている。

１６０４で、所望のビデオ表示ネットワークトポロジが与えられたとすると、少なくとも１つのビデオ表示ネットワークターゲット（すべてのターゲットなど）上で少なくとも１つのモニタサポートビデオ信号モード（すべてのモードなど）をサポートするビデオ表示ネットワーク構成（トポロジなど）を求めて、ビデオミニポートが照会される。

１６０６で、獲得されたビデオ表示ネットワーク構成（トポロジなど）中の少なくとも１つのビデオ表示ソース（すべてのソースなど）上の利用可能なビデオ表示ソースモードの集合がエニュメレーションされる。

１６０８で、ビデオ表示ソースモードが少なくとも１つのビデオ表示ネットワークソース（すべてのソースなど）上にピンニングされる。

１６１０で、ビデオ表示ソースモードがそこにピンニングされる次のビデオ表示ネットワークソースがあるかどうか判定される。ピンニングされる次のビデオ表示ネットワークソースがある場合、プロセスは１６１２に進む。そうでない場合、プロセスは１６１４に進む。

１６１２で、以前にエニュメレーションされたビデオ表示ソースモードのいずれかが無効化されているかどうか判定される。そうである場合、プロセスは１６０６に戻る。そうでない場合、プロセスは１６０８に戻る。この例では、別のビデオ表示ソースモードの選択に基づいて以前にエニュメレーションされたビデオ表示ソースモードの少なくとも１つが無効化され得るが、ビデオ表示ソースモードのすべてがそのような選択によって無効化され得るとは限らない。

１６１４で、獲得されたビデオ表示ネットワーク構成中の少なくとも１つのビデオ表示ターゲット（すべてのターゲットなど）上の利用可能なビデオ表示ターゲットモードの集合がエニュメレーションされる。

１６１６で、ビデオ表示ターゲットモードが少なくとも１つのビデオ表示ネットワークターゲット（すべてのターゲットなど）上にピンニングされる。

１６１８で、ビデオ表示ターゲットモードがそこにピンニングされる次のビデオ表示ネットワークターゲットがあるかどうか判定される。ピンニングされる次のビデオ表示ネットワークターゲットがある場合、プロセスは１６２０に進む。そうでない場合、プロセスは１６２２に進む。

１６２０で、以前にエニュメレーションされたビデオ表示ターゲットモードのいずれかが無効化されているかどうか判定される。そうである場合、プロセスは１６１４に戻る。そうでない場合、プロセスは１６１６に戻る。

１６２２で、結果として生じる動作可能なビデオ表示ネットワーク構成の組合せがコミットされる。

（実施例２２）
（動作可能構成に収束する解空間トラバースの第１の詳細な例）
図１７Ａ〜Ｂに、可能な動作可能複数ビデオ出力構成の組合せのグラフをトラバースする方法の第１の詳細な例１７００の流れ図を示す。そのような方法は、サーバ（ビデオドライバ１４２０など）と対話するクライアント（クライアント１４１０など）によって使用され得る。この例はビデオミニポートを示すが、別のビデオドライバ（ビデオドライバ１４２０など）も使用され得る。

１７０２で、初期のビデオ表示ネットワークトポロジが提供されている。

１７０４で、初期のビデオ表示ネットワークトポロジが与えられたとすると、少なくとも１つのビデオ表示ネットワークターゲット（すべてのターゲットなど）上の少なくとも１つのモニタサポートビデオ信号モード（すべてのモードなど）をサポートするビデオ表示ネットワーク構成（トポロジなど）を求めて、ビデオミニポートが照会される。

１７０６で、１７０４の照会によって指定されたビデオ表示ネットワークトポロジがサポートされるかどうかについて判定される。指定されたビデオ表示ネットワークトポロジがサポートされる場合、プロセスは１７０８に進む。そうでない場合、プロセスは１７１０に進む。

１７０８で、現在のビデオ表示ネットワークトポロジが最も望ましいビデオ表示ネットワークトポロジであるかどうかについて判定される。そうである場合、プロセスは１７１２に進む。そうでない場合、プロセスは１７１４に進む。

１７１０で、少なくとも１つの他の初期のビデオ表示ネットワークトポロジが存在するかどうかについて判定される。そうである場合、プロセスは１７０４に戻る。そうでない場合、プロセスは１７９０で終了する。というのは、所望のサーチパラメータを伴う動作可能構成の組合せへの収束がないからである。

１７１２で、獲得されたビデオ表示ネットワーク構成中の少なくとも１つのビデオ表示ネットワークソース（すべてのソースなど）上の利用可能なビデオ表示ソースモードの集合がエニュメレーションされる。次いでプロセスは１７２２に進む。

１７１４で、ビデオ表示ネットワークトポロジは、ビデオ表示パス（マルチパスなど）の付加または除去によって新しい有効なビデオ表示ネットワークトポロジに調整される。次いでプロセスは１７１６に進み、そこで、その新しい有効なビデオ表示ネットワークトポロジがサポートされるかどうかについて判定される。そうである場合、プロセスは１７０８に戻る。そうでない場合、プロセスは１７１８に進む。

１７１８で、有効なビデオ表示ネットワークトポロジによる増分変更によって獲得され得る少なくとも１つの他の所望のビデオ表示ネットワークトポロジがあるかどうかについて判定される。ある場合、プロセスは１７２０に進む。ない場合、プロセスは１７９０で終了する。

１７２０で、別の所望のビデオ表示ネットワークトポロジが、ヌルトポロジによってのみ獲得可能（例えば、トポロジがそれ以上調整され得ないなど）であるかどうかについて判定される。そうである場合、プロセスは１７０４に戻る。そうでない場合、プロセスは１７１４に戻る。

１７２２で、エニュメレーションされたビデオ表示ソースモードのいずれかがそれぞれのビデオ表示ネットワークソースに求められるモードを欠いているかどうかについて判定される。そうである場合、プロセスは１７２４に進む。そうでない場合、プロセスは１７３２に進む。

１７２４で、任意のビデオ表示ネットワークソースがピンニングされたビデオ表示ソースモードを持つかどうかについて判定される。そうである場合、プロセスは１７２８に進み、そこでピンニングされたビデオ表示ソースモードがアンピンニングされ、次いで１７１２に戻る。そうでない場合、プロセスは１７３０に進む。１７２８におけるビデオ表示ソースモードアンピンニングは、ビデオ表示ネットワークソースの重要度に従って順序付けされ得る（例えば、ソースモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１７３０で、ビデオ表示ネットワークソースに利用可能な少なくとも１つの他のビデオ表示ソースモードがあるかどうかについて判定される。ある場合、プロセスは１７３２に戻り、そこでビデオ表示ソースモードが少なくとも１つのビデオ表示ネットワークソース上に（例えばすべてのソースについて）ピンニングされ、次いで１７３４に進む。ない場合、プロセスは１７９０で終了する。１７３２におけるビデオ表示ソースモードピンニングは、ビデオ表示ネットワークソースの重要度に従って順序付けされ得る（例えば、ソースモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１７３４で、ビデオ表示ソースモードがそこにピンニングされる次のビデオ表示ネットワークソースがあるかどうか判定される。ピンニングされる次のビデオ表示ネットワークソースがある場合、プロセスは１７３６に進む。そうでない場合、プロセスは１７３８に進む。

１７３６で、以前にエニュメレーションされたビデオ表示ソースモードのいずれかが無効化されているかどうか判定される。そうである場合、プロセスは１７１２に戻る。そうでない場合、プロセスは１７３２に戻る。

１７３８で、獲得されたビデオ表示ネットワーク構成中の少なくとも１つのビデオ表示ネットワークターゲット（すべてのターゲットなど）上の利用可能なビデオ表示ターゲットモードの集合がエニュメレーションされる。

１７４２で、エニュメレーションされたビデオ表示ターゲットモードのいずれかが、それぞれのビデオ表示ネットワークターゲットに求められるモードを欠いているかどうかについて判定される。そうである場合、プロセスは１７４４に進む。そうでない場合、プロセスは１７５２に進む。

１７４４で、任意のビデオ表示ネットワークターゲットがその上にピンニングされたビデオ表示ターゲットモードを持つかどうかについて判定される。そうである場合、プロセスは１７４８に進み、そこでピンニングされたビデオ表示ターゲットモードがアンピンニングされ、次いで１７３８に戻る。そうでない場合、プロセスは１７５０に進む。１７４８におけるビデオ表示ターゲットモードのアンピンニングは、ビデオ表示ネットワークターゲットの重要度に従って順序付けされ得る（例えば、ターゲットモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１７５０で、ビデオ表示ネットワークターゲットに利用可能な少なくとも１つの他のビデオ表示ターゲットモードがあるかどうかについて判定される。ある場合、プロセスは１７５２に戻り、そこでビデオ表示ターゲットモードが、少なくとも１つのビデオ表示ネットワークターゲット上に（例えばすべてのターゲットについて）ピンニングされ、次いで１７５４に進む。ない場合、プロセスは１７９０で終了する。１７５２におけるビデオ表示ターゲットモードのピンニングは、ビデオ表示ネットワークターゲットの重要度に従って順序付けされ得る（例えば、ターゲットモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１７５４で、ビデオ表示ターゲットモードがそこにピンニングされる次のビデオ表示ネットワークターゲットがあるかどうか判定される。ピンニングされる次のビデオ表示ネットワークターゲットがある場合、プロセスは１７５６に進む。そうでない場合、プロセスは１７８０に進む。

１７５６で、以前にエニュメレーションされたビデオ表示ターゲットモードのいずれかが無効化されているかどうか判定される。そうである場合、プロセスは１７３８に戻る。そうでない場合、プロセスは１７５２に戻る。

１７８０で、結果として生じる動作可能なビデオ表示ネットワーク構成の組合せがコミットされる。

（実施例２３）
（動作可能構成に収束する解空間のトラバースの第２の詳細な例）
図１８Ａ〜Ｃに、可能な動作可能複数ビデオ出力構成の組合せのグラフをトラバースする方法の第２の詳細な例１８００の流れ図を示す。そのような方法は、サーバ（ビデオドライバ１４２０など）と対話するクライアント（クライアント１４１０など）によって使用され得る。この例にはビデオミニポートを示すが、別のビデオドライバ（ビデオドライバ１４２０など）も使用され得る。

１８０２で、初期のビデオ表示ネットワークトポロジが提供されている。

１８０４で、初期のビデオ表示ネットワークトポロジが与えられたとすると、少なくとも１つのビデオ表示ネットワークターゲット（すべてのターゲットなど）上で少なくとも１つのモニタサポートビデオ信号モード（すべてのモードなど）をサポートするビデオ表示ネットワーク構成（トポロジなど）を求めて、ビデオミニポートが照会される。

１８０６で、１８０４の照会によって指定されたビデオ表示ネットワークトポロジがサポートされるかどうかについて判定される。指定されたビデオ表示ネットワークトポロジがサポートされる場合、プロセスは１８０８に進む。そうでない場合、プロセスは１８１０に進む。

１８０８で、現在のビデオ表示ネットワークトポロジが最も望ましいビデオ表示ネットワークトポロジであるかどうかについて判定される。そうである場合、プロセスは１８１２に進む。そうでない場合、プロセスは１８１４に進む。

１８１０で、少なくとも１つの他の初期のビデオ表示ネットワークトポロジが存在するかどうかについて判定される。そうである場合、プロセスは１８０４に戻る。そうでない場合、プロセスは１８９０で終了する。というのは、所望のサーチパラメータを伴う動作可能構成の組合せへの収束がないからである。

１８１２で、獲得されたビデオ表示ネットワーク構成中の少なくとも１つのビデオ表示ネットワークソース（すべてのソースなど）上の利用可能なビデオ表示ソースモードの集合がエニュメレーションされる。次いでプロセスは１８２２に進む。

１８１４で、ビデオ表示ネットワークトポロジは、ビデオ表示パス（マルチパスなど）の付加または除去によって新しい有効なビデオ表示ネットワークトポロジに調整される。次いでプロセスは１８１６に進み、そこでその新しい有効なビデオ表示ネットワークトポロジがサポートされるかどうかについて判定される。そうである場合、プロセスは１８０８に戻る。そうでない場合、プロセスは１８１８に進む。

１８１８で、有効なビデオ表示ネットワークトポロジによる増分変更によって獲得され得る少なくとも１つの他の所望のビデオ表示ネットワークトポロジがあるかどうかについて判定される。ある場合、プロセスは１８２０に進む。ない場合、プロセスは１８９０で終了する。

１８２０で、別の所望のビデオ表示ネットワークトポロジが、ヌルトポロジによってのみ獲得可能（例えば、トポロジがそれ以上調整され得ないなど）であるかどうかについて判定される。そうである場合、プロセスは１８０４に戻る。そうでない場合、プロセスは１８１４に戻る。

１８２２で、エニュメレーションされたビデオ表示ソースモードのいずれかがそれぞれのビデオ表示ネットワークソースに求められるモードを欠いているかどうかについて判定される。そうである場合、プロセスは１８２４に進む。そうでない場合、プロセスは１８３２に進む。

１８２４で、任意のビデオ表示ネットワークソースがピンニングされたビデオ表示ソースモードを持つかどうかについて判定される。そうである場合、プロセスは１８２８に進み、そこでピンニングされたビデオ表示ソースモードがアンピンニングされ、次いで１８１２に戻る。そうでない場合、プロセスは１８３０に進む。１８２８におけるビデオ表示ソースモードアンピンニングは、ビデオ表示ネットワークソースの重要度に従って順序付けされ得る（例えば、ソースモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１８３０で、ビデオ表示ネットワークソースに利用可能な少なくとも１つの他のビデオ表示ソースモードがあるかどうかについて判定される。ある場合、プロセスは１８３２に戻り、そこでビデオ表示ソースモードが少なくとも１つのビデオ表示ネットワークソース上で（例えばすべてのソースについて）ピンニングされ、次いで１８３４に進む。ない場合、プロセスは１８３１に進む。１８３２におけるビデオ表示ソースモードのピンニングは、ビデオ表示ネットワークソースの重要度に従って順序付けされ得る（例えば、ソースモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１８３１で、他の任意の所望のビデオ表示ネットワークトポロジが与えられたとすると、ビデオ表示ネットワークソースに利用可能な少なくとも１つの他のビデオ表示ソースモードがあるかどうかについて判定される。ある場合、プロセスは１８１８に戻る。ない場合、プロセスは１８９０で終了する。

１８３４で、ビデオ表示ソースモードがそこにピンニングされる次のビデオ表示ネットワークソースがあるかどうか判定される。ピンニングされる次のビデオ表示ネットワークソースがある場合、プロセスは１８３６に進む。そうでない場合、プロセスは１８３８に進む。

１８３６で、以前にエニュメレーションされたビデオ表示ソースモードのいずれかが無効化されているかどうか判定される。そうである場合、プロセスは１８１２に戻る。そうでない場合、プロセスは１８３２に戻る。

１８３８で、獲得されたビデオ表示ネットワーク構成中の少なくとも１つのビデオ表示ネットワークターゲット（すべてのターゲットなど）上の利用可能なビデオ表示ターゲットモードの集合がエニュメレーションされる。

１８４２で、エニュメレーションされたビデオ表示ターゲットモードのいずれかが、それぞれのビデオ表示ネットワークターゲットに求められるモードを欠いているかどうかについて判定される。そうである場合、プロセスは１８４４に進む。そうでない場合、プロセスは１８５２に進む。

１８４４で、任意のビデオ表示ネットワークターゲットがその上にピンニングされたビデオ表示ターゲットモードを持つかどうかについて判定される。そうである場合、プロセスは１８４８に進み、そこでピンニングされたビデオ表示ターゲットモードがアンピンニングされ、次いで１８３８に戻る。そうでない場合、プロセスは１８５０に進む。１８４８におけるビデオ表示ターゲットモードのアンピンニングは、ビデオ表示ネットワークターゲットの重要度に従って順序付けされ得る（例えば、ターゲットモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１８５０で、現在のビデオ表示ネットワークトポロジおよびビデオ表示ネットワークソース上にピンニングされたビデオ表示ソースモードが与えられたとすると、ビデオ表示ネットワークターゲットに利用可能な少なくとも１つの他のビデオ表示ターゲットモードがあるかどうかについて判定される。ある場合、プロセスは１８５２に戻り、そこでビデオ表示ターゲットモードが、少なくとも１つのビデオ表示ネットワークターゲット上に（例えばすべてのターゲットについて）ピンニングされ、次いで１８５４に進む。そうでない場合、プロセスは１８５６に進む。１８５２におけるビデオ表示ターゲットモードのピンニングは、ビデオ表示ネットワークターゲットの重要度に従って順序付けされ得る（例えば、ターゲットモードに、重要度が最高のものから最低のものへ優先順位を付けることができる）。

１８５４で、ビデオ表示ターゲットモードがそこにピンニングされる次のビデオ表示ネットワークターゲットがあるかどうか判定される。ピンニングされる次のビデオ表示ネットワークターゲットがある場合、プロセスは１８６８に進む。そうでない場合、プロセスは１８８０に進む。

１８５６で、何がより重要であるとみなされるか、すなわち、現在のビデオ表示ネットワークトポロジか、それとも現在ビデオ表示ネットワークソース上にピンニングされているビデオ表示ソースモードかについて判定される。現在ビデオ表示ネットワークソース上にピンニングされているビデオ表示ソースモードがより重要であるとみなされる場合、プロセスは１８６２に進む。現在のビデオ表示ネットワークトポロジがより重要であるとみなされる場合、プロセスは１８６４に進む。

１８６２で、少なくとも１つの他の所望のビデオ表示ネットワークトポロジがあるかどうか判定される。ある場合、プロセスは１８１８に戻る。ない場合、プロセスは１８６６に進む。

１８６４で、現在のビデオ表示ネットワークトポロジが与えられたとすると、少なくとも１つの他の所望のビデオ表示ソースモードがあるかどうかについて判定される。ある場合、プロセスは１８２８に戻る。ない場合、プロセスは１８６２に進む。

１８６６で、少なくとも１つのビデオ表示ネットワークソース上で利用可能な少なくとも１つの他の望ましいビデオ表示ソースモードがあるかどうかについて判定される。ある場合、プロセスは１８６４に進む。ない場合、プロセスは１８９０で終了する。

１８６８で、以前にエニュメレーションされたビデオ表示ターゲットモードのいずれかが無効化されているかどうかが判定される。そうである場合、プロセスは１８３８に戻る。そうでない場合、プロセスは１８５２に戻る。

１８８０で、結果として生じる動作可能なビデオ表示ネットワーク構成の組合せがコミットされる。

（実施例２４）
（目標構成を実現する方法の例）
図１９に、（例えば、モニタによってサポートされるビデオモードの点で述べられている）目標に照らしてビデオ表示ネットワークのためのトポロジを決定する例示的な方法１９００を示す流れ図を示す。

１９０２で、プロセスは初期トポロジを用いて開始する。１９０６で、目標により適合するように（例えば、目標により適合する暫定的動作可能構成を生成することによって）初期トポロジが変更される。そのような変更は、ビデオ表示ネットワークのリソース間の相互依存性を考慮に入れることができる。

可能な目標はビデオモードまたは他の構成オプションに関連し得る。例えば、１つの目標は、ビデオ表示ネットワークターゲット上のビデオモード集合が、それらに接続されたモニタすべてでの優先モードをサポートしなければならないものと仮定して、そのビデオ表示ネットワークソース上のサポートされるグラフィックスビデオ表示ネットワークソースモード集合を最大にするように、利用可能なビデオ出力コーデックを介して、ビデオ表示ネットワークにおいてビデオ表示ネットワークターゲットからビデオ表示ネットワークソースまで経路指定する最善の方法とすることができる。あるいは、そのような目標が達成され得ない場合、目標は、ビデオ表示ネットワークターゲット上のビデオモード集合が、指定された優先順位でそれらに接続されたモニタ上の優先モードをサポートしなければならないものと仮定して、そのビデオ表示ネットワークソース上のサポートされるグラフィックスビデオ表示ネットワークソースモード集合を最大にするように、利用可能なビデオ出力コーデックを介して、ビデオ表示ネットワークにおいてビデオ表示ネットワークターゲットからビデオ表示ネットワークソースまで経路指定する最善の方法とすることができる。あるいは、そのような目標が達成されえない場合、目標は、ビデオ表示ネットワークターゲット上のビデオモード集合が、それらに接続されたモニタによってサポートされるビデオモードの少なくとも１つをサポートしなければならないものと仮定して、そのビデオ表示ネットワークソース上でのサポートされるグラフィックスビデオ表示ネットワークソースモード集合を最大にするように、利用可能なビデオ出力コーデックを介して、ビデオ表示ネットワークにおいてビデオ表示ネットワークターゲットからビデオ表示ネットワークソースまで経路指定する最善の方法とすることができる。

必要に応じて、第１の目標が試みられ得る。次いで、第１の目標が達成され得ない場合、第２の目標が試みられ、以下同様である。目標は「最適な」構成として説明されることもある。

（実施例２５）
（その他の目標の例）
前述の目標以外に、他の構成目標が求められることもあり、それらは本明細書で説明する技術によって円滑に行われ得る。例えば、以下を、別々に、または何らかの組合せとして達成することが重要とされ得る。

１．レンダリングターゲット上での空間解像度を最大にする
２．レンダリングターゲット上での色解像度を最大にする
３．レンダリングターゲットの１つでの空間解像度と色解像度両方を最大にする（医療用画像処理アプリケーション、コンピュータ援用設計などの場合）
４．ビデオストリーム同期問題を回避するために、リアルタイムテレビ放送表示を含むビューを表示するモニタ上のリフレッシュ速度をマッチさせる。そのような同期問題は、アーチファクトや、フレーム落ち（グリッチなど）や、その両方として現れる。

５．１つまたは複数のＧＰＵが同じビデオメモリバスをめぐって競合していると想定して、３Ｄ性能を高めるために、許容可能な最低のレンダリングモードでビューを駆動することによってビデオメモリ帯域幅をできるだけ温存する
そのような目標は、単純なビデオドライバの範囲を超えているため、そのような目標は、ビデオドライバの外部に（例えば、シェル、グラフィックスサブシステム、ＤＸランタイムなどといった、オペレーティングシステムの上位層に）意思決定能力を配置することによって達成され得る。

可能なレンダリングモードの絶対量の多さにより、ドライバはとてもそれらをエニュメレーションすることができない。構成目標を達成するために、（本明細書の各例で説明するような）照会またはトラバース手法を用いることができる。

さらに別の目標が以下のように分類され得る。

１．画像品質のために最適化されたモードでは、画像を可能な限り最適に表示することに最も配慮する。

２．性能のために最適化されたモードでは、ビデオメモリバスを過負荷状態にしないことに最も配慮する（例えば、各コーデックがビデオメモリから読み取る必要があり、ゆえに、ビデオメモリ帯域幅を消費するなど）。

３．電力消費のために最適化されたモードでは、それが２つのモニタのどちらかで優先モードを駆動することができない場合でさえ、最も電力消費の少ないコーデックを選択し、他のすべてのコーデックをオフにしようとすることがある。

通常、任意の構成における暗黙的目標は、ビデオ出力が、それぞれのモニタによってサポートされる少なくとも１つのモードをサポートすることである。性能または電力管理考慮事項によって指定変更されない限り、通常、別の目標は、ビデオ出力が、そのそれぞれのモニタの優先モードをサポートしようとすることであり、その場合、モニタの重要度には、構成要求の一部としてクライアント（オペレーティングシステムなど）によって優先順位が付けられる。

例えば、複数のビュー（クローンビューなど）で同じレンダリングターゲットを表示するために、ビデオドライバは、できるだけ多くのモニタをそれらの優先モードで実行させようとし、そうしないことは、要求された出力の１つが駆動され得ないことを意味するときにだけコーデックを共用するべきである。

例えば、３つのビデオ出力と、２つだけのコーデックが関与する場合、モニタの少なくとも１つがその優先モードで実行されていない場合でさえも、３つの出力すべてをサポートするよう求められたときにコーデックを共用することが容認され得る。しかしながら、出力の２つだけをサポートするよう求められたとき、コーデックを共用せずに優先モードが両方のモニタ上で達成され得る場合には、コーデックを共用すべきではない。

（実施例２６）
（電力消費に関連する目標の例）
いくつかのシナリオでは、電力消費に関する目標を指定することが望ましいことがある。例えば、節電状態にはより小さい電力消費を伴う構成が優先され、全出力状態のときには、性能および／または画像品質が優先され得る。本明細書の各例のいずれにおいても、そのような目標が実施され得る。

（実施例２７）
（デバイスドライバインタフェースの例）
実施例４５に、一連の関数（EnumerateAvailVidPNTargets、ConstrainNodesOnVidPNTargetsなど）およびその目的が列記されている。そのような関数は、ビデオデバイスドライバ（ビデオミニポートなど）によってサポートされるデバイスドライバインタフェースに含み得る。これらの関数は、クライアントによって、様々なアルゴリズム（サーチアルゴリズムなど）を用いて、増分的にビデオ表示ネットワークを構築するのに使用され得る。

（実施例２８）
（構成管理のための関数の例）
実施例４５に、構成管理のための一連の関数が詳述されている。例えば、ある関数（GetActiveVidPNTopologyなど）はビデオ表示ネットワーク構成（トポロジなど）を識別する。別の関数（CommitVidPNImplなど）は、ビデオ表示ネットワーク構成をコミットする。別の関数（EnumCurrentlyAvailVidPNSourceModeSetsなど）は、所望のビデオ表示ネットワーク構成が与えられたとして、利用可能なビデオ表示ソースモードをエニュメレーションする。別の関数（EnumCurrentlyAvailVidPNTargetModeSetsなど）は、所望のビデオ表示ネットワーク構成が与えられたとして、利用可能なビデオ表示ターゲットモードをエニュメレーションする。別の関数（PinModeOnVidPNSourceなど）は、ビデオ表示ネットワークソース上にビデオ表示ソースモードをピンニングする。別の関数（PinModeOnVidPNTargetなど）は、ビデオ表示ネットワークターゲット上にビデオ表示ターゲットモードをピンニングする。別の関数（UnpinModeOnVidPNSourceなど）は、ビデオ表示ネットワークソース上のビデオ表示ソースモードをアンピンニングする。別の関数（UnpinModeOnVidPNTargetなど）は、ビデオ表示ネットワークターゲット上のビデオ表示ターゲットモードをアンピンニングする。別の関数（CreateVidPNImplなど）は、ビデオ表示ネットワーク構成を作成する。これらの関数の任意の組合せが、プログラマチックインタフェース（デバイスドライバインタフェースなど）の一部として実施され得る。そのようなインタフェースは、（例えばクライアントプログラムなどのための）サービスとしてこれらの関数へのアクセスを提供することができる。

（実施例２９）
（構成に到達する呼び出しの例）
図２０に、構成に到達する呼び出しの例を示すブロック図を示す。そのような呼び出しは、デバイスドライバインタフェース（ＤＤＩ）の一部として実施され得る。

システム２０００は、ドライバ２００２（ビデオミニポートなど）とグラフィックスカーネルサブシステム２００４の間の通信を含む。指定されたビデオ表示ネットワーク構成が与えられたとして、EnumAvailVidPNTargetsを呼び出して、所与のビデオカードによってサポートされる利用可能なビデオ表示ネットワークターゲットがエニュメレーションされ得る。EnumAvailVidPNSourcesを呼び出して、その所与のビデオカードによってサポートされる利用可能なビデオ表示ネットワークソースがエニュメレーションされ得る。これら２つの呼び出しは、システム初期設定の一部とすることができる。代替として、これら２つの呼び出しを、ビデオアダプタ到達イベント（ＰＣＩエクスプレスやドッキングステーションホットプラグなど）の一部とすることもできる。状況によっては、ヌルビデオ表示ネットワーク構成様式がサポートされ、（例えば初期設定に適するように）すべての利用可能なビデオ表示ターゲットおよびソースを報告すべきことを知らせることもできる。

IsMonitorConnectedを使用して、エニュメレーションされたビデオ表示ターゲットのどれがそれらに接続されたモニタを備えるか判定され得る。GetMonitorDescriptorを呼び出して、接続されたモニタごとにそれぞれのモニタの記述子が獲得され得る。ConstrainModesOnVidPNTargetsを呼び出して、モニタの記述子から獲得されたモニタ機能を踏まえて、エニュメレーションされたビデオ表示ターゲットのそれぞれに対するビデオモード制約条件が設定され得る。

ビデオ表示ネットワーク構築時に、任意選択でGetInitialVidPNImplを呼び出して、ビデオミニポートによって推奨されるビデオ表示ネットワークの暫定的構成が獲得され得る。CreateVidPNImplを呼び出し、ビデオミニポートによる任意選択の推奨に基づいてビデオ表示ネットワークの暫定的構成が作成され得る。代替として、CreateVidPNImplが、ミニポートによる任意選択の推奨を無視してビデオ表示ネットワークの暫定的構成を作成することもできる。

半動作可能なビデオ表示ネットワークを作成することの一部として、ビデオ表示ソースモードがビデオ表示ネットワークソース上にピンニングされるまで、EnumCurrentlyAvailVidPNSourceModeSets、PinModeOnVidPNSource、およびUnpinModeOnVidPNSourceが呼び出され得る。ピンニングされるビデオ表示ソースモードが、ビデオ表示ネットワークソースで機能することが知られている場合、PinModeOnEachVidPNSourceを呼び出して、ビデオ表示ソースモードがビデオ表示ネットワークソースすべてに一度にピンニングされ得る。

動作可能なビデオ表示ネットワークを完成することの一部として、ビデオ表示ターゲットモードがビデオ表示ネットワークターゲット上にピンニングされるまで、EnumCurrentlyAvailVidPNTargetModeSets、PinModeOnVidPNTarget、およびUnpinModeOnVidPNTargetが呼び出され得る。ピンニングされるビデオ表示ターゲットモードが、ビデオ表示ネットワークターゲットで機能することが知られている場合、PinModeOnEachVidPNTargetを呼び出して、ビデオ表示ターゲットモードがビデオ表示ネットワークターゲットすべてに一度にピンニングされ得る。

ビデオ表示ネットワーク暫定的構成をコミットするには、CommitVidPNImplが呼び出され得る。動作可能なビデオ表示ネットワークの暫定的構成は、ビデオ表示ネットワークの各ソースごとに１次サーフェスチェーンがセットアップされた後でコミットされ得る。CommitVidPNImplは、入力として、ビデオ表示ネットワークトポロジおよびビデオ表示ソースおよびターゲット（１次サーフェスチェーンなど）の外部の他のＯＳ所有リソースを必要とすることがある。

（実施例３０）
（ビデオ出力とレンダリングターゲットの分離の例）
ビデオレンダリングデバイスドライバが（オペレーティングシステムに、したがって間接的にそのオペレーティングシステム上で走っているアプリケーションに）公開するインタフェースは、ビデオレンダリングデバイスが、そこで表示される画像を物理的に駆動しているビデオ出力と、アプリケーションが、それが表示しようとするコンテンツをそこに論理的にレンダリングしているレンダリングターゲットの概念を、２つの別個の独立したエンティティとして区別する必要はない。レンダリングターゲットは、ビデオレンダリングデバイス上の各ビデオ出力と、暗黙的、静的に関連付けられ得る。しかしながら、そのような手法は制約的であることがある。

本明細書で説明する各例のいずれにおいても、レンダリングターゲットの明示的概念は、レンダリングモードの概念によってサポートされ得る。オペレーティングシステムにおける任意のデバイスの基本動作様式記述子である表示モードは次の２つのものとして説明することができる。それらは、（図１または図２５に示すものなど、出力またはターゲットでの）出力様式記述子であるビデオモードと、（図１または図２５に示すものなど、入力またはソースでの）入力様式記述子であるレンダリングモードである。そのような手法は、複数のビデオ出力を備えるシステムで特に有用である。ビデオドライバ（ＤＤＩなど）へのインタフェースは、ビデオモードとレンダリングモードの別個の仕様を許容し得る。

ゆえに、論理的レンダリングターゲットは、その物理的ビデオ出力と切り離して動的に管理され得る。それらのターゲットは、実行時に選択のビデオ出力にマップされ、必要に応じてそれらを出力間で宛先変更し、あるいは単一のレンダリングターゲットを同時に複数の出力にマップすることさえもできる。

（実施例３１）
（モニタ到達／離脱(Monitor Arrival/Departure)管理の例）
本明細書で説明する技術のいずれも、モニタが実行中にシステムに接続され、またはシステムから取り外されるシナリオに適用され得る。例えば、モニタがシステムに到達し、またはシステムから離脱するときにシステムによってイベント（ＨＰＤイベントなど）が検出され、構成がしかるべく選択され得る。また、（クローンビュー、拡張デスクトップ管理などで）ビデオストリームを異なる出力に宛先変更する変更も実施され得る。前述のように論理的レンダリングターゲットをその物理的ビデオ出力と切り離して管理することによって、そのような動的構成変更での堅固なサポートが実現され得る。

（実施例３２）
（技術統合の例） 本明細書で説明する例のいずれにおいても、ビデオ表示装置は様々な形を取ることができる。例えば、図２１に、本技術の、複数のビデオ表示装置を備えるコンピュータシステムへの統合の一例を示す。

図２１は、複数ビデオ出力装置システムの例示的なハイレベルアーキテクチャ２１００を示す図である。デスクトップ２１１０、表示属性アプレット２１１２、および全画面グラフィックスアプリケーション２１１４は、グラフィックスサブシステム２１２０と通信する。グラフィックスサブシステム２１２０は、ビデオドライバ２１３０および別のビデオドライバ２１３２を駆動する。両ビデオドライバ（ビデオミニポートなど）は、ハードウェア抽象化層（ＨＡＬ）２１４０を介してビデオアダプタ２１５０および２１５２と通信し、それらが出力された信号を複数のビデオ出力装置の任意の組合せに送る。そのようなビデオ出力装置は、ＣＲＴモニタ２１６０、フラットパネルモニタ２１６２、ディジタルプロジェクタ２１６４、ＬＣＤモニタ２１６６、仮想現実ゴーグル２１６８などを含み得る。図示したもの以外の組合せも可能である。

（実施例３３）
（所望の構成に収束する解空間トラバースの例）
図２２に、ビデオ構成が属性に基づいて決定され得るクライアント／サーバシステム２２００を示す。クライアント２２０２はサーバ２２０４と通信する。クライアント２２０２は、優先順位情報を指定する優先順位２２０６を含む。

そのような優先順位情報は、１つまたは複数の所望のトポロジのリスト、それぞれのソースでの望ましいモードのリスト、それぞれのターゲットでの望ましいモードのリストなど、あるいはそれらの何らかの組合せを含み得る。優先順位情報は、特定のソースモードがトポロジ選択より重要であるかどうかも含み得る。さらに、望ましいソースモードおよび望ましいターゲットモードにも（例えば重要度が最高のものから最低のものへ）優先順位を付けることができる。

そのような優先順位は、優先順位リストの形とすることができる。しかしながら、優先順位は、論理への組み込み（クライアント２２０２でのｉｆ−ｔｈｅｎステートメントなど）によっても実現され得る。

図２３に、先に図２２に示したシステムでの場合などの、所望のビデオ構成オプションの優先順位リストに基づいてビデオ構成を決定する方法の一例２３００を示す。

２３０２で、少なくとも１つの第１のリソースでの部分ビデオ構成が提出される。

２３０４で、その部分ビデオ構成と共に動作可能な構成オプションのリストが受け取られる。

２３０６で、優先順位リスト中の所望のオプションが、その部分ビデオ構成と共に動作可能な構成オプションのリストに存在するかどうかについて判定される。

２３０８で、所望のオプションが存在しないという判定に応答して、第１のリソースのために、変更された部分構成が再提出される。実際には、優先順位間のトレードオフが望ましい。

（実施例３４）
（トポロジが変更され得る所望の構成に収束する解空間のトラバースの例）
図２４に、可能な動作可能複数ビデオ出力構成の組合せのグラフをトラバースする方法の別の例２４００の流れ図を示す。ただし、この例は、所望の動作可能ビデオ表示ネットワーク暫定的構成の決定時にトポロジを変更する可能性を含む。

２４０２で、特定のトポロジが選択される。

２４０４で、ビデオ表示ソースモードが選択され、ビデオ表示ソース上にピンニングされる。

２４０６で、（エニュメレーションなどによって）任意のビデオ表示ターゲットモードが利用可能であるかどうか判定される。そうである場合、プロセスは２４０８に進む。そうでない場合、プロセスは２４１０に進む。

２４０８で、ビデオ表示ターゲットモードが選択され、ビデオ表示ターゲットにピンニングされる。次いで、この方法は（コミット後などに）終了し得る。

２４１０で、以前に選択されたトポロジを持つことが、選択されたビデオ表示ソースモードを持つことより重要であるかどうか判定される。答えがＹＥＳである場合、２４１２で異なるビデオ表示ソースモードが選択され、そのビデオ表示ソース上にピンニングされ、プロセスは２４０６に戻る。そうでない場合、２４１４で異なるトポロジが選択され、プロセスは２４０４に戻る。

この例は、ソースモードとトポロジの間のトレードオフを示しているが、リソース間の他のトレードオフも可能である。さらに、その他の例のいくつかに示すように、所望のオプションに優先順位を付けることができる。

この例で実施され、図２４に示す論理は、先に、図１６で示したのと同様に、複数のビデオ表示ソースおよび／または複数のビデオ表示ターゲットに適応するように変更され得る。例えば、図２４の２４１０〜２４１４で実施される論理は、図１６の１６０８と１６１０の間、および／または１６１６と１６１８の間に挿入することができる。

この例では、サーチは、図２４の２４０２で行われるように、初期トポロジを用いて開始する。そのトポロジにおけるビデオ表示パスでは、ビデオ表示ターゲットモードがそのビデオ表示パスのビデオ表示ネットワークターゲットにピンニングされる前に、ビデオ表示ソースモードがそのビデオ表示パスのビデオ表示ネットワークソースにピンニングされ得る。例えば、サーチは、単一のソースビュービデオ表示パスを用いて開始し、ソースとターゲット両方にモードをピンニングし、次いで、別のビデオ表示パスをそこに付加することによってトポロジを増大させる。代替として、トポロジは、ビデオ表示ソースモードだけがピンニングされるときにも変更され得る。

（実施例３５）
（構成サービスの使用の例）
構成サービスの実行例は、次にビデオ表示ネットワークの構成を始めることができる。この例では、そのトポロジに３つのソースを有するビデオ表示ネットワーク、およびそれら３つのソースのそれぞれにエニュメレーションされた以下のビデオ表示ソースモード集合を想定する。

クライアントが、ビデオ表示ネットワークソースのそれぞれで可能な最高の空間解像度を得ようとしており、第１のビデオ表示ネットワークソースが最も重要であり、第２のビデオ表示ネットワークソースが次に重要であり、第３の最後のビデオ表示ネットワークソースが最も重要度が低いと想定すると、それは、第１のビデオ表示ネットワークソース上に最高のモードをピンニングしようとするはずであり、それは（４，１２８０×１０２４）である。

しかしながら、そうすることにより、クライアントは第２のビデオ表示ネットワークソース上のモード（４，１２８０×１０２４）、（５，１６００×１２００）、（６，２０００×１５００）を無効化する。クライアントはこのことをまだ知らないため、第２のビデオ表示ネットワークソース上に以前にエニュメレーションされた最高のモード（（６，２０００×１５００）など）をピンニングしようとするが、それは、指定されたビデオ表示ソースモードが無効化されていることを示す状況コードと共に失敗する。

この時点で、クライアントは、ビデオ表示ネットワークソースすべてにわたって利用可能なビデオ表示ソースモードを再エニュメレーションし、以下の３つの集合を獲得する。

クライアントは、次いで、第２のビデオ表示ネットワークソース上に利用可能な最高のビデオ表示ソースモード（（３，１０２４×７６８）など）をピンニングするはずである。しかしながら、この追加モードをサポートすると、ビデオカードは、もはや、第３のビデオ表示ネットワークソース上で（２，８００×６００）も（３，１０２４×７６８）もサポートすることができない。

この場合もやはりこの事実を知らないため、クライアントは、そのビデオ表示ソースに以前にエニュメレーションされた最高のモード（（３，１０２４×７６８）など）をピンニングしようとする。それに失敗すると、クライアントはすべてのソースにわたって利用可能なモードを再エニュメレーションし、以下の集合

を取得し、第３の最後のビデオ表示ネットワークソースにただ１つのモード選択肢が残される。

この時点で、クライアントは、このソースモード分配を受け入れ、それから動作可能なビデオ表示ネットワークに到達するためにターゲットモードをピンニングすることもでき、あるいは、６４０×４８０空間解像度が十分な高さではないと判断し、より適した解（例えば、第１のビデオ表示ネットワークソース上に１２８０×１０２４空間解像度を設定することを伴わないもの、あるいは、そのトポロジに２つだけのビデオ表示ネットワークソースを有するものなど）を見出すために引き返すこともできる。

以下の印を付けたモードリストは全プロセスを要約するものであり、各集合における太字で下線を付したモードはピンニングされたモードを表し、取り消し線を付したモードは、第１のビデオ表示ネットワークターゲット上のモードがピンニングされたときに無効化されたモードを表し、二重取り消し線を付したモードは、第２のビデオ表示ネットワークターゲットがピンニングされたときに無効化されたモードを表す。

前述のアルゴリズムは、レンダリングマルチモード収束に単純化した貪欲法(Greedy approach)を用いるものであり、バックトラックを用いないことがわかる。そうではなく、クライアントがより複雑なサーチ（深さ優先サーチなど）を用いてより適するレンダリングマルチモードを見出すこともできる。また、前述のアルゴリズムは、図１６の方法例１６００の場合のように、収束プロセスを通して所望のトポロジが固定されるものと想定していることもわかる。

（実施例３６）
（マルチモニタ／マルチビューシステムの例）
図２５は、マルチモニタ／マルチビューシステムの一例２５００の図であり、以下の形式論を用いて説明することができる。場合によっては、「ビデオ表示ネットワーク」の代わりに「ＶｉｄＰＮ」という用語が用いられ、「ビデオ表示（video presenting）」の代わりに「ビデオ表示（video present）」が用いられることもある。また、場合によっては、「暫定的構成」に言及するのに「実装形態」という用語も用いられる。システム２５００は、本明細書で説明する各例のいずれとも一緒に用いることができる。
１．Ｍはモニタの集合２５１０ｍ＝（δ_Ｍ）であり、式中、
ａ．モニタｍは、ビデオレンダリングデバイスの出力を監視するビデオ表示装置であり、
ｂ．δ_Ｍ∈｛ＥＤＩＤ ｖ１．０，ＥＤＩＤ ｖ１．１，ＥＤＩＤ ｖ１．２，ＥＤＩＤ ｖ１．３，ＤＩＥＸＴを伴うＥＤＩＤ ｖ１．３｝はモニタ記述子である。
２．Ｔは、１台のビデオレンダリングデバイスの、ビデオ表示ターゲットの集合２５２０ｔ＝（δ_Ｔ）であり、式中、
ａ．δ_Ｔ∈｛（形式［δ_Ｔ］，ＨＰＤ認識［δ_Ｔ］）｝はビデオ表示ターゲット記述子であり、式中、
ｉ．形式［δ_Ｔ］∈ＶＣ≡｛ＤＶＩ，ＨＤＭＩ，ＨＤＭＩ−２，ＨＤ−１５，ＢＮＣ，４ピンＳビデオ,７ピンＳビデオ，ＲＦ，ＲＣＡコンポジット，３コンポーネントＲＣＡ，その他｝はビデオ出力形式タイプであり、
ｉｉ．ＨＰＤ認識［δ_Ｔ］∈ＨＰＤ≡｛割り込み可能,非破壊的にポーリング,破壊的にポーリング,なし｝はビデオ出力ＨＰＤ認識であり、その場合ビデオ出力は、以下を備える。
１．割り込み可能ＨＰＤ認識 ビデオミニポートがＯＳにモニタ到達／離脱に関して非同期的に通知することができる場合に限る。
２．非破壊的にポーリングされるＨＰＤ認識 ビデオミニポートが、視覚的アーチファクトを生じずに、基礎をなすハードウェアを定期的にポーリングすることによってのみＯＳにモニタ到達／離脱を報告することができる場合に限る。
３．破壊的にポーリングされるＨＰＤ認識 ビデオミニポートが、基礎をなすハードウェアを散発的にポーリングすることによってのみＯＳにモニタ到達／離脱を報告することができ、各ポーリングで視覚的アーチファクトを生じる場合に限る。
４．ＨＰＤ認識なし ビデオミニポートがモニタ到達／離脱を認識せず、したがって、ＯＳにそのようなイベントの発生を非同期的に通知することも、同期的に報告することもできない場合に限る。
ｂ．符号化∈（ＶＥ）^ＶＣはビデオ符号化タイプであり、式中、
ｉ．ＶＥ≡｛Ｄｉｇｉｔａｌ＿ＹＣｂＣｒ，Ｄｉｇｉｔａｌ＿ＲＧＢ，Ａｎａｌｏｇ＿ＹＰｂＰｒ，Ａｎａｌｏｇ＿ＲＧＢ，Ａｎａｌｏｇ＿ＹＣ，Ａｎａｌｏｇ＿Ｃｏｍｐｏｓｉｔｅ，Ｏｔｈｅｒ｝はビデオ符号化タイプであり、ビデオ出力コネクタは、以下に示す表１で指定されるようにそれぞれのビデオ出力符号化にマップされる（注：ＤＤＣサポートの存在は、モニタ記述子、δ_Ｍを獲得する可能性を示唆する）。

ｃ．同期されている：

は、ビデオ出力同期述部であり、２つの出力が与えられたとすると、それらが相互に同期しているか否かを判定する。
３．Κはビデオ表示コーデックの集合２５３０κ＝（δ_Κ）であり、式中、
ａ． δ_Κはビデオコーデック記述子である。
４．Σはビデオ表示ソースの集合２５５０σ＝（δ_Σ）であり、式中、
ａ．δ_Σ∈｛線形，その他｝はビデオ表示ソース記述子であり、
ｂ．モニタ上に表示される各ビデオ表示ネットワーク入力のコンテンツをビューという。
５．Ｖはビューの集合２５６０ｖ＝（δ_Ｖ）であり、式中、
ａ．δ_Ｖ∈｛（重要度［ｄ_Ｖ］，向き［ｄ_Ｖ］）｝はビュー記述子であり、式中、
ｉ．重要度［ｄ_Ｖ］

｛１次，２次，その他｝
ｉｉ．向き［ｄ_Ｖ］

｛左，右，中央，その他｝
である。
６．

は３２ビット空間座標の集合である。

７．Θは、表示モードの集合θ＝（ｗ_Θ，ｈ_Θ，ｒ_Θ，ｆ_Θ）であり、式中、
ａ．ｗ_Θ∈Ｓ＼｛０｝は表示モード幅である。
ｂ．ｈ_Θ∈Ｓ＼｛０｝は表示モード高さである。
ｃ．ｒ_Θ∈Ｒ_Θは表示モードフレーム速度であり、式中、
ｉ．Ｒ_Θ≡｛ａ．ｂ｜ａ，ｂ

｛１．．０ｘＦＦＦＦ｝｝は、Ｈｚ単位の表示モードフレーム速度の集合である。

ｄ．ｆ_Θ∈Ｆ_Θは表示モード単位形式（すなわちモニタの有効色解像度、すなわちモニタ技術の関数である物理的パラメータ）であり、式中、
ｉ．Ｆ_Σ≡｛１ビット，５ビット，６ビット，８ビット，１０ビット，１２ビット，１６ビット，１８ビット，３２ビット，以下未定｝は表示モード色解像度の集合である。
ｅ．ｇ_Θ∈［１．０，＋∞）∪｛ＳＤ−６０１，ＨＤ−７０９｝は、モニタ技術の輝度応答関数であるモニタ転送関数（すなわちモニタガンマ）である。

８．Βはビデオ表示ターゲットモードの集合β＝（Ａ_Β，Ｔ_Β，Δ（Ａ_ΒＴ_Β），ｆ_Β，ｖｒ_Β，ｈｒ_Β，ｃｒ_Β，ｏ_Β，ｃｐ_Β，ｇ_Β，Ｔ_{Β，ＹＵＶ→ＲＧＢ}，ｂｐｏ_Β，ｗｐｏ_Β，ｐｍ_Β）であり、また、表示ターゲットモードとも呼ばれ、式中、
ａ．Ａ_Β∈｛（Ｗｉｄｔｈ［Ａ_Β］，Ｈｅｉｇｈｔ［Ａ_Β］）｝は、ビデオ表示ターゲットモードアクティブ領域であり、式中、
ｉ．Ｗｉｄｔｈ［Ａ_Β］はビデオ表示モードアクティブ領域幅である。
ｉｉ．Ｈｅｉｇｈｔ［Ａ_Β］はビデオ表示モードアクティブ領域高さである。
ｂ．Ｔ_Β∈｛（Ｗｉｄｔｈ［Ｔ_Β］，Ｈｅｉｇｈｔ［Ｔ_Β］）｝は、ビデオ表示ターゲットモード総領域であり、式中、
ｉ．Ｗｉｄｔｈ［Ｔ_Β］はビデオ表示モード総領域幅である。
ｉｉ．Ｈｅｉｇｈｔ［Ｔ_Β］はビデオ表示モード総領域高さである。
ｃ．Δ（Ａ_ΒＴ_Β）∈｛（ＯｆｆｓｅｔＨｏｒｉｚ［Ａ_Β，Ｔ_Β］，ＯｆｆｓｅｔＶｅｒｔ［Ａ_Β，Ｔ_Β］）｝は、ビデオ表示ターゲットモードのアクティブ領域変位であり、式中、
ｉ．ＯｆｆｓｅｔＨｏｒｉｚ［Ａ_Β，Ｔ_Β］はビデオ表示モードの水平アクティブ領域変位である。
ｉｉ．ＯｆｆｓｅｔＶｅｒｔ［Ａ_Β，Ｔ_Β］はビデオ表示モードの垂直アクティブ領域変位である。
ｄ．ｆ_Β∈Ｆ_Β＝Ｆ_{Β，ａｎａｌｏｇ}∪Ｆ_{Β，ｄｉｇｉｔａｌ}は、ビデオモード画素符号化形式であり、式中、
ｉ．Ｆ_{Β，ｄｉｇｉｔａｌ}≡｛Ｙ１０Ｃｂ１０Ｃｒ１０，Ｙ８Ｃｂ８Ｃｒ８，ｓＲ１０Ｇ１０Ｂ１０，ｓＲ８Ｇ８Ｂ８｝はディジタルビデオモード画素符号化形式の集合である。
ｉｉ．Ｆ_{Β，ａｎａｌｏｇ}≡｛ＹＰｂＰｒ，Ａｎａｌｏｇ＿ＹＣ，Ａｎａｌｏｇ＿Ｃｏｍｐｏｓｉｔｅ，ＲＧＢ｝はアナログビデオモード画素符号化形式の集合である。
ｅ．ｖｒ_Β∈ＶＲ_Βは垂直リフレッシュ速度であり、垂直同期速度、あるいは垂直帰線周波数とも呼ばれ、式中、
ｉ．ＶＲ_Β≡｛ａ．ｂ｜ａ，ｂ

｛１．．０ｘＦＦＦＦＦＦＦＦ｝｝は、Ｈｚ単位の整数垂直リフレッシュ速度(rationalvertical refresh rate)の集合であり、普通、５０から２００Ｈｚの範囲内にある。

ｆ．ｈｒ_Β∈ＨＲ_Βは水平リフレッシュ速度であり、水平同期速度、ライン速度、あるいは水平帰線周波数とも呼ばれ、式中、
ｉ．ＨＲ_Β≡｛ａ．ｂ｜ａ，ｂ

｛１．．０ｘＦＦＦＦＦＦＦＦ｝｝は、Ｈｚ単位の分数水平リフレッシュ速度(fractional horizontal refresh rate)の集合であり、普通、１０から２００ＫＨｚの範囲内にある。

ｇ．ｃｒ_Β∈ＣＲ_Βは画素クロック速度であり、式中、
ｉ．ＣＲ_Β≡｛ａ｜ａ

｛１．．０ｘＦＦＦＦＦＦＦＦ｝｝はＨｚ単位の画素クロック速度の集合であり、普通、１から５００ＭＨｚの範囲内にある。

ｈ．ｏ_Β∈Ｏ_Βはコンテンツ順序であり、式中、
ｉ．Ｏ_Β≡｛Ｐｒｏｇｒｅｓｓｉｖｅ，Ｉｎｔｅｒｌａｃｅｄ＿ｕｐｐｅｒＦｉｅｌｄＦｉｒｓｔ，Ｉｎｔｅｒｌａｃｅｄ＿ｌｏｗｅｒＦｉｅｌｄＦｉｒｓｔ｝は、コンテンツ順序タイプの集合であり、式中、プログレッシブ方式コンテンツ順序でのフィールド速度＝垂直同期速度であり、インターレース方式コンテンツ順序でのフィールド速度＝２ｘ垂直同期速度である。

ｉ．ｃｐ_Β∈ＣＰ_Βは原色である（（ｘ，ｙ）で表された３原色であり、ｘ＝Ｘ／（Ｘ＋Ｙ＋Ｚ）およびｙ＝Ｙ／（Ｘ＋Ｙ＋Ｚ）であり、何らかの仕様に関連する）。
ｊ．ｗｐｒ_Β∈ＣＰ_Βは白色点基準（すなわち基準白色）である。
ｋ．ｇ_Β∈［１．０，＋∞）∪｛ＳＤ−６０１，ＨＤ−７０９｝は転送関数の指数（すなわちガンマ係数）である。
ｌ．Ｔ_{Β，ＹＵＶ→ＲＧＢ}はＹ'Ｕ'Ｖ'からＲ’Ｇ'Ｂ’への色空間変換マトリクスである。
ｍ．

は黒色点オフセット（すなわちセットアップ電圧）である。

ｎ．

は白色点オフセットである。

ｏ．

はビデオ表示ターゲットモード優先序数であり、式中、モード優先度は｛０ｘ０１．．０ｘｆｆ｝の範囲によって表され、０ｘ０１が最高の優先度を示し、０ｘｆｆが最低の優先度、または無関係なモード優先を示す。０ｘ００は不明／初期設定なしに予約される。

一定のビデオモードが業界規模の（事実上と正式両方の）標準化によって定義される。これらのモードは、以下の表２に列記するもの、ならびに以下のＶＥＳＡ汎用タイミング式（ＧＴＦ）によって定義される連続的なモードの集合を含み得る。

β_ＧＴＦ≡β_{ＧＴＦ，ＶＲ}∪β_{ＧＴＦ，ＨＲ}∪β_{ＧＴＦ，ＣＲ}
式中、

である。

９．Γは、ビデオ表示ソースモードの集合、γ＝（ｗ_Γ，ｈ_Γ，ｆ_Γ，ψ_Γ，ｎ_Γ，ｐｍ_Γ）であり、表示ソースモードとも呼ばれ、式中、
ａ．ｗ_Γ∈Ｓ＼｛０｝はビデオ表示ソースモード幅である。
ｂ．ｈ_Γ∈Ｓ＼｛０｝はビデオ表示ソースモード高さである。
ｃ．ｆ_Γ∈Ｆ_Γはビデオ表示ソースモード単位形式であり、式中、
ｉ．Ｆ_Γはビデオ表示ソースモード単位形式の集合であり、以下の２つの主要なサブクラスに類別され得る。
１．最新のＤｉｒｅｃｔＸリリースにおけるＤ３ＤＦＯＲＭＡＴエニュメレーションタイプによって定義される、グラフィックスビデオ表示ソースモード単位形式。
２．（未定）によって定義される、テキストビデオ表示ソースモード単位形式。
ｄ．ψ_Γ∈Ψ_Γは、レンダリング時に使用されるラスタライズされたグラフィックスフィルタリング技法であり、式中、
ｉ．Ψ_Γは、最新のＤｉｒｅｃｔＸリリースにおけるＤ３ＤＤＤＩＭＵＬＴＩＳＡＭＰＬＥ＿ＴＹＰＥエニュメレーションタイプによって定義される、ラスタライズされたグラフィックスフィルタリング技法の集合である。
ｅ．ｎ_Γ∈Ｎは、１次サーフェスチェーン長さ（すなわち１次サーフェスチェーン中のサーフェスの数）である。
ｆ．

は、ビデオ表示ソースモード優先序数であり、式中、モード優先度は｛０ｘ０１．．０ｘｆｆ｝の範囲によって表され、０ｘ０１が最高の優先度を示し、０ｘｆｆが最低の優先度または無関係なモード優先を示す。０ｘ００は不明／初期設定なしに予約される。
１０．ρ_ＭＴ∈Ｔ^Ｍは、モニタ接続性トポロジ、すなわちモニタから、それらが接続されるビデオ表示ターゲットへのマッピングである。
１１．ρ_ＴＫ∈Ｋ^Ｔは、ビデオ表示ターゲット／コーデックトポロジ、すなわちビデオ表示ターゲットから、それらを駆動するビデオ表示コーデックへのマッピングであり、ビデオカード上のプログラマブルクロスバーによって定義される。
１２．ρ_ＫΣ∈Σ^Ｋは、ビデオ表示コーデック／ソーストポロジ、すなわちビデオ表示コーデックから、コーデックがそこから視覚コンテンツをストリーミングするビデオ表示ソースへのマッピングである。
１３．ρ_ＴΣ∈Σ^Ｔは、ビデオ表示ターゲット／ソーストポロジ２５４０、すなわち、その基礎をなすビデオ出力コーデックがそこから視覚コンテンツをストリーミングするビデオ表示ソースから、そのコンテンツがそこにストリーミングされるビデオ表示ターゲットへのマッピングである。
１４．

は、サポートされるＶｉｄＰＮトポロジの集合、すなわちビデオ表示ターゲットの集合とビデオ表示ソースの集合からなる対

から、その対でのサポートされるＶｉｄＰＮ実装形態のそれぞれの集合へのマッピングであり、各実装形態は、ビデオ表示ソースが、ビデオ出力コーデックを介して、それらが駆動するビデオ表示ターゲットに経路指定される方法を明示的に指定する。
１５．

をＶｉｄＰＮ実装形態といい、式中、
ａ．

はＶｉｄＰＮビデオ表示ターゲットの集合である。

ｂ．

はＶｉｄＰＮビデオ表示ソースの集合である。

ｃ．

はＶｉｄＰＮトポロジの集合である。
１６．ρ_ΣＶ∈Ｖ^Σおよびρ_ＶΣ∈Σ^Ｖは、ビューと基礎をなすビデオ表示ソースの間の１：１対応であり、すなわちρ_ΣＶおよびρ_ＶΣはΣとＶの間で同型である。
１７．

は、マルチコーデックビデオ表示ターゲットモード集合ベクトル、すなわち、ビデオ出力コーデックから、それらがサポートするビデオ表示ターゲットモード集合へのマッピングである。
１８．

は、マルチターゲットビデオ表示ターゲットモード集合ベクトル、すなわち、ビデオ表示ターゲットから、それらがサポートするビデオ表示ターゲットモード集合へのマッピングである。
１９．

は、マルチモニタビデオモニタソースモード集合ベクトル、すなわち、モニタから、それらがサポートするビデオモニタソースモード集合へのマッピングである。
２０．

は、マルチソースビデオ表示ソースモード集合ベクトル、すなわち、ビデオ表示ソースから、それらがサポートするビデオ表示ソースモード集合へのマッピングである。
２１．

は、マルチコーデックビデオ表示ターゲットモードベクトル、すなわち、ビデオ出力コーデックから、それらのコーデックが、それらが接続されたビデオ表示ターゲットのビデオ出力上で駆動するビデオ表示ターゲットモードへのマッピングである。
２２．

は、マルチ出力ビデオ表示ターゲットモードベクトル、すなわち、ビデオ表示ターゲットから、それらのビデオ表示ターゲット上で、それらが接続されたビデオ出力コーデックによって駆動されているビデオ表示ターゲットモードへのマッピングである。
２３．

は、マルチモニタビデオ表示ターゲットモードベクトル、すなわち、モニタから、それらの上で、それらが接続されたビデオ表示ターゲットによって駆動されているビデオ表示ターゲットモードへのマッピングである。
２４．

は、マルチモニタ表示モードベクトル、すなわち、モニタから、モニタの入力上で駆動される基礎をなすビデオ表示ターゲットモードの結果として、それらの上に表示される表示モードへのマッピングである。
２５．

は、マルチソースビデオ表示ソースベクトル、すなわち、ビデオ表示ソースから、それらのソースが設定されるビデオ表示ソースモードへのマッピングである。
２６．ＶｉｄＰＮ実装形態は、ビデオ表示ソースモードが、そのビデオ表示ソースのすべてにおいて正常に選択されている場合に限って半動作可能であるという。
２７．ＶｉｄＰＮ実装形態は、それが半動作可能であり、かつビデオ表示ターゲットモードがそのビデオ表示ターゲットのすべてにおいて正常に選択されている場合に限って動作可能であるという。

（実施例３７）
（定義の例）
複雑な相互依存性の集合が関与していると仮定して、いくつかの形式的定義がいくつかの実装形態に使用され得る。いくつかの（ビュー，出力）対が、ビデオ出力コーデック（ＣＲＴＣ ＤＡＣ、ＴＭＤＳなど）への入力を表し得るビデオ表示ソースと、ビデオカード（ＨＤ−１５、ＤＶＩ、Ｓビデオなど）上のビデオ出力を表し得るビデオ表示ターゲットに組み込まれ得る。

表示モードが、グラフィックススタックがユーザに表示されるレンダリングコンテンツを提供するための１次サーフェス形式を指定し得るビデオ表示ソースモードと、それぞれのビデオ出力で駆動されるビデオ信号形式を指定し得るビデオ表示ターゲットモードに組み込まれ得る。

マルチ出力ビデオカードのビデオ表示機能は、ビデオ表示ソースの集合を、ＶｉｄＰＮトポロジを介してビデオ表示ターゲットの集合に関連付けることができる、ビデオ表示ネットワーク（ＶｉｄＰＮ）の概念によってモデル化される。ＶｉｄＰＮは、ビデオ表示ソースモードが、そのビデオ表示ソースのそれぞれでピンニングされる場合に限って半動作可能とみなされ得る。ＶｉｄＰＮは、それが半動作可能であり、かつビデオ表示ターゲットモードが、そのビデオ表示ターゲットのそれぞれでピンニングされる場合に限って動作可能とみなされ得る。

単一のビデオ表示ソースと単一のビデオ表示ターゲットとの関連をビデオ表示パスと呼ぶことができる。単一のビデオ表示ソースと複数のビデオ表示ターゲットとの関連をビデオ表示マルチパスと呼ぶことができる。

前述の定義を用いると、ビデオミニポートのジョブは、表示モード管理の状況においては、それが駆動しているそれぞれのビデオカード上のビデオ表示構成の状態を表すアクティブなＶｉｄＰＮを管理するとともに、そのそれぞれがアクティブと設定され得る、動作可能なＶｉｄＰＮを増分的に構築するためにクライアントの要求に応えることであると説明され得る。

（実施例３８）
（複数のビデオ出力表示モード解の例）
マルチ出力ビデオカードに接続されたモニタ上の表示モードを変更すれば、ビデオミニポートの開発者らが、その場合、同じ基礎をなす物理装置を駆動していた特定のビデオドライバスタック間の複雑な同期を実施しなければならなかった、その世界の「単一出力動作」ビューに苦慮することもなくなり、単一のビデオドライバスタックによってサービスされる所与のビデオカード上での動作可能なＶｉｄＰＮの明示的なトランザクションベースのコミットによって置き換えられ得る。

マルチ出力ビデオ表示モード解は、以下のような複数の基準に左右され得る。それらは、（ａ）ハードウェア制限事項（それぞれのビデオ表示ターゲットに接続されたモニタによってサポートされるビデオモード集合など）、（ｂ）動作モード考慮事項（それぞれのビデオ表示ターゲットに接続されたモニタによって優先される特定のビデオモードなど）、（ｃ）性能考慮事項（ビデオ出力コーデックによるビデオメモリバスでの競合の低減によって達成されるレンダリング性能の改善など）、（ｄ）電力管理考慮事項（利用されないビデオ出力コーデックを使用不能にし、その機能を抑制することによって達成されるビデオカードの電力消費の低減など）、（ｅ）熱放散考慮事項（あるユニットには、別のユニットが動作している間に冷却する機会が与えられ、逆の場合も同じであり、ゆえに、ビデオカードによって放散されるＪ／秒の数が一定の所望の上限を超えて増大することがない、複数のユニット間で連続的に相互切換えを行うことによって達成されるビデオカードの動作温度の低減など）、および（ｆ）有用性考慮事項（すべてのモニタを優先モードで駆動することができないと想定すると、ユーザの１次モニタ上でモニタの優先モードを駆動することが、それを第２のモニタ上で駆動するより重要であり、その場合どのモニタが１次であるかの決定は、ユーザ指定の動作モードの関数であるなど）である。例えば、ＤＶＩ ＬＣＤ、ＳビデオＨＤＴＶ、およびＨＤ−１５ ＣＲＴ／３Ｄ眼鏡が与えられたとすると、ユーザは、最良の明瞭さを有するＤＶＩ ＬＣＤ上で作業／読取り／ブラウズを行い、最大のアクティブ画素領域を有するＳビデオＨＤＴＶ上で映画を見、最高のリフレッシュ速度および最適なゲーム体験をサポートするＨＤ−１５ ＣＲＴ／３Ｄ眼鏡でゲームをプレーしようとすることができる。

（実施例３９）
（解空間の例）
そのターゲット上で利用可能な、可能なすべてのビデオ表示ターゲットモード集合、および利用可能なビデオ表示ソースモードをその入力間で分配する様々なすべての方法を備え、それらのそれぞれの可用性は、（基礎をなすビデオコーデックにおけるハードウェアスケーリングの存在などの因子に基づく）それぞれの出力上で駆動されるビデオモードの関数である、可能なすべてのＶｉｄＰＮ実装形態を含む解空間は、単純で強引なエニュメレーションでは解決困難なことがある。Ｔビデオ表示ターゲット、Ｋコーデック、およびΣビデオ表示ソースの一般的な場合での強引でない手法は、古典的な３者間グラフマッチング問題と類似しており、それはＮＰＣであることが知られている（例えば、多項式時間で実行され、理想的な、または大域的に最適な解を見出す公知のアルゴリズムがないなど）。理想的な解に可能な限り近い近似解を求めることが望ましい。

（実施例４０）
（複雑さの例）
どの構成が動作可能であるか決定することは複雑なタスクである。例えば、所与の構成について、以下を考慮することが必要になり得る。

１．どのビデオ出力を駆動するのにどのビデオ出力コーデックが使用され得るか
２．どのレンダリングターゲットの１次サーフェスをビデオ信号に変換するのにどのビデオコーデックが使用され得るか
３．ビデオ出力間での可能なビデオモード集合分配はどのようなものか
４．各ビデオコーデックが駆動することのできる可能なビデオモードは何か
５．レンダリングターゲット間での可能なグラフィックスレンダリングモード分配はどのようなものか。

サーチを複雑にする問題のいくつかは、コードが不十分なリソースであること、およびコーデックが普通は出力より少ないことであり、そのため、クローンビューでは、可能な場合は常に、複数の出力にわたって単一のコーデックを共用することが有益である。そのような手法は、各モニタが両方ともサポートする共通ビデオモードを持たない場合には、機能しないことがある同じビデオモードを両方のモニタに強制するという欠点を持つ（例えば、ＣＲＴは最大１２８０×１０２４まで上げることができるが、ＬＣＤは１６００×１２００だけをサポートすることがある）。それらがビデオモードを共用する場合であっても、そのような手法はモニタを駆動する理想的な方法ではないこともある。というのは、そのビデオモードがそれらのモニタの優先モードではないことがあるからである。例えば、あるプロジェクタは、６４０×４８０、８００×６００、１０２４×７６８（ネイティブ）、および１２８０×１０２４をサポートする。そのＬＣＤは、６４０×４８０、８００×６００、１０２４×７６８、１２８０×１０２４、および１４００×１０５０（ネイティブ）をサポートする。これら２つの間でコーデックを共用することは、１つのドライバだけがその優先ビデオモードで駆動され得ることを意味する。

あるいは、あるＬＣＤは、１０２４×７６８、１２８０×１０２４、１６００×１２００（優先）をサポートすることができるとする。そして、あるプロジェクタは、６４０×４８０、８００×６００（優先）、および１０２４×７６８をサポートすることができるものとする。共用は、どちらのモニタもその優先モードで駆動され得ないことを意味する。

また、すべてのコーデックが等しく作成されるとは限らない。ビデオカードは、１つが他方より多くのモードを実行し、あるいはそれらのいくつかをより適切に実行することができる異なるコーデックを持つことがある。特定のモードが特定のコーデックで利用可能である（例えば、１つのコーデックは１６ビットだけを行うことができ、別のコーデックは３２ビットモードだけを行うことができるなど）場合には、状況がより一層複雑になり得る。

最後に、クロスバーを用いてコーデックを異なる出力に経路指定変更することができるが、その制限事項、およびコーデックのビデオ出力の技術との非互換性の結果として、特定のコーデックが特定の出力の部分集合に限定されることになり得る（例えば、ＣＲＴＣはＤＶＩを駆動することができず、ＴＭＤＳはＳビデオのＨＤ−１５を駆動することができないなど）。

可能なすべての実装形態をエニュメレーションするという強引な手法(brute force approach)を回避するために、代わりに、収束手法が用いられ得る。

（実施例４１）
（ビデオドライバに決定を委ねることの利点の例）
本明細書で説明する各例のいずれにおいても、特定の暫定的構成がそのビデオアダプタで動作可能であるかどうかの決定は、デバイスドライバによって達成され（に委ねられ）得る。１つの可能な代替方法は、ビデオアダプタの集合（すべての知られているビデオアダプタなど）に及ぶ決定を処理することができる一般例の一般解を構築することである。しかしながら、そのような解は、膨大な数のシナリオを処理する論理を必要とするはずである。

そうではなく、デバイスドライバに決定を委ねることによって、デバイスドライバをより軽量にすることができ、それが一般例を解決する必要がなくなる。例えば、デバイスドライバは、対応するビデオアダプタが実施することのできない（例えば、ハードウェアに存在しない）シナリオを処理するための論理を含む必要がない。このようにして、デバイスドライバのサイズが縮小され、（一般解に比べて）その性能（速度など）が増大され得る。

（実施例４２）
（トポロジとソース／ターゲットの間の比較の例）
トポロジは、その複数のオプション（ビデオ表示パスなど）が同時に構成され得る、構成可能なリソースとして扱われ得る。一度に１つのオプション（ソース／ターゲットモードなど）だけが構成され得るビデオ表示ソース／ターゲットに比較する。モードは、所与のモード集合内で相互に排他的とすることができ、他方、表示パスは必ずしも相互に排他的とする必要はないが、そうすることもできる。

（実施例４３）
（手法例）
２つの可能な手法は、照会に基づく手法およびトラバースに基づく手法を含む。照会に基づく手法には、ＯＳによって提供された要件の集合を満たす解を求めて表示ミニポートに照会することが関与し得る。トラバースに基づく手法には、それぞれ、そのターゲットとソースに選択された所望のビデオ表示ターゲットモードとビデオ表示ソースモードを用いて動作可能なＶｉｄＰＮ実装形態を増分的に構築することによって、解空間をナビゲートすることが関与し得る。ＶｉｄＰＮのほぼ最適な実装形態を決定することは、ビデオミニポートに任せることができる。

代替として、ＯＳは、ビデオミニポートに、（１）ＤＤＩ側でのそれに対する適合が、ビデオ表示ターゲットモードエニュメレーション時にＯＳによって検証され得る、そこに接続されたモニタを持つ各ＶｉｄＰＮターゲットごとのビデオ表示ターゲットモード集合要件（例えば、ビデオカードは、接続されたモニタによってサポートされないビデオ信号モードを公開してはならないなど）、および（２）表示ミニポートが、優先モニタソースモードが、まず、より好ましいモニタ上でサポートされるＶｉｄＰＮ実装形態を見出すことができ、システムに接続されたあらゆるモニタ上での優先モニタソースモードサポートがその理想解である、供給された優先順位方式に基づいてモニタの優先モニタソースモードをサポートするビデオ表示ターゲットモード集合の指針を供給することもできる。

ＶｉｄＰＮソース上でサポートされるグラフィックスビデオ表示ソースモードのほぼ最適な分配を見出すことは、グラフィックスサブシステムのクライアント（シェルなど）に任せることができ、その場合、ドライバは、単に、指定された動作状態下でのビデオカードの機能を報告するＡＰＩによって、それぞれのビデオ表示ソースモード集合分配解空間をトラバースすることができることを公開するだけである。貪欲法と同様に単純な手法も、グラフベースのサーチと同様に複雑な手法も用いられ得る。

（実施例４４）
（コンピューティング環境の例）
図２６および以下の説明は、開示の技術が実施され得るコンピューティング環境の一例の簡単な一般的説明を提供するためのものである。必須ではないが、以下では、開示の技術を、パーソナルコンピュータ（ＰＣ）によって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明する。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、開示の技術は、ハンドヘルド機器、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、他のコンピュータシステム構成を用いて実施することもできる。また、開示の技術は、タスクが、通信ネットワークを介してリンクされたリモート処理装置によって実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモート両方の記憶装置に位置することができる。

図２６を参照すると、開示の技術を実施するシステムの一例は、処理装置２６０２、システムメモリ２６０４、およびシステムメモリ２６０４を含む様々なシステムコンポーネントを処理装置２６０２に結合するシステムバス２６０６を備える従来型のＰＣ２６００の形で汎用コンピューティングデバイスを含む。システムバス２６０６は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかの種類のバス構造のいずれでもよい。システムメモリ２６０４は、読取り専用メモリ（ＲＯＭ）２６０８およびランダムアクセスメモリ（ＲＡＭ）２６１０を含む。ＰＣ２６００内の諸要素間の情報転送を支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）２６１２は、ＲＯＭ２６０８に格納される。

ＰＣ２６００は、さらに、ハードディスク（図示せず）との間で読取りおよび書込みを行うハードディスクドライブ２６１４、取り外し可能磁気ディスク２６１７との間で読取りおよび書込みを行う磁気ディスクドライブ２６１６、および取り外し可能光ディスク２６１９（ＣＤ−ＲＯＭなどの光媒体）との間で読取りおよび書込みを行う光ディスクドライブ２６１８を含む。ハードディスクドライブ２６１４、磁気ディスクドライブ２６１６、および光ディスクドライブ２６１８は、それぞれ、ハードディスクドライブインタフェース２６２０、磁気ディスクドライブインタフェース２６２２、および光ドライブインタフェース２６２４によってシステムバス２６０６に接続される。各ドライブおよびそれに関連するコンピュータ可読媒体は、ＰＣ２６００にコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性記憶を提供する。この例示的動作環境では、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ＣＤ、ＤＶＤ、ＲＡＭ、ＲＯＭなど、ＰＣからアクセス可能なデータを格納することのできる他の種類のコンピュータ可読媒体を使用することもできる。

ハードディスクドライブ、磁気ディスク２６１７、光ディスク２６１９、ＲＯＭ２６０８、またはＲＡＭ２６１０には、オペレーティングシステム２６３０、１つまたは複数のアプリケーションプログラム２６３２、その他のプログラムモジュール２６３４、およびプログラムデータ２６３６を含むいくつかのプログラムモジュールを格納することができる。ユーザは、キーボード２６４０やポインティングデバイス２６４２（マウスなど）といった入力装置を介してＰＣ２６００にコマンドおよび情報を入力することができる。他の入力装置（図示せず）は、ディジタルカメラ、マイクロホン、ジョイスティック、ゲームパッド、衛生パラボラアンテナ、スキャナなどを含み得る。上記その他の入力装置は、しばしば、システムバス２６０６に結合されたシリアルポートインタフェース２６４４を介して処理装置２６０２に接続されるが、パラレルポートや、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）といった他のインタフェースによっても接続され得る。システムバス２６０６には、ビデオアダプタ２６４８などのインタフェースを介して、モニタ２６４６または他の種類の表示装置も接続される。スピーカやプリンタ（図示せず）など、他の周辺出力装置も含み得る。

ＰＣ２６００は、リモートコンピュータ２６５０など、１つまたは複数のリモートコンピュータへの論理接続を用いてネットワークで接続された環境で動作することができる。リモートコンピュータ２６５０は、別のＰＣ、サーバ、ルータ、ネットワークＰＣ、またはピアデバイスなど他の一般のネットワークノードとすることができ、図２６には記憶装置２６５２だけしか示されていないが、通常、ＰＣ２６００に関連して前述した諸要素の多くまたはすべてを含む。図２６に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）２６５４および広域ネットワーク（ＷＡＮ）２６５６を含む。そのようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、インターネットでよく見られるものである。

ＬＡＮネットワーク環境で使用されるとき、ＰＣ２６００は、ネットワークインタフェース２６５８を介してＬＡＮ２６５４に接続される。ＷＡＮネットワーク環境で使用されるとき、ＰＣ２６００は、通常、モデム２６６０またはインターネットなどのＷＡＮ２６５６を介して通信を確立する他の手段を含む。モデム２６６０は、内蔵でも外付けでもよく、シリアルポートインタフェース２６４４を介してシステムバス２６０６に接続することができる。ネットワーク化環境では、パーソナルコンピュータ２６００に関連して示すプログラムモジュール、またはその一部は、リモート記憶装置に格納することもできる。図示のネットワーク接続は例示であり、コンピュータ間で通信リンクを確立する他の手段も使用され得る。

（実施例４５）
（仕様例）
以下は、本明細書で説明する様々な技術をサポートするビデオ表示ネットワークを実施するための仕様の一例である。この例では、ビデオ表示ネットワーク（video presenting network）は、「ビデオ表示ネットワーク（video present network）」または「ＶｉｄＰＮ」と呼ばれることがある。このビデオ表示ネットワークでの特定の構成は「ＶｉｄＰＮ実装形態」と呼ばれることがある。

説明する関数は、ＡＰＩやＤＤＩといったプログラマチックインタフェースに一体化することができる。そのようなインタフェースは、オペレーティングシステムなどのクライアントによるアクセスのためにデバイスドライバによって実施され得る。

（実施例４６）
（モニタの相対的重要度の例）
本明細書の各例のいずれにおいても、複数のモニタを処理するビデオドライバ（ビデオミニポートなど）は、推奨される動作可能構成を提供するよう求められることがある。そのような場合、モニタの相対的重要度が指定され得る。例えば、モニタが（例えば、重要度が最大のものから最小のものまで）ランク付けされ得る。その場合、ドライバは、指定された相対的重要度に従って構成を提供することができる。

（実施例４７）
（ステートレス実装形態の例）
本明細書で説明する技術のいくつかは、ビデオドライバが、暫定的構成の状態（例えばそれがピンニングされ、アンピンニングされている）を維持する手法を使用して説明されている。しかしながら、ステートレスの手法も用いられ得る。このやり方では、ビデオドライバは、（暫定的構成などの）状態を追跡する必要がなく、より軽量で簡単なものにすることができる。必要に応じて、クライアントソフトウェアは、所望の構成の決定時に状態を追跡することもできる。

そのような手法では、プログラミングインタフェース（ＤＤＩなど）を用いて、暫定的構成の状態に関する情報が渡され得る。例えば、データ構造を用いて構成詳細が保持され、インタフェースを介して渡され得る。

（実施例４８）
（ステートレスドライバインタフェースの例）
以下は、本明細書で説明する様々な技術をサポートするビデオ表示ネットワークを実施するための、ステートレスビデオ表示ネットワーク管理ミニポートインタフェースを含む、カーネルモードドライバインタフェース（ＤＤＩなど）の一例である。この例では、ビデオ表示ネットワーク（video presenting network）を「ビデオ表示ネットワーク（video present network）」または「ＶｉｄＰＮ」ともいう。ビデオ表示ネットワークの特定の構成を「ＶｉｄＰＮ実装形態」ともいう。また、この例では、「ミニポート」という語を使用するが、そこで説明する技術は、任意の表示アダプタまたはビデオドライバに適用され得る。

カーネルモードドライバの一例は、ビデオミニポートの一部とすることができる。各物理ＧＰＵは独自のアダプタとして扱われ、アダプタは、以下で検索されるHANDLE hAdapterによって表され得る。単一のＧＰＵが複数の出力（ヘッドなど）を持つ場合、それは、やはり、単一アダプタとして扱われ得る。

ミニポートのHwVidQueryInterface関数が、ドライバエントリポイントを検索するために以下のQUERY_INTERFACE構造を用いて呼び出され得る。

HwVidQueryInterface呼び出しは、このインタフェースが正常に検索された場合、NO_ERRORを返し、そうでない場合、適当なエラーコードを返すはずである。ドライバエントリポイントは、以下のD3DKMDDI_INTERFACE構造で返され得る。このインタフェースの照会は、暗黙的にそれを参照することができる。ゆえに、このインタフェースが照会された後でドライバの初期設定に失敗した場合、ドライバが明示的参照を行っていなくても、インタフェース逆参照関数が呼び出され得る。

D3DKMDDI_INTERFACE構造で戻されたhAdapterは、pInterfaceReferenceおよびpInterfaceDereferenceのコンテキストとして渡され得る。それはまた、このインタフェース中のアダプタ関数のhAdapterパラメータでも渡され得る。

インタフェース特有のデータは、ドライバが呼び出すことのできる実行時におけるコールバック関数へのポインタを含むことができる。hAdapterは、実行時のアダプタハンドルとすることができ、アダプタハンドルを要求するコールバックのために渡され得る。

前述のインタフェース以外に、以下の既存のＩＯＣＴＬも使用され得る。

EnumVideoPresentSourceSetは、指定された表示アダプタが持つビデオ表示ソースのリストを獲得するために、それぞれの表示アダプタのレンダリング後(post-rendering)のビデオ表示諸機能を駆動しているＶｉｄＰＮ管理インスタンスによって、システム中の各表示アダプタごとに呼び出され得る。

ミニポートは、INTERFACESPECIFICDATAインタフェースを介してオペレーティングシステムによって提供されたAllocSysMemForOutParamCbコールバックを使用して、システムメモリで、指定された表示アダプタでの要求されたビデオ表示ソースの集合を含むのに十分な大きさのバッファを割り振ることができる。割り振りのサイズは、sizeof（D３DKMDDI_VIDEO_PRESENT_SOURCE_SET）＋sizeof（D３DKMDDI_VIDEO_PRESENT_SOURCE）＊（ビデオ表示ソースの数−１）になるはずである。

出力パラメータのメモリが割り振られると、ミニポートは、以下の定義に基づいてそれにデータを取り込むことができる。

定義中、
・NumOfVideoPresentSources−VideoPresentSourcesに列記されたビデオ表示ソースの数。
・VideoPresentSources−集合中のビデオ表示ソース記述子の配列のアドレス。実際の要素数は、NumOfVideoPresentSourcesで指定される。
以下のように定義されるビデオ表示ソース記述子を用いる。

定義中、
・VideoPresentSourceID−ミニポートおよびオペレーティングシステムによってそれぞれのビデオ表示ソースを参照するのに使用される一意のＩＤ。
・dwReserved−他のビデオ表示ソース記述子属性はここに行く。
以下のように定義されるビデオ表示ソースＩＤを用いる。
ypedef UINT D3DKMDDI_VIDEO_PRESENT_SOURCE_ID
この関数から正常に戻ると、オペレーティングシステムは、出力パラメータで戻されたデータの存続時間の所有権を取ることができ、それを完了したときにそれがサポートする割り振りに要したメモリを割り振り解除することができる。

戻りコード
STATUS_SUCCESSは、ドライバが呼び出しを正常に処理したことを示す。

EnumVideoPresentTargetSetは、指定された表示アダプタが持つビデオ表示ターゲットのリストを獲得するために、それぞれの表示アダプタのレンダリング後のビデオ表示諸機能を駆動しているＶｉｄＰＮ管理インスタンスによって、システム中の各表示アダプタごとに呼び出され得る。

ミニポートは、INTERFACESPECIFICDATAインタフェースを介してオペレーティングシステムによって提供されたAllocSysMemForOutParamCbコールバックを使用して、システムメモリで、指定された表示アダプタのための要求されたビデオ表示ソースの集合を含むのに十分な大きさのバッファを割り振ることができる。割り振りのサイズは、sizeof（D3DKMDDI_VIDEO_PRESENT_TARGET_SET）＋sizeof（D3DKMDDI_VIDEO_PRESENT_TARGET）＊（ビデオ表示ターゲットの数−１）になるはずである。

出力パラメータのメモリが割り振られると、ミニポートは、以下の定義に基づいてそれにデータを取り込むことができる。

定義中、
・NumOfVideoPresentTargets−VideoPresentSourcesに列記されたビデオ表示ターゲットの数。
・VideoPresentSources−集合中のビデオ表示ターゲット記述子の配列のアドレス。実際の要素数は、NumOfVideoPresentTargetsで指定される。
以下のように定義されるビデオ表示ターゲット記述子を用いる。

定義中、
・VideoPresentTargetID−ミニポートおよびオペレーティングシステムによってそれぞれのビデオ表示ターゲットを参照するのに使用される一意のＩＤ。
・VideoOutputTechnology−ビデオ出力技術のタイプ。
・VideoOutputHPDAwareness−ビデオ出力のＨＰＤ認識のタイプ。
・MonitorOrientationAwareness−モニタ方向認識
以下のように定義されるビデオ表示ターゲットＩＤが用いられる。
typedef UINT D3DKMDDI_VIDEO_PRESENT_TARGET_ID
ビデオ出力技術タイプ記述子は以下のように定義され得る。

ビデオ出力ＨＰＤ認識記述子タイプは以下のように定義され得る。

ビデオ出力ＨＰＤ認識は、表示アダプタによってそのビデオ出力上で感知されるモニタ接続性のレベルを表すのに使用することができ、以下の４つのタイプが利用可能である。

１．割り込み可能ＨＰＤ認識−ミニポートがオペレーティングシステムにモニタ到達／離脱に関して非同期的に通知することができる場合に限る。

２．非破壊的にポーリングされるＨＰＤ認識−ミニポートは、オペレーティングシステムにモニタ到達／離脱に関して非同期的に通知することはできないが、オペレーティングシステムは、視覚的アーチファクトを生じずに、モニタの有無を定期的にポーリングすることができる場合に限る。

３．破壊的にポーリングされるＨＰＤ認識−ミニポートは、オペレーティングシステムにモニタ到達／離脱に関して非同期的に通知することはできないが、オペレーティングシステムは、各ポーリング時に視覚的アーチファクトを生じ、モニタの有無を散発的にポーリングすることができる場合に限る。

４．ＨＰＤ認識なし−ミニポートが、割り込みによっても、ポーリングによっても、モニタ到達／離脱を認識しない場合に限る。
モニタ方向認識は以下のように定義され得る。

この関数から正常に戻ると、オペレーティングシステムは、出力パラメータで戻されたデータの存続時間の所有権を取ることができ、それを完了したときにそれがサポートする割り振りに要したメモリを割り振り解除することができる。

戻りコード
STATUS_SUCCESSは、ドライバが呼び出しを正常に処理したことを示す。

IsSupportedVidPNは、オペレーティングシステムがミニポートに、提供されたＶｉｄＰＮ構成がサポートされる（動作可能なＶｉｄＰＮに拡張され得る）かどうか尋ねることができるようにする。第１の引数hAdapterは、そこでのＶｉｄＰＮサポートが問題となる表示アダプタを指定することができる。実際のＶｉｄＰＮは、第２の引数の第１のフィールド、pIsSupportedVidPNArg→pDesiredVidPNで指定することができ、その場合のＶｉｄＰＮ記述子は以下のように定義され得る。

ＶｉｄＰＮトポロジ記述子は以下のように定義され得る。

VidPNPresentPathSetは、ＶｉｄＰＮのトポロジを構成するビデオ表示パスの集合を表すことができ、定義中、

であり、
１．NumOfVidPNPresentPathsはVidPNPresentPaths中のビデオ表示パスの数を含み、
２．VidPNPresentPathsは、ＶｉｄＰＮのトポロジを構成するビデオ表示パスの配列を含む。

ＶｉｄＰＮ表示パス記述子は以下のように定義され得る。

D3DKMDDI_VIDPN_PRESENT_PATHは、あるＶｉｄＰＮトポロジ中の単一のビデオ表示ターゲットから単一のビデオ表示ソースへのマッピングを記述するのに使用され得るビデオ表示パス記述子であり、
・VidPNSourceは、ビデオ表示パスのソース記述子である。
・VidPNTargetは、ビデオ表示パスのターゲット記述子である。
・VidPNPresentPathTransformationは、ビデオ表示パスのコンテンツ変換記述子である。

定義中、ＶｉｄＰＮソース記述子は以下のように定義され得る。

定義中、
・VidPNSourceIDは、ミニポートおよびオペレーティングシステムによってそれぞれのビデオ表示ソースを参照するのに使用される一意のＩＤである。この値は、EnumVideoPresentSourceSet呼び出しからもたらされる。
・PinnedModeIndexは、現在のＶｉｄＰＮ構成が与えられたとして、このビデオ表示ソース上で利用可能な共に動作可能なモード集合中のピンニングされているビデオ表示ソースモードの索引であり、またはこのソース上でモードがピンニングされていない場合は、D3DKMDDI_NO_PINNED_MODEである。
・pCofuncVidPNSourceModeSetは、このソースがそのメンバである、現在の（部分的または暫定的）ＶｉｄＰＮと共に動作可能なＶｉｄＰＮソースモードである。
ＶｉｄＰＮソースモード集合記述子は以下のように定義され得る。

定義中、
・NumOfVidPNSourceModesは、VidPNSourceModesで列記されたビデオ表示ソースモードの数を指定する。
・VidPNSourceModesは、集合中のビデオ表示ソースモードの配列を含む。
ＶｉｄＰＮソースモード記述子は以下のように定義され得る。

定義中、TypeはＶｉｄＰＮソースモードタイプ記述子を含み、以下のように定義される。

TypeがD3DKMDDI_RMT_GRAPHICSに等しい場合、ソースモード記述子は、グラフィックスレンダリング形式記述子grfxFormatを含み、以下のように定義される。

定義中、
・sizePrimSurfは、このＶｉｄＰＮソースモードに必要とされる１次サーフェスのサイズを指定する。
・sizeVisibleは、ズームモードを含むパンモードに使用される、この１次サーフェスの可視部分のサイズを指定する。
・dwStrideは、ある走査線の先頭と次の走査線の先頭の間のバイト数を指定する。
・PixelFormatは画素形式を指定する。
・PixelValueAccessModeは、画素値情報のアクセスモードを指定する。

そうではなく、TypeがD3DKMDDI_RMT_TEXTに等しい場合、ソースモード記述子は、テキストレンダリング形式記述子textFormatを含み、以下のように定義される。

さらに、ＶｉｄＰＮターゲット記述子は以下のように定義され得る。

定義中、
・VidPNTargetIDは、ミニポートおよびオペレーティングシステムによってそれぞれのビデオ表示ターゲットを参照するのに使用される一意のＩＤである。この値は、EnumVideoPresentTargetSet呼び出しからもたらされる。
・PinnedModeIndexは、現在のＶｉｄＰＮ構成が与えられたとして、このビデオ表示ターゲット上で利用可能な共に動作可能なモードの集合中のピンニングされているビデオ表示ターゲットモードの索引であり、またはこのターゲット上にモードがピンニングされていない場合は、D3DKMDDI_NO_PINNED_MODEである。
・pCofuncVidPNSourceModeSetは、このターゲットがそのメンバである、現在の（部分的）ＶｉｄＰＮと共に動作可能なＶｉｄＰＮターゲットモードである。

ＶｉｄＰＮターゲットモード集合記述子は以下のように定義され得る。

定義中、
・NumOfVidPNTargetModesは、VidPNTargetModesで列記されたビデオ表示ターゲットモードの数を指定する。

・VidPNTargetModesは、集合中のビデオ表示ターゲットモードの配列を含む。
定義中、ＶｉｄＰＮターゲットモード記述子は、表５３に示すように定義され得る。

定義中、
・vidStandardは、このモードがそれによって定義されるビデオモード標準を指定する（もしあれば）。
・sizeTotalは、画素単位のビデオ信号のサイズを指定する（HTotalおよびVTotalなど）。
・sizeActiveは、アクティブ画素単位の表示されるイメージのサイズを指定する（HActiveおよびVActiveなど）。
・sizeActiveOffsetは、総画素に対するアクティブ画素の位置を指定する。
・sizeTLDeltaVisibleFromActiveは、モニタ画面の、ビデオ信号のアクティブ画素右下隅からの可視画素の左上隅のデルタを指定する。
・sizeBRDeltaVisibleFromActiveは、モニタ画面の、ビデオ信号のアクティブ画素右下隅からの可視画素の右下隅のデルタを指定する。
・frqVSyncこのモードの垂直リフレッシュ周波数（Ｈｚ単位）を指定する。
・frqHSyncこのモードの水平リフレッシュ周波数（ＫＨｚ単位）を指定する。
・sztPixelRateこのモードの画素クロック速度を指定する。
・ScanLineOrderingこのモードの走査線順序（プログレッシブ、インターレースなど）を指定する。
・IsGTFCompliantは、このモードの垂直同期、水平同期、およびクロック速度が、ＶＥＳＡ汎用タイミング式によって課される制限事項に適合するかどうか指定する。
・ModePreferenceは、このモードが、それぞれのビデオ出力に接続されたモニタによって優先されるかどうか指定する。

このビデオ信号標準エニュメレーションを用いて、適宜、ビデオモード比較が簡素化され得る。

分数周波数記述子は以下のように定義され得る。

定義中、
・Numeratorは、分数周波数の分子を指定する。
・Denominatorは、分数周波数の分母を指定する。

垂直周波数はＨｚ単位で格納され、水平周波数はＫＨｚ単位で格納され得る。この符号化形式のダイナミックレンジは、（３２ビットシステム上での）１０＾−７解像度を想定すると、｛０．．２＾３２−１／１０＾７｝であり、これは、垂直周波数での｛０．．４２８．４９６７２９６｝［Ｈｚ］、水平周波数での｛０．．４２８．４９６７２９６｝［ＫＨｚ］に変換される。このサブマイクロ秒精度範囲は、専門のビデオ用途にさえも許容可能なはずである（ビデオ信号同期での１マイクロ秒におけるエラーは、１０＾７／（６０＊６０＊２４）＝１１５．７４１日間周期でのタイムドリフトを示唆する）。

ビデオ信号走査線順序記述子は以下のように定義され得る。

また、これを用いて、各フィールドが、１フレーム全体を含むか、それともその半分だけを（例えば、偶数線／奇数線を交互に）含むか指定することができる。エニュメレーションを用いてこの特性を明示的に指定することは、クライアントをモードベースのルックアップ表を維持する必要から解放することができると共に、D3DKMDDI_VIDEO_SIGNAL_STANDARDエニュメレーションに列記されない将来の標準モードにも拡張可能である。

可視画素のサイズおよびオフセットではなく可視／アクティブ画素マッピングのデルタを格納することには、理想／デフォルト状態がゼロであるというさらなる利点がある。

ＶｉｄＰＮ表示パス変換記述子は以下のように定義され得る。

定義中、
・D3DKMDDI_VPPT_IDENTITYは、そのままで表示されるソースコンテンツを表す。この変換は、ビデオ表示ソースモードとビデオ表示ターゲットモードの空間解像度がマッチする場合に限って利用可能であることに留意されたい。
・D3DKMDDI_VPPT_CENTEREDは、ターゲットモードの空間解像度に対して中央に配置され、拡縮なしで表示されるソースコンテンツを表す。
・指定されたＶｉｄＰＮは、少なくとも、１つの有効なトポロジを指定する必要があるが、そのターゲット／ソースの一部または全部をそれぞれにピンニングされたモードを用いて構成させることもできる。

戻りコード
STATUS_SUCCESSは、ドライバが呼び出しを正常に処理したことを示す。
STATUS_GRAPHICS_INVALID_VIDPN_TOPOLOGYは、指定されたＶｉｄＰＮトポロジが無効であることを示す。

EnumCofuncVidPNSourceIDSetは、指定されたＶｉｄＰＮ実装形態と共に動作可能なＶｉｄＰＮソースＩＤの集合をエニュメレーションする。ＶｉｄＰＮソースは、そのＶｉｄＰＮ実装形態を無効あるいはサポートなしにすることなくそれが少なくとも１つのビデオ表示パスを介してそのトポロジに付加され得る場合に限り、所与のＶｉｄＰＮ実装形態と共に動作可能とすることができる。ミニポートは、D3DKMDDI_INTERFACESPECIFICDATA.pfnAllocSysMemForOutParamCbを使用して、pEnumCofuncVidPNSourceIDSetArgによって指し示される、全エニュメレーション結果を収容するのに十分な大きさのバッファを割り振ることができる。割り振りのサイズは、sizeof（D3DKMDDI_VIDEO_PRESENT_SOURCE_ID_SET）＋sizeof（D3DKMDDI_VIDEO_PRESENT_SOURCE_ID）＊（共に動作可能なビデオ表示ソースの数−１）になるはずである。

出力パラメータのメモリが割り振られると、ミニポートは、以下の定義に基づいてそこにデータを取り込むことができる。

定義中、
・NumOfVidPNSourceIDsは、VideoPresentSourceIDsに列記されたビデオ表示ソースのＩＤの数を指定する。
・VideoPresentSourceIDsは、集合中のビデオ表示ソースのＩＤの配列を表す。

この関数から正常に戻ると、オペレーティングシステムは、出力パラメータで戻されたデータの存続時間の所有権を取ることができ、それを完了したときにそれがサポートする割り振りに要したメモリを割り振り解除することができる。

戻りコード
STATUS_SUCCESSは、ドライバが呼び出しを正常に処理したことを示す。
STATUS_GRAPHICS_INVALID_VIDPN_TOPOLOGYは、指定されたVidPNトポロジが無効であることを示す。
STATUS_NO_MEMORYは、ミニポートが、要求されたエニュメレーションに適するバッファを割り振ることができなかったことを示す。

EnumCofuncVidPNTargetIDSetは、指定されたＶｉｄＰＮ実装形態と共に動作可能なＶｉｄＰＮターゲットＩＤの集合をエニュメレーションする。ＶｉｄＰＮターゲットは、そのＶｉｄＰＮ実装形態を無効あるいはサポートなしにすることなくそれが少なくとも１つのビデオ表示パスを介してそのトポロジに付加され得る場合に限り、所与のＶｉｄＰＮ実装形態と共に動作可能とすることができる。ミニポートは、D3DKMDDI_INTERFACESPECIFICDATA.pfnAllocSysMemForOutParamCbを使用して、pEnumCofuncVidPNTargetIDSetArgによって指し示される、全エニュメレーション結果を収容するのに十分な大きさのバッファを割り振ることができる。割り振りのサイズは、sizeof（D3DKMDDI_VIDEO_PRESENT_ TARGET_ID_SET）＋sizeof（D3DKMDDI_VIDEO_PRESENT_TARGET_ID）＊（共に動作可能なビデオ表示ターゲットの数−１）になるはずである。

出力パラメータのメモリが割り振られると、ミニポートは、以下の定義に基づいてそこにデータを取り込むことができる。

定義中、
・NumOfVidPNTargetIDsは、VideoPresentTargetIDsで列記されたビデオ表示ターゲットのＩＤの数を指定する。
・VideoPresentSourceIDsは、集合中のビデオ表示ターゲットのＩＤの配列を表す。

この関数から正常に戻ると、オペレーティングシステムは、出力パラメータで戻されたデータの存続時間の所有権を取ることができ、それを完了したときにそれがサポートする割り振りに要したメモリを割り振り解除することができる。

戻りコード
STATUS_SUCCESSは、ドライバが呼び出しを正常に処理したことを示す。
STATUS_GRAPHICS_INVALID_VIDPN_TOPOLOGYは、指定されたＶｉｄＰＮトポロジが無効であることを示す。
STATUS_NO_MEMORYは、ミニポートが、要求されたエニュメレーションに適するバッファを割り振ることができなかったことを示す。

EnumVidPNCofuncModalityは、オペレーティングシステムに、指定されたＶｉｄＰＮ中の各ビデオ表示パス上の共に動作可能なビデオ表示およびターゲットモード集合をエニュメレーションさせ、
・pConstrainingVidPNは、それに関してＶｉｄＰＮのターゲットおよびソース上の共に動作可能なモード集合が求められているＶｉｄＰＮである。
・pVidPNPresentPathSetWithCofuncModeSetsは、各ソース／ターゲットに、制約ＶｉｄＰＮと共に動作可能なモード集合が取り込まれるＶｉｄＰＮ表示パスの集合である。制約ＶｉｄＰＮの任意のソース／ターゲットがその上にピンニングされたモードを持つ場合、それらの索引は、結果集合中のそれぞれのＶｉｄＰＮソース／ターゲット記述子において正しく更新されるはずである。

ミニポートは以下のようにデータを取り込むはずである。

この関数から正常に戻ると、オペレーティングシステムは、出力パラメータで戻されたデータの存続時間の所有権を取ることができ、それを完了したときにそれがサポートする割り振りに要したメモリを割り振り解除することができる。

戻りコード
STATUS_SUCCESSは、ドライバが呼び出しを正常に処理したことを示す。
STATUS_NO_MEMORYは、ミニポートが、要求されたエニュメレーションに適するバッファを割り振ることができなかったことを示す。

表５７−関数RecommendFunctionalVidPN

RecommendFunctionalVidPNは、ハードウェアの現在の状態が与えられたとして、オペレーティングシステムに、ミニポートによって推奨されるＶｉｄＰＮを照会させる。オペレーティングシステムは、ユーザ設定（最後に使用された様式など）が指定されていない構成に遭遇した場合にそれを使用することができる。この要求の一部として、オペレーティングシステムは、ミニポートに、それらに接続されたモニタの相対的重要度を表す、最重要なものから配列されたＶｉｄＰＮターゲットＩＤのベクトルpVidPNTargetPrioritizationVectorを指定する。次に、ミニポートは、現在のハードウェアの状態でそれがオペレーティングシステムに推奨しようとする動作可能なＶｉｄＰＮにデータを取り込むのに十分なメモリを割り振り、それぞれのフィールドにデータを取り込み、そのアドレスをpRecommendedFunctionalVidPNに割り当てるはずである。この関数から正常に戻ると、オペレーティングシステムは、出力パラメータで戻されたデータの存続時間の所有権を取ることができ、それを完了したときにそれがサポートする割り振りに要したメモリを割り振り解除することができる。

戻りコード
STATUS_SUCCESSは、ドライバが呼び出しを正常に処理したことを示す。
STATUS_GRAPHICS_NO_RECOMMENDED_VIDPNは、ミニポートが、表示アダプタの現在の構成でのＶｉｄＰＮ推奨を持たないことを示す。
STATUS_NO_MEMORYは、ミニポートが、要求されたエニュメレーションに適するバッファを割り振ることができなかったことを示す。

（実施例４９）
（ビデオレンダリングデバイスドライバのデバイス固有部分の例）
本明細書で説明する技術のいずれも、ビデオレンダリングデバイスドライバのデバイス固有部分で実施され得る。ドライバの再利用可能部分は、ビデオレンダリングデバイスドライバ間で共用され得る。

例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムで実行される実装形態では、ビデオポートはドライバの再利用可能部分として働くことができ、ビデオミニポートはビデオレンダリングデバイスドライバのデバイス固有部分として働くことができる。

（利点の例）
マルチモニタ表示モード管理は、ビデオレンダリング／表示デバイス（グラフィックスアダプタとも呼ばれるビデオカードなど）およびビデオ監視装置（モニタなど）の諸機能を処理する複雑な問題である。表示モード管理における複雑さを生じる主要な問題は、それぞれが単一のマルチ出力ビデオカード上の別個の（ビュー，出力）マッピングを表す、グラフィックス表示装置オブジェクト（ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）ＧＤＩオブジェクトなど）の諸機能間の固有の相互依存性であり、それは、既存の表示モード管理アーキテクチャによってはうまく処理されない。

これらの相互依存性は、主に、（１）それらを駆動することができるコーデックより多くのビデオ出力を持つシステム上のビデオ出力コーデックをめぐる可能な競合、（２）主として、（ａ）ビデオカードに存在するビデオ出力コーデックの諸機能の差異、（ｂ）任意のビデオ出力コーデックを任意の互換性のあるビデオ出力に経路指定することのできるクロスバーの使用によりビデオ出力コーデックを様々なビデオ出力と共に使用することができるビデオカードの能力、（ｃ）ビデオ出力コーデックが不十分なリソースである（駆動されるビデオ出力の数より少ないなどの）場合に複数のビデオ出力にビデオ出力コーデックを共用することができるビデオカードの能力、（ｄ）ビデオストリームの１つを改ざんすることが許容されない場合、あるいはその上に２次信号をオーバーレイする必要のあるビデオストリームが、すでに、アナログ形式であり、ディジタルオーバーレイを付加し、次いで、それを再変調するだけのためにそれを復号化することが無駄である場合に、複数のビデオ出力コーデックまたは単一のマルチ入力ビデオ出力コーデックを単一のビデオ出力（オーバーレイなど）に使用することができるビデオカードの能力に起因する、所与のビデオカード内の任意の所与のマルチ出力ビデオ表示構成の確立を求める要求を満たす複数の方法、（３）最終的には定期的なビデオメモリ読取りに還元される、そのそれぞれが関連する１次サーフェスのコンテンツをそれぞれのビデオ出力インタフェース上のビデオ信号に変換する役割を果たす、ビデオ出力コーデックによって利用されるビデオメモリバス帯域幅をめぐる競合、あるいは、（４）所与のビデオ表示パス（レンダリングされたディジタルコンテンツから物理ビデオインタフェース出力までの論理パスなど）をサポートするのに必要とされる１次サーフェスによるビデオメモリ容量をめぐる競合から生じる。

したがって、前述の、利用可能な（ビュー，出力）対の表示モード集合間の相互依存性は、１つの（ビュー，出力）対だけでのものより複雑である。具体的には、あるビューで所与の１次サーフェス形式を使用することを選択すると、それぞれの出力でどのビデオ信号が表示され得るかに影響を及ぼしうる。また、単一のビューが複数の出力で表示されるシナリオを考察すると、利用可能なビデオ信号の集合も、どのように、どのビデオ出力コーデックを使用して、結果として生じる表示構成が実施されるかに基づいて変わる。最後に、複数のビューが単一のビデオカード上で用いられる（それぞれがおそらく複数の出力に表示される）シナリオを考察すると、利用可能なビデオ信号は、様々なビューと出力の間の関連に基づいて変わる。すなわち、ビデオカードがどのビデオ信号をその出力で駆動することができるかは、それが、どのタイプの１次サーフェスを表示するよう求められているか、およびそれらをどのようなやり方で（例えばどの出力に）表示すべきかの関数である。

さらに、設計は、所与の１次サーフェスコンテンツを、それぞれのビデオ出力上で駆動される異なる空間解像度にアップサンプルまたはダウンサンプルすることができる昨今のビデオカードのスケーリング機能を考慮に入れないことがある。したがって、マルチ出力ビデオカードに関して行われ得る２つの主要な抽象化は、（１）２つの異なる物理デバイスの状態を含む、統一された「表示モード」記述子様式で表される、ビデオカードとモニタ両方を含む多機能表示装置抽象化の簡略化されたビューと、（２）（ビュー，出力）ごとに１つの、独立のビデオドライバスタックおよびそれぞれのグラフィックスデバイスの複製によって達成され得る、単一出力モードエニュメレーションのマルチ出力への拡張である。これらの抽象化は、そのようなデバイスを適正に駆動するのに十分ではなく、以下で置き換えられ得る。（１）ビューおよび出力での異なる様式記述子、（２）クライアントにそれが求めるモードをピンニングさせ、利用可能なモードの更新された集合を再エニュメレーションさせて、一連の反復（グラフィックスサーチなど）で最終的に動作可能な解に収束させる機能平衡化ＤＤＩを公開するビデオミニポートをホスティングする、ビデオカードごとに１つのビデオドライバスタック、および（３）表示モード相互依存性、結果として生じる利用可能なモード集合の無効化、およびモード変更失敗をサポートするための実装形態の拡大。

（代替物）
どの例の技術も、その他の例のいずれか１つまたは複数で説明した技術と組み合わせることができる。本発明の原理が適用され得る多くの可能な実施形態を考えると、説明した実施形態は、本発明の例であり、本発明の範囲を限定するものと解釈すべきではないことを理解すべきである。そうではなく、本発明の範囲は、以下の特許請求の範囲によってカバーされるものを含む。したがって、本発明として、これらの特許請求の範囲の範囲および精神に含まれるものすべてを特許請求するものである。

構成可能なビデオ表示ネットワークの一例を示すブロック図である。 構成可能なビデオ表示ネットワークの別の例を示すブロック図である。 ビデオ表示ネットワークでの構成の組合せを示すブロック図である。 図１に示すものなどの構成可能なビデオ表示ネットワークの構成方法を示す流れ図である。 図１に示すものなどのビデオ表示ネットワークの暫定的構成の例を示す表である。 図１に示すものなどのビデオ表示ネットワークの構成を実現するトランザクショナル手法の一例を示すブロック図である。 トランザクショナル手法を介して構成を実行する方法の一例を示す流れ図である。 図１に示すものなどのビデオ表示ネットワークの暫定的構成時のフィードバックでのソースの例を示すブロック図である。 図８Ａに類似の、複数のリソースのフィードバックでのソースの例を示すブロック図である。 ピンニング時の複数のリソースでの共に動作可能なオプションの例を示すブロック図である。 ピンニング時の複数のリソースでの共に動作可能なオプションの例を示すブロック図である。 ピンニング時の複数のリソースでの共に動作可能なオプションの例を示すブロック図である。 ピンニング時の複数のリソースでの共に動作可能なオプションの他の例を示すブロック図である。 ピンニング時の複数のリソースでの共に動作可能なオプションの他の例を示すブロック図である。 ピンニング時の複数のリソースでの共に動作可能なオプションの他の例を示すブロック図である。 図１に示すものなどのビデオ表示ネットワークの構成を実現するフィードバックを用いたトランザクショナル手法の一例を示すブロック図である。 サーバから見た、フィードバックを用いたトランザクショナル手法により構成を実行する方法の一例を示す流れ図である。 クライアントから見た、フィードバックを用いたトランザクショナル手法による構成を実行する方法の一例を示す流れ図である。 暫定的構成が実施され得るアーキテクチャの一例を示すブロック図である。 ビデオ表示ネットワークの構成方法の一例を示す流れ図である。 所望の構成に収束する解空間の系統的トラバースによる所望の構成の発見方法の一例を示す流れ図である。 所望の構成に収束する解空間の系統的トラバースによる所望の構成の第１の詳細な発見方法の例を示す流れ図である。 所望の構成に収束する解空間の系統的トラバースによる所望の構成の第１の詳細な発見方法の例を示す流れ図である。 所望の構成に収束する解空間の系統的トラバースによる所望の構成の第２の詳細な発見方法の例を示す流れ図である。 所望の構成に収束する解空間の系統的トラバースによる所望の構成の第２の詳細な発見方法の例を示す流れ図である。 所望の構成に収束する解空間の系統的トラバースによる所望の構成の第２の詳細な発見方法の例を示す流れ図である。 ビデオ表示ネットワークでのトポロジの決定方法の一例を示す流れ図である。 ビデオ表示ネットワークでの構成に到達するクライアントとサーバの間の呼び出しを示すブロック図である。 当該技術の実装形態の、複数のビデオ表示装置を備えるコンピュータシステムへの統合を示すブロック図である。 所望のビデオ構成を決定する際に優先順位を考慮に入れるクライアント／サーバシステムを示すブロック図である。 図２２のものなどのクライアント／サーバシステムにおける所望のビデオ構成の決定方法の一例を示す流れ図である。 当該方法の実行時にトポロジが変更され得る解空間の系統的トラバースによる所望の構成の発見方法の一例を示す流れ図である。 マルチモニタ／マルチビューシステムの一例を示すブロック図である。 開示の技術を実施する例示的システムを構成する汎用コンピューティングデバイスを示す図である。

符号の説明

１４０ その他のリソース
６１０ クライアント
６２０ サーバ
６３０ ビデオ表示ネットワーク
１１１０ クライアント
１１２０ サーバ
１１３０ ビデオ表示ネットワーク
１４１０ クライアント
１４２０ ドライバ
１４２５ 相互依存性論理
１４３０ ビデオアダプタ
１４４０Ａ 表示装置
２００２ ビデオドライバ
２００４ グラフィックスカーネルサブシステム
２１１０ デスクトップ
２１１２ 表示属性アプレット
２１１４ 全画面グラフィックスアプリケーション
２１２０ グラフィックスサブシステム
２１３０ ビデオドライバ
２１３２ ビデオドライバ
２１４０ ハードウェア抽象化層
２１５０ ビデオアダプタ
２１５２ ビデオアダプタ
２１６０ ＣＲＴモニタ
２１６２ フラットパネルモニタ
２１６４ ディジタルプロジェクタ
２１６６ ＬＣＤモニタ
２１６８ 仮想現実ゴーグル
２２０２ クライアント
２２０４ サーバ
２２０６ 優先順位
２６０２ 処理装置
２６０４ システムメモリ
２６０６ システムバス
２６２０ ハードディスクドライブインタフェース
２６２２ 磁気ディスクドライブインタフェース
２６２４ 光ドライブインタフェース
２６３０ オペレーティングシステム
２６３２ アプリケーションプログラム
２６３４ プログラムモジュール
２６３６ プログラムデータ
２６４０ キーボード
２６４４ シリアルポートインタフェース
２６４６ モニタ
２６４８ ビデオアダプタ
２６５０ リモートコンピュータ
２６５８ ネットワークインタフェース
２６６０ モデム

Claims (13)

1. ビデオ表示ネットワークの暫定的構成の指示を受け取るサービスであって、前記ビデオ表示ネットワークは、少なくとも第１のビデオネットワークリソースと、複数の第２のビデオネットワークリソースとを含み、前記暫定的構成は、前記第１のビデオネットワークリソースを含む、サービスと、
   前記複数の第２のビデオネットワークリソースに関する第１の複数の構成オプションをエニュメレーションするサービスであって、前記第１の複数の構成オプションは、前記第１のビデオネットワークリソースと共に動作可能である、サービスと、
   前記第１の複数の構成オプションのうちの１つをピンニングするサービスと、
   前記複数の第２のビデオネットワークリソースに関する第２の複数の構成オプションであって、該ピンニングされた構成オプションと共に動作可能な第２の複数の構成オプションをエニュメレーションするサービスと、
   へのアクセスを提供するインタフェースにアクセスするためのコンピュータ実行可能命令を格納したことを特徴とするコンピュータ可読記録媒体。
2. 前記第１の複数の構成オプションは、
   前記暫定的構成と共に動作可能な複数のビデオ表示ネットワークソースをエニュメレーションすることを含むことを特徴とする請求項１に記載のコンピュータ可読記録媒体。
3. 前記第１の複数の構成オプションは、
   前記暫定的構成と共に動作可能な複数のビデオ表示ソースモードをエニュメレーションすることを含むことを特徴とする請求項１に記載のコンピュータ可読記録媒体。
4. 前記第１の複数の構成オプションは、
   前記暫定的構成と共に動作可能な複数のビデオ表示ネットワークターゲットをエニュメレーションすることを含むことを特徴とする請求項１に記載のコンピュータ可読記録媒体。
5. 前記第１の複数の構成オプションは、
   前記暫定的構成と共に動作可能な複数のビデオ表示ターゲットモードをエニュメレーションすることを含むことを特徴とする請求項１に記載のコンピュータ可読記録媒体。
6. 前記第１の複数の構成オプションは、少なくとも１つのビデオ表示ネットワークソースを含むことを特徴とする請求項３に記載のコンピュータ可読記録媒体。
7. 前記インタフェースは、さらに、
   前記複数のビデオ表示ソースモードの前記１つをアンピンニングするサービスへのアクセスを提供することを特徴とする請求項６に記載のコンピュータ可読記録媒体。
8. 前記インタフェースは、さらに、
   前記複数のビデオ表示ソースモードの前記１つの前記アンピンニングの後で前記暫定的構成と共に動作可能な複数のビデオ表示ソースモードをエニュメレーションするサービスへのアクセスを提供することを特徴とする請求項７に記載のコンピュータ可読記録媒体。
9. 前記第１の複数の構成オプションは、少なくとも１つのビデオ表示ネットワークターゲットを含み、前記インタフェースは、さらに、前記少なくとも１つのビデオ表示ネットワークターゲット上に前記複数のビデオ表示ターゲットモードの１つをピンニングするサービスへのアクセスを提供することを特徴とする請求項５に記載のコンピュータ可読記録媒体。
10. 前記インタフェースは、さらに、
    前記複数のビデオ表示ターゲットモードの前記１つの前記ピンニング後に前記暫定的構成と共に動作可能な複数のビデオ表示ターゲットモードをエニュメレーションするサービスへのアクセスを提供することを特徴とする請求項９に記載のコンピュータ可読記録媒体。
11. 前記インタフェースは、さらに、
    前記複数のビデオ表示ターゲットモードの前記１つをアンピンニングするサービスへのアクセスを提供することを特徴とする請求項９に記載のコンピュータ可読記録媒体。
12. 前記インタフェースは、さらに、
    前記複数のビデオ表示ターゲットモードの前記１つの前記アンピンニング後に前記暫定的構成と共に動作可能な複数のビデオ表示ターゲットモードをエニュメレーションするサービスへのアクセスを提供することを特徴とする請求項１１に記載のコンピュータ可読記録媒体。
13. 前記インタフェースは、さらに、
    動作可能なビデオ表示ネットワーク構成をコミットするサービスへのアクセスを提供することを特徴とする請求項１に記載のコンピュータ可読記録媒体。

Images