Communication method and related equipment

Abstract

The invention provides a communication method and related equipment. The method comprises: at a sink device, sending a request message of a newly added HID to a source device, the request message of the newly added HID comprising an identifier allocated by the sink device for a target HID, device information of the target HID and a report descriptor of the target HID, the target HID being any one of at least one HID inserted into the sink device or an HID newly inserted into the sink device; receiving a response message of a newly added HID from the source device, the response message comprising an identifier of a target HID and first indication information, the first indication information being used for indicating that an input processing module corresponding to the target HID has been successfully loaded in the source device; in response to receiving an input report from the target HID, the input report is sent to the source device, the input report including an identification of the target HID and input report data. According to the technical scheme, richer and richer man-machine interaction requirements at present can be met.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication, and more particularly to a method of communication and related devices. BACKGROUND

[0002] At present, the input mode of television is more and more diversified, and new human interface devices (HID) such as pointing remote control and Bluetooth game handle become new input modes of high-end televisions.

[0003] In a related technical solution, the remote control transparent transmission function is one of the functions of high-definition multimedia interface consumer electronics control (HDMI CEC), and this function is usually used to transmit the remote control key event received by one device (such as a television) to another device in the network. This function is usually used in the case where the television provides a remote control with other modes to control other devices in the system. After the television receives the remote control key event, the remote control event is transmitted to the target device, and the target device responds to the remote control key event.

[0004] The above related technical solution only supports the transparent transmission of the keys of the remote control, and cannot meet the transparent transmission of the input events of other types of HID, and therefore cannot meet the current increasingly rich human-computer interaction requirements.

[0005] Therefore, how to meet the current increasingly rich human-computer interaction requirements is a problem to be solved in the field. SUMMARY

[0006] The present application provides a method of communication and related devices, which is beneficial to meet the current increasingly rich human-computer interaction requirements.

[0007] In a first aspect, an embodiment of the present application provides a communication method, comprising: at a sink device, sending a request message for adding a human interface device (HID) to a source device, the request message for adding the HID being used to request the source device to load an input processing module corresponding to a target HID, and the request message for adding the HID including an identifier allocated by the sink device for the target HID, device information of the target HID, and a report descriptor of the target HID, the target HID being any one of at least one HID already inserted into the sink device or an HID newly inserted into the sink device; receiving a response message for adding the HID from the source device, the response message for adding the HID including the identifier of the target HID and first indication information, the first indication information being used to indicate that the input processing module corresponding to the target HID has been successfully loaded in the source device; and in response to receiving an input report from the target HID, sending the input report to the source device, wherein the input report includes the identifier of the target HID and input report data, and the input report indicates an instant input event generated by the target HID.

[0008] In the above technical solution, by loading the input processing module corresponding to the target HID on the source device, a virtual target HID is created on the source device, so that the sink device can transparently transmit HID events (including HID input reports and HID function reports) obtained from any target HID to the source device. Alternatively, the sink device can also transparently transmit HID events (including HID output reports and HID function reports) obtained from the source device to the target HID connected to the sink device. In this way, not only can the transparent transmission of multiple different HID be supported, but also the insertion of a new HID during use can be supported, thereby meeting the increasingly rich human-computer interaction requirements.

[0009] In combination with the first aspect, in a possible implementation manner of the first aspect, the method further comprises: sending a HID transparent transmission request message to the source device, the HID transparent transmission request message being used to request the source device to allow a HID transparent transmission session between the sink device and the source device, the HID transparent transmission request message including an address of the sink device; receiving a HID transparent transmission response message from the source device, the HID transparent transmission response message including a session identifier allocated by the source device for the HID transparent transmission session; and wherein the request message for adding the HID, the response message for adding the HID, and the input report of the target HID further include the session identifier.

[0010] In the above technical solution, by allocating a session identifier for the HID transparent transmission session of a certain sink device by the source device, the conflict problem of the identifier of the target HID when multiple sink devices simultaneously perform HID transparent transmission to one source device can be avoided.

[0011] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving an output report from the source device, the output report including the identification of the target HID, the session identification, and output report data; and sending the output report to the target HID.

[0012] In the technical solution, the transmission of the output event can be supported in the HID transparent stage.

[0013] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving a first function report from the target HID; and sending the first function report to the source device, wherein the first function report includes the identification of the target HID, the session identification, and first function report data.

[0014] In the technical solution, the transmission of the function report between the HID device and the source device can be supported in the HID transparent stage.

[0015] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving a second function report from the source device, wherein the second function report includes the identification of the target HID, the session identification, and second function report data; and sending the second function report to the target HID.

[0016] In the technical solution, the transmission of the function report between the source device and the HID device can be supported in the HID transparent stage.

[0017] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: in response to detecting that the target HID is unplugged or the target HID is faulty, sending a request message for unloading the HID to the source device, wherein the request message for unloading the HID is used to request the source device to unload an input processing module corresponding to the target HID, and the request message for unloading the HID includes the identification of the target HID and the session identification; and receiving a response message for unloading the HID from the source device, wherein the response message for unloading the HID indicates that the source device has successfully unloaded the input processing module corresponding to the target HID.

[0018] In the technical solution, the unplugging of the HID device on the sink device can be supported in the HID transparent stage.

[0019] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: sending an end HID transparent transmission request message to the source device, the end HID transparent transmission request message being used to inform the source device to end the HID transparent transmission session, and the end HID transparent transmission request message including the session identifier; and receiving an end HID transparent transmission response message from the source device, the end HID transparent transmission response message indicating that the source device has successfully unloaded all loaded input processing modules.

[0020] In the technical solution, when the sink device switches the source device, the HID event needs to be stopped from being transparently transmitted to the old source device before being transparently transmitted to the new source device.

[0021] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving an acquisition report request message from the source device, the acquisition report request message being used to request specific report data from the target HID, and the acquisition report request message including an identifier of the target HID and the session identifier; sending the report request message to the target HID; receiving the specific report data from the target HID; and sending an acquisition report response message to the source device, the acquisition report response message including the identifier of the target HID and the specific report data.

[0022] With reference to the first aspect, in a possible implementation manner of the first aspect, the specific report data is data of input report or function report.

[0023] With reference to the first aspect, in a possible implementation manner of the first aspect, the specific report data includes device status, control information or configuration data of the target HID.

[0024] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving a setting report request message from the source device, the setting report request message including an identifier of the target HID, the session identifier and specific report data; and sending the setting report request message to the target HID.

[0025] With reference to the first aspect, in a possible implementation manner of the first aspect, the specific report data is data of output report or function report.

[0026] With reference to the first aspect, in a possible implementation manner of the first aspect, the specific report data includes control instruction or configuration data.

[0027] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving an idle state obtaining request message from the source device, the idle state obtaining request message being used for querying the target HID for a current input idle state, the idle state obtaining request message including an identifier of the target HID and the session identifier; receiving the current input idle state of the target HID, the current input idle state of the target HID indicating a current idle time of a specified input report; and sending an idle state obtaining response message to the source device, the idle state obtaining response message including the identifier of the target HID, the session identifier, and the current input idle state of the target HID.

[0028] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving a setting idle state request message from the source device, the setting idle state request message being used for requesting to set a time for the target HID to remain silent before receiving a user input event, the setting idle state request message including an identifier of the target HID, a session identifier, and the time; and sending the setting idle state request message to the target HID.

[0029] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving an obtaining protocol request message from the source device, the obtaining protocol request message being used for requesting a current transmission protocol state from the target HID, the obtaining protocol request message including an identifier of the target HID and the session identifier; sending the obtaining protocol request message to the target HID; receiving the current transmission protocol state of the target HID; and sending an obtaining protocol response message to the source device, the obtaining protocol response message including the identifier of the target HID and the current transmission protocol state of the target HID.

[0030] With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: receiving a setting protocol request message from the source device, the setting protocol request message being used for specifying a HID transmission protocol currently required to be used by the target HID, the setting protocol request message including an identifier of the target HID, a session identifier, and the HID transmission protocol currently required to be used by the target HID; and sending the setting protocol request message to the target HID.

[0031] With reference to the first aspect, in a possible implementation manner of the first aspect, the HID transmission protocol is a root protocol or a report protocol.

[0032] With reference to the first aspect, in a possible implementation manner of the first aspect, the device information of the target HID includes a device vendor code, a product code, or a version number of a code, a device name, a physical address, and a serial number of the target HID.

[0033] In a second aspect, an embodiment of the present application provides a method for communication, which comprises: receiving, at a source device, a request message for adding a human interface device (HID) from a sink device, the request message for adding the HID being used to request the source device to load an input processing module corresponding to a target HID, and the request message for adding the HID including an identifier assigned to the target HID by the sink device, device information of the target HID, and a report descriptor of the target HID, the target HID being any one of at least one HID already inserted into the sink device or a HID newly inserted into the sink device; loading the input processing module corresponding to the target HID according to the device information of the target HID and the report descriptor of the target HID; sending, to the sink device, a response message for adding the HID, the response message for adding the HID including the identifier of the target HID and first indication information, the first indication information being used to indicate that the input processing module corresponding to the target HID has been successfully loaded in the source device; and receiving, from the sink device, an input report from the target HID, wherein the input report includes the identifier of the target HID and input report data, and the input report indicates an instant input event generated by the target HID.

[0034] With reference to the second aspect, in a possible implementation manner of the second aspect, the method further comprises: receiving a HID pass-through request message from the sink device, the HID pass-through request message being used to request the source device to allow a HID pass-through session between the sink device and the source device, the HID pass-through request message including an address of the sink device; sending, to the sink device, a HID pass-through response message, the HID pass-through response message including a session identifier assigned to the HID pass-through session by the source device; and wherein the request message for adding the HID, the response message for adding the HID, and the input report of the target HID further include the session identifier.

[0035] With reference to the second aspect, in a possible implementation manner of the second aspect, the method further comprises: receiving an output report from the input processing module corresponding to the target HID, the output report including the identifier of the target HID, the session identifier, and output report data; and sending, to the sink device, the output report.

[0036] With reference to the second aspect, in a possible implementation manner of the second aspect, the method further comprises: receiving, from the sink device, a first function report from the target HID, wherein the first function report includes the identifier of the target HID, the session identifier, and first function report data; and processing the first function report by the input processing module corresponding to the target HID.

[0037] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving a second function report from an input processing module corresponding to the target HID, wherein the second function report includes an identifier of the target HID, a session identifier, and second function report data; and sending the second function report to the destination device.

[0038] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving a request message to uninstall HID from the destination device, wherein the request message to uninstall HID is used to request the source device to uninstall the input processing module corresponding to the target HID, and the request message to uninstall HID includes an identifier of the target HID and the session identifier; sending a response message to uninstall HID to the destination device, wherein the response message to uninstall HID indicates that the source device has successfully uninstalled the input processing module corresponding to the target HID.

[0039] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving a termination HID pass-through request message from the destination device, the termination HID pass-through request message being used to notify the source device to terminate the HID pass-through session, the termination HID pass-through request message including the session identifier; and sending a termination HID pass-through response message to the destination device, the termination HID pass-through response message indicating that the source device has successfully unloaded all loaded input processing modules.

[0040] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: sending a report request message to the destination device, the report request message being used to request specific report data from the target HID, the report request message including the identifier of the target HID and the session identifier; and receiving a report response message from the destination device, the report response message including the identifier of the target HID and the specific report data.

[0041] In conjunction with the second aspect, in one possible implementation of the second aspect, the specific report data is data from an input report or a function report.

[0042] In conjunction with the second aspect, in one possible implementation of the second aspect, the specific reporting data includes the device status, control information, or configuration data of the target HID.

[0043] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: sending a configuration report request message to the destination device, the configuration report request message including the identifier of the target HID, the session identifier, and specific report data.

[0044] In conjunction with the second aspect, in one possible implementation of the second aspect, the specific report data is data from an output report or a function report. In conjunction with the second aspect, in one possible implementation of the second aspect, the specific report data includes control commands or configuration data.

[0045] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving an idle status request message from an input processing module corresponding to the target HID, the idle status request message being used to query the current input idle status of the target HID, the idle status request message including the identifier of the target HID and the session identifier; sending the idle status request message to the destination device; and receiving an idle status response message from the destination device, the idle status response message including the identifier of the target HID, the session identifier, and the current input idle status of the target HID.

