Apparatus, systems, and methods for real-time video switching in extended environments

Abstract

Extension devices, such as upstream-facing port devices (UFP devices) and downstream-facing port devices (DFP devices), are connected via extension media. When a UFP device and a DFP device are paired, DisplayPort video and / or audio information from a DisplayPort source device can be presented by a DisplayPort sink device, which is connected to the UFP device and the DFP device, respectively. In some embodiments, the DFP device can be trained to the DisplayPort link of the DisplayPort sink device, regardless of whether it is receiving actual data from the UFP device; and can provide placeholder data to the DisplayPort sink device to keep the link active. Then, once the actual data from the UFP device is received, the DFP device can use the actual data instead of the placeholder data, thereby seamlessly switching the DisplayPort sink device from presenting placeholder data to presenting data from the DisplayPort source device.

Description

[0001] This application is a divisional application of the same patent application, filed on August 31, 2018, with application number 201811009518.6. Background Technology

[0002] DisplayPort communication is described in detail at least in the “VESA DisplayPort Standard, Version 1.4” published by VESA on March 1, 2016. The entire contents of this document (the contents of which are known to those skilled in the art), together with any earlier versions or related documents mentioned therein (collectively, the “DisplayPort Specification”), are incorporated herein by reference for all purposes. The DisplayPort Specification describes the physical and logical techniques for enabling communication between a DisplayPort source device that generates video (and, in some embodiments, audio) and a DisplayPort destination device that presents video (and, in some embodiments, audio). The DisplayPort Specification also describes a topology in which one or more branch devices (similar to repeaters, splitters, or hubs) exist between the DisplayPort source device and the DisplayPort destination device.

[0003] The DisplayPort specification includes limitations on the cable length connecting DisplayPort source and destination devices, and also includes other specific requirements for cable physical construction. For example, full-bandwidth transmission over passive cable is limited to a cable length of three meters. Additionally, the DisplayPort specification describes direct communication between DisplayPort source and destination devices, but does not permit any manipulation of the video or audio content between them. The DisplayPort specification also assumes that a link is established between a given DisplayPort source and destination device, and that if a given DisplayPort destination device is linked to a different DisplayPort source device, the link must be completely retrained.

[0004] The desired outcome is the provision of apparatus and techniques that allow DisplayPort source devices and DisplayPort destination devices, which conform to the DisplayPort specification in other ways, to communicate via extended media, despite the distance limitations and media requirements of the DisplayPort specification. It is also desired to provide apparatus and techniques that allow seamless switching between displaying content from a first DisplayPort source device and displaying content from a second DisplayPort source device, without requiring retraining of the link with the DisplayPort destination device. Summary of the Invention

[0005] This overview is provided to introduce a set of concepts in a simplified form, which are further described in detail below. This overview is not intended to identify key features of the claimed subject matter, nor is it intended to help determine the scope of the claimed subject matter.

[0006] In some embodiments, a system for switching DisplayPort connections is provided. The system includes an extension medium, a first upstream-facing port device (UFP device), and a downstream-facing port device (DFP device). The first UFP device is communicatively connected to a first DisplayPort source device and the extension medium. The DFP device is communicatively connected to a DisplayPort sink device and the extension medium. The first UFP device is configured to: perform link training with the DisplayPort source device and receive video data from the DisplayPort source device before pairing with the DFP device. The DFP device is configured to: perform link training with the DisplayPort sink device before pairing with the first UFP device; transmit DisplayPort data including placeholder video data to the DisplayPort sink device; and, in response to pairing with the first UFP device via the extension medium: switch from transmitting DisplayPort data including the placeholder video data to instead transmitting DisplayPort data including video data received from the first UFP device.

[0007] In some embodiments, a method is provided for switching a DisplayPort connection via an extended medium. An extended device performs link training with a DisplayPort sink device to establish a DisplayPort link between the extended device and the DisplayPort sink device. The extended device generates placeholder video data. The extended device generates DisplayPort data including the placeholder video data. The extended device transmits the DisplayPort data including the placeholder video data to the DisplayPort sink device. The extended device receives actual video data via the extended medium, wherein the actual video data is generated by a DisplayPort source device. The extended device generates DisplayPort data including the actual video data and transmits the DisplayPort data including the actual video data to the DisplayPort sink device without retraining the link between the extended device and the DisplayPort sink device.

[0008] In some embodiments, a downstream-facing port device (DFP device) is provided. The DFP device includes an extension interface, a DisplayPort interface, a placeholder video engine, and a downstream video engine. The DisplayPort interface is configured to receive actual video data from the extension interface, wherein the actual video data is generated by a DisplayPort source device. The placeholder video engine is configured to generate placeholder video data. The downstream video engine is configured to: perform link training with a DisplayPort destination device connected to the DisplayPort interface; transmit DisplayPort data including the placeholder video data to the DisplayPort destination device; and switch to transmitting DisplayPort data including the actual video data instead of the placeholder video data to the DisplayPort destination device without re-performing link training.

[0009] In some embodiments, an upstream-facing port device (UFP device) is provided. The UFP device includes an extension interface, a DisplayPort interface, and an upstream video engine. The upstream video engine is configured to: perform link training with a DisplayPort source device connected to the DisplayPort interface, and receive DisplayPort data from the DisplayPort source device before pairing with a first downstream-facing port device (DFP device); receive a first command for pairing with the first DFP device; and, in response to pairing with the first DFP device via the extension interface: extract actual video data from the DisplayPort data received from the DisplayPort source device; and transmit the actual video data to the first DFP device via the extension interface. Attached Figure Description

[0010] The foregoing aspects and several incidental advantages of the invention will become more readily understood as these advantages will become more apparent when considered in conjunction with the following detailed description, in which:

[0011] Figure 1A and 1B This is a block diagram illustrating non-limiting exemplary embodiments of an upstream-oriented port device (UFP device) and a downstream-oriented port device (DFP device) according to various aspects of this disclosure.

[0012] Figure 2 It is a schematic diagram illustrating a non-limiting example of communication technology, showing various aspects of this disclosure;

[0013] Figure 3 This is a block diagram illustrating a non-limiting exemplary embodiment of an upstream video engine according to various aspects of this disclosure;

[0014] Figure 4 This is a block diagram illustrating a non-limiting exemplary embodiment of a downstream video engine according to various aspects of this disclosure;

[0015] Figure 5 This is a block diagram illustrating a non-limiting exemplary embodiment of an extended interface engine according to various aspects of this disclosure; and

