Display devices with bridges for application tethering

The display device's bridge circuitry automatically tethers downstream devices to applications based on user interactions, addressing manual configuration issues and ensuring seamless transitions, thus enhancing productivity.

WO2025254643A1PCT designated stage Publication Date: 2025-12-11HEWLETT PACKARD DEVELOPMENT COMPANY LP
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/US2024/032382
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-06-04
Publication Date
2025-12-11

AI Technical Summary

Technical Problem

Existing display devices require manual configuration to switch downstream devices between host devices, disrupting applications and reducing productivity.

Method used

A display device with bridge circuitry that automatically tethers downstream devices to applications based on user interactions, such as cursor movements or window dragging, allowing seamless transitions without manual intervention.

Benefits of technology

Enables smooth switchover of downstream devices between host devices, maintaining application continuity and enhancing user productivity by eliminating disruptive manual configurations.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2024032382_11122025_PF_FP_ABST
    Figure US2024032382_11122025_PF_FP_ABST
Patent Text Reader

Abstract

A display device including a display panel, a first upstream port, a second upstream port, and bridge circuitry may be provided. The first upstream port receives, from a first host device, first content. The second upstream port receives, from a second host device while the first port concurrently receives the first content, second content. The bridge circuitry displays the first content on a first portion of the display panel and the second content on a second portion of the display panel; connects a downstream device to the first host device to enable information exchange with an application executing on the first host device; and tethers the downstream device to the application executing on the first host device.
Need to check novelty before this filing date? Find Prior Art

Description

DISPLAY DEVICES WITH BRIDGES FOR APPLICATION TETHERINGBACKGROUND

[0001] A display device with a display screen may connect to a host computing device. The host computing device may include a desktop computer, a thin client, a notebook, a tablet, a smart phone, a wearable device, or the like. The display device may display, on the display screen, content received from the host computing device. The content, also referred to as display content or video content, may be in the form of a video feed that includes a series of frames or images provided at a particular rate and displayed in sequence (e g., at a certain number of frames per second). The display device may also connect to downstream devices to enable a user to interact with the host computing device. For example, the downstream devices may include input devices to receive user input or input from another device, output devices to provide output to a user or other device, and / or input / output devices (I / O) devices that can receive input and provide output (e.g., simultaneously or separately). Example downstream devices include a mouse, a keyboard, a touchpad, a touch screen, a camera, a microphone, a stylus, a (further) display, a speaker, headphones, a printer, or the like.BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following draw ings are provided to help illustrate various features of examples of the disclosure and are not intended to limit the scope of the disclosure or exclude alternative implementations.

[0003] FIG. 1 A is a block diagram of an example computing environment according to some aspects of the present disclosure.

[0004] FIG. IB is a block diagram of example block circuitry according to some aspects of the present disclosure.

[0005] FIG. 2 is an example host device according to some aspects of the present disclosure.

[0006] FIG. 3 is a flowchart that illustrates an example process for application tethering according to some aspects of the present disclosure.

[0007] FIGS. 4A and 4B illustrate an example of the computing environment of FIG. 1A implementing aspects of an application tethering process, according to some aspects of the present disclosure.

[0008] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate examples of the disclosure and, together with the description, explain principles of the examples.

[0009] In the drawings, like reference symbols and numerals indicate the same or similar components. Like elements in the various figures are denoted by like reference symbols and numerals for consistency. Unless otherwise indicated, like elements and method steps are referred to with like reference numerals.DETAILED DESCRIPTION

[0010] The following describes technical solutions with reference to the accompanying drawings.

[0011] An example display device, for example, a monitor, may include a display screen or panel, multiple upstream ports to removably connect different host devices to the display device, and multiple dow nstream ports to removably connect different downstream devices to the host devices. Connecting a set of downstream devices and host devices to a single displaydevice may improve an experience of the user. For example, the display device may simultaneously^ display or present content (e.g., video content) from each host device coupled to the display device on the display screen. In an example with two host devices connected to the display device, the display device may control the display screen as a split-screen with a left portion of the display screen displaying content from a first host device, and with a right portion of the display screen displaying content from a second host device. In some examples, with this arrangement, a user may have connected to the display device a first host computing device associated with a job or work (also referred to as a “work computer”) and a second host computing device that is a personal device (also referred to as a “personal computer”).

[0012] In addition to sharing a display7device between multiple host devices, the display device may enable the host devices to share downstream devices. For example, a keyboard, mouse, headset, speaker, and / or other downstream devices may be connected to the displaydevice. A device bridge or hub in the display device may control to which host device each of the downstream devices is connected at a particular time. Thus, a user may avoid having duplicate downstream devices for each host device (e.g., two keyboards, two mice, etc., one for each of two host devices) and may avoid physically uncoupling and coupling each downstream device to the appropriate host device for use therewith.

[0013] Still, controlling the device bridge or hub to connect a particular downstream device to a particular host may involve manual configuration via a graphical user interface on the display device (e.g., generated by one of the host devices) each time re-assignment is desired.Further, the resulting switchover can be disruptive to applications currently executing on the host devices, reducing productivity' of the systems and user.

[0014] Described herein are systems, methods, and media that address these and other technical challenges. For example, embodiments provided herein include a display device that may assign or tether a downstream device to an application executing on one of the host devices, in contrast to assignment of a downstream device to a host device more generally. Such tethering enables smooth transition of use of a downstream device with an application on a first host device to use of the downstream device with the application on a second host device (also referred to as a switchover). The tethering may also involve the sharing of preferences and other related data for the downstream device and application from the first host device to the second host device. Further, in some examples, the display device maydetect a switchover event based on user cursor control and cause the switchover, avoiding manual configuration via a specific graphical user interface otherwise available for assigning downstream devices to applications or host devices. For example, moving a mouse cursor or dragging a window- from a portion of the display screen associated with the first host device to a second portion of the display screen associated with the second host device may be a switchover event that is detected and results in a switchover.

[0015] Examples are described in detail with reference to the accompanying drawings.

[0016] FIG. 1 A show s a block diagram of an example computing environment 100. Referring to FIG. 1 A, a configuration of the computing environment 100 may include a monitor 110, downstream devices 120 and upstream devices 130. The downstream devices 120 may include a keyboard 122, a pointing device 124, and at least one auxiliary device 126. The upstream devices 130 may include host device 132, and host device 134. It should be understood that the computing environment 100 may include additional components that are not shown in FIG. 1A.

[0017] The monitor 110 in the example computing environment 100 of FIG. 1 A is a display device that may include downstream ports 111, bridge circuitry- 112 (also referred to as bridge control circuitry or control circuitry ), and upstream ports 113. The monitor 110 may include a display panel 114, and an enclosure 115. The enclosure 115 is a protective housing that may surround and encase the downstream ports 1 11, bridge circuitry 112 and upstream ports 113. The downstream ports 111, bridge circuitry- 112 and upstream ports 113 are electronically- interconnected. Those skilled in the art will appreciate that there may be additional circuitry in the monitor 110 that is not shown in FIG. 1A.

