Cross-platform input device access method, device and computer readable storage medium

Abstract

The application discloses a cross-platform input device access method, device and computer readable storage medium, and the method comprises the following steps: determining the platform type of a target host connected with a receiver; establishing a first data channel based on the platform type and determining a signal conversion strategy; determining the device type of an input device to be accessed connected with the receiver; establishing a second data channel based on the device type; receiving an operation signal of the input device to be accessed through the second data channel; and encapsulating the operation semantics into a target control signal based on the signal conversion strategy and sending the target control signal to the target host through the first data channel. The application realizes the universal access of cross-platform input devices.

Description

Technical Field

[0001] This invention relates to the field of human-computer interaction technology, and in particular to a cross-platform input device access method, device, and computer-readable storage medium. Background Technology

[0002] With the diversification of the game console market, different manufacturers have adopted their own proprietary input device protocols and communication standards for their game console platforms, forming a closed hardware ecosystem.

[0003] In real-world scenarios, users may possess multiple input devices (such as gamepads) from different platforms and wish to use these devices on target host platforms that are not natively compatible with them. However, existing technologies, when faced with such cross-platform access requirements, often only achieve single-type signal adaptation between homogeneous devices or through limited manual configuration. This conventional signal adaptation method essentially relies on the predictability of the signal format between the source and target devices. When the source input device comes from a non-preset third-party platform, its output signal format is heterogeneous data that is unrecognizable to the target host. Conventional adaptation mechanisms cannot convert this into control commands that the target host can respond to correctly without compromising the integrity of the operational information, resulting in severely limited compatibility and universality of cross-platform access.

[0004] Therefore, how to establish a universal access mechanism that is compatible with heterogeneous input devices on different platforms has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a cross-platform input device access method, aiming to solve the problem that existing technologies cannot achieve universal access when facing heterogeneous platform input devices due to incompatible signal formats.

[0006] To achieve the above objectives, embodiments of this application provide a cross-platform input device access method, including:

[0007] Determine the platform type of the target host connected to the receiver;

[0008] Based on the platform type, the system calls the first device identity description data corresponding to the platform type to establish a first data channel between the receiver and the target host, and determines the signal conversion strategy of the receiver.

[0009] Determine the device type of the input device to be connected to the receiver;

[0010] Based on the device type, the second device identity description data corresponding to the device type is invoked to establish a second data channel between the receiver and the input device to be accessed.

[0011] The second data channel is used to receive operation signals from the input device to be connected.

[0012] Based on the signal conversion strategy, operational semantics are extracted from the operational signals, and the operational semantics are encapsulated into target control signals compatible with the platform type of the target host;

[0013] The target control signal is sent to the target host through the first data channel.

[0014] In one embodiment, determining the platform type of the target host connected to the receiver includes:

[0015] Based on the polling data from the target host captured by the receiver, the platform feature identifier is extracted;

[0016] The platform feature identifier is compared with the platform feature database preset by the receiver to obtain the platform type of the target host;

[0017] and / or

[0018] Determining the device type of the input device to be connected to the receiver includes:

[0019] Based on the access request data from the input device to be accessed captured by the receiver, the device identification feature of the input device to be accessed is extracted;

[0020] The device identification feature is compared with the device feature database preset by the receiver to obtain the device type of the input device to be accessed.

[0021] In one embodiment, based on the platform type, invoking first device identity description data corresponding to the platform type to establish a first data channel between the receiver and the target host includes:

[0022] Capture the initial polling data packet sent by the target host, and extract the device enumeration feature from the initial polling data packet;

[0023] Based on the device enumeration features, the corresponding native handshake protocol data is matched from the feature library built into the receiver and used as the first device identity description data;

[0024] Based on the first device identity description data, a disguised response message carrying native peripheral protocol characteristics is sent back to the target host to establish the first data channel.

[0025] In one embodiment, based on the device type, second device identity description data corresponding to the device type is invoked to establish a second data channel between the receiver and the input device to be accessed, including:

[0026] Based on the device type, the corresponding native host protocol data is matched from the feature library built into the receiver and used as the second device identity description data;

[0027] Based on the second device identity description data, a disguised authentication data packet carrying native host protocol characteristics is sent to the input device to be accessed;

[0028] Based on the authentication confirmation information fed back by the input device to be accessed, the communication link is configured to establish the second data channel.

[0029] In one embodiment, based on the signal conversion strategy, operational semantics are extracted from the operational signal, and the operational semantics are encapsulated into a target key-value signal compatible with the platform type of the target host, including:

[0030] Based on the operation signal, discrete trigger event identification and continuous physical quantity calculation are performed to obtain operation semantics that include operation type and operation magnitude.

[0031] The control mapping relationship in the signal conversion strategy is invoked to map the operation type contained in the operation semantics to the target opcode;

[0032] Based on the message specification corresponding to the platform type of the target host, data frame encapsulation is performed on the target opcode and the operation range to obtain the target control signal.

[0033] In one embodiment, before invoking the key-value mapping relationship in the signal conversion strategy, the access method further includes:

[0034] Receive custom configuration data packets sent by the configuration terminal based on the configuration interface;

[0035] The custom configuration data packet is parsed and validated to obtain the update mapping rules;

[0036] The update operation is performed on the control mapping relationship pre-stored in the receiver based on the update mapping rule.

[0037] In one embodiment, when at least two of the input devices to be accessed are connected to the same receiver, the access method further includes:

[0038] Based on the built-in virtual traffic splitting architecture, corresponding logical interfaces are registered for each of the input devices to be accessed in the first data channel;

[0039] Based on the access requests initiated by each of the input devices to be accessed, multiple second data channels corresponding one-to-one with each of the input devices to be accessed are established.

[0040] Based on the signal conversion strategy, concurrent mapping conversion is performed on the operation signals received by each of the second data channels to obtain multiple target control signals;

[0041] Based on each of the aforementioned logical interfaces, the multiple target control signals are respectively sent to the target host via the first data channel.

[0042] In one embodiment, the access method further includes:

[0043] Obtain the raw feedback data, including frame data and / or multi-channel audio data, output by the target host in running state;

[0044] The raw feedback data is parsed, and the spatial orientation information and feedback intensity information of the target game event are extracted.

[0045] A preset feedback mapping table is invoked to map the spatial orientation information and the feedback intensity information into a driving command for the target vibration unit. The target vibration unit belongs to a feedback device connected to the receiver, and the feedback device includes the input device to be connected.

[0046] The driving command is sent to the feedback device to drive the target vibration unit to perform vibration feedback in the corresponding spatial orientation.

[0047] The present invention also proposes a cross-platform input device access device, including a memory, a processor, and a cross-platform input device access program stored in the memory and executable on the processor. When the processor executes the cross-platform input device access program, it implements the cross-platform input device access method as described in any of the preceding claims.

[0048] The present invention also proposes a computer-readable storage medium storing a cross-platform input device access program, which, when executed by a processor, implements the cross-platform input device access method as described in any of the preceding claims.

[0049] The access method of this application establishes a first data channel and a second data channel between the receiver and the target host, and between the receiver and the input device to be accessed (such as the handle or steering wheel to be accessed). Compared with the traditional technical solution where the receiver can only perform device pairing with a single inherent identity, this application completes the native device identity registration of the receiver on the target host side and the native host identity registration on the input device to be accessed during the communication link establishment stage. This allows the original operation data of the input device to be accessed to be completely captured by the receiver in its native communication format, and the converted target control signal can also be received and processed by the target host in the standard reporting format of the target host's native input device, thereby eliminating the protocol barriers between heterogeneous platform devices at the physical level.

[0050] Simultaneously, a signal conversion strategy is employed to perform discrete trigger event identification and continuous physical quantity calculation on the operation signals received via the second data channel. This extracts operation semantics independent of specific platform protocols. Then, through a control mapping relationship, the operation type within this semantics is mapped to the target opcode of the target host, and encapsulated into a target control signal according to the message specifications corresponding to the target host platform. This enables operation inputs from heterogeneous input devices on different platforms with different control coding systems and message formats to be converted into standard control signals that the target host can correctly parse and respond to, achieving universal access for cross-platform input devices. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0052] Figure 1 This is a module structure diagram of an embodiment of the cross-platform input device access device of the present invention;

