W E 0 PRESENTING NETWORK MANAGEMENT
RELATED APPLICATION DATA
This application claims priority to U.S. Provisional Application No. 601567,053,
5 filed April 30,2004, to U.S. Utility Application No. 10/925,662, filed August 24,2004,
to U.S. Utility Application No. 10/925,445, filed August 24,2004, to U.S. Utility
Application No. 10/925,837, filed August 24,2004, and to U.S. Utility Application No.
10/925,859, filed August 24,2004, all of which are incorporated herein by reference.
TECHNICAL HELD
The technical field relates to configuration of video display adapters (e.g.,
computer video cards).
BACKGROUND
15 Computer systems using multiple monitors are becoming widespread. For
example, it is now common for a computer to drive both an LCD panel and a projector
device. Further, computer users now routinely watch video presentations (e.g., DVDs)
using their computer. In such a case, the computer may be driving both a conventional
monitor and a television.
20 In response to demand, video adapter hardware manufacturers now include
multiple outputs on video adapters. In this way, a user can more easily use a computer
to drive desired devices without having to switch cables for a single output and reconfigure
the output.
Although such multi-monitor video adapters have a variety of functionality,
25 available configurations are typically limited. Accordingly, there exists a need to
improve functionality related to configuring multi-monitor computer systems.
SUMMARY
Configuring a video presenting network having plural outputs can be challenging,
due to the sheer number of possible configurations and configuration interdependencies
among resources.
5 A variety of technologies described herein can be used to configure resources of a
video presenting network having plural outputs. For example, provisional configuration
can be supported. Configuration of inputs can be performed separately from
configuration of outputs. Interdependencies between network resources can be
considered to restrict provided options to those co-functional with a provisional
10 configuration. A client can use a set of functions provided by a service to traverse the
configuration solution space. Traversal through possible configuration solutions can
include backtracking. For example, backtracking can be used when a selected
configuration option invalidates another desired configuration option. Provisional
configuration functionality can support a transactional configuration approach, and
15 resources can be separately configured. An enumeration function can provide only those
options co-functional with a provisional configuration, based on interdependencies
between network resources. Validity of enumerated options can be guaranteed after
pinning.
The functions can be grouped into an interface that includes calls for enumerating
20 configurations (e.g., those configurations that are co-functional with a provisional
configuration) and pinning resources. Other calls can be provided for creating a
configuration and committing the configuration. The functions can support a
transactional approach to configuration.
A topology best meeting a configuration goal can be found in light of the
25 interdependencies. For example, a best way to route targets to sources though available
codecs to maximize support source mode sets on sources can be found, given that targets
must support preferred modes on the display devices connected to them. Other goals
can be supported. Prioritization ordering can also be supported. Enumeration and
pinning functionality can be used during pursuit of a topology better meeting the goal.
Provisional configuration can support incremental configuration via separate
device driver interface calls for configuring different resources (e.g., one call for a video
5 output and another for a video input). Between calls, enumeration can indicate cofunctional
resources for remaining unpinned (e.g., not yet provisionally configured)
resources.
Responsibility for considering interdependencies can be delegated to (e.g.,
performed by) a video driver, such as a video miniport. A client can use a variety of
10 approaches to find a desired configuration. The desired configuration can be treated as a
solution to an NP-complete graph problem.
The foregoing and other features and advantages will become more apparent fiom
the following detailed description of disclosed embodiments, which proceeds with
reference to the accompanying drawings.
15
BRIEF DESCRIPTION OF THE FIGURES
FIG. 1 is a block diagram showing an exemplary configurable video presenting
network.
FIG. 2 is a block diagram showing another exemplary configurable video
20 presenting network.
FIG. 3 is a block diagram showing combinations of configurations for a video
presenting network.
FIG. 4 is a flowchart showing a method of configuring a configurable video
presenting network, such as that shown in FIG. 1.
25 FIG. 5 is a table showing exemplary provisional configuration of a video
presenting network, such as that shown in FIG. 1.
FIG. 6 is a block diagram showing an exemplary transactional approach to
achieving configuration of a video presenting network, such as that shown in FIG. 1.
FIG. 7 is a flowchart showing an exemplary method for performing configuration
via a transactional approach.
5 FIG. 8A is a block diagram showing exemplary source for feedback during a
provisional configuration of a video presenting network, such as that shown in FIG. 1.
FIG. 8B is a block diagram showing exemplary source for feedback similar to
FIG. 8A, but for plural resources.
FIGS. 9A, 9B, and 9C are block diagrams showing exemplary co-functional
10 options for a plurality of resources during pinning.
FIGS. 1 OA, 1 OB, and 10C are block diagrams showing other exemplary cofunctional
options for a plurality of resources during pinning.
FIG. 11 is a block diagram showing an exemplary transactional approach with
feedback to achieve configuration of a video presenting network, such as that shown in
15 FIG. 1.
FIG. 12 is a flowchart showing an exemplary method for performing
configuration via a transactional approach with feedback from a server perspective.
FIG. 13 is a flowchart showing an exemplary method for performing
configuration via a transactional approach with feedback fiom a client perspective.
20 FIG. 14 is a block diagram showing an exemplary architecture in which
provisional configuration can be implemented.
FIG. 15 is a flowchart showing an exemplary method of configuring a video
presenting network.
FIG. 16 is a flowchart showing an exemplary method of finding a desired
25 configuration by systematic traversal of the solution space to converge on a desired
configuration.
FIGs. 17A-B are a flowchart showing a fwst exemplary detailed method of
finding a desired configuration by systematic traversal of the solution space to converge
on a desired configuration.
FIGs. 18A-C are a flowchart showing a second exemplary detailed method of
5 finding a desired configuration by systematic traversal of the solution space to converge
on a desired configuration.
FIG. 19 is a flowchart showing an exemplary method of determining a topology
for a video presenting network.
FIG. 20 is a block diagram showing calls between a client and server to arrive at a
10 configuration for a video presenting network.
FIG. 2 1 is a block diagram showing integration of an implementation of the
technology into a computer system having a plurality of video display devices.
FIG. 22 is a block diagram showing a client-server system that takes priorities
into account in determining a desired video configuration.
15 FIG. 23 is a flowchart showing an exemplary method of determining a desired
video configuration in a client-server system such as that in FIG. 22.
FIG. 24 is a flowchart showing an exemplary method of fmding a desired
configuration by systematic traversal of the solution space where the topology can be
changed during execution of the method.
20 FIG. 25 is a block diagram showing an exemplary multi-monitor/multi-view
system.
FIG. 26 is a diagram depicting a general-purpose computing device constituting
an exemplary system for implementing the disclosed technology.
DETAILED DESCRIPTION
Example 1 -Exemplary Video Presenting Network
FIG. 1 shows a configurable video presenting network 100. The technologies
described in any of the examples herein can be used to configure the video presenting
5 network 100.
The video presenting network 100 for use with the technologies described herein
can have one or more inputs 110A-110N (e.g., a total of C inputs, o); two or more
outputs 120A-120N (e.g., a total of T inputs, T); and one or more digital-video-inputrepresentation-
to-video-output-signal converters 130A-130N (e-g., a total of K
10 converters, K).
The inputs 1 10A-11 ON are sometimes called "sources" or "surfaces." The
outputs 120A-120N are sometimes called b'targets." The digital-video-inputrepresentation-
to-video-output-signal converters are sometimes called "converters."
In addition to the inputs, converters, and outputs, the video presenting network
15 can include other resources 140 (e.g., video memory, bandwidth, memory capacity, and
the like). The other resources 140 can be used by the inputs, converters, and outputs to
achieve video presenting functionality.
The video presenting network 100 can be implemented in hardware such as a
video display adapter (e.g., video card). In some cases, some resources may reside
20 outside the adapter.
An exemplary computer system may include one or more video views in digital
form (e.g., which are written to by applications of the computer system), which are used
by the inputs 110A-11 ON. The resulting signal coming !?om the plural outputs 120A-
120N can be used to drive plural video display devices.
25
Excrmple 2 -Exemplary Alternative Video Presenting Network
FIG. 2 shows another configurable video presenting network 200. The
technologies described in any of the examples herein can be used to configure the video
presenting network 200.
5 In the example, multiple inputs can be used for a single digital-video-inputrepresentation-
to-video-output-signal converter (e.g., the inputs 210B and 210N are used
as inputs to the converter 230N). Such a configuration can be usell in overlaying one
video signal on top of another by using a video output codec with two inputs, wherein
the ftrst input is the primary content and the second input is the overlaid content. In
10 such a situation, the position and size of the overlay can be specified as part of the video
present source mode for the video presenting network source representing the overlaid
content.
Video presenting networks can take many other forms, having an arbitrary
number of inputs, converters, and plural outputs.
15
Example 3 - Exemplary Video Presenting Network Resources
In any of the examples herein, a resource can include video presenting network
inputs (e.g., sources or surfaces), video presenting network outputs (e.g., targets),
converters, video memory, bandwidth, memory capacity, and the like.
20 The topology of a video presenting network is also sometimes called a resource.
For example, configuring a resource can include simply choosing a topology without
regard to choosing configuration options for the individual resources involved in the
topology.
25 Example 4 - Exemplary Video Paths in a Video Presenting Network
A video presenting network 100 can have a plurality of video paths. For
example, as shown in FIG. 1, a path may be from the input 1 10A, through the converter
130A, to the output 120A. Another path may be fiom the input 1 10A through the
converter 130A, to the output 120B, and so forth.
The topology of the video presenting network 100 can be configured so that there
are different paths according to the configuration. For example, instead of sending the
5 output of the converter 130N to the video output 120N, it could be routed to a different
video output (e.g., 120B) by changing a configuration setting.
Example 5 - Khmplary Video Presenting Network Inputs
In any of the examples described herein, the video inputs (or "sources") can take
10 any of a variety of forms, such as those providing digital surfaces. In practice, the inputs
can be configured to use a variety of source modes. Such modes can include parameters
such as width, height, unit format, rasterized graphics filtering technique, primary
surface chain length, the like, or some combination thereof.
Example 6 - Exemplary Video Presenting Network Outputs
In any of the examples described herein, the video outputs (or "targets") can take
any of a variety of forms, such as those providing output signals. A descriptor can be
associated with the outputs. The descriptor can indicate a format (e.g., DVI, HDMI,
HD-15, BNC, S-video, RF, RCA and the like) and HPD awareness. The output can also
20 be associated with a video encoding type. Furthermore, an output can be configured to
be in sync with another output.
In practice, the outputs can be configured to use a variety of target modes. Such
modes can include parameters such as active region (e.g., width and height), total region
(e.g., width and height), active region displacement, pixel encoding format, vertical
25 retrace fiequency, horizontal retrace fiequency, pixel clock rate, content ordering, color
primaries, white point reference, color space transformation matrix, the like, or some
combination thereof.
Example 7 - hkemplary Converters
In any of the examples herein, a digital-video-input-representation-to-videooutput-
signal converter can take the form of a video codec, a digital-to-analog converter,
5 or the like. Some converters are sharable. For example, in a clone (e.g., mirror) mode, a
codec may send its signal to two outputs.
Example 8 -Exemplary Interdependency of Resources
Although any number of configurations of the video presenting network 100 are
10 theoretically possible, only a limited number of theoretical configurations are functional
configurations. In practice, the resources of the video presenting network 100 are
subject to configuration interdependency.
For example, configuring the video input 110A to be of a particular type may
consume a large amount of video memory. In such a case, there may not be sufficient
15 remaining memory for another video input (e.g., 1 ION) to be of the same type. For
example, it may only be configurable to a type consuming less memory.
There are a wide variety of other interdependencies. For example, the converters
may only accept particular video input types or produce particular video output types.
So, a particular input may not be functional in combination with a particular converter,
20 and so forth.
Thus, in practice, an obstacle to implementing a desired configuration is that it
may not be functional. Further, it is not easy to determine which combinations are
functional out of the myriad of theoretically possible combinations for a video
presenting network having a plurality of video inputs, a plurality of converters, and a
25 plurality of video outputs (which can be interconnected in a variety of ways).
FIG. 3 is a block diagram showing combinations of configurable resources for a
video presenting network. In the example, the theoretically possible configurations 300
can be assembled by connecting one or more of a configured fmt resource 302 (e.g., a
video presenting network input), with one or more of a configured second resource 304
(e.g., a video presenting network converter), that are connected with one or more of a
configured third resource 306 (e.g., a video presenting network output). The resulting
5 set of theoretically possible configurations 3 10 is shown as a vast collection of
possibilities, some of which are functional, and some of which are non-functional,
depending on the configuration of the resources therein.
Finding a solution for an optimal configuration in such a vast solution space is a
tri-partite graph matching problem, which is an NP-complete problem. Therefore, using
10 a brute force approach can be problematic when the number of possible configurations
for the resources exceeds a reasonable number.
Example 9 - Exemplary Configuration
In any of the examples described herein, configuration of resources can take a
15 wide variety of forms, including selecting a topology for a set of resources of the video
presenting network or selecting configuration options (e.g., modes) for one or more
resources in the network (e.g., whether or not the network is interconnected).
Example 10 - Ewmplary Configuration Method
20 FIG. 4 shows an exemplary configuration method 400 which can be used for any
of the video presenting networks described herein to achieve configuration. The method
and any of the other methods described herein can be implemented via computerexecutable
instructions on one or more computer-readable media.
At 410, an indication of a configuration of a fust resource of the video presenting
25 network is received. For example, a configuration for a particular video input of the
video presenting network can be received.
At 420, separately from the indication of the configuration of the first resource,
an indication of a configuration for a second resource of the video presenting network is
received. For example, a configuration for a particular video output of the plurality of
outputs of the video presenting network can be received.
5 Then, at 430, the video presenting network is coniigured according to the
indications of configurations.
In practice, additional indications of configuration can be separately received for
any resources of the video presenting network (e.g., for two different inputs, two
different outputs, two different converters, a converter and an output, and so forth).
10 Separately received indications can include those received by using two different
calls, such as those to a programmatic interface (e.g., device driver interface calls). For
example, two different calls to a device driver can be used. Or, two different parameters
can be used in the same call. Or, one or more data structures indicating separate values
for the resources can be used. Such calls can come fiom a client such as an operating
15 system.
In such a way, the resources of the video presenting network can be
independently configured. Such configuration can also indicate a topology for the video
presenting network (e.g., how the resources are interconnected).
20 Example 11 - hhzmplary Provisional Configuration
Using a provisional configuration approach can facilitate a variety of
functionality, including finding a desirable configuration among the myriad of possible
functional configurations. FIG. 5 shows a table 500 indicating provisional configuration
of a resource of a video presenting network such as that shown in FIG. 1.
25 In the example, the resource ol has been provisionally configured (e.g.,
configuration parameters for the resource of the video presenting network are stored but
the configuration need not be llly functional). Such a provisional configuration can be
based on receipt of a partial configuration (e.g., a configuration of a resource out of the
video presenting network resources or an indication of a topology for the video
presenting network). Configuration for all resources need not be received for a
provisional configuration. Because a configuration without the full set of configuration
5 parameters is typically not yet functional, a provisional configuration is sometimes
called "semi-functional." Providing a partial configuration for a resource is sometimes
called "pinning" the resource. If desired, the partial configuration can be removed (or
overridden). Removing the partial configuration is sometimes called "unpinning."
10 Example I2 -Exemplary Transactional Configuration
A transactional approach to achieving configuration of a video presenting
network can be based on the described provisional configuration. FIG. 6 shows an
exemplary arrangement 600 for achieving configuration of a video presenting network
630 (e.g., the video presenting network shown in FIG. 1) via a transactional approach.
15 In the example arrangement 600, a client 610 can send partial configuration
information for a video presenting network to a server 620. Upon receiving a commit,
the server 620 can then configure the video presenting network 630 according to the
indications of partial configuration.
FIG. 7 shows an exemplary method 700 for performing configuration via a
20 transactional approach. At 710, a series of partial configurations for the video
presenting network are received (e.g., fiom a client by a server). The partial
configurations can be used to build a provisional functional conf~guration.
At 720, the provisional functional configuration is committed. The committing
can implement the provisional functional configuration in the video presenting network
25 (e.g., the network 630).
A provisional functional configuration can be stored without being implemented.
For example, the configuration can be stored without configuring the resources of the
video presenting network (e.g., until a commit configuration indication is processed).
5 EwampIe 13 - ExempIary Determination of Co-functional Configuration Options
Due to interdependencies between the resources of a video presenting network,
some theoretically possible configuration options may not be functional in light of a
provisionally functional configuration that has already been assembled. For example,
given that the resource ol has been provisionally configured (e.g., as shown in FIG. 5),
10 the configuration options available for another resource of the video presenting network
(e.g., ox) may be restricted.
FIG. 8A shows an exemplary set of configuration options 850 for a resource ox,
out of which only a subset 860 of configuration options are available (e.g., would result
in a functional configuration) in light of how another resource 01 has been provisionally
15 configured. In such an arrangement, the available configuration options are sometimes
described as "co-functional" with the other configuration options (e.g., of the provisional
functional configuration) or "not invalidating" a provisional configuration.
The set of co-functional coniiguration options 860 for a resource can be provided
as feedback during provisional configuration in a process sometimes called
20 "enumeration." Such feedback can then be used to make decisions regarding M e r
configuration (e-g., to M e r build the provisional functional configuration or to
backtrack to an earlier provisional functional configuration).
In some cases, it may be desirable to remove a partial configuration fiom the
provisional functional ~o~gurationFo. r example, it may be discovered that the
25 provisional functional configuration does not permit configuration of an as yet unconfigured
resource in a desired way. Accordingly, any of the configuration methods
described herein can include receiving an indication to remove a partial configuration
fiom the provisional hctional codiguration and remove the partial configuration
responsive to receiving the indication (or, simply a new partial configuration, which
overrides the old). In this way, a method can backtrack (e.g., unpin a resource) to an
earlier provisional functional configuration (e.g., before committing the provisional
5 functional configuration).
Example 14 - Exemplary Determination of Co-functional Configuration Options for
Plural Resources
10 In practice, it may be desirable to determine co-functional configuration options
for plural resources at once. For example, after a given topology is selected as part of a
partial configmtion, it may be desirable to enumerate the configuration options for
video presenting network sources that are co-functional with the selected topology.
FIG. 8B shows an arrangement in which co-functional configuration options
15 880A, MOB, and 880C for respective resources (e.g., ol, oz, and 03) are indicated,
wherein configuration options for more than one resource at a time are indicated. The
co-functional configuration options shown are co-functional with respect to the chosen
topology. The options may not be co-functional with respect to each other. For
example, choosing one of the co-functional options for a first resource may invalidate
20 (e.g., not be co-functional with) another one of the co-functional options of another
resource.
In the example, at least some of the original options (e.g., 870A, 870B, and 870C)
are no longer available (e.g., are not co-functional) in light of the chosen topology. A
similar arrangement is possible when options are enumerated for other resources (e.g.,
25 targets).
Such options can be enumerated by software (e.g., a video driver). In any of the
examples described herein, it may be desirable to guarantee that if any of the enumerated
options are chosen for one resource, such a choice will be co-functional with at least one
(e.g., will not invalidate all) of the options for any of the other resources.
&le 15 -Exemplary Invalidation of Co-Functional Options During Pinning
5 In practice, after having enumerated the configuration options (e.g., for a plurality
of resources) co-functional with a topology for a plurality of resources, such
configuration options can be included in a partial, provisional configuration. However,
pinning (e-g., provisionally choosing) one of the configuration options for a first
resource may invalidate (e.g., not be co-functional with) another option for another
10 resource.
FIGS. 9A-C show an example in which choosing a configuration option for one
resource invalidates a configuration option for another resource. A topology can be
chosen. FIG. 9A shows the co-functional options 920A, 920B, and 920C (e.g., subsets
of theoretically possible options 910A, 920B, and 920C, respectively) enumerated after
15 having chosen a topology. Then, FIG. 9B shows that a particular option 921 has been
chosen (e-g., pinned) for a first resource. As a result, some of the configuration options
for the other resources may no longer be available (e.g., they are invalidated). In the
example, an option no longer appears in 920B'. In some cases, other options are
invalidated. Or, perhaps none are invalidated.
20 FIG. 9C shows that a particular option 922 has been chosen (e.g., pinned) for
another resource. As a result, some of the configuration options for the remaining
resources may no longer be available. In the example, an option no longer appears in
920C". In some cases, some of the options for the first resource may also be invalided
(e.g., resulting in a set 920A9, not shown). However, in practice, after a resource has
25 been pinned (e.g., a configuration option has been chosen for the resource), the pinned
configuration option will not be invalidated by choosing another one of the enumerated
configuration options.
Due to the phenomenon illustrated in FIGS. 9A-9C, when enumerating for plural
resources, it may be necessary to check for invalidated options after pinning a resource.
Such can be performed by re-enumeration.
5 Example I6 - Exemplary Invalidation of Co-Functional Options During Another
Pinning Scenario
FIGS. 1 OA-C show another example in which choosing a configuration option for
one resource invalidates a configuration option for another resource. A topology can be
chosen. FIG. 10A shows the co-functional options 1020A, 1020B, and 1020C (e.g.,
10 subsets of theoretically possible options 10 1 OA, 1020B, and 1020C, respectively)
enumerated after having chosen a topology. Then, FIG. 10B shows that a particular
option 1021 has been chosen (e.g., pinned) for a first resource. As a result, some of the
configuration options for the other resources may no longer be available (e.g., they are
invalidated). In the example, an option no longer appears in 1020B'. In some cases,
15 other options are invalidated. Or, perhaps none are invalidated.
FIG. 10C shows that a particular option 1022 has been chosen (e.g., pinned) for
another resource. As a result, some of the configuration options for the remaining
resources may no longer be available. In the example, an option no longer appears in
1020C". In some cases, some of the options for the first resource may also be invalided
20 (e.g., resulting in a set 1020A', not shown). However, in practice, after a resource has
been pinned (e.g., a configuration option has been chosen for the resource), the pinned
configuration option will not be invalidated by choosing another one of the enumerated
configuration options. Many other scenarios are possible.
Example 1 7 - Ejcemplary Transactional Approach with Feedback
FIG. 11 shows an exemplary arrangement 1 100 for achieving configuration of a
video presenting network 1130 (e.g., the video presenting network shown in FIG. 1) via
a transactional approach with feedback.
5 In the example arrangement 1 100, a client 1 1 10 can send partial configuration
information for a video presenting network to a server 1 120. The partial conf~guration
information can be for any of the resources of the video presenting network. The partial
configuration can indicate a topology of the video presenting network.
After receiving the configuration information (e.g., a partial configuration, such
10 as for a first resource), co-functional configuration options (e.g., for a second resource)
can be provided. The co-functional configuration options can be for a different resource
than the partial configuration, for a resource in a different path, and the like. The cofunctional
options can be restricted (e.g., at least one non-co-functional option is
removed) based on the configuration information. As described herein, the options can
15 be provided via enumeration, and enumeration can be done for plural resources at a time.
The co-functional configuration options for the other resource(s) can be based on
interdependencies between the resources of the video presenting network. The client can
select kom among the co-functional configuration options and continue to build a
provisional functional configuration.
20 Upon receiving a commit, the server 1 120 can then configure the video
presenting network 1 13 0 according to the indications of partial configuration.
FIG. 12 shows an exemplary method 1200 for performing configuration with
feedback fiom a server perspective. The method can operate via the arrangement shown
in FIG. 1 1. At 12 10, an indication of a partial video network presenting configuration is
25 received. For example, the partial configuration can indicate a configuration for a h t
resource of the video presenting network.
At 1220, co-functional configuration options are indicated (e.g., as described for
FIGS. 11A or 1 lB, above). Alternatively, all configuration options may be indicated
with the exception of one or more non-co-functional configuration options, which would
be removed fiom the options indicated before the options are indicated. The method can
5 also include a commit (not shown) by which the configuration is committed to the video
presenting network.
FIG. 13 shows an exemplary method 1300 for performing configuration with
feedback fiom a client perspective. The method can operate via the arrangement shown
in FIG. 1 1. At 13 10, an indication of a partial video presenting network configuration is
10 sent. For example, the partial configuration can indicate a configuration for a first
resource of the video presenting network.
At 1320, a set of co-functional configuration options (e.g., as described for FIGS.
1 1A or 1 IB, above) are indicated. Again, the method can also include a commit (not
shown) by which the configuration is committed to the video presenting network.
15
Example 18 - Exemplary Server Implementation in Video Driver
Determining co-functional configuration options can be delegated to a video
driver. In any of the examples described herein, actions performed by the server can be
performed by a video driver (e.g., a video miniport).
20 FIG. 14 shows an exemplary architecture 1400 in which provisional configuration
with feedback can be implemented. The example includes a client 1410 (e.g., an
operating system, such as the graphics subsystem, an application, or the like), a driver
1420 (e.g., a device-specific video driver operating in kernel mode) with
interdependency logic 1425, and a video adapter 1430, which provides video output to
25 plural display devices 1440A - 1440N.
The video driver 1420 can serve as a server in any of the examples described
herein. The interdependency logic 1425 can include functions for accepting partial
configurations, enumerating co-functional configuration options, and committing a
configuration.
In this way, a hardware vendor of a display adapter can develop an appropriate
driver 1420 that incorporates the appropriate interdependency logic 1425 to aid in
5 determining a desirable video presenting network configuration.
Exawe 19 - Exemplary Advantages
Implementing interdependency logic in a video driver, as discussed above in
Example 18, can simplify determining an appropriate configuration by reducing the
10 scope for a given hardware implementation with a certain set of limitations. If the logic
were instead in the operating system, the task can be more complex (e.g., need to be
completely generic and support every possible interdependency).
Example 20 - Exemplary Configuration of Video Presenting Network
15 FIG. 15 shows an exemplary method 1500 for configuration of a video presenting
network via partial configuration. At 1504, a topology for the video presenting network
is chosen. At 1506, configurations options for the sources are enumerated and pinned.
At 1508, configuration options for the targets are enumerated and pinned. A commit
(not shown) can be used to implement the configuration.
20 In any of the examples herein, although sources are sometimes shown as pinned
before targets, such need not be the case. For example, targets can be pinned before
sources.
Example 21 - Exemplary Traversal of Solution Space to Converge
25 on Functional Configuration
FIG. 16 shows a flowchart of an exemplary method 1600 of traversing a graph of
possible functional multiple video output configuration combinations. Such a method
can be used by a client (e.g., the client 1410) interacting with a server (e.g., video driver
1420). The example shows a video miniport, but another video driver (e.g., video driver
1420) can be used.
The example also includes a fxed topology functional video presenting network
5 configuration search, but other examples may include an option of changing the
topology during the search. For example, a topology may be desired to be changed after
the pinning of a video present source mode on a video presenting network source
invalidates at least one other video present source mode for another video presenting
network source.
10 At 1602, a desired video presenting network topology has been selected.
At 1604, given the desired video presenting network topology, a video miniport is
queried for a video presenting network configuration (e.g., topology) that supports at
least one monitor-supported video signal mode (e.g., all modes) on at least one video
presenting network target (e.g., all targets).
15 At 1606, the set. of available video present source modes on at least one video
present source (e.g., all sources) in the obtained video presenting network configuration
(e.g., topology) are enumerated.
At 1608, a video present source mode is pinned on at least one video presenting
network source (e.g., all sources).
20 At 16 10, it is determined whether there are any more video presenting network
sources on which a video present source mode is to be pinned. If there is another video
presenting network source to be pinned, the process proceeds to 1612. Otherwise, the
process proceeds to 16 14.
At 16 12, it is determined whether any of the previously enumerated video present
25 source modes has been invalidated. If so, the process returns to 1606. If not, the process
returns to 1608. In the example, at least one of the previously enumerated video present
source modes can be invalidated based on the selection of another video present source
mode, but not all of the video present source modes can be invalidated by such a
selection.
At 1614, the sets of available video present target modes on at least one video
present target (e.g., all targets) in the obtained video presenting network configuration
5 are enumerated.
At 1616, a video present target mode is pinned on at least one video presenting
network target (e.g., all targets).
At 161 8, it is determined whether there are any more video presenting network
targets on which a video present target mode is to be pinned. If there is another video
10 presenting network target to be pinned, the process proceeds to 1620. Otherwise, the
process proceeds to 1622.
At 1620, it is determined whether any of the previously enumerated video present
target modes has been invalidated. If so, the process returns to 16 14. If not, the process
returns to 1616.
15 At 1622, a resulting functional video presenting network configuration
combination is committed.
hkarnple 22 - First Exemplary Detailed Traversal of Solution Space to Converge
on Functional Configuration
20 FIGS. 17A-B show a flowchart of a first exemplary detailed method 1700 of
traversing a graph of possible functional multiple video output configuration
combinations. Such a method can be used by a client (e.g., the client 1410) interacting
with a server (e.g., video driver 1420). The example shows a video miniport, but
another video driver (e.g., video driver 1420) can be used.
25 At 1702, an initial video presenting network topology has been provided.
At 1704, given the initial video presenting network topology, a video miniport is
queried for a video presenting network configuration (e.g., toplogy) that supports at least
one monitor-supported video signal mode (e.g., all modes) on at least one video
presenting network target (e.g., all targets).
At 1706, a determination is made as to whether the video presenting network
topology specified by the query of 1704 is supported. If the specified video presenting
5 network topology is supported, then the process proceeds to 1708. Otherwise, the
process proceeds to 1710.
At 1708, a determination is made as to whether the current video presenting
network topology is the most desired video presenting network topology. If it is, then
the process proceeds to 171 2. Otherwise, the process proceeds to 1714.
10 At 1710, a determination is made as to whether at least one other initial video
presenting network topology exists. If so, then the process returns to 1704. Otherwise,
the process terminates at 1790 because there is no convergence to a functional
configuration combination with the desired search parameters.
At 1712, the sets of available video present source modes on at least one video
15 presenting network source (e.g., all sources) in the obtained video presenting network
configuration are enumerated. The process then proceeds to 1722.
At 1714, the video presenting network topology is adjusted to a new valid video
presenting network topology by the addition or removal of a video presenting path (e.g.,
multi-path). The process then proceeds to 171 6, where a determination is made as to
20 whether the new valid video presenting network topology is supported. If so, then the
process returns to 1708. Otherwise, the process proceeds to 17 18.
At 171 8, a determination is made as to whether there is at least one other desired
video presenting network topology that can be obtained by incremental changes through
valid video presenting network topologies. If so, the process proceeds to 1720.
25 Otherwise, the process terminates at 1790.
At 1720, a determination is made as to whether another desired video presenting
network topology is obtainable only by the null topology (e.g., the topology cannot be
firther adjusted). If so, the process returns to 1704. Otherwise, the process returns to
1714.
At 1722, a determination is made as to whether any of the enumerated video
present source modes are missing a mode desired for the respective video presenting
5 network some. If so, the process proceeds to 1924. Otherw~set,h e process proceeds to
1732.
At 1724, a determination is made as to whether any video presenting network
sources have a video present source mode pinned. If so, the process proceeds to 1728,
where a pinned video present source mode is unpinned, and then back to 1712.
10 Otherwise, the process proceeds to 1730. The video present source mode unpinning at
1728 can be ordered according to video presenting network source importance (e-g., the
source modes can be prioritized fiom most to least important).
At 1730, a determination is made as to whether there is at least one other video
present source mode available for a video presenting network source. If so, the process
15 returns to 1732, where a video present source mode is pinned on at least one video
presenting network source (e.g., for all sources), and then to 1734. Otherwise, the
process terminates at 1790. The video present source mode pinning at 1732 can be
ordered according to video presenting network source importance (e.g., the source
modes can be prioritized fiom most to least important).
20 At 1734, it is determined whctktr there am rlny more video pmeefmg rittwork
sources on which a video present source mode is to be pinned. If there is another video
presenting network source to be pinned, the process proceeds to 1736. Otherwise, the
process proceeds to 1738.
At 1736, it is determined whether any of the previously enumerated video present
25 source modes has been invalidated. If so, the process returns to 1712. If not, the process
returns to 1732.
At 1738, the sets of available video present target modes on at least one video
presenting network target (e.g., all targets) in the obtained video presenting network
configuration are enumerated.
At 1742, a determination is made as to whether any of the enumerated video
5 present targets modes are missing a mode desired for the respective video presenting
network target. If so, the process proceeds to 1744. Otherwise, the process proceeds to
1752.
At 1744, a determination is made as to whether any video presenting network
target has a video present target mode pinned on it. If so, the process proceeds to 1748,
10 where a pinned video present target mode is unpinned, and then back to 173 8.
Otherwise, the process proceeds to 1750. The video present target mode unpinning at
1748 can be ordered according to video presenting network target importance (e.g., the
target modes can be prioritized fiom most to least important).
At 1750, a determination is made as to whether there is at least one other video
15 present target mode available for a video presenting network target. If so, the process
returns to 1752, where a video present target mode is pinned on at least one video
presenting network target (e.g., for all targets), and then to 1754. Otherwise, the process
terminates at 1790. The video present target mode pinning at 1752 can be ordered
according to video presenting network target importance (e.g., the target modes can be
20 prioritized fi-om most to least important).
At 1754, it is determined whether there are any more video presenting network
targets on which a video present target mode is to be pinned. If there is another video
presenting network target to be pinned, the process proceeds to 1756. Otherwise, the
process proceeds to 1780.
25 At 1756, it is determined whether any of the previously enumerated video present
target modes has been invalidated. If so, the process returns to 173 8. If not, the process
returns to 1752.
At 1780, a resulting functional video presenting network configuration
combination is committed.
Example 23 -Second Exemplary DetaiIed TravemaI of Solution Space to Converge
5 on Functional Configuration
FIGS. 1 8A-C shows a flowchart of a first exemplary detailed method 1800 of
traversing a graph of possible functional multiple video output configuration
combinations. Such a method can be used by a client (e.g., the client 1410) interacting
with a server (e.g., video driver 1420). The example shows a video miniport, but
- 10 another video driver (e.g., video driver 1420) can be used.
At 1802, an initial video presenting network topology has been provided.
At 1804, given the initial video presenting network topology, a video miniport is
queried for a video presenting network configuration (e.g., topology) that supports at
least one monitor-supported video signal mode (e.g., all modes) on at least one video
15 presenting network target (e.g., all targets).
At 1806, a determination is made as to whether the video presenting network
topology specified by the query of 1804 is supported. If the specified video presenting
network topology is supported, then the process proceeds to 1808. Otherwise, the
process proceeds to 18 10.
20 At 1808, a determination is made as to whether the current video presenting
network topology is the most desired video presenting network topology. If it is, then
the process proceeds to 18 12. Otherwise, the process proceeds to 18 14.
At 1810, a determination is made as to whether at least one other initial video
presenting network topology exists. If so, then the process returns to 1804. Otherwise,
25 the process terminates at 1890 because there is no convergence to a functional
configuration combination with the desired search parameters.
At 18 12, the sets of available video present source modes on at least one video
presenting network source (e.g., all sources) in the obtained video presenting network
configuration are enumerated. The process then proceeds to 1822.
At 18 14, the video presenting network topology is adjusted to a new valid video
5 presenting network topology by the addition or removal of a video presenting path (e.g.,
multi-path). The process then proceeds to 1816, where a determination is made as to
whether the new valid video presenting network topology is supported. If so, then the
process returns to 1808. Otherwise, the process proceeds to 1 8 18.
At 18 18, a determination is made as to whether there is at least one other desired
10 video presenting network topology that can be obtained by incremental changes through
valid video presenting network topologies. If so, the process proceeds to 1820.
Otherwise, the process terminates at 1890.
At 1820, a determination is made as to whether another desired video presenting
network topology is obtainable only by the null topology (e.g., the topology cannot be
15 fUrther adjusted). If so, the process returns to 1804. Otherwise, the process returns to
1814.
At 1822, a determination is made as to whether any of the enumerated video
present source modes are missing a mode desired for the respective video presenting
network source. If so, the process proceeds to 1824. Otherwise, the process proceeds to
20 1832.
At 1824, a determination is made as to whether any video presenting network
sources have a video present source mode pinned. If so, the process proceeds to 1828,
where a pinned video present source mode is unpinned, and then back to 18 12.
Otherwise, the process proceeds to 1830. The video present source mode unpinning at
25 1828 can be ordered according to video presenting network source importance (e-g., the
source modes can be prioritized fiom most to least important).
At 1830, a determination is made as to whether there is at least one other video
present source mode available for a video presenting network source. If so, the process
returns to 1832, where a video present source mode is pinned on at least one video
presenting network source (e.g., for all sources), and then to 1834. Otherwise, the
5 process proceeds to 183 1. The video present source mode pinning at 1832 can be
ordered according to video presenting network source importance (e.g., the source
modes can be prioritized from most to least important).
At 1 83 1, a determination is made as to whether there is at least one other video
present source mode available for a video presenting network source given any other
10 desired video presenting network topology. If so, the process returns to 18 18.
Otherwise, the process terminates at 1890.
At 1834, it is determined whether there are any more video presenting network
sources on which a video present source mode is to be pinned. If there is another video
presenting network source to be pinned, the process proceeds to 1836. Otherwise, the
15 process proceeds to 1838.
At 1836, it is determined whether any of the previously enumerated video present
source modes has been invalidated. If so, the process returns to 1 8 12. If not, the process
returns to 1832.
At 1838, the sets of available video present target modes on at least one video
20 presenting network target (e.g., all targets) in the obtained video presenting network
configuration are enumerated.
At 1842, a determination is made as to whether any of the enumerated video
present targets modes are missing a mode desired for the respective video presenting
network target. If so, the process proceeds to 1844. Otherwise, the process proceeds to
25 1852.
At 1844, a determination is made as to whether any video presenting network
target has a video present target mode pinned on it. If so, the process proceeds to 1848,
where a pinned video present target mode is unpinned, and then back to 1838.
Otherwise, the process proceeds to 1850. The video present target mode unpinning at
1848 can be ordered according to video presenting network target importance (e.g., the
target modes can be prioritized fiom most to least important).
5 At 1850, a determination is made as to whether there is at least one other video
present target mode available for a video presenting network target given the current
video presenting network topology and video present source modes pinned on video
presenting network sources. If so, the process returns to 1852, where a video present
target mode is pinned on at least one video presenting network target (e.g., for all
10 targek), and then to 1854. Otherwise, the process proceeds to 1856. The video present
target mode pinning at 1852 can be ordered according to video presenting network target
importance (e.g., the target modes can be prioritized fiom most to least important).
At 1854, it is determined whether there are any more video presenting network
targets on which a video present target mode is to be pinned. If there is another video
15 presenting network target to be pinned, the process proceeds to 1868. Otherwise, the
process proceeds to 1880.
At 1856, a determination is made as to what is considered to be more important:
the current video presenting network topology or the video present source modes
currently pinned on video presenting network sources. If the video present source
20 modes currently pinned on video presenting network sources are considerEd to be more
important, the process proceeds to 1862. If the current video presenting network
topology is considered to be more important, the process proceeds to 1864.
At 1862, it is determined whether there is at least one other desired video
presenting network topology. If so, the process returns to 18 18. If not, the process
25 proceeds to 1866.
At 1864, a determination is made as to whether there is at least one other desired
video present source mode given the current video presenting network topology. If so,
the process retums to 1828. Otherwise, the process proceeds to 1862.
At 1866, a determination is made as to whether there is at least one other
5 desirable video present source mode available on at least one video presenting network
source. If so, the process proceeds to 1864. Otherwise, the process terminates at 1890.
At 1868, it is determined whether any of the previously enumerated video present
target modes has been invalidated. If so, the process returns to 1838. If not, the process
returns to 1852.
10 At 1880, a resulting functional video presenting network configuration
combination is committed.
Example 24 -Exemplary Method of Achieving Goal Configuration
FIG. 19 shows a flowchart showing an exemplary method 1900 of determining a
15 topology for a video presenting network in light of a goal (e.g., stated in terms of video
modes supported by monitors).
At 1902, the process starts with an initial topology. At 1906, the initial topology
is modified to better meet the goal (e.g., by generating a provisional functional
configuration better meeting the goal). Such modifications can take into account
20 interdependencies among resources of the video presenting network.
Possible goals can relate to video modes or other configuration options. For
example, a goal can be the best way to route video presenting network targets to video
presenting network sources in a video presenting network through the available video
output codecs to maximize supported graphics video presenting network source mode
25 sets on its video presenting network sources, given that video mode sets on the video
presenting network targets must support preferred modes on all the monitors connected
to them. Or, if such a goal cannot be attained, the goal can be the best way to route
video presenting network targets to video presenting network sources in a video
presenting network through the available video output codecs to maximize supported
graphics video presenting network source mode sets on its video presenting network
sources, given that video mode sets on the video presenting network targets must
5 support preferred modes on the monitors connected to them in a specified prioritization
ordering. Or, if such a goal cannot be attained, the goal can be the best way to route
video presenting network targets to video presenting network sources in a video
presenting network through the available video output codecs to maximii supported
graphics video presenting network source mode sets on its video presenting network
10 sources, given that video mode sets on the video presenting network targets must
support at least one of the video modes supported by the monitors connected to them.
If desired, a first goal can be attempted. Then, if the first goal cannot be met, a
second goal can be attempted, and so forth. A goal is sometimes described as an
"optimal" configuration.
15
Ejcample 25 - Exemplary Additional Goals
In addition to the goals described above, other configuration goals may be desired
and can be facilitated by the technologies described herein. For example, it might be of
interest to achieve the following, separately or in some combination:
20 1. Maximize the special resolution on the render targets
2. Maximize the color resolution on the render targets
3. Maximize both spatial and color resolutions on one of the render targets (e.g.,
for medical imaging applications, computer assisted design, and the like).
4. Match refiesh rates on the monitors displaying a view which contains a real-
25 time television broadcast presentation to avoid video stream synchronization issues.
Such synchronization issues can manifest themselves as artifacts, dropped h e s (e.g.,
glitches), or both.
5. Conserve the video memory bandwidth as much as possible by driving views
at lowest rendering modes acceptable to boost 3D performance, assuming one or more
GPUs are competing for the same video memory bus.
Because such goals are beyond the scope of a simple video driver, such goals can
5 be achieved by placing decision-making ability outside of the video driver (e.g., in the
upper layers of the operating system, such as in the shell, graphics subsystem, DX
runtime, and the like).
Due to the sheer amount of possible rendering modes, a driver can not simply
enumerate them. A query or a traversal approach (e.g., such as described in the
10 examples herein) can be used to achieve configuration goals.
Still other goals can be classified as follows:
1. In a mode optimized for image quality, one cares most about displaying the
image to the best degree possible.
2. In a mode optimized for performance, one cares most about not overloading
15 the video memory bus (e.g., each codec has to read from .the video memory, and thus
1
consumes video memory bandwidth).
3. In a mode optimized for power consumption, one may want to choose the
codec which consumes the least power, even if it can not drive preferred modes on either
of two monitors, turning all other codecs off.
20 ' Typically, an implicit goal in any configuration is that the video outputs support
at least one mode supported by the respective monitor. Unless overridden by
performance or power management considerations, it is typically a further goal that
video outputs try to support preferred modes of their respective monitors, where the
monitor's importance is prioritized by the client (e.g., operating system) as part of the
25 configuration request.
For example, the present the same render target on multiple views (e.g., clone
view), the video driver should attempt to have as many monitors to run in their preferred
modes, only sharing codecs when doing otherwise means one of the requested outputs
can not be driven.
For example, in a case involving three video outputs, but only two codecs, it
might be acceptable to share a codec when asked to support all three outputs, even if at
5 least one of the monitors might not be running in its preferred mode. However, when
asked to support only two of the outputs, a codec should not be shared if preferred
modes can be achieved on both monitors by not sharing a codec.
Example 26 - Exemplary Goals Related to Power Consumption
10 In some scenarios, it may be desirable to specify goals with respect to power
consumption. For example, a configuration with smaller power consumption may be
preferred for economy power states, and performance and/or image quality may be
preferred when in full-power states. In any of the examples herein, such goals can be
implemented. .
15
Example 2 7 - Exemplary Device Driver Inteface
Example 45 lists a set of functions (e.g., EnumerateAvailVidPNTargets,
ConstrainNodesOnVidPNTargets, etc.) and their purposes. Such functions can be
included in a device driver interface supported by a video device driver (e.g., a video
20 miniport). The functions can be used by clients to build a video presenting network in
incremental fashion, employing various algorithms (e.g., search algorithms).
Example 28 -Exemplary Functions for Confguration Management
Example 45 details a set of functions for configuration management. For
25 example, a function (e.g., GetActiveVidPNTopology) identifies a video presenting
network configuration (e.g., a topology). Another function (e.g., CornmitVidPNImpl)
commits a video presenting network configuration. Another function (e.g.,
EnumCurrentlyAvailVidPNSourceModeSets) enumerates video present source modes
available given a desired video presenting network configuration. Another function
(e.g., EnumCurrentlyAvailVidPNTargetModeSets) enumerates video present target
modes available given a desired video presenting network configuration. Another
5 function (e.g., PinModeOnVidPNSource) pins a video present source mode on a video
presenting network source. Another function (e.g., PinModeOnVidPNTarget) pins a
video present target mode on a video presenting network target. Another function (e.g.,
UnpinModeOnVidPNSource) unpins a video present source mode on a video presenting
network source. Another function (e.g., UnpinModeOnVidPNTarget) unpins a video
10 present target mode on a video presenting network target. Another function (e.g.,
CreateVidPNImpl) creates a video presenting network configuration. Any combination
of the functions can be implemented as part of a programmatic interface (e.g., a device
driver interface). Such an interface can provide access to the functions as a service (e.g.,
for client programs).
Example 29 - Ejwmglary Calls to Am-ve at Configuration
FIG. 20 shows a block diagram showing exemplary calls to arrive at a
configuration. Such calls can be implemented as part of a device driver interface (DDI).
System 2000 includes communication between a driver 2002 (e.g., video
20 miniport) and a graphics kerne1,subsystem 2004. Given a specified video presenting
network configuration, EnumAvailVidPNTargets can be called to enumerate available
video presenting network targets supported by a given video card.
EnumAvailVidPNSources can be called to enumerate available video presenting
netwoik sources supported by the given video card. These two calls can be part of a
25 system initialization. Alternatively, these two calls can be part of a video adapter amval
event (e.g., PC1 express or docking station hot-plug). In some situations, a null video
presenting network configuration modality can be supported, signifying that all available
video presenting targets and sources should be reported (e.g., as is appropriate for
initialization).
IsMonitorConnected can be used to determine which of the enumerated video
presenting targets have a monitor connected to them. GetMonitorDescriptor can be
5 called for each of the connected monitors to obtain each respective monitor's descriptor.
ConstrainModesOnVidPNTargets can be called to set video mode constraints on each of
the enumerated video presenting targets in line with the monitor capabilities obtained
fiom the monitors' descriptors.
During video presenting network construction, GetInitialVidPNImpl can
10 optionally be called to obtain a video presenting network provisional configuration
recommended by the video miniport. CreateVidPNImpl can be called to create a video
presenting network provisional configuration based on the optional recommendation by
the video miniport. Alternatively, CreateVidPNLmpl can create a video presenting
network provisional configuration disregarding the optional recommendation by the
15 miniport.
EnumCurrentlyAvailVidPNSourceModeSets, PinModeOnVidPNSource, and
UnpinModeOnVidPNSource can be called until video presenting source modes are
pinned on the video presenting network sources, as part of creating a semi-functional
video presenting network. If video presenting source modes to be pinned are known to
20 work for the video presenting network sources, PinModeOnEachVidPNSource can be
called to pin video presenting source modes on all the video presenting network sources
at once.
EnumCurrentlyAvailVidPNTargetModeSets, PinModeOnVidPNTarget, and
UnpinModeOnVidPNTarget can be called until video presenting target modes are
25 pinned on the video presenting network targets, as part of completing a functional video
presenting network. If video presenting target modes to be pinned are known to work
for the video presenting network targets, PinModeOnEachVidPNTarget can be called to
pin video presenting target modes on all the video presenting network targets at once.
To commit a video presenting network provisional configuration,
CornmitVidPNImpl may be called. A functional video presenting network provisional
5 configuration may be committed after primary surface chains have been set up for each
source in the video presenting network. CommitVidPNImpl might require as input other
0s-owned resources outside of the video presenting network topology and video
presenting sources and targets (e.g., primary surface chains).
10 Example 30 - Bemplary Separation of Video Output and Render Target
An interface that a video rendering device driver exposes (e.g., to an operating
system, and thus indirectly to applications running on the operating system) need not
differentiate between the notion of a video output on which the video rendering device is
physically driving the displayed image and a render target to which the application is
15 logically rendering the content it wants to be presented as two separate, independent
entities. The render target can be implicitly and statically associated with each video
output on the video rendering device. However, such an approach can be limiting.
In any of the examples described herein, an explicit notion of a render target can
be supported through the notion of a rendering mode. A display mode that is the basic
20 operational modality descriptor of any device in an operating system can be described as
two things: a video mode, which is an output modality descriptor (for an output or target,
such as those shown in FIG. 1 or FIG. 25), and a rendering mode, which is an input
modality descriptor (for an input or source, such as those shown in FIG. 1 or FIG. 25).
Such an approach is particularly useful in system with multiple video outputs. Interfaces
25 to the video driver (e.g., a DDI) can allow separate specification of the video mode and
the rendering mode.
Thus, logical render targets can be dynamically managed separately fiom the
physical video outputs. The targets can be mapped to video outputs of choice in runtime,
redirecting them fiom output to output as needed, or even mapping a single render
target simultaneously to multiple outputs.
5
Example 31 - Exemplary Management for Monitor ArrivaUDeparhrre
Any of the technologies described herein can be applied to scenarios in which a
monitor is attached to or removed from a system while it is running. For example,
events (e.g., HPD events) can be detected by a system when a monitor arrives or departs
10 &om the system, and a configuration can be chosen accordingly. Also, changes to
redirect video streams to different outputs (e.g., for clone view, extended desktop
management, and the like) can be implemented. Robust support for such dynamic
configuration changes can be accomplished by managing logical render targets
separately from the physical video outputs as described herein.
15
Example 32 -Exemplary Integration of Technology
In any of the examples described herein, the video display devices can take a
variety of forms. For example, FIG. 21 shows an exemplary integration of the
technology into a computer system having a plurality of video display devices.
20 FIG. 21 is a diagram of an exemplary high-level architecture of a multiple video
output device system 2 100. A desktop 2 1 10, a display properties applet 2 1 12, and a
full-screen graphics application 21 14 communicate with a graphics subsystem 2120.
The graphics subsystem 2 120 drives a video driver 2 130 and another video driver 2 132.
Both video drivers (e.g., video miniports) communicate through a hardware abstraction
25 layer (HAL) 2140 to video adapters 2150 and 2 152, which send outputted signals to any
combination of multiple video output devices. Such video output devices can include a
CRT monitor 2 160, a flat-panel monitor 2 162, a digital projector 2 164, an LCD monitor
2 166, a pair of virtual reality goggles 2 168, and the like. Other combinations than those
shown are possible.
Ejcample 33 -Exemplary Traversal of Solution Space to Converge
on Desired Configuration
FIG. 22 shows a client-server system 2200 in which a video configuration is
determined based on priorities. A client 2202 communicates with a server 2204. The
client 2202 contains priorities 2206 that specify prioritization information.
Such prioritization information can include a list of one or more desired
10 topologies, a list of desired modes for respective sources, a list of desired modes for
respective targets, the like, or some combination thereof. Prioritization information can
also include whether certain source modes are more important than topology selection.
Additionally, the source modes desired and the target modes desired can be prioritized
(e.g., ftom most to least important).
15 Such priorities can be in the form of a prioritized list. However, the priorities can
also be achieved by incorporation into logic (e.g., if-then statements in the client 2202).
FIG. 23 shows an exemplary method 2300 for determining a video configuration
based on a prioritized list of desired video configuration options, such as in the system
shown above in FIG. 22.
- 20 - At 2302, a partial video configuration for at least a first resource is submitted.
At 2304, a list of configuration options co-functional with the partial video
configuration is received.
At 2306, a determination is made as to whether a desired option in the prioritized
list is present in the list of configuration options co-functional with the partial video
25 configuration.
At 2308, in response to a determination that the desired option is not present, a
modified partial configuration is re-submitted for the first resource. In practice, a tradeof
between priorities may be desirable.
Detailed examples are included in the present application (e.g., Appendix A at
5 Figures 5 and 6).
Erample 34 -Exemplary Traversal of Solution Space lo Converge
on Desired Configuration where Topology can be Changed
FIG. 24 shows a flowchart of another exemplary method 2400 of traversing a
10 graph of possible functional multiple video output configuration combinations. The
example, however, includes the possibility of changing the topology during
determination of a desired bctional video presenting network provisional
configuration.
At 2402, a particular topology is selected.
15 At 2404, a video present source mode is selected and pinned on a video present
source.
At 2406, it is determined whether any video present target modes are available
(e.g., via enumeration). If so, the process continues to 2408. If not, the process
advances to 2410.
20 At 2408, a video present target mode is selected and p i ~ e odn a video present
target. The method can then end (e.g., after a commit).
At 24 10, it is determined whether having the previously selected topology is more
important than having the selected video present source mode. If the answer is yes, a
different video present source mode is selected and pinned on the video present source at
25 2412 and the process returns to 2406. If not, a different topology is selected at 2414 and
the process returns to 2404.
Although the example shows a trade-off between source mode and topology,
other trade-offs among resources are possible. Further, as shown in some of the other
example, desired options can be prioritized.
The logic implemented in the example and demonstrated in FIG. 24 may be
5 altered to accommodate multiple video present sources and/or multiple video present
targets, similar to that demonstrated above and in FIG. 16. For example, the logic
implemented at 241 0-24 14 in FIG. 24 can be inserted between 1608 and 16 10 and/or
between 1616 and 1618 in FIG. 16.
the example, the search begins with an initial topology, as is done at 2402 in
10 FIG. 24. For video present paths in the topology, a video present source mode can be
pinned on the video present path's video presenting network source before a video
present target mode can be pinned on the video present path's video presenting network
target. For example, a search can start with a single source-view video present path, pin
modes on both the source and the target, and then grow the topology by adding another
15 video present path to it. Alternatively, the topology can be changed when only the video
present source mode is pinned.
Example 35 -Exemplary Use of Configuration Service
Exemplary execution of the codiguration service can proceed to configure a
20 video presenting network. The example assumes a video presenting network with three
sources in its topology and the following video present source mode sets enumerated for
each of the w e sources:
I. (1, (1, 640x480), (2, 800x600), (3, 1024x768), (4, 1280x1024) 1)
3. (3, (1, 640x480), (2, 800x600), (3, 1024x768)))
Supposing the client is interested in getting the highest possible spatial resolution
on each of the video presenting network sources, the first video presenting network
source being most important, the second video presenting network source being the
second-most important, and the third and last video presenting network source beiig of
least importance, it would proceed to pin the highest mode on the first video presenting
network source, which is (4, 1280x1024 1.
5 By doing so, however, the client invalidates modes (4, 1280x1024 ) , (5,
I ~ O O X ~ ~ O Oan) d, ( 6, 2000~15ooo n the second video presenting network source. Since the
client isn't yet aware of this, it will try and pin the highest mode previously enumerated
on the second video presenting network source (e.g., ( 6 , ~ O O O X ~ ~ O O w) ) h, ich will fail
with a status code stating that the specified video present source mode has been
10 invalidated.
At this point, the client will re-enumerate the available video present source
modes across all the video presenting network sources, obtaining the following three
sets:
I. (1, 11, 640x480), (2, 800x600), (3, 1024x768), (4, 1280x1024) } )
15 2. (2, 11, 640x4801, (2, 800x600), (3, 1024x768) 1)
3. (3, {I, 640x480), (2, 800x600), (3, 1024x768) 1)
The client would then proceed to pin the highest available video present source
mode on the second video presenting network source (e.g., (3, 1024x768)). TO support
this additional mode, however, the video card can no longer support neither ( 2, 800~60)0
20 nor (3, 1024x768 ) on the third video presenting network source.
Again, not being aware of this fact, the client will try to pin the highest mode
previously enumerated for that video present source (e.g., ( 3, 1024x7 68 ) ). Failing that,
the client will re-enumerate the available modes across all sources, getting:
1. (1, (1, 640x480), (2, 800x600), (3, 1024x7681, (4, 1280x1024) 1)
25 2. (2, {I, 640x480), (2, 800x600), (3, 1024x768) 1)
3. (3, {I, 640x480) 1)
leaving it with only one mode choice for the third and last video presenting network
source.
At this point, the client can either accept this source mode distribution and
proceed to pin target modes to arrive at a functional video presenting network, or it may
decide that 640x480 spatial resolution isn't high enough for it and backtrack to find a
more suitable solution (e.g., one that perhaps doesn't involve setting 1280x1024 spatial
5 resolution on the first video presenting network source, or alternatively, one that has
only 2 video presenting network sources in its topology).
The following marked-up list of modes summarizes the whole process, with bold
and underlined modes in each set representing the pinned modes, single strikethrough
modes representing the modes invalidated when the mode on the first video presenting
10 network target was pinned, and double strikethrough modes representing the modes
invalidated when the mode on a second video presenting network target was pinned:
1. (1, (1, 640x480), (2, 800x600), (3, 1024x768), (4, 1280x10241))
2. (2, (1, 640x480), (2, 800x600), (3, 1024x7681, -f+-32- -,
-) )
15 3. (3, (1, 640x4801, -, -1)
It can be noted that the above algorithm uses a simplistic Greedy approach for
rendering multi-mode convergence, and that it doesn't employ back-tracking. A more
complicated search (e.g., a depth-fmt search) can be used by the client instead to find a
more optimal rendering multi-model. It can also be noted that the above algorithm
20 assumes a desired topology is fvted through the convergence process, such as in the
. exemplary method 1600 in FIG. 16.
Example 36 - Exemplary Multi-MonitorMulti- View System
FIG. 25 is a diagram of an exemplary multi-monitor/multi-view system 2500,
25 which can be described using the following formalism. Sometimes the term "VidPN" is
used in place of ''video presenting network," and "video present" is used in place of
"video presenting." Also, the term "implementation" is sometimes used to refer to a
provisional configuration. The system 2500can be used with any of the examples
described herein.
1. M is a set of monitors 25 10 m = (s,), where:
a. Monitor m is video presenting device that monitors the output of a video
rendering device, and
b. SM E {EDIDv1.0,EDIDvl.l,EDIDv1.2,EDIDv1.3,EDIDv1.w3it h
DIEXT ) is a monitor descriptor.
T is a set of video present targets 2520 t = (b)o,f a video rendering device,
where:
a. 6, E { (Fonnat[ST], HPD-aware[&,]) ) is a video present target descriptor,
where:
i. Format[G, ] E VC = ( DVI, HDMI, HDMI-2, HD-15, BNC, 4-pin S-video,
7-pin S-video, RF, RCA composite, 3 component RCA, Other ) is a video
output format type,
ii. HPD-awareness[G,] E HPD a ( Interruptible, Non-Destructively Polled,
~estructivel~~olNleodn,e ) is the video output HPD-awareness, where
video output has:
1. Interruptible HPD-awareness iff (if and only if) video miniport can
asynchronously notify the OS about monitor arrivalddepartures.
2. Non-Destructively Polled HPD-awareness iff video miniport can
report monitor arrivalsldepartures to the OS only by periodically
polling the underlying hlw, without causing visual artifacts.
3. Destructively Polled HPD-awareness iff video miniport can report
monitor arrivals/departures to the OS only by sporadically polling the
underlying h/w, causing visual artifacts on each poll.
4. No HPD-awareness iff video miniport is not aware of monitor
arrivalsldepartures and, hence, can not asynchronously notifl or
synchronously report occurrences of such events to the 0s.
b. Encoding E ( v E )i~s a video encoding type, where:
i. PE = { Digital- Y CbCr, Digital-RGB, Analog-YPbPr, Analog-RGB,
Analog-YC, Analog-Composite, Other ) is a video encoding type, and
Video output connectors are mapped to respective video output encoding as
specified in Table 1, shown below (note: presence of DDC support implies possibility to
acquire a monitor descriptor, 6, ):
10 Table 1- Video Output Connectors to Output Encoding Mapping
1 Digital - YCbCr
(+audio)
Video output
connector type
DVI
HDMI
I I
HD-15 1 Analog- R GB I Sometimes
Video enkoding type
Digital- R GB Or
Digital- Y CbCr
Digital- R GB Or
HDMI-2
DDC
support
Yes
Yes
( ~nalo-gY PbPr I
Digital- R GB Or
Digital- Y CbCr
BNC
Yes
Analog-RGB . or
7-pin S-video
4-pin S-video
No
Analog -Y C
Analog- Y C
No
I
Yes
No
RCA composite Analog- C omposite
c. Synchronized
3 component RCA
RF
Other
True : present t arg et modes on t, and t, are in sync
: T2 + {True, False} = is a
False : otherwise
video output synchronization predicate, which, given two outputs,
Analog YPbPr
Analog - Composite
Other
determines whether they are in sync with each other or not.
No
No
Unknown -
3. K is a set of video presenting codecs 2530 K = (6K), where:
a 6K is a video codec descriptor.
10 4. C is a set of video present sources 2550 0 = (6,), where:
a. 6, E { Linear, Other ) is a video present source descriptor, and
b. The content of each video presenting network input that is presented on a
monitor, is called a view.
15 5. V is a set of views 2560 v = (&), where:
a. 6, E ( (Importance[Gv], Orientation[Gv]) ) is a view descriptor, where:
i. Importance[GV] € ( Primary, Secondary, Other )
ii. Orientation[Sv] € { Left, Right, Center, Other )
20 6. S = Z,, = (O..OxflBEE) is a set of 32-bit spatial coordinates.
7. @ is a set of display modes 0 = (we &re,&), where:
-44-
a we E S \{O) is the display mode width.
b. h, E S \{O) is the display mode height
c. re E 4 is the display mode frame rate, where:
i. & = { a. b I a, b € {l..OxFFFF) ) is a set of display mode frame rates in
Hz.
d. f, E FB is the display mode unit format, (i-e. effective color resolution of the
monitor - a physical parameter that is a function of the monitor technology),
where:
i. F, = { lbit, Sbit, 6bit, 8bit, lobit, 12bit, 16bit, 18bit, 32bit, TBD ) is a set
of display mode color resolutions.
e. g ,E [l.O,i-m)u{SD-60l,HD-70is9 t)h e monitor transfer function (i.e.
monitor gamma) which is a function of the monitor technology's intensity
response.
15 8. B is a set of video present target modes,
P = ( A B , T B , A ( A , T , ) . ~ B , ~ ~ ~ ~ ~ B , ~ ~ , ~ B , ~ P B , ~ ~ , T B ~ + ~ B ~ ~ Pa~ls$oW P O B ~ P ~ )
known as present target modes, where:
a A, E { (Width[ A* 1, Height[ AB 1) ) is the video present target mode active
region, where:
i. Width[AB] is video present mode active region width.
ii. Height[AB ]is video present mode active region height.
b. TB E { (Width[T,], Height[TB]) ) is the video present target mode total
region, where:
i. Width[TB] is video present mode total region width.
ii. Height[TB] is video present mode total region height.
c. A(A,T,) E { (OffSetHOk[ABT, , I, ~ffset~eAr,t r, T , 1) is the video present
target mode's active region displacement, where:
i. OffsetHok[A, ,TB] is video present mode's horizontal active region
displacement.
ii. OffsetVert[ A,, T,] is video present mode's vertical active region
displacement.
d. f, E FB = FB,dog u FB,*- is the video mode pixel encoding format, where:
i. FBrdisi=fa {l YlOCblOCrlO, Y8Cb8Cr8, sRlOGlOB10, sR8G8B8 ) is a set
of digital video mode pixel encoding formats.
.. 11. F, E { YPbPr, Analog-YC, Analog-Composite, RGB ) is a set of
analog video mode pixel encoding formats.
e. vr, E VR, is the vertical refresh rate, also known as Vsync rate, or vertical
retrace frequency, where:
i. VR, = { a.b I a, b € {l..OxFFFFFFFF) ) is a set of rational vertical
refresh rates in Hz, usually found in the range of 50 to 200 Hz.
f. hr, E HR, is the horizontal refresh rate, also known as Hsync rate, line
rate, or horizontal retrace frequency, where:
i. HR, = { a. b I a, b € {I ..OxFFFFFFFF) ) is a set of fractional horizontal
refresh rates in Hz, usually found in the range of 10 to 200 KHz.
g. cr, E CR, is the pixel clock rate, where:
i. CR, = { a I a € {1 ..OxFFFFFFFF) ) is a set of pixel clock rates in Hz,
usually found in the range of 1 to 5OOMHz.
h. o, E 0, is the content ordering, where:
i. 0, = { Progressive, Interlaced-upperFieldFirst,
Interlaced-1owerFieldFirst ) is a set of content ordering types, where for
progressive content orderingfield rate = Vsync rate, and for interlaced
content orderingfield rate = 2x Vsync rate.
i. cp, E CP, are the color primaries. (3 primaries in (x,y), where x=X/(X+Y+Z)
and y=Y/(X+Y+Z) which are relative to some spec.).
j. wpr, E CP, is the white point reference (i.e. reference white).
k. gB E [I .O,w) u {SD - 601, HD - 709) is the transfer function's exponent (i.e.
gamma coefficient).
I. T,,,,, is the color space transformation matrix from Y'U'V' to R'G'B'.
m. bpoB E %+ is the black point offset (i.e. setup voltage).
n. wpoB E %+ is the white point offset.
o. p m E~ Z,, =(O . . Oxff) is the video present target mode preference
ordinal, where mode preference is represented via the (0x01 ..Oxff) range
with Ox0 1 signifying the most preferred and Oxff - the least preferred mode or
irrelevant mode preference. Ox00 is reserved for uknownlnot initialized.
Certain video modes are defined through an industry-wide standardization (both
de-facto and formal). These modes can include those listed in Table 2 below, as well as
the following continuous set of modes defined by the VESA Generalized Timing
Formula (GTF):
20 Pcm Bcm,m u Pm,m u Vm,cR
where:
~ m , m - # ~ r B , ~ ~ ~ m ~ + H R ~ ( v r B , o B * w B ~ h B b ~ ~ m ~ + m ~ ( v r B , o ~ ~ w B , h B ) ) l v r B ~ ~ ~ . ]
PC~;,HR # G T F ~ ~ + ~ ~ ( ~ ~ B , o B , w B , ~ B ~ ~ o(~hr,BG,o~BHY~w~B+,~~))Rlh~rB E HRB J
' p m , C R P [ G ~ ~ ~ B + H R ~ ( c r B , o B ~ w B ~ h B ~ G p m ~ + ~ ~ ( v r B 9 0 B 9 w B ~ h B b c r B ) [ c r B E c ~ B ]
25 Table 2 - Modes
-47-
Name
NTSC-M
NTSC-J
NTSC-443
YlOCblOCrlO
(RlOGIOBIOfubrre)
YlOCblOCrlO
-48-
Width
(Pixels)
720
720
720
Height
pixels)
525
525
525
Pixel E- Format
YPbR
AnalogYC
AnalogComposite
Same
Same
Vsym rate
(Hz)
6000W1001
60000/1001
60000/1001
Hsync rate
(Hz)
15,734.27
15,734.27
15,734.27
Pixel clock
rate@)
3,579,545
3,579,415
4.433.618.75
YW-
>RGB
Tnmsfm
Matrix
601
601
601
Content
Ordaing
Intalaced
Interlaced
Interlaced
EIA-861-8
EM-861-9
EM-861-10
EM-861A-1
(sRlOG1OBlO futun)
-49-
720
1280
1920
720
480
720
1080
576
Same
Same
Same
YPbPr(pALtiming)
sRGB
Y8CbSCr8
YlOCblOCrlO
(sRlOGlOBl0 firhrre)
60
60
60
50
601
709
709
601
Progressive
Rogrcssive
htdaad
Interlaad
9. r is a set ofvideo present source modes, ~=(w,,h&,~,+,~rn,), also known
as present source modes, where:
a, w, E'S \ (0) is a video present source mode width.
b. h, E S \ (0) is a video present source mode height
c. f, E Fr is a video present source mode unit format, where:
-50-
i. F, is a set of video present source mode unit formats, which can be
categorized into two major subclasses:
1. Graphics video present source mode unit formats, as defined by
D3DFORMAT enum type in the latest Direct. release.
2. Text video present source mode unit formats, as defined by TBD.
d. p, E Y, is a rasterized graphics filtering technique used during rendering,
where:
i. Yr is a set of rasterized graphics filtering techniques, as defined by
D3DDDTMULTISAMPLE-TYPE enum type in the latest DirectX release.
e. n, E N is the primary surfaces chain length (i.e. number of surfaces in the
primary surfsces chain).
f. pmr E Z2, ={O . . Ox@ is the video present source mode preference
ordinal, where mode preference is represented via the {Ox01 ..Ox@ range
with Ox0 1 signiwg the most preferred and Oxff - the least preferred mode or
irrelevant mode preference. Ox00 is reserved for unlcnownlnot initialized.
10. E T~ is a monitor connectivity topology - i.e. mapping fiom monitors to the
video present targets they are connected to.
20 11. p, E K~ is a video present targets-to-codecs topology - i.e. mapping fiom
video present targets to video present codecs driving them - defined by a
programmable cross-bar on the video card.
12. p, E CK is a video present codecs-to-sources topology - i.e. mapping fiom
25 video present codecs to video video present sources fiom which the codecs are
streaming visual content.
13. p, E CT is a video present targets-to-sources topology 2540 - i.e. mapping
from video present sources, £tom which its underlying video output codecs are
streaming visual content, to video present targets, to which that content is being
streamed to..
14. ~ * = ( p , l ( ~ i , = ~ ~ ~ o & ) ~ ~ ~ ~ s ~ ) ~ ~ C s , ) ~ ~ i /mnapm~l =- ~&t~~ )
is a set of supported VidPN topologies - i.e. a mapping fiom a pair consisting
of the set of video present targets and the set of video present sources,
10 (T, , C, ) E &T)x @(C), to the respective set of the supported VidPN
implementations for that pair, where each implementation specifies explicitly the
way in which video present sources are routed through the video output codecs to
the video present targets they are driving.
15 15. Y E {(T,,C,, &,z, ) I (T, c T) A (C, E C) A iIAaEP(fmirr% = h )i)s c alled a VidPN
implementation, where:
a T, E p(T) is the set of VidPN video present targets.
b. C, E @(C) is the set of VidPN video present sources.
C. PT,E~ z T is the VidPN topology.
20
16. p,, E V" and p, E C' are the 1 : 1 correspondences between views and the
underlying video present sources - i.e. p,, and p, are isomorphisms between
Cand V.
17. B, E Q(B)~is a multi-codec video present target mode set vector - i.e.
mapping from video output codecs to the video present target mode sets they
support.
5 18. g, EQ(B)~is a multi-target video present target mode set vector - i.e.
mapping from video present targets to the video present target mode sets they
support.
19. BME Q(B)~is a multi-monitor video monitor source mode set vector - i.e.
mapping from monitors to the video monitor source mode sets they support.
20. FT E is a multi-source video present source mode set vector - i.e.
mapping fiom video present sources to the video present source mode sets they
support.
21. DK E B~ is a multi-codec video present target mode vector - i.e. mapping from
video output codecs to the video present target modes which these codecs are
driving on the video present targets' video outputs to which they are connected.
20 22.8, i (& 0 A) E B~ is a multi-output video present target mode vector - i.e.
mapping from video present targets to the video present target modes being
driven on their video present targets by the video output codecs they are
connected to.
25 ' 2,3.( & = 0 a) E BM is a multi-monitor video present target mode vector - i.e.
mapping from monitors to the video present target mode being driven on them by
- 53 -
the video'present targets they are connected to.
24. a,, E OM"B is a multi-monitor display mode vector - mapping from monitors
,
to the display modes being displayed on them as the result of the underling video
present target mode driven on the monitors' inputs.
25. Tz E r q s a multi-source video present source vector - i.e. mapping from video
present sources to the video present source modes these sources are set to.
10 26. A VidPN implementation is said to be semi-functional iff video present source
modes have been successfully selected on all of its video present sources.
27.A VidPN implementation is said to be functional iff it is semi-functional and
video present target modes have been successfully selected on all of its video
present targets.
Example 3 7 - Exemplary Definitions
Given the complicated set of interdependencies involved, a number of formal
defdtions can be used for some implementations. Certain (view, ourput) pairs may be
20 factored into video present sources, which can represent inputs into video output codecs
(e.g., CRTC DAC, TMDS) and video present targets, which can represent video outputs
on a video card (e.g., HD-15, DM, S-video).
A display mode may be factored into a video present source mode, which can
specify the primary surface format via which a graphics stack is providing rendered
25 content to be presented for a user, and a video present target mode, which can specify a
video signal format driven on a respective video output.
Video presenting capabilities of a multiple-output video card are modeled via the
notion of a Video Present Network (VidPN), which can relate a set of video present
sources to a set of video present targets via a VidPN topology. A VidPN may be
considered semi-jirnctional iff video present source modes are pinned on each of its
5 video present sources. A VidPN may be consideredfinctional iff it is semi-functional,
and video present target modes are pinned on each of its video present targets.
Association between a single video present source and a single video present
target can be called a video presentpath. Association between a single video present
source and multiple video present targets can be called a video present multipath.
10 With the preceding definitions in place, a video miniport's job, in the context of
display mode management can be described as managing an active VidPN that
represents a state of a video present configuration on a respective video card it is
driving, as well as servicing clients' requests aimed at incrementally building hctional
VidPNs, each of which could be set as active.
15
Example 38 - Exemplary Multiple Video Output Display Mode Solution
Changing display modes on monitors attached to a multiple-output video card
may no longer suffer from a "single-output operation" view of the world, where video
miniport developers had to implement complex synchronization among certain video
20 driver stacks that were driving the same underlying physical device, and may be
superseded with an explicit transaction-based commit of a functional VidPN
implementation on a given video card serviced by a single video driver stack.
A multiple output video display mode solution may depend on multiple criteria
such as: (a) hardware limitations (e.g., video mode sets supported by monitors connected
25 to respective video present targets); (b) operational mode considerations (e.g., specific
video modes preferred by monitors connected to respective video present targets); (c)
performance considerations (e.g., rendering performance improvements achieved
through reduction of contention for a video memory bus by video output codecs); (d)
power management considerations (e.g., reduction of a video card's power consumption
achieved by disabling unutilized video output codecs, and throttling down its
capabilities); (e) heat dissipation considerations (e.g., reduction of a video card's
5 operational temperature achieved through continuous interswitching among multiple
units, where one unit is given a chance to cool down while another one is operational,
and vice versa, thus never increasing the number of Jlsec radiated by the video card
beyond a certain desired upper bound); and (f) usability considerations (e.g., a driving
monitor's preferred mode on a user's primary monitor is more important than driving it
10 on a secondary monitor, assuming that all monitors cannot be driven at preferred modes,
where a decision of which monitor is primary is a function of user-specified mode of
operation). For example, given DVI LCD, S-video HDTV, and HD-15 CRTl3D glasses,
a user might prefer to worlt/read/browse on DVI LCD that has the best clarity, watch
movies on S-video HDTV that has the largest active pixel region, and play games on
15 HD-15 CRTl3D glasses that support the highest refresh rates and best gaming
experience.
Example 39 - Exemplary Solution Space
A solution space containing all possible VidPN implementations, with all
20 possible video present target mode sets available on its targets and all the various ways
to distribute available video present source modes across its inputs, availability of each
of which is a function of a video mode to be driven on a respective output (based on
such factors as the presence of hardware scaling in an underlying video codec), may be
intractable for a simple brutal force enumeration. A non-brute force approach for a
25 general case of T video present targets, K codecs, and C. video present sources may be
analogous to a classical tri-partite graph matching problem, which is known to be NPC
(e.g., there is no known algorithm that runs in polynomial time and finds an ideal, or
globally optimal, solution). Determining an approximate solution as close as possible to
an ideal solution is desirable.
Example 40 - Exemplary Complexities
5 Determining which configurations are functional can be a complex task. For
example, for a given configuration, the following may need to be considered:
1. Which video output codec can be used to drive which video output
2. Which video codec can be used to convert which render target's primary
surface into a video signal
10 3. What are the possible video mode set distributions across the video outputs
4. What are the possible video modes that each video codec can drive
5. What are the possible graphics rendering mode distributions across the render
targets.
Some of the issues making the search complex are that codes are a scarce
15 resource, and there are usually less codecs than outputs, so for clone-view it is beneficial
to share a single codec across multiple outputs, whenever possible. Such an approach
has a downside of forcing the same video mode on both monitors which may not work,
if the monitors do not have a common video mode that the both support (e.g., a CRT can
go up to 1280x1 024 and an LCD may support only 1600x1 200). Even if they do share a
20 video mode, such might not be the ideal way to drive the monitors, since the video mode
might not be their preferred mode. For example, a projector supports 640x480,
800x600,1024x768 (native), and 1280x1024. The LCD supports 640x480,800x600,
1024~768,1280~102a4n,d 1400x1050 (native). Sharing a codec between these two
means only one driver can be driven at its preferred video mode.
25 Or, an LCD might support 1024x768,1280x1024,1600x1200 (preferred). And a
projector might support 640x480,800x600 (preferred), and 1024x768. Sharing means
that neither monitor can be driven at its preferred mode.
In addition, not all codecs are created equal. Sometimes a video card has
different codecs, with one being able to do more modes or perform some of them better
than the other. The situation can become even more complicated with certain modes
being available on certain codecs (e.g., one codec can do only 16-bit, and another codec
5 can do only 32-bit modes).
Finally, while cross-bar can be used to reroute codecs to different outputs, its
limitations and incompatibility of the codec with the video output's technology can
result in certain codecs being restricted to certain subsets of outputs (e.g., CRTC can not
drive DVI, and TMDS can not drive HD- 15 of S-video).
10 To avoid a brute force approach of enumerating all possible implementations, a
convergence approach can be used instead.
Example 41 - Exemplary Advaniages to Delegating Determination to 'video Driver
In any of the examples described herein, determining whether a particular
15 provisional configuration is functional for the video adapter can be accomplished by
(e.g., delegated to) the device driver. A possible alternative is to construct a generalcase
generic solution that can handle determination across a set of video adapters (e.g.,
all known video adapters). However, such a solution would require logic for handling a
vast number of scenarios.
20 Instead, by delegating determination to the device driver, the device driver can be
made more lightweight and need not solve the general case. For example, the device
driver need not contain logic for handling scenarios that the corresponding video adapter
cannot implement (e.g., are not present in hardware). In this way, the size of the device
driver can be reduced and its performance (e.g., speed) can be increased (e.g., as
25 compared to a general solution).
Example 42 - Exemplary Comparison between Topology and SourcedTargets
A topology can be treated as a configurable resource, wherein the options (e.g.,
video present paths) can be configured concurrently. Compare to those video preset
sourcesltargets in which only a single option (e.g., sourceltarget mode) can be
5 configured at once. Modes can be mutually exclusive within a given mode set, whereas
present paths need not be necessarily mutually exclusive, but can be.
Example 43 - Exemplary Approaches
Two possible approaches include a query-based approach and a traversal-based
10 approach. A query-based approach may involve querying a display miniport for a
solution that satisfies a set of requirements provided by the 0s. A traversal-based
approach may involve navigating through a solution space by incrementally building up
a functional VidPN implementation with desired video present target and source modes
chosen for its targets and sources, respectively. Determining a near-optimal
15 implementation of a VidPN may be left to a video miniport.
Alternatively, an OS may supply a video miniport with: (1) a video present target
mode set requirement for each VidPN target that has a monitor connected to it (e.g., a
video card must not expose video signal modes not supported by an attached monitor),
conformance to which on the DDI side can be validated by the OS during video present
20 target mode enumeration; and (2) a video present target mode set guideline to support
monitors' preferred monitor source modes based on a supplied prioritization scheme,
where a display miniport may find a VidPN implementation where a preferred monitor
source mode is supported on a more preferable monitor first, with the preferred monitor
source mode support on every monitor connected to the system being the ideal solution.
25 Finding a near-optimal distribution of graphics video present source modes
supported on VidPN sources may be left to a graphics subsystem's client (e.g., Shell),
where a driver merely exposes an ability to traverse respective video present source
mode sets distribution solution space through an API reporting a video card's
capabilities under a specified operational state. Approaches as simple as Greedy or as
complex as graph-based searches may be employed.
5 E x m e 44 - ExempIary Computing Environment
FIG. 26 and the following discussion are intended to provide a brief, general
description of an exemplary computing environment in which the disclosed technology
may be implemented. Although not required, the disclosed technology will be described
in the general context of computer-executable instructions, such as program modules,
10 being executed by a personal computer (PC). Generally, program modules include
routines, programs, objects, components, data structures, etc. that perform particular
tasks or implement particular abstract data types. Moreover, the disclosed technology
may be implemented with other computer system configurations, including hand-held
devices, multiprocessor systems, microprocessor-based or programmable consumer
15 electronics, network PCs, minicomputers, mainframe computers, and the like. The
disclosed technology may also be practiced in distributed computing environments
where tasks are performed by remote processing devices that are linked through a
communications network. In a distributed computing environment, program modules
may be located in both local and remote memory storage devices.
20 With reference to FIG. 26, an exemplary system for implementing the disclosed
technology includes a general purpose computing device in the form of a conventional
PC 2600, including a processing unit 2602, a system memory 2604, and a system bus
2606 that couples various system components including the system memory 2604 to the
processing unit 2602. The system bus 2606 may be any of several types of bus
25 structures including a memory bus or memory controller, a peripheral bus, and a local
bus using any of a variety of bus architectures. The system memory 2604 includes read
only memory (ROW 2608 and random access memory (RAM) 2610. A basic
input/output system (BIOS) 2612, containing the basic routines that help with the
transfer of information between elements within the PC 2600, is stored in ROM 2608.
The PC 2600 further includes a hard disk drive 2614 for reading from and writing
to a hard disk (not shown), a magnetic disk drive 2616 for readiig from or writing to a
5 removable magnetic disk 2617, and an optical disk drive 261 8 for reading from or
writing to a removable optical disk 2619 (such as a CD-ROM or other optical media).
The hard disk drive 26 14, magnetic disk drive 261 6, and optical disk drive 26 18 are
connected to the system bus 2606 by a hard disk drive interface 2620, a magnetic disk
drive interface 2622, and an optical drive interface 2624, respectively. The drives and
10 their associated computer-readable media provide nonvolatile storage of computerreadable
instructions, data structures, program modules, and other data for the PC 2600.
Other types of computer-readable media which can store data that is accessible by a PC,
such as magnetic cassettes, flash memory cards, digital video disks, CDs, DVDs, RAMS,
ROMs, and the like, may also be used in the exemplary operating environment.
15 A number of program modules may be stored on the hard disk, magnetic disk
26 17, optical disk 26 1 9, ROM 2608, or RAM 26 10, including an operating system 2630,
one or more application programs 2632, other program modules 2634, and program data
2636. A user may enter commands and information into the PC 2600 through input
devices such as a keyboard 2640 and pointing device 2642 (such as a mouse). Other
20 input devices (not shown) may include a digital camera, microphone, joystick, game
pad, satellite dish, scanner, or the like. These and other input devices are often connected
to the processing unit 2602 through a serial port interface 2644 that is coupled to the
system bus 2606, but may be connected by other interfaces such as a parallel port, game
port, or universal serial bus (USB). A monitor 2646 or other type of display device is
25 also connected to the system bus 2606 via an interface, such as a video adapter 2648.
Other peripheral output devices, such as speakers and printers (not shown), may be
included.
The PC 2600 may operate in a networked environment using logical connections
to one or more remote computers, such as a remote computer 2650. The remote
computer 2650 may be another PC, a server, a router, a network PC, or a peer device or
other common network node, and typically includes many or all of the elements
5 described above relative to the PC 2600, although only a memory storage device 2652
has been illustrated in FIG. 26. The logical connections depicted in FIG. 26 include a
local area network (LAN) 2654 and a wide area network (WAN) 2656. Such
networking environments are commonplace in offices, enterprise-wide computer
networks, intranets, and the Internet.
10 When used in a LAN networking environment, the PC 2600 is connected to the
LAN 2654 through a network interface 2658. When used in a WAN networking
environment, the PC 2600 typically includes a modem 2660 or other means for
establishing communications over the WAN 2656, such as the Internet. The modem
2660, which may be internal or external, is connected to the system bus 2606 via the
15 serial port interface 2644. In a networked environment, program modules depicted
relative to the personal computer 2600, or portions thereof, may be stored in the remote
memory storage device. The network connections shown are exemplary, and other
means of establishing a communications link between the computers may be used.
20 Example 45 - E-ary Specification
The following is an exemplary specification for implementing a video presenting
network supporting the various technologies described herein. In the example, a video
presenting network is sometimes called a "video present network" or "VidPN." A
particular configuration for the video present network is sometimes called a "VidPN
25 implementation."
The functions described can be combined into a programmatic interface, such as
an API or DDI. Such an interface can be implemented by a device driver for access by a
client such as an operating system.
Table 3 - Function EnumAvailVidPNTargets
( Name ( EnumAvailVidPNTargets
I ( Enumerates available ViPN targets, supported by the video card, given the specified VidPN
Inputs
Purpose
implementation, each of which could be added to its topology using
AddVideoPresentPathToVidPNTopology,w here each target represents a unique video output on
the video card.
NTSTAT US
Note that these aren't just the targets that are part of the
specilied VidPN implementation.
EnumAvailVidPNTargets
(
[in] VIDPN-IMPL hVidPNImp1,
[out] PDWORD pdwNumOfAvailVidPTs ,
[out] WIDEO-PRESENT-TARGET* ppAvailVidPTs
1;
I If hVidPNImpl = NULL, the video present targets that (
Name
---
Name
hVidPNImpl
I I 1 video card can support through at least one ViPN shall be I
Description
---
Description
ViPN implementation in whose context the caller is
interested in finding the available ViPN targets suppmted
by the video card.
I I ( video present target descriptors to be initialized by the 1
pdwNumOfAvailVidPTs
ppAvailVidPTs
display miniport
Name Description I
returned.
Number of available video present targets (VtiPTs).
Placeholder for the addm of the array containing available
STATUS~SUCCESS
~ T A T U ~ - ~ I D E ~ - I ~ I D - V I D P N ~ I M P L
Query has been mmpleted successfully.
Invalid VidPN implementation handle has been provided.
I
STATUS-NO-MEMORY Display miniport failed to allocate enough system memory
Side-effects
A''ocation
ownership
semantics
Remarks
I ( ConstrainModesOnVidPNTargets I
for the requested array of video present targets.
None.
Display miniport is responsible for allocating a buffer of size:
pdwNumOfAvailVidPTs * sizeof (VIDPT)
for the video present targets array in system memory using DlpAllocatePool. Display loader is
responsible for de-allocating this buffer once it's done with it.
Video present targets are ordered by their IDS, smallest first. from 0 to pdw~~mornvai~vid~~s-1.
Note that any number ofthe enumerated video present targets can be mutually exclusive, meaning they
are not necessarily all available for concurrent use through a single WdPN, and wing one of them for the
topology of any given WdPN may make one or more of the other enumerated video present targets
inaccessible.
Table 4 - Function ConstrainModesOnVidPNTargets
Name
Purpose
I on these outputs.
ConstrainModesOnVidPNTegets
Sets the video mode constraints on each of the enumerated video present targets.
NTSTATUS
I PmtotVpe
Entry containing NULL means no constraints are imposed on the
respective video output's modes (i.e. no monitor is present on
that output). OS shall treat NvLmnsWned outputs as disabled,
and display minipoct mini pgonct ishfwocupld consider down the DAC
(
[in] PVIDEO-MODE-SET pmnsMonitor
);
I I I driving that video output to conserve video card's -r I
Name
Name
outputs
Description
--- ---
Description
Array of video mode sets supported by the monitors connected to
the respective VidPT's video present targets, and, hence, allowed
I
Name
Status
Description
STATUS~SUCCESS I Constraint has been set successfully.
I I
Sidesffects 1 None. 1 I
Display miniport must make a private copy of the supplied per-target video mode constraints, since once
ownership
semantics
I 1 3d party hard-coded Tit manipulation (e.g. additionhemoval of video mod? to/timn such lists) shall be I
the request is successfully completed, arguments' memory can be deallocated by the 0s.
This DDI lats OS specify the video mode sets that are allowed on each of the video present targets,
ordered in the same sequence as enumerated by EnumAvailVidPNTargets. OS needs to use this DDI
on monitor HPD events to notify display miniport about Ute change in video mode constraints on the
video card's video present targets.
Remarks Note that if no monitor descriptor is present, OS shall use a hard mded list of video modes expected to
be supported on the video outpot of a given type (e.g. IBM-*. APPLE-+, VESA-*, VDW-*, and EIR-•
modes for DVI, HD-15, BNC, etc.; NTSC-*, PAL_*, and SECK* modes for Svideo, RCA. RF, etc.).
Table 5 - Function EnumAvailVidPNSources
I supported in the OS to satisfy extensibility and flexibility requirements.
plototype
Inputs
Name
( [out] PDWORD pdwNumOfAvailVidPSs,
EnumAvailVicWNSources
Enumerates available WPN sources supported by the video card, given the specified VidPN
implementation, each of which could be added to its topology using
AddVideoPresentPathToVidPNTopol~gyw~h ere each source t3pESents a video output d e c k
input on the video card.
NTSTATUS
the caller is interested in finding the
available VidPN sources supported by the
[out] PVIDEO-PRESENT-SOURCEt ppAvailVidPSs
);
I video card.
Name
Note that these aren't just the sources that
are part of the specilied VidPN
Description
I I implementation.
1 VidPN implementation in whose context
I 1 1 ~fh ~id~~1mpl'NU-L L, them u% ai I I ( number of video present sources (and
hence views) video card can support
I I under at least one VidPN shall be
I I ( can be added to the topology of the 1
Name
pdwNumOfAvailVidPSs
retumed.
Description
Number of available present sources that
I I 1 axltaining available video present source 1
/ Om*
ppAvailVidPSs
Name
STATUS-SUCCESS
I 1 Display miniport failed to allocate enough
spedfied VidPN.
Placeholder for the address of the army
descriptors to be initialized by the display
miniport
Description
Query has been mpleted su~~essf~lly.
status
I ( STATUS-NO-MEMORY 1 system memory for the requested array of I
Fwmattwk Spanish (Spain-Modem ~
sort)
STATUS-VIDEO-INVALID-VIDPN-IMPL.
Allocation
pdwNumOfAvailVidPSs * sizeof(V1DPS)
ownership
Invalid VidPN implementation handle has
been provided.
Sideeffeets
semantics I for the video present targets array in system memory using DlpAllocatePool. Display loader is I
_ .-.
video present sources.
None.
Display miniport is responsiMe for allocating a buffer of size:
responsible for de-allocating this buffer once Ks done with it
Vdeo present sources are identified from 0 to dwNumOfOutputs-1, ordered smallest first Note that
I I thii DDl does not return all the sources, just hxe that can be added to the spedied VidPN. I
Maximum number of supported video present sources is a function of the WdPN's implementation.
Specifically, per each shating of video output codec among two or more video present targets (for cloneview),
an additional video present source can be supported by the video card. If each output in cloneview
association is driven by a separate video codec, then the number of maximum number of video
present sources decreases as the number of available codecs decreases. Therefore, essentially, this
DDI returns the number of video output codecs unused by the implementation of the specified VIPN
and usable in combination with the video output Wets employed by that VidPN.
To find the maximum number of additional video present sources cumntVidPN can be extended to,
pass the VidPN implementation handle retumed by GetActiveVidPNImpl.
Table 6 - Function CreateVidPNImpl
1 Name 1 CreateVidPNImpl
I
purpose Creates a WdPN implementation.
1 NTSTATUS
Status
( ownership
I CreateVidPNImpl
(
[in] PVIDPN-TOPOLOGY pVidPNTopology,
[in] PDWORD pdwPreferredMonitors,
[out 1 PVIDPN-IMPL phVidPNImp1
( preferred to the least preferred. While
1;
( choosing among WdPN implementations
Name
pVidPNTopology
satisfying the specified topology, display
miniport must try to support preferred
Description
Topology ofthe VidPN to be created.
Prioritization of monitors, from the most
I video mode on the most preferred ( I monitor first, the ideal situation being that ] I monitors (e.g.. all) can be driven in their I
preferred modes.
Name
I
Description
phVidPNImp1
Name
STATUS-SUCCESS
. . I 1 Specified VdPN is invalid (e.g. output
Placeholder for the handle to the
implementation of the specified VidPN.
Description
Request has been mpieted
s u ~ f u l l y .
I
STATUS~VIDEO~INVALID~VIDPN~TOPOLOG~ 1 can not point to bu video present -. 1
STATUS~VIDEO~VIDPN~TOPOLOGYYNOT~SUPPORTED
sources simultaneously).
None,
Speciiied VIPN topology is not
supported by the video card.
Display miniport must make a private copy of the supplied monitors' prioritization scheme, since once
the request is sxzessfully mpleted, arguments' memory can be deallocated by the 0s. I
This DDI creates a temporary object maintained by the display miniport that re-ts a ViPN. The
following operations can subsequently be executed on such a VidPN object
, . - -. matted: Spanish (Spain-Modem
sort)
..-. Formatted: Font Not- 1
I. AddVideoPresentPathToVidPNTopology - add a video present (target, source)
association to it.
-67-
2. RemovePresentTargetFromVidPNTopology - remove an video pESent targetfrom it
3. RemovePresentSourceFromVidPNTopology - remove a video present source from it
4. DisposeOfVidPNImpl - dispose of it
5. CommitVidPNImpl - set video card's adive VidPN to it
See destiptions of the respedive DDls for more detail.
'Outputs
Table 7 - Function GetActiveVidPNImpl
Name
Purpose
NTSTATUS
GetActiveVidPNImpl
(
[out] PVIDPN-IMPL phActiveVidPNImp1
);
GetActiveVidPNImp$
Returns a handle to the ViiPN implementation Aich is based on the VidPN currently set on the video
card.
Name
I
_--
Description
Name
Name
It is also useful to determina the addiional maximum number of video present sources (and hence views)
that video card can support given the Wt'fent VidPN (see EnumAvailVidPNSources for more detail).
Description
Description
SidesRects
Remarks
phActiveVidPNImp1 1 Handle to the implementation of the active ViPN.
STATUS-SUCCESS I Query has been completed successfully.
I
None.
This DDI is useful when it is desired to add or remove a WdPN assodation to the existing VidPN, rather
than creating a completely new configuration. This DDI is essentially a combination of
GetActiveVidPNTopologyandCreateVidPNImpl.
Formatted: Font: Bdd 1
Table 8 - Function GetActiveVidPNTopology
Name
Purpose
Prototype
Inputs
ow-
-68-
GetActiveVidPNTopology
Returns topology of the active VidPN.
NTSTATUS
GetActiveVidPNTopology
(
[out] WIDPN-TOPOLOGY* ppActiveVidPNTopology
);
Name
---
Name
Description
---
Description
Status
- -
-~ ... 1 semantics ( I
ppActiveVidPNTopology
Name
STATUS-SUCCESS
STATUS NO MEMORY
memciy for the requested VidPN.
Allocation
ownership
Placeholder for the topology descriptor of the active
VidPN.
Description
Query has been completed successfully.
Display miniport failed to allocate enough system
Sideeffects ( None.
Display miniport is responsible for allocating a big enough buffer for the VidPN in system memory using
DlpAllocatePool. Display loader is responsible for deallocating this buffer once it's done with it.
Table 9 - Function DisposeOfVidPNImpl
Remarks
This DDI is useful to detenine the active VidPN. In particular, it's required to obtain the inSal ViPN
topology video card is booted in, by the BIOS.
Name
purpose
DisposeOfVidPNImpl
Disposes of the specified VidPN implementation.
NTSTATUS
Prototype
DisposeOfVidPNImpl
(
[in] VIDPN-IMPL hVidPNImp1
);
Inputs
outputs
Status
Formatted: Spanish (Spain-Modem
Sort)
Name
hVidPNImp1
Name
---
I
Table 10 - Function CommitVidPNImpl
Description
VidPN implementation to be disposed off.
Description
---
Name
STATUS-SUCCESS
Description
Request has been completed
Sideeffects
Remarks
-
sTATus-vIDEo-INv~ID-VIDPN-IMP4.. - - -.. - - - -. -..
- 69 -
Name
Purpose
On successful completion, the specified WdPN implementation is rendered invalid.
OS should use this DDI when it no longer needs the ViPN implementation it created using
CreateVidPNImplOTGetActiveVidPNImpl.
successfully.
S@fi~eded\LldPr?r?L?l~lemen.tatio~i~- SLne!id..
C o d tVidPNImp1
Sets the active VidPN to the specified ViPN implementation.
-- -,
Inputs
I I 1 completed I
OutPd
[in] VIDPN-IMPL hVidPNImpl
I ;
Name
hVidPNImpl
Name
---
Name
STATUS-SUCCESS
I
I implementation can
be committed.
Descrlptlon
VidPN
implementation to be
set as active.
Description
---
Description
Request has been
su-fully.
I Specitied VidPN .
I
I
~ T A T U ~ ~ V I D E ~ ~ M ~ D E ~ N ~ T ~ P I N N E D ~ O N ~ V I D P N ~ S O ~IC VEid eo present source
On successful completion, the active VidPN on the video card is changed to the
Status
mode has not been
pinned on one or
more video present
sources. Only a
functional VidPN
implementation can
be committed. I specitid VdPN
implementation. Apprcpriate video modes and graphics modes are then set on the video present targets
and video present sources, acmrding to how they were set on the ViPN implementation using I I
sTATus-vIDEo-=~ID-VIDON_IMP4.. -. . . . . . . . . . . - - -. . . . . . . . . -. . . . . . . . . . . . . . .
STATUS-VIDEO-MODE-NOT-PINNED-ON-VIDPN-TAFtGET
- Formatted: Spanish (Spain-Modern
sort)
. .iF!P.k.menta~?!! is.. . .--
invalid.
Video mode has not
been pinned on one
or more video present
targets. Only a
functional ViPN
Remah
--.
~inModeOn~idPNSource(s)andPinVideoModes.
OS uses this DDI to change the current VidPN to a functional ViPN implementation it converged on.
Table 11 - Function AddVideoPresentPathToVidPNTopology
Name
Purpose
AddVideoPresentPathToVidP~opo1ogy
Adds a video present target-bsourca association to the spedfied VidPN implementation.
NTSTATUS
AddVideoPresentPathToVidPNTopology
(
[in] VIDPN-IMPL hVidPNImpl,
[in] PVIDEO-PRESENT-PATH pVidPresentPathToAdd,
[in] PDWORD pdwPreferredMonitors
):
Name
hVidPNImp1
pVidPresentPathToAdd
pdwPreferredMonitors
I I
Description
VdPN implementation to add videooutput-
terender-target association to.
Video present path (i.e. target to source
assodation) to be added.
Prioritization of monitors, from the most
prefened to the least preferred. While
choosing among the various ViPN
implementations satisfying the specified
topology, display miniport must try to
support the prefened video mode on the
most prefemd monitor first, the ideal
situation being that monitors (e.g., all)
can be driven in their prefened modes.
outputs
Name
STATUS-SUCCESS
Description
Request has bean completed
I
I
Name --- 1
I
Description
Status
STATUS~VIDEO~VIDPN~TOPOLCGYYNOTOTSUPPORTED
Side-effecta
Remarks
--- I
Requested WdPN is not supported by
the video card.
I
On successful completion, the specitid VidPN association is added to the specified ViiPN
implementation. Otherwise, no changes are made.
OS uses this DDI to incrementally graw a VidPN topology, one present path at a time.
sTATus~V1DEo-1NvAC1-D - .-. --v . .1 - - D- - -P - -N- - --.1 MP44
sTAT~s-vIDEo-INvALID-VIDPN_TARGETCCCCC CC -.. -.
STATUS-VIDEO-INVALID-VIDPN-SOURCE
successfully.
Specified ViPN implementation is .-- .-- ..- - - - - - -..- - .. -..- -.- -... - -..- - -... -
invalid.
CCSp:fied.d@~_n?_n?@rgf?-! jsSin~!id.dd
Spedfied video present source ifi invalid.
. . - - matted: Spanish (Spain-Modem
sort)
---- Spanish (Spain-Modem
sort)
Table 12 - Function RemovePresentTargetFromVidPNTopology
Name 1 RemovePresentTargetFromVidPNTopology
I I RemovePresentTargetFromVidPNTopology I
Purpose
l I (
[in] VIDPN-IMPL hVidPNImp1,
Removes the specified video present target from the topology of the specified VdPN implementation.
NTSTATUS
Inputs
[in] VIDPT-ID idTargetToRemove
);
Name
hVidPNImpl
I I
Name Description I
Description
ViPN implementation to remove video
present target from.
outputs
I
STATUS-SUCCESS I Request has been completed 1
idTargetToRemove
Name
---
Vnieo present target to remove.
Description
---
I s-
/ moved from the W o g y of the spedfied WdPN implementation. Ornetwise, m dlanges are made. I
If vdeo present source is removed as part of the output removal, the sets of available graphics video 1
STATUS-VIDEO-INVALID-VIDPN-IMP4 .
I XKJ I
I 1 present source modes on the other video present sources in the resulting VidPN may grow to include I
STATU~-~IDE~-INVALID-VIDPN~TARGET
new modes.
Remarks I OS uses this DDI to remove a video present target from a ViPN implementation.
suazssfully.
Specified ViPN lmplementat!ofl is invalid,
Specified video present target is invalid.
Table 13 - Function RemovePresentSourceFromVidPNTopology
. - - [ -atted: Spanish (Spain-MCdem 1
On successful completion, the VidPN assodation corresponding to the specified video present target is
Name
purpose
plototype -
RemovePresentSourceFromVidPNTopo10gy
Removes the spe&ied video present source from the topology of the specified VidPN implementation.
NTSTATUS
RemovePresentSourceFromVidPNTopology
(
[in] VIDPN-IMPL hVidPNImpl,
[in] VIDPS-ID idSourceToRemove
I :
. .-{matted: Spanish (Spain-Modem I
Table 14 - Function EnumCurrentlyAvailVidPNTargetModeSets
Description
ViPN implementation to remove video
present source from.
Vdeo present source to remove.
Description
---
Description
Request has been completed
successfully.
Specified VIPN implementation is invalid,.
Specified video present source is invalid.
Inputs
outputs
status
Name
h v i d ~ ~ ~ m p l
idSourceToRemove
Name
---
Name
STATUS-SUCCESS
STATUS-~IDE~-INVALID-VIDPN~IMP~
~TATU~~~IDE~~INVALID~VIDPN~SOURCE
Sideeffects
Remarks
Name
purpose
plototype
Inputs
Ow*
On successful ampletion, the WdPN associations mrresponding to the spedfied video present source
are removed from the topology of the specified VidPN implementation. Otherwise, no changes are
made.
If successful, the sets of available graphics video present source modes on other video present sources
in the resulting WdPN may grow to indude new modes.
OS should use this DDI to remove a video present source from a topology of the WdPN implementation.
EnumCurrentlyAvailVidPNTargetModeSets
Enumerates sets of available video present target modes on each of the video present targets in the
specified WdPN implementation, supported by the respective monitors connected to these outputs.
NTSTATUS
EnumCurrentlyAvailVidPNTargetModeSets
(
[in] VIDPN-IMPL hVidPNImp1,
[out] PVIDEO-MODE-SET* ppvmsAvailable
1;
Name
hVidPNImp1
Name
ppvmsAvailable
Description
ViPN implementation on whose video
present targets sets of available video
modes must be enumerated.
Description
Phcedholder for the array of video mode
sets suppwted on the video present
targets in the specified VidPN
implementation.
Vieo mode sets are ordered by their
Table 15 - Function PinModeOnVidPNTarget
I Name I PinModeOnVidPNTarget
'
outputs IDS (smallest first).
If no video modes are supported on a
given video output (e.g. output has been
disabled), display miniport should return
NULL for its video mode set
Description
Request has been ~mpl&?d
successfully.
Specified VdPN implementation is inValid,.
Display miniport failed to allocate enough
system memory for the requested ViPN.
Status
[in] VIDPN-IMPL hVidPNImp1,
[in] VIDEO-PRESENT-TARGET pTargetToPinModeOn,
[in] DWORD dwVideoPresentTargetModeToPin,
Name
STATUS-SUCCESS
STATUS-VIDEO-INVALID-VIDPN-IMP4
STATUS-NO-MEMORY
PU-
. . - - Formatted: Spanish (Spain-Modem
sort)
Allocation
ownemhip
semantics
Sideeffects
Remarks
Pins the specified video present target mode on the specified ViPN target, guaranteeing that display
miniport shall not enumerate (and allow to be pinned) video present target modes on other VidPN
targets that would invalidate this mode.
NTSTATUS
D~splaym iniport is responsible for allocating a big enough buffer for the army of sets of available video
modes in the system memory using DlpAllocatePool. Display loader is responsible for deallocating
this buffer once iYs done with it
None.
Note that video card might not support all the video modes supported by the monitor. Hence OS must
enumerate video modes despite the fact that it is aware of what video modes each monitor supports.
OS shall validate that enumerated video mode sets are subsets of the video mode sets supported by the
respective monitors.
Note that setting one of the enumerated video modes on one of the video present targets may invalidate
enumerated video mode on another video output This is the primary reason for enumerating available
(e.g., all) video mode sets on all video present targets in a single call, so that the dient muld choose
from the options potentially available to it
Inputs
Name
whose video present target the
specified video present target
modes is to be pinned.
Description
( pTargetToPinModeOn ( the specified video present 1
I VidPN implementation on
target mode is to be pinned.
Index of the video present
I I target mode from the set of I
available modes on the
specified video present target.
enumerated through
EnumCurrentlyAvailVidPN
TargetModeSets, to pin.
Placeholder for the predicate,
which if true signifies that at
least one video present target
mode on some other video
present target has been
in~lidatedan d the OS needs
to re-query the available video
present target modes using
EnumCurrentlyAvailVidPN
I I I TargetModeSets. I
outputs
Status
STATUS-VIDEO-INVALID-VIDPN-TARGET
STATUS-VIDEO-INVALID-VIDEO-PRESENT-TARGET_MODE
STATUS-VIDEO-INVALID-VIDPN-IMPL
Specified video present target
Name
---
Name
STATUS-SUCCESS
Specified VIPN
implementation is invalid.
is invalid.
Description
---
Description
Request has been completed
successfully.
target mode was not I
enumerated as available.
already been pinned on the
STATUS-VIDEO-PRESENT-TARGET-MODE-ALREADY-PINNED
specified video present target
Caller must first unpin the
video present target mode in
question using
UnpinModeOnVidPNTarget.
Previously enumerated set of
available video present target
STATUS-VIDEO-MODE-NOT-PINNED-ON-VIDPN-SOITRCE
modes on the specified video
present target has changed.
OS must reenumerate the set
by using
EnumCurrentlyAvailVidPN
TargetModeSets.
Vieo mode was not pinned on
one or more of the video
present sources. Semi
functional VidPN I
implementation, prior to activating that implementation using ComitVidPNImpl.
Side-effects
Remarks
Note that video present targets must have a video mode selected on them.
implementation must be
provided.
None.
OS uses this DDI to pin a video present target mode for each of the video present targets in the ViPN
Video present target modes on the video present target other than the pinned mode are subject to
ifl~lidatiown hen a video present target mode on another video present target is set Display miniport
shall guarantee that no video present target mode that would invalidate any of the pinned video present
target modes is enumerated andlor pinnable (from previous enumerations) on any of the video present
targets in the specified VidPN implementation.
Table 16 - Function UnpinModeOnVidPNTarget
' Name UnpinModeOnVidPNTarget
I target modes on other video present ources that would invalidate the previously selected video present
Purpose
target mode on the specified video present target
NTSTATUS
Unpins the currently selected video present target mode on the specified video present target of the
specified VidPN implementation, freeing display miniport up from the obligation to disallow video present
Inputs
present target the
spedfied video present
[in] VIDPN-IMPL hVidPNImp1,
[in] PVIDEO-PRESENT-TARGET pTargetToUnpinModeOn,
[out] PBOOLEAN . pbNewVideoPresentTargetModesAvailable
);
target mode is to be
unpinned.
VidPN target on which
Name
the spedfied video
present target mode is
Description
VidPN implementation
on whose video
to be unpinned.
Placeholder for the
predicate, which if true
signifies that at least
I I I one new video present (
target mode has
become available on
some other video
present target and the
OS needs to re-query
the available video
present target modes
using
EnumCurrentlyAvai
1VidPNTargetModeS
ets.
STATUS-VIDEO-INVALID-VIDPN-IMPL implementation is
invalid.
target is invalid.
ornuts
Status
Name
---
Name
STATUS-SUCCESS
Description
---
Description
Request has been
completed
Table 17 - Function PinModeOnEachVidPNTarget
STATUS-VIDEO-MODE-NOT-PINNED-ON-VIDPN-TARGET Specified video present
target doesn't have a
selected mode.
I P,i nModeOnEachVidPNTarget
Name
Purpose
I pmbnpe 1 ' i n VIDPNIMPL hVidPNImp1,
Sideeffects
Remarks
PinModeOnEachVidPXWarget
Pins a video mode for each video present target in the spedfied VdPN implementation.
NTSTATUS
[in] PDWORD pdwVideoModesToPin
);
Name I Description
1 VidPN implementation on whose video
None.
OS uses this DDI when it is no longer interested in support for the specified video present target mode
on the specified video present target This could, for instance, be the case if a pinned video present
target mode invalidates a desired video present target mode on another video present target.
respective video mode sets enumerated
using
EnumCurrentlyAvailVidPNTargetMode
Sets.
hVidPNImpl
Video modes are ordered by their video
present targets specitied video modes will be
pinned.
Array of video mode indices into the
I I ( output IDS (smallest first). I
OutDuts ---
Name
STATUS~SUCCESS
STATUS-VIDEO-INVALID-VIDPN- IMP^ Fwmatmk Spanish (Spain-Modem
sort)
Name
/ S t a b
Description
---
Description
Request has been completed successfully.
Specified VidPN implementation is inval~d. -.
-
- -
STATUS-VIDEO-INVALID_VIDEO-PRESENTNTTARGETM
ODE
I
One or more of the specified video mode IDS
were invalid.
STATU~-VIDEO-ENUMERATED-VIDPN-TARGET-MODESE
T-CHANGED
Previously enumerated sst of available video
modes on the specitied video output has
changed. OS must reenumerate the set by
I I using
respective outputs, enumerated Using EnumCurrentlyAvailVidPNTargetModeSets.
Sideeffects
Remarks
Note that pinning a video mode on one video output does not invalidate any previously enumerated video
modes on the other video present targets, since available video mode sets depend only on the video
output codec driving it, and hence only on the specified VdPN implementation.
EnumCurrentlyAvailVidPNTargetMode
Sets.
None.
This DDls pins a video mode for each video output in the VidPN from the sets of video modes available on
I I The only way a given video mode may become invalidated is if the video card's operational capabiliies I
have changed due to a change in in its power management state.
Table 18 - Function EnumCurrentlyAvairVidPNSourceModeSets
prototype
Name
Purpose
Inputs
EnumCurrentlyAvailVidPNSourcdbdeSets
Enumerates sets of available video present source modes on each of the video present sources in the
spedfied VidPN implementation.
NTSTATUS
hVidPNImp1
Name
(
[in] VIDPN-IMPL hVidPNImp1,
[out] PVIDEO-PRESENT-SOURCE-MODE-SET* pprmsAvailable
) ;
views sets of available video
present source modes must be
enumerated.
Description
Array of video present source
mode sets available on the video
Name
present sources in the speu'fied
Description
VidPN implementation.
I VidPN implementation on whose
Vdeo present source mode sets
are ordered by their video
present sources' IDS (smallest
first).
Status
Name
STATUS-SUCCESS
Description
Request has been completed
successfully.
I I Display miniport failed to allocate
STATUS-VIDEO-INVALID-VIDPN-IMP<
Speded VidPN implementation
is invalid.
STATUSNO-MEMORY
STATUS~VIDEO~MODE~NOIOTPINNEDDONNVIDPNNTARGET
.
enough System memory for the
requested VidPN.
Video mode has not been
pinned on one or more video
Sideeffects
Allocation
ownership
Note that the spatial resolution of the video mode set does not necessarily correspond to that of the
(graphics) video present source mode, since video card can do hh scaling (in its video output codec).
present targets. SemCfunctional
VIPN implementation must be
provided.
None.
Display miniport is responsible for allocating a big enough buffer for the array of sets of available
graphics modes in the system m r y using DlpAllocatePool. Display loader is responsible for d e
semantics
Remarks
Display miniport must not report (graphics) video present source modes which require GPU based
scaling. This functionality shall be done in the graphics subsystem layer of the 0s.
allocating this buffer once it's done with it
Before calling this DDI, OS must select a video present target mode for each of the VidPN targets.
Display miniport must not report (graphics) video present source modes seleding which would prevent
another video present source from supporting at least one video present source mode.
Table 19 - Function PinModeOnVidPNSource
1 Name 1 PinModeOnVidPNSource I
Purpose I Pins the specified video present source mode on the specified video present source of the speafied
VidPN implementation, guaranteeing that display rniniport shall not enumerate (and allow to be pinned)
video present source modes on other video present swm that would invalidate this mode.
NTSTATUS
I I PinModeOnVidPNSource I
.f Formatted: Spanish (Spain-Modem 1
Prototype
(
[in] VIDPN-IMPL . hVidPNImpl, . . . . .
[in] PVIDEO-PRESENT-SOURCE pSourceToPinModeOn,
[in] DWORD dwVideoPresentSourceModeToPin,
-. -. - Formatted: Spanish (Spain-Modem
Sort) I
Inputs
outputs
Status
[out] PBOOLEAN pbOtherVideoPresentSourceModesInvalidated
1;
Name
hVidPNImp1
pSourceToPinModeOn
dwVideoPresentSourceModeToPin
pbOtherVideoPresentSourceModesInvalidated
Name
---
Name
STATUS-SUCCESS
STATUS~VIDEO~INVALID~VIDPNNIMP~
~TAT~~~~IDEO~INVALID~VIDPN~SOURCE
STATUS~VIDEO~INVALID~VIDEO~PRESENT~SOURCE_MODE
, .
STATUS~VIDEO~MODE~ALREADYYPINNED~ONNVIDPNSOCE
- 81 -
Description
ViPN implementation on
whose video present target the
specified video present source
modes is to be pinned.
Vteo present source on which
the specified video present
source mode is to be pinned.
Index of the video present
source mode from the set of
available modes on the
spechied VidPN source,
enumerated through
EnumCurrentlyAvailVidPN
SourceModeSets, to pin.
Placeholder for the predicate,
which if true signifies that at
least one video present source
mode on some other ViPN
source has been invalidated
and the OS needs to mquery
the available video present
source modes using
EnumCurrentlyAvailVidPN
SourceModeSets.
Description
---
Description
Request has been completed
successfully.
Specified ViPN
implementation is invalid.
Specified ViPN source is
invalid.
The specified video present
source mode was not
enumerated as available.
Video present source mode
has already been pinned on
I the specified VidPN source. I
STATUS-VIDEO-ENUMERATED-VIDPN-TARGET-MODESET-CHANGE
I I Note that video present targets must have a video mode selected on them. I
Caller must first unpin the
video present source mode in
question using
UnpinModeOnVidPNSource.
Previously enumerated set of
available video present source
modes on the specified VidPN
Side-effects
Remarics
Video present source modes on the video present source other than the pinned mode are subject to
invalidation when a video present source mode on another video present source is set Display miniport
shall guarantee that no video present source mode that would invalidate any of the pinned video present
source modes is enumerated andlor pinnable (from previous enumerations) on any of the video present
sourcas in the spedfied VidPN implementation.
Table 20 - Function UnpinModeOnVidPNSource
D source has changed. OS must
reenumerate the set by using
EnumCurrentlyAvailVidPN
SourceModeSets.
None.
OS uses this DDI to pin a video present source mode for each of the video present sources in the VidPN
implementation, prior to activating that implementation using CommitVidPNImpl.
Name
Purpose
Prototype
Inputs
UnpinModeOnVidPNSource
Unpins the currently selected video present source mode on the specified video present source of the
specified VidPN implementation, freeing display miniport up from the obligation to disallow video present
source modes on other video present ources that would invalidate the previously selected video present
source mode on the specified video present source.
NTSTATUS -
UnpinModeOnVidPNSource
(
[in] VIDPN-IMPL hVidPNImpl,
[in] PVIDEO-PRESENT-SOURCE pSourceToUnpinModeOn,
[out I PBOOLEAN pbNewVideoPresentSourceModesAvailable
:
Name Description
VidPN implementation
hVi -1
I
outputs
Status
Side-effects
Remarks
on whose video
present targets the
specified video present
source modes is to be
unpinned.
Vieo present source
on which the specified
pSourceToUnpinModeOn video present source
mode is to be
unpinned.
Placeholder for the
prediite, which ltrue
signifies that at least
one new video present
source mode has
become available on
some other video
pbNewVideoPresentSourceModesAvailable present source and the
OS needs to requery
the available video
present source modes
using
EnumCurrentlyAvai
1VidPNSourceModeS
ets.
Name Description
--- ---
Name Description
STATUS~SUCCESS Request has been
completed
successfully.
Specified VIPN
sTATus-v1DE0-1NvAL1D-v1DPN-1MP444.44!4~44P44~44E44~4.. -4 -~ 4Fo4~rm4a4~ttE4d?4: S4p~a4nis4h~ (4Sp4asin4-M4~od4e~m4 4~44~44~invalid. alt)
STATUS-VIDEO-INVALID-VIDPN-SOURCE Specified video present
source is invalid.
STATUS~VIDEO~MODE~NOT~PINNEDNNONNVIDPN~somc~ Specified video present
source doesn't have a
selected mode.
None. . . . .
OS uses this DDI when it is no longer interested in support for the specified video present source mode
Formatted: Spanish (Spain-Modem
sort) I
Table
Name
Purpose
P~tOtupe
Inputs
outputs
Status
21 - Function PinModeOnEachVidPNSource
PinModeOnEachVidPNSource
Pins a video present source mode for each of the video present sources in the VidPN implementation, in
a single call.
NTSTATUS
PinModeOnEachVidPNSource
(
[in1 VIDPN-IMPL hVidPNImp1,
[in] PDWORD pdwRenderingModeIDsToPin
):
Name
hVidPNImp1
pdwRenderingModeIDsToPin
Name
---
Name
STATUS-SUCCESS
sTATus-vIDEo-I~~~~~D_VIDPN-IMP444444444444444444444444444444444.
Description
VidPN implementation on
whose video present source
specified video present
source modes will be
pinned.
Array of video present
source mode IDS of video
present source modes to be
pinned, where each mode is
from the mode set of the
respective video present
sources'. , enumerated via
EnumCurrentlyAvailVi
dPNSourceModeSets.
Video present source
modes are ordered by their
video present sources' IDS
(smallest first).
Description
---
Description
Request has been
completed successfully.
Specified VdPN
.. . .. .. ... ~mpler.n.e. ntB-b.o-nIS- -in.v.a.li-d.:- ---
STATUS~VIDEO~INVALID~VIDEO~PRESENT~SOURCE~MODE~1 IODn e or more of the
STATUS-VIDEO-MODE-NOT-PINNED-ON-VIDPN-TARGET
specified video present
source mode IDS were
invalid.
of available video present
source modes on the
specified video present
source has changed. OS
I must reenumerate the set (
by using
EnumCurrentlyAvailVi
dPNSourceModeSets.
video present source
modes on one of the video
present sources invalidates
another specified video
present source mode on
another video present
source in the specified
on one or more of the video
present targets. SemC
functional ViPN
video present source modes available on the respective video present sources, enumerated using
EnumCurrentlyAvailVidPNSourceModeSets.
Side-effects
Remarks
I ( This DDI should be used when the specified rendering multi-mode for a given VidPN is known to work, I
implementation must be
provided.
None.
This DDls pins a video present source mode for each video present source in the VidPN from the set of
such as the case when OS logs a known user in, or, on a previously encountered monitor HPD-eventinduced
ViPN, where a previously used configuration has been persisted and can still be reused.
1 I Note that if any of the video present sources had a video present source mode pinned on them using I
PinRenderMode, that mode shall be ignored and assuming the specified video present source modes
can be set, the cail shall suc%d. his is different from the calling ema anti^^ of~in~endei~wohdiceh
will fail if a vid& present source mode is already selected on the specified video present source.
Table 22 - Function EnumCurrentlyAvailFilteringTechniqueSets
1 Name I EnumCurrentlyAvailFilteringTechniqueSets
I
Purpose I Enumerates sets of available filtering techniques on each of the video present sources in the specitid
functional VidPN implementation.
1 NTSTATUS
Prototype
(
[in] VIDPN-IMPL
views the sets of available
filtering techniques must be
[out] PFILTERING-TECHNIQUES-SET* ppftsAvailable
);
Name
Name
STATUS-SUCCESS
Description
Name
implementation. I
I VidPN implementation on whose
enumerated.
Description
Array of filtering techniques sets
available on the video present
sources in tha specified VidPN
Video present swrce mode sets
are ordered by their video
present sources' IDS (smallest
first).
Description
Request has been completed i
I I Display miniport failed to allocate
I
I STATU~-NO~MEM~RY 1 enough Wstem memv for the I
STATUS-VIDEO-INVALID-VIDPN-IMPL
requested VidPN.
STATUS-VIDEO-MODE-NOT-PINNED-ON-VIDPN-TARGET 1 Video mode W ~nSot pinned on
Specified WdPN implementation
is invalid.
one or more video present
target A functional VidPN
I I implementation must be I
STATUS~VIDEO~MODE~NOTOTPINNEDNNON~VIDPN~SOURCE
provided. . ''
Video present source mode was
Table 23 - Function PinFiteringTechniqueOnVidPNSource
Side-effects
Allocation
ownership
semantics
Remarks
I Name
Purpose
not pinned on one or more video
present source. A functional
VidPN implementation must be
provided.
None.
Display miniport is responsible for allocating a big enough buffer for the array of sets of available
graphics modes in the system memory using DlpAllocatePool. Display loader is responsible for deallocating
this buffer once it's done with it
Before calling this DDI, OS must pin a video mode for each of the video present targets and pin a video
present source mode for each of the video present sources in the specified VidPN implementation (i.e. t
needs to construct a functional VidPN).
PinFilteringTeJlniqueOnVidPNSource
Pins the specified filtering technique on the specified video present source of the specified VidPN
implementation, guaranteeing that display miniport shall not enumerate (and allow to be set) filtering
techniques on other video present sources that would invalidate this filtering technique.
NTSTATUS
PinFilteringTechnique
(
[in] VIDPN-IMPL hVidPNImp1,
[in] VIDPS-ID idSourceToPinModeOn,
[in] DWORD dwFilteringTechniqueToSelect,
[out] PBOOLEAN pbOtherFilteringTechniquesInvalidated
) :
Name Description
I VIPN implementation on
whose video present targets
the specified video present
source modes is to be pinned.
Vieo present source on
idRenderTargetToSelectModeOn which the spedfied filtering
technique is to be pinned.
Index of the filtering technique
from the set of available
filtering techniques on the
spedfied video present I
I I source, enumerated through (
3utp-
Status
Name
---
Name
STATUS-SUCCESS
STATUS-VIDEO-INVALID-VIDPN-IMPL
STATUS-VIDEO-INVALID-FLTRTECHNIQUE
pin.
Placeholder for the predicate,
which if true signifies that at
least one filtering technique
on same other video present
source has been invalidated
and the OS needs to requery
the available filtering
techniques using
eringTechniqueSets.
Description
---
Description
Request has been mmpleted
successfully.
Specified VidPN
implementation is invalid.
Speciiied video present
source is invalid.
The specified filtering
technique has not been
enumerated as available.
Filtering technique has
already been pinned on the
specified video present
source. Caller must first unpin
the filtering technique in
question using
7npinFilteringTechniqu
'reviwsly enumerated set of
lvailable filtering techniques
,n the specified video present
source has changed. OS must
vxnumerate the set by using
SnumCurrentlyAvailFilt
?ringTe. chni. queSets.
/idea mode has not been
)inned on one or more video
Table 24 - Function UnpinFilteringTechniqueOnVidPNSource
STATUS-VIDEO-MODE-NEPINNED-ON-VIDPN-SOURCE
present targets. A functional
VdPN implementation must
be provided.
Vieo present source mode
was not selected on one or
mom video present sources.
A functional VdPN
implementation must be
provided.
Name
Purpase
I
VidPN implementation
hVi -1
Sldeeffects
Remarks
UnpinFilteringTechniqueOnVidPNSource
Unpins the currently pinned filtering technique on the specified video present source of the specified
VidPN implementation, freeing display miniport up from the obligation to disallow filtering techniques on
other video present source that would invalidate the previously selected filtering technique on the
specified video present source.
NTSTATUS
Prototype
Inputs
None.
OS uses this DDI to select a filtering technique for each of the video present sources in the VidPN
implementation, prior to setting that implementation as the current configuration, using
ComitVidPNImpl.
Note that this step is optional, and if not explicitly spedfied, driver should use the default filtering
technique - i.e. no filtering.
Note that video present targets must have a video mode pinned on them and video present sources
must have a video present source mode pinned on them - i.e. the VidPN must be functional.
Filtering techniques on the video present source other than the pinned technique are subject to
invalidation when a filtering technique on another video present source is set Display miniport shal
guarantee that no filtering technique that would invalidate any of the pinned techniques is enumerated
andlor pinnable (from previous enumerations) on any of the video present sources in the specified
VidPN implementation.
[in] VIDPN-IMPL hVidPNImpl,
[in] VIDPS-ID idSorceToUnpinTechniqueOn,
[out] PBOOLEAN pbNewFilteringTechniquesAvailable
);
Name Description
1 on whose video I present targets the /
I I I spedfied video present I
I 1 source modes is to be 1
pinned.
1 Vieo present source
on wh'kh the specified
video present source
mode is to be pinned.
Placeholder for the
predicate, which if true
signifies that at least
I I 1 one new filtering I
I I I technique has become I
1 1 1 available on some 1
other video present
source and the OS 1
1 1 1 available filtering I
techniques using
EnumCurrentlyAvai
1 F i l t e r i n g T e c h n i q
ueSets.
Name
---
1 I 1 completed 1
Description
---
Name
STATUS-SUCCESS
successfully.
Specified ViPN
Description
Request has been
swrce is invalid.
~ T A T ~ ~ ~ ~ I D E ~ ~ F L T R T E C H N I Q U E ~ N O T ~ P I N N E D ~ ~ NI ~S~pIeDciPfdN v~ide~o~ p~reRse~nEt
Status
I I I source doesn't have a 1 I pinned fihering
STATUS-VIDEO-INVALID-VIDPN-IMPL
STATUS-VIDEO-INVALID-VIDPN-SOURCE
implementation is
invalid.
Specified video present
1 ( specified video present source. This muld, for instance. be the case if a selected filtering technique 1
Sideeffects
Remarks
technique.
None.
OS uses this DDI when it is no longer interested in support for the specified filtering technique on the
in~lidateas desired filtering technique on another video present source.
When no filtering technique is selected on the video present source the default filtering technique is 'no
filtering', represented through a zero filtering technique ID.
Table
Name
Purpose
Prototype
Inputs
outputs
Status
25 - Function PinFilteringTechniqueOnEachVidPNSource
PinFilterin~echniqueOnEachVidpNSo~~ce
Pins a filtering technique for each of the video present sources in the V'iPN implementation, in a single
call.
NTSTATUS
PinFilteringTechniques
(
[in] VIDPN-IMPL hVidPNImp1,
[in] PDWORD pdwFilteringTechniqueIDsToPin
);
Name
hVidPNImp1
pdwFilteringTechniqueIDsToPin
Name
---
Name
STATUS-SUCCESS
STATUS-VIDEO-INVALID-VIDPN-IMPL
STATUS-VIDEO-INVALID-E'LTRTECHNIQUE-ID
STAT~~~~IDEO~FLTP.M~DE~~AR.~MUTUALLY~EXCLUSIVE
Description
VidPN implementation on
whose video present source
specified filtering
techniques will be pinned.
Array of filtering technique
IDS from the filtering
technique sets of respective
video present sources.
Filtering techniques are
ordered by their video
present sources' IDS
(smallest first).
Description
---
Description
Request has been
completed successfully.
Specified VidPN
implementation is invalid.
One or more of the
specified filtering technique
IDS were invalid.
At least one of the specified
I I filtering techniques on one I
I I 1 of the video present I
I I I sou- invalidates another I
rSTATUS-VIDEO-MODE-NOT-PINNED-ON-VIDPN-SOURCE
spechled filtering technique
on another video present
source in the specified
VidPN.
Video mode was not pinned
on one or more video
present targets. A functional
ViPN implementation must
be provided.
was not pinned on one or
more video present
sources. A functional VidPN
filtering techniques available on the respective video present sounes, enumerated using
EnumCurrentlyAvailFilteringTechniqueSets. Zem filtering technique ID represents no filtering.
Sideeffects
Remadm
This DDI should be used when the specilied distribution of filtering techniques aaoss the video present
swrces for a given ViPN is known to work, such as the case when OS logs a k m user in, or, on a
previously encountered monitor HPD event induced ViPN, where a previously used configuration can
be reused.
implementation must be
provided.
None.
This DDls selects a filtering technique for each video present source in the VidPN from the sets of
Table 26 - Function FilterincTechniques-Set
Name
Purpose
DefiniUon
Fields
FILTERINGNGTECHNIQUES_sET
Filtering techniques set
typedef struct -FILTERING-TECHNIQUES-SET
(
DWORD dwNumOfFilteringTechniques;
PFILTERING-TECHNIQUE pFilteringTechniques;
1
FILTERING-TECHNIQUES-SET, *PFILTERING-TECHNIQUES-SET;
Name
dwNumOfFilteringTechniques
pFilteringTechniques
Description
Number of filtering techniques in the set
Array of &s elements (number of entries is determined by
Table 27 - Function FilteringTechnique
Remarks
dwNumOfFilteringTechniques).
Filtering techniques sets are used to descni sets of available filtering techniques on the video present
sources in a given ViPN implementation.
Table 28 - Function Video-Present-Target
Name
Purpose
bfinition
Remarks
FILTERING-TECHNIQUE
Filtering technique descriptw.
typedef enum -FILTERING-TECHNIQUE
(
TBD
1
VIDEO-MODE, *PVIDEO-MODE;
Filtering technique spedfies what filtering algorithm GPU andlor video output codec uses to process the
video present source's primary surface while converting the rendered frame into a video mode field.
5
Name
Purpose
Definition
Fields
Remarks
VIDEO-PRXSENT-TARGET
Vieo present target descriptor.
typedef struct -VIDPT
(
VIDEO-OUTPUT-TECHNOLOGY VideoOutputTechnology;
VIDEO-OUTPUT-HPD-AWARENESS VideoOutputHPDAwareness;
DWORD dwCharacteristics;
1
VIDEO-PRESENT-TARGET, *PVIDEO-PRESENT-TARGET;
Name
VideoOutputTechnology
VideoOutputHPDAwareness
dwCharacteristics
Description
Type of the video output technology (see
VIDEO-OUTPW-TECHNOLCGY for m0re details).
Type of the video output's HPD awareness (see
VIDE~~~UTP~~HPD~AWARfoEr mNE~SrSdee t ails).
Bit array describing prediitive characteristics of the video
output, with the following Rags defined:
TED
OS obtains descriptors for each video ou@ut in the VdPN by enumerating them with
EnumAvailVidPNTargets.
Table 29 - Function Video-Output-Technology
Table 30 - Function Video-Output-HPD-Awareness
Name
Purpose
Definition
Remarks
cDefinition
VIDEO~OUTPUT~TE~OLCGY
Vieo output technology descriptor.
typedef enum -VIDEO-OUTPUT-TECHNOLOGY
(
VOT-Uninitialized = 0,
VOT-HD15 = 1,
V C D V I = 2,
VOT-HDMI = 3,
VOT-HDMI2 = 4,
VOT-SVideo-4pin = 5,
VOT-SVideo-7pin = 6,
VOT-RCA-composite = 7,
VOTPCA_3component = 8,
VOT-BNC = 9,
VOT-RF = 10,
VO-ther - 255
}
VIDEO-OUTPUT-TECHNOLOGY, *PVIDEO-OUTPUT-TECHNOLOGY:
Vie0 output ted\nolog/ is used b determine the hard-coded list of video modes supported by the
monitor, when monitor descriptor is not available. Filtering technique is a video cutput ccdec input
characteristic. WV->RGB transformation is a video output codec ouQwrt characteristic. Defaults
recommendation to IHVs: SD -> 601, HD a 709. This cwkl be wrong so you want to be able to override
it
Vieo output HPD awareness desaiptor.
typedef enum -VIDEO-OUTPUT-HPD-AWARENESS
VOHPD-Uninitialized 0,
VOHPD-None = 1
VOHPD-DestructivelyPolled = 2,
VOHPD-NonDestructivelyPolled = 3,
VOHPD-Interruptible 4
1
VIDEO-OUTPUT-HPD-AWARENESS, *PVIDEO-OUTPUT-HPD-AWARENESS;
Video output HPD awareness is used to represent the level of monitor connectivity
I I sensed by a video card on its video output. Video output has: I
4. lntenuptible HPD-awareness iff display miniport can asynchronously notify the OS about I
- 94 -
monitor arrivalsldepartures.
5. Non-Destructively Polled HPDawareness iff display miniport can report monitor
arrivalsldepartures to the OS only by periodically polling the underlying h/w, without causing
visual artifads.
8. Destrudhrely Polled HPDawareness iff display miniport can report monitor
arrivalsldepartures to the OS only by sporadically polling the underlying h/w, causing visual
artifads on each poll.
7. No HPDawareness iff display miniport is not aware of monitor arrivalsldepartures and, hence,
can not asynchronously notify or synchronously report occurrences of such events to the OS
Table 31 - Function Video-Present-Source
Table 32 - Function Video-Present-Source-Content-Layout
Name
Purpose
Definition
Fields
Remaks
VIDEO_PRESENT-SOURCE
wdeo present source desaiptor.
typedef struct -VIDEO-PRESENT-SOURCE
{
VIDEO-PRESENT-SOURCE-CONTENT-LAYOUT ContentLayout;
DWORD dwCharacteristics;
1
VIDEO-PRESENT-SOURCE, *PVIDEO-PRESENT-SOURCE;
Name
Purpose
Definition
Remarks
Name
dwCharacteristics
ContentLayout
V I D E O - p R E S E N T - ~ - ~ N T - L A Y O U T
Vdeo present source content's layout format
typedef enum -VIDEO-PRESENT-SOURCE-CONTENT-LAYOUT
{
VPSCL-Linear = 1,
VPSCL-Other = 2
1
VIDEO-PRESENT-SOURCE-CONTENT-LAYOUT, *PVIDEO-PRESENT-SOURCE-CONTENT-LAYOUT;
Video present souna's layout format is used to determine how the content of the image is arrangd in the
respedive primary surface.
Description
Bit array desaibing predicative characteristics of the video
present source, with the following Rags defined:
TBD
Type of the laycut format in which video present source's content
~SS~~~~~(S~~VIDEO-PRESENT-SOURCE-CONTENT~LAYOUT~O~
more details).
OS obtains desaiptors for each video present source in the VidPN by enumerating them with
EnumAvailVidPNTargets.
Table 33 - Function Video-Present-Path
Name
Purpose
Definition
Remarks
Table 34 - Function VidPN-Topology
VIDEO-PRESENT-PATH
Video present target to source mapping.
typedef struct -VIDEO-PRESENT-PATH
r
PVIDEO-PRESENT-TARGET pVidPT;
PVIDEO-PRESENT-SOURCE pVidPS;
1
VIDEO-PRESENT-PATH, *PVIDEO-PRESENT-PATH;
This type is used to describe a mapping from a single video present target b a single video present
source in a VidPN.
Name
Purpose
Definition
I I (elements of the video present paths in the 1
VIDPN-TOPOLOGY
ViPN topology descriptor.
typedef struct -VIDPN-TOPOLOGY
I
DWORD dwNumOfVidPresentPaths;
VIDEO-PRESENT-PATH arrgVidPresentPaths [I];
1
Fields
VIDPN-TOPOLOGY, *PVIDPN-TOPOLOGY;
Remarks
Name
dwNumOfVidPresentPaths
arr- pVidPresentPaths
ldPN topology.
This type is used to describe VidPNs in CreateVidPNImpl and GetCurrentVidPNTopology.
Table 35 - Function VidPN-Imp1
Description
Number of video modes in the set
AmyofdwNum~NidPresent~aths
Name
Purpose
Definition
Remarks
Table 36 - Function video-~re&nt-~ar~et_~ode-~et
VIDPN-IMPL
VidPN implementation handle.
typedef ULONG-PTR VIDPN-IMPL, *PVIDPN-IMPL;
This type is used to descn'be handles to ViPN implementations returned by the display miniport for a
particular ViPN.
Name VIDEO-PRESENT-TARGET-MDDE-~ET
-96-
Purpose
Definition
Fields
Rernarlu
Table 37 - Function Video-Present-Ta%et_Mode
Vdeo mode set descriptor.
typedef struct -VIDEO-PRESENT-TARGET-MODE-SET
(
DWORD dwNumOfModes ;
VIDEO-PRESENT-TARGET-MODE arr-vidptModes[ll;
I
VIDEO-PRESENT-TARGET-MODE-SET, *PVIDEO-PRESENT-TARGET-MODE-SET;
Name
Purpose
Definition
Fields
Name
dwNumOfModes
arr-vidptModes
VIDEO-=SENT-TARGET-~DE
Vteo mode descriptor.
typedef struct -VIDEO-PRESENT-TARGET-MODE
t
VIDEO-SIGNAL_STANDARD vidstandard;
SIZE sizelotal;
SIZE sizeActive;
SIZE sizeActive0ffset;
SIZE sizeTLDeltaVisibleFromActive:
SIZE sizeBRDeltaVisibleFromActive;
FRACTIONAL-FREQUENCY frqVSync;
FRACTIONAL-FREQUENCY frqHSync;
DWORD dwPixelRate;
VIDEO-SIGNAL-SCANLINE-ORDERING ScanLineOrdering;
BOOLEAN bIsGTF;
BOOLEAN bIsPreferred;
BOOLEAN bIsKnownToBeSupportedByMonitor;
vidstandard
Description
Number of video modes in the set
ARay of dwNum0fModes elements of the video
mode set
1
VIDEO-PRESENT-TARGET_MoDE, *PVIDEO-PRESENT-TARGET-MODE;
Vieo mode standard this mode is defined by (if
any).
sizeTotal
sizeActive
Vdeo mode sets are used to describe sets of a~ilablevid eo modes on the video present targets in a
given VclPN implementation.
Name
Total region size (in pixels)
Active region size (in pixels), also known as
production aperture.
Description
sizeTLDeltaVisibleFromActive er from video signal's active pixels topleft
r from video signal's active pixels bottomright
sizeBRDeltaVisibleFromActive
bIsPreferred the monitor conneckl to the respectbe video
be supported by the connected monitor. By setting
field to TRUE, video miniport will make sure this
bIsKnownToBeSupportedByMonitor
cular mode survives OS monitor-capabilii
pruning, even if the monitor doesn't li
driven by an internal video output codec.
Note that this descriptor supersedes subset of the VIDEO-MODE-INFORMATION structure related to video
mode. In XDDM, both video and video present source modes were desaibed in this strud LDDM
separates these two notions, and hence their descriptors.
The video standard field, vidstandard, should be used for video mode comparisons, when I s set to a
wel!-defined video standard. Note that most of the standard modes do not comply with the VESA GTF
frequency constraints.
The monitor-capability based pruning-override field, bIsKnownToBeSupportedByMonitor, lets video
lHVs specify additional video modes whii they know are supported by the monitor their video card is
attached to, but which are not spechied in the monitoh descriptor. This is most useful for monitMs w h i i
have no descriptors and information about their capabilities is instead stored in a proprietary format in the
BlOS by the OEM who produces the final integrated solution. This override should be used sparingly and
only resewed for cases where there is no other way to expose a mode which is known to wok for a given
monitorl V W miniport should never enumerate a mode which is listed as supported by the mmitor
descriptor with this field set t0 TRUE.
Table 38 - Function Video-Signal-Standard
I Name VIDEO-SIGNAL-STANDARD
t Purpose ( Vieo mode standafd desuiptor, listing standards that are expliatty supported by Windows.
Definition
typedef enum -VIDEO-SIGNAL-STANDARE
(
NTSC-M, NTSC-J, NTSC-443,
PAL-B, PAL_Bl, PKG, PAL-H, PAL-I, PAL_D, PAL-N, PAL-NC,
SECKB, SEW-D, SECAM-G, SECKH, S E K K , SECAM K1, SECAM L, - -L , SECAM- L 1,
EIA-861-1, EIA-861-2, EIA-861-3, EIA-861-4, EIA-861-5,
EIA-861-6, EIA-861-7, EIA-861-8, EIA-861-9, EIA-861-10,
EIA-861A-1, EIA-861A-2, EIA-861A-3, EIA-861A-4,
EIA-8618-1, EIA-8619-2, EIA-861B-3, EIA-0619-4, En-861B-5,
EIA-861B-6, EIA-8619-7,
IBM-1, IBM-2, IBM-3, IBM-4, - i
APPLE-1, APPLE-2, APPLE-3,
VESA-1, VESA-2, VESA-3, VESA-4, VESA-5, VESA-6, VESA-7, VESA-8, VESA-9,
VESA - 10, VDMT-1, VDMT-2, VDMT-3, VDMT-4, VW-5, VDMT-6, VDw-7, VDm-8,
VDw-9, VM-10. VDMT-11, VM-12, VDMT-13, MMl-14, VtX-fl'-15, V-16,
VDMT-17, VDMT-18, VW-19, VDMT-2 0, VW-2 1, VDMT-2 2, MMT-23, VDMT-24,
VDMT-25, VDMT-26, vm-27, VDMT-28, VDMT-29, VDW-30, VDMT-31, VDW-32,
VDW-33, VDMT-34,
GTF,
Other I )
VIDEO-SIGNAL-STANDARD, 'PVIDEO-SIGNAL-STANDARD;
This enum shoukl be used to simplify video mode comparisons, when appropriate (i.e. not Other). The
following table lists some of the basic parameters of these modes.
Remarks 1 NTSC-U
NTSC-J
msc-443
PALB
PAL-61
PAL-G
PAL-H
PAL-I
Interlaced
Interlaced
Interlaced
Interlaced
Intsrlaced
Interlaced
Interlaced
Interlac&
PAL-D 720 525 59.94 15.734 3,575,611.49 Interlaced
PAL-N 720 625 50 15.625 4.433.618.75 Interlaced
PAL-NC 720 625 50 15.625 3.582.05625 Interlaced
S E W 720 625 50 15.825 Interlaced
SEW-D 720 625 50 15.625 Interlacsd
SECAB-G 720 625 50 15.625 Interlaced
SEW-H 7X) 625 50 15.625 Interlaced
SEW-K 720 625 50 15.625 Interlaced
SECAB-Kl 720 625 50 15.625 Interlaced
S E W L 720 625 50 15.625 Interlaced
SEW-Ll 7k 625 50 15.625 Interlaced.
EIA-861-1 720 480 59.94 Interlaced
ETA-861-2 720 480 60 Interlaced
ETA-861-3 640 480 59.94 Progressive
~1~-861-4 6 4 0 4 8 0 8 0 Progressive
EIA-861-5 720 480 59.94 Progressive
Em-861-6 7 2 0 4 8 0 8 0 Prograssiva
ETA-861-7 1280 720 59.94 Progressive
EIA-861-8 1280 720 60 Progressive
EIA-861-9 1920 1080 59.94 Interlaced
ETA-861-10 1920 1080 60 Interlaced
ETA-86lA-1 720 576 50 Interlaced
Em-86lA-2 720 576 50 Progressive
EIA-86lA-3 1280 720 50 Progressive
Em-86lA-4 1920 1080 50 Interlaced
ETA-861B-1 l9ZD 1080 23.96 Progressive
ETA-861B-2 1920 1080 24 Progressive
EIA-861B-3 1920 1080 25 Progressive
ETA-8618-4 1920 1080 29.97 Progressive
EX86lB-5 1920 1080 30 Progressive
EIA-8618-6 1920 1080 50 Progressive
EIA-8618-7 1920 1080 60 Progressive
IBW-1 720 4W ,70 Progressive
rm-2 720 4W 88 Progressive
1- 640 480 80 Progressive
IBW-4 1024 768 67 Interlaced
APPLE-1 640 480 67 Progressive
APPLE-2 832 624 75 Progressive
APPLE-3 1152 870 75 Progressive
VESA-1 640 480 72 Progressive
VESA-2 640 480 75 Progrersive
VESA-3 800 800 56 Progressive
VESA-4 8 0 0 8 0 0 6 0 Progressive
VESA-5 8W 6W 72 Progressive
VESA-6 800 800 75 Progressive
VEsA-7 1024 788 80 Progressive
VZSA-8 1024 768 70 Progressive
VZSA-9 1024 788 75 Progressive
VESA-10 1280 1024 75 Progressive
--1 640 350 85 37.900 31.5&3.020 progressive
VDHTVDHT2 640 4W 85 37.900 31.5W.WO Progressive
--3 720 - 4W 85 37.900 J5.5W.WO Progressive
vOnrvOnr4 640 480 60 31.m 25.175.WO Progressive
--5 6 4 480 72 37,900 31.500.WO Progressive
- 100 -
--= 640 480 75 37,500 31,500,000 Progressive
VDHTVDHT7 840 480 85 43.300 38,WO,WO Progresaivs
"="Ln 800 600 56 35.100 38,000,000 Progressive
--9 800 600 60 37.900 40,000,000 Progressive
m - l o 800 BM) 72 48.100 50.WO.000 Progressive
m-11 800 600 75 46.8M1 4Q,500,WO Progressive
m - 1 2 800 600 85 53.700 56,250,000 Progressive
VDXT-13 1024 788 43 35,500 44,900,WO Interlaced
VTMl-14 1024 788 60 48.400 85.000,MM Progressive
VDI(T-15 1024 788 70 56.500 75,000,000 Progressive
VIX-16 1024 788 75 80.000 78,750,000 Progressive
KMl-17 1024 788 85 88.700 94.5W.000 Progressive
m - 1 8 1152 864 75 67.500 1m,W0,000 Progressive
m - 1 9 1280 9@4l 80 80.000 108,000,000 Progressive
v w - 2 0 1280 ga0 85 85.900 148.500.WO Progressive
m - 2 1 1280 1024 80 64.000 10I),WO,WO Progressive
Vm4T-22 1280 1024 75 80.000 135,000,000 Progressive
m - 2 3 1280 I024 85 91.100 157.5W.000 Progressive
VDKT-2 4 1600 1200 80 75.000 162,000,000 Progressive
VaCP-25 1600 1200 6.5 81.m 175,500,000 Progressive
VmT-2 6 18W 1200 70 87.500 189,000,000 Progressive
m - 2 7 1600 1200 75 93.800 Z.500.000 Progressive
Vm4T-28 1600 1200 85 108,300 229.500.000 Progressive
m - 2 9 1792 1344 60 83.640 204,750,000 Progressive
VDUT-30 1792 1344 75 108270 281.000.000 Progressive
m - 3 1 1856 1392 60 88.330 218,250,000 Progressive
m - 3 2 1856 1392 75 112.500 288.WO.WO Progressive
VDXT-33 1920 1440 60 80.000 234,000,000 Progressive
m - 3 4 1920 1440 75 112.500 297,000,000 Progressive
Table 39 - Function Video-Signal-Scanline-Ordering
Name
Purpose
Definition
Remarks
VIDEO-SIGNAL-SCANLIN'~~ORDERING
Scan line ordering desaiptor.
I
typedef enum -VIDEO-SIGNAL-SCANLINE-ORDERING
(
SLO-Uninitialized = 0,
SLO-Progressive = 1,
SLO-Interlaced-UpperFieldEirst = 2,
SLO-Interlaced-LowerEieldFirst = 3,
SLO-Other = 255
VIDEO-SIGNALGNALSCANLINE_oRDERING*,P VIDEO-SIGNAL-SCANLINE-ORDERING;
Scan-line ordering of the video mode, spedfies whether each field contains the entire content of a frame,
or only half of it (i.e. evenlodd lines interchangeably).
Note that while for standard interlaced modes, what field mmes first can be inferred from the mode,
s~ecifvinath is characteristic ex~lidhw/ ith an enurn bdh frees UD the client from havina to maintain modeI
DWORD dwNumerator;
Definition
DWORD dwDenominator;
Table 40 - Function Fractional-Frequency
based lookut~ab les and is extensible for Mure standard modes not listed in the VIDEO-MODE-STD
en*.. -.....--...---....-.--..------- -..-.---.----..--------....-.-...
Name
Purpose
I
Remarks
-- 1
FRACTIONALNALE'REpvENcY
Video mode fractional frequency descriptor.
typedef struct -ERACTIONAL_FREQUENCY
t
Fields
HSync). Vertical frequencies are stored in Hz Horizontal frequencies are stored in KHz I The dynamic range of this encoding lotmat, given loA-7 reresdution is @..2*32 - 1 1 10hn, which translates
to {0..428.4967296) [Hz] for vertical frequencies and {0..428.4967296} [KHz] for horizontal frequencies.
FRACTIONAL-FREQUENCY, *PFRACTIONcFREQUENCY;
This s u b - m i i d s precision range should be acceptable even lor a pmvidso appliion (error in 1
Name
dwNumerator
dwDenominator
Description
Fractional frequency numerator. -
-ractional frequency denominator.
Table 41 - Function Video_Present-Source-Mode-Set
Fractional value used to represent vertical and horizontal frequencies of a video mode (i.e. VSync and
one mimxemnd lor video signal synchronization would imply a time drifI with a cycle of iW7/(60'60*24)
= 115.741 days, . . . - Formatted: Font: 10 pt, Font color:
Dark Blue
Name
Purpose
Definition
Fields
Remarks
VIDEO-~SENT-S~-~DE-SET
Video present source mode set descriptor.
typedef struct VIDEO-PRESENT-SOURCE-MODE-SET
DWORD dwNumOfModes ;
VIDEO-PRESENT-SOURCE_MODE arr-vidpsModes[ll;
1
VIDEO-PRESENT-SOURCE-MODE-SET, *PVIDEO-PRESENT-SORCE-MODE-SET;
Name
dwNumOBlodes
pvidpsModes
Description
Number of video present source modes in the
set
Array Of dwNumOfModes elements of the video
present source mode set
Video present so uerbcei miocdes esedts are used to sets of available video present source modes on
[ the video present sources in a given VidPN implementation.
Table 42 - Function Video-Present-Source-Mode
Name I VIDEO-PRESENT-SOURC!Z-H)DE
{
GRAPHICS-RENDERING-FORMAT grfxFonnat; // if (type = Graphics)
Purpose
I I TEXT-RENDERING-FORMAT textFomat; // if (type = Text) I
Video present source mode descriptor.
typedef struct -VIDEO-PRESENT-SOURCE-MODE
{
VIDEO-PRESENTSOURCE-MODE-TYPE type;
union
Fiekls
1
VIDEO-PRESENT-SOURCE-MODE, *PVIDEO-PRESENT-SOURCE_MODE;
type ppechks whether the mode is a graphics or a text
grfxFormat
video present source mcde.
Descriptor of the graphics video present source mcde
textFormat
I ( source mode determines the format of the video present source's primary surface to w h i i the graphics I
(Valid only if (type=-Graphics) .
Descriptor of the text video present source mode
Remarks
I 1 subsystem is rendering the visual image to be presented to the user, and from whii the video output 1
valid Only if (type==Graphics) .
Vdeo present source mode is the mode of operation of a given video present source. Video present
d e c is reading the visual image content to be converted into a respecdive video mode signal.
Table 43 - Function Video-Present-Source-Mode-Type
5
Name
Purpose
Definition
Remarks
vIDEO_PReSENTENTSOURCEURCEMDDE-TYPE
Vdeo present source mode enumeration type descriptor.
typedef enum - VIDEO-PRESENT-SOURCE_MODE_TYPE
(
RMT-Uninitialized = 0,
RMT-Graphics = 1,
RMT-Text - 2
1
VIDEO-PRESENT-SOURCE-MODE-TYPE, 'WIDEO-PRESENl-SOURCE-MODE_TYPE;
This type is used to spedfy whether the video present source mode is a graphics or a text video present
source mode (see vIDE~-PREsEN~-SOURCE~MODE for more details).
I I SIZE sizeprimsurf; I
Table 44 - Function Graphics_RenderingForrnat
I 1 SIZE sizevisible; I
Name
Purpose
1 Definition 1 DWORD dwstride; I
GRAPHICS-RENDERING-POIIMAT
Graphics video present source mode descriptor.
typedef struct -GRAPHICS-RENDERING-FORMAT
(
I 1 PIXEL-FORMAT PixelFomat; I
I 1 COLOR-ACCESS-MODE clrAccessMode; I
Fields
Remarks
GRAPHICS-RENDERING-FORMAT, *PGRAPHICS-RENDERING-FORMAT; I
ize of the primary surface required for this video
sizePrimSurf
I
of the visible part of the primary surface, used
sizevisible
r panned modes including zoom modes.
I
umber of bytes between the start of one scan line
dwStri.de
I
ixel format (e.g. break down into indnridual sub
PixelFormat
(other being the text video present source mode).
-
clrAccessMode
I ( Note that whenever video present source mode's visible size, I
channels)
Access mode for the pixel color informatian
GRAPHICS-VIDEO-PRESENTNTSOURCEEMODE. sizevisible is not equal to the E~pectiv~idee o
mode's visible size, VIDEO-MODE . sizevisible, hEw scaling is undertaken by the video output codsc.
Graphics video present source mode is the dominantly used subtype of the video present source modes
Table 45 - Function Pixel-Format
Name
Purpose
Definition
Fields
Remarks
PIXEL-POMAT
Graphics video present source mode pixel format desaiptor.
typedef struct -PIXEL-FORMAT
{
D3DFORMAT type;
COLOR-WIS clrBasis;
I
type
clrBasis
Corresponding Dire& type of the pixel m a t
Color basis with respect to which the pixel's color is
expanded.
Display miniport is free to support any D3D pkel format for its graphics modes that is meaningful as a
primary surface pixel format No validation for an appropriately used pixel format shall be done in kemeC
mode. If this turns out to be a problem, WHQL can enforce a certain list of pixel formats from usermode.
This desaiptor does NOT include pixel value sub-channel bit masks since:
a. Primary argument for exposing pixel value subchannel bR masks is to allow application
developers write extensible code that can leverage future pixel formats.
b. As it stands, however, historically numerous application developers have failed to properly
implement generic pixel value demding algorithms and pixel value subchannel bit masks were
dropped in DXB.
c. Main idea: it's best to force application developers to test every scenario they daim to support by
making them use lock-up tables that map D3D pixel format enums into pbel value sub-channel bit
masks.
d. To facilitate application development, it would make sense to ship a helper usermode library that
does the e n u m t ~ b i i smk apping for the applicatim developers. They would still need to code
their application against existing pixel value formats but not maintain look-up tables, for every
application.
e. Need for pixel value subchannel b i s exposure is further reduced by the fact that they are
only truly useful for linear surface formats with well defined integer RGB encoded pixel values.
i. When surface format has a nodinear pixel layout (i.e. VIDPS .vidPSContentLayout =
VpSCL-~inear), knoWledge of pbel value subchannel bitmasks will not help the developer
to know how to access each pbel in the surface.
ii. Most four-CC formats (e.g. NVT4MVT5) fall into this category and one should test against
every format to be supported by the application, because most of them imply texture layouts
that aren't easilyb ed.ies cr
iii. Also the b i k s won't work for floating point pixel formats.
I
Table 46 - Function Color-Access-Mode
Name
Purpose
Definition
Remarks
MU)RU)RACCESS_MDDE
Color access mode desaiptor.
typedef enum -COLOR-ACCESS-MODE
(
CAM-Uninitialized = 0,
C-Direct = 1,
CAM-Presetpalette = 2,
CAM-Settablepalette = 3
1
COLOR-ACCESS-MODE, *PCOLOR-ACCESS-MODE:
Use Direct to represent video present source modes with colors stored diredly in the primary surface.
Use Presetpalette to represent video present source modes with colors' indices stored in the primary
surface and actual color values stored in a palette specific to the video card, that must be queried from
the display miniport
U&settable~alette to represent video present source modes with colors' indices stored in the
primary surface and actual color values stored in a settable palette that can be dynamically set on the
( video card, by spedfying it to the display miniport. '
Table 47 - Function Color-Basis
( Name 1 COLOR-BASIS
typedef enum -COLOR-BASIS
t
Purpose
COLOR-BASIS, *PCOLOR-BASIS;
Remarks I The commonly used cobr bases in graphics industry are RGB, which has the basis (red, green,
Descriptor of the color basis with respect to which the pixels' colors are expanded, or conversely, based
on which the color values are synthesized.
I I blue), as well as YPbPr and YCbCr, which have scaled variants of basis (1, blue-1, red- I
11 *intensity (red, green,blue)
Tri-stimulus linear RGB is well suited for reabtime rendering, since most filtering algorithms use trC
stimulus values to approdmate light's spectral transformations caused by its interaction with the
environment, priparily due to the fad that there is a linear relationship between the perceived light level
and the light's specbal intensity. Ideally, processing (e.g., all processing) of video content 0.e. scaling,
filtering, etc) should be performed in a linear RGB space.
YPbPr spaces store data using a nonlinear curve which is approximately the inverse of a gamma 2.2
curve 0.e. xW.45). This allows more precision to be stored in darker intensities where the human eye is
mwe sensitive. I I sRGB (more accurately, sR'G'B') stores light intensities relative to a gamma curve.
I scRGB stores linear values and requires much higher pxision to represent the same perceptually similar
signal.
The light-intensity based YPbPr and YCbCr is better suited for persistence of pmrendered content, such
as video streaming. This is due to the fact that a human visual system is more responsive to small
differences in photons' intensity rather than frequency (i.e. perceived color), and, hence, a light-intensity
based color expansion ever a finite dynamic range, yields a better perceptual image quality for the human
eye than a tri-stimulus based color expansion in that same range (e.g non-linear Y8Cb8Cr8 appears
slightly better than R8G8B8 and is comparable to R9G9B9).
To represent monochrome modes, use Intensity. Grayscale imaging is heavily used in medical
imaging.
Note: the apostrophe notation YPbPr is used to remind you that you are working with non-linear data.
Table 48 - Function Text-RenderingFormat
Table 49- Function Filterin~Technique
Name
Purpose
Definition
Remarks
!CEXT~RXNDERINGG~T
Text video present source mode format
typedef TED TEXT-RENDERING-FORMAT;
Text video present source modes are only supported for backwards compatibility.
Example 46 - Exemplary Relative Importance of Monitors
In any of the examples herein, the video driver handling multiple monitors (e.g.,
video miniport) can be asked to provide a recommended functional configuration. In
10 such a case, the relative importance of the monitors can be specified. For example, the
monitors can be ranked (e.g., most important to least important). The driver can then
provide a configuration according to the relative importance as specified.
Name
Purpose
Definition
Remarks
Example 47 - Exemplary Stateless Implementation
15 Some of the technologies described herein have been described using an approach
in which the video driver maintains a state of the provisional configuration (e.g., as it is
pinned and unpinned). However, a stateless approach can also be employed. In this
- 107 -
FILTERING-TECHNIQUE
Filtering technique enumeration type.
typedef D3DDDIMULTISAMPLETYPE FILTERING-TECHNIQUE, *PFILTERING-TECHNIQUE;
This type is used to specify what type of filtering technique is used for rendering on the video present
source (e.g. 2~2'4x4 mulb'samplinglsupersampling. etc.).
5
way, the video driver need not track state (e.g., of the provisional configuration) and
may be made more lightweight and less complex. If desired, the client software can
track a state during determination of a desired configuration.
In such an approach, a programming interface (e-g., a DDI) can be used to pass
5 information regarding a state of the provisional configuration. For example, a data
structure can be used to hold the configuration details and passed through the interface.
Example 48 - Eremplary Stateless Driver InteMace
The following is an exemplary kernel mode driver interface (e.g., a DDI),
10 including a stateless video presenting network management miniport interface, for
implementing a video presenting network supporting the various technologies described
herein. In the example, a video presenting network is sometimes called a "video present
network" or "VidPN." A particular configuration for the video present network is
sometimes called a "VidPN implementation." Also in the example, the word "miniport"
15 is used, but the technologies described within can be applied to any display adapter or
video driver.
An exemplary kernel mode driver can be part of a video miniport. Each physical
GPU can be treated as its own adapter, where the adapter can be represented by the
HANDLE hAdapter retrieved below. If a single GPU has multiple outputs (e.g., heads),
20 it may still be treated as a single adapter.
A miniport's HwVidQueryInterface hction can be called with the following
QUERY-INTERFACE structure to retrieve driver entry points:
QUWYYBRJBFACE queryinterface;
queryhterhe.InterfaceType = GUIDUIDDEWNTERFACE_D3DDDI;
queryinterface.Size = sizeof(D3DKMDDI-=ACE);
queryinterface.Version = D3DDDI-INTERFACE-VERSION;
queryinterhe.Intexfae = stpD3DKMDDIInterface;
queryinterfm.InterfaceSpecificData = BrpD3DKMDDIInterfaceSpecficData;
The HwVidQueryInterface call returns NO-ERROR if the interface was
successllly retrieved; otherwise it should return the appropriate error code. The driver
entry points can be returned in the D3DKMDDI-INTERFACE structure below.
Querying the interface may implicitly reference it. Thus, if initialization of the driver
5 fails after the interface has been queried, the interface dereference function can be called
without the driver having seen an explicit reference.
typedef struct -D3DKMDDIfNIERFACE
I
10 USHORT Size;
USHORT Version;
HANDLE hAdapter,
VOIDb pInte&ceReferenw,
VOID* pInte&ceDereference;
15
// Exemplary adapter methods
PFND3DKMDDI OUERYADAPTERDEO
-. --.- ~ -
PFND~DKMDDI~ACQURF~AF'ERTURE
PFND3DKMDDI RELEASEAPERTURE
PFND~DKMDDI~MITCOMMAND
PFND3DKMDDI PREEMPTCOMMAND
J-'
// Exemplary adapter VidPN management methods
PFND3DKMDDI ENUMVIDEOPRESENTSOURCESEZ ~~umVideoPresentSourc~.
45 I/ Exemplary device methods
. .- ..
PFND3DKMDDI-DESTROYDEVICE
PFND3DKMDDI OPENALLOCATION
PFND~DKMDDI~OSEALLOCATION
PFND3DKMDDI RENDER
) D3DKMDDI-INTERFACE;
twedef NTSTATUS (APENTRY *PFND3DKMDDI OUERYADAFTERNFOXHANDLE -. -O - UERYADAFTERNFO,X, H ANDLEh Ada*.r. . CONST
D~DKMDDLARG~QuERYAD~o*);
typedef NTSTATUS (APIENTRY *PFND3DKMDDI-_ CREATEDEVIC. E. XHANDLhEA dapter.
- D~DKMDDIARG CREATEDEVICE?:
typedef NTSTATUS (~WNTRY*P FND~DKMDDI~CREATEALLOCATIO~hLAEda pter,
D3DKMDDIARG-CREATEALLOCATION*);
typedef NTSTATUS (APENTRY *PFND3DKMDDIIDESTROYAUOCATION)(HAFDLE hAdapter, CONST
D3DKMDDIARG DESTROYALLOCATION*);
t-w.e def NTSTATUS (BENTRY *PFND~DKMDD-IA CO.UIRE APERTUREXHANDLE hAdaoter. 7 , . ,
D~DKMDDIARG-ACQUIREAPERTURE*);
t-y -u edef NTSTATUS (APIENTRY *PFND3DKMDDI- R ELEASEAPERTURE.X .H ANDLE hAda-pter.. CO NST
D~DKMDDIARG RELEASEAPERTURE*):
typedef NTSTATUS (%'ENTRY * P F N D ~ D K ~ ~ D I - M A P A P E R T U R E S E GhA~dLapEte r, CONST
D3DKMDDIARG MAPAPERTURESEGMENT*);
tv..o edef NTSTATUS (~IENTRY*P FND3DKMDDI ~APERTURESEGMENTXHANDLhEA daater. CONST , . r ,
D~DKMDDIARG~IJNMAF'APER~GMI&P);
twedef NTSTATUS (APIENTRY *PFND3DKMDDI PATCHXHANDLE hAda~ter. CONST D3DKMDDIARG PATCH*t
~+~C~NTSTATU(SA PIENTRY *PFND~DK~V~DDI~UBMI'?COM~~AhNAD&~ptNer.~ CLOEN ST
-
D3DKMDDIARG SUBMITCOMMAND*);
tvmdef NTSTATUS (~IENTRY* PFND~DKI~DPRI EEMF'TCOMMANDMHANDLEh Ada~ter.C ONST .x , . . .
D~DKMDD~A~~-PREEMP~coMMAN-D *);
hmeddNTSTATUS (MIENTRY *PFND3DKMDDI SETPOINTERSHAPE)(HANDLE hAdapter, CONST - A - , .
D~DKMDDIAR&SETP~INTERSHAPE*);
typedef NTSTATUS (APIENTRY *PFND3DKMDDI SETF'OINTERPOSITION)(HANDLE hAdapter, CONST
typedef NTSTATUS ( ~ I E N T R*YPF ND~DKMDDI~BUILDPAGINGBUFFER)(VOID*,
D3DKMDDIARG-BUILDPAGINGBUFFER*);
typedef NTSTATUS (APJENTRY *PFND3DKMDDIIESCAPE)(HA.NDLE hAdapter, D3DKMDDIARG_ESCAPE*);
trpcdef NTSTATUS (APIENTRY *PFND3DKMDDI-QUERYCmCE)(HANDLE Mdapfer,
typedef N T S T ~ (SA P E ~ R Y*P FND3DKMDDI_SETMODE)(HANDLEh Adapter, D3DKMDDIARG_SETMODE*),
tvpedef NTSTATUS (APIENTRY *PFND3DKMDDI SETOUTPUTSTATEXHANDLE hAdapter,
/I Exemplary VidPN management methods
tjpdef NTSTATUS (APIENTRY *PFND3DKMDDIYENUMVIDEOPRESENTSOURCESET)@LWDLE hAdapter,
D3DKMDDIARG ENUMVIDEOPRESENTSOURCESET*~:
typedef NTSTATUS (GENTRY *PFND~DKMDDI~ENUMVL~EOPRESENTARGETSET)@LhWADdaLpEte r,
D3DKMDDIARG FNUMVDEOPRESENITARGETSE'P~
t.w. e def NTSTATUS (&ENTRY *PFND3DKMDDI ~ssuPPoRTEDV~DPW,, H ANDLEh A&oter. . -
D~DKMDDIARG-ISSUPPORTEDVIDPN*);-
tWedef NTSTAlUS (APIENTRY *PFND3DKMDDI ENUMCOFUNCVIDPNSOURCEIDSETXHANDLE Udauter.
typedef NTSTATUS ( ~ ~ N T *RPYFN D~DKMDDI-WCO~CVIDPNTARGETIDS~LEh Adapter,
D3DKMDDIARG-ENUMCOFUNCVIDPNTARGEIlDS~*);
typedef NTSTATUS (APIENTRY *PFND3DKMDDI-ENUMVIDPNCOFUNCMODAL~NDLE hAdapter,
D3DKMDDIARG ENUMVIDPNCOFUNCMODM*);
typedef NTSTATUS (BENTRY * P ~ ~ D ~ D I ~ R E C O ~ F U N C ~ O N AhAdLapVter, I D P ~ ~
D3DKMDDIARG-~CO~EuNCnONALVIDPN*);
typedef NTSTATUS (APENTRY *PFND3DKMDDI_DESTROYDEVI~LEhD evice);
t.w. e def NTSTATUS (APIENTRY *PFND3DKMDDI OPENALLOCATION,H, IANDLE hDwice. CONST
D~DKMDDIARG-OPENALLOCATION*); -
t.y.p e def NTSTATUS (APJENTRY *PFND3DKMDDI- C LOSEALLOCATION.X .H ANDLE hDevice, CONST
D~DKMDDIARG-CLOSEALLOCATION*);
typedef NTSTATUS (APIENTRY *PFND3DKMDDIIRENDER)(HANJ3LE hDevice, D3DKMDDIARGGRENDER*);
typedef NTSTATUS (APIENTRY *PFND3DKMDDI-PRESENTXHANDLE hDevice, D3DKMDDIARGIARPRESENT*);
The returned hAdapter in the D3DKMDDI-INTERFACE structure can be passed
as the context for pInterfaceReference and pInterfaceDereference. It can also be passed
in the hAdapter parameter for the adapter functions in the interface.
5 typedef struct -D3DKMDDIf~ACESPECIFICDATA
{
HANDLE hAdapM, .
/I Exemplary D3DKMDDI interface callback functions
PFND3DKMDDI-GETHANDLEDATACE phGeiHandleDataCb;
10 PFND3DKMDDI-GETHANDLEPARENTCB phGetHandleParentCb;
PFND3DKMDDII~LECHlLDRENCB p~umHandleChildrenCb;
PFND3DKMDDI-NOTIFYIARD~UPTCB p61NotiryDmaInterruptCb;
PFND3DKMDDI-NOTIFY-DMADPCCB p6INotifyDmaDpcCb.
PFND3DKMDDI-ALLOCSY~OROUTPARAMCB pfiuulocSysMemFolOutParamCb;
15 PFND3DKMDDI-FFEESYSMEh4FOROUTPARAMCB pMreeSysMemForOutParamCb;
) D3DKMDDIINERFACESPECIFICDATA;
typedef HANDLE (APIENTRY CALLBACK *PFND3DKMDDICGETHANDLEPARENTCB)(HANDLE hDevice,
D3DKMT-HANDLE);
20 typedef VOID* (APIENTRY CALLBACK *PFND3DKMDDIYGETHANDLEDATACBmLE hDevice, CONST
D3DKMDDIARGCBGCGmLEDATA*);
typedef HANDLE (APIENTRY CALLBACK *PFND3DKMDDII-LECHILDRENCB-LE bDevice,
CONST D3DKMDDIARGCBGCBENUMUNDLECHILDREN*);
typedef NTSTATUS (APIENTRY CALLBACK *PFND3DKMDDIYNOTIFYIARDMANIERRUPTCB)(HANDhALEda pter,
25 CONST D3DKMDDIARGGNOTIFYTIFDMAlNERRUPTUPTDATA*);
typedef NTSTATUS (APIENTRY CALLBACK *PFND3DKMDDIYNOTIFYTIFDMADPCCB~hLAEd apter, CONST
D3DKMDDIARG-NOTIEYIARDMADPCPCDATA*);
typedef VOID* (APIENTRY CALLBACK *PFND3DKMDDI-ALLOCSYSMEMFOROUTPARAMCBPO~O L-TYPE,
IN SDT);
30 typedef VOID (APIENTRY CAUBACK *PFND3DKMDDIIFREESYSMEMFOROUTPARAMCB~OID*);
The interface specific data can contain pointers to callback functions in the
runtime that the driver can call. The hAdapter can be the runtime's adapter handle and
can be passed for callbacks requesting an adapter handle.
In addition to the above interfaces, the following legacy IOCTLs can also be
35 used:
IOCTLOCTLVIDEOORESETRESDEVICE
Table 50 - Function EnumVideoPresentSourceSet
typedef NTSTATUS
(APD3TRY IPFM)3DKMDDIImEOPRESENTSOURCESET)
(IN HANDLE hAdapter,
OUT D3DKMDDIARGIAR~EOPRESENTSOURCESET* pEnumVideoPresentSourceS~);
typedef struct-D3DKMDDIARGG~EOPRES~SOURCESET
{
OUT D3DKMDDI-VIDEOEOPRESENTSENTSOURCECpEVSidEeTo*Pr esentSourceSet;
1
D3DKMDDIARGG~EOPRESENTSOURCESET;
EnumVideoPresentSourceSet can be called for each display adapter in the system
10 by the VidPN manager instance that is driving the post-rendering video presentational
capabilities of the respective display adapter in order to obtain a list of video present
sources that the specified display adapter has.
The miniport can allocate a large enough buffer in system memory to contain the
requested set of video present sources for the specified display adapter using the
15 AllocSysMemForOutParamCb callback provided to it by the operating system via the
INTERFACESPECIFICDATA interface. The size of the allocation should be
~ ~ ~ ~ ~ ~ ~ D ~ D I - ~ E O ~ P R E S E N T ~+S sOizUeoRf(&D3~DKSMEDDTI-)V IDEOOPRESENTIARSOUR*c (E#> o f video
present sources - 1).
Once the memory for the output parameter has been allocated, the miniport can
20 populate it based on the detinitions below:
where:
NumOfVideoPresentSources - Number of video present sources listed in
VideoPresentSources.
5 VideoPresentSources - Address of the array of video present source descriptors
in the set. Actual number of elements is specified in NumOfVideoPresentSource~~
With the video present source descriptor defined as follows:
typedef struct -D3DKMDDIIVIDEOVIDPRESE5TTISOURCE
10 t
D3DKMDDI-VIDEOIPRESENTISOURCECEID VideoPresentSourceID;
DWORD dwReserved;
1
D3DKMDDIIVIDEOIPRESENT_SOURcE.,
15 where:
VideoPresentSourceID - Unique ID used to reference the respective video
present source by the miniport and the operating system.
dwResewed - Other video present source descriptor properties go here
20 With the video present source ID defined as:
typedef UMT
On successful return fiom this function, the operating system can take ownership
of the lifetime of the data returned in the output parameter and can deallocate the
memory taken by its supporting allocation when it is done with it.
25 Return Codes
STATUS-SUCCESS indicates that the driver handled the call successfully.
Table 51 - Function EnumVideoPresentTargetSet
typedef NTSTATUS
(APEWRY *PFND3DKMDDII~EOl'RESENTTARGETSET)
rn K4mLE hAdapter,
OUT D3DKMDDIARG-ENUMVJDEOPRESENITARGETSET* pEnumVideoPresentTargetSetArg);
typedef stnrct -D3DKMDDIARG-mEOPRESENTTARGETSET
(
OUT D3DKMDDI-VIDEO-PRESENT-TARGET-SET* pVideoPresentTargetSet;
1
D3DKMDDIARGGENUMVIDEOPRES~ARGETSET;
EnumVideoPresentTargetSet can be called for each display adapter in the system
5 by the VidPN manager instance that is driving the post-rendering video presentational
capabilities of the respective display adapter in order to obtain a list of video present
targets that the specified display adapter has.
The miniport can allocate a large enough buffer in system memory to contain the
requested set of video present sources for the specified display adapter using the
10 AllocSysMemForOutParamCb callback provided to it by the operating system via the
INTERFACESPECIFICDATA interface. The size of the allocation should be
sizeoQ3DKIMDDI-VIDEO-PRESENT-TARGET-Sm + sizeoQ3DKMDDIIVIDEOOPRESENTENTTARGE(T#) o f video
present targets - 1).
Once the memory for the output parameter has been allocated, the miniport can
15 populate it based on the defmitions below:
typedef struct -D3DKMDDI-VIDEO-rmESENT-TARGET-SET
(
SIZE-T NumOfVideoResentTargets;
D3DKMDDI-VIDEO-PRESENT-SOURCE VideoFksentTargets[l];
20 1
D3DKMDDI-VIDEOENTm(ESENT-TARGET-Sm,
where:
NumOfVideoPresentTargets - Number of video present targets listed in
VideoPresentSources.
VideoPresentSources - Address of the array of video present target descriptors
in the set. Actual number of elements is specified in NumOfVideoPresentTargets.
5
With the video present target descriptor defmed as follows:
where:
VideoPresentTargetID - Unique ID used to reference the respective video
present target by the miniport and the operating system.
20 VideoOutputTechnology - Type of the video output technology.
VideoOutputHPDAwareness - Type of the video output's HPD awareness.
MonitorOrientationAwareness - Monitor orientation awareness.
With the video present target ID defined as:
25 typedef UINT D3DKMDDIIVIDEONPRESENTENTTARGET-D,
The video output technology type descriptor can be defined as:
typedef enum -D3DKMDDI-VIDEOOO~DTECHNOLOGY
{
D3DKMDDI-VOT-UNBWbUIZED = 0,
3 0 D3DKMDDI-VOT-HD IS = 1,
D3DKMDDI-VOT-DVI = 2,
D3DKMDDIIVOTTHDMI = 3,
D3DKMDDI-VOTOTHDh4J2 = 4.
D3DKMDDI-VOT-SVIDEO-4PIN = 5,
35 D3DKh4DDI-VOT-SWEO-WIN = 6,
D3DKMDDI-VOTOTRCAOTCOMPOSITE = 7.
D~DKMDDI-VOT-RCA- COMPONENT = 8,
D3DKMDDI-VOT-BNC = 9,
D3DKMDDI-VOT-RF = 10,
D3DKMDDIIVOTTOTHW = 255
1
D3DKMDDI-VIDEOEOOUTPUTUTTECHNOLOGY;
5 The video output HPD awareness descriptor type can be defined as:
typedef enum -D3DKMDDIIVIDEOVIDOUTPUTUTHPDDAW~S
{
D 3 D K M D D I V I D V O H P D A A ~ = 0,
D3DKMDDI-VOHPDA-NONE = 1,
1 0 D3DKMDDI-VOHPDA-DESTRUmLYPOLLED = 2,
D3DKMDDIIVOHPDAONONDESTRU~YPOUED = 3,
D3DKMDDIIVOHPDAVINlERRUPWLE = 4
I
D3DKMDDI-VIDEOOUTPUTHPD-AWARENESS;
15 Video output HPD awareness can be used to represent the level of monitor
connectivity sensed by a display adapter on its video output, and with the following four
types available:
1. Interruptible HPD-awareness if and only if the miniport can asynchronously
notify the operating system about monitor arrivals/departures.
20 2. Non-Destructively Polled HPD-awareness if and only if the miniport can not
asynchronously notify the operating system about monitor arrivalddepartures, but
the operating system can periodically poll for the presence of a monitor without
causing visual artifacts.
3. Destructively Polled HPD-awareness if and only if the miniport can not
25 asynchronously notify the operating system about monitor arrivalddepartures, but
the operating system can sporadically poll for presence of a monitor, causing
visual artifacts on each poll.
4. No HPD-awareness if and only if the miniport is not aware of monitor
anivals/departures either through interrupts or polling.
30 Monitor orientation awareness can be defined as:
typedef enurn -D3DKMDDI-MONITOR-ORIENTATION-AWARENESS
{
D3DKMDDI-MOA-UNJNTMLIZED = 0,
D3DKMDDIIMOAINONE = 1,
35 D3DKMDDI-MPA-POLLED = 2,
D3DKMDDIIMOAAINTERRUPWLE = 3
I
D3DKMDDIIMONITORNITORENTATIONTIAWARENESS;
- 116-
On successful return fiom this function, the operating system can take ownership
of the lifetime of the data returned in the output parameter and can deallocate the
memory taken by its supporting allocation when it is done with it.
Return Codes
5 STATUS-SUCCESS indicates that the driver handled the call successllly.
Table 52 - Function IsSupportedVidPN
typedef NTSTATUS
(MIENTRY *PFND3DKMDDIIISSUPPORTEDVIDPN)
@-J HmlDLE hAdapter,
IN OUT D3DKh4DDIARGGISSUPPORTEDVIDPN* pIsSupportedVidPNArg);
typedef met -D3DKMDDIARG-ISSUPPORTEDVIDPN
IN OUT D3DKMDDI-VIDPN* pDesiredVidPN;
OUT BOOLEAN* pbIsVidPNSupported;
1
D3DKMDDIARG-ISSUPPORTEDVIDF'N;
L I
IsSupportedVidPN can allow the opemting system to ask the miniport whether
10 the provided VidPN configuration is supported (e.g., can be extended to a functional
VidPN). The first argument, hAdapter, can specifL the display adapter on which the
VidPN support is in question. The actual VidPN can be specified in the first field of the
second argument, pIsSupportedVidPNArg->pDesiredVidPN, where the VidPN
descriptor can be defmed as:
15 iypedef met -D3DKMDDI-VIDPN
{
D3DKMDDI-VIDPN-TOPOLOGY VidF'NTopology;
DWORD dwReserved,
I
20 D3DKMDDI-VIDPN;
The VidPN topology descriptor can be defined as:
- 117-
typedef struct -D3DKMDDI-VIDPNNTOPOLOGY
{
D3DWDI-VIDpN-PRESENT_PATH-m VidPNF'resentPathSet;
5 1
D3DKMDDI-VIDPN-TOPOLOGY;
VidPNPresentPathSet can represent the set of video present paths constituting the
VidPN's topology, where:
10
typedef struct -D3DKMDDI-VIDPN-PRESENT-PATH-SET
{
S W T NumOfVidPNPresentPaths,
D3DKMDDI-VIDPN-PRESENT-PATH VidPNPmentF'aths[l];
15 1
D3DKMDDIIVIDPNNPPRESENTENTPATHTHSET,
with:
1. NumOfVidPNPresentPaths containing the number of video present paths in
20 VidPNPresentPaths, and
2. VidPNPresentPaths containing an array of video present paths constituting the
VidPN's topology.
The VidPN present path descriptor can be defined as:
25
typedef struct -D3DKMDDIIVIDPNPNPRESENTSENTPATH
{
D3DKMJlDI-VIDPN-SOURCE VidPNSource;
D3DWDI-VIDPN-TARGET VidPNTarget;
30 D3DKMJlDI-VIDPNNPRESENTENTPATHTHTRANSFORMATIViOdNPN PresentF'athTransformation;
1
D3DWDIIVIDPNPNPRESENTENTPATH;
D~DKMDDI-VIDPN-pmm-PATisH th e video present path descriptor that can be used
to describe a mapping fiom a single video present target to a single video present source
in a VidPN topology, with:
VidPNSource is the video present path's source descriptor.
5 VidPNTarget is the video present path's target descriptor.
VidPNPresentPathTransformation is the video present path's content
transformation descriptor.
where the VidPN source descriptor can be defined as:
typedef struct -D3DKMDDIIVIDPNNSOURCE
10 {
D3DKMDDI-VIDEO-P~SENTSENTSOURCE-ID VidPNSourceD,
SIZE-T PinnedModeIndex;
D3DKMDDI-VIDPNPNSOURCEEMODESIX* pCofuncVidPNSourceModeSet;
I
15 D3DKMDDI-VIDPN-SOURCE;
with:
VidPNSourceID is the unique ID used to reference the respective video present
source by the miniport and the operating system. This value comes fiom the
EnumVideoPresentSourceSet call.
20 PinnedModeIndex is the index of the video present source mode that is pinned
in the co-functional set of modes available on this video present source given the
current VidPN configuration, or D3DKMDDI_NO_PINNED_MODE if no mode
is pinned on this source.
pCofuncVidPNSourceModeSet is the VidPN source modes co-functional with
25 the current (partial or provisional) VidPN this source is a member of.
The VidPN source mode set descriptor can be defined as:
typedef struct -D3DKMDDIIVIDPNPNSOURCECEMODESET
{
SIZE-T NumOfVidPNSomceModes;
30 D3DKMDDI-VIDPN-SOURCE-MODE VidF'NSourceModes[l];
I
D3DKMDDI-WPN-SOURCE-MODESET;
with:
NumOfVidPNSourceModes specifying the number of video present source
35. modes listed in VidPNSourceModes.
VidPNSourceModes containing the array of video present source modes in the
set.
- 119-
The VidPN source mode descriptor can be defined as:
tupedef sbuct -D3DKMDDIIVIDPNSOURCE-MODE
{
D3DKMDDI-VIDPN-SOURCE-MODE_TYPE Type;
5
union
D3DKMDDI-GRAPHICS-REM>ERING-FORMAT grfxFomat;
MDKMDDI-mIRENDERINGFORMAT textEomat;
10 1;
1
D3DKMDDI-VIDPN-SOURCE-MODE;
with Type containing the VidPN source mode type descriptor, defined as:
typedef enum -D3DKMDDI-VIDPN-SOURCE-MODE-WE
{
If Type equals D3DKMDDI-RMT-GRAPHICS, then the source mode descriptor
25 contains a graphics rendering format descriptor, grfxFormat, defined as:
iypedef struct -D3DKMDDI-GRAPHICS-RENDERING-FORMAT
{
SIZE sizeprimsurf;
SIZE sizevisible;
30 DWORD dwStride;
D3DKMDDI-PIXEL-FORMAT PixelFomat;
D3DKMDDI-COLOR-ACCESS-MODE PixelValueAccessMode;
1
D3DKMDDI-GRAPMCS-RENDERING-FORMAT;
35 with:
sizeprimsurf specifying the size of the primary surface required for this VidPN
source mode.
sizevisible specifying the size of the visible part of the primary surface, used for
panned modes including zoom modes.
5 dwStride specifying the number of bytes between the start of one scan line and
the next.
PixelFormat specifying the pixel format.
PixelValueAccessMode specifying access mode for the pixel value information.
Otherwise, if Type equals D3DKMDDI-RMT-TEXT, then the source mode
descriptor contains a text rendering format descriptor, textFormat, defined as:
typedef enum _D3DKMDDI-=-REM)ERINGFORMAT
{
D3DKMDDIITRFTRF-IZED = 0
15 1
D3DKMDDI-m-RENDmG-FORMAT;
Furthemore, the VidPN target descriptor can be defined as:
with:
VidPNTargetID is the unique ID used to reference the respective video present
target by the miniport and the operating system. This value comes fiom the
EnumVideoPresentTargetSet call.
30 PinnedModeIndex is the index of the video present target mode that is pinned in
the co-functional set of modes available on this video present target given the
current VidPN configuration, or D3DKMDDI-NO-PINNED-MODE if no mode
is pinned on this target.
pCofuncVidPNSourceModeSet is the VidPN target modes co-functional with
35 the current (partial) VidPN this target is a member of.
The VidPN target mode set descriptor can be defined as:
typedef struct -D3DKMDDI-VlDPN-TARGET-MODESET
{
SIZE-T NumONidPNTargetModes;
D3DKMDDI-VIDPN-TARGET-MODE VidPNTargetModes[l];
5 1
D3DKMDDI-VIDPNTARGETMODESET;
with:
NumONidPNTargetModes specifying the number of video present target
modes listed in VidPNTargetModes.
10 VidPNTargetModes containing the array of video present target modes in the
set.
where the VidPN target mode descriptor can be defined as shown in Table 53:
Table 53 -- VidPN target mode descriptor
15
typedef struct -D3DKMDDIctVIDPNNTARGET-MODE
(
D3DKMDDI-VIDEO-SIGNAL-STANDARD vidStandard;
SIZE sizeTotal,
SIZE sizeActive;
SIZE' sizeActiveOffset;
SIZE sizeTLDeltaVisibleFmmActive;
SIZE sizeBRDe1taVisibleFromActive;
D3DKMDDI-FRACTI0NA.T-FREQUENCY frqVSync;
D3DKMDDI-FRACTIONAL-FREQUENCY ff@mc;
SIZET SMiXelRate;
D3DKMDDI-VIDEO-SIGNAL-SCANLINE-ORDmG ScanLineOrdering,
D3DKMDDI-GTFCOMPLIANCE IsGTFCompIiant;
D3DKMDDI-MODE-P-CE ModeF'reference;
1
D3DKMDDI-VIDPN-TARGET-MODE;
typedef enum -D3DKMDDIIVlDEO-SIGNAL-STANDARD
(
llWxH(ilp}@(VR I HR I CR )
D3DKMDDI-VMS-mIZED = 0,
D~DI&DDI-VMS-GTF = 1,
D3DKMDDI-VMS-NTSC-M = 2, I/ 720 x 525i @ (59.94 [Hz] I 15,734.27~11 3,579,545 [Hz])
= 3, I/ 720 x 525i @ (59.94 [Hz] 1 15,734.27[Hz]1 3,579,545 [Hz])
= 4, /I 720 x 525i @ (59.94 [Hz] 1 15,734.27pI I 4,433,618.75m)
= 5, 11 720 x 625i @ (50 p] I 15,625 [Hz] I 4,433,618.75[Hz1)
= 6, I1 720 x625i @ (50 [Hz] 1 15,625 [Hz] I 4,433,618.75ml)
= 7, I1 720 x 625i @ (50 [Hz] I 15,625 [Hz] I 4,433,618.75ml)
= 8, I1 720 x 625i @ (50 [Hz] 1 15,625 [Hz] 1 4,433,618.75[IIz])
= 9, 11 720 x 625i @ (50 [Hz] 1 15,625 [Hz] 1 4,433,618.75[Hz])
= 10, I1 720 x 525i @ (59.94 [Hz] 1 15,734 [Hz] 1 3.575.611.49[Hz])
= 11. I1 720 x 625i @ (50 [Hz] 1 15,625 [Hz] 1 4,433,618.75@])
= 12, 11 720 x 625i @ (50 [Hz] 1 15,625 [Hz] I 3,582,056.25[Kzl)
= 13, I1 720 x 625i @ (50 [Hz] 1 15,625 [Hz] 1 m])
= 14, 11 720 x 625i @ (50 [Hz] 1 15.625 [Hz] 1 [Hz])
= 15, I1 720 x 625i @ (50 [Hz] I 15,625 [Hz] 1 PI)
= 16, /I 720 x 625i @ (50 @z] I 15,625 [Hz] 1 [Hz])
= 17, /I 720 x 625i @ (50 [Hz] 1 15,625 [Hz] 1 [Hz])
= 18, 11 720 x 625i @ (50 [Hz] 1 15,625 [Hz] I [Hz])
= 19, N ?20 x 625 @ (50 [Hz] 1 15,625 [Hz] I [Hz])
= 20, I/ 720 x 625i @ (50 [Hz] 1 15,625 [Hz] 1 [Hz])
= 21, I1 720 x 480i @ (59.94 [Hz] 1 W 1 [Hz])
=22,ll720x480i@(60 m]l @z]I [Hz])
= 23, I1 640 x 48% @ (59.94 [Hz] 1 [Hz] I [Hz])
= 24, 11 640 x 480p @ (60 [Hz] 1 [Hz] I [Hz])
= 25, N 720 x 480p @ (59.94 [Hz] 1 [Hz] 1 m])
= 26, 11 n o x 480p @ (60 ~1 I [H~II ~ 1 )
= 27, 11 1280 x 72% @ (59.94 [Hz] 1 [Hz] 1 [Hz])
= 28, I1 1280 x 72% @ (60 [Hz] l [Hz] l [Hz])
= 29. N 1920 x 1080i @ (59.94 m] 1 [Hz] 1 [Hz])
= 30, 11 1920 x 108Oi @ (60 [Hz] 1 [Hz] I [Hz])
= 31, N 720 x 576i @ (50 [Hz] 1 [Hz] / [Hz])
= 32, I1 720 x 576p @ (50 [Hz] I [Hz] 1 [Hz])
= 33, 11 1280 x 72% @ (50 m] 1 [Hz] I [Hz])
= 34, I1 1920 x 1080i @ (50 [Hz] I [Hz] 1 [Hz])
= 35, 11 1920 x 1080p @ (23.960 [Hz] 1 [Hz] 1 [Hz])
= 36, I1 1920 x 1080p @ (24 [Hz] 1 [Hz] 1 [Hz])
= 37, I1 1920 x 1080p @ (25 IJk] I [Hz] 1 [Hz])
= 38, 11 1920 x 1080p @ (29.970 [Hz] 1 [Hz] I [Hz])
= 39. I1 1920 x 1080p @ (30 [Hz] 1 [Hz] 1 [Hz])
= 40. 11 1920 x 1080~@ (50 [Hz] 1 [Hz] 1 [Hz])
=41.//1920xl080p@(60 [Hz]/ [Hz]/ [Hz])
= 42, I1 720 x 400p @ (70 [Hz] 1 [Hz] 1 [Hz])
= 43, I/ 720 x 400p @ (88 [Hz] 1 [Hz] 1 [Hz])
= 44, I/ 640 x 480p @ (60 [Hz] 1 [Hz] I [Hz])
= 45, 11 1024 x 768i @ (87 [Hz] I [Hz] 1 [Hz])
=46,//640~480p@(67 [Hz]/ [Hz]/ [Hz])
= 47, I/ 832 x 624p @ (75 [Hz] 1 w] 1 [Hzn
=48,//1152~870p@(75 [Hz]/ [Hz]/ m])
=49,#640~480p@(72 [Hz]/ [HA/ [Hz])
= 50, 11 640 x 480p @ (75 [Hz] 1 w ] 1 [Hz])
=51,l/8OOx600p@(56 [Hz]/ l3Iz]/ [Hz])
= 52, 11 800 x 600p @ (60 [Hz] 1 [Hz] I [Hz])
= 53, 11 800 x 60% @ (72 [Hz] I [Hz] 1 [Hz])
= 54, 11 800 x 600p @ (75 [Hz] 1 [Hz] I [Hz])
= 55, I1 1024 x 768p @ (60 [Hz] 1 [Hz] I [IIz])
= 56, 11 1024 x 768p @ (70 [Hz] I [Hz] 1 m])
= 57, I1 1024 x 768p @ (75 [Hz] 1 [Hz] 1 [Hz])
= 58, 11 1280 x 1024p @ (75 [Hz] 1 [Hz] 1 m])
= 59, I1 640 x 350p @ (85 [Hz] 1 37,900 [Hz) 1 31,500,000 [Hz])
= 60, I1 640 x 400p @ (85 [Hz] 1 37,900 [Hz] I 31,500,000 [Hz])
= 61, I1 720 x 400p @ (85 [Hz] 1 37,900 [Hz] 1 35,500,000 [Hz])
= 62, I/ 640 x 48% @ (60 f.Hz] 1 31,500 [Hz] 1 25,175,000 [Hz])
= 63, I1 640 x 480p @ (72 w ] 1 37,900 [Hz] 1 31,500,000 [Hz])
= 64, N 640 x 480p @ (75 &] 1 37.500 w] I 31,500,000 [Hz])
= 65, I1 640 x 480p @ (85 [Hz] 1 43,300 [Hz] I 36,000,000 [Hz])
= 66, I1 800 x 600p @ (56 [Hz] I 35,100 [Hz] I 36,000,000 [Hz])
= 67. 11 800 x 600p @ (60.317 [Hz] I 37,879 [Hz] 1 40,000.000 [Hz])
= 68, I1 800 x 600p @ (72 [Hz] 1 48,100 [Hz] 1 50,000,000 [Hz]) - 69, I1 800 x 600p @ (75 [Hz] I 46,900 [Hz] 1 49,500.000 [Hz])
= 70, 11 800 x 600p @ (85 [Hz] I 53,700 [Hz] I 56,250,000 [Hz])
= 71, I1 1024 x 768i @ (43 [Hz] I 35,500 [Hz] I 44,900,000 [Hz]) - n, 11 1024 x 768p @ (60.004 ~1148,363 ~1 I 65,000,000
= n, 11 1024 x 768p @ (70 1 56,500 [~z1175,000,000
= 74, 11 1024 x 768p @ (75 [Hz] I 60,000 [Hz] 1 78,750,000 [Hz])
=75, 11 1024 x 768p @ (85 [WI 68,700 [Hz] 1 94,500,000 [Hz])
= 76, I1 1152 x 864p @ (75 [Hz] I 67.500 [Hz] I 108,000,000 [Hz])
= 77, N 1280 x 960p @ (60 [Hz] 1 60,000 p] 1 108,000,000 [Hz]) - 78. 11 1280 x 960p @ (85 [Hz] 1 85.900 W I 148,500,000 [Hz]) - 79, 11 1280 x 1024p @ (60 [&II6 4,000 m ]I 1 08,000,000 m])
= 80, I1 1280 x 1024p @ (75 @II8 0,000 [Hz] I1 35,000,000 [Hz])
D3DKMDDI-VMS-WMT-23 = 81, I1 1280 x l024p @ (85 [Hz] I 91,100 @] 1157,500,000 [Hz])
D3DKhDDI-VMS-VDMT-24 = 82, 11 1600 x 12% @ (60 [Hz] 1 75,000 [Hz] 1 162,000,000 [Hz])
D3DKMDDI-VMS-VDIX-25 = 83, I1 1600 x 120% @ (65 [Hz] I 81,300 [Hz] 1 175,500,000 m])
D3DKMDDI-VMS-VDIX-26 = 84, I1 1600 x 1200p @ (70 [Hz] I 87,500 [Hz] I 189,000,000 [Hz])
D3DKMDDI-VMS-VDIX-27 = 85, I1 1600 x 1200p @ (75 [Hz] / 93,800 w] 1202,500,000 [Hz])
D3DKMDDIIVMSVMSVDMT-28 = 86, I1 1600 x 1 2 9 @ (85 m] I 106,300 p] 1229,500,000 w ] )
D3DKMDDI-VMS-VDMT-29 = 87, I1 1792 x 1344p @ (60 [Hz] I 83,640 [Hz] 1204,750,000 [Hz])
D3DKMDDI-VMS-VDMT-30 = 88, I1 1792 x 1344p @ (75 [Hz] 1 106,270 [Hz] 1261.750,000 [Hz])
D3DKMDDIIVMSVMSVDh4T-31 = 89, 11 1856 x 1392p @ (60 [Hi] 1 86,330 m]1 218,250,000 w ] )
D3DKMDDI-VMS-VDMT-32 = 90, /I 1856 x 1392p @ (75 [Hz] 1 112,500 [Hz] 1288,000,000 [Hz])
D3DKMDDI-VMS-VDMT-33 = 91, I1 1920 x 144% @ (60 [Hz] 1 90,000 [Hz] 1234,000,000 [Hz])
D3DKMDDI-VMS-VDm-34 = 92, I1 1920 x 144% @ (75 m] I 112,500 [Hz] 1297,000,000 [Hz])
D3DKMDDI-VMS-OTHER = 255
I
D3DKMDDIIVIDEOOSIGNAL-STANDARD;
typedef enum -D3DKMDDI-GTFCOMPLIANCE
I
(
D3DKMDDI-GTE-UNNITULIZED = 0,
D3DKMDDI-GTF-COMPLIANT = 1,
D3DKMDDI-GTF-NOTCOMPLIANT = 2
1
D3DKMDDI-GTFCOMPLIANCE.,
typedef enum -D3DKMDDI-MODE-PREFERENCE
{
D 3 D K M D D I - M P - m m = 0,
D3DKMDDI-MP-PREFEIUUD = 1,
D3DKMDDI-MP-NO- = 2
1
D3DKMDDI-MODE-PREFElUNcE.,
with:
vidstandard specifying the video mode standard this mode is defined by (if any).
sizeTotal specifying video signal's size in pixels (e.g., HTotal & VTotal).
5 sizeActive specifying the presented image's size in active pixels (e.g., HActive &
VActive).
sizeActiveOffset specifling the position of the active pixels with respect to the
total pixels.
sizeTLDeltaVisibleFromActive specifying monitor screen's delta of visible
pixels' top-left comer from video signal's active pixels bottom-right comer.
sizeBRDeltaVisibleFromActive specifying monitor screen's delta of visible
pixels' bottom-right comer from video signal's active pixels bottom-right comer.
frqVSync specifying this mode's vertical re£iesh fiequency (in Hz).
frqHSync specifying this mode's horizontal refresh frequency (in KHz).
sztPixelRate specifying this mode's pixel clock rate.
ScanLineOrdering specimg this mode's scan line ordering (e.g., progressive,
interlaced).
IsGTFCompliant specifying whether this mode's VSync, HSync, and clock rate
comply with the restrictions imposed by the VESA Generalized Timing Formula.
Modepreference specifying whether this mode is preferred by the monitor
connected to the respective video output.
The video signal standard enum can be used to simplify video mode comparisons
when appropriate.
The ktional frequency descriptor can be defined as:
typedef struct -D3DKMDDIctFRA(JIIONAL-FREQUENCY
{
SUET Numerator,
SUET sztDenominator,
1
D3DKMDDIFRA(JIIONALALFREQUENCY;
with:
Numerator specifying the fixdonal frequency numerator.
Denominator specifying the fractional fkquency denominator.
Vertical frequencies can be stored in Hz and horizontal frequencies can be stored
in KHz. The dynamic range of this encoding format, given 10k7 resolution (on 32-bit
systems) is (0..(2"32 - 1) / 10A7), which translates to {0..428.4967296) Bz] for vertical
frequencies and (0..428.4967296) m] for horizontal frequencies. This submicroseconds
precision range should be acceptable even for a pro-video application
(error in one microsecond for video signal synchronization would imply a time drift with
a cycle of 1 OA7/(60*60*24) = 1 15.741 days.
The video signal scan-line ordering descriptor can be defined as:
- 126 -
typedef enum -D3DKMDDI-VIDEO-SIGNAL-SCm-ORDERING
{
D3DKMDDI-VSSLO-UNNITMLIZED = 0,
D3DKMDDI-VSSLO-PROGRESSIVE = 1,
5 D3DWDI-VSSLO-INTERLACED-WPE%ILELDFIRST = 2,
D3DKMDDI-VSSLO-INTERLACED-LOWERFELDFIRST = 3,
D3DKMDDI-VSSLO-OTHER = 255
1
D3DKMDDI-VIDEO-SIGNALSCANLINE-ORDERING;
10 and can be used specify whether each field contains the entire content of a h e or only
half of it (e.g., evenlodd limes interchangeably). Specifying this characteristic explicitly
with an enum can both fiee up the client fiom having to maintain mode-based look-up
tables and be extensible for future standard modes not listed in the
15 Storing deltas for visiblelactive pixels mapping rather than visible pixels' size &
offset has the added benefit of idealldefault state being zeros.
The VidPN present path transformation descriptor can be defined as:
typedef enum -D3DKMDDIeVIDPNPNPRESENT-PATH-TRANSFORMATION
{
20 D3DKMDDI-WIT-IDENTITY = 1,
D3DKMDDI-WFT-CEMERED = 2
1
D~DKMDDI-WPN-PRESENT-PATH--SFORMATION;
with:
25 D3DKMDDI-VPPT-IDENTITY representing source content presented as-is.
Note that this transformation is available if and only if the video present source
and target modes' spatial resolutions match.
D3DKMDDI-WPT-CENTERED representing source content presented
unsealed, centered with respect to the target mode's spatial resolution.
30 A specified VidPN should at a minimum specify a valid topology, but can also
have some or all of its targets/sources configured with respectively pinned modes.
Return Codes
STATUS-SUCCESS indicates that the driver handled the call successfully.
STATUS-GRAPHICS-INVALIDDDVIDPNNTOPOLOGinYd icates that the specified
VidPN topology is invalid.
Table 54 - Function EnumCofuncVidPNSourceIDSet
typedef NTSTATUS
(APIENTRY *PFND3DKMDDIIENUMCOFUNCVIDPNSOURCEIDSET)
(IN I-WNDLE hAdapter,
IN OUT WDKMDDIARG-ENUMCOFUNCVIDPNSOURCEIDSET*
~numCofuncVidPNSo~~ceID~g);
typedef shuct -D3DKMDDIARGGENUMCOFUNCVIDPNSOURCEIDSET
{
IN D3DKMDDI-VIDPN* pConstmhingVidPN;
OUT D3DKMDDIIVIDEOOPRESENTISOURCE-ID-SET* pCofuncVidPNSourceIDSet;
1
D3DKMDDIARG-~COFUNCVIDPNSOURCEIDS~,
EnumCofimcVidPNSourceIDSet enumerates a set of VidPN source IDS
10 confunctional with the specified VidPN implementation. A VidPN source can be
cofunctional with a given VidPN implementation if an only if it can be added to its
topology via at least one video present path without rendering that VidPN
implementation invalid or unsupported. The miniport can allocate a large enough buffer
pointed to by pEnumCofuncVidPNSourceIDSetArg to accommodate the entire
15 enumeration result using
D3DKMDDI-INTERFACESPECIFICDATA.p~llocSysMeouCb. The
size of the allocation should be sizcof@3DKMDDI-VIDEOVIDPRESENTENTSOURCECE+D u)SET)
sizeom3DKMDDI-VIDEO-PRESW-SOURCE-ID) (# of wfunctional video present sources - 1).
Once the memory for the output parameter has been allocated, the miniport can
populate it based on the definitions below:
typedef struct -D3DKMDDIIVIDEOOP~-SOURCE-ID-SET
{
5 SIZE_T NumOfVidPNSourceIDs;
D3DKMDDI-VIDEO-PmSENT-SOURCE-ID VideoFVesentSourccIDs[l];
1
D3DKMDDI-WEO_PRESENT_SOURCEEIDIDSET;
with:
10 NumOfVidPNSourceIDs specifying the number of video present sources' IDS
listed . in VideoPresentSourceIDs. VideoPresentSourceIDs representing the array of video present sources' IDS in
the set.
On successful return h m this function, the operating system can take ownership
15 of the lifetime of the data returned in the output parameter and can deallocate the
memory taken by its supporting allocation when it is done with it.
Return Codes
STATUS-SUCCESS indicates that the driver handled the call successfully.
STATUS-GRAPHICSCINVALIDIDVIDPNNTOPOLOGinYd icates that the specified
20 VidPN topology is invalid. STATUS-NO-MEMORY indicate that miniport could not
allocate a buffer to fit in the requested enumeration.
Table 55 - Function EnumCofuncVidPNTargetIDSet
typedef NTSTATUS
(APIENTRY *PFND3DKMDDIIENUMCOFUNCVIDPNTARGETIDSET)
rn Er'4NDLE hAdapter,
IN OUT D3DIEO-PRESENT-TARGET-ID) * (# of cofimctional video present targets - 1).
15 Once the memory for the output parameter has been allocated, the miniport can
populate it based on the definitions below:
typedef struct -D3DKMDDIIVIDEOVIDPRESENT-TARGET-IDIDSET
(
. SEET NumOfVidPNTargetIDs;
20 D3DKMDDI-WE0-P~SENTSENTTARGETETD VideoPresentTargetlDs[l];
I
- 130 -
D3DWDI-VIDEO-PRESENT-TARGET-ID-SET;
with:
NumOfVidPNTargetIDs specifying the number of video present targets' IDS
listed in VideoPresentTargetIDs.
5 VideoPresentSourcelDs representing the array of video present targets' IDS in
the set.
On successful return fiom this function, the operating system can take ownership
of the lifetime of the data returned in the output parameter and can deallocate the
memory taken by its supporting allocation when it is done with it.
10 Returncodes
STATUS-SUCCESS indicates that the driver handled the call successfully.
STATUS-GRAPHICS-INVALIDIDVIDPNNTOPOLOGiYnd icates that the specified
VidPN topology is invalid.
STATUS-NO-MEMORY indicates that the miniport could not allocate a buffer to fit
15 in the requested enumeration.
Table 56 - Function EnurnVidPNCofuncModality
typedef NTSTATUS
(APENTRY *PFND3DKMDDII~PNCOFUNCMODALrry)
W H.mDLJ3 hAdapter,
IN OUT D3DKMDDIARGGENUMVIDPNCOFUNCMODALITY* pEnumVidPNCofuncMdityArg);
typedef struct -D3DKMDDIARGctENUMVIDPNCOFUNCMODALITY
(
IN D3DKMDDI-VIDPN* pConsh.8iningVidPN;
OUT D3DKMDDI-VIDPNPNPRESENTENTPATHTHpSVEiTdP*N PresentPathSetWithCofuncModeSets;
1
D3DKh4DDIARGGJ3WMVDPNCOFUNCMODALITY;
20 EnurnVidPNCofuncModality lets the operating system enumerate cofunctional
video present and target mode sets on each video present path in the specified VidPN,
where:
pConstrainingVidPN is the VidPN with respect to which cofimctional mode sets
on VidPN's targets and sources are being sought.
pVidPNPresentPathSetWithCofuncModeSets is the set of VidPN present paths
where each sourceltarget is populated with mode sets cofunctional to the
constraining VidPN. If any sourcesltargets of the constraining VidPN have modes
pinned on them, their indices should be properly updated in the respective VidPN
sourceltarget descriptor in the result set.
The miniport should populate:
pVi~ntPath->VideoPresentSource.pCofimcVidPNSo~~~eModeSet->VidPNSourceModes[l..n]
10 and
pVi~ntPath->VideoPresentTargetpCofUncVidmJT~~getModeSet->VidPNTargetMode.sm[]1 .
where:
-
15 On successful return from this function, the operating system can take ownership
of the lifetime of the data returned in the output parameter and can deallocate the
memory taken by its supporting allocation when it is done with it.
Return Codes
STATUS-SUCCESS indicates that the driver handled the call successfully.
20 STATUS-NO-MEMORY indicate that miniport could not allocate a buffer to fit in the
requested enumeration.
Table 57 - Function RecommendFunctionalVidPN
typedef NTSTATUS
(MIENTRY *PFND3DKMDDIIRECO-FLMCTIONALVIDar)
W E J ~ ~ D L E Mdapter,
IN OUT D3DKMDDIARG-RW:O~~CTIONALVIDPN* pRecommendFunctidVidPNArg);
typedef struct -D3DKMDDIARGGRECO~FLMCTIONALVIDPN
{
IN UINT NumbexOfMonitors;
IN D3DKMDDI-Wm-PRESENT-TARGETID* pVidIWTar@rioritizationVector,
OUT D3DKMDDI-VIDPN* pRecomrnendedFunctionalVidPN;
I
D3DKMDDIARG-RECO~FLMCrrONALVIDPN;
5 RecomendFunctionalVidPN lets the operating system query for a VidPN
recommended by the miniport, given the current state of the Ww. The operating system
may use it in case it encounters a configuration where no user preference (e.g., last-used
modality) has been specified. As part of this request, the operating system specifies to
the miniport a vector of VidPN targets IDS, pVidPNTargetPrioritizationVector
10 ordered most important first, representing the relative importance of monitors connected
to them. In turn, the miniport should allocate sufficient memory to populate the
functional VidPN it wishes to recommend to the operating system for the current state of
the hlw, populate the respective fields, and assign its address to
pRecommendedFunctionalVidPN. On successful return fiom this function, the
15 operating system can take ownership of the lifetime of the data returned in the output
parameter and can deallocate the memory taken by its supporting allocation when it is
done with it.
Return Codes
STATUS-SUCCESS indicates that the driver handled the call successfully.
STATUS-GRAPHICSCNOORECOMMENDEDNVIDPNin dicates that miniport has
no VidPN recommendation for the current configuration of the display adapter.
5 STATUS-NO-MEMORY indicates that the miniport could not allocate a buffer to fit
in the requested enumeration.
Example 49 - Exemplary DeviceSpecific Part of Video Rendering Device Driver
Any of the technologies described herein can be implemented in the device-
10 specific part of a video rendering device driver. A reusable portion of the driver can be
shared across video rendering device drivers.
For example, in an implementation carried out in the MICROSOFT@
WINDOWS@ operating system, the video port can serve as the reusable portion of the
driver, and a video miniport can serve as the device-specific part of the video rendering
15 device driver.
Exemplary Advantages
Multi-monitor display mode management is a complex problem that deals with
capabilities of video renderinglpresenting devices (e.g., yideo cards also known as
20 graphics adapters) and video monitoring devices (e.g., monitors). A main issue causing
complexity in display mode management is an inherent interdependency among
capabilities of graphics display device objects (e.g., MICROSOFT@ WINDOWS@ GDI
objects), each representing a separate (view, ouput) mapping on a single multi-output
video card, which is not dealt with well by the legacy display mode management
25 architecture.
These interdependencies arise primarily ftom: (1) possible contention for video
output codecs on systems having more video outputs than codecs that can drive them;
(2) the multitude of ways to satisfy a request for establishment of any given multi-output
video presenting configktion within a given video card, largely due to: (a) differences
in capabilities of video output codecs present in a video card; (b) a video card's ability to
use video output codecs with various video outputs through the use of cross-bars that
5 can route any video output codec to any compatible video output; (c) a video card's
ability to share video output codecs for multiple video outputs in cases where video
output codecs are a scarce resource (e-g., less than the number of video outputs to be
driven); (d) a video card's ability to use multiple video output codecs or a single multiinput
video output codec for a single video output (e.g., overlays), in cases where
10 tampering with one of the video streams cannot be tolerated or where a video stream on
which a secondary signal needs to be overlaid is already in an analog format and
decoding it just to add a digital overlay and then remodulate it is wasteful; (3) contention
for video memory bus bandwidth by utilized video output codecs, each of which is
responsible for converting content of associated primary surface(s) into a video signal on
15 the respective video output interface, which ultimately is reduced to periodic video
memory reads; or (4) contention for video memory capacity by the primary surfaces
required to support a given video present path (e.g., a logical path from the rendered
digital content to the physical video interface output).
As such, above-mentioned interdependencies between available display mode
20 sets of (view, output) pairs are more intricate than just on a (view, output) pair basis.
Specifically, choosing to use a given primary surface format on a view may affect what
video signal can be presented on the respective output. Also, when considering
scenarios where a single view is presented on multiple outputs, the set of available video
signals changes based on how and which video output codecs are used to implement the
25 resulting present configuration. Finally, when considering scenarios where multiple
views are employed on a single video card (each potentially presented to multiple
outputs), available video signals change based on association between the various views
and the outputs. That is, what video signals a video card can drive on its outputs is a
function of what types of primary surfaces it is asked to present and in what fashion
should they be presented (e.g., to what outputs).
Furthermore, designs might not take into account the scaling capability of
5 contemporary video cards, which are able to up- or down-sample a given primary
surface content to a different spatial resolution to be driven on the respective video
output. As such, two main abstractions that may be made with respect to multi-output
video cards are: (1) a simplified view of a multi-function display device abstraction that
includes both the video card and the monitor, represented in a unified "display mode"
10 descriptor modality, which contains states of two distinct physical devices; and (2)
extension of a single-output mode enumeration to multiple outputs, which can be
achieved via duplication of independent video driver stacks and respective graphics
devices, one per (view, output). These abstractions are not sufficient to properly drive
such devices and may be superseded with: (1) distinct modality descriptors for views and
15 outputs; (2) one video driver stack per video card, which hosts a video miniport that
exposes a capability-balancing DDI that lets a client pin the modes it desires and reenumerate
an updated set of available modes, ultimately converging on a functional
solution in a series of iterations (e.g., graph search); and (3) augmentation of an
implementation to support display mode interdependencies, resulting available mode set
20 invalidations, and mode change failures.
Alternatives
The technologies fiom any example can be combined with the technologies
described in any one or more of the other examples. In view of the many possible
25 embodiments to which the principles of the invention may be applied, it should be
recognized that the illustrated embodiments are examples of the invention and should
not be taken as a limitation on the scope of the invention. Rather, the scope of the
invention includes what is covered by the following claims. We therefore claim as our
invention all that comes within the scope and spirit of these claims.

CLAIMS
We claim:
1. One or more computer-readable media having computer-executable
instructions for implementing a programmatic interface, the interface providing
5 access to the following services:
receiving an indication of a provisional configuration for a video
presenting network; and
enumerating configuration options co-functional with the provisional
configuration.
10
2. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumerating a plurality of video presenting network sources co-functional
with the provisional configuration.
15
3. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumerating a plurality of video present source modes co-functional with
the provisional configuration.
20
4. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumerating a plurality of video presenting network targets co-functional
with the provisional configuration.
25
5. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumerating a plurality of video present target modes co-functional with
the provisional configuration.
6. The one or more computer-readable media of claim 3, the interface
5 further providing access to the following service:
pinning one of the plurality of video present source modes on at least one
video presenting'network source.
7. The one or more computer-readable media of claim 6, the interface
10 further providing access to the following service:
enumerating a plurality of video present target modes co-functional with
the provisional configuration after the pinning of the one of the plurality of video
present source modes.
15 8. The one or more computer-readable media of claim 6, the interface
further providing access to the following service:
unpinning the one of the plurality of video present source modes.
9. The one or more computer-readable media of claim 8, the interface
20 firther providing access to the following service:
enumerating a plurality of video present source modes co-functional with
the provisional configuration after the unpinning of the one of the plurality of
video present source modes. -
10. The one or more computer-readable media of claim 5, the interface
further providing access to the following service:
pinning one of the plurality of video present target modes on at least one
video presenting network target.
5
1 1. The one or more computer-readable media of claim 10, the
interface further providing access to the following service:
enumerating a plurality of video present target modes co-functional with
the provisional configuration after the pinning of the one of the plurality of video
10 present target modes.
12. The one or more computer-readable media of claim 10, the
interface further providing access to the following service:
unpinning the one of the plurality of video present target modes.
13. The one or more computer-readable media of claim 12, the
interface further providing access to the following service:
enumerating a plurality of video present target modes co-functional with
the provisional configuration after the unpinning of the one of the plurality of
20 video present target modes. .
14. The one or more computer-readable media of claim 1, the interface
further providing access to the following service:
committing a functional video presenting network configuration.
15. One or more computer-readable media having computer-executable
instructions for accessing a programmatic interface, the interface providing
access to the following services:
receiving an indication of a provisional configuration for a video
5 presenting network; and
enumerating configuration options co-functional with the provisional
configuration.
16. The one or more computer-readable media of claim 15, wherein the
10 enumerating comprises:
enumerating a plurality of video present target modes co-functional with
the provisional configuration.
17. The one or more computer-readable media of claim 16, the
15 interface fiuther providing access to the following service:
pinning one of the plurality of video present target modes on at least one
video presenting network target.
18. A method of finding a configuration of a configurable video
20 presenting network comprising a plurality of video targets, the method .
comprising:
receiving a series of partial configurations for the video presenting
network to build a provisional functional configuration; and
committing the provisional functional configuration, wherein the
25 committing implements the provisional functional configuration in the video
presenting network.
19. The method of claim 18 further comprising:
prior to the committing, receiving an indication to remove at least one of
the partial configurations fiom the provisional functional configuration.
5 20. One or more computer-readable media having computer-executable
instructions for performing the method of claim 18.
2 1. A method of configuring a video presenting network comprising a
plurality of resources and comprising a plurality of outputs, the method
10 comprising:
accepting an indication of a partial configuration of the video presenting
network, wherein the partial configuration comprises an indication of a
configuration for a fust resource out of the plurality of resources of the video
presenting network;
15 based on interdependencies between the plurality of resources of the video
presenting network, determining one or more configuration options for a second
resource out of the resources of the video presenting network that are cofunctional
with the indication of the partial configuration of the video presenting
network; and
20 indicating the co-functional configuration options for the second resource.
22. The method of claim 21 wherein:
the accepting is performed by a video driver;
the determining is performed by the video driver; and
25 the indicating is performed by the video driver.
23. The method of claim 22 wherein:
the video driver comprises a video miniport;
the accepting is performed by the video miniport;
the determining is performed by the video miniport; and
the indicating is performed by the video miniport.
24. The method of claim 21 wherein:
the indicating is performed in response to a programmatic call to an
enumeration function of a device driver interface.
10
25. The method of claim 21 wherein:
the indicating indicates co-functional configuration options for the
plurality of resources of the video presenting network.
26. The method of claim 21 wherein:
the fmt resource is in a first video path of the video presenting network;
and
the second resource is in a second video path of the video presenting
network.
20
27. The method of claim 21 wherein:
the partial configuration of the video presenting network indicates a
configuration for one out of a plurality of video inputs of the video presenting
network.
25
28. The method of claim 21 wherein:
the partial configuration of the video presenting network indicates a
configuration for one out of the plurality of video outputs of the video presenting
network.
5
29. The method of claim 21 wherein:
the partial configuration of the video presenting network indicates a
configuration for one out of a plurality of digital-video-input-representation-tovideo-
output-signal converters of the video presenting network.
10
30. The method of claim 29 wherein:
the digital-video-input-representation-to-video-output-signal converter
comprises a video codec.
3 1. The method of claim 29 wherein:
the d i g i t a l - v i d e o - i n p u t - r e p r e s e n t a t i o n - t o - v converter
comprises a digital-to-analog converter.
32. The method of claim 21 wherein:
20 the first resource comprises an input of the video presenting network; and
the second resource comprises an output of the video presenting network.
3 3. The method of claim 2 1 wherein:
the partial configuration of the video presenting network indicates a
25 topology for the video presenting network.
34. The method of claim 21, wherein:
the partial configuration of the video presenting network indicates a
mapping fiom a video adapter output to a video device.
5 35. One or more computer-readable media having computer-executable
instructions for performing the method of claim 2 1.
36. A method of configuring a video presenting network comprising
video sources and video targets, the method comprising:
10 selecting a topology for the video presenting network;
enumerating co-functional options for the video sources;
fiom among the co-functional options for the video sources, pinning
options for the video sources;
enumerating co-functional options for the video targets; and
fiom among the co-functional options for the video targets, pinning
options for the video targets.
37. The method of claim 36 wherein:
the co-functional options for the video sources are co-functional with
20 respect to the topology; and
the co-functional options for the video targets are co-functional with
respect to the topology and co-functional with respect to the pinned options for
the video sources.
38. The method of claim 36 wherein pinning options for the video
sources comprises:
pinning an option for a first video source, wherein the pinning invalidates
a configuration option for a second video source;
5 determining that the configuration option for the second video source has
been invalidated; and
unpinning the option for the first video source responsive to determining
that the configuration option for the second video source has been invalidated.
10 39. The method of claim 36 further comprising:
responsive to determining a desired option is not among the co-functional
options for the video sources, choosing a different topology.
40. The method of claim 36 further comprising:
15 responsive to determining a desired option is not among the co-functional
options for the video targets, choosing a different topology.
41. The method of claim 36 further comprising:
responsive to determining a desired option is not among the co-functional
20 options for the video targets, choosing a different option for at least one of the
video sources.
42. One or more computer-readable media having computer-executable
instructions for performing the method of claim 36.
43. One or more computer-readable media having encoded thereon
computer-executable instructions implementing a video driver operable to
configwe a video presenting network comprising a plurality of resources
5 comprising a plurality of outputs, the video driver comprising:
logic operable to accept an indication of a partial configuration of the
video presenting network, wherein the partial configuration comprises an
indication of a configuration for a first resource out of the plurality of resources
of the video presenting network;
10 logic operable to, based on interdependencies between the plurality of
resources of the video presenting network, determine one or more configuration
options for a second resource out of the plurality of resowces of the video
presenting network that are co-functional with the indication of the partial
configuration of the video presenting network; and
15 logic operable to indicate the co-functional configuration options for the
second resource.
44. One or more computer-readable media having computer-executable
instructions for performing a method of determining a topology for a video
20 presenting network, the method comprising:
starting with an initial topology; and
based on a goal stated in terms of video modes supported by monitors,
modifying the initial topology to better meet the goal.
45. The one or more computer-readable media of claim 44, wherein the
modifying comprises generating a provisional functional configuration better
meeting the goal.
46. The one or more computer-readable media of claim 44, wherein the
modifying accounts for interdependencies among resources of the video
presenting network.
5
47. The one or more computer-readable media of claim 44, wherein the
goal comprises a best way to route video present targets to video present sources .
in the video presenting network through available video output codecs to
maximize supported graphics video present source mode sets on video present
10 sources, given that video mode sets on the video present targets must support
preferred modes on video display devices connected to them.
48. The one or more computer-readable media of claim 44, wherein the
goal comprises a best way to route video present targets to video present sources
15 in the video presenting network through available video output codecs to
maximize supported graphics video present source mode sets on video present
sources, given that video mode sets on the video present targets must support
preferred modes on video display devices connected to them in a specified
prioritization ordering.
20
49. The one or more computer-readable media of claim 44, wherein the
goal comprises a best way to route video present targets to video present sources
in the video presenting network through available video output codecs to
maximize supported graphics video present source mode sets on video present
25 sources, given that video mode sets on the video present targets must support at
least one of video mode supported by video display devices connected to them.
50. The one or more computer-readable media of claim 44, wherein
modifying the initial topology comprises enumerating a plurality of video modes
available to a plurality of video outputs.
5 5 1. The one or more computer-readable media of claim 50, wherein
modifLing the initial topology further comprises pinning at least one of the
plurality of video modes on at least one of the plurality of video outputs.
52. The one or more computer-readable media of claim 5 1, wherein
10 modifLing the initial topology further comprises enumerating a plurality of
rendering modes available to a plurality of render targets.
53. The one or more computer-readable media of claim 52, wherein
modifying the initial topology further comprises pinning at least one of the
15 plurality of rendering modes on one of the plurality of render targets.
54. The one or more computer-readable media of claim 53, wherein
modifying the initial topology further comprises unpinning the at least one of the
plurality of rendering modes pinned on the one of the plurality of render targets.
20
55. The one or more computer-readable media of claim 54, wherein
modifying the initial topology further comprises pinning an other of the plurality
of rendering modes on the one of the plurality of render targets.
56. A method of determining a video configuration satisfying a
prioritized list of desired video configuration options, the method comprising:
based on the prioritized list, submitting a partial video configuration for at
least a first resource;
5 receiving a list of configuration options co-fbnctional with the partial
video configuration;
determining whether a desired option in the prioritized list is present in the
list of configuration options co-functional with the partial video configuration;
and
10 responsive to determining the desired option is not present, re-submitting
a modified partial configuration for the first resource.
57. The method of claim 56, wherein the video configuration indicates
configuration of a video presenting network.
15
58. The method of claim 57, wherein the list indicates desired
configuration options for the video presenting network.
59. One or more computer-readable media having computer-executable
20 instructions for performing the method of claim 56.
60. In one or more computer-readable media, a video rendering device
driver comprising:
means for obtaining a first video presenting network configuration
provisional configuration having a plurality of video outputs, a plurality of render
5 targets, and at least one video output to render target association; and
means for replacing the first video presenting network configuration
provisional configuration with a second video presenting network configuration
provisional configuration.
10 61. The video rendering device driver of claim 60, further comprising
means for disposing of the fmt video presenting network configuration
provisional configuration.
62. The video rendering device driver of claim 60, wherein the means
15 for replacing the first video presenting network configuration provisional
configuration comprises means for setting video mode constraints on each of a
plurality of enumenited video outputs.
63. The video rendering device driver of claim 60, wherein the means
20 for replacing the first video presenting network configuration provisional
configuration comprises means for creating the second video presenting network
configuration provisional configuration.
64. A method, comprising:
querying a hdeo driver for a video output configuration that supports a
plurality of video modes on at least one video output in the video output
5 configuration;
provisionally configuring one of the plurality of video modes on the at
least one video output in the video output configuration; and
provisionally configuring one of a plurality of render modes on at least
one render target in the video output configuration.
10
65. The method of claim 64, wherein provisionally configuring one of
the plurality of video modes comprises enumerating a plurality of available video
modes on the at least one video output.
66. The method of claim 65, wherein provisionally configuring one of
the plurality of video modes further comprises selecting a first video mode and
selecting a second video mode such that the first video mode is valid before and
after selecting the second video mode.
67. The method of claim 64, wherein provisionally configuring one of
the plurality of render modes comprises enumerating a plurality of available
render modes on the at least one render target.
68. The method of claim 67, wherein provisionally configuring one of
the plurality of render modes further comprises selecting a first render mode and
selecting a second render mode such that the fmt render mode is valid before and
after selecting the second render mode.
5
69. The method of claim 64, fhther comprising committing the video
output configuration.
70. One or more computer-readable media having computer-executable
10 instructions for performing the method of claim 64.
7 1. A method of configuring a configurable video presenting network
comprising a plurality of video outputs, the method comprising:
receiving an indication of a configuration of a video input of the video
15 presenting network;
separately fiom receiving the indication of the configuration of the video
input, receiving an indication of a configuration of a video output out of the
plurality of video outputs; and
configuring the video presenting network according to the indication of
20 the configuration of the video output and the indication of the configuration of
the video input.
72. The method of claim 71 further comprising:
separately fiom receiving the indication of the configuration of the video
input and separately f?om receiving the indication of the configuration of the
video output, receiving an indication of a configuration of a video-input-to-
5 output converter of the video presenting network.
73. The method of claim 71 wherein:
the indication of the configuration of the video output is received in a first
device driver interface call; and
10 the indication of the configuration of the video input is received in a
second device driver interface call.
74. The method of claim 71 wherein:
the indication of the configuration of the video output is received in a first
15 call to a device driver; and
the indication of the configuration of the video input is received in a
second call to the device driver.
75. The method of claim 71 wherein:
20 - the indication of the configuration of the video output is sent by an
operating system; and
the indication of the configuration of the video input is sent by the
operating system.
76. The method of claim 71 further comprising:
in response to receiving the indication of the configuration of the video
input of the video presenting network, indicating a set of additional possible
configuration optipns for the video presenting network, wherein the additional
5 possible configuration options are restricted to those co-functional with the
indication of the configuration of the video input of the video presenting
network.
77. Thelmethod of claim 76 wherein:
10 a device driver determines which options are co-functional with the
indication of the configuration of the video input of the video presenting
network.
78. The method of claim 76 wherein:
15 at least one configuration option of the video presenting network is not cofunctional
with the indication of the configuration of the video input of the video
presenting network.
79. One or more computer-readable media having computer-executable
20 instructions for pe'rforming the method of claim 71.
80. A method of managing configuration of a configurable video
presenting network comprising a pIurality of video paths, the method
comprising:
5 sending an indication of a partial video presenting network configuration,
wherein the partial video presenting network configuration indicates at least
configuration for a resource in a first video path in the video presenting network;
and
responsive to sending the indication of the partial video presenting
10 network configuration, receiving a set of possible configuration options for a
resource of the video presenting network in a second video path of the video
presenting network, wherein the configuration options for the resource are
restricted based on the indication of the partial video presenting network to
options that do not invalidate the partial video presenting network configuration
15 when selected; and
sending an'indication of at least one of the possible configuration options.
8 1. The:method of cl* 80, hufher comprising committing the at least
one of the possible configuration options.
20
82. The.method of claim 80, further comprising changing'the
indication of the at least one of the possible configuration options.
83. One or more computer-readable media having computer-executable
25 instructions for performing the method of claim 80.

We claim:
1. One or more computer-readable media having computer-executable
instructions for implementing a programmatic interface, the interface providing
access to the following services:
receiving an indication of a provisional configuration for a video presenting network; and
enumerating configuration options co-fimctional with the provisional configuration.
2. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumerating a plurality of video presenting network sources co-functional with the provisional configuration.
3. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumerating a plurality of video present source modes co-fimctional with the provisional configuration.
4. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumeratmg a plurality of video presenting network targets co-fimctional with the provisional configuration.
5. The one or more computer-readable media of claim 1, wherein the
enumerating comprises:
enumerating a plurality of video present target modes co-functional with the provisional configuration.
6. The one or more computer-readable media of claim 3, the interface
further providing access to the following service:
pinning one of the plurality of video present source modes on at least one video presenting network source.
7. The one or more computer-readable media of claim 6, the interface
further providing access to the following service:
enumerating a plurality of video present target modes co-functional with the provisional configuration after the pinning of the one of the plurality of video present source modes.
8. The one or more computer-readable media of claim 6, the interface
further providing access to the following service:
unpinning the one of the plurality of video present source modes.
9. The one or more computer-readable media of claim 8, the interface
further providing access to the following service:
enumerating a plurality of video present source modes co-functional with the provisional configuration after the unpinning of the one of the plurality of video present source modes.
10. The one or more computer-readable media of claim 5, the interface further providing access to the following service:
pinning one of the plurality of video present target modes on at least one video presenting network target.
11. The one or more computer-readable media of claim 10, the
interface further providing access to the following service:
enumerating a plurality of video present target modes co-fimctional with the provisional configuration after the pinning of the one of the plurality of video present target modes.
12. The one or more computer-readable media of claim 10, the
interface further providing access to the following service:
unpinning the one of the plurality of video present target modes.
13. The one or more computer-readable media of claim 12, the
interface further providing access to the following service:
enumerating a plurality of video present target modes co-functional with the provisional configuration after the unpinning of the one of the plurality of video present target modes.
14. The one or more computer-readable media of claim 1, the interface
further providing access to the following service:
committing a functional video presenting network configuration.
15. One or more computer-readable media having computer-executable
instructions for accessing a programmatic interface, the interface providing
access to the following services:
receiving an indication of a provisional configuration for a video presenting network; and
enumerating configuration options co-functional with the provisional configuration.
16. The one or more computer-readable media of claim 15, wherein the
enumerating comprises:
enumerating a plurality of video present target modes co-functional with the provisional configuration.
17. The one or more computer-readable media of claim 16, the
interface further providing access to the following service:
pinning one of the plurality of video present target modes on at least one video presenting network target.
18. A method of finding a configuration of a configurable video
presenting network comprising a plurality of video targets, the method
comprising:
receiving a series of partial configurations for the video presenting network to build a provisional fimctional configuration; and
committing the provisional fimctional configuration, wherein the committing implements the provisional fimctional configuration m the video presenting network.
19. The method of claim 18 further comprising:
prior to the committing, receiving an indication to remove at least one of the partial configurations from the provisional functional configuration.
20. One or more computer-readable media having computer-executable instructions for performing the method of claim 18.
21. A method of configuring a video presenting network comprising a plurality of resources and comprising a plurality of outputs, the method comprising:
accepting an indication of a partial configuration of the video presenting network, wherein the partial configuration comprises an indication of a configuration for a first resource out of the plurality of resources of the video presenting network;
based on interdependencies between the plurality of resources of the video presenting network, determining one or more configuration options for a second resource out of the resources of the video presenting network that are co-functional with the indication of the partial configuration of the video presenting network; and
indicating the co-fiinctional configuration options for the second resource.
22. The method of claim 21 wherein:
the accepting is performed by a video driver;
the determining is performed by the video driver; and
the indicating is performed by the video driver.
23. The method of claim 22 wherein:
the video driver comprises a video miniport;
the accepting is performed by the video miniport;
the determining is performed by the video miniport; and
the indicating is performed by the video miniport.
24. The method of claim 21 wherein:
the indicating is performed in response to a programmatic call to an enumeration fimction of a device driver interface.
25. The method of claim 21 wherein:
the indicating indicates co-functional configuration options for the plurality of resources of the video presenting network.
26. The method of claim 21 wherein:
the first resource is in a first video path of the video presenting network; and
the second resource is in a second video path of the video presenting network.
27. The method of claim 21 wherein:
the partial configuration of the video presenting network indicates a configuration for one out of a plurality of video inputs of the video presenting network.
28. The method of claim 21 wherein:
the partial configuration of the video presenting network indicates a configuration for one out of the plurality of video outputs of the video presenting network.
29. The method of claim 21 wherein:
the partial configuration of the video presenting network indicates a configuration for one out of a plurality of digital-video-input-representation-to-video-output-signal converters of the video presenting network.
30. The method of claim 29 wherein:
the digital-video-input-representation-to-video-output-signal converter comprises a video codec.
31. The method of claim 29 wherein:
the digital-video-input-representation-to-video-output-signal converter comprises a digital-to-analog converter.
32. The method of claim 21 wherein:
the first resource comprises an input of the video presenting network; and the second resource comprises an output of the video presenting network.
33. The method of claim 21 wherein:
the partial configuration of the video presenting network indicates a topology for the video presenting network.
34. The method of claim 21, wherein:
the partial configuration of the video presenting network indicates a mapping from a video adapter output to a video device.
35. One or more computer-readable media having computer-executable instructions for performing the method of claim 21.
36. A method of configuring a video presenting network comprising video sources and video targets, the method comprising:
selecting a topology for the video presenting network;
enumerating co-functional options for the video sources;
fi-om among the co-fimctional options for the video sources, pinning options for the video sources;
enumerating co-fimctional options for the video targets; and
fi-om among the co-fimctional options for the video targets, pinning options for the video targets.
37. The method of claim 36 wherein:
the co-fimctional options for the video sources are co-fimctional with respect to the topology; and
the co-fimctional options for the video targets are co-fimctional with respect to the topology and co-fimctional with respect to the pinned options for the video sources.
38. The method of claim 36 wherein pinning options for the video
sources comprises:
pinning an option for a first video source, wherein the pinning invalidates a configuration option for a second video source;
determining that the configuration option for the second video source has been invalidated; and
unpinning the option for the first video source responsive to determining that the configuration option for the second video source has been invalidated.
39. The method of claim 36 further comprising:
responsive to determining a desired option is not among the co-fiinctional options for the video sources, choosing a different topology.
40. The method of claim 36 fiirther comprising:
responsive to determining a desired option is not among the co-functional options for the video targets, choosing a different topology.
41. The method of claim 36 fiirther comprising:
responsive to determining a desired option is not among the co-fiinctional options for the video targets, choosing a different option for at least one of the video sources.
42. One or more computer-readable media having computer-executable
instructions for performing the method of claim 36.
43. One or more computer-readable media having encoded thereon computer-executable instructions implementing a video driver operable to configure a video presenting network comprising a plurality of resources comprising a plurality of outputs, the video driver comprising:
logic operable to accept an indication of a partial configuration of the video presenting network, wherein the partial configuration comprises an indication of a configuration for a first resource out of the plurality of resources of the video presenting network;
logic operable to, based on interdependencies between the plurality of resources of the video presenting network, determine one or more configuration options for a second resource out of the plurality of resources of the video presenting network that are co-fiinctional with the indication of the partial configuration of the video presenting network; and
logic operable to indicate the co-functional configuration options for the second resource.
44. One or more computer-readable media having computer-executable
instructions for performing a method of determining a topology for a video
presenting network, the method comprising:
starting with an initial topology; and
based on a goal stated in terms of video modes supported by monitors, modifying the initial topology to better meet the goal.
45. The one or more computer-readable media of claim 44, wherein the
modifying comprises generating a provisional functional configuration better
meeting the goal.
46. The one or more computer-readable media of claim 44, wherein the modifying accounts for interdependencies among resources of the video presenting network.
47. The one or more computer-readable media of claim 44, wherein the goal comprises a best way to route video present targets to video present sources in the video presenting network through available video output codecs to maximize supported graphics video present source mode sets on video present sources, given that video mode sets on the video present targets must support preferred modes on video display devices connected to them.
48. The one or more computer-readable media of claim 44, wherein the goal comprises a best way to route video present targets to video present sources in the video presenting network through available video output codecs to maximize supported graphics video present source mode sets on video present sources, given that video mode sets on the video present targets must support preferred modes on video display devices connected to them in a specified prioritization ordering.
49. The one or more computer-readable media of claim 44, wherein the goal comprises a best way to route video present targets to video present sources in the video presenting network through available video output codecs to maximize supported graphics video present source mode sets on video present sources, given that video mode sets on the video present targets must support at least one of video mode supported by video display devices connected to them.
50. The one or more computer-readable media of claim 44, wherein modifying the initial topology comprises enumerating a plurality of video modes available to a plurality of video outputs.
51. The one or more computer-readable media of claim 50, wherein modifying the initial topology fiirther comprises pinning at least one of the plurality of video modes on at least one of the plurality of video outputs.
52. The one or more computer-readable media of claim 51, wherein modifying the initial topology further comprises enumerating a plurality of rendering modes available to a plurality of render targets.
53. The one or more computer-readable media of claim 52, wherein modifying the initial topology fiirther comprises pinning at least one of the plurality of rendering modes on one of the plurality of render targets.
54. The one or more computer-readable media of claim 53, wherein modifying the initial topology fiirther comprises unpinning the at least one of the plurality of rendering modes pinned on the one of the plurality of render targets.
55. The one or more computer-readable media of claim 54, wherein modifying the initial topology fiirther comprises pinning an other of the plurality of rendering modes on the one of the plurality of render targets.
56. A method of determining a video configuration satisfying a
prioritized list of desired video configuration options, the method comprising:
based on the prioritized list, submitting a partial video configuration for at least a first resource;
receiving a list of configuration options co-functional with the partial video configuration;
determining whether a desired option in the prioritized list is present in the list of configuration options co-fimctional with the partial video configuration; and
responsive to determining the desired option is not present, re-submitting a modified partial configuration for the first resource.
57. The method of claim 56, wherein the video configuration indicates configuration of a video presenting network.
58. The method of claim 57, wherein the list indicates desired configuration options for the video presenting network.
59. One or more computer-readable media having computer-executable instructions for performing the method of claim 56.
60. In one or more computer-readable media, a video rendering device
driver comprising:
means for obtaming a first video presenting network configuration provisional configuration having a plurality of video outputs, a plurality of render targets, and at least one video output to render target association; and
means for replacing the first video presenting network configuration provisional configuration with a second video presenting network configuration provisional configuration.
61. The video rendering device driver of claim 60, further comprising means for disposing of the first video presenting network configuration provisional configuration.
62. The video rendering device driver of claim 60, wherein the means for replacing the first video presenting network configuration provisional configuration comprises means for setting video mode constraints on each of a plurality of enumerated video outputs.
63. The video rendering device driver of claim 60, wherein the means for replacing the first video presenting network configuration provisional configuration comprises means for creating the second video presenting network configuration provisional configuration.
64. A method, comprising:
querying a video driver for a video output configuration that supports a plurality of video modes on at least one video output in the video output configuration;
provisionally configuring one of the plurality of video modes on the at least one video output in the video output configuration; and
provisionally configuring one of a plurality of render modes on at least one render target in the video output configuration.
65. The method of claim 64, wherein provisionally configuring one of the plurality of video modes comprises enumerating a plurality of available video modes on the at least one video output.
66. The method of claim 65, wherein provisionally configuring one of the plurality of video modes fiirther comprises selecting a first video mode and selecting a second video mode such that the first video mode is valid before and after selecting the second video mode.
67. The method of claim 64, wherein provisionally configuring one of the plurality of render modes comprises enumerating a plurality of available render modes on the at least one render target.
68. The method of claim 67, wherein provisionally configuring one of the plurality of render modes fiirther comprises selecting a first render mode and selecting a second render mode such that the first render mode is valid before and after selecting the second render mode.
69. The method of claim 64, fiirther comprising committing the video output configuration.
70. One or more computer-readable media having computer-executable instructions for performing the method of claim 64.
71. A method of configuring a configurable video presenting network comprising a plurality of video outputs, the method comprising:
receiving an indication of a configuration of a video input of the video presenting network;
separately fi-om receiving the indication of the configuration of the video input, receiving an indication of a configuration of a video output out of the plurality of video outputs; and
configuring the video presenting network according to the indication of the configuration of the video output and the indication of the configuration of the video input.
72. The method of claim 71 further comprising:
separately from receiving the indication of the configuration of the video input and separately from receiving the indication of the configuration of the video output, receiving an indication of a configuration of a video-input-to-output converter of the video presenting network.
73. The method of claim 71 wherein:
the indication of the configuration of the video output is received in a first device driver interface call; and
the indication of the configuration of the video input is received in a second device driver interface call.
74. The method of claim 71 wherein:
the indication of the configuration of the video output is received in a first call to a device driver; and
the indication of the configuration of the video input is received in a second call to the device driver.
75. The method of claim 71 wherein:
the indication of the configuration of the video output is sent by an operating system; and
the indication of the configuration of the video input is sent by the operating system.
76. The method of claim 71 further comprising:
in response to receiving the indication of the configuration of the video input of the video presenting network, indicating a set of additional possible configuration options for the video presenting network, wherein the additional possible configuration options are restricted to those co-functional with the indication of the Configuration of the video input of the video presenting network.
77. The method of claim 76 wherein:
a device driver determines which options are co-functional with the indication of the configuration of the video input of the video presenting network.
78. The method of claim 76 wherein:
at least one configuration option of the video presenting network is not co-functional with the indication of the configuration of the video input of the video presenting network.
79. One or more computer-readable media having computer-executable
instructions for peirforming the method of claun 71.
80. A method of managing configuration of a configurable video presenting network comprising a plurality of video paths, the method comprising:
sending an indication of a partial video presenting network configuration, wherein the partial video presenting network configuration indicates at least configuration for a resource in a first video path in the video presenting network; and
responsive to sending the indication of the partial video presenting network configuration, receiving a set of possible configuration options for a resource of the video presenting network in a second video path of the video presenting network, wherein the configuration options for the resource are restricted based on the indication of the partial video presenting network to options that do not invalidate the partial video presenting network configuration when selected; and
sending an indication of at least one of the possible configuration options.
81. The method of claim 80, fiirther comprising committing the at least one of the possible configuration options.
82. The method of claim 80, further comprising changing the indication of the at least one of the possible configuration options.
83. One or more computer-readable media having computer-executable instructions for performing the method of claim 80.