[0018] The bridge circuitry' 112 in the example computing environment 100 of FIG. 1 A is circuitry that may control the overall operations of the monitor 110, as will be explained in detail. FIG. IB shows a block diagram of an example of the bridge circuitry 112 that may include a scaler processor 116, a hub controller 117, monitor memory’ 118, and switching circuitry 119.

[0019] With continued reference to FIG. IB, the scaler processor 116 includes circuitry that may adjust the resolution and aspect ratio of incoming display content (e.g., video content) to the resolution and aspect ratio of the display panel 114.

[0020] When the scaler processor 116 adjusts the resolution the incoming video content, the scaler processor 116 may upconvert or downconvert the incoming video content. An up- conversion of the incoming video content may occur when the scaler processor 116 increases the resolution of the incoming video content to match the resolution of the display panel 114. A down-conversion of the incoming video content may occur when the scaler processor 116 reduces the resolution of the incoming video content to match the resolution of the display panel 114.

[0021] To adjust the aspect ratio of the incoming video content, the scaler processor 116 may upscale or downscale the incoming video content. An upscaling of the incoming video content may occur when the scaler processor 116 increases the yvidth-to-height ratio of the incoming video content to match the yvidth-to-height ratio of the display panel 114. A downscaling of the incoming video content may occur yvhen the scaler processor 116 decreases the width-to-height ratio of the incoming video content to match the width-to- height ratio of the display panel 114.

[0022] The scaler processor 116 may be implemented as any suitable processing circuitry' including, but not limited to, at least one of a microcontroller, a microprocessor, a single processor, and a multiprocessor. The scaler processor 116 may include at least a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application specific integrated circuit (ASIC), field programmable gate arrays (FPGA), or the like, and may have a plurality of processing cores. In some examples, the scaler processor 116 may include or may be referred to as a video scaler integrated circuit (IC) or scaler.

[0023] The hub controller 117 includes circuitry that may manage the downstream ports 111 and the upstream ports 113. Specifically, the hub controller 117 may manage the flo v of information between the downstream ports 111 and the downstream devices 120 when any ofthe downstream devices 120 are connected to any of the downstream ports 111. Hub controller 117 may manage the flow of information between the upstream ports 113 and the upstream devices 130 when any of the upstream devices 130 are connected to any of the upstream ports 1 13. The hub controller 117 may also manage the flow of information between the downstream devices 120 and the upstream devices 130. For example, the hub controller 117 may control the switching circuitry 119 to selectively control each of the downstream devices 120 to connect to a particular one of the upstream devices 130. For example, at a first moment in time, the hub controller 117 may control the keyboard 122 and pointing device 124 to connect to the host device 132 and may control the auxiliary device 126 to connect to the host device 134 and, at a second moment in time, the hub controller 117 may control the keyboard 122. pointing device 124, and the auxiliary device 126 to connect to the host device 134. These particular assignments are merely an example, as other connections may be made between the downstream devices 120 and the upstream devices 130, and other combinations of dow nstream devices 120 and upstream devices 130 may be present. The switching circuitry 119 may include a plurality of controllable switches (e.g., field effect transistors (FETs), bipolar junction transistors (BJTs). or the like) and communicating pathways (e.g., conductors, wires, traces, or the like) to enable the various possible interconnections between the downstream devices 120 and the upstream devices 130.

[0024] The hub controller 117 may be implemented as any suitable processing circuitry including, but not limited to. at least one of a microcontroller, a microprocessor, a single processor, and a multiprocessor. The hub controller 117 may include at least a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application specific integrated circuit (ASIC), field programmable gate arrays (FPGA), or the like, and may have a plurality of processing cores.

[0025] Monitor memory 118 in the example computing environment 100 of FIG. 1A may be any electronic, magnetic, optical, or other physical storage device. Monitor memory 118 may be a non-transitory machine-readable storage medium, where the term “non-transitory” does not encompass transitory propagating signals. Monitor memory 118 may include read-only monitor memory (“ROM”), random access monitor memory (“RAM”), other non-transitory computer-readable media, or a combination thereof.

[0026] Monitor memory7118 may have stored thereon bridge softw are 140 for the bridge circuitry 112. The bridge software 140 may include program code. The program code mayinclude program instructions that are readable and executable by the bridge circuitry 112, also referred to as machine-readable instructions. In some examples, the scaler processor 116 and / or hub controller 117 may execute the program code, or portions thereof, to implement the functionality of the scaler processor 116 and the hub controller 117, respectively, described herein.

[0027] Monitor memory 118 may retain tethering data 142 used by the bridge circuitry 112 when executing the bridge software 140, as will be explained in detail.

[0028] The downstream ports 111 in the example computing environment 100 of FIG. 1A are circuitry that may interconnect, by wire or wirelessly, with one or more of the keyboard 122, the pointing device 124 and the auxiliary' device 126. The downstream ports 111 include circuitry that may enable the monitor 110 to receive information from the keyboard 122, the pointing device 124 and the auxiliary device 126. The circuitry in the downstream ports 111 may enable the monitor 110 to transmit data to the keyboard 122, the pointing device 124 and the auxiliary' device 126. The downstream ports 111 may include D-Port (1) through D-Port (N), with “N'’ being another integer number greater than 1. As will be explained in detail, the data and information may permit a person to interact with the monitor 110. In some examples, the downstream ports 111 may include, for example, a universal serial bus (USB) Type A port, a USB Type B port, a USB Type C port), another USB type port, a Thunderbolt port, or the like.

[0029] The upstream ports 113 in the example computing environment 100 of FIG. 1 A may include U-Port (1) through U-Port (X), with 'X being another integer number greater than 1. For example, U-Port (1) is circuitry that may enable the monitor 110 to receive, by wire or wirelessly, information from the host device 132 and output data to the host device 132. U- Port (2) is circuitry that may enable the monitor 110 to receive, by wire or wirelessly, information from the host device 134 and output data to the host device 134. Although two ports are shown in FIG. 1 A, those skilled in the art will appreciate that the computing environment 100 may include more than U-Port (1) and U-Port (2) in some examples. As will be explained in detail, the upstream ports 113 may communicate with any of the host devices 132, 134. In some examples, the upstream ports 113 may include, for example, a high- definition multimedia interface (HDMI) port, digital visual interface (DVI) port, a DisplayPort (DP) port, a universal serial bus (USB) Type-C (USB-C) port, a Thunderbolt port, or the like.