[0016] Figures 6A to 6D This is a flowchart illustrating a non-limiting exemplary embodiment of a method for managing a switchable DisplayPort extended connection according to various aspects of this disclosure. Detailed Implementation

[0017] In some embodiments of this disclosure, extension devices, such as upstream-facing port devices (UFP devices) and downstream-facing port devices (DFP devices), are connected via an extension medium, such as a network. The UFP device forms a DisplayPort connection to a DisplayPort source device, and the DFP device forms a DisplayPort connection to a DisplayPort sink device. When the UFP device and DFP device are paired, DisplayPort video and / or audio information from the DisplayPort source device can be presented by the DisplayPort sink device, which is connected to the UFP device and the DFP device, respectively. In some embodiments of this disclosure, the DFP device can be trained to the DisplayPort link of the DisplayPort sink device, regardless of whether it receives actual data from the UFP device; and can provide placeholder data to the DisplayPort sink device to keep the link active. The DFP device can then replace the placeholder data with actual data from the UFP device (once acquired), thereby seamlessly switching the DisplayPort sink device from displaying placeholder data to displaying actual data from the DisplayPort source device. In some embodiments, the DFP device can use a similar placeholder function while changing its pairing with a new UFP device, thereby seamlessly switching the DisplayPort sink device to displaying data from the new DisplayPort source device.

[0018] Figure 1A and 1B These are block diagrams illustrating non-limiting exemplary embodiments of upstream-facing port devices (UFP devices) and downstream-facing port devices (DFP devices) according to various aspects of this disclosure. Figure 1AThe image shows a DisplayPort source device 102, an upstream-facing port device (UFP device) 104, and an extension medium 90. The DisplayPort source device 102 can be any type of device with a DisplayPort receptacle and capable of transmitting DisplayPort information, including but not limited to: desktop computing devices, laptop computing devices, tablet computing devices, rack-mount computing devices, external graphics cards, video processing systems, etc. The DisplayPort source device 102 includes a DisplayPort interface 110, which is communicatively connected to a DisplayPort interface 112 of the UFP device 104. The connection between the DisplayPort source device 102 and the UFP device 104 via DisplayPort interfaces 110 and 112 includes standard DisplayPort receptacles, DisplayPort cables, etc., as described in the DisplayPort specification and known to those skilled in the art. In some embodiments, DisplayPort interfaces 110 and 112 may include one or more of the following: a DisplayPort connector, a USB Type-C connector, and / or a DockPort connector.

[0019] As shown in the figure, the UFP device 104 includes an upstream processor 114. In some embodiments, the upstream processor 114 may be implemented using a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a microcontroller, and / or any other suitable type of computing device or integrated circuit. The upstream processor 114 may be configured to provide an upstream video engine 120, an upstream AUX engine 122, and a DisplayPort sink emulation engine 124.

[0020] In general, as used herein, the term "engine" refers to the logic implemented in hardware or software instructions that can be written in programming languages ​​such as C, C++, COBOL, and JAVA. TM , PHP, Perl, HTML, CSS, JavaScript, VBScript, ASPX, Microsoft.NET TMEngines implemented in hardware can be designed using Hardware Description Language (HDL). Software engines can be compiled into executable programs or written in interpreted programming languages. Engines can be called from other engines or from themselves. Generally, the engines described herein refer to logical modules that can be combined with other engines or can be divided into sub-engines. Engines can be stored on any type of computer-readable medium or computer storage device and can be stored on and executed on one or more general-purpose computers, thereby creating a dedicated computer configured to provide the engine or application. Engines can also be implemented using floating-point gate arrays (FPGAs), application-specific integrated circuits (ASICs), microcontrollers, and / or any other suitable type of integrated circuit computing device.

[0021] In some embodiments, the upstream video engine 120 is configured to receive one or more DisplayPort channels from the DisplayPort interface 112. The upstream video engine 120 is configured to recover video and / or audio signals from the DisplayPort channels and provide the video and / or audio signals to the expansion interface 116. In some embodiments, the upstream video engine 120 may configurably perform further processing on the video and / or audio before providing it to the expansion interface 116, including but not limited to: changing the bit rate of information, encrypting information, upsampling or downsampling information, and / or any other type of processing. In some embodiments, the upstream video engine 120 is also configured to selectively provide a hot-plug detection (HPD) signal to the DisplayPort source device 102 via the DisplayPort interface 112. The upstream video engine 120 may selectively provide the HPD signal based on instructions received from the upstream AUX engine 122, the DisplayPort sink emulation engine 124, or other components of the UFP device 104. Figure 3 Further demonstrations and descriptions of exemplary embodiments of the upstream video engine 120 are provided in the accompanying text.

[0022] In some embodiments, the upstream AUX engine 122 is configured to manage AUX channel communication with the DisplayPort source device 102 and to control the selective presentation of HPD signals via the upstream video engine 120. A technical challenge in extending DisplayPort communication via the extension medium 90 is that the UFP device 104 may be unaware of the presence, configuration, or capabilities of the DFP device 106 or the DisplayPort sink device 108 when the DisplayPort source device 102 is connected to the DisplayPort interface 112. Accordingly, the upstream AUX engine 122 manipulates information transmitted via the AUX channel and HPD signals to overcome these challenges.

[0023] The upstream AUX engine 122 and upstream video engine 120 can also be configured to implement link training with DisplayPort source device 102. Another technical challenge arising when implementing switchable connectivity via extension medium 90 is that once link training with DisplayPort source device 102 is implemented, the DisplayPort link between DisplayPort source device 102 and UFP device 104 should remain active regardless of whether UFP device 104 is paired with DFP device 106. Accordingly, in some embodiments, DisplayPort sink emulation engine 124 is configured to provide information to upstream video engine 120 in response to signals provided by DisplayPort source device 102, instead of information typically generated by DisplayPort sink device 108, to maintain the link active. In this way, UFP device 104 can train and maintain the DisplayPort link with DisplayPort source device 102, and therefore, even if the pairing between UFP device 104 and DFP device 106 changes, DisplayPort source device 102 will not detect any change. Further details are provided below regarding some exemplary technologies used by the upstream AUX engine 122, the upstream video engine 120, and the DisplayPort sink emulation engine 124 to provide this functionality.

