Method for communication, and related apparatus

Abstract

Provided in the present application are a method for communication, and a related apparatus. The method comprises: at a sink apparatus, sending to a source apparatus a request message for adding a new HID, the request message for adding a new HID comprising an identifier allocated to a target HID by the sink apparatus, device information of the target HID, and a report descriptor of the target HID, and the target HID being any one of at least one HID that has been inserted into the sink apparatus or an HID newly inserted into the sink apparatus; receiving from the source apparatus a response message for adding a new HID, the response message comprising the identifier of the target HID and first indication information, and 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 apparatus; and, in response to receiving an input report from the target HID, sending the input report to the source apparatus, the input report comprising the identifier of the target HID and input report data. The described technical solution can satisfy the increasingly diverse human-computer interaction requirements at present.

Description

Communication methods and related equipment

[0001] This application claims priority to Chinese Patent Application No. 202411219934.4, filed with the China National Intellectual Property Administration on August 30, 2024, entitled “Method and Related Apparatus for Communication”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communications, and more specifically to methods and related equipment for communications. Background Technology

[0003] 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.

[0004] 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.

[0005] The aforementioned technical solutions only support the pass-through of remote control buttons and cannot meet the pass-through of other types of HID input events. Therefore, they cannot meet the increasingly diverse human-computer interaction needs.

[0006] Therefore, how to meet the increasingly diverse needs of human-computer interaction is a problem that urgently needs to be solved in this field. Summary of the Invention

[0007] This application provides a communication method and related equipment, which is beneficial to meeting the increasingly diverse human-computer interaction needs.

[0008] In a first aspect, embodiments of this application provide a communication method, comprising: at a destination device, sending a request message for adding a human-computer interaction device (HID) to a source device, the request message requesting the source device to load an input processing module corresponding to a target HID, and the request message including an identifier assigned by the destination 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 inserted into the destination device or a newly inserted HID; receiving a response message for the added HID from the source device, the response message including an identifier of the target HID and first indication information, the first indication information indicating that an 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 an identifier of the target HID and input report data, the input report indicating an immediate input event generated by the target HID.

[0009] The above technical solution, by loading an input processing module corresponding to the target HID on the source device, is equivalent to creating a virtual target HID on the source device. This allows the destination device to pass through HID events (including HID input reports and HID function reports) obtained from any target HID to the source device. Alternatively, the destination device can also pass through HID events (including HID output reports and HID function reports) obtained from the source device to the target HID connected to the destination device. This not only supports the simultaneous pass-through of multiple different HIDs but also allows for the insertion of new HIDs during use, thus meeting the increasingly diverse human-computer interaction needs.

[0010] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: sending 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; receiving 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.

[0011] In the above technical solution, the source device assigns a session identifier to the HID pass-through session of a certain destination device, thereby avoiding the conflict problem of target HID identifier when multiple destination devices simultaneously perform HID pass-through to a source device.

[0012] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving an output report from the source device, the output report including an identifier of the target HID, a session identifier, and output report data; and sending the output report to the target HID.

[0013] The above technical solution can support the pass-through of output events during the HID pass-through stage.

[0014] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving a first function report from the target HID; sending the first function report to the source device, wherein the first function report includes an identifier of the target HID, a session identifier, and first function report data.

[0015] The above technical solution can support the transparent transmission of functional reports from the HID device to the source device during the HID transparent transmission phase.

[0016] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving a second function report from the source device, 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 target HID.

[0017] The above technical solution can support the transparent transmission of functional reports from the source device to the HID device during the HID transparent transmission phase.

[0018] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: in response to detecting that the target HID has been unplugged or that the target HID has malfunctioned, sending a request message to the source device to unload the HID, wherein the request message to unload the HID is used to request the source device to unload the input processing module corresponding to the target HID, and the request message to unload the HID includes an identifier of the target HID and a session identifier; receiving a response message to unload the HID from the source device, wherein the response message to unload the HID indicates that the source device has successfully unloaded the input processing module corresponding to the target HID.

[0019] The above technical solution can support the removal of the HID device on the destination device during the HID pass-through phase.

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

[0021] In the above technical solution, when the destination device switches to the source device, it is necessary to stop passing HID events to the old source device before passing them to the new source device.

[0022] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving 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 an identifier of the target HID and a session identifier; sending the report request message to the target HID; receiving the specific report data from the target HID; and sending a report response message to the source device, the report response message including an identifier of the target HID and the specific report data.

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

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