[0030] The display panel 114 in the example computing environment 100 of FIG. 1 A is an electrical device that may present content as visual information for viewing by a person. The content may be provided as frames by the upstream devices 130 to the bridge circuitry 112 (e.g., the scaler processor 116), which then controls the display panel 114 to display the content. The content may include graphics, text, icons, a graphical user interface (GUI), a graphical desktop, application windows, multimedia content, or combinations thereof. In some examples, the multimedia content may be a still image. The image may be a Graphics Interchange Format (GIF) image file, a Joint Photographic Experts Group (JPEG) image file, and / or any other image file. In other examples, the multimedia content may be a continuous sequence of images that the display panel 114 may display in succession. The continuous sequence of images may be a series of consecutive image frames. The series of consecutive image frames may be a Moving Picture Experts Group (MPEG) video file, and / or any other video file. The display panel 1 14 may be an ultrawide screen that has an aspect ratio greater than 16:9. For example, the display panel 114 may have an aspect ratio of 21:9 or wider.

[0031] The keyboard 122 in the example computing environment 100 of FIG. 1 A is an electronic device that may permit a person to manually input text, characters, commands and other information into the monitor 110. The keyboard 122 may include switches, buttons, and / or knobs that are arranged in a specific layout. The layout may include an array of alphanumeric keys, numeric keys, punctuation marks, and special function keys. The switches, buttons, and / or knobs of keyboard 122 may include mechanical components that are arranged in the specific layout. The switches, buttons, and / or knobs of keyboard 122 may appear virtually on a display screen of the keyboard 122. As will be explained in detail, the monitor 110 may communicate, by wire or wirelessly, with the keyboard 122.

[0032] The pointing device 124 in the example computing environment 100 of FIG. 1A is an electronic device that may permit a person to interact manually with information and video content that may appear on the display panel 114. For example, the bridge circuitry 112 may control the monitor 110 to cause an icon to appear on the display panel 114. The icon may be a cursor or a pointer. The pointing device 124 may convert a physical motion of the pointing device 124 into a signal that causes the bridge circuitry 112 to control movement of the icon on the display panel 114 when the person physically repositions the pointing device 124. When the person physically maneuvers the pointing device 124, the pointing device 124 may convert any maneuvering of the pointing device 124 into the signal that causes the bridge circuitry 112 to control the movement of the icon on the display panel 114. As otherexamples, the pointing device 124 may convert the physical motion and / or the maneuvering into a signal that instructs the bridge circuitry 112 to manipulate the information and video content that may appear on the display panel 114. The pointing device 124 may be a mouse, a trackball, a trackpad and / or any other device that converts the maneuvering and / or the physical motion into the signals. As will be explained in detail, the monitor 110 may communicate, by wire or wirelessly, with the pointing device 124.

[0033] An auxiliary device 126 in the example computing environment 100 of FIG. 1A is an electronic device that may include a headset or a headphone, an earphone or earbud, a speaker, a microphone, a camera, a projector, a display device, a smartphone, a lamp, a fan, a heatsink, a memory module, a USB storage device, a stylus, a liquid cooling pump, and / or any other electronic equipment that may electronically communicate with the monitor 110. As will be explained in detail, the monitor 110 may communicate, by wire or wirelessly, with the auxiliary device 126. Additionally, although FIG. 1 A illustrates a single auxiliary device 126, in some examples, the dow nstream devices 120 comprise a plurality of auxiliary devices 126, each connected to a respective port of the downstream ports 111.

[0034] Host devices 132, 134 in the example computing environment 100 of FIG. 1A may include host device 132 and host device 134. One or both of the host devices 132, 134 may be a desktop or computer tow er, a tablet, a telephone, a smartphone, a laptop, a television set, or any other electronic equipment that may exchange data and information electronically with the monitor 110. One or both of the host devices 132, 134 may be a mobile electronic device or may be a stationary electronic device. Additionally, although FIG. 1A illustrates two host devices 132, 134, in some examples, the upstream devices 130 comprise three or more host devices, each similar to the host devices 132 or 134 and being connected to a respective port of the upstream ports 113.

[0035] FIG. 2 illustrates a host device 200 that is an example of the host device 132, the host device 134, or each of host devices 132 and 134. As will be explained in detail, the monitor 110 may communicate, by wire or wirelessly, with any of the host devices 132, 134.

[0036] Referring to FIG. 2, the host device 200 is an electronic apparatus that may include a host controller 210, host memory 220. a host data port 230 and a host screen 240. Those skilled in the art will appreciate that there may be additional circuitry in the host device 200 that is not shown in FIG. 2.

[0037] The host controller 210 may be implemented as any suitable electronic circuitry including, but not limited to at least one of a microcontroller, a microcontroller, a singlecontroller, and a multi-controller. The host controller 210 may include at least one of a video scaler integrated circuit (IC), an embedded controller (EC), a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application specific integrated circuit (ASIC), field programmable gate arrays (FPGA), or the like, and may have a plurality of processing cores. The host controller 210 may control the overall operations of the host device 200. The host controller 210 may execute software stored on the host memory7220 to perform functions of the host controller 210 and / or the host device 200 described herein. Although the host device 200 has been depicted as including a single host controller 210, it should be understood that the host device 200 may include multiple processors, multiple cores, or the like, without departing from the scope of the host device 200 disclosed herein.

[0038] Host memory 220 may be a non-transitory processor readable or computer readable storage medium. Host memory7220 may' be any electronic, magnetic, optical, or other physical storage device that stores executable instructions and / or data. Host memory7220 may retain filters, rules, data, or a combination thereof. Host memory7220 may comprise read-only host memory 220 (“ROM”), random access host memory 220 (“RAM”), other non-transitory7computer-readable media, or a combination thereof. In some examples, host memory' 220 may retain firmware.

[0039] Host memory7220 may retain software for the host device 200. The software stored in host memory 220 may include host applications 222, host drivers 224, and a bridge application 226 for the host device 200. The software stored in the host memory 220 may further include an operating system (OS). The software for the host device 200 may include program code. The program code may include program instructions that are readable and executable by the host controller 210, also referred to as machine-readable instructions. Host memory 220 may also retain data for the host device 200. which may include bridge data 228, as well as other data for use by the host applications 222, the host drivers 224, and the like.

[0040] Each host application of the host applications 222 may include a software program that is designed cause the host controller 210 to perform specific tasks upon execution by the host controller 210. The host applications 222 may include, for example, a word processing software application, a video conference software application, an electronic mail (e-mail) software application, a web browser software application, and / or other applications.

[0041] Host drivers 224 may enable the host controller 210 to interact with associated hardware components (e g., the downstream devices 120). For example, a host driver of thehost drivers 224 may include software specialized to facilitate communication between the host device 200 and any hardware component that is controllable by the host controller 210.