[0046] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving a set idle state request message from an input processing module corresponding to the target HID, the set idle state request message being used to set a time during which the target HID remains silent before receiving a user input event, the set idle state request message including the identifier of the target HID, the session identifier, and the time; and sending the set idle state request message to the destination device.

[0047] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving an acquisition protocol request message from an input processing module corresponding to the target HID, the acquisition protocol request message being used to request the current transport protocol status from the target HID, the acquisition protocol request message including the identifier of the target HID and the session identifier; sending the acquisition protocol request message to the destination device; and receiving an acquisition protocol response message from the destination device, the acquisition protocol response message including the identifier of the target HID and the current transport protocol status of the target HID.

[0048] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving a setup protocol request message from an input processing module corresponding to the target HID, the setup protocol request message being used to specify the HID transmission protocol currently required by the target HID, the setup protocol request message including the identifier of the target HID, the session identifier, and the HID transmission protocol currently required by the target HID; and sending the setup protocol request message to the destination device.

[0049] In conjunction with the second aspect, in one possible implementation of the second aspect, the type of the HID transport protocol is either a root protocol or a reporting protocol.

[0050] In conjunction with the second aspect, in one possible implementation of the second aspect, the device information of the target HID includes the device vendor code, product code, or version number of the code, device name, physical address, and serial number of the target HID.

[0051] Thirdly, embodiments of this application provide an electronic device that includes units for implementing the first aspect or any possible implementation of the first aspect.

[0052] Fourthly, embodiments of this application provide an electronic device that includes units for implementing the second aspect or any possible implementation of the second aspect.

[0053] Fifthly, embodiments of this application provide a computer device, the electronic device including a processor, the processor being coupled to a memory to read and execute instructions and / or program code in the memory to perform the first aspect or any possible implementation of the first aspect.

[0054] In a sixth aspect, embodiments of this application provide a computer device, the electronic device including a processor, the processor being coupled to a memory to read and execute instructions and / or program code in the memory to perform the second aspect or any possible implementation of the second aspect.

[0055] In a seventh aspect, embodiments of this application provide a chip system including logic circuitry for coupling with an input / output interface to transmit data via the input / output interface, thereby executing the first aspect or any possible implementation thereof.

[0056] Eighthly, embodiments of this application provide a chip system including logic circuitry for coupling with an input / output interface to transmit data via the input / output interface, thereby executing the second aspect or any possible implementation thereof.

[0057] Ninthly, embodiments of this application provide a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform the first aspect or any possible implementation thereof.

[0058] In a tenth aspect, embodiments of this application provide a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform the second aspect or any possible implementation thereof.

[0059] Eleventhly, embodiments of this application provide a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform as in the second aspect or any possible implementation thereof.

[0060] In a twelfth aspect, embodiments of this application provide a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform the second aspect or any possible implementation thereof. (See accompanying drawings.)

[0061] Figure 1 This is a schematic block diagram of a system architecture applicable to embodiments of this application.

[0062] Figure 2 This is a schematic diagram of the structure of the management tunnel message of HID PassThrough.

[0063] Figure 3 This application provides an illustrative flowchart of a method for allocating session identifiers to a source device during the HID PassThrough initiation phase.

[0064] Figure 4 This application provides an illustrative flowchart of a method for adding a new HID during the HID PassThrough startup phase.

[0065] Figure 5 This is a schematic flowchart illustrating the method for transmitting input reports during the HID pass-through phase.

[0066] Figure 6 This is a schematic flowchart illustrating the method for transmitting output reports during the HID pass-through phase.

[0067] Figure 7 This is a schematic flowchart illustrating the method by which the source device transmits a functional report to the HID device through the destination device during the HID pass-through phase.

[0068] Figure 8 This is a schematic flowchart illustrating the method by which an HID device transmits a function report to a source device through the destination device during the HID pass-through phase.

[0069] Figure 9 This is a schematic flowchart illustrating a method for removing an HID device during the HID pass-through stage, as provided in an embodiment of this application.

[0070] Figure 10 This is a schematic flowchart illustrating a method for a source device to request specific report data from an HID, as provided in an embodiment of this application.

[0071] Figure 11 This is a schematic flowchart illustrating a method for a source device to send specific report data to an HID, as provided in an embodiment of this application.

[0072] Figure 12 This is a schematic flowchart illustrating a method provided in this application embodiment for a source device to request a query from a target HID to determine the current input idle status.

[0073] Figure 13 This is a schematic flowchart illustrating a method for a source device to set an idle state for a specified input report to an HID, as provided in an embodiment of this application.

[0074] Figure 14 This is a schematic flowchart illustrating a method provided in this application for a source device to request a query from an HID to the target HID regarding the current transport protocol status.

[0075] Figure 15 This is a schematic flowchart illustrating a method provided in this application for a source device to set the HID transmission protocol currently required by the target HID.

[0076] Figure 16 This is a schematic flowchart illustrating a method for HID pass-through between a destination device and a source device, provided in an embodiment of this application.

[0077] Figure 17 This is a schematic structural block diagram of an electronic device 1600 provided according to an embodiment of this application.

[0078] Figure 18 This is a schematic structural block diagram of an electronic device 1700 provided according to an embodiment of this application. Detailed Implementation

[0079] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0080] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0081] Currently, television input methods are becoming increasingly diversified, with new human-computer interaction devices (HID) such as remote controls and Bluetooth game controllers becoming new input methods for high-end televisions.

[0082] In one related technical solution, the remote control pass-through function is one of the functions of High-Definition Multimedia Interface (HDMI) Consumer Electronics Control (CEC). This function is typically used to transmit remote control button events received by one device (such as a television) to another device on a network. This function is often used when a television provides a remote control with additional modes to control other devices in the system. After receiving the remote control button event, the television transmits the remote control event to the target device, which then responds to the remote control button event.

[0083] The aforementioned technical solutions only support the pass-through of remote control buttons and cannot meet the pass-through of input events from other types of HID (e.g., directional remote controls, keyboards, mice, etc.). Therefore, they cannot meet the increasingly diverse human-computer interaction needs.

[0084] Another related technical solution only supports the pass-through of a single HID, and therefore cannot meet the increasingly rich human-computer interaction needs.

[0085] In view of this, embodiments of this application provide a communication method that can not only support the transparent transmission of multiple HIDs at the same time, but also support the insertion of new HIDs during use, thereby meeting the increasingly rich human-computer interaction needs.

[0086] For ease of description, let's first combine... Figure 1 The following is an example of a system architecture according to an embodiment of this application.

[0087] Figure 1 This is a schematic block diagram of a system architecture applicable to embodiments of this application. For example... Figure 1 As shown, the system includes a source device, a sink device, and at least one HID connected to the sink device (wired or wireless connection).

[0088] It should be understood that the embodiments of this application do not specifically limit the number of HIDs connected (hereinafter also referred to as inserted) on the destination device. Figure 1 The example below uses n HIDs for illustration.

[0089] As an example, the destination device can obtain HID reports (e.g., HID input reports, HID function reports) generated by at least one HID connected to it via a user input interface (e.g., USB interface, Bluetooth interface, I2C interface, etc.). HID pass-through refers to the destination device passing through the HID reports generated by at least one HID connected to it to the source device via a high-speed interface. The source device can also feed back the results (e.g., output reports, function reports) generated by its user input processing module to the destination device via a high-speed interface. The destination device then sends the results generated by its user input processing module to at least one HID connected to it via its user input interface, thereby enabling control and management of the source device through the HIDs connected to the destination device.

[0090] It should be understood that the embodiments of this application do not specifically limit the high-speed interface described above. For example, the high-speed interface is a general purpose multimedia interface (GPMI).

[0091] For example, the aforementioned equipment may include, but is not limited to: television monitors, computer monitors, mobile phone screens, or other professional displays.

[0092] For example, the aforementioned source devices may include, but are not limited to: set-top boxes, game consoles, portable computers, personal computers, etc.

[0093] For example, HID devices can include, but are not limited to: remote controls, mice, keyboards, touchpads, drawing tablets, game controllers, gamepads, flight sticks, steering wheels, and switching devices.

[0094] The aforementioned destination and source devices can communicate via HID PassThrough messages. For ease of understanding, the HID PassThrough message will be explained below.

[0095] As an example, a HID PassThrough message can be encapsulated within an Internet Protocol (IP) packet. For instance, an IP header can be added before the HID PassThrough message, containing both the source and destination addresses. The destination device can then transmit this IP packet to the source device via Ethernet, where the source address in the IP packet header is the destination device's IP address, and the destination address is the source device's IP address.

[0096] Another example is that the HID PassThrough message can be encapsulated in a GPMI message, which the destination device can then send to the source device via the GPMI interface. For instance, this GPMI message could be a management tunnel message for HID PassThrough.

[0097] For example, such as Figure 2 As shown, the management tunnel message of the HID PassThrough mentioned above may include the following fields: message header, general fields, device address addressing field, HID PassThrough message field, padding field, cyclic redundancy check (CRC) 32 field, etc.

[0098] The above header includes a ShuttleID field and a Type field. For management tunnel messages, the ShuttleID field is always set to 0. The Type field indicates the type of management message transmitted in the management data packet. For example, if the transmitted management message is a HID PassThrough message, the Type field is always set to 0x1D.

[0099] The HID PassThrough message fields mentioned above are used to carry the payload of the HID PassThrough message. The HID PassThrough message is described in detail below with reference to Table 1.

[0100] For example, the HID PassThrough message consists of two parts: a message header and a message body. The message header is fixed at 6 bytes, and its structure is shown in Table 1 below.

[0101] Table 1. Message header structure of HID PassThrough messages

[0102] Bytes Field Size in bytes Type Description 0 bDeviceId 1 BYTE HID device identification 1 bOperation 1 BYTE HID PassThrough message operation 2 wSessionID 2 WORD Session identification 4 wLength 2 WORD Message length, maximum 5120 bytes

[0103] The following is an explanation of each field in Table 1.

[0104] 1. bDeviceID: HID device identifier. The HID pass-through function supports the pass-through of HID reports from multiple HID devices between the destination and source devices. The HID device identifier is used to identify HID reports generated by different HID devices, or HID reports sent to different HID devices. The HID device identifier is assigned by the destination device and synchronized to the source device via the Add_HID_Device message. The Start_HID_PassThrough and End_HID_PassThrough messages are unrelated to the HID device, and the bDeviceID field is filled with 0.

[0105] 2. bOperation: HID PassThrough message operation code, used to identify the operation type and operation code of the current HID PassThrough message. For specific meanings, please refer to the description of HID PassThrough operation in Table 2.

[0106] 3. wSessionID: Session identifier, assigned by the source device. When the source device has multiple destination devices, the source device can identify which destination device's HID report came from through wSessionId, and then determine which HID device generated the HID report based on bDeviceId.

[0107] 4. wLength: Length of the HID PassThrough message. This length includes the 6-byte header but excludes the trailing padding bytes, and has a maximum value of 5120.

[0108] Table 2 HID PassThrough Operations

[0109]

[0110] As an example, the HID PassThrough interaction described above can be divided into three phases: the startup phase, the HID passthrough phase, and the termination phase.

[0111] The following is combined Figure 3 - Figure 4 This section provides a detailed explanation of the startup phase of HID PassThrough.

[0112] Figure 3 This application provides a schematic flowchart of a method for allocating a session identifier to a source device during the HID PassThrough initiation phase. (See attached flowchart.) Figure 3 As shown, the method includes steps 310-330, which are described below.

[0113] Step 310: The destination device sends an HID pass-through request message to the source device.

[0114] In this embodiment of the application, when the destination device needs to start the HID PassThrough function, for example, when the destination device needs to pass through its own HID device to a specific source device, the destination device needs to send an HID passthrough request message to the corresponding source device.

[0115] It should be understood that the HID of the local end can be at least one HID that has been inserted into the host device, or it can be at least one HID that has been newly inserted into the host device. This application embodiment does not specifically limit this.

[0116] It should also be understood that the HID passthrough request message mentioned above can also be called the start HID passthrough message, for example, the Start_HID_PassThrogh message.

[0117] It should be noted that the HID device in this application can also be referred to as HID.

[0118] The HID pass-through request message sent by the destination device to the source device may include the address of the destination device. The HID pass-through request message is used to request the source device to allow an HID pass-through session between the destination device and the source device.

[0119] It should be noted that a destination device can only initiate an HID pass-through session to one source device. If the destination device has already initiated an HID pass-through session with a source device, and the destination device needs to initiate an HID pass-through session with another source device, the destination device must first end the HID pass-through session with the original source device before it can initiate an HID pass-through session with the other source device.