[0053] Figure 2 This is a flowchart illustrating an embodiment of the cross-platform input device access method of the present invention.

[0054] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0055] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0056] It should be noted that when ordinal numbers such as "first" and "second" are mentioned in the embodiments of this application, they are only used to distinguish different objects and do not indicate a specific order or degree of importance, unless the context clearly specifies otherwise. Furthermore, the "connection" or "coupling" described in the embodiments of this application includes not only direct physical connections but also indirect connections or electrical / communication connections via an intermediate medium.

[0057] like Figure 1 As shown, Figure 1 This is a schematic diagram of the structure of the cross-platform input device access device 1 of the hardware operating environment involved in the embodiment of the present invention.

[0058] The cross-platform input device access device 1 (hereinafter referred to as "the device") in this application embodiment can be physically manifested as, but is not limited to, a server (including cloud servers, server clusters, edge computing nodes), a high-performance workstation, a personal computer (PC), a mobile terminal, an IoT gateway, or a dedicated embedded processing device. The device is configured to execute the cross-platform input device access method provided in this application embodiment.

[0059] like Figure 1 As shown, the device may include a memory 11, a processor 12, a communication interface 13, and a system bus 14.

[0060] The memory 11 is used to store computer programs (or instructions) and data required for the operation of the device.

[0061] The memory 11 includes at least one type of readable storage medium. The readable storage medium includes non-volatile memory (NVM), such as solid-state drive (SSD), hard disk drive (HDD), flash memory, optical disk, or other magnetic / optical storage media; the readable storage medium may also include volatile memory, such as random access memory (RAM) or cache.

[0062] More importantly, the memory 11 stores the operating system, the database, and the cross-platform input device access program 10 involved in this application.

[0063] Processor 12 is the core of the device's operation and control center.

[0064] Specifically, processor 12 may be one or more central processing units (CPUs), microprocessors (MCUs), digital signal processors (DSPs), or field-programmable gate arrays (FPGAs). In embodiments involving artificial intelligence, big data processing, or image rendering, processor 12 may also include an artificial intelligence acceleration chip (such as an NPU, TPU) or a graphics processing unit (GPU) for performing parallel vector or tensor operations.

[0065] The processor 12 uses the system bus 14 to read the cross-platform input device access program 10 in the memory 11, and implements each step of the cross-platform input device access method provided in this application embodiment by parsing and executing the program instructions.

[0066] Communication interface 13 (or network interface) is used to enable communication and interaction between the device and other electronic devices (such as clients, third-party servers, and sensor nodes).

[0067] Specifically, the communication interface 13 may optionally include a wired interface (such as an Ethernet interface, fiber optic interface, or USB interface) or a wireless interface (such as a Wi-Fi module, cellular mobile communication module, Bluetooth module, or NFC module). This interface supports various standard communication protocols, including but not limited to TCP / IP, HTTP / HTTPS, UDP, MQTT, and RPC.