[0042] The bridge application 226 may include a software program that is designed to enable the host controller 210 to communicate with the bridge circuitry 112 of the monitor 110. As described in further detail below, execution of the bridge application 226 by the host controller 210 may generate a graphical user interface (GUI) on the display panel 114. Via interaction with the GUI, a user may input configuration data that configures or controls the bridge circuitry 112. The bridge application 226 may also enable communication of application identifiers, downstream device identifiers, downstream device settings between the host device 200, the bridge circuitry 112, and other host devices coupled to the monitor110.

[0043] The bridge data 228 may include application identifiers for each application residing on the host device 200 and other host devices coupled to the monitor, a status of each of these applications (e.g., inactive, suspended, executing) with respect to each host device, downstream device identifiers for each downstream device coupled to the downstream ports111, and downstream device settings for each of the downstream devices coupled to the downstream ports 11 1 or for each of the downstream devices coupled to the downstream ports 111 and connected to the host device 200 via the bridge circuitry 112. In some examples, the bridge application 226, via execution by the host controller 201, enables the host controller 201 to communicate with the bridge circuitry 112 (e.g., the hub controller117) to obtain the tethering data 142 from the monitor memory 118 to update the bridge data 228 (e.g., based on changes to the tethering data 142 resulting from communications with another host device 200), and to communicate with the bridge circuitry 112 (e.g., the hub controller 117) to provide updates from the bridge data 228 to the tethering data 142. Accordingly, the bridge data 228 for each host device 200 (e.g., for the host device 132 and the host device 134) and the tethering data 142 may include copies of similar information, with the tethering data 142 serving as a middle entity so that the host device 132 and the host device 134 may share information with one another and thereby maintain consistent information system-wide for the computing environment 100. In some examples, the bridge data 228 for each host device may include additional information that is not shared with other host devices.

[0044] In the example of FIG. 1A, the host data port 230 includes electronic circuitry that may allow the host device 200 to electronically communicate with any of the upstream ports113. The host data port 230 is circuitry that may facilitate the transfer of information between the monitor 110 and the host device 200 when the host device 200 is electronically connected to any of the upstream ports 113. In some examples, the host data port 230 may be, for example, a high-definition multimedia interface (HDMI) port, digital visual interface (DVI) port, a DisplayPort (DP) port, a universal serial bus (USB) Type-C (USB-C) port, a Thunderbolt port, or the like.

[0045] The host screen 240 is an electrical device that may present content for viewing when the host screen 240 receives the content from the host controller 210. The host screen 240 may be present when the host device 200 is, for example, a laptop or tablet, or other computing device with an integrated screen. In other examples, the host screen 240 may be absent from the host device 200, for example, when the host device 200 is a desktop or computer tower.

[0046] FIG. 3 is a flowchart that illustrates an example process 300 for tethering a downstream device to an application of a host device. The process 300 is described as being carried out by the monitor 110 and in conjunction with the computing environment 100 described above. For example, the bridge circuitry 112 of the monitor 110 (e.g., based on executing instructions stored in the monitor memory 118) may execute the process 300. However, in some embodiments, the process 300 is implemented by another system and / or in conjunction with another computing environment. Additionally, although the blocks of the process 300 are illustrated in a particular order, in some embodiments, one or more of the blocks may be executed partially or entirely in parallel, may be executed in a different order than illustrated in FIG. 3, or may be bypassed.

[0047] In block 305, a display device (e.g., the monitor 110) displays first content on a first portion of a display panel that is received from a first host device and second content on a second portion of the display panel that is received from a second host device. For example, with reference to FIG. 1A, the bridge circuitry 112 of the monitor 110 may receive first content (e.g., representing visual information for display) from the host device 132 and may receive second content (e.g., representing further visual information for display) from the second host device 134 via respective upstream ports U-Port (1) and U-Port (2) of upstream ports 113. The bridge circuitry 1 12 (e.g., via the scaler processor 116) may control the display panel 114 to display the first content on a left-side portion of the display panel 114 and to display the second content on a right-side portion of the display panel 114 (e.g., in a split-screen manner). In some examples, the sides are swapped such that the left-side andright-side portions of the display panel 114 may display the second content and first content, respectively. In some examples, the display panel 114 is apportioned between the first and second portions in another manner, for example, between top and bottom portions or between non-rectangular portions. In some examples, the portions are of equal size so that, for example, the first content is displayed on a left half of the display panel 114 and the second content is displayed on right half of the display panel 114. In other examples, the portions are of unequal size so that, for example, the first content covers more area of the display panel than the second content, or vice versa.

[0048] In block 310, bridge circuitry of the display device connects a downstream device to the first host device to enable information exchange with an application executing on the first host device. For example, with reference to FIG. 1A, the bridge circuitry 112 of the monitor 110 may connect the auxiliary device 126 to the host device 132, which may be executing an application (e g., of the host applications 222), or, more particularly, a first instance of the application. To make the connection, the bridge circuitry 112 (e.g., the hub controller 117) may control the switching circuitry' 119 to connect the auxiliary device 126 to the host device 132. Once connected, the host device 132 may receive data from the auxiliary device 126 that is intended for consumption or use by the application via the downstream ports 1 11 and the bridge circuitry 112; may transmit data from the application to the auxiliary device 126 via the downstream ports 111 and the bridge circuitry' 112; or may both receive such data and transmit such data. Accordingly, in block 310, the bridge circuitry’ 112 may also be described as connecting the downstream device to the application executing on the first host device.

[0049] As an example for discussion purposes, the auxiliary' device 126 may be a webcam and the application may be a video conferencing software application that enables a user of the computing environment 100 to conduct a video conference with another user at another computing device via a network. In such examples, the webcam may transmit captured video and / or audio data via the bridge circuitry 112 to the host device 132 for use by the video conferencing software application, and / or the video conferencing software application executing on the host device 132 may transmit control signals via the bridge circuitry' 112 to the webcam to enable and / or disable such capture of video and / or audio data. Of course, the auxiliary device 126, the application, and the transmitted data may each be of another type in other examples.

[0050] In block 315, the bridge circuitry' tethers the downstream device to the application executing on the first host device. For example, the bridge circuitry 112 may link a deviceidentifier of the dow nstream device to an application identifier of the application. The device identifier may be a unique identifier for the particular downstream device. Additionally or alternatively, in some examples, the device identifier indicates a type or class of the downstream device (e.g., indicates that the downstream device is a webcam type, a speaker type, a keyboard ty pe, a headset type, etc.). The device identifier may be or include an alphanumeric code that maps to a downstream name, type, version, etc., and / or may be or include a common name for the downstream device used in the marketplace. The application identifier may be a unique identifier for the application, for example, that is indicative of a particular instance of the application and / or that is indicative of a particular application (e.g., including version number). The application identifier may be or include an alphanumeric code that maps to an application name, type, version, etc., and / or may be or include a common name for the application used in the marketplace.