[0120] For example, the structure of the Start_HID_PassThrogh message will be explained below with reference to Table 3.

[0121] Table 3 shows the structure of the Start_HID_PassThrogh message.

[0122]

[0123]

[0124] Step 320: The source device assigns a session identifier to the HID pass-through session.

[0125] In this embodiment of the application, after the source device receives the HID pass-through request message sent by the destination device, if the source device allows the current HID pass-through session, it assigns a session identifier (e.g., wSessionID) to the HID pass-through session.

[0126] Step 330: The source device sends an HID pass-through response message to the destination device.

[0127] In this embodiment, if the source device has assigned a session identifier to the HID pass-through session, the source device can return the session identifier (e.g., wSessionID) to the destination device via an HID pass-through response message. If the source device rejects the current HID pass-through session, it sets the value of the session identifier (e.g., wSessionID) field in the HID pass-through response message to 0.

[0128] It should be noted that when the source device resources are insufficient, such as when the number of HID devices exceeds the limit of the operating system kernel, the HID pass-through session must be rejected.

[0129] It should be understood that the above-mentioned HID passthrough request and response message can also be called the Start HID Passthrough Response message, for example, the Start_HID_PassThrogh response message.

[0130] For example, the structure of the Start_HID_PassThrogh response message will be explained below with reference to Table 4.

[0131] Table 4 shows the structure of the Start_HID_PassThrogh response message.

[0132]

[0133] In this embodiment, after receiving the HID pass-through request response message from the source device, the destination device needs to check whether the value of the wSessionID field in the HID pass-through request response message is 0. If the value of the wSessionID field in the HID pass-through request response message received by the destination device is 0, it means that the source device rejects this HID pass-through session, and the destination device ends this HID pass-through session. Only when the value of the wSessionID field in the HID pass-through request response message received by the destination device is not 0 can the destination device enter the HID pass-through stage.

[0134] Figure 4 This application provides an illustrative flowchart of a method for adding a new HID during the HID PassThrough initiation phase. (See attached flowchart.) Figure 4 As shown, the method includes steps 400-440, which are described below.

[0135] Step 410: The destination device sends a request message to the source device to add a new HID.

[0136] As an example, when a destination device needs to enable the HID PassThrough function, for instance, after the destination device establishes an HID passthrough session through an HID passthrough request message, when the destination device needs to enable the passthrough of an HID report for a certain HID, the destination device needs to send a request message to the corresponding source device to add a new HID.

[0137] For ease of description, the following example illustrates how the host device needs to initiate the transparent transmission of HID reports to the target HID.

[0138] For example, the aforementioned request message for adding a new HID is used to request the source device to load the input processing module corresponding to the target HID. This request message includes the identifier assigned to the target HID by the destination device, the device information of the target HID, and the report descriptor of the target HID.

[0139] It should be understood that the device information and report descriptor of the target HID can be obtained by the destination device from the target HID through steps 400-405. For example, the destination device sends a request to the target HID to obtain the device information and report descriptor of the target HID through step 403, and the target HID returns the device information and report descriptor of the target HID to the destination device through step 405.

[0140] The aforementioned request for the source device to load the input processing module corresponding to the target HID can also be understood as a request to load the input processing module corresponding to the target HID on the source device, or it can also be understood as a request to load the input processing module related to the target HID on the source device. This application embodiment does not specifically limit this.

[0141] It should be understood that the target HID can be any one of at least one HID that has been inserted into the host device, or it can be any one of at least one HID that has been newly inserted into the host device. This application embodiment does not specifically limit this.

[0142] As an example, the device information of the target HID may include, but is not limited to: the device vendor code, product code, or version number of the code, device name, physical address, and serial number of the target HID.

[0143] For example, the above request message for adding a new HID can also be called the Add_HID_Device message.

[0144] It should be noted that an Add_HID_Device message carries only one HID device information. If the destination device has multiple HID devices that need to be passed to the source device, then multiple Add_HID_Device messages need to be sent to the source device separately.

[0145] It should also be noted that the HID pass-through function supports HID pass-through for a maximum of 16 HID devices. The destination device can send a maximum of 16 Add_HID_Device messages to the source device.

[0146] For example, the structure of the Add_HID_Device message is explained below with reference to Table 5.

[0147] Table 5 Structure of the Add_HID_Device message

[0148]

[0149]

[0150] Step 420: The source device loads the input processing module corresponding to the target HID.

[0151] In this embodiment of the application, after the source device receives the request message for adding a new HID sent by the destination device, it obtains the device information of the target HID and the report descriptor of the target HID from the request message, and loads the input processing module corresponding to the target HID according to the device information of the target HID and the report descriptor of the target HID.

[0152] In one possible implementation, the source device registers or loads the driver for the target HID in the source device's operating system based on the target HID's device information and the target HID's report descriptor.

[0153] Step 430: The source device sends a request-response message to the destination device to add a new HID.

[0154] In this embodiment of the application, if the source device successfully loads the input processing module corresponding to the target HID, the source device can send a request-response message for adding a new HID to the destination device.

[0155] The response message for the newly added HID may include the identifier of the target HID and a first indication information, wherein the first indication information is used to indicate that the input processing module corresponding to the target HID has been successfully loaded in the source device.

[0156] For example, the request and response message for adding a new HID can also be called the Add_HID_Device response message.

[0157] For example, the structure of the Add_HID_Device response message will be explained below with reference to Table 6.

[0158] Table 6. Structure of the Add_HID_Device response message

[0159]

[0160] In this embodiment of the application, after the receiving device receives the request response message for the newly added HID, it can start the transparent transmission phase of the HID report of the target HID corresponding to bDeviceID.

[0161] Step 440: In response to receiving the input report from the target HID, the destination device sends the input report to the source device.

[0162] Step 440 will be combined below Figure 5 To provide a further, more detailed description.

[0163] The following is combined Figure 5 - Figure 8 This paper introduces the specific implementation process of transmitting input reports, output reports, and functional reports during the HID pass-through phase.

[0164] For example, in response to receiving an input report from a target HID, the destination device can send the input report to the source device. This input report includes the identifier of the target HID and the input report data.

[0165] The aforementioned input reports, also known as HID input reports, are fundamental to enabling effective interaction between users and computer systems. They carry operation instructions and status information generated by various input devices and play a crucial role for the operating system, applications, and users.

[0166] In this embodiment, an HID input report typically refers to a data packet from a HID device to a host. In HIDPassThrough, it refers to a data packet from a destination device to a source device. This input report is used to transmit real-time input events generated by user interaction with a device (e.g., an HID device). These reports have wide applications in human-computer interaction, system control, application programming interfaces (APIs), and game development.

[0167] As an example, Figure 5 This is a schematic flowchart illustrating the method of transmitting input reports during the HID pass-through phase. When the source device receives the HID input report corresponding to the HID with bDeviceId, the destination device can send the HID input report back to the source device via the HID_Input_Report message. For example, ... Figure 5 As shown, after the destination device receives the HID input report data of the target HID in step 510, it carries the HID input report in the HID_Input_Report message and sends the HID input report to the source device through the HID_Input_Report message in step 520.

[0168] The HID_Input_Report message mentioned above may include the HID input report, the identifier of the target HID, and the session identifier.

[0169] For example, the structure of the HID_Input_Report message will be explained below with reference to Table 7.

[0170] Table 7 shows the structure of the HID_Input_Report message.

[0171]

[0172] In this embodiment, after the source device receives the HID_Input_Report message sent by the destination device, it reports the HID input report in the HID_Input_Report message to the operating system of the source device through the HID driver corresponding to bDeviceId loaded in the source device. For example, Figure 5 As shown, the source device obtains input report data from the HID_Input_Report message and reports the input report data to the source device's operating system through the driver of the target HID loaded in the source device.

[0173] It should be understood that the HID_Input_Report message does not have a corresponding response message.

[0174] For example, the following lists some of the main uses of HID input reports.

[0175] 1. User input capture:

[0176] a) Keyboard input: Records the user's actions of pressing or releasing keyboard keys, including character keys, function keys (such as F1-F12), modifier keys (such as Shift, Ctrl, Alt), etc.

[0177] b) Mouse input: Report mouse movement (such as coordinate changes), scroll wheel scrolling, left / right / middle button press / release, and other events.

[0178] c) Touchpad / touchscreen: Records finger gestures such as touching, swiping, zooming, and rotating, as well as information such as the coordinates, pressure, and size of the touch point.

[0179] d) Game controller: Reports the movement of the joystick, the pressing / releasing of trigger buttons (such as trigger buttons), directional pad operations, shoulder buttons, touchpad touch, etc.

[0180] 2. System Interaction and Control:

[0181] a) Wake-up / Hibernate: Pressing certain keys on some devices (such as wireless keyboards and mice) can trigger the system to wake up from sleep or enter hibernation mode.

[0182] b) Keyboard shortcuts: Users can perform system-level shortcuts such as copy, paste, and lock the screen by using key combinations (such as Ctrl+C, Win+L).

[0183] c) Menu navigation: Menu selection, cursor movement, and other operations are performed in the graphical user interface (GUI) using the D-pad (arrow keys) or similar input devices.

[0184] 3. Application Input Processing:

[0185] a) Text Input: In scenarios such as word processors, chat software, and web forms, keyboard input reports are used to construct text strings entered by users.

[0186] b) Game Control: Input reports from devices such as game controllers, flight sticks, and racing steering wheels are parsed by the game engine and used to control the actions of characters, changes in perspective, and driving of vehicles in the game.

[0187] c) Graphic design and engineering software: Precise input reports from devices such as mice and drawing tablets are used for drawing lines, shapes, and making precise selections.

[0188] 4. Accessibility features:

[0189] a) Assistive input devices: such as switches, alternative keyboards, eye-tracking systems, and other input devices designed specifically for people with disabilities, which translate user operations into system-understandable instructions through HID input reports.

[0190] 5. Remote control and switching between keyboard, monitor, and mouse (Keyboard, Video, Mouse, KVM):

[0191] a) Remote Desktop: Sends input reports from the local HID device to a remote host via a network, enabling remote control of another computer.

[0192] b) KVM switch: Shares a single keyboard, mouse, and monitor among multiple computers, and input reports help determine which computer should respond to the current user input.

[0193] In some embodiments, the source device may also receive an output report from an input processing module (e.g., the driver of the target HID) corresponding to the target HID and send the output report to the destination device.

[0194] It should be understood that output reports, also known as HID output reports, are typically data packets transmitted from the source device to the destination device in HID PassThrough. HID output reports are primarily used by the host system to send instructions to HID devices to control device behavior, update display information, manage device status, and implement more advanced customized functions. These output reports enable the host to interact flexibly with peripherals, enhance the user experience, and support device diversity and functional expansion.

[0195] In the above technical solution, the HID PassThrough function receives input events from the HID device through the destination device and transmits them to the source device through the GPMI interface, thereby enabling access and operation of different source devices on the same destination device.

[0196] As an example, Figure 6 This is a schematic flowchart illustrating the method for transmitting output reports during the HID pass-through phase. For example... Figure 6 As shown, after the source device receives the HID output report from the HID driver corresponding to bDeviceId, it can send the HID output report to the destination device via the HID_Output_Report message. The destination device retrieves the HID output report from the HID_Output_Report message and sends it to the HID driver corresponding to bDeviceId. For example... Figure 6 As shown, after the source device receives the HID output report data from the target HID's driver, it sends the HID output report to the destination device via the HID_Output_Report message in step 610. The destination device retrieves the HID output report from the HID_Output_Report message and sends the HID output report to the target HID.

[0197] The HID_Output_Report message includes the identifier of the target HID, the session identifier, and the output report data.

[0198] For example, the structure of the HID_Output_Report message will be explained below with reference to Table 8.

[0199] Table 8 shows the structure of the HID_Output_Report message.

[0200]

[0201] It should be understood that the HID_Output_Report message does not have a corresponding response message.

[0202] For example, the following lists some of the main uses of HID output reports.

[0203] 1. Equipment status control:

[0204] a) Keyboard indicator lights: The host sends output reports to control the on / off state of indicator lights such as Num Lock, Caps Lock, and Scroll Lock on the keyboard, ensuring that all connected keyboards are consistent with the system display status.

[0205] b) Game controller vibration: The host sends a command to the game controller, causing its built-in motor to vibrate, simulating physical feedback such as impacts and explosions in the game.