[0068] System bus 14 can be a Peripheral Component Interconnect Standard (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus is used to transfer instruction and data streams between processor 12, memory 11 and communication interface 13.

[0069] Optionally, the device 1 may also include a user interface (not shown) for human-computer interaction. The user interface may include a display unit (such as an LCD screen, OLED screen, or touch screen) and an input unit (such as a keyboard, mouse, or microphone).

[0070] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a physical limitation on the cross-platform input device access device 1. Depending on the specific application scenario, the device may include fewer or more components than shown, or combine certain components, or use different component arrangements.

[0071] exist Figure 1 In the operating environment shown, processor 12 calls the cross-platform input device access program 10 stored in memory 11 and is configured to perform the following operations:

[0072] Determine the platform type of the target host connected to the receiver;

[0073] Based on the platform type, the system calls the first device identity description data corresponding to the platform type to establish a first data channel between the receiver and the target host, and determines the signal conversion strategy of the receiver.

[0074] Determine the device type of the input device to be connected to the receiver;

[0075] Based on the device type, the second device identity description data corresponding to the device type is invoked to establish a second data channel between the receiver and the input device to be accessed.

[0076] The second data channel is used to receive operation signals from the input device to be connected.

[0077] Based on the signal conversion strategy, operational semantics are extracted from the operational signals, and the operational semantics are encapsulated into target control signals compatible with the platform type of the target host;

[0078] The target control signal is sent to the target host through the first data channel.

[0079] Furthermore, the processor 12 may also be configured to perform refined steps of the cross-platform input device access method in any of the following embodiments.

[0080] Based on the hardware architecture of the aforementioned cross-platform input device access device, embodiments of the cross-platform input device access method of the present invention are proposed. The cross-platform input device access method of the present invention aims to solve the problem that existing technologies cannot achieve universal access when facing heterogeneous platform input devices due to incompatible signal formats.

[0081] Reference Figure 2 , Figure 2 This is an embodiment of the cross-platform input device access method of the present invention, which includes the following steps:

[0082] S10. Determine the platform type of the target host connected to the receiver.

[0083] Specifically, this step aims to establish an initial identification mechanism for the communication link between the receiver and the target host, obtain the platform identity identifier of the target host, and provide an index basis for the subsequent dynamic invocation of the first device identity description data and signal conversion strategy corresponding to the platform.

[0084] Specifically, the receiver can establish a connection with the target host through a physical interface provided by the target host. This physical interface includes at least one of a serial bus interface, a video graphics array interface, a peripheral component interconnect interface, or a custom communication interface. Alternatively, the receiver can also establish a connection with the target host through a wireless communication module.

[0085] In some embodiments, step S10 can be implemented by the following steps S11-S12.

[0086] S11. Based on the polling data from the target host captured by the receiver, extract the platform feature identifier code.

[0087] Specifically, after the receiver establishes an electrical connection with the target host's physical interface, the target host's bus controller periodically initiates device polling on the bus. The receiver's signal processing module captures the initial polling data packets sent by the target host through this physical interface.

[0088] The processing module performs protocol deframing on the initial polling data packet, stripping its bus protocol layer header and extracting the payload field. This payload field carries a platform feature identifier that uniquely corresponds to the platform type of the target host. This platform feature identifier is a set of binary feature sequences broadcast by the target host to the devices to be connected during the device enumeration phase; this feature sequence has a one-to-one mapping relationship with the host vendor and communication protocol version. The processing module extracts a fixed-byte length of the platform feature identifier from the payload at a predetermined offset address by performing bitmasking operations and field offset addressing.

[0089] S12. Compare the platform feature identifier with the platform feature database preset by the receiver to obtain the platform type of the target host.

[0090] Specifically, the receiver's internal storage unit contains a pre-built platform feature library. This platform feature library is a data table structure, in which each record contains a preset platform feature identifier template field and a corresponding platform type enumeration field.

[0091] The processor performs a pattern matching operation on the platform feature identifier code extracted in step S11, comparing it one by one with the identifier code template field of each record in the platform feature library. Specifically, this operation involves performing an XOR comparison byte-by-byte and accumulating the Hamming distance of mismatched bits. When a record's template field has a Hamming distance of zero with the platform feature identifier code, a match is successful. The processor then reads the value of the corresponding platform type enumeration field from that record and outputs it as the platform type of the target host. This platform type represents the input device communication protocol family followed by the target host, providing an index key for subsequent steps to retrieve the uplink handshake protocol data and signal conversion strategy corresponding to that protocol family.

[0092] It is understandable that by executing the above steps S11-S12, the receiver completes the step-by-step conversion of the physical layer signal of the target host platform identity to the logical layer identifier. This process directly uses the inherent periodic polling signal on the host side as the source of information for platform identification, completing identity authentication at the initial stage of device access and avoiding link initialization delay introduced by inserting additional probe packets.

[0093] S20. Based on the platform type, call the first device identity description data corresponding to the platform type to establish a first data channel between the receiver and the target host, and determine the signal conversion strategy of the receiver.

[0094] Specifically, this step aims to use the platform type determined in step S10 as an index to retrieve the identity spoofing credentials and signal conversion rule set that match the platform type from the receiver's local resource library, complete the device identity registration of the receiver on the target host side, and establish the uplink conversion logic required for subsequent signal processing.

[0095] In some embodiments, step S20 can be implemented by the following steps S21-S23:

[0096] S21. Capture the initial polling data packet sent by the target host, and extract the device enumeration feature from the initial polling data packet.

[0097] Specifically, after the physical layer link between the receiver and the target host is established, the bus controller of the target host enters the device enumeration phase and periodically sends device descriptor requests to the devices it is connected to. The receiver's signal processing module continuously monitors bus transmission events on the physical interface. When it detects a data frame start flag on the bus, it triggers a data capture process to completely read the initial polling data packet sent by the target host into the receiver's receive buffer.

[0098] The processor performs layer-by-layer deframeing on the initial polling data packet in the receive buffer. This deframeing operation includes stripping the transport layer header and link layer frame header of the bus protocol stack to extract the device enumeration request field carried at the application layer. The processor performs feature code recognition on the device enumeration request field. Specifically, by parsing the standard request code and descriptor type code in the request field, it determines the descriptor category targeted by the request and the expected response data length. The combination of the standard request code, descriptor type code, and expected response data length is output as the device enumeration feature of the initial polling data packet. This device enumeration feature characterizes the type of device capability declaration that the target host expects to obtain from the device to be accessed during the device identification phase.

[0099] S22. Based on the device enumeration features, match the corresponding native handshake protocol data from the feature library built into the receiver, and use it as the first device identity description data.

[0100] Specifically, a feature library is pre-installed in the non-volatile storage unit inside the receiver. This feature library adopts a key-value pair data structure, where the key field stores a preset device enumeration feature template, and the value field stores the native handshake protocol data block corresponding to the enumeration feature template. This native handshake protocol data block is a set of pre-collected binary data that is completely consistent with the response data sequence that the native input device of a specific platform should return when responding to the same type of device enumeration request.

[0101] The processor uses the device enumeration feature extracted in step S21 as the query key, traverses the enumeration feature template fields of each record in the feature library, and performs key-value matching. The matching process is a complete comparison performed byte by byte. When the template field of a record completely matches the device enumeration feature, the processor reads the storage address pointed to by the value field in that record, and retrieves the entire native handshake protocol data block stored at that storage address into the first device identity description data buffer in memory, as the first device identity description data. The first device identity description data contains at least one field sequence of device descriptor, configuration descriptor, interface descriptor, and endpoint descriptor in its data structure, and the byte value of each field sequence is consistent with the field value filled in the standard enumeration response by the native input device of the target host.

[0102] S23. Based on the first device identity description data, send a disguised response message carrying native peripheral protocol characteristics to the target host to establish the first data channel.

[0103] Specifically, the processor, based on the first device identity description data retrieved in step S22, performs a response message construction operation. This construction operation includes: reading the device descriptor sequence and configuration descriptor sequence from the first device identity description data, using this sequence as the payload field of the response message; using the device address specified in the target host's device enumeration request as the target address field of the response message; and filling the header control field of the response message with the response type code. The above fields are assembled according to the bus protocol specifications followed by the target host to generate a fake response message that is completely identical in field format, byte order, and data length to the standard enumeration response message of the target host's native input device.

[0104] The processor writes the spoofed response message into the transmit buffer, triggering the transmit control unit of the physical interface to execute data transmission. The transmit control unit outputs the spoofed response message bit-by-bit in differential signal form to the transmission line of the physical interface, according to the target host's bus clock timing.

[0105] Upon receiving the spoofed response message, the target host's bus controller parses the message, retrieving the device descriptor and interface descriptor that match the native input device. Based on this, the receiver is identified as a legitimate connected device with standard input capabilities, and a device address is assigned to it. This device address serves as the unique addressing identifier for the receiver in subsequent data communication between the receiver and the target host. At this point, the first data channel between the receiver and the target host is established.

[0106] It is understandable that by executing the above steps S21-S23, the receiver utilizes the standard descriptor request that the target host will inevitably issue during the device enumeration phase as the operation opportunity, and feeds back the preset native handshake protocol data to the target host in a timing and format that conforms to the target host bus protocol. Thus, at the physical layer, the receiver completely reproduces the device identity of the target host's native input device. This process incorporates the identity spoofing technique into the standard timing of device enumeration. After completing the standard enumeration process, the target host has already included the receiver as a native input device in its device management list. Any key-value signals subsequently transmitted through this first data channel will be treated by the target host as standard input data of this native input device and processed without any protocol-level adaptation or modification on the target host side.

[0107] S30. Determine the device type of the input device to be connected to the receiver.

[0108] This step establishes an initial identification mechanism for the communication link between the receiver and the input device to be accessed, and obtains the identity identifier of the native host platform to which the input device belongs, providing an index for subsequent dynamic retrieval of the second device identity description data corresponding to the device type. It should be understood that the "input device to be accessed" mentioned in this embodiment includes, but is not limited to, game controllers, e-sports keyboards, steering wheel controllers, flight joysticks, or various external devices with physical control forms. To facilitate a clear explanation of the underlying physical signaling flow and parsing mechanism, the following specific embodiments use "game controller to be accessed" as the input device and "game controller type" as the device type for elaboration.

[0109] In some embodiments, step S30 can be implemented by the following steps S31-S32.

[0110] S31. Based on the access request data from the input device to be accessed captured by the receiver, extract the device identification feature of the input device to be accessed.

[0111] Specifically, taking the access-to-hand controller as an example, when the controller enters the working state and is in discoverable mode, its wireless communication module periodically broadcasts access request data packets on a predetermined channel according to the wireless protocol specifications defined by its native host platform, or unicasts access request data packets in response to a device discovery scan issued by the receiver. The receiver's wireless radio frequency module continuously monitors the signal energy distribution on the predetermined channel. When it detects a radio frequency signal that conforms to a preset carrier frequency and modulation method on the predetermined channel, it performs down-conversion and analog-to-digital conversion on the radio frequency signal, converting the radio frequency analog signal into a digital baseband signal sequence. The processing module performs physical layer synchronization header detection on the digital baseband signal sequence. After confirming that the synchronization header matches, it demodulates and decodes the digital baseband signal sequence to obtain the digital bit stream of the access request data packet, and stores it in the receiver's receive buffer.

[0112] The processor performs protocol deframing on the access request data packet in the receive buffer. This deframing operation includes stripping the link layer header and network layer header of the access request data packet and extracting the device information field carried at the application layer or device identification layer. This device information field contains a unique device identifier sequence, a manufacturer identifier, and a product identifier that were permanently written into the device during the manufacturing stage. From this device information field, the processor extracts specific byte segments of the unique device identifier sequence, the manufacturer identifier, and the product identifier according to a predetermined offset address and field length. These three are then concatenated in a predetermined order to form a fixed-length device identifier feature vector, which is output as the device identifier feature of the device to be accessed (i.e., the input device to be accessed). This device identifier feature vector is a compressed feature code representing the native host platform to which the device to be accessed belongs; different native host platforms correspond to different encoding ranges for the manufacturer identifier and the product identifier.

[0113] S32. Compare the device identification features with the receiver's preset handle feature library to obtain the handle type of the handle to be connected.

[0114] Specifically, the receiver's internal non-volatile storage unit contains a pre-built device feature library (in this embodiment, specifically a handle feature library). This device feature library uses a key-value pair data structure, where the key field stores a preset device identification feature template, and the value field stores the handle type enumeration value corresponding to the template. This handle type enumeration value uniquely identifies the native host platform to which the handle belongs.

[0115] The processor uses the device identifier feature vector extracted in step S31 as a query key and inputs it into the matching engine of the handheld feature library. The matching engine performs the following operation: it performs a byte-by-byte equality match between the device identifier feature vector and the device identifier feature template of each record in the handheld feature library. When a record's template field matches all byte values ​​of the device identifier feature vector, the match is successful. The processor reads the enumerated value stored in the value field of that record and outputs it as the handheld type (i.e., the aforementioned device type) of the handheld to be connected. This handheld type represents the input device communication protocol family and key-value encoding system followed by the handheld to be connected, providing an index key for retrieving the downlink handshake protocol data and input-side parsing rules corresponding to that protocol family in subsequent steps.

[0116] It is understandable that by executing the above steps S31-S32, the receiver extracts the device identification feature containing platform attribution information from the access request data packet of the input device to be accessed (taking a gamepad as an example) during the initial communication phase. This is done by matching the feature with a pre-set gamepad feature library to convert the feature into a clear platform type index. This process directly uses the inherent connection request signal on the input device side as the source of platform identification, without requiring the receiver to send any additional probe or interrogation commands to the input device, thus avoiding the wireless connection establishment delay introduced by additional signaling interaction. At the same time, the mechanism of using the encoding range of the manufacturer's identification code and product identification code as the identification basis ensures that even if the input device to be accessed is not a known model preset by the receiver, as long as its encoding range belongs to a known platform, it can still be accurately classified as a gamepad type of that platform. This alleviates the problem of access rejection due to unregistered device models in traditional technical solutions and ensures the compatibility of the identification mechanism with unknown new models of input devices on the same platform (such as newly released gamepads or steering wheels in the future).

[0117] S40. Based on the controller device type, call the second device identity description data corresponding to the controller device type to establish a second data channel between the receiver and the controller to be connected to the input device.

[0118] Specifically, this step uses the device type determined in step S30 as an index to retrieve the downlink identity spoofing credential matching the device type from the receiver's local resource library. It then proactively initiates a connection establishment process with the input device to be accessed, acting as the native host to which the input device belongs, thus completing the receiver's host identity registration on the input device side. It should be understood that, to detail the underlying physical interaction process of establishing this downlink channel, the following specific embodiments will continue to describe the input device to be accessed as a "handle to be accessed" and the device type as a "handle type."

[0119] In some embodiments, step S40 can be implemented by the following steps S41-S43.

[0120] S41. Based on the device type, match the corresponding native host protocol data from the feature library built into the receiver as the second device identity description data.

[0121] Specifically, taking the input device to be connected as a handle as an example, the pre-built feature library (specifically, a handle feature library in this embodiment) in the non-volatile storage unit inside the receiver stores not only the upstream native handshake protocol data, but also the downstream native host protocol dataset. This native host protocol dataset also uses a key-value pair data structure, where the key field stores the handle type enumeration value, and the value field stores the native host protocol data block corresponding to that handle type. This native host protocol data block is a set of pre-collected protocol parameters that are completely consistent with the host-side protocol behavior exhibited by the native host to which the handle belongs when making external connections.

[0122] The processor uses the handle type enumeration value output in step S30 as the query key, traverses the key fields of each record in the downlink protocol data area of ​​the feature library, and performs key-value matching. When a record's key field completely matches the handle type enumeration value, the processor reads the storage address pointed to by the value field in that record, and retrieves the entire native host protocol data block stored at that address into the second device identity description data buffer in memory, as the second device identity description data. The second device identity description data contains at least one field sequence from the host device category identifier, host Bluetooth address format template, link manager protocol version parameters, and service discovery protocol record. The values ​​of each field in this field sequence are consistent with the host-side protocol field values ​​filled in by the native host to which the handle to be accessed belongs during the standard wireless connection establishment phase.

[0123] S42. Based on the second device identity description data, send a disguised authentication data packet carrying native host protocol characteristics to the input device to be accessed.

[0124] Specifically, taking the aforementioned handset to be accessed as an example, the processor performs a disguised authentication data packet construction operation based on the second device identity description data retrieved in step S41. This construction operation includes: reading the host device category identifier and host Bluetooth address format template from the second device identity description data; generating a disguised host address that conforms to the native host address encoding rules based on the Bluetooth address format template; and filling the disguised host address into the source address field of the authentication data packet; reading the link manager protocol version parameter from the second device identity description data and filling it into the protocol version negotiation field of the authentication data packet; and reading the service discovery protocol record from the second device identity description data, serializing it, and filling it into the service description payload field of the authentication data packet. The above fields are assembled according to the wireless protocol specifications followed by the handset to generate a disguised authentication data packet that is completely consistent with the standard authentication data packet of the native host to which the handset belongs in terms of field format, byte order, and protocol version.

[0125] The processor writes the spoofed authentication data packet into the wireless transmission buffer, triggering the transmission control unit of the wireless radio frequency module to execute data transmission. The transmission control unit radiates the spoofed authentication data packet into the wireless channel in the form of a radio frequency signal conforming to a preset modulation scheme and transmission power, according to the link layer timing of the wireless protocol followed by the handset to be accessed.

[0126] S43. Configure the communication link according to the authentication confirmation information fed back by the input device to be accessed, and establish the second data channel.

[0127] Specifically, continuing with the example of the handset to be accessed, the receiver's radio frequency module captures the authentication confirmation information fed back by the handset. After down-conversion, analog-to-digital conversion, and demodulation decoding, the digital bit stream of the authentication confirmation information is stored in the receiving buffer. The processor parses the authentication confirmation information and extracts the link layer connection parameters contained therein. These connection parameters include at least one of the following: connection interval, channel frequency hopping sequence, and encryption mode configuration.

[0128] Based on the connection parameters, the processor performs link configuration operations on the receiver's wireless RF module. This configuration includes: writing the connection interval to the period register of the link layer timer to set the data transmission and reception time slot interval between the receiver and the handset to be accessed; writing the channel frequency hopping sequence to the sequence register of the frequency hopping controller to set the channel switching order used for subsequent data communication; and writing the encryption mode configuration to the mode register of the encryption engine to set the encryption algorithm and key length for the link layer data frames. After the above configuration is completed, the processor triggers the wireless RF module to enter the connection state according to the connection parameters and perform data transmission and reception with the handset to be accessed within the predetermined connection time slot. At this point, the second data channel between the receiver and the handset to be accessed (i.e., the input device to be accessed) is established.

[0129] It is understandable that by executing steps S41-S43 above, the receiver uses the device type (such as the handle type) output in step S30 as an index to retrieve the native host protocol data corresponding to that device type from the feature library, and constructs a fake authentication data packet that is completely consistent with the standard protocol behavior of the native host to which the input device to be accessed belongs at the protocol field level. After receiving the fake authentication data packet, the input device to be accessed completes the authentication negotiation and link configuration with the receiver according to its inherent standard connection establishment process. This process maps the downlink identity emulation technical operators into the frame interaction specification of the underlying wireless communication, alleviating the problem in traditional technical solutions where peripherals refuse to establish connections because they do not detect the native host, thereby improving the system compatibility and wireless link stability of heterogeneous input devices accessing the system.

[0130] S50. Receive an operation signal from the input device to be connected through the second data channel.

[0131] Specifically, this step utilizes the second data channel established in step S40 as a data receiving path to capture the raw operation data generated by the input device to be accessed under user operation, providing an input data source for signal conversion in the subsequent step S60. It should be understood that, to detail the underlying physical interaction process of data capture and deframe, the following specific embodiments will continue to elaborate on the input device to be accessed as a "handle to be accessed" and the operation signal as a "handle input signal".

[0132] Specifically, when a user operates the controller to be connected, the microcontroller built into the controller encapsulates the button status bitmap and analog axis displacement into a raw operation data frame according to the communication protocol specifications of its native host platform, and sends the raw operation data frame to the wireless channel through the wireless radio frequency module within the connection time slot specified by the second data channel.

[0133] Within the corresponding connection time slot, the receiver's radio frequency module, according to the channel frequency hopping sequence and encryption mode configuration negotiated in step S43, performs reception acquisition, down-conversion, and demodulation decoding on the radio frequency signal on the wireless channel to obtain the digital bit stream of the original operation data frame. The processing module performs a protocol deframe operation on the digital bit stream, which strips its link layer frame header and extracts the connection handle field to confirm that the frame comes from the handle to be accessed (i.e., the input device to be accessed) associated with the second data channel. Subsequently, the processor performs cyclic redundancy check on the payload field. If the check passes, it reads the operation code field, button status bitmap field, and analog axis displacement field from the payload field, outputs the combination of the above fields as the handle input signal, and stores it in the receiver's input signal buffer for subsequent step S60 to call.

[0134] It is understandable that by executing the above-described receiving steps based on underlying time slot synchronization and RF deframes, the receiver continuously captures and extracts the raw operational data transmitted by the input device to be accessed (such as the handset to be accessed) in the established second data channel. This process demodulates the encapsulated RF signals transmitted by heterogeneous peripherals into standard digital payloads readable by the central processing module, alleviating the data packet loss and bit error problems caused by mismatched underlying communication parameters in traditional technical solutions, thereby ensuring the data integrity and real-time performance of upper-layer operational semantic extraction and cross-platform signal conversion logic.

[0135] S60. Based on the signal conversion strategy, extract the operation semantics from the operation signal and encapsulate the operation semantics into a target control signal compatible with the platform type of the target host.

[0136] Specifically, this step aims to deconstruct and reconstruct the operation signal received in step S50 at the protocol level. It extracts the operation semantics corresponding to the physical operation from the native protocol format of the input device to be connected, and then repackages the operation semantics into a target control signal that the target host can correctly parse, according to the control coding system and message format specifications defined by the target host platform. It should be understood that, to detail the underlying physical process of instruction deconstruction and mapping, the following specific embodiments will continue to use the input device to be connected as a "handle to be connected" and the operation signal as a "handle input signal" for further explanation.

[0137] In some embodiments, step S60 can be implemented by the following steps S61-S63.

[0138] S61. Based on the operation signal, perform discrete trigger event identification and continuous physical quantity calculation to obtain operation semantics including operation type and operation amplitude.

[0139] Specifically, taking the controller to be connected as an example, the processor retrieves the operation signal (i.e., the controller input signal) output in step S50 from the input signal buffer and performs input-side parsing on the operation signal. This input-side parsing is performed based on the input-side parsing rules in the signal conversion strategy. These input-side parsing rules define the payload field structure definition and control encoding table corresponding to the device type of the input device to be connected (i.e., the controller).

[0140] The input-side analysis includes two parts: discrete trigger events (such as key event recognition) and continuous physical quantity calculation (such as trajectory displacement calculation).

[0141] In the discrete trigger event section, the processor performs bit-by-bit parsing of the discrete state bitmap (such as a button state bitmap) field of the operation signal. This bit-by-bit parsing includes: reading the current frame of the discrete state bitmap, performing a bitwise XOR operation between the current frame and the previous frame of the discrete state bitmap temporarily stored in the processor to obtain a state change bitmap, where the set bits of the state change bitmap correspond to the physical trigger element (such as a button) that has undergone a state change; for each set bit of the state change bitmap, reading the level value of the corresponding bit in the current frame, if the level value is logic high, generating a press event for the corresponding physical trigger element; if the level value is logic low, generating a release event for the corresponding physical trigger element. Based on the preset control encoding table in the input-side parsing rules, the processor maps the physical element number corresponding to the press or release event to the native operation type identifier of the input device to be connected. This native operation type identifier represents the standard control function semantics of the physical element in the native host platform to which the input device to be connected belongs.

[0142] In the continuous physical quantity calculation section, the processor performs numerical calculations on the analog axis displacement field of the operation signal. This analog axis displacement field contains unsigned integer raw sample values ​​from at least one analog channel. These raw sample values ​​represent the physical offset of the analog input element (such as a steering wheel shaft, a joystick, or a touchpad) in the corresponding axis. The processor reads these raw sample values ​​and performs median calibration, subtracting the preset median value of the analog channel to obtain the signed offset. It then performs a dead-zone threshold comparison on the signed offset. If the absolute value of the signed offset is less than the preset dead-zone threshold, the signed offset is set to zero; if the absolute value is greater than or equal to the preset dead-zone threshold, the signed offset is retained. Finally, it performs range normalization on the dead-zone-processed signed offset, linearly mapping it to a preset normalized numerical range. The signed value within this normalized numerical range is the output of the continuous physical quantity calculation, representing the operating amplitude and direction of the analog input element in that axis.

[0143] The processor combines the native operation type identifier identified by the discrete trigger event with the operation amplitude value calculated from the continuous physical quantity to form the operation semantics. This operation semantics is a binary tuple in data structure, containing an operation type field and an operation amplitude field. The operation type field stores the native operation type identifier, and the operation amplitude field stores the operation amplitude value. This operation semantics strips away the native protocol encapsulation format of the input device to be connected from the operation signal, retaining only the abstract operation information that corresponds one-to-one with the specific physical operation.

[0144] S62. Invoke the control mapping relationship in the signal conversion strategy to map the operation type contained in the operation semantics to the target opcode.

[0145] Specifically, the processor reads the output-side encapsulation rules from the policy cache, as determined in step S20, which include control mapping relationships and message format templates. The control mapping relationship defines a mapping table from source platform operation types to target platform opcodes. Each record in this mapping table contains a source operation type identifier field and a target opcode field.

[0146] The processor uses the operation type field value from the operation semantics output in step S61 as the query key and performs a linear match in the source operation type identifier field of each record in the control mapping relationship. When the source operation type identifier field of a record is equal to the value of the operation type field, the processor reads the value of the corresponding target opcode field in that record and outputs it as the target opcode. The target opcode is a binary encoded value that conforms to the standard control encoding specified by the target host platform. The bus controller of the target host platform can recognize the target opcode and trigger the corresponding underlying control event, thereby realizing accurate delivery across the logical instruction space.

[0147] S63. Based on the message specification corresponding to the platform type of the target host, perform data frame encapsulation on the target opcode and the operation range to obtain the target control signal.

[0148] Specifically, the processor reads the message format template from the output-side encapsulation rules. The message format template defines the field structure, byte order, and field alignment rules of the standard input device data frame of the target host platform.

[0149] The processor performs a data frame encapsulation operation. This encapsulation operation includes: creating a data frame buffer with a preset frame header identifier; writing the target opcode to the offset address of the opcode field specified by the message format template; writing the operation amplitude value output in step S61 to the offset address of the analog data field specified by the message format template, and arranging the bytes according to the big-endian or little-endian order specified by the message format template; calculating the cyclic redundancy checksum for each field already filled in the data frame buffer, and writing the cyclic redundancy checksum to the offset address of the check field specified by the message format template. After the above fields are byte-filled according to the field alignment rules of the message format template, the target control signal is formed. The target control signal is completely consistent with the standard input data frame reported by the target host's native input device in response to user operations in terms of frame structure, field definition, and check method, establishing the leap from logical instruction characteristics to physical layer communication payload.

[0150] It can be understood that by executing the above steps S61-S63, the processor completes the data format conversion from the raw operation data of the input device to be connected (such as a heterogeneous handle or steering wheel) in its native protocol format to the standard control signal recognizable by the target host platform. In the operation semantic extraction stage, the physical operation of the input device to be connected is decoupled from its native platform's protocol encapsulation, forming an abstract operation representation independent of the source platform protocol. In the control mapping stage, the operation type in this abstract operation representation is remapped to the target platform's instruction namespace. In the data frame encapsulation stage, the mapped opcode and operation amplitude are reassembled according to the target platform's message specifications into the standard input data frame format of the target platform's native input device. This three-step conversion mechanism enables the target host, upon receiving the target control signal, for its bus controller to parse and respond to the signal according to the standard process for handling standard input device data frames. This alleviates the cross-platform operation gap problem caused by heterogeneous instruction set misalignment and improves the execution accuracy of complex input feature conversion.

[0151] S70. The target control signal is sent to the target host through the first data channel.

[0152] Specifically, the processor retrieves the target control signal generated in step S60 from the transmit buffer. The processor's transmit control unit performs the data transmission operation according to the bus protocol timing or wireless link layer timing determined when the first data channel is established. This transmission operation includes: using the target control signal as a payload, adding address and control fields according to the communication protocol specifications followed by the target host, assembling it into a transmit data frame conforming to the link layer format of the first data channel; and transmitting the transmit data frame to the target host through a physical interface or wireless radio frequency module.

[0153] After receiving the transmitted data frame, the bus controller or wireless communication module of the target host performs a link layer deframe operation to recover the target control signal and convert it into an input event that the target host operating system can recognize. This process triggers the system kernel mode to periodically refresh the status of the input command by driving the target host's underlying hardware interrupt pin.

[0154] It is understood that the access method of this application establishes a first data channel and a second data channel between the receiver and the target host, and between the receiver and the input device to be accessed (such as the handle or steering wheel to be accessed). Compared with the traditional technical solution where the receiver can only perform device pairing with a single inherent identity, this application completes the native device identity registration of the receiver on the target host side and the native host identity registration on the input device to be accessed during the communication link establishment stage. This allows the original operation data of the input device to be accessed to be completely captured by the receiver in its native communication format, and the converted target control signal can also be received and processed by the target host in the standard reporting format of the target host's native input device, thereby eliminating the protocol barriers between heterogeneous platform devices at the physical level.

[0155] Simultaneously, a signal conversion strategy is employed to perform discrete trigger event identification and continuous physical quantity calculation on the operation signals received via the second data channel. This extracts operation semantics independent of specific platform protocols. Then, through a control mapping relationship, the operation type within this semantics is mapped to the target opcode of the target host, and encapsulated into a target control signal according to the message specifications corresponding to the target host platform. This enables operation inputs from heterogeneous input devices on different platforms with different control coding systems and message formats to be converted into standard control signals that the target host can correctly parse and respond to, achieving universal access for cross-platform input devices.

[0156] In some embodiments, before invoking the control mapping relationship in the signal conversion strategy in step S62, the access method of this application further includes a custom mapping configuration update process to allow users to customize the preset control mapping relationship in the receiver. This custom mapping configuration update process includes the following steps S110-S130.

[0157] S110: Receive custom configuration data packets sent by the configuration terminal based on the configuration interface.

[0158] Specifically, the receiver is equipped with a configuration interface for establishing a configuration data link with the configuration terminal. For example, this configuration interface can be the communication module between the target host physical interface and the input device to be connected (such as a handset), or it can be a third communication interface independent of the communication module between the target host physical interface and the input device to be connected. For instance, the configuration interface could be a Universal Serial Bus (USB) device interface, and the configuration terminal could be a personal computer. After the receiver establishes a configuration data link with the configuration terminal through this configuration interface, configuration management software runs on the configuration terminal. When the user modifies the mapping relationship between a specific operation type and the target opcode on the user interface of the configuration management software and submits an update command, the configuration management software serializes the user-modified mapping entry into a custom configuration data packet and sends the custom configuration data packet to the receiver through the configuration data link.

[0159] The receiver's processor receives the custom configuration data packet through the configuration interface and stores it in the configuration data receive buffer.

[0160] S120. Parse and verify the custom configuration data packet to obtain the update mapping rules.

[0161] Specifically, the processor retrieves the custom configuration data packet from the configuration data receive buffer and performs a parsing operation on the custom configuration data packet. The parsing operation includes: reading the data packet type identifier field of the custom configuration data packet to confirm that the data packet is a mapping configuration update type; reading the configuration entry count field to determine the number of subsequent configuration entry payloads; and, according to the value of the configuration entry count field, sequentially reading the source operation type identifier, target opcode, and operation attribute flag of each configuration entry from the configuration entry payload using a preset address offset.

[0162] Then, the processor performs a verification operation on the custom configuration data packet. This verification operation includes: calculating the cyclic redundancy checksum for each field in the custom configuration data packet except for the checksum field, and performing a bitwise XOR comparison between the calculated result and the checksum field carried in the custom configuration data packet. If the verification passes (i.e., the comparison result is zero) and the value of the configuration entry count field is greater than zero, the processor summarizes all the configuration entries read from the custom configuration data packet to form an update mapping rule. This update mapping rule is structurally a list of mapping entries, with each entry containing three fields: source operation type identifier, target opcode, and operation attribute flag.

[0163] S130. Based on the update mapping rule, perform an update operation on the key-value mapping relationship pre-stored in the receiver.

[0164] Specifically, the processor writes the updated mapping rule obtained in step S120 into the control mapping relationship storage area associated with the output-side encapsulation rule in the signal conversion strategy.

[0165] In some embodiments, the update operation is an overwrite update. The processor performs a block erase operation on the control mapping relationship storage area, clearing all pre-stored mapping entries in the storage area. Subsequently, the processor writes each mapping entry in the update mapping rule into the control mapping relationship storage area one by one, and updates the mapping entry count register of the storage area.

[0166] In some alternative embodiments, the update operation is an incremental update. Each configuration entry payload in the custom configuration data package also includes an operation type flag, which includes three types of operations: add, modify, and delete. The processor performs the corresponding incremental operation on the control mapping memory area based on the operation type flag of each configuration entry.

[0167] After the above update operation is completed, when step S62 calls the control mapping relationship in the signal conversion strategy, it will perform operation type mapping based on the updated control mapping relationship storage area, so that the user-defined control mapping relationship will take effect in subsequent cross-platform input signal conversion.

[0168] It is understood that by executing steps S110 to S130 above, this application, based on the control mapping relationship, realizes user-defined updates to the control mapping relationship through an independent configuration interface and a structured custom configuration data package. Furthermore, this update operation is completed before the processor executes step S62, which maps the operation type. The updated mapping table can be immediately invoked after each subsequent receipt of an operation signal (such as a controller or steering wheel operation signal) and extraction of the operation semantics. This allows mapping changes submitted by the user in the configuration management software to take effect instantly during seamless switching of current game controls, improving the flexibility and real-time conversion accuracy of cross-domain control flow mapping.

[0169] In some embodiments, when at least two input devices are connected to the same receiver, the receiver enables a built-in virtual splitter architecture to support concurrent access and processing of multiple operating signals. This concurrent access and processing includes the following steps S210-S240.

[0170] S210. Based on the built-in virtual splitting architecture, register corresponding logical interfaces for each of the input devices to be accessed in the first data channel.

[0171] Specifically, the virtual offloading architecture is a logical device abstraction mechanism within the receiver. This mechanism maps the single physical device address obtained by the receiver in the first data channel to multiple independent logical interface instances at the logical layer. Each logical interface instance has a unique logical interface identifier and corresponds to an independent input reporting endpoint.

[0172] Specifically, taking the input device to be accessed as a handle as an example, after the processor detects that the first handle to be accessed has completed the establishment of the second data channel in step S40, it triggers the initialization process of the virtual traffic splitting architecture. This initialization process includes: the processor sending a device configuration update notification to the target host, in which it declares that the receiver supports multiple logical input device instances; subsequently, the processor registers a logical interface instance for the first handle to be accessed in the bus device descriptor table inside the receiver, assigns a logical interface identifier, and establishes an internal routing mapping between the logical interface instance and the second data channel established in step S40.

[0173] When a second access request is detected from a second access handle, the processor registers a new logical interface instance for the second access handle in the bus device descriptor table, assigns a new logical interface identifier to the new logical interface instance, and reserves an internal routing mapping entry between the new logical interface instance and the second data channel to be established for the second access handle. This internal routing mapping entry defines the data forwarding path from the second data channel receive buffer to the output report endpoint of the logical interface instance.

[0174] S220. Based on the access requests initiated by each of the input devices to be accessed, establish a plurality of second data channels corresponding one-to-one with each of the input devices to be accessed.

[0175] For each input device to be connected, the receiver establishes multiple corresponding second data channels according to the process described in step S40.

[0176] Specifically, taking the controller to be connected as an example, for the first controller to be connected, the processor retrieves the second device identity description data corresponding to the controller type (i.e. the device type mentioned above) of the first controller to be connected according to the process of step S40, sends a disguised authentication data packet carrying the native host protocol characteristics to the first controller to be connected, and performs communication link configuration according to the authentication confirmation information fed back by the first controller to be connected, and establishes a second data channel with the first controller to be connected.

[0177] For the second and subsequent handsets to be connected, the processor executes the platform type determination process described in step S30 to obtain the handset type of each handset to be connected. Then, following the process in step S40, it retrieves the second device identity description data corresponding to each handset type, sends a fake authentication data packet to each handset to be connected, and performs communication link configuration based on the authentication confirmation information fed back by each handset to be connected, establishing multiple second data channels corresponding one-to-one with each handset to be connected. Each second data channel has an independent connection handle, ensuring that subsequent data communication between the handsets to be connected is isolated from each other in terms of time slot resources and channel frequency.

[0178] S230. Based on the signal conversion strategy, perform concurrent mapping conversion on the operation signals received by each of the second data channels to obtain multiple target control signals.

[0179] Specifically, when multiple input devices (such as gamepads) generate input data simultaneously under user operation, each input device sends an operation signal (such as a gamepad input signal) within the connection time slot of its corresponding second data channel.

[0180] The receiver's radio frequency module uses time-division multiplexing to receive radio frequency signals transmitted by the corresponding input devices within the connection time slots of each second data channel. After down-conversion, demodulation, decoding, and protocol deframing, multiple operation signals corresponding to each input device are obtained. The processor extracts the connection handle field from the link layer frame header of each operation signal. Based on this connection handle field, each handle operation signal is stored in the input signal sub-buffer corresponding to each connection handle, thus achieving channel-level separation of multiple input signals.

[0181] Then, the processor performs the operation semantic extraction and control signal encapsulation operations described in step S60 on each of the aforementioned operation signals. In the operation semantic extraction stage, the processor, based on the device type of the input device to which each operation signal belongs, calls the corresponding input-side parsing rules to perform independent discrete trigger event identification and continuous physical quantity calculation on each operation signal, obtaining each independent first operation semantic. In the control mapping and encapsulation stage, the processor calls the control mapping relationship in the signal conversion strategy to map the operation type in each first operation semantic to the target operation code, and encapsulates it into multiple target control signals according to the message specification corresponding to the target host platform.

[0182] S240. Based on each of the aforementioned logic interfaces, the multiple target control signals are respectively sent to the target host via the first data channel.

[0183] Specifically, for each target control signal, the processor reads the connection handle from which the signal originates, and uses this connection handle as an index to look up the corresponding logical interface identifier in the internal routing map established in step S210. After finding the logical interface identifier, the processor writes the target control signal into the output report endpoint buffer associated with that logical interface identifier.

[0184] The processor performs polling scheduling on the output report endpoint buffers of each logical interface instance according to the input report timing of the target host bus protocol. When a target control signal to be sent exists in a certain output report endpoint buffer, the processor uses the logical interface identifier corresponding to that logical interface instance as the data source address of the input report, encapsulates the target control signal into an input report data packet conforming to the target host input report format, and sends it to the target host through the first data channel.

[0185] On the target host side, each operation input from different input devices to be connected is identified as an independent operation from different logical input devices, thereby supporting multiple users to operate their respective handles simultaneously on the target host platform.

[0186] It is understood that by executing the above steps S210 to S240, this application utilizes a virtual splitting architecture to register logical interface instances corresponding one-to-one with each input device to be accessed within the single first data channel already established between the receiver and the target host. Through an internal routing mapping mechanism and connection handle binding, a complete data forwarding path is established from each second data channel to each logical interface instance. This virtual splitting architecture enables the target host to identify the receiver on a single physical interface as multiple independent logical input devices. Each logical input device can respond to operation inputs from different input devices to be accessed, thereby achieving concurrent access and independent control of multiple cross-platform input devices without the need for an external hardware hub chip. This improves the multiplexing capability and concurrent execution efficiency of the cross-platform heterogeneous control system.

[0187] In some embodiments, when the target host is in a game running state, the access method of this application further includes a multi-dimensional vibration feedback process based on the game's underlying data, to convert the game state information output by the target host into haptic drive commands for the feedback device. This multi-dimensional vibration feedback process includes the following steps S310-S340.

[0188] S310. Obtain the raw feedback data, including screen frame data and / or multi-channel audio data, output by the target host in the running state.

[0189] Specifically, the receiver continuously monitors the feedback data stream output by the target host during runtime via the first data channel. This feedback data stream is real-time data pushed by the game engine to the output device interface during the execution of the game program by the target host, representing specific events in the current game scene.

[0190] In some embodiments, the raw feedback data includes frame data. This frame data is a bitmap data stream, either encoded or unencoded, of the frame buffer data output by the target host graphics processing unit. The receiver's processor acquires the frame data via an isochronous transfer endpoint or a bulk transfer endpoint in the first data channel and stores it in the frame buffer. Each pixel position in the frame data carries a three-channel or four-channel color value in the color space, and the value range of each channel is consistent with the bit depth of the target host's graphics output.

[0191] In other embodiments, the raw feedback data includes multi-channel audio data. This multi-channel audio data is a series of independent channel signals output by the target host audio processing unit and encapsulated according to a specific multi-channel audio encoding format. For example, the multi-channel audio encoding format is a 5.1-channel or 7.1-channel format, with each channel signal corresponding to a different spatial speaker location. The receiver's processor acquires the multi-channel audio data through the audio transmission endpoint in the first data channel and stores it in an audio data buffer.

[0192] S320. The original feedback data is parsed, and the spatial orientation information and feedback intensity information of the target game event are extracted.

[0193] Specifically, the processor performs a parsing operation on the raw feedback data acquired in step S310 to extract spatial orientation information and feedback intensity information associated with the target game event. This parsing operation executes a screen parsing path, an audio parsing path, or a combination of both, depending on the type of the raw feedback data.

[0194] When the raw feedback data contains frame data, the processor performs specific color threshold matching on the edge pixel regions of the frame data. Specifically, the processor extracts rectangular pixel subsets from the top, bottom, left, and right edge regions of the frame data. After performing color space conversion on the pixels within each edge region, it matches their hue, saturation, and brightness component values ​​with a preset target threshold range. Pixels falling within the threshold range are marked as target feature pixels, resulting in a target feature pixel set. Based on the quadrant distribution of this target feature pixel set in the image coordinate system, the processor counts the number of target feature pixels in each spatial quadrant, maps the spatial orientation corresponding to the quadrant with the largest number of pixels to a first spatial orientation scalar, and determines its confidence level based on the pixel proportion of that quadrant. Simultaneously, the processor determines the image feedback intensity based on the ratio of the total number of target feature pixels to the preset maximum number of pixels.

[0195] When the raw feedback data contains multi-channel audio data, the processor performs channel demultiplexing on the multi-channel audio data, separating multiple independent channel signals corresponding to the positions of each spatial speaker. The processor performs time-domain analysis and amplitude analysis on each channel signal, extracting the time arrival difference component between each channel pair and the amplitude comparison component of each channel. Based on the time arrival difference component and amplitude comparison component, the processor performs sound field localization calculation to solve for the spatial orientation of the sound source, obtaining a second spatial orientation scalar. Simultaneously, the processor determines the audio feedback intensity based on the ratio of the maximum impact amplitude of each channel to a preset maximum amplitude.

[0196] When the original feedback data contains both video frame data and multi-channel audio data, the processor performs a weighted fusion of the first and second spatial orientation scalars. The orientation enumeration values ​​of the two are weighted and summed using video confidence weights and preset audio confidence weights, and the result is rounded down to obtain the fused orientation parameter. The average confidence level of the two is then used as the fused confidence parameter. The processor combines the fused orientation parameter, the fused confidence parameter, and the corresponding feedback intensity information into a feedback event data structure for use in subsequent steps.

[0197] S330. Call the preset feedback mapping table to map the spatial orientation information and the feedback intensity information into a driving command for the target vibration unit, wherein the target vibration unit belongs to the feedback device connected to the receiver, and the feedback device includes the input device to be connected.

[0198] Specifically, the processor invokes a pre-defined feedback mapping table. This feedback mapping table is pre-stored in the receiver's non-volatile memory unit. Its data structure is a two-dimensional lookup table, where the row index is the spatial orientation enumeration value, the column index is the feedback device type identifier, and the table entries contain the target vibration unit identifier and the driving waveform parameters. The target vibration unit identifier uniquely identifies a specific vibration unit installed on the feedback device, and the driving waveform parameters define the vibration intensity and vibration waveform envelope when the vibration unit is triggered.

[0199] The processor uses the orientation parameters in the spatial orientation information as row indices and the device type identifier of the currently connected feedback device as column indices to perform a lookup operation in the feedback mapping table. When the lookup operation is successful, the processor reads the target vibration unit identifier and the drive waveform parameters from the table entry. Using the intensity parameters in the feedback intensity information, the processor scales the vibration intensity value in the drive waveform parameters and writes the scaled vibration intensity value into the intensity field of the drive instruction; it also writes the target vibration unit identifier into the target address field of the drive instruction; and it writes the vibration waveform envelope identifier from the drive waveform parameters into the waveform field of the drive instruction. Thus, the processor generates a drive instruction for the target vibration unit.

[0200] Furthermore, the feedback device includes a target input device. Taking a target controller as an example, when the target vibration unit is located inside the target controller, the target vibration unit identifier points to the vibration motor built into the target controller. In addition, the feedback device may also include a wearable feedback device wirelessly connected to a receiver, such as a headband, vest, gloves, or VR glasses. The wearable feedback device has multiple vibration units distributed on it, each corresponding to a different spatial orientation, and the target vibration unit identifier points to a specific vibration unit on the wearable feedback device that corresponds to that spatial orientation information.

[0201] S340. Send the driving command to the feedback device to drive the target vibration unit to perform vibration feedback in the corresponding spatial orientation.

[0202] Specifically, when the feedback device is an input device to be connected (such as the aforementioned handle), the processor encapsulates the drive instruction into a vibration control data packet conforming to the vibration control protocol followed by the input device to be connected, and sends the vibration control data packet to the input device to be connected through the second data channel corresponding to the input device. Taking the handle to be connected as an example, after receiving the vibration control data packet, the microcontroller of the handle to be connected parses the target vibration unit identifier and the drive waveform parameters, and outputs a pulse width modulation drive signal matching the drive waveform parameters to the vibration motor corresponding to the target vibration unit identifier, driving the vibration motor to perform vibration according to the preset vibration waveform.

[0203] When the feedback device is a wearable feedback device, the processor encapsulates the drive instruction into a vibration drive data packet conforming to the communication protocol of the wearable feedback device, and sends the vibration drive data packet to the wearable feedback device through the wireless communication link established with the wearable feedback device. The controller of the wearable feedback device parses the target vibration unit identifier and drive waveform parameters, and triggers the vibration unit corresponding to the target vibration unit identifier to perform vibration.

[0204] It is understood that by executing the above steps S310 to S340, this application uses the screen frame data and / or multi-channel audio data output by the target host in the running state as the event perception source in the game scene. By matching specific color thresholds of the pixel area at the edge of the screen and analyzing the temporal domain and amplitude of the multi-channel audio signal, the spatial orientation information and feedback intensity information of the target game event are extracted from the underlying data of the visual and auditory modalities. Through a preset feedback mapping table, the above spatial orientation information and feedback intensity information are converted into driving instructions for the vibration unit of the specific spatial orientation on the feedback device. This multimodal feedback mechanism breaks through the limitations of traditional solutions that only support a preset single vibration mode and the feedback lag problem caused by the limitation of upper-level API calls. It enables the vibration unit on the feedback device (including heterogeneous input devices to be connected) to execute tactile feedback with direction discrimination capability according to the real-time spatial orientation and intensity of the event in the game scene, thereby providing users with an immersive vibration experience consistent with the game scene space.

[0205] Furthermore, this application embodiment also provides a computer-readable storage medium (or a non-volatile computer-readable storage medium) storing a computer program (or instructions). When the computer program is executed by a processor, it implements the various steps in the above-described cross-platform input device access method embodiment. The computer-readable storage medium may include any medium capable of storing program code, including but not limited to: read-only memory (ROM), random access memory (RAM), magnetic disk, optical disk, flash memory, hard disk (HDD), or solid-state drive (SSD). This storage medium may exist independently or be integrated into a processor or server.

[0206] The embodiments described herein may be provided as methods, systems, or computer program products. Therefore, this application may be implemented entirely in hardware, entirely in software, or a combination of hardware and software. Furthermore, this application may also be embodied as a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, optical storage, flash memory, etc.).