[0051] To link the device identifier and the application identifier, the bridge circuitry 1 12 may store (as tethering data) the device identifier and the application identifier in a memory of the monitor 110 (e. g. , the monitor memory 118) in a manner that links the elements . F or example, the monitor memory 118 may store and maintain the tethering data, including a tethering data table, as part of the tethering data 142. In such a tethering data table, each downstream port 1 11 corresponds to an associated row of the tethering data table. Each row of the tethering data table may have a plurality of columns to store tethering data for each downstream port. The columns may include, for example, a device identifier column, an application identifier column, device settings column(s), and a current host device column. Accordingly, continuing with the above example for discussion purposes, one row of the tethering data table may include a first row for D-Port 1 of downstream ports 111, where the row- includes a device identifier column with a value identifying the webcam (as a device identifier), an application identifier column with a value identifying the video conference software application (as an application identifier), device settings column(s) with values indicating device settings of the webcam (e.g., a video brightness setting, a video contrast setting, a microphone volume level setting, camera enabled / disabled setting, microphone muted / unmuted setting, etc.), a current host device column with a value indicating the host device to which the downstream device is connected (e.g., the host device 132), an indication of whether the application resides on the first host device, a current status of the application on the first host device (e.g., inactive (not yet launched), paused, or executing), an indication of whether the instance of the application resides on the second host device, and / or a currentstatus of the instance of the application on the second host device (e.g., inactive (not yet launched), paused, or executing). The indications of whether the instance of the application resides on the host devices, and the status of the instances of the application on the host devices, may be provided to the bridge circuitry 112 by the respective host devices (e.g., via the respective bridge applications 226 executing on the host devices). In some examples, the bridge circuitry 112 may link the device identifier of the dow nstream device to the application identifier of the application using other table formats or other techniques.

[0052] The particular device settings stored in the tethering data 142 may vary by type of downstream device. For example, a streaming light as a downstream device may include a brightness setting to control the brightness of the streaming light; speakers as a downstream device may include a volume level setting; a light emitting diode (LED) lighting accessory may include a color setting, a brightness setting, and / or a pattern setting to control the illumination color, brightness, and / or pattern of the LED lighting accessory, etc. Additionally, in some examples, the device settings include application settings for the application to which the downstream device is linked. For example, when the application is a video conferencing software application, the application settings may include current meeting information (e.g., a meeting identifier, a meeting password), which may ultimately be used by the second host device to enable a smooth transition of the application executing on the first host device with the dow nstream devices to the instance of the application executing on the second host device with the downstream device (e.g., a relatively seamless transition of a videoconference between host devices).

[0053] Accordingly, in some examples, to tether the downstream device to the application, the bridge circuitry' 112 may store tethering data in the monitor memory 118 (e.g., as the tethering data 142), where the tethering data stored may include: an application identifier of the application, a device identifier of the downstream device that is tethered to the application, device settings for the downstream device that is tethered to the application, an indication of w hether the application resides on the first host device, a current status of the application on the first host device, an indication of whether the instance of the application resides on the second host device, and / or a current status of the instance of the application on the second host device.

[0054] In block 320, the bridge circuitry detects whether a switching event has occurred. The switching event may indicate a desire to execute, on the second host device, an instance of the application that is tethered to the downstream device. For example, the bridge circuitry112 may detect the switching event based on detecting a desire of the user to execute, on the host device 134, an instance of the application that is tethered to the auxiliary device 126. Accordingly, the application on the host device 132 may be a first instance of the application, and the instance of the application on the host device 134 may be a second instance of the application.

[0055] To detect the sw itching event, the bridge circuitry may receive an indication of the switching event from one of the upstream devices 130 (e.g., from the host device 132 or the host device 134). For example, and as explained further below, the host device 132 may indicate to the bridge circuitry 1 12 that a switching event has occurred, via a message transmitted over upstream ports 113, in response to movement of a cursor on the display panel 114, dragging of a window- on the display panel 114, or an explicit request for the switching event by a user via a graphical user interface on the display panel 114.

[0056] With respect to the cursor example, the host device 132 may receive cursor movement input from the pointing device 124 via the bridge circuitry 112 and, responsive to the cursor movement input, may output to the monitor 110 location information for the cursor (e.g., as part of content that the host device 132 provides to the monitor 110 for display on the display panel 1 14). The bridge circuitry 112 (e.g., via the scaler processor 116) may illustrate the cursor on the first portion of the display panel 114 corresponding to the location information. The host device 132 may continuously update the location of the cursor on the display panel 114 based on further cursor movement input from the pointing device 124. When the cursor moves from the first portion (associated with the host device 132) to the second portion of the display panel 114 (associated with the host device 134), the host device 132 may detect the switching event. For example, the host device 132 may detect based on further cursor movement input from the pointing device 124 that the user has directed the cursor to cross a boundary separating the first portion and the second portion of the display panel 114 and, at the point when the cursor crosses the boundary, the host device 132 may detect the switching event.

[0057] With respect to the window' example, the pointing device 124 may also be used to drag a window of the application (to which the downstream device is tethered) on the displaypanel 1 14. For example, the cursor may be placed over a title bar of the window, a user selection input (e.g., mouse click or button press) on the pointing device 124 may be received, and then the pointing device 124 may be controlled to move the w indow of the application on the display panel 114 (e.g., by moving a tracking ball of the pointing device124). When the window of the application moves from the first portion (associated with the host device 132) to the second portion of the display panel 114 (associated with the host device 134), the host device 132 may detect the switching event. For example, the host device 132 may detect based on movement input from the pointing device 124 that the user has directed the window to cross a boundary’ separating the first portion and the second portion of the display panel 114 and, at the point when the window crosses the boundary7(in full or a partial amount), the host device 132 may detect the switching event.

[0058] With respect to the explicit request example, as previously described, each of the host devices 132, 134 may execute the bridge application 226. For example, the host device 132 may execute the bridge application 226, which may cause the host device 132 to control the monitor 110 to generate a graphical user interface (GUI) for configuring the bridge circuitry 112. The keyboard 122 and / or pointing device 124 may receive user input, which may be transmitted via the bridge circuitry7112 to the host device 132 to enable a user to interact with the GUI (e.g., to cause the GUI to receive user input). In some examples, the GUI may receive such user input that explicitly links a downstream device to an application or instance of an application on one of the host devices 132, 134. For example, the GUI may display a list of the downstream devices 120, the host applications 222 residing on the host device 132 and the host device 134 (e.g., as maintained in the bridge data 228), and each of the host applications 222 currently linked to one of the downstream devices 120. Via user input to the GUI, a user may modify the linking of host applications 22 and downstream devices 120 (e.g.. via drop down menus, radio buttons. Tillable text boxes, and the liked). Accordingly, in some examples, the GUI associated with the bridge application executing on the host device 132 (or on the host device 134) may receive user input that indicates a switchover event. For example, such user input may include a request received via the GUI to connect the downstream device (e.g., the auxiliary device 126) to an instance of the application executing on the host device 134.