[0025] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving 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; and sending the configuration report request message to the target HID.

[0026] In conjunction with the first aspect, in one possible implementation of the first aspect, the specific report data is data from an output report or a functional report.

[0027] In conjunction with the first aspect, in one possible implementation of the first aspect, the specific reporting data includes control instructions or configuration data.

[0028] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving 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; receiving 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; and sending 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.

[0029] In conjunction with the first aspect, in one possible implementation 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 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; and sending the setting idle state request message to the target HID.

[0030] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving an Acquire Protocol Request message from the source device, the Acquire Protocol Request message being used to request the current transport protocol status from the target HID, the Acquire Protocol Request message including the identifier of the target HID and the session identifier; sending the Acquire Protocol Request message to the target HID; receiving the current transport protocol status from the target HID; and sending an Acquire Protocol Response message to the source device, the Acquire Protocol Response message including the identifier of the target HID and the current transport protocol status of the target HID.

[0031] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: receiving a setup protocol request message from the source device, the setup protocol request message being used to specify the HID transport 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 transport protocol currently required by the target HID; and sending the setup protocol request message to the target HID.

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

[0033] In conjunction with the first aspect, in one possible implementation of the first 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.

[0034] Secondly, embodiments of this application provide a communication method, the method comprising: at a source device, receiving a request message for a newly added human-computer interaction device (HID) from a destination device, the request message for a newly added HID being used to request the source device to load an input processing module corresponding to a target HID, and the request message for a newly added HID including an identifier assigned by the destination 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 inserted into the destination device or a newly inserted HID; according to the target... The device information of the HID and the report descriptor of the target HID are loaded with the input processing module corresponding to the target HID; a response message for the new HID is sent to the destination device, the response message for the new 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; an input report from the target HID is received from the destination device, wherein 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.

[0035] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving 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; sending 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.

[0036] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving an output report from an 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 the output report to the destination device.

[0037] In conjunction with the second aspect, in one possible implementation of the second aspect, the method further includes: receiving 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; and processing the first function report through an input processing module corresponding to the target HID.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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 functional report.

[0046] In conjunction with the second aspect, in one possible implementation of the second aspect, the specific reporting data includes control instructions or configuration data.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

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

[0059] 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.

[0060] 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.

[0061] 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.

[0062] In a twelfth aspect, embodiments of this application provide a computer program product comprising: computer program code that, when run on a computer, causes the computer to perform as described in the second aspect or any possible implementation thereof. Attached Figure Description

[0063] Figure 1 is a schematic block diagram of a system architecture applicable to an embodiment of this application.

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

[0065] Figure 3 is a schematic flowchart of a method for allocating a session identifier to a source device during the HID PassThrough initiation phase, as provided in an embodiment of this application.

[0066] Figure 4 is a schematic flowchart of a method for adding a new HID during the HID PassThrough startup phase provided in an embodiment of this application.

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

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

[0069] Figure 7 is a schematic flowchart of 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.

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

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

[0072] Figure 10 is a schematic flowchart of a method for a source device to request specific report data from HID according to an embodiment of this application.

[0073] Figure 11 is a schematic flowchart of a method for a source device to send specific report data to HID according to an embodiment of this application.

[0074] Figure 12 is a schematic flowchart of a method provided in this application for a source device to request a query of the current input idle status of a target HID.

[0075] Figure 13 is a schematic flowchart of a method for a source device to set an idle state of a specified input report to an HID according to an embodiment of this application.

[0076] Figure 14 is a schematic flowchart of a method provided in this application for a source device to request a query of the current transport protocol status of a target HID.

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

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

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

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

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

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

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

[0087] 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.

[0088] For ease of description, the following example illustrates a system architecture of an embodiment of this application, referring to Figure 1.

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

[0090] It should be understood that the embodiments of this application do not specifically limit the number of HIDs connected (hereinafter also referred to as insertions) on the host device. Figure 1 is illustrated using n HIDs as an example.

[0091] 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 passthrough refers to the destination device transmitting 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.

[0092] 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).

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

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

[0095] 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.

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

[0097] 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.

[0098] 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.

[0099] For example, as shown in Figure 2, 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.

[0100] 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.

[0101] 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.

[0102] 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.

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

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

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] Table 2 HID PassThrough Operations