[0207] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this embodiment. It should be understood that each flow, block, and combination thereof in the flowchart illustrations and / or block diagrams can be implemented by computer program instructions. These instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device for execution, thereby producing a machine for implementing a specified function. Simultaneously, these instructions can also be stored in a computer-readable storage medium or loaded onto a computer device, causing the device to perform a series of operational steps to produce a computer-implemented process.

[0208] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. If such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for connecting a cross-platform input device, characterized in that, include: Determine the platform type of the target host connected to the receiver; Based on the platform type, the system calls the first device identity description data corresponding to the platform type to establish a first data channel between the receiver and the target host, and determines the signal conversion strategy of the receiver. Determine the device type of the input device to be connected to the receiver; Based on the device type, the second device identity description data corresponding to the device type is invoked to establish a second data channel between the receiver and the input device to be accessed. The second data channel is used to receive operation signals from the input device to be connected. Based on the signal conversion strategy, operational semantics are extracted from the operational signals, and the operational semantics are encapsulated into target control signals compatible with the platform type of the target host; The target control signal is sent to the target host through the first data channel.

2. The cross-platform input device access method as described in claim 1, characterized in that, Determine the platform type of the target host connected to the receiver, including: Based on the polling data from the target host captured by the receiver, the platform feature identifier is extracted; The platform feature identifier is compared with the platform feature database preset by the receiver to obtain the platform type of the target host; and / or Determining the device type of the input device to be connected to the receiver includes: Based on the access request data from the input device to be accessed captured by the receiver, the device identification feature of the input device to be accessed is extracted; The device identification feature is compared with the device feature database preset by the receiver to obtain the device type of the input device to be accessed.