[0206] c) RGB lighting control: For keyboards, mice, or headsets that support custom lighting effects, the host adjusts the color, brightness, mode, etc. of their LEDs through output reports.

[0207] 2. Device function switching:

[0208] a) Mode switching: In multi-functional devices (such as keyboards with touchpads, composite game controllers), the host sends an output report to change the device's operating mode, such as enabling or disabling the touchpad, or switching to different game operation configurations.

[0209] b) Touchpad calibration: When recalibrating the touchpad of a portable computer, the host may send an output report to guide the device in performing the calibration process.

[0210] 3. Information display:

[0211] a) LCD screen display: Some advanced HID devices (such as professional music keyboards and high-end mice) are equipped with LCD screens. The host updates the displayed content, such as audio track information and DPI settings, through output reports.

[0212] b) Dynamic display of OLED keyboard keys: For keyboards with programmable OLED display keys, the host sends an output report to change the displayed content such as text and icons on the keys.

[0213] 4. System Notification:

[0214] a) Battery status indicator: The host sends an output report request or updates battery power information to the wireless device (such as a wireless mouse or keyboard). The device may change the LED color or flashing pattern accordingly to remind the user to charge.

[0215] b) Error or warning indication: When the device malfunctions, has a connection problem, or is outside the normal operating range, the host can request the device to display a specific error code or warning symbol by outputting a report.

[0216] 5. Customization features:

[0217] a) Macro execution: For devices that support macro programming, the host can send an output report to trigger a preset macro sequence, such as executing complex key combinations or mouse actions with a single click.

[0218] b) Custom key mapping: The host sends an output report to update the device's key mapping table, allowing users to temporarily or permanently change the function of specific keys on the device.

[0219] In some embodiments, feature reports can also be exchanged between the source device and the destination device.

[0220] It should be understood that function reports in computer systems are primarily used to transmit data related to the functional status of a device. These reports differ from regular input reports (such as keyboard key presses, mouse movements, or touchpad touch events); they typically relate to status or configuration information related to non-immediate user input of the device.

[0221] In this embodiment, the feature report can be bidirectional, meaning the HID device can report to the source device via the destination device, or the source device can send the report to the HID device via the destination device. HID feature reporting provides a mechanism that allows the source device to interact more deeply with the HID device through the destination device, going beyond basic user input events to encompass device configuration, status monitoring, maintenance operations, and even secure communication. These features enhance the flexibility, scalability, and ease of use of the HID device, enabling it to adapt to various complex application scenarios and user needs.

[0222] As an example, Figure 7 This is a schematic flowchart illustrating the method by which a source device transmits a function report to an HID device through a destination device during the HID pass-through phase. After the input processing module (also called the input processing module) corresponding to bDeviceId in the source device generates a function report, the source device can send the function report to the destination device via the HID_Feature_Report message. Upon receiving the HID_Feature_Report message from the source device, the destination device sends the HID function report from that message to the HID device corresponding to bDeviceId. For example, as... Figure 7 As shown, after the source device generates a function report from the input processing corresponding to the target HID, it sends the function report to the destination device via the HID_Feature_Report message in step 710. Upon receiving the HID_Feature_Report message from the source device, the destination device sends the HID function report from the HID_Feature_Report message to the HID corresponding to the target HID via step 720.

[0223] The HID_Feature_Report message mentioned above may include the identifier of the target HID, the session identifier, and the HID feature report.

[0224] As an example, Figure 8 This is a schematic flowchart illustrating the method by which an HID device transmits a function report to a source device through the destination device during the HID pass-through phase. For example...Figure 8 As shown, in step 810, after the HID device corresponding to bDeviceId (e.g., the target HID) generates a function report, it can send the function report to the destination device. The destination device sends the function report to the source device via the HID_Feature_Report message in step 820. For example, after the HID device corresponding to bDeviceId (e.g., the target HID) generates second function report data, the destination device carries the second function report in the HID_Output_Report message and sends it to the source device.

[0225] In the embodiments of this application, such as Figure 8 As shown, after the source device receives the HID_Feature_Report message sent by the destination device, the source device reports the function report in the message body to the input processing (e.g., the input processing module) corresponding to the bDeviceId loaded in the source device to process the function report data.

[0226] In the above technical solution, the HID PassThrough function receives the function events of the HID device through the destination device and transmits them to the source device through the GPMI interface, thereby enabling access and operation of different source devices on the same destination device.

[0227] For example, the structure of the HID_Feature_Report message will be explained below with reference to Table 9.

[0228] Table 9 Structure of HID_Feature_Report Message

[0229]

[0230]

[0231] It should be understood that the HID_Feature_Report message does not have a corresponding response message.

[0232] For example, the following lists some of the main uses of feature reports.

[0233] 1. Equipment configuration and control:

[0234] a) Function reports can be used to set or query device configuration parameters, such as key mapping, sensitivity, report rate, LED status (such as keyboard backlight, Num Lock, Caps Lock indicator, etc.), vibration intensity (for game controllers that support vibration feedback), etc.

[0235] b) Device drivers or applications change the device's operating mode, enable or disable specific functions, or read the current configuration state by sending function report requests.

[0236] 2. Equipment Status Inquiry:

[0237] a) Functional reports can be used to obtain real-time status information of the device, such as battery level, wireless signal strength, device temperature, and fault indications. This information is crucial for device management and fault diagnosis.

[0238] b) For professional or specific-purpose HID devices, more complex device status data may also be included, such as the precise angle of a 3D mouse, the tilt angle and pressure value of a joystick, and sensor readings of medical devices.

[0239] 3. Firmware updates and maintenance:

[0240] a) Some HID devices support firmware upgrades or device self-tests via function reports. In this case, function reports are used to transmit firmware data blocks or control the firmware update process, as well as to receive device feedback and status updates.

[0241] b) Through functional reports, the host system can request the device to perform internal diagnostic tests, obtain hardware health status or calibration data to ensure proper device operation or trigger maintenance operations when necessary.

[0242] 4. Security authentication and encryption:

[0243] In certain security-sensitive environments, HID devices may use function reports for authentication, key exchange, or data encryption. For example, a smart card reader may use function reports to securely communicate with a smart card, transmit encrypted data, or execute authentication protocols.

[0244] a) Device personalization and customization:

[0245] b) Users can personalize device behavior through feature reports, such as custom macro commands, key bindings, vibration modes, etc. These settings are usually stored internally by the device and read and modified by the host through feature reports.

[0246] The following is combined Figure 9 This paper introduces the specific implementation process of removing HID devices during the HID pass-through phase.

[0247] Figure 9 This is a schematic flowchart illustrating a method for removing an HID device during the HID pass-through stage, as provided in an embodiment of this application. Figure 9 As shown, the method may include steps 910-940, which will be described in detail below.

[0248] Step 910: The host device detects that an HID device has been unplugged or that an HID device has malfunctioned.

[0249] As an example, during the HID pass-through phase, if the target HID on the destination device is unplugged or malfunctions, the destination device can detect that the target HID on the destination device has been unplugged (i.e. disconnected) or malfunctioned.

[0250] Step 920: The destination device sends a request message to the source device to unload HID.

[0251] As an example, if the destination device detects that the target HID has been unplugged or malfunctioned, the destination device sends a request message to the source device to uninstall the HID. This request message includes the identifier of the target HID and a session identifier. The request message requests the source device to uninstall the input processing module corresponding to the target HID; for example, it requests the source device to uninstall the driver for the target HID.

[0252] For example, the above request message to uninstall HID can also be called the Remove_HID_Device message.

[0253] It should be understood that the Remove_HID_Device message is an optional implementation.

[0254] For example, the structure of the Remove_HID_Device message described above will be explained below with reference to Table 10.

[0255] Table 10 Structure of the Remove_HID_Device message

[0256]

[0257]

[0258] Step 930: The source device unloads the input processing module corresponding to the target HID.

[0259] As an example, when a source device receives a request message from a destination device to unload a HID, it can unload the input processing module corresponding to the target HID. For example, the source device can unload the driver for the target HID.

[0260] Step 940: The source device sends a response message to the destination device to unload HID.

[0261] As an example, after the source device unloads the input processing module corresponding to the target HID, it can send an unloaded HID response message to the destination device. This unloaded HID response message indicates that the source device has successfully unloaded the input processing module corresponding to the target HID.

[0262] For example, the above response message for unloading HID can also be called the Remove_HID_Device response message.

[0263] For example, the structure of the Remove_HID_Device response message described above will be explained below with reference to Table 11.

[0264] Table 11 Structure of the Remove_HID_Device response message

[0265]

[0266] In some embodiments, during the HID pass-through phase, the source device can communicate with the HID device in the destination device through GET_REPORT, SET_REPORT, GET_IDLE, SET_IDLE, GET_PROTOCOL, and SET_PROCOTOL operations.

[0267] The following is combined Figure 10 This paper describes the specific implementation process of communication between the source device and the HID device in the destination device through the GET_REPORT operation.

[0268] Figure 10 This is a schematic flowchart illustrating a method for a source device to request specific report data from an HID, as provided in an embodiment of this application. Figure 10 As shown, the method may include steps 1010-1020, which will be described in detail below.

[0269] Step 1010: The source device sends a request message to the destination device to obtain a report.

[0270] As an example, the source device sends a GET report request message to the destination device. This GET report request message is used to request specific report data from the target HID. The GET report request message includes the identifier of the target HID and the session identifier.

[0271] For example, the above-mentioned report request message can also be called a GET_REPORT message.

[0272] It should be noted that the GET_REPORT message is a mandatory request, and both the source and destination devices should support this request.

[0273] It should be understood that a GET_REPORT message is a control transmission request from a host to an HID device for specific report data. For example, the GET_REPORT message is an important means for a host to proactively obtain device status, control information, configuration data, and other specific reports. It ensures the synchronization and interaction of data between the host and the HID device, and plays an important role in the normal use of the HID device, troubleshooting, personalized configuration, and security control.

[0274] For example, the following lists some of the main functions of the GET_REPORT message.

[0275] 1. Obtain device status:

[0276] a) Reading Input Reports: The host sends a GET_REPORT request, requesting the device to send recent input data, such as keyboard key states, mouse movements or scroll wheel changes, and gamepad button presses. This is crucial for real-time processing of user interactions.

[0277] b) Retrieve Function Report: The host can request the device to return data that is not directly triggered by the user, such as its current configuration, status information, or firmware version. This helps the host system understand the detailed status of the device or manage the device.

[0278] 2. Equipment Control and Configuration:

[0279] a) Obtaining output reports: Although output reports are usually sent from the host to the device, in some cases (such as when the device has internal state storage), the host may need to read the device's output buffer to confirm whether previous control commands have been executed correctly.

[0280] b) Obtaining feature reports: For devices with specific functions or complex configurations, the host may obtain the device's feature reports, such as device feature descriptors and custom function settings, through a GET_REPORT request.

[0281] 3. Equipment initialization and recovery:

[0282] a) Synchronization after device reset: After the device is reset or connected, the host obtains the initial state of the device through the GET_REPORT message to ensure that communication with the device is in a known state.

[0283] b) Troubleshooting and Recovery: When a device malfunction is detected or a user requests a device reset, the host sends a GET_REPORT request to obtain the device's error status or fault code in order to perform fault diagnosis and recovery operations.

[0284] 4. Equipment personalization and customization:

[0285] a) Reading user configuration: For devices that support user-defined configurations, such as key mapping, macro definitions, LED colors, etc., the host reads the user's personalized settings through a GET_REPORT request.

[0286] b) Firmware update verification: During the device firmware upgrade process, the host may use the GET_REPORT message to query the firmware version or verify whether the firmware update was successful.

[0287] 5. Security Authentication and Encryption:

[0288] a) Device authentication information: In situations requiring security authentication, such as smart card readers and encrypted keyboards, the host sends a GET_REPORT request to obtain the device's authentication data or key materials.

[0289] b) Security event logging: For devices with security auditing capabilities, the host can query the security event logs recorded by the device through the GET_REPORT message.

[0290] For example, the structure of the GET_REPORT message described above will be explained below with reference to Table 12.

[0291] Table 12 Structure of the GET_REPORT message

[0292]

[0293] It should be noted that in the GET_REPORT message sent from the source device to the destination device, the first byte of the message body must be the ReportId. If the target HID uses an unnumbered HID report, this byte should be filled with 0.