[0024] In some embodiments, upstream video engine 120 and upstream AUX engine 122 transmit video / audio information and AUX information to DFP device 106 via extension medium 90 and extension interface 116. In some embodiments, communication over extension medium 90 may include any suitable networking technology, such as Ethernet, Bluetooth, WiFi, WiMax, the Internet, serial communication, etc.; and any suitable communication medium, such as via physical cable, via wireless spectrum, via fiber optic cable, etc. In some embodiments, UFP device 104 and DFP device 106 may happen to be closer to each other than the maximum distance specified in the DisplayPort specification, but can still communicate via extension medium 90. In some embodiments, extension interface 116 is configured to provide physical layer connectivity and logic that allows communication over extension medium 90. Figure 5 Further demonstrations and descriptions of exemplary embodiments of the extended interface 116 are provided in the accompanying text.

[0025] exist Figure 1BThe image shows a DisplayPort sink device 108, a downstream-facing port device (DFP device) 106, and an extension medium 90. The DisplayPort sink device 108 can be any type of device capable of being used as a DisplayPort sink device, as described in the DisplayPort specification. Some non-limiting examples of the DisplayPort sink device 108 include liquid crystal display (LCD) detectors, projectors, large-format screens, video processing systems, etc. The DisplayPort sink device 108 includes a DisplayPort interface 132 that is communicatively connected to the DisplayPort interface 130 of the DFP device 106 using a cable or other connector. Similar to the connection between the DisplayPort source device 102 and the UFP device 104, the cables and interfaces 130, 132 include standard DisplayPort sockets, plugs, conductors, etc., as described in the DisplayPort specification and known to those skilled in the art.

[0026] In some embodiments, the DFP device 106 includes a downstream processor 128. Like the upstream processor 114, the downstream processor 128 and / or its components may be implemented using an FPGA, ASIC, microcontroller, and / or any other suitable type of computing device or integrated circuit. In some embodiments, the downstream processor 128 provides a downstream video engine 136, a downstream AUX engine 138, and a placeholder video engine 140.

[0027] In some embodiments, downstream video engine 136 is configured to receive video and / or audio signals from expansion interface 126 or placeholder video engine 140, and generate one or more DisplayPort channels based on the video and / or audio signals. Downstream video engine 136 is configured to provide DisplayPort channels to DisplayPort sink device 108 via DisplayPort interface 130. Downstream video engine 136 may also be configured to receive and detect HPD signals transmitted by DisplayPort sink device 108 via DisplayPort interface 130. Figure 4 Further demonstrations and descriptions of exemplary embodiments of the downstream video engine 136 are provided in the accompanying text.

[0028] In some embodiments, the downstream AUX engine 138 is configured to manage AUX channel communication with the DisplayPort sink device 108. This may include determining the capabilities of the DisplayPort sink device 108 to determine the maximum possible bandwidth or other connection quality. The downstream AUX engine 138 and the downstream video engine 136 may also be configured to perform link training with the DisplayPort sink device 108. In some embodiments, link training may be performed by the downstream AUX engine 138 and the downstream video engine 136 to establish the highest possible bandwidth link between the DFP device 106 and the DisplayPort sink device 108 based on the capabilities reported by the DisplayPort sink device 108. In some embodiments, link training may be performed to match a standard link configuration that remains constant throughout the system. In some embodiments, once the link between DFP device 106 and DisplayPort sink device 108 is trained at a given time (but before DFP device 106 pairs with UFP device 104 and begins receiving actual video data from it), placeholder video engine 140 is configured to generate placeholder video data at that given time and provide the generated placeholder video data to downstream video engine 136 to be incorporated into DisplayPort data transmitted via DisplayPort interface 130 to DisplayPort sink device 108 to maintain link validity. Once DFP device 106 receives actual video data, downstream video engine 136 can use the actual video data instead of placeholder video data to create DisplayPort data. Further details are provided below regarding some exemplary techniques used by downstream AUX engine 138, downstream video engine 136, and placeholder video engine 140 to provide this functionality.

[0029] In some embodiments, downstream video engine 136 and downstream AUX engine 138 communicate with upstream video engine 120 and upstream AUX engine 122 via extension medium 90 and using extension interface 126. The extension medium is as described above, and the extension interface 126 is also similar to... Figure 1A The extended interface 116 is shown (but operates in reverse). In Figure 5 Further demonstrations and descriptions of exemplary embodiments of the extended interface 126 are provided in the accompanying text.

[0030] Figure 2 This is a schematic diagram illustrating a non-limiting example of communication technology, showing various aspects of this disclosure. Figure 2In this diagram, network 90 is shown connecting a first UFP device 202, a second UFP device 204, a controller device 206, a first DFP device 208, a second DFP device 210, and a third DFP device 212. In some embodiments, there may be more or fewer UFP devices and / or DFP devices.

[0031] Each of the UFP devices is connected to a DisplayPort source device: the first UFP device 202 is connected to the first DisplayPort source device 201, and the second UFP device 204 is connected to the second DisplayPort source device 203. Similarly, each of the DFP devices is connected to a DisplayPort sink device: the first DFP device 208 is connected to the first DisplayPort sink device 214, the second DFP device 210 is connected to the second DisplayPort sink device 216, and the third DFP device 212 is connected to the third DisplayPort sink device 220. UFP devices 202 and 204 are each examples of the UFP device 104 described above, and DFP devices 208, 210, and 212 are each examples of the DFP device 106 described above. Similarly, DisplayPort source devices 201 and 203 are each examples of the DisplayPort source device 102 described above, and DisplayPort sink devices 214, 216, and 220 are each examples of the DisplayPort sink device 108 described above.

[0032] In some embodiments, controller device 206 may be used to receive configuration information from UFP devices 202, 204 and DFP devices 208, 210, 212 via network 90 and send configuration commands to them. In some embodiments, controller device 206 may use technologies such as IP broadcast, IP multicast, and / or any other suitable technology to broadcast a request for configuration information to network 90. ​​UFP devices 202, 204 and DFP devices 208, 210, 212 connected to network 90 may then transmit a response to controller device 206, which receives and compiles the response to form a representation of communication topology 200. The response transmitted to controller device 206 may include, but is not limited to, information such as, but not limited to, unique hardware identifiers (e.g., MAC address, etc.), network addresses (e.g., IP address, etc.), supported protocol versions, vendor names, product names, revisions, and / or identifiers of one or more other extension devices paired with the extension device. Controller device 206 may use the configuration information to generate a graphical representation of communication topology 200 and may subsequently present the graphical representation of communication topology 200 to a user. The controller device 206 can also accept commands from the user regarding the presented communication topology 200 to reconfigure the communication topology 200, as discussed below.