3. The cross-platform input device access method as described in claim 1, characterized in that, Based on the platform type, a first data channel is established between the receiver and the target host by invoking the first device identity description data corresponding to the platform type, including: Capture the initial polling data packet sent by the target host, and extract the device enumeration feature from the initial polling data packet; Based on the device enumeration features, the corresponding native handshake protocol data is matched from the feature library built into the receiver and used as the first device identity description data; Based on the first device identity description data, a disguised response message carrying native peripheral protocol characteristics is sent back to the target host to establish the first data channel.

4. The cross-platform input device access method as described in claim 1, characterized in that, Based on the device type, second device identity description data corresponding to the device type is invoked to establish a second data channel between the receiver and the input device to be accessed, including: Based on the device type, the corresponding native host protocol data is matched from the feature library built into the receiver and used as the second device identity description data; Based on the second device identity description data, a disguised authentication data packet carrying native host protocol characteristics is sent to the input device to be accessed; Based on the authentication confirmation information fed back by the input device to be accessed, the communication link is configured to establish the second data channel.

5. The cross-platform input device access method as described in claim 1, characterized in that, Based on the signal conversion strategy, operational semantics are extracted from the operational signals, and the operational semantics are encapsulated into target key-value signals compatible with the platform type of the target host, including: Based on the operation signal, discrete trigger event identification and continuous physical quantity calculation are performed to obtain operation semantics that include operation type and operation magnitude. The control mapping relationship in the signal conversion strategy is invoked to map the operation type contained in the operation semantics to the target opcode; Based on the message specification corresponding to the platform type of the target host, data frame encapsulation is performed on the target opcode and the operation range to obtain the target control signal.