[0294] It should also be noted that in the GET_REPORT message sent from the source device to the destination device, the aData field in the message body is a buffer for receiving reports, and the data in it is meaningless. After receiving the SET_REPORT message, the destination device initiates a GET_REPORT request to the HID device, then fills this field with the actual report information returned by the HID device, and then returns it to the source device.

[0295] Step 1020: The destination device sends a report retrieval response message to the source device.

[0296] As an example, after receiving the GET REPORT request message sent by the source device, the destination device initiates a GET REPORT request to the HID device corresponding to bDeviceId. For example, it sends a GET REPORT request message (e.g., GET REPORT or Get Report, or Get Report Request) to the target HID through step 1013 to obtain the HID report (e.g., specific report data) from the target HID.

[0297] For example, the specific report data mentioned above is data from an input report or a function report. For instance, this specific report data includes the device status, control information, or configuration data of the target HID.

[0298] It should be noted that the GET_REPORT message is typically used to retrieve functional and input reports from the HID device from the destination device. If the destination device receives a GET_REPORT request for the output report from the source device, it should directly respond with an invalid GET_REPORT request and should not initiate a GET_REPORT request to the HID device.

[0299] In this embodiment of the application, after the destination device obtains specific report data from the target HID through step 1015, it can return the HID report (e.g., specific report data) returned by the target HID to the source device by obtaining a report response message.

[0300] The aforementioned report response message includes the identifier of the target HID and specific report data.

[0301] For example, the above-mentioned GET report response message can also be called a GET_REPORT response message.

[0302] It should be noted that the structure of this GET_REPORT response message is the same as that of the GET_REPORT message. For details on the structure of the GET_REPORT response message, please refer to the description of the structure of the GET_REPORT message in Table 12. It will not be repeated here.

[0303] The following is combined Figure 11 This paper describes the specific implementation process of communication between the source device and the HID device in the destination device through the SET_REPORT operation.

[0304] Figure 11 This is a schematic flowchart illustrating a method for a source device to send specific report data to an HID, as provided in an embodiment of this application. Figure 11 As shown, the method may include steps 1110-1120, which will be described in detail below.

[0305] Step 1110: The source device sends a configuration report request message to the destination device.

[0306] As an example, the source device sends a configuration report request message to the destination device. This report request message includes the identifier of the target HID, the session identifier, and specific report data.

[0307] For example, the specific report data mentioned above is received by the source device from the input processing module corresponding to the target HID.

[0308] For example, the specific report data mentioned above is data from output reports or function reports. This specific report data may include control commands or configuration data.

[0309] For example, the above-mentioned setup report request message can also be called a SET_REPORT message.

[0310] It should be noted that the SET_REPORT message is typically used to configure the function reports and output reports of an HID device. If the destination device receives a SET_REPORT for an input report, it should ignore the request.

[0311] It should also be noted that the SET_REPORT message is a mandatory request, and both the source and destination devices should support the processing of this request message.

[0312] It should be understood that a SET_REPORT message is a control transmission request from a host to a device to send specific report data. For example, the SET_REPORT message is a key means for a host to send control commands, configuration data, and other specific reports to an HID device. It ensures that the host can effectively manage device behavior, enable user interaction, perform device initialization and recovery, support personalized configuration, and execute security control operations.

[0313] For example, the following lists some of the main functions of the SET_REPORT message.

[0314] 1. Equipment control and configuration:

[0315] a) Set Output Report: The host sends a SET_REPORT request to send output data to the HID device, such as LED status changes, vibration mode settings, custom button mappings, etc., to change the device's behavior or display.

[0316] b) Sending feature reports: For HID device features that require host configuration, such as device configuration and firmware update commands, the SET_REPORT message is used to transmit this control information.

[0317] 2. User interaction feedback:

[0318] a) Keyboard / Mouse Events: The host sends events such as key press / release, mouse movement, and scroll wheel scrolling to the HID device via the SET_REPORT message to enable user interaction with the device.

[0319] b) Game controller input: The host sends a SET_REPORT message to HID devices such as game controllers and flight sticks to send information such as joystick position and button status to achieve game control.

[0320] 3. Equipment initialization and recovery:

[0321] a) Device reset: When the HID device malfunctions or the connection is unstable, the host sends a SET_REPORT message to request the HID device to be reset in order to restore normal communication.

[0322] b) Device configuration recovery: After the HID device is powered off or unexpectedly restarted, the host restores the previous configuration of the HID device, such as key mapping and vibration intensity, through the SET_REPORT message.

[0323] 4. Equipment personalization and customization:

[0324] a) Saving user configuration: For devices that support user-defined configurations, such as key mapping, macro definitions, and LED colors, the host saves the user's personalized settings to the HID device via the SET_REPORT message.

[0325] b) Firmware update: During the firmware upgrade process of the HID device, the host uses the SET_REPORT message to send new firmware data or commands to update the firmware of the HID device.

[0326] 5. Security Authentication and Encryption:

[0327] a) Device authentication: In situations requiring security authentication, such as smart card readers and encrypted keyboards, the host sends authentication data or key materials to the HID device via the SET_REPORT message.

[0328] b) Security event logging: For HID devices with security auditing capabilities, the host can send security event logs to the HID device via the SET_REPORT message, such as login attempts and permission changes.

[0329] For example, the structure of the SET_REPORT message described above will be explained below with reference to Table 13.

[0330] Table 13 Structure of the SET_REPORT message

[0331]

[0332] Step 1120: The destination device sends a configuration report request message to the target HID.

[0333] As an example, after receiving a configuration report request message from the source device, the destination device sends a configuration report request message (e.g., SET_REPORT or Set_Report, or Set_Report Request) to the target HID.

[0334] In one possible implementation, the destination device obtains specific report data from the setup report request message and sends the specific report data to the HID device corresponding to bDeviceId. For example, the destination device sends the specific report data in the setup report request message to the target HID.

[0335] It should be noted that the SET_REPORT message does not require a response, i.e., there is no corresponding response message for the SET_REPORT message.

[0336] The following is combined Figure 12 This paper describes the specific implementation process of communication between the source device and the HID device in the destination device through the GET_IDLE operation.

[0337] Figure 12 This is a schematic flowchart illustrating a method provided in this application for a source device to request a query from a target HID to determine the current input idle status. Figure 12 As shown, the method may include steps 1210-1220, which will be described in detail below.

[0338] Step 1210: The source device sends an idle status request message to the destination device.

[0339] As an example, the source device sends an idle status request message to the destination device. This idle status request message is used to query the current input idle status of the target HID. The idle status request message includes the identifier of the target HID and the session identifier.

[0340] It should be understood that the aforementioned request message for obtaining idle status may, for example, be received by the source device from the input processing module corresponding to the target HID.

[0341] For example, the above-mentioned request message for obtaining idle status can also be called a GET_IDLE message.

[0342] It should be understood that the GET_IDLE message is a control transmission request from a host to the HID device requesting the current input idle state.

[0343] For example, the following lists some of the main functions of the GET_IDLE message.

[0344] 1. Equipment status monitoring:

[0345] a) Input Idle Detection: The host sends a GET_IDLE message to query the HID device's current input idle state, i.e., whether the HID device has detected any user input activity within a specified time. This is important for understanding whether the HID device is currently idle and whether resource release or energy-saving operations are needed.

[0346] b) Device wake-up trigger: For HID devices that support automatic wake-up, the host queries the idle status of the HID device through the GET_IDLE message to determine whether a wake-up signal needs to be sent.

[0347] 2. User interaction response:

[0348] a) Interaction timeout handling: When the user does not operate the HID device for a long time, the host uses the GET_IDLE message to determine whether the HID device has entered an idle state, so as to trigger the corresponding timeout handling logic, such as automatic screen locking, exiting full-screen applications, etc.

[0349] b) Interaction recovery detection: When the HID device recovers from the idle state to the active state, the host promptly detects and resumes normal user interaction processing through the GET_IDLE message.

[0350] 3. Equipment energy-saving management:

[0351] a) Power Management: For mobile devices or applications requiring energy saving, the host uses the GET_IDLE message to understand the input status of the HID device so as to take appropriate power management measures, such as reducing the power consumption of the HID device or switching to a low-power mode.

[0352] b) Wake-up threshold setting: The host can adjust the wake-up threshold according to the idle state of the HID device to minimize power consumption without affecting the user experience.

[0353] 4. Equipment troubleshooting:

[0354] a) Device fault detection: When the HID device malfunctions or communication is abnormal, the host queries the idle status of the HID device through the GET_IDLE message to determine whether the HID device has lost response or is in a fault state.

[0355] b) Fault recovery tracking: When the HID device recovers from a fault state to a normal working state, the host tracks the recovery process of the HID device through the GET_IDLE message in order to troubleshoot and repair the fault.

[0356] 5. Security Authentication and Encryption:

[0357] a) Device authentication: In situations requiring security authentication, such as smart card readers and encrypted keyboards, the host queries the idle status of the HID device through the GET_IDLE message to verify whether the HID device is in a secure authentication state.

[0358] b) Security event logging: For HID devices with security auditing capabilities, the host can query the device's idle state via the GET_IDLE message to log security events of the device.

[0359] For example, the structure of the GET_IDLE message described above will be explained below with reference to Table 14.

[0360] Table 14 Structure of the GET_IDLE message

[0361]

[0362] It should be noted that in the GET_IDLE message sent from the source device to the destination device, the first byte of the message body must be the ReportId. If the target HID uses an unnumbered HID report, this byte should be filled with 0.

[0363] It should also be noted that in the GET_IDLE message sent from the source device to the destination device, the bIdleRate field in the message body is a buffer for receiving reports, and the data in it is meaningless. After receiving the GET_IDLE message, the destination device initiates a GET_IDLE request to the HID device, fills this field according to the actual bIdleRate returned by the HID device, and then returns it to the source device.

[0364] Step 1220: The destination device sends an idle status response message to the source device.

[0365] As an example, after receiving the get idle status request message sent by the source device, the destination device initiates an get idle status request to the HID device corresponding to bDeviceId. For example, it sends an get idle status request message (e.g., GET_IDLE request message, or Get_Idle, or Get_Idle Request) to the target HID through step 1213 to obtain the current input idle status of the target HID. The current input idle status of the target HID indicates the idle time of the currently specified input report.

[0366] For example, the destination device can return the idle time (e.g., bIdleRate) of the currently specified input report returned by the target HID in step 1215 to the source device via a GET_IDLE response message. After receiving the GET_IDLE response message, the source device returns bIdleRate from the message body to the input processing module corresponding to the target HID. For example, it returns bIdleRateb from the message body to the HID driver corresponding to DeviceId.

[0367] For example, the above-mentioned message for obtaining an idle status response can also be called a GET_IDLEresponse message.

[0368] It should be noted that the structure of this GET_IDLEresponse message is the same as that of the GET_IDLE message. For details on the structure of the GET_IDLEresponse message, please refer to the description of the structure of the GET_IDLE message in Table 14. It will not be repeated here.

[0369] The following is combined Figure 13 This paper describes the specific implementation process of communication between the source device and the HID device in the destination device through the SET_IDLE operation.

[0370] Figure 13 This is a schematic flowchart illustrating a method for a source device to set an idle state for a specified input report in an HID, as provided in an embodiment of this application. Figure 13 As shown, the method may include steps 1310-1320, which will be described in detail below.

[0371] Step 1310: The source device sends a request message to the destination device to set idle state.

[0372] As an example, the source device sends a Set Idle State Request message to the destination device. This Set Idle State Request message is used to request the target HID to remain silent for a certain period of time before receiving a user input event. The Set Idle State Request message includes the identifier of the target HID, the session identifier, and the aforementioned silent period.

[0373] It should be understood that the aforementioned idle state request message may, for example, be received by the source device from the input processing module corresponding to the target HID.

[0374] For example, the above-mentioned request message for setting an idle state can also be called a SET_IDLE message.

[0375] It should be understood that the SET_IDLE message is a request sent by a host to an HID device to set a specified idle state for input reporting (i.e., the time the device remains silent before receiving user input events). For example, the SET_IDLE message is a key means for hosts to set the idle state of HID device input reporting, and it plays an important role in HID device input timeout management, user interaction response optimization, HID device status monitoring, and security control.

[0376] For example, the following lists some of the main functions of the SET_IDLE message.

[0377] 1. HID device input timeout management:

[0378] a) Input event interval control: The host informs the HID device via the SET_IDLE message of the maximum time (in milliseconds) it can wait before receiving the next input event. This allows the HID device to enter power-saving mode or release relevant resources during periods of no user operation.