[0033] Controller device 206 can be any computing device suitable for providing commands to UFP devices 202, 204 and DFP devices 208, 210, 212 via network 90. ​​For example, controller device 206 can be a laptop computer, desktop computer, tablet computer, smartphone, or other computing device connected to network 90, and can request information from UFP devices 202, 204 and DFP devices 208, 210, 212 and send commands to them via network 90. ​​As another example, controller device 206 can be partially or completely integrated into one of DisplayPort source devices 201, 203, one of UFP devices 202, 204, one of DFP devices 208, 210, 212, or one of DisplayPort sink devices 214, 216, 220; and can accept configuration commands from a user via a user interface device, including but not limited to: mechanical buttons or switches, jumper settings, toggle switches, and devices configured to present a graphical user interface. Although Figure 2 A single controller device 206 is shown, but in some embodiments, more than one controller device 206 may be used.

[0034] In some embodiments, controller device 206 is configured to send configuration commands to UFP devices 202, 204 and DFP devices 208, 210, 212, the configuration commands including instructions on how UFP devices 202, 204 and DFP devices 208, 210, 212 should be configured for communication on a network. For example, in some embodiments, controller device 206 may send a command to UFP device 202 to instruct UFP device 202 to automatically obtain an IPv4 address from an address server device (e.g., a DHCP server, etc.) on network 90. ​​As another example, in some embodiments, controller device 206 may send a command to UFP device 202 to instruct UFP device 202 to use a static IPv4 address provided in the command. As yet another example, in some embodiments, controller device 206 may send a command to UFP device 202 to instruct UFP device 202 to obtain an IPv6 address by using Stateless Address Autoconfiguration (SLAAC) or using any other suitable technology. Those skilled in the art will understand that such commands can also be sent to any of the other UFP devices 204 and / or DFP devices 208, 210, 212, and can also be obtained using any other suitable technology for obtaining addresses on any type of network.

[0035] In some embodiments, each UFP device 202, 204 may be paired with zero or one DFP device 208, 210, 212, and each DFP device 208, 210, 212 may be paired with zero or one UFP device 202, 204 at any given time. When the first UFP device 202 is paired with the first DFP device 208, the first UFP device 202 is able to transmit video and / or audio data from the first DisplayPort source device 201 to the first DFP device 208, and then the first DFP device 208 is able to transmit DisplayPort data containing video and / or audio data from the first DisplayPort source device 201 to the first DisplayPort destination device 214. The pairing can then be changed to switch the video and / or audio to be presented on the first DisplayPort destination device 214. For example, the pairing can be changed to pair the second UFP device 204 (instead of the first UFP device 202) with the first DFP device 208. After the pairing is changed, the second UFP device 204 can transmit video and / or audio from the second DisplayPort source device 203 to the first DFP device 208, and then the first DFP device 208 can transmit DisplayPort data containing video and / or audio data from the second DisplayPort source device 203 (but not the first DisplayPort source device 201) to the first DisplayPort sink device 214. Since the UFP devices 202, 204 form link partnerships with their associated DisplayPort source devices 201, 203 and maintain these links regardless of the pairing configuration, and since the DFP devices 208, 210, 212 also form link partnerships with their associated DisplayPort sink devices 214, 216, 220 and maintain these links regardless of the pairing configuration, the pairing switch can be transparent to both the DisplayPort source devices 201, 203 and the DisplayPort sink devices 214, 216, 220, as further described below.

[0036] Figure 2A general communication topology 200 has been illustrated, but those skilled in the art will recognize that communication topology 200 has many useful applications. In one non-limiting exemplary embodiment, a communication topology similar to communication topology 200 can be used to provide switchable access from a single projector (DisplayPort sink device) in a conference room to multiple laptops or desktop computers (DisplayPort source devices) in the same conference room. The ability to reconfigure the topology to seamlessly switch the projector from one laptop computer to another will be far superior to existing systems that require a lengthy process to reconfigure the link with the projector each time a new laptop computer is connected. In another non-limiting exemplary embodiment, multiple computing devices can be arranged in a cluster, server group, test bench, or in some other situations where connecting individual display devices to each computing device is impractical or impossible. By using a communication topology similar to communication topology 200, a DisplayPort sink device can be shared by all computing devices, and the display can be quickly and seamlessly switched from one technology device to another without having to wait for the DisplayPort link to be retrained each time. As those skilled in the art will recognize, the exemplary topology embodiments described above are merely exemplary and should not be considered limiting. In some embodiments, other configurations of the embodiments of this disclosure may also be used.

[0037] Figure 3 This is a block diagram illustrating a non-limiting exemplary embodiment of an upstream video engine according to various aspects of this disclosure. As shown, the upstream video engine 120 includes a SERDES engine 302, a decoding engine 304, and a descrambling engine 306. The SERDES engine 302, or serializer / deserializer engine, is configured to deserialize parallel data streams received in serial format via a DisplayPort interface 112. The received data streams may include one or more scrambled and encoded video data streams. The received signals may also include AUX channel data, audio data, and / or other types of data.

[0038] Decoding engine 304 is configured to decode the encoded signal received from SERDES engine 302. The decoding algorithm to be used can be specified via AUX channel communication, allowing decoding engine 304 to be configured to use a decoding technique matching the input data. Some non-limiting examples of encoding formats include 8b / 10b encoding, Display Stream Compression (DSC) encoding, etc. Descrambling engine 306 is configured to descramble the decoded video signal generated by decoding engine 304. Techniques for descrambling are described in the DisplayPort specification. The output of descrambling engine 306 (and therefore upstream video engine 120) is a video signal suitable for presentation by a video rendering device or suitable for further video processing. H.264 streaming is a non-limiting example of said output, but other suitable video formats may be used. In some embodiments, the output of upstream video engine 120 may also include audio information and / or AUX channel information.

[0039] In some embodiments, the components displayed by the upstream video engine 120 may be combined with each other, or individual components may be divided into multiple components. Several other exemplary components suitable for use in the upstream video engine 120 are described in the description of the DisplayPort specification for providing the main link.