[0059] As illustrated in FIG. 3, the bridge circuitry 112 may continue to execute block 320 until a switching event is detected, as which point, the process 300 proceeds to block 325. The process 300 may also be exited (e.g., while waiting in block 320 for a switching event or at another point) in response to, for example, physical uncoupling of the downstream device from the downstream ports 111, physical uncoupling of one of the host devices from the upstream ports 113, or other actions.

[0060] In block 325, in response to detecting the switching event, the bridge circuitry may disconnect the downstream device from the first host device. For example, the bridge circuitry 112 may disconnect the auxiliary device 126 from the host device 132. Additionally, in response to detecting the switching event, in block 330, the bridge circuitry may connect the downstream device to the second host device to enable information exchange between the downstream device and the instance of the application on the second host device. For example, the bridge circuitry 112 may connect the auxiliary device 126 to the host device 134 (and / or to the instance of the application executing on the host device 134). In some examples, the hub controller 1 17 controls the switching circuitry 119 to disconnect the downstream device (e.g., the auxiliary' device) from the first host device (e.g., the host device 132) and to connect the downstream device to the second host device (e.g., the host device 134) in blocks 325 and 330. In some examples, control of the switching circuitry 119 causes both the disconnection of block 325 and the connection of block 330 to occur simultaneously.

[0061] After connecting the downstream device to the second host device, information is exchanged between the downstream device and the instance of the application on the second host device. For example, continuing with the above webcam example for discussion purposes, after connecting the webcam (i.e., the downstream device in this example) to the host device 134 (the second host device in this example), the w ebcam may transmit captured video and / or audio data to the instance of the video conferencing softw are application executing on the host device 134 via the bridge circuitry’ 112. Similarly, the host device 134 may transmit control signals to the webcam via the bridge circuitry 112 to enable and / or disable such capture of video and / or audio data.

[0062] Accordingly, through the process 300, the downstream device is tethered to the application executing on different host devices, in contrast to merely being connected to a particular host device.

[0063] In some examples, in response to the switching event detected in block 320, the bridge circuitry 112 outputs, to the second host device (e.g., the host device 134), tethering data including an application identifier that identifies the application, a device identifier that identifies the downstream device, and device settings for the downstream device that is tethered to the application. The bridge application 226 executing on the second host device may receive the tethering data. In response to receiving the tethering data, the bridge application 226 may identify the application based on the application identifier and cause launching or resuming of the application on the second host device by transmitting a requestto launch or resume the application to an operating system executing on the second host device. In response to receiving the tethering data, the bridge application 226 may also connect the downstream device identified by the identifier to the instance of the application executing on the second host device. In response to receiving the tethering data, the bridge application 226 may also configure the settings of the downstream device (e.g., used or controlled by the instance of the application executing on the second host device) according to the device settings received as part of the tethering data.

[0064] In some examples, the switching event is specifically associated with the application, for example, when the switching event is an explicit request or when a window of the application is dragged from the first portion to the second portion of the display panel 114. In such cases, the bridge circuitry 112 may receive an indication of the application as being associated with the switching event when the bridge circuitry 112 detects the switching event in block 320. And, in response to such a switching event, the bridge circuitry 1 12 outputs to the second host device (e.g., the host device 134) tethering data for that application, as discussed above.

[0065] In some examples, the switching event is generic, for example, when the switching event results from moving of a cursor from the first portion to the second portion of the display panel 114. In such cases, the bridge circuitry 112 may identify the application as being associated with the switching event based on predetermined settings stored in the tethering data 142 that associates a generic switching event to the application. And, in response to such a switching event, the bridge circuitry 112 outputs to the second host device (e.g., the host device 134) tethering data for that application, as discussed above.

[0066] In some examples, the application of the first host device (e.g., the host device 132) is tethered to multiple downstream devices. In response to a switching event associated with the application, the bridge circuitry 112 outputs to the second host device (e.g., the host device 134) tethering data for the application, which may include the application identifier, a device identifier for each downstream device tethered to the application, and device settings for each downstream device tethered to the application. The bridge application 226 executing on the second host device may receive the tethering data for the application. In response to receiving the tethering data, the bridge application 226 may identify the application based on the application identifier and cause launching or resuming of the application on the second host device, may connect the downstream devices identified by the device identifiers to the instance of the application executing on the second host device, and may configure thesettings of the downstream devices according to the device settings, in a similar manner as discussed above with respect to the switching event associated with the application tethered to one downstream device.

[0067] In some examples, multiple applications of the first host device (e.g., the host device 132) are tethered to respective downstream devices, and the multiple applications are associated with the switching event detected in block 320, whether specifically or via predetermined settings. In response to such a switching event, the bridge circuitry 112 outputs to the second host device (e.g., the host device 134) tethering data for each respective application, in a similar manner as discussed above with respect to one application. The bridge application 226 executing on the second host device may receive the tethering data for the multiple applications. In response to receiving the tethering data, the bridge application 226 may identify the applications based on the application identifiers and cause launching or resuming of the applications on the second host device, may connect the downstream devices identified by the device identifiers to the instances of the applications executing on the second host device, and may configure the settings of the dow nstream devices according to the device settings, in a similar manner as discussed above with respect to the switching event associated with one tethered application.

[0068] In some examples, in response to the switching event detected in block 320, the bridge circuitry 112 suspends the application (or applications) associated with the switching event on the first host device (e.g., the host device 132). To suspend the application(s), the bridge circuitry 112 may send a request to the first host device to suspend the application(s). The bridge application 226 executing on the first host device may then send a request to suspend the application(s) to the operating system executing on the first host device, which may, as a result, suspend the application(s). In some examples, where the switching event originates in the first device and is initially detected by the first host device (and communicated to the bridge circuitry 112), the first host device may determine to suspend the application based on the initial detection, rather than based on a request from the bridge circuitry 112.

[0069] In response to a further switching event (e.g., that is indicative of a desire of the user to again execute the application that is tethered to the downstream device on the first host device) detected by the bridge circuitry 112, the bridge circuitry 112 may resume the application executing on the first host device (e.g., the host device 132). To resume the application, the bridge circuitry 112 may send a request to resume the application to the first host device, the bridge application 226 executing on the first host device may receive therequest and send a request to resume the application to the operating system executing on the first host device, which may, as a result, resume the application. Additionally, in response to the further switching event detected by the bridge circuitry 112, the bridge circuitry 112 may suspend the instance of the application executing on the second host device (e.g., the host device 134). To suspend the instance of the application, the bridge circuitry 112 may send a request to suspend the instance of the application to the second host device, the bridge application 226 executing on the second host device may receive the request and send a request to suspend the instance of the application to the operating system executing on the second host device, which may, as a result, suspend the application. In response to this further switching event, the bridge circuitry may operate similar to as described with respect to the switching event detected in block 320, albeit with roles of the host devices reversed. For example, in response to this further switching event, the bridge circuitry 112 may also: disconnect the downstream device from the second host device, connect the downstream device to the first host device (and the application executing thereon), and may output tethering data to the first host device including, e.g.. the application identifier for the application, the device identifier for the downstream device, and device settings).