[0379] b) Wake-up threshold setting: For devices that support remote wake-up, the host sets the wake-up threshold of the HID device during periods without input events via the SET_IDLE message, so that it can quickly return to working state when the user operates.

[0380] 2. Optimized user interaction response:

[0381] a) Interaction delay adjustment: The host can dynamically adjust the idle state of the HID device through the SET_IDLE message according to the user interaction mode (such as game, text input, etc.) to optimize the response speed or reduce unnecessary system wake-ups.

[0382] b) Interactive feedback control: For HID devices that support haptic feedback (such as vibration, LED flashing, etc.), the host controls the HID device to stop or reduce feedback during periods without input events via the SET_IDLE message, in order to save power or avoid interference.

[0383] For example, the structure of the SET_IDLE message described above will be explained below with reference to Table 15.

[0384] Table 15 Structure of the SET_IDLE message

[0385]

[0386] Step 1320: The destination device sends the set time for the target HID to remain silent before receiving a user input event to the target HID.

[0387] As an example, after receiving a Set Idle State Request message from the source device, the destination device obtains the time (e.g., bIdleRate) during which the target HID remains silent before receiving a user input event from the Set Idle State Request message, and sends the bIdleRate to the HID device corresponding to bDeviceId. For example, the destination device sends the bIdleRate to the target HID through a Set Idle State Request message (e.g., SET_IDLE request message, or Set_Idle, or Set_Idle Request).

[0388] It should be noted that the SET_IDLE message does not require a response, i.e., there is no corresponding response message for the SET_IDLE message.

[0389] The following is combined Figure 14 This paper describes the specific implementation process of communication between the source device and the HID device in the destination device through the GET_PROTOCOL operation.

[0390] Figure 14 This is a schematic flowchart illustrating a method provided in this application for a source device to request a query from an HID to the target HID regarding the current transport protocol status. Figure 14 As shown, the method may include steps 1410-1420, which will be described in detail below.

[0391] Step 1410: The source device sends a protocol acquisition request message to the destination device.

[0392] As an example, the source device sends a protocol request message to the destination device. This protocol request message is used to request the current transport protocol status from the target HID. The protocol request message includes the identifier of the target HID and the session identifier.

[0393] It should be understood that the aforementioned acquisition protocol request message may, for example, be received by the source device from the input processing module corresponding to the target HID.

[0394] For example, the above-mentioned protocol request message can also be called a GET_PROTOCOL message.

[0395] It should be understood that the GET_PROTOCOL message is a control transport request from a host to an HID device requesting the current transport protocol status.

[0396] For example, the following lists some of the main functions of the GET_PROTOCOL message.

[0397] 1. HID device communication mode query:

[0398] a) Protocol switching monitoring: The host queries the HID device's current HID transmission protocol (Boot Protocol or Report Protocol) through the GET_PROTOCOL message to understand the HID device's communication mode.

[0399] b) HID device status diagnosis: When the HID device experiences communication abnormalities or requires troubleshooting, the host queries the protocol status of the HID device through the GET_PROTOCOL message to determine whether the HID device has switched to the wrong protocol.

[0400] 2. HID device initialization and recovery:

[0401] a) HID device reset: After the HID device is powered off or unexpectedly restarted, the host queries the protocol status of the HID device through the GET_PROTOCOL message to restore the normal working mode of the HID device.

[0402] b) HID device configuration recovery: When the HID device recovers from a fault state to a normal working state, the host queries the protocol status of the HID device through the GET_PROTOCOL message to restore the configuration information of the HID device.

[0403] For example, the structure of the GET_PROTOCOL message described above will be explained below with reference to Table 16.

[0404] Table 16 Structure of the GET_PROTOCOL message

[0405]

[0406] It should be noted that in the GET_PROTOCOL message sent from the source device to the destination device, the bProtocol field in the message body is the protocol type expected by the source device's HID driver.

[0407] Step 1420: The destination device sends an Acquire Protocol Response message to the source device.

[0408] As an example, after receiving the Acquire Protocol Request message sent by the source device, the destination device initiates an Acquire Protocol Request to the HID device corresponding to bDeviceId. For example, it initiates an Acquire Protocol Request message (e.g., GET_PROTOCOL request message or Get_Protocol, or Get_Protocol Request) to the target HID through step 1413 to obtain the current transport protocol status of the target HID.

[0409] For example, the destination device can return the current transport protocol status (e.g., bProtocol) of the target HID, as returned in step 1415, to the source device via a protocol response message, for example, via a GET_PROTOCOL response message. Upon receiving the GET_PROTOCOL response message, the source device returns bProtocol from the message body to the input processing module corresponding to the target HID, for example, returning bProtocol from the message body to the HID driver corresponding to DeviceId.

[0410] For example, the above-mentioned protocol response message can also be called a GET_PROTOCOL response message.

[0411] It should be noted that the structure of this GET_PROTOCOL response message is the same as that of the GET_PROTOCOL message. For details on the structure of the GET_PROTOCOL response message, please refer to the description of the structure of the GET_PROTOCOL message in Table 16. It will not be repeated here.

[0412] The following is combined Figure 15 This paper describes the specific implementation process of communication between the source device and the HID device in the destination device through the SET_PROTOCOL operation.

[0413] Figure 15 This is a schematic flowchart illustrating a method provided in this application for a source device to set the HID transmission protocol currently required by the target HID. Figure 15 As shown, the method may include steps 1510-1520, which will be described in detail below.

[0414] Step 1510: The source device sends a configuration protocol request message to the destination device.

[0415] As an example, the source device sends a configuration protocol request message to the destination device. This configuration protocol request message is used to specify the HID transport protocol that the target HID should currently use. The configuration protocol request message includes the identifier of the target HID, the session identifier, and the HID transport protocol that the target HID should currently use.

[0416] It should be understood that the aforementioned setup protocol request message may, for example, be received by the source device from the input processing module corresponding to the target HID.

[0417] For example, the above-mentioned protocol request message can also be called a SET_PROTOCOL message.

[0418] It should be understood that the SET_PROTOCOL message is a request sent by a host to an HID device to set the HID transport protocol (e.g., Boot Protocol or Report Protocol) currently used by the HID device.

[0419] For example, the following lists some of the main functions of the SET_PROTOCOL message.

[0420] 1. HID device communication mode switching:

[0421] a) Protocol switching: The host sets the HID transmission protocol used by the HID device through the SET_PROTOCOL message to switch the communication mode of the HID device.

[0422] b) HID device status diagnosis: When the HID device experiences communication abnormalities or requires troubleshooting, the host sets the protocol status of the HID device through the SET_PROTOCOL message to determine whether the HID device has switched to the wrong protocol.

[0423] 2. HID device initialization and recovery:

[0424] a) HID device reset: After the HID device is powered off or unexpectedly restarted, the host sets the protocol status of the HID device through the SET_PROTOCOL message to restore the normal working mode of the HID device.

[0425] b) HID device configuration recovery: When the HID device recovers from a fault state to a normal working state, the host sets the protocol state of the HID device through the SET_PROTOCOL message to restore the configuration information of the HID device.

[0426] For example, the structure of the SET_PROTOCOL message described above will be explained below with reference to Table 17.

[0427] Table 17 Structure of the SET_PROTOCOL message

[0428]

[0429] Step 1520: The destination device sends a configuration protocol request message to the target HID.

[0430] As an example, after receiving the configuration protocol request message sent by the source device, the destination device sends the configuration protocol request message to the HID device corresponding to bDeviceId. For example, the destination device sends a configuration protocol request message (e.g., SET_PROTOCOL request message, Set_Protocol, or Set_Protocol Request) to the target HID.

[0431] After receiving the protocol setting request message, the target HID sets the HID transmission protocol that the target HID needs to use according to bProtocol in the protocol request message.

[0432] It should be noted that the SET_PROTOCOL message does not require a response; that is, the SET_PROTOCOL message has no corresponding response message.

[0433] The communication method provided in this application can solve the problem of networking and video signal transmission between multiple source devices and multiple destination devices in multiple rooms within a home. It also supports usage scenarios such as playing content from a living room set-top box on a bedroom TV, or playing games from a living room Xbox on a study monitor.

[0434] The communication method provided in this application has the following beneficial effects.

[0435] 1. Simplified remote control operation: Optimized operation of remote control for set-top boxes and TVs, allowing one remote control to operate TVs and multiple set-top boxes simultaneously, reducing the complexity of watching TV.

[0436] 2. Mobile Office: When the portable computer is connected to the monitor, the monitor automatically transmits the keyboard and mouse operations connected to it to the portable computer. At the same time, the monitor charges the portable computer, achieving a very simple connection for the portable computer.

[0437] 3. Multi-device switching: When switching the source from PlayStation to Xbox on a TV, the HID input of the game controller connected to the TV is automatically passed through to the new active source, Xbox, without having to change the game controller.

[0438] 4. Cross-room display: In any room, as long as a keyboard and mouse are plugged into the display screen, the HID input of the keyboard, mouse or remote control can be transparently transmitted to the source device in another room through the display screen, and the source device can be operated to play or play games.

[0439] The following is combined Figure 16 The specific implementation process for ending HID pass-through is described.

[0440] Figure 16 This is a schematic flowchart illustrating a method for HID pass-through between a destination device and a source device, provided in an embodiment of this application. Figure 16 As shown, the method may include steps 1610-1630, which will be described in detail below.

[0441] Step 1610: The destination device sends a request message to the source device to end HID pass-through.

[0442] In this embodiment of the application, when the destination device needs to disable the HID PassThrough function of the source device, the destination device can send a "End HID PassThrough Request" message to the source device. For example, after the source device is switched, the destination device needs to disable the original source device's HID PassThrough function, and in this case, it needs to send an "End HID PassThrough Request" message to the original source device.

[0443] The aforementioned End HID Transmission Request message is used to notify the source device to end the HID transmission session, wherein the End HID Transmission Request message includes the aforementioned session identifier.

[0444] For example, the above-mentioned message to end the HID passthrough request can also be called the End_HID_PassThrough message.

[0445] For example, the structure of the End_HID_PassThrough message described above will be explained below with reference to Table 18.

[0446] Table 18 Structure of the End_HID_PassThrough Message

[0447]

[0448] Step 1620: The source device unloads all input processing modules that are loaded on the source device and correspond to the HID that has been inserted into the destination device.

[0449] In this embodiment of the application, after the source device receives the end HID pass-through request message sent by the destination device, it can unload all input processing modules that have been loaded on the source device and correspond to each HID that has been inserted into the destination device. For example, it can unload all HID drivers that have been loaded on the source device and inserted into each HID of the destination device.

[0450] Step 1630: The source device sends a completion HID pass-through response message to the destination device.

[0451] In this embodiment of the application, after the source device unloads all the input processing modules that have been loaded on the source device, it can send a termination HID pass-through response message to the destination device. The termination HID pass-through response message is used to indicate that the source device has successfully unloaded all the loaded input processing modules.

[0452] For example, the above-mentioned End HID PassThrough response message can also be called the End_HID_PassThroughresponse message.

[0453] It should be understood that the structure of the End_HID_PassThrough response message is the same as that of the End_HID_PassThrough message. For details, please refer to the description of the structure of the End_HID_PassThrough message above, which will not be repeated here.

[0454] Figure 17 This is a schematic structural block diagram of an electronic device 1700 according to an embodiment of this application. The electronic device 1700 can be a receiving device, or it can be a chip in a receiving device; this embodiment of the application does not specifically limit it in this way.

[0455] As an example, such as Figure 17 The electronic device 1700 shown includes a receiving unit 1710 and a transmitting unit 1720.

[0456] The sending unit 1720 is configured to send a request message for adding a human-computer interaction device (HID) to the source device. This request message requests the source device to load an input processing module corresponding to the target HID. The request message includes an identifier assigned to the target HID by the destination device, device information of the target HID, and a report descriptor for the target HID. The target HID is any one of at least one HID already inserted into the destination device or a newly inserted HID. The receiving unit 1710 is configured to receive a response message from the source device for the added HID. This response message includes the identifier of the target HID and first indication information, indicating that the input processing module corresponding to the target HID has been successfully loaded into the source device. The sending unit 1720 is also configured to send an input report to the source device in response to receiving an input report from the target HID. The input report includes the identifier of the target HID and input report data, indicating an immediate input event generated by the target HID.