[0040] Figure 4 This is a block diagram illustrating non-limiting exemplary embodiments of a downstream video engine according to various aspects of this disclosure. In some embodiments, the downstream video engine 136 provides functionality inversely to the upstream video engine 136. That is, the downstream video engine 136 can receive video and audio signals suitable for presentation and can transmit DisplayPort data. As shown, the downstream video engine 136 includes a scrambling engine 402, an encoding engine 404, and a SERDES engine 406. The scrambling engine 402 receives video and / or audio signals and scrambles them using any suitable technique (including, but not limited to, the techniques described in the DisplayPort specification). The encoding engine 404 receives the scrambled video and / or audio signals from the scrambling engine 402 and encodes them using any suitable technique, including, but not limited to, 8b / 10b encoding, DSC encoding, etc. The SERDES engine 406 then combines the multiple scrambled and encoded data streams into a single serialized signal for transmission. Similar to the components of the upstream video engine 120, the components of the downstream video engine 136 can be combined or subdivided, and their functions and structures are similar to the main link described in the DisplayPort specification.

[0041] Figure 5This is a block diagram illustrating a non-limiting exemplary embodiment of an extended interface engine according to various aspects of this disclosure. The primary purpose of the extended interface engine 500 when on a UFP device 104 is to transmit video signals, audio signals, and / or AUX signals in an extended format via an extended medium 90. When on a DFP device 106, the primary purpose of the extended interface engine 500 is to receive extended format information from the extended medium 90 and convert it back into the original video signals, audio signals, and / or AUX signals. The extended interface engine 500 can also transmit information bidirectionally and can be used to implement a connection handshake between the UFP device 104 and the DFP device 106.

[0042] As shown in the figure, the extended interface engine 500 includes a multiplexing engine 502, a framing engine 504, a media access control (MAC) engine 506, a 10 Gigabit Media Independent Interface (XGMII) engine 508, an XGMII Extender Sublayer (XGXS) engine 510, and a SERDES engine 512. Acquiring, implementing each of these components, and / or integrating them with each other to form the extended interface engine 500 is within the knowledge of those skilled in the art and therefore will not be described in detail. The extended interface engine 500 shown is configured to use Gigabit Ethernet as the extended medium 90. In some embodiments, different extended media 90 may be used, and therefore the components of the extended interface engine 500 used with said different extended media will be selected as appropriate.

[0043] Figures 6A to 6D This is a flowchart illustrating a non-limiting exemplary embodiment of a method for managing switchable DisplayPort extended connections according to various aspects of this disclosure. Starting with a start box, method 600 proceeds to a set of method steps 602 defined between an ingress end (“End A”) and an egress end (“End B”). In this set of method steps 602, UFP device 104 trains a link with DisplayPort source device 102, and DFP device 106 trains a link with DisplayPort sink device 108. While the following description refers to a detailed representation of DisplayPort source device 102, UFP device 104, DFP device 106, and DisplayPort sink device 108, those skilled in the art will recognize that the description may also interchangeably refer to a first DisplayPort source device 201, a first UFP device 202, a first DFP device 208, and a first DisplayPort sink device 214.