[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 startup phase of HID PassThrough will be explained in detail below with reference to Figures 3 and 4.

[0112] Figure 3 is a schematic flowchart of a method for allocating a session identifier to a source device during the HID PassThrough initiation phase, according to an embodiment of this application. As shown in Figure 3, 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. Structure of the Start_HID_PassThrogh message

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

[0123] 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.

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

[0125] 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.

[0126] 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.

[0127] It should be understood that the above-mentioned HID passthrough request and response message can also be called the start HID passthrough response message, such as the Start_HID_PassThroghresponse message.

[0128] For example, the structure of the Start_HID_PassThroghresponse message will be explained below with reference to Table 4.

[0129] Table 4. Structure of the Start_HID_PassThroghresponse message

[0130] 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.

[0131] Figure 4 is a schematic flowchart of a method for adding a new HID during the HID PassThrough startup phase provided by an embodiment of this application. As shown in Figure 4, the method includes steps 400-440, which are described below.

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

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

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

[0141] 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.

[0142] 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.

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

[0144] Table 5. Structure of the Add_HID_Device message

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

[0146] 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.

[0147] 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.

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

[0149] 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.

[0150] 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.

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

[0152] For example, the structure of the Add_HID_Deviceresponse message will be explained below with reference to Table 6.

[0153] Table 6. Structure of the Add_HID_Deviceresponse message

[0154] 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.

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

[0156] Step 440 will be described in further detail below with reference to Figure 5.

[0157] The following section, with reference to Figures 5-8, describes the specific implementation process of transmitting input reports, output reports, and function reports during the HID pass-through phase.

[0158] 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.

[0159] 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.

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

[0161] As an example, Figure 5 is a schematic flowchart of the method for transmitting input reports during the HID pass-through stage. When the source device receives the HID input report of the HID corresponding to bDeviceId, the destination device can send the HID input report to the source device through the HID_Input_Report message. For example, as shown in Figure 5, 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.

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

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

[0164] Table 7 Structure of HID_Input_Report messages

[0165] In this embodiment, after receiving the HID_Input_Report message from the destination device, the source device reports the HID input report in the HID_Input_Report message to the source device's operating system through the HID driver corresponding to the bDeviceId loaded in the source device. For example, as shown in Figure 5, the source device obtains the 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.

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

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

[0168] 1. User input capture:

[0169] 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.

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

[0171] 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.

[0172] 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.

[0173] 2. System Interaction and Control:

[0174] 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.

[0175] 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).

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

[0177] 3. Application Input Processing:

[0178] 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.

[0179] 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.

[0180] 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.

[0181] 4. Accessibility features:

[0182] a) Assistive input devices: such as switches, alternative keyboards, and other input devices designed specifically for people with disabilities, which use HID input reports to translate user operations into instructions that the system can understand.

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

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

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] As an example, Figure 6 is a schematic flowchart of the method for transmitting output reports during the HID pass-through stage. As shown in Figure 6, 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 corresponding to bDeviceId. For example, as shown in Figure 6, after the source device receives the HID output report data from the target HID 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 it to the target HID.

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

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

[0192] Table 8. Structure of HID_Output_Report messages

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

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

[0195] 1. Equipment status control:

[0196] 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 the status of all connected keyboards is consistent with the system display.

[0197] 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.

[0198] 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.

[0199] 2. Device function switching:

[0200] 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.

[0201] 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.

[0202] 3. Information display:

[0203] 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.

[0204] 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.

[0205] 4. System Notification:

[0206] 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.

[0207] 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.

[0208] 5. Customization features:

[0209] 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.

[0210] 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.

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

[0212] 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.

[0213] 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.

[0214] As an example, Figure 7 is a schematic flowchart illustrating the method of transmitting a function report from a source device to an HID device through a destination device during the HID pass-through phase. After the input processing (also known as 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. After receiving the HID_Feature_Report message sent by the source device, the destination device sends the HID function report in the HID_Feature_Report message to the HID device corresponding to bDeviceId. For example, as shown in Figure 7, after the input processing corresponding to the target HID in the source device generates a function report, the source device sends the function report to the destination device via the HID_Feature_Report message in step 710. After receiving the HID_Feature_Report message sent by the source device, the destination device sends the HID function report in the HID_Feature_Report message to the HID corresponding to the target HID via step 720.

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

[0216] As an example, Figure 8 is a schematic flowchart of a method for an HID device to transmit a function report to a source device via a destination device during the HID pass-through phase. As shown in Figure 8, 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 then 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 this second function report in an HID_Output_Report message and sends it to the source device.

[0217] In this embodiment of the application, as shown in Figure 8, 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.

[0218] 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.

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

[0220] Table 9 Structure of HID_Feature_Report message

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

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

[0223] 1. Equipment configuration and control:

[0224] 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.

[0225] 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.

[0226] 2. Equipment Status Inquiry:

[0227] 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.

[0228] 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.

[0229] 3. Firmware updates and maintenance:

[0230] 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.

[0231] 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.

[0232] 4. Security authentication and encryption:

[0233] 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.

[0234] a) Device personalization and customization:

[0235] 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.

[0236] The following section, with reference to Figure 9, describes the specific implementation process of removing the HID device during the HID pass-through stage.

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

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

[0239] 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.

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

[0241] 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.

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

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

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

[0245] Table 10 Structure of the Remove_HID_Device message

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

[0247] 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.

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

[0249] 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.

[0250] For example, the response message for unloading HID mentioned above can also be called the Remove_HID_Deviceresponse message.

[0251] For example, the structure of the Remove_HID_Deviceresponse message will be explained below with reference to Table 11.

[0252] Table 11 Structure of the Remove_HID_Deviceresponse message

[0253] 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.

[0254] The following description, with reference to Figure 10, details the specific implementation process of communication between the source device and the HID device in the destination device via the GET_REPORT operation.

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

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

[0257] 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.

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

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

[0260] 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.

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

[0262] 1. Obtain device status:

[0263] 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.

[0264] 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.

[0265] 2. Equipment Control and Configuration:

[0266] 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.

[0267] 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.

[0268] 3. Equipment initialization and recovery:

[0269] 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.

[0270] 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.

[0271] 4. Equipment personalization and customization:

[0272] 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.

[0273] 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.

[0274] 5. Security Authentication and Encryption:

[0275] 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.

[0276] 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.

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

[0278] Table 12 Structure of the GET_REPORT message

[0279] 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.

[0280] 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.

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

[0282] 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 GetReport, or GetReport Request) to the target HID through step 1013 to obtain the HID report (e.g., specific report data) from the target HID.

[0283] 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.

[0284] 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.

[0285] 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.

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

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

[0288] 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.

[0289] The following description, with reference to Figure 11, details the specific implementation process of communication between the source device and the HID device in the destination device via the SET_REPORT operation.

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

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

[0292] 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.

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

[0294] 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.

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

[0296] 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.

[0297] 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.

[0298] 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.

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

[0300] 1. Equipment control and configuration:

[0301] 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.

[0302] 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.

[0303] 2. User interaction feedback:

[0304] 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.

[0305] 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.

[0306] 3. Equipment initialization and recovery:

[0307] 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.

[0308] 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.

[0309] 4. Equipment personalization and customization:

[0310] 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.

[0311] 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.

[0312] 5. Security Authentication and Encryption:

[0313] 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.

[0314] 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.

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

[0316] Table 13 Structure of the SET_REPORT message

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

[0318] 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.

[0319] 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.

[0320] 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.

[0321] The following description, with reference to Figure 12, details the specific implementation process of communication between the source device and the HID device in the destination device via the GET_IDLE operation.

[0322] Figure 12 is a schematic flowchart of a method for a source device to request a query of the current input idle status of a target HID according to an embodiment of this application. As shown in Figure 12, the method may include steps 1210-1220, which will be described in detail below.

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

[0324] 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.

[0325] 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.

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

[0327] 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.

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

[0329] 1. Equipment status monitoring:

[0330] 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.

[0331] 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.

[0332] 2. User interaction response:

[0333] 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.

[0334] 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.

[0335] 3. Equipment energy-saving management:

[0336] 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.

[0337] 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.

[0338] 4. Equipment troubleshooting:

[0339] 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.

[0340] b) Fault recovery tracking: When the HID device recovers from a faulty 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.

[0341] 5. Security Authentication and Encryption:

[0342] 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.

[0343] 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 record security events of the device.

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

[0345] Table 14 Structure of the GET_IDLE message

[0346] 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.

[0347] 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.

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

[0349] 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.

[0350] 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.

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

[0352] 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.

[0353] The following description, with reference to Figure 13, details the specific implementation process of communication between the source device and the HID device in the destination device via the SET_IDLE operation.

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

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