[0457] Optionally, the sending unit 1720 is further configured to send an HID pass-through request message to the source device, the HID pass-through request message being used to request the source device to allow an HID pass-through session between the destination device and the source device, the HID pass-through request message including the address of the destination device; the receiving unit 1710 is further configured to receive an HID pass-through response message from the source device, the HID pass-through response message including a session identifier assigned by the source device for the HID pass-through session; and wherein the request message for the new HID, the response message for the new HID, and the input report of the target HID also include the session identifier.

[0458] Optionally, the receiving unit 1710 is further configured to receive an output report from the source device, the output report including the identifier of the target HID, the session identifier, and output report data; the sending unit 1720 is further configured to send the output report to the target HID.

[0459] Optionally, the receiving unit 1710 is further configured to receive a first function report from the target HID; and send the first function report to the source device, wherein the first function report includes the identifier of the target HID, the session identifier, and first function report data.

[0460] Optionally, the receiving unit 1710 is further configured to receive a second function report from the source device, wherein the second function report includes the identifier of the target HID, the session identifier, and second function report data; and send the second function report to the target HID.

[0461] Optionally, the sending unit 1720 is further configured to send a request message to the source device to unload the HID in response to detecting that the target HID has been unplugged or that the target HID has malfunctioned. The request message to unload the HID requests the source device to unload the input processing module corresponding to the target HID. The request message to unload the HID includes the identifier of the target HID and the session identifier. The receiving unit 1710 is further configured to receive a response message to the unload the HID from the source device. The response message to the unload the HID indicates that the source device has successfully unloaded the input processing module corresponding to the target HID.

[0462] Optionally, the sending unit 1720 is further configured to send an end HID pass-through request message to the source device, the end HID pass-through request message being used to notify the source device to end the HID pass-through session, the end HID pass-through request message including the session identifier; the receiving unit 1710 is further configured to receive an end HID pass-through response message from the source device, the end HID pass-through response message indicating that the source device has successfully unloaded all loaded input processing modules.

[0463] Optionally, the receiving unit 1710 is further configured to receive a report request message from the source device, the report request message being used to request specific report data from the target HID, the report request message including the identifier of the target HID and the session identifier; the sending unit 1720 is further configured to send the report request message to the target HID; receive the specific report data from the target HID; and the sending unit 1720 is further configured to send a report response message to the source device, the report response message including the identifier of the target HID and the specific report data.

[0464] Optionally, the specific report data can be data from an input report or a feature report.

[0465] Optionally, the specific report data may include the device status, control information, or configuration data of the target HID.

[0466] Optionally, the receiving unit 1710 is further configured to receive a configuration report request message from the source device, the configuration report request message including the identifier of the target HID, the session identifier, and specific report data; the sending unit 1720 is further configured to send the configuration report request message to the target HID.

[0467] Optionally, the specific report data may be from an output report or a feature report.

[0468] Optionally, this specific report data may include control commands or configuration data.

[0469] Optionally, the receiving unit 1710 is further configured to receive an idle status request message from the source device, the idle status request message being used to query the target HID for the current input idle status, the idle status request message including the identifier of the target HID and the session identifier; the receiving unit 1710 is further configured to receive the current input idle status from the target HID, the current input idle status of the target HID indicating the idle time of the currently specified input report; the sending unit 1720 is further configured to send an idle status response message to the source device, the idle status response message including the identifier of the target HID, the session identifier, and the current input idle status of the target HID.

[0470] Optionally, the receiving unit 1710 is further configured to receive a setting idle state request message from the source device, the setting idle state request message being used to request setting a time during which the target HID remains silent before receiving a user input event, the setting idle state request message including the identifier of the target HID, the session identifier, and the time; the sending unit 1720 is further configured to send the setting idle state request message to the target HID.

[0471] Optionally, the receiving unit 1710 is further configured to receive an acquisition protocol request message from the source device, the acquisition protocol request message being used to request the current transport protocol status from the target HID, the acquisition protocol request message including the identifier of the target HID and the session identifier; the sending unit 1720 is further configured to send the acquisition protocol request message to the target HID; the receiving unit 1710 is further configured to receive the current transport protocol status from the target HID; the sending unit 1720 is further configured to send an acquisition protocol response message to the source device, the acquisition protocol response message including the identifier of the target HID and the current transport protocol status of the target HID.

[0472] Optionally, the receiving unit 1710 is further configured to receive a setup protocol request message from the source device, the setup protocol request message being used to specify the HID transmission protocol currently required by the target HID, the setup protocol request message including the identifier of the target HID, the session identifier, and the HID transmission protocol currently required by the target HID; the sending unit 1720 is further configured to send the setup protocol request message to the target HID.

[0473] Optionally, the type of the HID transport protocol can be either a root protocol or a reporting protocol.

[0474] Optionally, the device information of the target HID includes the device vendor code, product code, or version number of the code, device name, physical address, and serial number of the target HID.

[0475] Figure 18 This is a schematic structural block diagram of an electronic device 1800 according to an embodiment of this application. The electronic device 1800 may be a source device or a chip in a source device; this embodiment of the application does not specifically limit it in this regard.

[0476] As an example, such as Figure 18 The electronic device 1800 shown includes a receiving unit 1810, a processing unit 1820, and a transmitting unit 1830.

[0477] The receiving unit 1810 is configured to receive a request message for a newly added human-computer interaction device (HID) from the destination device. This request message requests the source device to load an input processing module corresponding to the target HID. The request message includes an identifier assigned to the target HID by the destination device, device information of the target HID, and a report descriptor for the target HID. The target HID is any one of at least one HID already inserted into the destination device or a newly inserted HID. The processing unit 1820 is configured to process the target HID according to its device information and the target HID's... The report descriptor loads the input processing module corresponding to the target HID; the sending unit 1830 is used to send a response message for the newly added HID to the destination device. The response message for the newly added HID includes the identifier of the target HID and first indication information. The first indication information is used to indicate that the input processing module corresponding to the target HID has been successfully loaded in the source device; the receiving unit 1810 is also used to receive an input report from the target HID from the destination device. The input report includes the identifier of the target HID and input report data. The input report indicates the instantaneous input event generated by the target HID.

[0478] Optionally, the receiving unit 1810 is further configured to receive an HID pass-through request message from the destination device, the HID pass-through request message being used to request the source device to allow an HID pass-through session between the destination device and the source device, the HID pass-through request message including the address of the destination device; the sending unit 1830 is further configured to send an HID pass-through response message to the destination device, the HID pass-through response message including a session identifier assigned by the source device for the HID pass-through session; and wherein the request message for the new HID, the response message for the new HID, and the input report of the target HID also include the session identifier.

[0479] Optionally, the receiving unit 1810 is further configured to receive an output report from the input processing module corresponding to the target HID, the output report including the identifier of the target HID, the session identifier, and output report data; the sending unit 1830 is further configured to send the output report to the destination device.

[0480] Optionally, the receiving unit 1810 is further configured to receive a first function report from the target HID from the destination device, wherein the first function report includes the identifier of the target HID, the session identifier, and first function report data; the processing unit 1820 is further configured to process the first function report through an input processing module corresponding to the target HID.

[0481] Optionally, the receiving unit 1810 is further configured to receive a second function report from the input processing module corresponding to the target HID, wherein the second function report includes the identifier of the target HID, the session identifier, and second function report data; the sending unit 1830 is further configured to send the second function report to the destination device.

[0482] Optionally, the receiving unit 1810 is further configured to receive a request message for unloading HID from the destination device, wherein the request message for unloading HID is used to request the source device to unload the input processing module corresponding to the target HID, and the request message for unloading HID includes the identifier of the target HID and the session identifier; the sending unit 1830 is further configured to send a response message for unloading HID to the destination device, wherein the response message for unloading HID indicates that the source device has successfully unloaded the input processing module corresponding to the target HID.

[0483] Optionally, the receiving unit 1810 is further configured to receive a termination HID pass-through request message from the destination device, the termination HID pass-through request message being used to notify the source device to terminate the HID pass-through session, the termination HID pass-through request message including the session identifier; the sending unit 1830 is further configured to send a termination HID pass-through response message to the destination device, the termination HID pass-through response message indicating that the source device has successfully unloaded all loaded input processing modules.

[0484] Optionally, the sending unit 1830 is further configured to send a report request message to the destination device, the report request message being used to request specific report data from the target HID, the report request message including the identifier of the target HID and the session identifier; the receiving unit 1810 receives a report response message from the destination device, the report response message including the identifier of the target HID and the specific report data.

[0485] Optionally, the specific report data can be data from an input report or a feature report.

[0486] Optionally, the specific report data may include the device status, control information, or configuration data of the target HID.

[0487] Optionally, the sending unit 1830 is further configured to send a configuration report request message to the destination device, the configuration report request message including the identifier of the target HID, the session identifier, and specific report data.

[0488] Optionally, the specific report data may be from an output report or a feature report.

[0489] Optionally, this specific report data may include control commands or configuration data.

[0490] Optionally, the receiving unit 1810 is further configured to receive an idle status request message from the input processing module corresponding to the target HID, the idle status request message being used to query the target HID for the current input idle status, the idle status request message including the identifier of the target HID and the session identifier; the sending unit 1830 is further configured to send the idle status request message to the destination device; the receiving unit 1810 is further configured to receive an idle status response message from the destination device, the idle status response message including the identifier of the target HID, the session identifier, and the current input idle status of the target HID.

[0491] Optionally, the receiving unit 1810 is further configured to receive a set idle state request message from the input processing module corresponding to the target HID. The set idle state request message is used to set the target HID to remain silent for a period of time before receiving a user input event. The set idle state request message includes the identifier of the target HID, the session identifier, and the time. The sending unit 1830 is further configured to send the set idle state request message to the destination device.

[0492] Optionally, the receiving unit 1810 is further configured to receive an acquisition protocol request message from the input processing module corresponding to the target HID, the acquisition protocol request message being used to request the current transport protocol status from the target HID, the acquisition protocol request message including the identifier of the target HID and the session identifier; the sending unit 1830 is further configured to send the acquisition protocol request message to the destination device; the receiving unit 1810 is further configured to receive an acquisition protocol response message from the destination device, the acquisition protocol response message including the identifier of the target HID and the current transport protocol status of the target HID.

[0493] Optionally, the receiving unit 1810 is further configured to receive a setting protocol request message from the input processing module corresponding to the target HID. The setting protocol request message is used to specify the HID transmission protocol that the target HID currently needs to use. The setting protocol request message includes the identifier of the target HID, the session identifier, and the HID transmission protocol that the target HID currently needs to use. The sending unit 1830 is further configured to send the setting protocol request message to the destination device.

[0494] Optionally, the type of the HID transport protocol can be either a root protocol or a reporting protocol.

[0495] Optionally, the device information of the target HID includes the device vendor code, product code, or version number of the code, device name, physical address, and serial number of the target HID.

[0496] This application also provides an electronic device. This electronic device can be used to implement the embodiments of the methods described above. The electronic device includes a processor and a memory. The processor is used to execute computer programs or instructions stored in the memory, or to read data / signaling stored in the memory, to execute the methods in the above method embodiments. The memory can be integrated with the processor, or it can be separately configured. Optionally, there may be one or more processors. Optionally, there may be one or more memories. Optionally, the electronic device may further include a transceiver (or communication interface) for receiving and / or transmitting signals.

[0497] It should be understood that the processor mentioned in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0498] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM). For example, RAM can be used as an external cache. By way of example and not limitation, RAM includes the following forms: static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0499] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) can be integrated into the processor.

[0500] It should also be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0501] This application also provides a chip system. The chip system (or processing system) includes logic circuits and an input / output interface.

[0502] The logic circuit can be a processing circuit in the chip system. The logic circuit can be coupled to a memory cell, calling instructions from the memory cell, enabling the chip system to implement the methods and functions of the embodiments of this application. The input / output interface can be an input / output circuit in the chip system, outputting processed information or inputting data or signaling information to be processed into the chip system for processing.

[0503] As one approach, this chip system is used to implement embodiments of the methods described above. For example, the chip system is used to implement processing-related operations performed by the source device in the method embodiments described above.

[0504] As one approach, this chip system is used to implement embodiments of the methods described above. For example, the chip system is used to implement processing-related operations performed by the destination device in the method embodiments described above.

[0505] This application also provides a computer-readable storage medium storing computer instructions for implementing the methods executed by the source device in the above-described method embodiments.

[0506] This application also provides a computer-readable storage medium storing computer instructions for implementing the methods executed by the destination device in the above-described method embodiments.