[0044] From end A ( Figure 6BMethod 600 proceeds to block 608, where a physical connection is made between DisplayPort source device 102 and upstream-facing port device (UFP device) 104. A physical connection between DisplayPort source device 102 and UFP device 104 can be formed between DisplayPort interface 110 and DisplayPort interface 112, as described above.

[0045] At block 610, the DisplayPort sink emulation engine 124 of the UFP device 104 performs link training with the DisplayPort source device 102. The upstream video engine 120 and the upstream AUX engine 122 may also participate in the link training process. In some embodiments, the DisplayPort sink emulation engine 124 may generate EDID messages, DPCD messages, and / or DisplayID messages to be transmitted by the upstream AUX engine 122 to simulate the presence of a DisplayPort sink. Otherwise, link training between the DisplayPort source device 102 and the UFP device 104 may substantially occur as described in the DisplayPort specification. In some embodiments, the DisplayPort sink emulation engine 124 may cause the link to be trained with the maximum bandwidth, bit depth, refresh rate, resolution, or timing supported by the DisplayPort source device 102. In some embodiments, the DisplayPort sink emulation engine 124 may cause the link to be trained with the maximum bandwidth, bit depth, refresh rate, resolution, or timing supported by the extension medium 90. In some embodiments, the DisplayPort sink emulation engine 124 can cause the link to be trained or guided by the controller device 206 to maintain a constant standard bandwidth, bit depth, refresh rate, resolution, or timing across the communication topology 200.

[0046] At box 612, UFP device 104 begins receiving DisplayPort data from DisplayPort source device 102. The DisplayPort data includes video data generated by DisplayPort source device 102 at a timing negotiated during link training between UFP device 104 and DisplayPort source device 102. In some embodiments, the DisplayPort data may also include audio data streams and / or other data streams transmitted via the DisplayPort connection. Prior to pairing between UFP device 104 and DFP device 106, DisplayPort sink emulation engine 124 receives DisplayPort data but may simply provide the necessary acknowledgments to keep the link active without further processing or transmission of the received DisplayPort data.

[0047] At box 614, a physical connection is made between DisplayPort sink device 108 and downstream-facing port device (DFP device) 106. A physical connection between DisplayPort sink device 108 and DFP device 106 can be formed between DisplayPort interface 130 and DisplayPort interface 132, as described above.

[0048] At block 616, the downstream video engine 136 of the DFP device 106 performs link training with the DisplayPort sink device 108 at the maximum supported bandwidth. In some embodiments, the downstream AUX engine 138 may also participate in the link training process. In some embodiments, the downstream AUX engine 138 may request EDID, DPCD, and / or DisplayID information from the DisplayPort sink device 108, and may train the link between the DFP device 106 and the DisplayPort sink device 108 with the maximum bandwidth, highest resolution, highest bit depth, highest refresh rate, and / or fastest timing supported by the DisplayPort sink device 108 and / or the physical connection. In some embodiments, the downstream AUX engine 138 may train the link between the DFP device 106 and the DisplayPort sink device 108 to match the standard bandwidth, bit depth, refresh rate, resolution, and / or timing established for the communication topology 200 or as directed by the controller device 206. In some embodiments, when the input video data does not precisely match the existing timing of the link between the DFP device 106 and the DisplayPort sink device 108, training the link to maximum bandwidth, highest bit depth, highest refresh rate, highest resolution, and / or fastest timing increases the opportunity for the DFP device 106 to manipulate the input video data to match the timing of the link without retraining the link.

[0049] The method 600 then proceeds to block 618, where the DFP device 106 begins transmitting placeholder DisplayPort data to the DisplayPort sink device 108. The placeholder DisplayPort data is generated by the downstream video engine 136 and includes placeholder video data generated by the placeholder video engine 140. The placeholder video data is generated by the placeholder video engine 140 at a specific timing that matches the timing negotiated during link training. In some embodiments, the placeholder video data may include still images or blank images. In some embodiments, the placeholder video data may be moving video, such as a screen saver, to prevent burn-in of any still images on the display.

[0050] It should be noted that the connection and link training between UFP device 104 and DisplayPort source device 102 described in boxes 608 to 612 are unrelated to the connection and link training between DFP device 106 and DisplayPort sink device 108 described in boxes 614 to 618. Thus, boxes 608 to 612 can occur at least partially concurrently with boxes 614 to 618, or boxes 614 to 618 can occur prior to boxes 608 to 612.

[0051] Method 600 then proceeds to end B. From end B ( Figure 6A Starting from the input end (“End C”), method 600 proceeds to a set of method steps 604 defined between the input end (“End C”) and the output end (“End D”). In this set of method steps 604, the UFP device 104 and the DFP device 106 are paired with each other and transmit video from the DisplayPort source device 102 to the DisplayPort sink device 108. Again, while the following description refers to a detailed representation of the DisplayPort source device 102, UFP device 104, DFP device 106, and DisplayPort sink device 108, those skilled in the art will recognize that the description may also interchangeably refer to the first DisplayPort source device 201, the first UFP device 202, the first DFP device 208, and the first DisplayPort sink device 214.

[0052] From end C ( Figure 6C Method 600 proceeds to block 620, where UFP device 104 and DFP device 106 receive a pairing command from controller device 206. In some embodiments, the pairing command may include unique network addresses of UFP device 104 and / or DFP device 106. In some embodiments, the command may be generated through user interaction with a graphical representation of the communication topology 200 presented by controller device 206. In other embodiments, the command may be generated in a simpler manner. For example, the command may be generated by key combinations entered using an input device of controller device 206. As another example, in some embodiments, pressing a button on DFP device 106 may cause DFP device 106 to broadcast its unique network address, while pressing a button on UFP device 104 may cause UFP device 104 to interpret the network address broadcast by DFP device 106 into a pairing command with DFP device 106. In some embodiments, the unique network address of the DFP device 106 can be manually entered into the UFP device 104 by using an interface integrated into the UFP device 104, a set of DIP switches or jumpers integrated into the UFP device 104, or by using any other suitable calculation.

[0053] Those skilled in the art will recognize that while a “unique network address” is used in this discussion to address messages to a specific extension device, other techniques can be used to uniquely identify each of the extension devices in communication topology 200. For example, a MAC address or other suitable unique hardware identifier can be used to uniquely address an extension device.

[0054] Once UFP device 104 and DFP device 106 are paired, method 600 proceeds to block 622, where UFP device 104 and DFP device 106 exchange link timing information. The link timing information represents the timing of the link between UFP device 104 and DisplayPort source device 102, and the timing of the link between DFP device 106 and DisplayPort sink device 108. The link timing information may include one or more of the following: resolution, bit depth, refresh rate, number of channels, link rate, and / or any other type of timing information. This exchange allows UFP device 104 and DFP device 106 to determine whether the link timings are close enough to avoid retraining the link between DFP device 106 and DisplayPort sink device 108. For example, if every aspect of the timings is identical, they are clearly close enough. As another example, if the link between UFP device 104 and DisplayPort source device 102 uses a lower bit depth or fewer channels, the downstream video engine 136 may be able to upsample or otherwise modify the input data to create DisplayPort data that matches the timing of the link between DFP device 106 and DisplayPort sink device 108. As yet another example, as long as the link clock rate of the link between DFP device 106 and DisplayPort sink device 108 is greater than or equal to the link clock rate of the link between DisplayPort source device 102 and UFP device 104, DFP device 106 can generate and transmit DisplayPort data based on the timing of the input video data without retraining the link. However, if the timing of the link between DFP device 106 and DisplayPort sink device 108 cannot be used to transmit video provided by the source (e.g., if the link between DisplayPort source device 102 and UFP device 104 is transmitted over a high-bandwidth link, such as 4K resolution at 24bpp and 60Hz, and the link between DFP device 106 and DisplayPort sink device 108 has only one channel), it may not be close enough to be supported.

[0055] At decision box 624, it is determined whether the link between DFP device 106 and DisplayPort sink device 108 can support video transmission at the timing provided by UFP device 104. If video can be supported, the result of decision box 624 is "yes", and method 600 proceeds to decision box 628. Otherwise, if video cannot be supported, the result of decision box 624 is "no", and method 600 proceeds to box 626, where DFP device 106 and / or UFP device 104 retrain their links to DisplayPort sink device 108 or DisplayPort source device 102, respectively, to a supported link configuration. For example, if, as described above, the link between DisplayPort source device 102 and UFP device 104 is high bandwidth and the link between DFP device 106 and DisplayPort sink device 108 is low bandwidth, then UFP device 104 and DFP device 106 can negotiate to determine whether the link to DisplayPort sink device 108 can be trained to a higher bandwidth, or whether the link to DisplayPort source device 102 should be retrained to a lower bandwidth. This is not ideal because one benefit of the remainder of method 600 is that such retraining can be avoided and the switching can be seamless. However, this functionality can be provided by some embodiments of this disclosure to ensure that a given communication topology 200 can support all combinations of DisplayPort source device 102 and DisplayPort sink device 108. Method 600 then proceeds from block 626 to decision block 628.

[0056] At decision box 628, it is determined whether the timing of the DisplayPort data transmitted from DFP device 106 to DisplayPort sink device 108 needs to be changed. In this regard, in method 600, it is already known that the timing configuration of the DisplayPort data supports the timing of the received video data (after proceeding from decision box 624 or 626 to decision box 628). Even if the timing differs in some respect, DFP device 106 can compensate for the timing difference without retraining the link to DisplayPort sink device 108. If the timing is different (or the received video data cannot be changed by DFP device 106 to match the link timing), the result of decision box 628 is "yes," and method 600 proceeds to box 630. At block 630, DFP device 106 modifies the timing configuration of the link between DFP device 106 and DisplayPort sink device 108 to match the timing configuration of the link between UFP device 104 and DisplayPort source device 102, without retraining the link between DFP device 106 and DisplayPort sink device 108. In some embodiments, modifying the timing configuration may include sending five DisplayPort idle modes before sending new timing information and a new video stream. In some embodiments, modifying the timing configuration may include changing the timing of placeholder video data to the new timing, and transmitting DisplayPort data including the new placeholder video data after these five idle modes (and before receiving actual video data from UFP device 104), as described below. The new timing information may be exactly the same as the timing of the video data received from UFP device 104, or it may be modified to a slightly different configuration, but for this purpose, DFP device 106 may modify the received video data to match.

[0057] Following box 630, or if the timing does not need to be changed and the result of box 628 is "no", method 600 proceeds to box 632. At box 632, UFP device 104 transmits data from DisplayPort source device 102 to DFP device 106. This data includes video extracted from DisplayPort data received by upstream video engine 120 from DisplayPort source device 102. In some embodiments, other information may also be extracted and transmitted to DFP device 106, including but not limited to: audio data, USB data, and / or any other data transmitted from DisplayPort source device 102 to UFP device 104.

[0058] At block 634, DFP device 106 transmits DisplayPort data, including data from DisplayPort source device 102, to DisplayPort sink device 108 instead of transmitting placeholder DisplayPort data. In some embodiments, switching from placeholder DisplayPort data to DisplayPort data including data from UFP device 104 may involve sending five idle modes between these two data types. In some embodiments, if the timing is the same, these five idle modes may not be sent, and the video source to be placed in the DisplayPort data may simply be changed. In some embodiments, DFP device 106 may wait for frame boundaries to perform the switch. The result of these actions is a seamless transition from placeholder video to actual video data. Because there is no retraining of the link, there are no switching visual artifacts at DisplayPort sink device 108 (e.g., “no signal” notifications or other connection losses shown by DisplayPort sink device 108), and the switch should occur faster than if link retraining is implemented. The lack of visual artifacts and the switching speed are both superior to systems that do not use the techniques described herein.

[0059] Method 600 then proceeds to end D, and from end D ( Figure 6A The process proceeds to a set of method steps 606 defined between the inlet (“End E”) and the outlet (“End F”). In this set of method steps 606, the DFP device 106 is paired with the new UFP device 104, and the new video generated by the new DisplayPort source device 102 coupled to the new UFP device 104 is seamlessly provided to the DisplayPort destination device 108. This set of method steps 606 involves a detailed representation of the DisplayPort source device 102, the UFP device 104, the DFP device 106, and the DisplayPort destination device 108. Those skilled in the art will recognize that this description may interchangeably refer to a communication network 200 in which a first UFP device 202 connected to a first DisplayPort source device 201 is paired with a first DFP device 208 connected to a first DisplayPort sink device 214, and this set of method steps 606 causes the first DFP device 208 to switch its pairing to a second UFP device 204 connected to a second DisplayPort source device 203.

[0060] From end E ( Figure 6DMethod 600 proceeds to block 636, where DFP device 106 receives a new pairing command from controller device 206 for pairing with a new UFP device 104 (e.g., a second UFP device 204), which is linked to a new DisplayPort source device 102 (e.g., a second DisplayPort source device 203). Next, at block 638, DFP device 106 transmits placeholder DisplayPort data, instead of DisplayPort data, to DisplayPort destination device 108. This DisplayPort data includes data from the original DisplayPort source device 102 (e.g., a first DisplayPort source device 201). As before, the placeholder DisplayPort data includes placeholder video data from placeholder video engine 140, rather than actual video data received from the original or new DisplayPort source device. Switching between video data from the original DisplayPort source device and placeholder video data can wait for a frame boundary, but is otherwise seamless, especially when the placeholder video data has been set to match the timing of the link between DFP device 106 and DisplayPort sink device 108.

[0061] At box 640, DFP device 106 and the new UFP device 104 exchange link timing information. The new UFP device 104 has already trained its link with its associated DisplayPort source device 102 and has therefore established the timing of the link. This information exchange is similar to the exchange described above in box 622. Method 600 then proceeds to decision box 642, where a determination is made based on whether the link between DFP device 106 and DisplayPort sink device 108 can support the timing of data transmitted between DisplayPort source device 102 and the new UFP device 104, without performing link training. This determination is similar to the determination made in decision box 624 and is therefore not described in detail here for brevity. If the timing can be supported, the result of decision box 642 is "yes," and method 600 proceeds to another decision box 646. If timing cannot be supported without retraining the link between DFP device 106 and DisplayPort sink device 108, the result of decision box 642 is "No", and the method proceeds to box 644, where DFP device 106 and / or the new UFP device 104 retrain their link to the supported configuration. Again, this is similar to box 626, and therefore will not be described in detail here for the sake of brevity. Method 600 then proceeds to decision box 646.

[0062] At decision box 646, it is determined whether the timing of the link between DFP device 106 and DisplayPort sink device 108 should be changed to support video data transmitted by the new UFP device 104. This is similar to the decision made in decision box 628, and therefore is not described in detail here to avoid unnecessary repetition. If the timing should be changed, the result of decision box 646 is "yes", and method 600 proceeds to decision box 648. At box 648, DFP device 106 changes the timing configuration of the link between DFP device 106 and DisplayPort sink device 108 to match the timing configuration of the link between the new UFP device 104 and the new DisplayPort source device 102, without retraining the link between DFP device 106 and DisplayPort sink device 108. As described in box 630, changing the timing configuration may include sending five DisplayPort idle modes before sending new timing information and a new video stream, and may include changing the timing of placeholder video data to the new timing, and transmitting DisplayPort data including the new placeholder video data after these five idle modes. Similarly, as described in box 630, the new timing information may be exactly the same as the timing of the video data received from UFP device 104, or it may be changed to a slightly different configuration, but for this purpose, DFP device 106 may modify the received video data to match. Method 600 then proceeds to box 650. If the timing does not need to be changed, the result of decision box 646 is "No," and method 600 proceeds directly from decision box 646 to box 650.

[0063] At box 650, the new UFP device 104 transmits data from the new DisplayPort source device 102 to the DFP device 106. Next, at box 652, the DFP device 106 transmits DisplayPort data (not placeholder DisplayPort data) of the data from the new DisplayPort source device 102 to the DisplayPort destination device 108. In some embodiments, the DFP device 106 can directly switch from video from the original DisplayPort source device / UFP device to video from the new DisplayPort source device / UFP device, but transmitting placeholder DisplayPort data in between helps compensate for any latency when receiving a new stream.

[0064] Regarding this, in method 600, the video displayed by the DisplayPort sink device 108 has been switched from the video provided by the first DisplayPort source device to the video provided by the second DisplayPort source device. While placeholder data can be presented between these two videos, these switchings occur seamlessly in other ways, especially since link training does not need to repeat the switching between the first and second videos. Method 600 then proceeds to end F, and from end F ( Figure 6A ) to the end box (where method 600 ends).

[0065] Although illustrative embodiments have been shown and described, it should be understood that various changes may be made without departing from the spirit and scope of the invention.

Claims

1. A method for switching DisplayPort connections on an extended medium, the method comprising: Link training with the DisplayPort sink device coupled to the downstream port DFP device is performed via the downstream port DFP device; The DFP device sends DisplayPort data to the DisplayPort sink device, the DisplayPort data including first actual video data received by the DFP device from the extension medium, wherein the first actual video data is received from a first extension device connected to the first DisplayPort source device; The DFP device receives commands for pairing with a second extension device connected to the second DisplayPort source device; and The DFP device sends DisplayPort data, which includes second actual video data received from the second extension device instead of the first actual video data, to the DisplayPort sink device without retraining the link between the DFP device and the DisplayPort sink device.

2. The method according to claim 1, wherein, The first actual video data and the second actual video data have the same timing sequence.

3. The method according to claim 1, wherein, The timing sequence of the first actual video data is different from that of the second actual video data, and the method further includes: The DFP device generates DisplayPort data including at least five idle modes; and The DisplayPort data is sent by the DFP device, and the DisplayPort data includes at least five idle modes between the DisplayPort data including the first actual video data and the DisplayPort data including the second actual video data.

4. The method according to claim 1, further comprising: The DFP device sends DisplayPort data, including placeholder video data generated by the DFP device, to the DisplayPort sink device; as well as The DFP device switches to sending DisplayPort data, which includes the first actual video data instead of the placeholder video data, to the DisplayPort sink device without performing link training again.

5. The method according to claim 4, wherein, The timing of the placeholder video data is the same as the timing of the first actual video data.

6. The method according to claim 4, further comprising: The first actual video data received from the extended medium is used to generate DisplayPort data including the first actual video data; as well as The placeholder video data generated by the DFP device is used to generate DisplayPort data that includes the placeholder video data.

7. A downstream-facing port DFP device, comprising: Extended interfaces; A DisplayPort interface configured to receive actual video data from the expansion interface, wherein the actual video data is generated by a DisplayPort source device; and The downstream video engine is configured as follows: Perform link training with the DisplayPort sink device coupled to the DisplayPort interface; DisplayPort data, including first actual video data, is sent to the DisplayPort sink device, wherein the first actual video data is received from a first extension device connected to the first DisplayPort source device; Receive commands for pairing with a second extension device connected to a second DisplayPort source device; and DisplayPort data, including second actual video data received from the second extension device instead of the first actual video data, is sent to the DisplayPort sink device without retraining the link between the DFP device and the DisplayPort sink device.

8. The DFP device according to claim 7, wherein, The first actual video data and the second actual video data have the same timing sequence.

9. The DFP device according to claim 7, wherein, The timing sequence of the first actual video data is different from that of the second actual video data, and the downstream video engine is further configured as follows: Generate DisplayPort data including at least five idle modes; and The DisplayPort data is sent, which includes at least five idle modes between the DisplayPort data including the first actual video data and the DisplayPort data including the second actual video data.

10. The DFP apparatus of claim 7, further comprising a placeholder video engine configured to generate placeholder video data, wherein, The downstream video engine is also configured to: Send DisplayPort data, including the placeholder video data, to the DisplayPort destination device; as well as The process switches to sending DisplayPort data, which includes the first actual video data instead of the placeholder video data, to the DisplayPort sink device without retraining the link, wherein the timing of the first actual video data is the same as the timing of the placeholder video data.

11. The DFP apparatus of claim 7, further comprising a placeholder video engine configured to generate placeholder video data, wherein, The downstream video engine is also configured to: Send DisplayPort data, including the placeholder video data, to the DisplayPort destination device; Switch to sending DisplayPort data, which includes the first actual video data instead of the placeholder video data, to the DisplayPort sink device without performing link training again; Use the placeholder video data generated by the placeholder video engine to generate DisplayPort data including the placeholder video data; as well as The first actual video data received by the extended interface is used to generate DisplayPort data that includes the first actual video data.

12. A non-transitory computer-readable medium having computer-executable instructions stored thereon, the computer-executable instructions being responsive to execution by one or more processors of a downstream-facing port DFP device, causing the DFP device to perform actions for switching a DisplayPort connection on an extended medium, the actions comprising: The DFP device performs link training with the DisplayPort sink device coupled to the DFP device; The DisplayPort data is sent to the DisplayPort sink device, the DisplayPort data including first actual video data received by the DFP device from the extended medium, wherein the first actual video data is received from a first extended device connected to the first DisplayPort source device; The DFP device receives commands for pairing with a second extension device connected to the second DisplayPort source device; and The DFP device sends DisplayPort data, which includes second actual video data received from the second extension device instead of the first actual video data, to the DisplayPort sink device without retraining the link between the DFP device and the DisplayPort sink device.

13. The computer-readable medium according to claim 12, wherein, The first actual video data and the second actual video data have the same timing sequence.

14. The computer-readable medium of claim 12, wherein, The timing sequence of the first actual video data is different from that of the second actual video data, and the action further includes: The DFP device generates DisplayPort data including at least five idle modes; and The DisplayPort data is sent by the DFP device, and the DisplayPort data includes at least five idle modes between the DisplayPort data including the first actual video data and the DisplayPort data including the second actual video data.

15. The computer-readable medium according to claim 12, wherein, The actual video data is first actual video data received from a first extension device connected to a first DisplayPort source device, and the action further includes: The DFP device sends DisplayPort data, including placeholder video data generated by the DFP device, to the DisplayPort sink device; and The DFP device switches to sending DisplayPort data, which includes the first actual video data instead of the placeholder video data, to the DisplayPort sink device without performing link training again.

16. The computer-readable medium of claim 15, wherein, The timing sequence of the first actual video data is the same as that of the placeholder video data.

17. The computer-readable medium of claim 15, wherein, The action also includes: Using the placeholder video data generated by the DFP device, DisplayPort data including the placeholder video data is generated; and DisplayPort data including the first actual video data is generated using the first actual video data received from the extended medium.

Images