[0356] 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.

[0357] 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.

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

[0359] 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.

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

[0361] 1. HID device input timeout management:

[0362] 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.

[0363] 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.

[0364] 2. Optimized user interaction response:

[0365] 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.

[0366] 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.

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

[0368] Table 15 Structure of the SET_IDLE message

[0369] 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.

[0370] 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).

[0371] 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.

[0372] The following description, with reference to Figure 14, details the specific implementation process of communication between the source device and the HID device in the destination device via the GET_PROTOCOL operation.

[0373] Figure 14 is a schematic flowchart of 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. As shown in Figure 14, the method may include steps 1410-1420, which will be described in detail below.

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

[0375] 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.

[0376] 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.

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

[0378] 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.

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

[0380] 1. HID device communication mode query:

[0381] 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.

[0382] 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.

[0383] 2. HID device initialization and recovery:

[0384] 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.

[0385] 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.

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

[0387] Table 16 Structure of the GET_PROTOCOL message

[0388] 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.

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

[0390] 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.

[0391] 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. After 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.

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

[0393] 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.

[0394] The following description, with reference to Figure 15, details the specific implementation process of communication between the source device and the HID device in the destination device via the SET_PROTOCOL operation.

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

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

[0397] 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.

[0398] 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.

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

[0400] 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.

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

[0402] 1. HID device communication mode switching:

[0403] 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.

[0404] 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.

[0405] 2. HID device initialization and recovery:

[0406] 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.

[0407] 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.

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

[0409] Table 17 Structure of the SET_PROTOCOL message

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

[0411] 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.

[0412] 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.

[0413] 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.

[0414] 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.

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

[0416] 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.

[0417] 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.

[0418] 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.

[0419] 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.

[0420] The specific implementation process of ending HID pass-through is described below with reference to Figure 16.

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

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

[0423] 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.

[0424] 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.

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

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

[0427] Table 18 Structure of the End_HID_PassThrough Message

[0428] 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.

[0429] 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.

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

[0431] 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.

[0432] For example, the above-mentioned End HID Passthrough Response message can also be called the End_HID_PassThroughresponse message.

[0433] 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.

[0434] Figure 17 is a schematic structural block diagram of an electronic device 1700 according to an embodiment of this application. The electronic device 1700 may be a receiver device or a chip in a receiver device; this embodiment of the application does not specifically limit this.

[0435] As an example, the electronic device 1700 shown in FIG17 includes a receiving unit 1710 and a transmitting unit 1720.

[0436] 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.

[0437] 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.

[0438] 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.

[0439] 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.

[0440] 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.

[0441] 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.

[0442] 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.

[0443] 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.

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

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

[0446] 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.

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

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

[0449] 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.

[0450] 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.

[0451] 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.

[0452] 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.

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

[0454] 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.

[0455] Figure 18 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, and this embodiment of the application does not specifically limit it in this way.

[0456] As an example, the electronic device 1800 shown in FIG18 includes a receiving unit 1810, a processing unit 1820, and a transmitting unit 1830.

[0457] 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.

[0458] 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.

[0459] 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.

[0460] 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.

[0461] 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.

[0462] 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.

[0463] 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.

[0464] 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.

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

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

[0467] 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.

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

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

[0470] 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.

[0471] 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.

[0472] 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.

[0473] 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.

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

[0475] 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.

[0476] 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.

[0477] 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.

[0478] 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).

[0479] 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.

[0480] 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.

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

[0482] 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.

[0483] 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.

[0484] 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.

[0485] 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.

[0486] 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.

[0487] 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.

[0488] 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.

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

[0490] 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.

[0491] 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.

[0492] 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.

[0493] 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