6. The cross-platform input device access method as described in claim 5, characterized in that, Before invoking the key-value mapping relationship in the signal conversion strategy, the access method further includes: Receive custom configuration data packets sent by the configuration terminal based on the configuration interface; The custom configuration data packet is parsed and validated to obtain the update mapping rules; The update operation is performed on the control mapping relationship pre-stored in the receiver based on the update mapping rule.

7. The cross-platform input device access method as described in claim 1, characterized in that, When at least two of the input devices to be accessed are connected to the same receiver, the access method further includes: Based on the built-in virtual traffic splitting architecture, corresponding logical interfaces are registered for each of the input devices to be accessed in the first data channel; Based on the access requests initiated by each of the input devices to be accessed, multiple second data channels corresponding one-to-one with each of the input devices to be accessed are established. Based on the signal conversion strategy, concurrent mapping conversion is performed on the operation signals received by each of the second data channels to obtain multiple target control signals; Based on each of the aforementioned logical interfaces, the multiple target control signals are respectively sent to the target host via the first data channel.

8. The cross-platform input device access method as described in claim 1, characterized in that, The access method further includes: Obtain the raw feedback data, including frame data and / or multi-channel audio data, output by the target host in running state; The raw feedback data is parsed, and the spatial orientation information and feedback intensity information of the target game event are extracted. A preset feedback mapping table is invoked to map the spatial orientation information and the feedback intensity information into a driving command for the target vibration unit. The target vibration unit belongs to a feedback device connected to the receiver, and the feedback device includes the input device to be connected. The driving command is sent to the feedback device to drive the target vibration unit to perform vibration feedback in the corresponding spatial orientation.

9. A cross-platform input device access device, characterized in that, The method includes a memory, a processor, and a cross-platform input device access program stored in the memory and executable on the processor. When the processor executes the cross-platform input device access program, it implements the cross-platform input device access method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a cross-platform input device access program, which, when executed by a processor, implements the cross-platform input device access method as described in any one of claims 1-8.

Images