[0070] Although the further switching event is described with respect to the application and the downstream device, the further switching event may correspond to multiple applications and / or multiple downstream devices, in a similar manner as described above with respect to the switching event being applicable to multiple applications and / or multiple downstream devices.

[0071] In some examples, before connecting the downstream device to the second host device in block 330 (e.g., as part of tethering the downstream device to the application in block 315 or in response to detecting a switching event in block 320), the bridge circuitry' 112 also determines whether an instance of the application that is tethered to the downstream device resides on the second host device (e.g., based on the tethering data 142). When the bridge circuitry 112 determines that the second host device does not have the instance of the application, the bridge circuitry' 112 may bypass block 330, portions of block 330, and / or other blocks of the process 300. When the bridge circuitry’ 112 determines that the second host device does have the instance of the application, the bridge circuitry 112 may connect the downstream device to the second host device in block 330 further in response to determining that the application resides on the second host device in combination w ith detecting the switching event in block 320.

[0072] Additionally, in some examples, the bridge circuitry 112 may determine whether the instance of the application that is tethered to the downstream device is currently executing on the second host device (e.g., based on the tethering data 142). When the bridge circuitry 112 determines that the instance of the application is not currently executing upon detection of the switching event in block 320, the bridge circuitry 112 may also request launch of the instance of the application on the second host device in response to detecting the switching event in block 320. The bridge circuitry 112 may transmit the launch request to the second host device. The bridge application 226 executing on the second host device may transmit a request to launch the instance of the application to the operating system executing on the second host device, which may launch the instance of the application.

[0073] In some examples, in response to the switchover event, downstream devices that are not tethered to a particular application are also switched from being connected to the first host device to the second host device. For example, the keyboard 122 and the pointing device 124 may be dow nstream devices that are not tethered to a particular application, at least in some instances. Upon detecting the switchover event in block 320, the bridge circuitry 112 may disconnect the keyboard 122, the pointing device, or both, from the first host device (e.g., the host device 132) and connect the device(s) to the second host device (e.g., the host device 134).

[0074] Although the process 300 and variations thereof are generally described with respect to the computing environment 100 having two host devices each associated with a corresponding portion of the display panel 114, as noted, the computing environment 100 may have more than two host devices, where each of the host devices is associated with a corresponding portion of the display panel 114. In such examples, the process 300 may be executed in a similar manner as described above except that a switching event may occur between any two host devices (e.g., by explicit request or by moving a cursor or dragging a window betw een any two portions of the display panel 114).

[0075] FIG. 4A illustrates a system 400, which is a particular example of the computing environment 100, which may execute the process 300. The system 400 includes the display panel 114 connected to upstream devices including the host device 132 and the host device 134 and connected to downstream devices including the keyboard 122, the pointing device 124, and a webcam 402 (as an example of the auxiliary device 126). The display panel 114 is divided into a first (left) portion 404 associated with the host device 132 and a second (right) portion 406 associated with the host device 134. The first portion 404 and the second portion406 may be substantially equal in size (e.g., within a tolerance of 5% of the total area of the display panel 114) and are divided by a boundary 408. The host device 132 may be executing a video conference software application that is tethered to the webcam 402 and associated with a window 410a on the first portion 404. The video captured by the webcam 402 may be routed by the bridge circuitry 112 (see FIG. 1A) of the monitor 110 to the host device 132 and displayed within the window' 410a. The host device 134 may be executing the bridge application 226 and displaying a GUI 412 of the bridge application 226.

[0076] The bridge circuitry 112 may detect a switching event for the video conference softw are application, as described w ith respect to block 320 in FIG. 3, by, for example, user input at the keyboard 122 and / or pointing device 124 causing a cursor 414 or the window' 410a to move across the boundary 408 or by explicitly requesting a switching event via the GUI 412. As a result, the monitor 110 (via the bridge circuitry 112) may disconnect the webcam 402 from the host device 132, and connect the webcam 402 to the host device 134 and an instance of the video conference softw are application executing on the host device 134 (e.g., launched or resumed by the bridge circuitry 112), as described with respect to blocks 325 and 330 in FIG. 3. In addition, in response to detecting the switching event, the bridge circuitry 112 may suspend the video conference softw are application executing on the host device 132 and / or may output tethering data for the application to the host device 134.

[0077] FIG. 4B illustrates the system 400 after the switching event, where the host device 134 may be executing the instance of the video conference software application that is tethered to the webcam 402 and associated with a window 410b on the second portion 406. The video captured by the webcam 402 may be routed by the bridge circuitry 112 (see FIG. 1A) of the monitor 110 to the host device 134 and displayed within the w indow' 410b. The GUI 412 is not illustrated in FIG. 4B to simplify the drawing, but may still be present in the second portion 406.

[0078] The system 400 and scenario of FIGS. 4A and 4B are merely an example of implementation of a tethering process (e.g., the tethering process 300). Other examples may include different downstream devices, different upstream devices, different applications, and / or different tetherings of downstream device(s) to application(s).

[0079] Certain operations of methods according to the technology, or of systems executing those methods, can be represented schematically in the figures or otherwise discussed herein. Unless otherwise specified or limited, representation in the figures of particular operations in particular spatial order can not necessarily require those operations to be executed in aparticular sequence corresponding to the particular spatial order. Correspondingly, certain operations represented in the figures, or otherwise disclosed herein, can be executed in different orders than are expressly illustrated or described, as appropriate for particular examples of the technology. Further, in some examples, certain operations can be executed in parallel, including by dedicated parallel processing devices, or separate computing devices that interoperate as part of a large system.

[0080] The disclosed technology is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. Other examples of the disclosed technology are possible and examples described and / or illustrated here are capable of being practiced or of being carried out in various ways.