A communication method, characterized in that, include: At the destination device, a request message for adding a new human-computer interaction device (HID) is sent to the source device. The request message for adding a new HID is used to request the source device to load an input processing module corresponding to the target HID. The request message for adding a new HID includes an identifier assigned by the destination device to the target HID, device information of the target HID, and a report descriptor of the target HID. The target HID is any one of at least one HID that has been inserted into the destination device or a newly inserted HID. The system receives a response message for a new HID from the source device. The response message for the new HID includes the identifier of the target HID and first indication information. The first indication information is used to indicate 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, wherein the input report includes an identifier of the target HID and input report data, and the input report indicates an immediate input event generated by the target HID. The method according to claim 1, characterized in that, The method further includes: Send an HID pass-through request message to the source 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. The HID pass-through request message includes the address of the destination device. Receive an HID passthrough response message from the source device, the HID passthrough response message including a session identifier assigned by the source device for the HID passthrough session; Furthermore, the request message for adding a new HID, the response message for adding a new HID, and the input report for the target HID also include the session identifier. The method according to claim 2, characterized in that, The method further includes: 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; send the output report to the target HID. The method according to claim 2 or 3, characterized in that, The method further includes: Receive the first functional report from the target HID; The first function report is sent to the source device, wherein the first function report includes the identifier of the target HID, the session identifier, and the first function report data. The method according to any one of claims 2 to 4, characterized in that, The method further includes: 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; Send the second function report to the target HID. The method according to any one of claims 2 to 5, characterized in that, The method further includes: In response to detecting that the target HID is unplugged or that the target HID is faulty, a request message to unload the HID is sent to the source device, wherein the request message to unload the HID is used to request the source device to unload the input processing module corresponding to the target HID, and the request message to unload the HID includes the identifier of the target HID and the session identifier; Receive a response message from the source device for unloading the HID, 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. The method according to any one of claims 2 to 6, characterized in that, The method further includes: Send an end HID pass-through request message to the source device. The end HID pass-through request message is used to notify the source device to end the HID pass-through session. The end HID pass-through request message includes the session identifier. Receive a termination HID passthrough response message from the source device, the termination HID passthrough 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 destination device. The method according to any one of claims 2 to 7, characterized in that, The method further includes: 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; Send the report request message to the target HID; Receive the specific report data from the target HID; Send a report retrieval response message to the source device, the report retrieval response message including the identifier of the target HID and the specific report data. The method according to claim 8, characterized in that, The specific report data refers to the data from the input report or the function report. The method according to claim 8 or 9, characterized in that, The specific report data includes the device status, control information, or configuration data of the target HID. The method according to any one of claims 2 to 10, characterized in that, The method further includes: 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; Send the configuration report request message to the target HID. The method according to claim 11, characterized in that, The specific report data refers to the data in the output report or the function report. The method according to claim 11 or 12 is characterized in that, The specific report data includes control commands or configuration data. The method according to any one of claims 2 to 13, characterized in that, The method further includes: Receive an idle status request message from the source device. The idle status request message is used to request the current input idle status from the target HID. The idle status request message includes the identifier of the target HID and the session identifier. Receive the current input idle state from the target HID, the current input idle state of the target HID indicating the idle time of the currently specified input report; Send an idle status response message to the source device. The idle status response message includes the identifier of the target HID, the session identifier, and the current input idle status of the target HID. The method according to any one of claims 2 to 14, characterized in that, The method further includes: Receive a Set Idle State Request message from the source device. The Set Idle State Request message is used to request setting a time during which the target HID remains silent 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. Send the Set Idle State Request message to the target HID. The method according to any one of claims 2 to 15, characterized in that, The method further includes: Receive a protocol request message from the source device, the protocol request message being used to request the current transport protocol status from the target HID, the protocol request message including the identifier of the target HID and the session identifier; Send the Acquire Protocol Request message to the target HID; Receive the current transport protocol status from the target HID; Send a protocol retrieval response message to the source device. The protocol retrieval response message includes the identifier of the target HID and the current transport protocol status of the target HID. The method according to any one of claims 2 to 16, characterized in that, The method further includes: Receive a configuration protocol request message from the source device. The configuration protocol request message is used to specify the HID transmission protocol that the target HID needs to use. The configuration protocol request message includes the identifier of the target HID, the session identifier, and the HID transmission protocol that the target HID needs to use. Send the configuration protocol request message to the target HID. The method according to claim 17, characterized in that, The HID transmission protocol is either a root protocol or a reporting protocol. The method according to any one of claims 1 to 18, characterized in that, The device information of the target HID includes the device supplier code, product code, or version number of the code, device name, physical address, and serial number of the target HID. A communication method, characterized in that, include: At the source device, a request message for a new human-computer interaction device (HID) is received from the destination device. The request message for a new HID is used to request the source device to load an input processing module corresponding to the target HID. The request message for a new HID includes an identifier assigned by the destination device to the target HID, device information of the target HID, and a report descriptor of the target HID. The target HID is any one of at least one HID that has been inserted into the destination device or a newly inserted HID. The input processing module corresponding to the target HID was loaded based on the device information of the target HID and the report descriptor of the target HID; 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 device receives 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 immediate input event generated by the target HID. The method according to claim 20, characterized in that, The method further includes: Receive an HID pass-through request message from 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. The HID pass-through request message includes the address of the destination device. Send an HID pass-through response message to the destination device, the HID pass-through response message including the session identifier assigned by the source device to the HID pass-through session; Furthermore, the request message for adding a new HID, the response message for adding a new HID, and the input report for the target HID also include the session identifier. The method according to claim 21, characterized in that, The method further includes: 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; Send the output report to the destination device. The method according to claim 21 or 22 is characterized in that, The method further includes: 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 first function report is processed by the input processing module corresponding to the target HID. The method according to any one of claims 21 to 23 is characterized in that, The method further includes: 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; Send the second function report to the destination device. The method according to any one of claims 21 to 24, characterized in that, The method further includes: Receive 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 the identifier of the target HID and the session identifier; Send a response message to the destination device to uninstall the HID, wherein the response message indicates that the source device has successfully uninstalled the input processing module corresponding to the target HID. The method according to any one of claims 21 to 25 is characterized in that, The method further includes: Receive an End HID Transmission Request Message from the destination device. The End HID Transmission Request Message is used to notify the source device to end the HID transmission session. The End HID Transmission Request Message includes the session identifier. Send a termination HID passthrough response message to the destination device. The termination HID passthrough response message indicates that the source device has successfully unloaded all loaded input processing modules corresponding to the HID that has been inserted into the destination device. The method according to any one of claims 21 to 26, characterized in that, The method further includes: Send a report request message to the destination device. The report request message is used to request specific report data from the target HID. The report request message includes the identifier of the target HID and the session identifier. The device receives a report retrieval response message, which includes the identifier of the target HID and the specific report data. The method according to claim 27, characterized in that, The specific report data refers to the data from the input report or the function report. The method according to claim 27 or 28 is characterized in that, The specific report data includes the device status, control information, or configuration data of the target HID. The method according to any one of claims 21 to 29, characterized in that, The method further includes: A configuration report request message is sent to the destination device. The configuration report request message includes the identifier of the target HID, the session identifier, and specific report data. The method according to claim 30, characterized in that, The specific report data refers to the data in the output report or the function report. The method according to claim 30 or 31 is characterized in that, The specific report data includes control commands or configuration data. The method according to any one of claims 21 to 32, characterized in that, The method further includes: Receive an idle status request message from the input processing module corresponding to the target HID. The idle status request message is used to request the current input idle status from the target HID. The idle status request message includes the identifier of the target HID and the session identifier. Send the idle status request message to the destination device; 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. The method according to any one of claims 21 to 33, characterized in that, The method further includes: Receive an idle state setting request message from the input processing module corresponding to the target HID. The idle state setting request message is used to set the time during which the target HID remains silent before receiving a user input event. The idle state setting request message includes the identifier of the target HID, the session identifier, and the time. Send the set idle state request message to the destination device. The method according to any one of claims 21 to 34, characterized in that, The method further includes: Receive a protocol request message from the input processing module corresponding to the target HID. The 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. Send the Acquire Protocol Request message to the destination device; 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. The method according to any one of claims 21 to 35, characterized in that, The method further includes: 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 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 needs to use. Send the configuration protocol request message to the destination device. The method according to claim 36, characterized in that, The HID transmission protocol is either a root protocol or a reporting protocol. The method according to any one of claims 20 to 37, characterized in that, The device information of the target HID includes the device supplier code, product code, or version number of the code, device name, physical address, and serial number of the target HID. An electronic device, characterized in that, The electronic device is used to implement the method as described in any one of claims 1 to 19, and / or to implement the method as described in any one of claims 20 to 38. A computer device, characterized in that, include: A processor configured to be coupled to memory, read and execute instructions and / or program code in the memory to perform the method as claimed in any one of claims 1 to 19, and / or to perform the method as claimed in any one of claims 20 to 38. A chip system, characterized in that, include: A logic circuit for coupling with an input / output interface, through which data is transmitted to perform the method as claimed in any one of claims 1 to 19, and / or to perform the method as claimed in any one of claims 20 to 38. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program code that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1 to 19, and / or to perform the method as described in any one of claims 20 to 38.

Images