[0507] This application also provides a computer program product comprising instructions which, when executed by a computer, implement the methods performed by the source device in the above-described method embodiments.

[0508] This application also provides a computer program product comprising instructions which, when executed by a computer, implement the methods executed by the destination device in the above-described method embodiments.

[0509] This application also provides a communication system, including the aforementioned source device and destination device.

[0510] The explanations and beneficial effects of the relevant contents in any of the devices provided above can be found in the corresponding method embodiments provided above, and will not be repeated here.

[0511] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

[0512] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. For example, the computer can be a personal computer, a server, or a network device, etc. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs). For example, the aforementioned available media include, but are not limited to, USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, and other media capable of storing program code.

[0513] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of communication, comprising: Comprising: At the sink device, sending a request message for adding a human interface device (HID) to a source device, the request message for adding the HID being used to request the source device to load an input processing module corresponding to a target HID, and the request message for adding the HID including an identifier assigned by the sink device to the target HID, device information of the target HID, and a report descriptor of the target HID, the target HID being any one of at least one HID already plugged into the sink device or a HID newly plugged into the sink device; Receiving a response message for adding the HID from the source device, the response message for adding the HID including the identifier of the target HID and first indication information, the first indication information being used to indicate that the input processing module corresponding to the target HID has been successfully loaded in the source device; In response to receiving an input report from the target HID, sending the input report to the source device, wherein the input report includes the identifier of the target HID and input report data, the input report indicating an instant input event generated by the target HID.

2. The method of claim 1, wherein, The method further comprises: Sending a HID pass-through request message to the source device, the HID pass-through request message being used to request the source device to allow a HID pass-through session between the sink device and the source device, the HID pass-through request message including an address of the sink device; Receiving a HID pass-through response message from the source device, the HID pass-through response message including a session identifier assigned by the source device for the HID pass-through session; And wherein the request message for adding the HID, the response message for adding the HID, and the input report of the target HID further include the session identifier.

3. The method of claim 2, wherein, The method further comprises: Receiving an output report from the source device, the output report including the identifier of the target HID, the session identifier, and output report data; and sending the output report to the target HID.

4. The method according to claim 2 or 3, characterized in that, The method further comprises: Receiving a first function report from the target HID; Sending the first function report to the source device, wherein the first function report includes the identifier of the target HID, the session identifier, and first function report data.

5. The method according to any one of claims 2 to 4, characterized in that, The method further comprises: Receiving a second function report from the source device, wherein the second function report includes the identifier of the target HID, the session identifier, and second function report data; Sending the second function report to the target HID.

6. The method according to any one of claims 2 to 5, characterized in that, The method further comprises: In response to detecting that the target HID is unplugged or the target HID is faulty, sending a request message for unloading a HID to the source device, wherein the request message for unloading the HID is used to request the source device to unload an input processing module corresponding to the target HID, the request message for unloading the HID including the identifier of the target HID and the session identifier. receiving an unload HID response message from the source device, wherein the unload HID response message indicates that the source device has successfully unloaded the input processing module corresponding to the target HID.

7. The method according to any one of claims 2 to 6, characterized in that, The method further comprises: sending an end HID pass-through request message to the source device, the end HID pass-through request message being used to inform the source device to end the HID pass-through session, the end HID pass-through request message comprising the session identifier; receiving an end HID pass-through response message from the source device, the end HID pass-through response message indicating that the source device has successfully unloaded all loaded input processing modules corresponding to the HID that has been inserted into the sink device.

8. The method according to any one of claims 2 to 7, characterized in that, The method further comprises: receiving an acquire report request message from the source device, the acquire report request message being used to request specific report data from the target HID, the acquire report request message comprising the identifier of the target HID and the session identifier; sending the report request message to the target HID; receiving the specific report data from the target HID; sending an acquire report response message to the source device, the acquire report response message comprising the identifier of the target HID and the specific report data.

9. The method of claim 8, wherein, The specific report data is data of an input report or a function report.

10. The method according to claim 8 or 9, characterized in that, The specific report data comprises device status, control information or configuration data of the target HID.

11. The method according to any one of claims 2 to 10, characterized in that, The method further comprises: receiving a set report request message from the source device, the set report request message comprising the identifier of the target HID, the session identifier and specific report data; sending the set report request message to the target HID.

12. The method of claim 11, wherein, The specific report data is data of an output report or a function report.

13. The method according to claim 11 or 12, characterized in that, The specific report data comprises control instructions or configuration data.

14. The method according to any one of claims 2 to 13, characterized in that, The method further comprises: receiving an acquire idle state request message from the source device, the acquire idle state request message being used to request current input idle state from the target HID, the acquire idle state request message comprising the identifier of the target HID and the session identifier; receiving the current input idle state of the target HID, the current input idle state of the target HID indicating idle time of a specified input report; sending an acquire idle state response message to the source device, the acquire idle state response message comprising the identifier of the target HID, the session identifier and the current input idle state of the target HID.

15. The method according to any one of claims 2 to 14, characterized in that, The method further comprises: receiving a set idle state request message from the source device, the set idle state request message being used to request to set time for the target HID to remain silent before receiving a user input event, the set idle state request message comprising the identifier of the target HID, the session identifier and the time; sending the set idle state request message to the target HID.

16. The method according to any one of claims 2 to 15, characterized in that, The method further comprises: receiving a get protocol request message from the source device, the get protocol request message being used to request a current transport protocol state of the target HID, the get protocol request message comprising an identification of the target HID and the session identification; sending the get protocol request message to the target HID; receiving the current transport protocol state from the target HID; sending a get protocol response message to the source device, the get protocol response message comprising the identification of the target HID and the current transport protocol state of the target HID.

17. The method according to any one of claims 2 to 16, characterized in that, The method further comprises: receiving a set protocol request message from the source device, the set protocol request message being used to specify a HID transport protocol currently required by the target HID, the set protocol request message comprising an identification of the target HID, the session identification and the HID transport protocol currently required by the target HID; sending the set protocol request message to the target HID.

18. The method of claim 17, wherein, The type of the HID transport protocol is a root protocol or a report protocol.

19. The method of any one of claims 1 to 18, wherein, The device information of the target HID comprises a device vendor code, a product code, or a version number of a code, a device name, a physical address and a serial number of the target HID.

20. A method of communication, comprising: Comprise: At a source device, receiving a request message for adding a human-computer interaction device (HID) from a sink device, the request message for adding the HID being used to request the source device to load an input processing module corresponding to a target HID, and the request message for adding the HID comprising an identification allocated by the sink device to the target HID, device information of the target HID and a report descriptor of the target HID, the target HID being any one of at least one HID that has been inserted into the sink device or a HID newly inserted into the sink device; loading the input processing module corresponding to the target HID according to the device information of the target HID and the report descriptor of the target HID; sending a response message for adding the HID to the sink device, the response message for adding the HID comprising the identification of the target HID and first indication information, the first indication information being used to indicate that the input processing module corresponding to the target HID has been successfully loaded in the source device, and receiving an input report from the target HID from the sink device, wherein the input report comprises the identification of the target HID and input report data, and the input report is used to indicate an instant input event generated by the target HID.

21. The method of claim 20, wherein, The method further comprises: receiving a HID pass-through request message from the sink device, the HID pass-through request message being used to request the source device to allow a HID pass-through session between the sink device and the source device, the HID pass-through request message comprising an address of the sink device; sending a HID pass-through response message to the sink device, the HID pass-through response message comprising a session identification allocated by the source device for the HID pass-through session; And wherein the request message for adding the HID, the response message for adding the HID, and the input report of the target HID further comprise the session identifier.

22. The method of claim 21, wherein, The method further comprises: receiving an output report from an input processing module corresponding to the target HID, the output report comprising an identifier of the target HID, the session identifier, and output report data; sending the output report to the sink device.

23. The method of claim 21 or 22, wherein, The method further comprises: receiving a first function report from the target HID from the sink device, wherein the first function report comprises an identifier of the target HID, the session identifier, and first function report data; processing the first function report by an input processing module corresponding to the target HID.

24. The method of any one of claims 21-23, wherein, The method further comprises: receiving a second function report from an input processing module corresponding to the target HID, wherein the second function report comprises an identifier of the target HID, the session identifier, and second function report data; sending the second function report to the sink device.

25. The method of any one of claims 21-24, wherein, The method further comprises: receiving an offload HID request message from the sink device, wherein the offload HID request message is used to request the source device to offload an input processing module corresponding to the target HID, and the offload HID request message comprises an identifier of the target HID and the session identifier; sending an offload HID response message to the sink device, wherein the offload HID response message indicates that the source device has successfully offloaded the input processing module corresponding to the target HID.

26. The method of any one of claims 21-25, wherein, The method further comprises: receiving an end HID pass-through request message from the sink device, the end HID pass-through request message being used to inform the source device to end the HID pass-through session, and the end HID pass-through request message comprising the session identifier; sending an end HID pass-through response message to the sink device, the end HID pass-through response message indicating that the source device has successfully offloaded all input processing modules corresponding to the HID that has been inserted into the sink device.

27. The method of any one of claims 21-26, wherein, The method further comprises: sending an obtain report request message to the sink device, the obtain report request message being used to request specific report data from the target HID, and the obtain report request message comprising an identifier of the target HID and the session identifier; receiving an obtain report response message from the sink device, the obtain report response message comprising the identifier of the target HID and the specific report data.

28. The method of claim 27, wherein, The specific report data is data of an input report or a function report.

29. The method of claim 27 or 28, wherein, The specific report data comprises device status, control information, or configuration data of the target HID.

30. The method of any one of claims 21-29, wherein, The method further comprises: sending a set report request message to the sink device, the set report request message comprising an identifier of the target HID, the session identifier, and specific report data.

31. The method of claim 30, wherein, The specific report data is data of an output report or a function report.

32. The method of claim 30 or 31, wherein, The specific report data comprises control instructions or configuration data.

33. The method of any one of claims 21-32, wherein, The method further comprises: receiving an idle state acquisition request message from the input processing module corresponding to the target HID, the idle state acquisition request message being used to request a current input idle state of the target HID, the idle state acquisition request message comprising an identification of the target HID and the session identification; sending the idle state acquisition request message to the sink device; receiving an idle state acquisition response message from the sink device, the idle state acquisition response message comprising the identification of the target HID, the session identification, and the current input idle state of the target HID.

34. The method of any one of claims 21-33, wherein, The method further comprises: receiving a set idle state request message from the input processing module corresponding to the target HID, the set idle state request message being used to set a time for the target HID to remain silent before receiving a user input event, the set idle state request message comprising the identification of the target HID, the session identification, and the time; sending the set idle state request message to the sink device.

35. The method of any one of claims 21-34, wherein, The method further comprises: receiving a get protocol request message from the input processing module corresponding to the target HID, the get protocol request message being used to request a current transmission protocol state of the target HID, the get protocol request message comprising the identification of the target HID and the session identification; sending the get protocol request message to the sink device; receiving a get protocol response message from the sink device, the get protocol response message comprising the identification of the target HID and the current transmission protocol state of the target HID.

36. The method of any one of claims 21-35, wherein, The method further comprises: receiving a set protocol request message from the input processing module corresponding to the target HID, the set protocol request message being used to specify a HID transmission protocol currently required to be used by the target HID, the set protocol request message comprising the identification of the target HID, the session identification, and the HID transmission protocol currently required to be used by the target HID; sending the set protocol request message to the sink device.

37. The method of claim 36, wherein, The type of the HID transmission protocol is a root protocol or a report protocol.

38. The method of any one of claims 20-37, wherein, The device information of the target HID comprises a device vendor code, a product code, or a version number of a code, a device name, a physical address, and a serial number of the target HID.

39. An electronic device, comprising: The electronic device is configured to implement the method of any one of claims 1 to 19, and / or to implement the method of any one of claims 20 to 38.

40. A computer device, comprising: comprising: a processor configured to couple with a memory, read and execute instructions and / or program codes in the memory to perform the method of any one of claims 1 to 19, and / or to perform the method of any one of claims 20 to 38.

41. A chip system, characterized by comprising: a logic circuit configured to couple with an input / output interface, transmit data through the input / output interface to perform the method of any one of claims 1 to 19, and / or to perform the method of any one of claims 20 to 38.

42. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program code which, when run on a computer, causes the computer to perform the method of any one of claims 1 to 19, and / or to perform the method of any one of claims 20 to 38.

Images