[0081] A plurality of hardware and software-based devices, as well as a plurality of different structural components can be used to implement the disclosed technology. In addition, examples of the disclosed technology can include hardware, software, and electronic components or modules that, for purposes of discussion, can be illustrated and described as if the majority of the components were implemented solely in hardware. However, in one example, the electronic based aspects of the disclosed technology can be implemented in software (for example, stored on non-transitory computer-readable medium) executable by a processor. Although certain drawings illustrate hardware and software located within particular devices, these depictions are for illustrative purposes. In some examples, the illustrated components can be combined or divided into separate software, firmware, hardware, or combinations thereof. As one example, instead of being located within and performed by a single electronic processor, logic and processing can be distributed among multiple electronic processors. Regardless of how they are combined or divided, hardw are and software components can be located on the same computing device or can be distributed among different computing devices connected by a network or other suitable communication links.

[0082] Any suitable non-transitor ' computer usable or computer readable medium may be utilized. The computer-usable or computer-readable medium may be. for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer- readable medium w ould include the follow ing: a portable computer diskette, a hard disk, a random-access memory (RAM), a read-only memory (ROM), an erasable programmableread-only memory (EPROM or Flash memory ), a portable compact disc read-only memory' (CD-ROM), an optical storage device, or a magnetic storage device. In the context of this disclosure, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0083] As used herein in the context of computer implementation, unless otherwise specified or limited, the terms “component / ’ “system.” “module,” “block,” and the like are intended to encompass part or all of computer-related systems that include hardware, software, a combination of hardware and software, or softw are in execution. For example, a component can be, but is not limited to being, a processor device, a process being executed (or executable) by a processor device, an object, an executable, a thread of execution, a computer program, or a computer. By way of illustration, both an application running on a computer and the computer can be a component. Components (or system, module, and so on) can reside within a process or thread of execution, can be localized on one computer, can be distributed between two or more computers or other processor devices, or can be included within another component (or system, module, and so on).

Claims

What is claimed is:

1. A display device comprising: a display panel; a first upstream port to: receive, from a first host device, first content; a second upstream port to: receive, from a second host device while the first upstream port concurrently receives the first content, second content; and bridge circuitry to: display the first content on a first portion of the display panel and the second content on a second portion of the display panel; connect a downstream device to the first host device to enable information exchange with an application executing on the first host device; and tether the downstream device to the application executing on the first host device.

2. The display device of claim 1, wherein the bridge circuitry is to: detect a switching event, wherein the switching event indicates a desire to execute, on the second host device, an instance of the application that is tethered to the downstream device; and in response to detecting the switching event, disconnecting the downstream device from the first host device, and connecting the downstream device to the second host device to enable information exchange between the downstream device and the instance of the application on the second host device.

3. The display device of claim 2, wherein, in response to the switching event, the bridge circuitry is to: output, to the second host device, tethering data including an application identifier that identifies the application, a device identifier that identifies the downstream device, and device settings for the downstream device that is tethered to the application.

4. The display device of claim 2, wherein, to tether the downstream device to the application, the bridge circuitry is to:store tethering data in a memory of the display device, the tethering data including at least one selected from a group including: an application identifier of the application. a device identifier of the downstream device that is tethered to the application, device settings for the downstream device that is tethered to the application, an indication of whether the application resides on the first host device, a current status of the application on the first host device, an indication of whether the instance of the application resides on the second host device, or a current status of the instance of the application on the second host device.

5. The display device of claim 2, wherein the switching event is at least one selected from a group of: a movement of a cursor on the display panel across a boundary from the first portion of the display panel and the second portion of the display panel, a movement of a window of the application on the display panel from the first portion of the display panel and the second portion of the display panel, or a request received in response to a user input via a graphical user interface that is generated on the display device by the first host device or the second host device.

6. The display device of claim 2, wherein, in response to the switching event, the bridge circuitry is further to: suspend the application on the first host device.

7. The display device of claim 4, wherein the bridge circuitry is to: resume, when the bridge circuitry detects a further switching event, the application executing on the first host device and suspend the instance of the application executing on the second host device.

8. A method comprising: displaying, by a display device, first content on a first portion of a display panel that is received from a first host device and second content on a second portion of the display panel that is received from a second host device;connecting, by bridge circuitry' of the display device, a down stream device to the first host device to enable information exchange with an application executing on the first host device; tethering the downstream device to the application executing on the first host device; detecting a switching event, wherein the switching event indicates a desire to execute, on the second host device, an instance of the application that is tethered to the downstream device; and in response to detecting the switching event, disconnecting, by the bridge circuitry, the downstream device from the first host device, and connecting, by the bridge circuitry, the downstream device to the second host device to enable information exchange between the downstream device and the instance of the application on the second host device.

9. The method of claim 8, further comprising: outputting, in response to the switching event, tethering data by the bridge circuitry to the second host device, the tethering data including an application identifier that identifies the application, a device identifier that identifies the downstream device, and device settings for the downstream device that is tethered to the application.

10. The method of claim 8, further comprising: determining whether the instance of the application that is tethered to the downstream device resides on the second host device, wherein connecting the downstream device to the second host device is further in response to determining that the application resides on the second host device.

11. The method of claim 8, further comprising: determining whether the instance of the application that is tethered to the dow nstream device is currently executing on the second host device; and when the bridge circuitry determines that the instance of the application is not currently executing upon detection of the switching event, requesting launch of the instance of the application on the second host device.

12. A non-transitory computer-readable medium storing machine-readable instructions that, when executed by control circuitry including a processor, cause the control circuitry to: display first content on a first portion of a display panel that is received from a first host device and second content on a second portion of the display panel that is received from a second host device; connect a downstream device to the first host device to enable information exchange with an application executing on the first host device; tether the downstream device to the application executing on the first host device; detect a switching event; and in response to detecting the switching event, disconnect the downstream device from the first host device, and connect the downstream device to the second host device to enable information exchange between the downstream device and an instance of the application on the second host device.

13. The computer-readable medium of claim 12, storing machine-readable instructions that, when executed by the control circuitry, cause the control circuitry to: output, in response to the switching event, tethering data by the control circuitry to the second host device, the tethering data including an application identifier that identifies the application, a device identifier that identifies the downstream device, and device settings for the downstream device that is tethered to the application.

14. The computer-readable medium of claim 12, wherein the switching event is at least one selected from a group of: a movement of a cursor on the display panel across a boundary from the first portion of the display panel and the second portion of the display panel, a movement of a window of the application on the display panel from the first portion of the display panel and the second portion of the display panel, or a request received in response to a user input via a graphical user interface that is generated on the display panel by the first host device or the second host device.

15. The computer-readable medium of claim 12, storing machine-readable instructions that, when executed by the control circuitry, cause the control circuitry to:in response to the switching event, suspend the application on the first host device; and resume, in response to detecting a further switching event, the application executing on the first host device and suspend the instance of the application executing on the second host device.

Citation Information

Patent Citations

  • Picture display device and picture display method

    US20070109287A1

  • KVM switch identifying peripheral for computer and method thereof

    US20090063712A1

  • Seamless Switching of USB Devices Connected to a Monitor Hub

    US20150113181A1