Handheld game console and multi-purpose implementation method thereof

Abstract

The invention relates to the technical field of electronics, in particular to a handheld game console and a multi-purpose implementation method thereof. The multi-purpose implementation method comprises the following steps: expanding a controller capability report to enable a Bluetooth controller of a Bluetooth module to simultaneously support a central equipment role and a peripheral role in a dual-mode time division multiplexing mode; creating two virtual adapters, mapping the two virtual adapters to a Bluetooth controller at the same time through a time division multiplexing mechanism, and respectively applying the two virtual adapters to classic Bluetooth and BLE; in the dual-mode time division multiplexing mode, current to-be-transmitted data are confirmed and classified according to priorities, and the current to-be-transmitted data comprise audio data and handle control data; and transmitting the audio data and the handle control data in a time-sharing manner according to the priority. According to the embodiment of the invention, the problem of mode conflict is solved, dual-mode parallelism of classic Bluetooth audio transmission and BLE handle control is realized, a user does not need to carry out complex setting, and the functionality of equipment and the user experience are greatly improved.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and in particular to a handheld game console and a method for implementing its multi-purpose functionality. Background Technology

[0002] With the development of mobile computing and the gaming industry, handheld game consoles are becoming increasingly popular. These devices typically have built-in high-performance Bluetooth modules that support both classic Bluetooth and BLE (Bluetooth Low Energy) modes. Classic Bluetooth is usually used for high-bandwidth applications, such as using the A2DP profile (Advanced Audio Distribution Profile) for audio data output; while BLE mode is known for its low power consumption and fast connection characteristics, and is often used for connecting peripherals to PCs, such as using the HID over GATT profile (Human Interface Device Protocol) to transmit controller control data.

[0003] The inventors' research revealed that current handheld game consoles suffer from at least the following technical shortcomings:

[0004] Mode conflict: When the handheld game console connects to the PC via Bluetooth, its default Bluetooth mode is Classic Bluetooth, and its profile (protocol) is A2DP. Without changing its original Bluetooth functionality, simultaneously connecting it to the PC as a BLE controller presents challenges because the current Bluetooth protocol stack cannot effectively handle the dynamic switching and coexistence of master / slave roles and different profiles.

[0005] As a result, existing solutions typically force users to choose "as a standalone game console" instead of "as a PC controller," thus reducing device utilization and user experience.

[0006] Therefore, improvements to existing technologies are necessary.

[0007] The above information is provided as background information only to aid in understanding this application and does not constitute an assertion or admission that any of the above content can be used as prior art relative to this application. Summary of the Invention

[0008] This application provides a handheld game console and a method for implementing its multiple uses, in order to solve the problem of limited functionality caused by mode conflicts in the prior art.

[0009] To achieve the above objectives, this application provides the following technical solution:

[0010] In a first aspect, embodiments of this application provide a multi-purpose implementation method for a handheld game console, the handheld game console including a Bluetooth module, the working mode of the handheld game console including a dual-mode time-division multiplexing mode; in the dual-mode time-division multiplexing mode, the Bluetooth module supports dual-mode parallelism, maintaining a connection with an audio device as classic Bluetooth for audio data output, and maintaining a connection with a PC as Bluetooth Low Energy (BLE) for transmitting controller control data;

[0011] The multi-purpose implementation method includes:

[0012] By extending the controller capability report, the Bluetooth controller of the Bluetooth module can simultaneously support the central device role and the peripheral role in the dual-mode time-division multiplexing mode, so as to control the classic Bluetooth and the BLE respectively; two virtual adapters are created, which are simultaneously mapped to the Bluetooth controller through the time-division multiplexing mechanism and are used for the classic Bluetooth and the BLE respectively.

[0013] In the dual-mode time-division multiplexing mode, the data to be transmitted is identified and prioritized. The data to be transmitted includes the audio data and the controller control data. The audio data and the controller control data are then transmitted in a time-division manner according to their priorities.

[0014] Optionally, the step of transmitting the audio data and the controller control data in a time-division manner according to priority includes:

[0015] By default, the audio data is transmitted first, and the controller control data is scheduled to be transmitted during the interval between the transmission of two adjacent frames of audio data.

[0016] When the current scene is detected to be a preset intense game scene, the priority of the controller control data is temporarily adjusted to be higher than the priority of the audio data;

[0017] When a stutter or retransmission of the audio data is detected, the priority of the audio data is temporarily adjusted to be higher than the priority of the controller control data.

[0018] Optionally, it also includes: actively negotiating a maximum transmission unit with the PC during the connection establishment phase between the BLE and the PC; and transmitting the controller control data according to the maximum transmission unit during the transmission of the controller control data.

[0019] Optionally, it also includes: dynamically adjusting BLE connection parameters, including shortening the connection interval parameter, reducing the slave delay parameter, and extending the monitoring timeout parameter; and controlling the transmission of the handle control data according to the BLE connection parameters during the transmission of the handle control data.

[0020] Optionally, it also includes: during the transmission of the handle control data,

[0021] Differential encoding is performed on the continuously changing target data in the handle control data, and only the amount of change is transmitted. The target data includes joystick control data.

[0022] And / or, during periods of high audio data density, the handle control data is transmitted after batch processing;

[0023] And / or, monitor the current send queue depth in real time, and automatically reduce the sampling rate of the handle control data when the send queue is backlogged.

[0024] Optionally, it also includes: predicting radio frequency conflict time windows by monitoring the timestamps of scheduled transmitted data packets, and proactively delaying preset non-critical handle control data within the radio frequency conflict time window.

[0025] Optionally, during the transmission of the audio data and the controller control data, a fixed guaranteed bandwidth is allocated to the audio data, and an optimal effort bandwidth is allocated to the controller control data.

[0026] Optionally, it also includes: collecting statistical information in real time, including data throughput, packet transmission delay distribution, radio frequency collision count, error rate and retransmission rate of each protocol, and exposing the statistical information through the debugfs interface and the D-Bus interface of the system bus, respectively, for real-time display and problem diagnosis of desktop applications.

[0027] Secondly, embodiments of this application provide a handheld game console, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the multi-purpose handheld game console method as described in any of the above claims.

[0028] Thirdly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions thereon, which are executed by a computer processor to implement the multi-purpose implementation method of the handheld game console as described in any of the above claims.

[0029] Compared with the prior art, this application has the following beneficial effects:

[0030] This application's embodiments, by extending the controller capability report, enable the Bluetooth controller to simultaneously support both Central and Peripheral roles. Combined with the logical isolation and time-division multiplexing mapping of dual virtual adapters, the mode conflict problem is overcome, achieving dual-mode parallel operation of classic Bluetooth audio transmission and BLE gamepad control. Furthermore, the mode management state machine can accurately respond to switching commands from the operating system's desktop application without manual configuration. The switching process automatically and synchronously activates the corresponding role, virtual adapter, and transmission strategy. Users can enjoy the handheld's own gaming and audio functions while simultaneously using it as a high-performance wireless gamepad for PC games, greatly enhancing the device's functionality and user experience.

[0031] This application has other features and advantages that will be apparent from or will be set forth in detail in the accompanying drawings and following detailed description, which together serve to explain the particular principles of this application. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a flowchart of Profile concurrency and resource arbitration provided in an embodiment of this application;

[0034] Figure 2 This is a flowchart illustrating the switching management process for the working mode provided in this application embodiment;

[0035] Figure 3 This is a system architecture diagram of a handheld game console and a PC provided in an embodiment of this application;

[0036] Figure 4 This is a flowchart of the BLE transmission optimization module provided in the embodiments of this application;

[0037] Figure 5 This is a flowchart of the internal data flow of a Windows-specific driver provided in this application embodiment. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] To address the limitation of single-function technology in existing technologies, this application provides a multi-purpose handheld game console. The handheld game console includes a Bluetooth module and operates in three modes:

[0040] The first working mode is Standlone: ​​Independent game console mode.

[0041] Bluetooth module role: Classic Bluetooth Host.

[0042] Function Description: In this mode, the handheld game console operates as a standalone gaming device. The Bluetooth module is used to connect Bluetooth headsets, speakers (A2DP / AVRCP), or other classic Bluetooth peripherals. The BLE function is either idle or off.

[0043] The second working mode is Peripheral: Bluetooth gamepad mode.

[0044] Bluetooth module role: Bluetooth Low Energy Peripheral (slave device or peripheral).

[0045] Function Description: In this mode, the handheld game console emulates a BLE game controller. The Bluetooth module stops classic Bluetooth broadcasting and begins broadcasting the HID over GATT service, awaiting scanning and connection by a PC. The handheld's own audio output is typically forced to switch to the built-in speakers or the 3.5mm headphone jack, as classic Bluetooth audio connectivity is no longer available.

[0046] The third working mode, Dual: Dual-mode time-division multiplexing mode.

[0047] Bluetooth module role: Dual-mode (dual-mode parallel).

[0048] Function Description: This is the most complex and core mode. In this mode, the handheld game console maintains two logical connections simultaneously: as a classic Bluetooth Host, it stays connected to the audio device for audio data output; and as a Bluetooth Low Energy Peripheral, it stays connected to the PC for transmitting controller control data.

[0049] Therefore, this application provides a method for implementing a multi-purpose handheld game console, including:

[0050] By extending the controller capability report, the Bluetooth module's Bluetooth controller can simultaneously support the central device role and peripheral role in dual-mode time-division multiplexing mode, for controlling Classic Bluetooth and BLE respectively; two virtual adapters are created, which are simultaneously mapped to the Bluetooth controller through a time-division multiplexing mechanism, and are used for Classic Bluetooth and BLE respectively; a mode management state machine is created to respond to mode switching commands from the operating system desktop application.

[0051] When switching to dual-mode time-division multiplexing mode, the data to be transmitted is identified and prioritized. The data to be transmitted includes audio data and controller control data. Audio data and controller control data are transmitted in a time-division manner according to priority.

[0052] In summary, this application's embodiments, by extending the controller capability report, enable the Bluetooth controller to simultaneously support both Central and Peripheral roles. Combined with the logical isolation and time-division multiplexing mapping of dual virtual adapters, the mode conflict problem is overcome, achieving dual-mode parallel operation of classic Bluetooth audio transmission and BLE gamepad control. Furthermore, the mode management state machine can accurately respond to switching commands from the operating system's desktop application without manual configuration. The switching process automatically and synchronously activates the corresponding role, virtual adapter, and transmission strategy. Users can enjoy the handheld's own gaming and audio functions while simultaneously using it as a high-performance wireless gamepad for PC games, greatly enhancing the device's functionality and user experience.

[0053] The inventors also discovered the following technical pain points in the existing technology:

[0054] Transmission performance bottleneck: The transmission rate and stability of the standard BLE protocol are insufficient to meet the demands of high-quality game controls. Its data transmission suffers from high latency and large rate fluctuations (typically far below 50KB / s), making it unsuitable for game interaction scenarios with extremely high real-time requirements, easily leading to stuttering and latency.

[0055] Windows compatibility issues: Microsoft's Windows operating system has excellent native support for classic Bluetooth controllers, automatically recognizing them as standard gaming devices such as the Xbox 360 Controller. However, for BLE HID devices, especially game controllers based on the GATT protocol, driver support is very limited, preventing them from being directly recognized as standard game controllers, resulting in poor compatibility and missing functionality.

[0056] Therefore, the present application also provides the following embodiments, in which each implementation step will be described in detail.

[0057] I. Dual-mode coexistence and control module: Integrated into the game handheld operating system (e.g., SteamOS). This module features deep customization of the open-source BlueZ Bluetooth protocol stack and the Linux Bluetooth protocol stack.

[0058] 1. Deep customization of BlueZ user space

[0059] 1.1 Customized Management of Dual-Mode Roles

[0060] Extended Controller Capabilities Report: By modifying src / shared / mainloop.c and tools / btmgmt.c, the controller can now support both the Central and Peripheral roles in Dual mode (i.e., dual-mode), instead of the traditional single role.

[0061] The `src / shared / mainloop.c` file is the "core event loop file" of the BlueZ protocol stack, used to schedule the processing order of various Bluetooth events. The `tools / btmgmt.c` file is the "Bluetooth management tool source code file" included with BlueZ, a key tool for debugging and controlling Bluetooth hardware.

[0062] Based on the extended controller capability report, the controller can simultaneously complete the registration and event response of two roles in Dual mode: when acting as the Central role, it can normally scan and connect to audio devices such as Bluetooth headsets and speakers to realize the function of a standalone game console; when acting as the Peripheral role, it can broadcast the BLE HOGP service, be scanned and connected by a PC to realize the function of a gamepad.

[0063] Create a virtual controller interface: In bluez / src / adapter.c (the "adapter management core file" of the BlueZ protocol stack, responsible for managing adapters), create a logical virtual interface so that upper-layer applications see two independent virtual adapters: one for Classic Bluetooth and one for BLE. The underlying layer uses a time-division multiplexing mechanism to map these two virtual adapters to the same physical Bluetooth controller. Based on this, upper-layer applications see two independent Bluetooth adapters, but the underlying Bluetooth controller, through time-division multiplexing, can respond to requests from both virtual adapters simultaneously, achieving "logical separation, physical sharing" and avoiding compatibility errors (such as data obfuscation).

[0064] Custom state machine management: A mode management state machine is integrated into bluez / src / main.c (the "main entry file" of the BlueZ protocol stack, responsible for initializing all core modules), enabling it to respond to mode switching commands from the SteamOS (a Linux-based operating system for handheld consoles) desktop application. Based on this, mode switching logic can be uniformly managed through the mode management state machine.

[0065] 1.2 Deep Implementation of HID over GATT (HOGP) Profile (Human Interface Device over Generic Attribute Profile):

[0066] Extended HOGP service descriptors: A complete gamepad report mapping is customized in profiles / input / hog-lib.c (a library file in the BlueZ Bluetooth protocol stack responsible for the core logic of the HOGP protocol, used to store the description rules and report mapping format of HOGP services). The gamepad report defines the operation control parameters for each hardware component of the gamepad, such as joystick control parameters, button control parameters, trigger control parameters, D-pad control parameters, action button control parameters, and vibration feedback control parameters. Based on this, the gamepad report can perfectly match the gamepad's operation logic, with no missing functions and high accuracy.

[0067] Optimize the report notification mechanism: Modify the notification sending logic in profiles / input / hog-device.c (the core file in the BlueZ protocol stack responsible for HOGP device "sending data notifications"), integrating data compression and batch processing algorithms to avoid frequent transmission of small data packets. Data compression and batch processing effectively improve transmission efficiency, reduce latency, and prevent stuttering caused by frequent small packet transmissions.

[0068] 1.3 Profile Concurrent Arbitration Integration

[0069] Create a Profile Arbitration Layer: Add a new module src / profile-arbiter.c (a new "resource scheduling module file" added to the BlueZ protocol stack, used to manage multi-profile concurrency) in BlueZ, which serves as a unified scheduler for all Profile traffic (the actual data transmitted by each Profile; A2DP traffic is audio data streams, and HOGP traffic is game control data).

[0070] Integrated QoS (Quality of Service) classification: Insert a classification hook in the data transmission path of src / adapter.c (BlueZ protocol stack "Bluetooth adapter management file") to assign priority tags based on packet type (audio vs. control).

[0071] For example, A2DP audio streams and joystick / trigger data can be set to high priority because the audio cannot be choppy and the joystick / trigger is a core game operation that requires extremely low latency and high real-time performance. Action buttons (A / B / X / Y) and the D-pad are regular operations that allow for shorter delays and do not affect the game experience, so they can be set to medium priority. Menu buttons, home buttons, and repeat buttons are non-core operations that users do not perceive as having longer delays, so they can be set to low priority.

[0072] 2. Customization of the Linux kernel Bluetooth subsystem

[0073] 2.1 HCI (Host Controller Interface) Layer Connection Parameter Optimization:

[0074] Dynamic connection parameter management: Modify net / bluetooth / hci_conn.c (the core file in the Linux kernel responsible for managing Bluetooth connection parameters) to allow dynamic setting of connection parameters from user space (i.e., upper-layer applications, such as SteamOS's mode switching UI and game optimization programs). For example, core parameters that can be directly set by user space may include: minimum connection interval (min_interval), maximum connection interval (max_interval), slave latency, and supervision timeout. By allowing upper-layer applications to dynamically adjust core parameters such as connection interval, latency, and timeout, BLE transmission latency can be reduced, connection stability improved, and the requirements of real-time game control can be met.

[0075] MTU (Maximum Transmission Unit) negotiation optimization: By modifying the l2cap_bredr_sig_cmd and l2cap_le_sig_cmd processing logic in net / bluetooth / l2cap_core.c, the maximum MTU (247 bytes) is actively requested during the connection establishment phase. It's important to note that a larger MTU allows for more data transmission in a single operation, requires fewer transmissions, and results in higher transmission efficiency. By actively negotiating the maximum MTU during connection establishment, increasing it from the default 23 bytes to 247 bytes, the amount of data transmitted in a single operation can be increased, the number of transmissions reduced, and the transmission efficiency of both BLE and Classic Bluetooth improved.

[0076] 2.2 RF Timing Scheduling Optimization

[0077] Create a dual-mode scheduler: Implement a custom packet scheduling algorithm in net / bluetooth / hci_core.c; this packet scheduling algorithm sets the scheduling priority: audio data stream > game control data > other Bluetooth data (such as device status notifications), which can solve the problem of "audio data stream and game control data competing for the radio frequency channel", allowing the two types of data to be transmitted according to priority and timing intervals, so as not to delay the smoothness of audio, nor to affect the gamepad latency.

[0078] Conflict prediction and avoidance: By monitoring the timestamps of scheduled data packets, the radio frequency conflict time window is predicted, and low-priority data packets are rescheduled in advance accordingly.

[0079] 3. System Integration and API Exposure

[0080] This section integrates the scattered underlying technology modules, such as BlueZ protocol stack customization, Linux kernel optimization, and mode management state machine, into a unified set of functions that can be called and managed by the SteamOS system, ensuring that the modules work together, such as synchronously enabling virtual adapters and time-sharing schedulers when switching modes.

[0081] 3.1 Custom D-Bus API

[0082] Create a mode management interface: Expose a dedicated D-Bus (Desktop Bus) interface in BlueZ for SteamOS desktop applications to call.

[0083] 3.2 Performance Monitoring and Debugging Interface

[0084] Implement statistical information collection: Add performance counters in the kernel and BlueZ to monitor in real time: data throughput, packet transmission delay distribution, radio frequency collision count, error rate and retransmission rate for each profile.

[0085] Expose debugging interfaces: Expose these statistics through debugfs and D-Bus properties for real-time display and problem diagnosis in desktop applications.

[0086] Based on the above customization, a dual-mode time-division multiplexing mechanism was implemented. It allows the Bluetooth chip to logically maintain two independent virtual connections simultaneously: one as a Host, using the classic Bluetooth protocol to communicate with audio devices (such as headphones) and maintain profiles such as A2DP / AVRCP; the other as a Peripheral, using the BLE protocol and simulating a HID over GATT (HOGP) device.

[0087] II. Controller Mode Management and Switching

[0088] 1. Mode switching command sequence:

[0089] Use the btmgmt command to control the switching from Standlone to Peripheral and from Peripheral to Dual.

[0090] 2. Hardware status monitoring and recovery:

[0091] A. Implement a hardware status listener to continuously monitor the actual working status of the controller (via HCI events).

[0092] B. When an abnormal state is detected (such as controller reset or mode switching failure), a recovery sequence is automatically executed.

[0093] C. Record error codes during the switching process to provide detailed fault diagnosis information for the UI.

[0094] 3. Power management optimization:

[0095] Different power strategies are employed in different modes:

[0096] A. Standlone mode: Standard power consumption strategy.

[0097] B. Peripheral mode: Optimized for low-power listening and extended broadcast time.

[0098] C. Dual Mode: A performance-first strategy that allows for higher power consumption to maintain dual-connectivity stability.

[0099] III. Profile Concurrency and Resource Arbitration

[0100] 1. Time-sequenced arbitration mechanism

[0101] A. A2DP Audio Frame Analysis: Monitor the frame interval of the A2DP audio stream and prioritize scheduling BLE HID data packets during the natural gaps in audio frame transmission.

[0102] B. Dynamic priority adjustment:

[0103] i. When intense gameplay is detected (frequent HID report changes), temporarily increase the priority of HID data. This is because during intense gameplay (such as FPS shooting), the operation of the joystick / trigger button is "millisecond sensitive," and a delay of more than 10ms can lead to aiming errors. In this case, the controller experience is more important than audio smoothness.

[0104] ii. When audio stream stutters or retransmissions occur, temporarily increase the priority of A2DP data. This is because audio stuttering / retransmissions indicate insufficient audio bandwidth. If the controller continues to compete for resources, it will cause audio stream interruptions (more noticeable to the user). In this case, ensuring audio stability should be prioritized.

[0105] C. Collision Avoidance Algorithm: Predicts the RF collision time window and proactively delays non-critical HID reports (such as continuously held-down arrow keys). In other words, this algorithm predicts the time period during which two data plans will be transmitted simultaneously (at which point resource contention will occur, leading to data retransmissions and spiked latency), and delays non-critical HID reports accordingly, thus avoiding critical data delays caused by collisions.

[0106] 2. Quality of Service (QoS) Policy

[0107] A. Data Classification: Classification principles can prioritize operations based on their sensitivity to latency; operations that significantly impact user experience should have higher priority. For example, priorities can be assigned as follows:

[0108] i. Real-time high priority: joystick coordinates, trigger buttons (requires extremely low latency);

[0109] ii. Real-time standard priority: primary action keys (A / B / X / Y);

[0110] iii. Non-real-time low priority: menu button, home button, etc.

[0111] This is because the joystick / trigger button is a "fine control" button, and a high delay will cause the operation and screen to be out of sync, so it is set to high priority; A / B / X / Y is a "core operation", and a high delay will result in "no response when pressed", so it is set to standard priority; the menu button / home button is a non-real-time operation, and a slightly delayed response will not affect the experience, so it is set to low priority.

[0112] B. Bandwidth allocation:

[0113] i. Reserve a guaranteed bandwidth for A2DP (to ensure smooth audio playback); this is equivalent to reserving a "fixed bandwidth" for A2DP, which is used exclusively for audio regardless of how busy other data is.

[0114] ii. Allocate optimal effort bandwidth to HID so that all available bandwidth can be used when audio is idle. This is equivalent to allocating "elastic bandwidth" to HID, allowing HID to utilize all idle bandwidth not used by audio.

[0115] 3. Buffer Management and Flow Control

[0116] A. HID data compression: Differential encoding is used for continuously changing data such as joysticks, transmitting only the changing amounts, which can reduce the amount of data transmitted and reduce bandwidth usage.

[0117] B. Adaptive Batch Processing: During periods of high audio intensity, multiple HID reports are packaged and sent in a single connection event, which reduces the number of transmissions and lowers RF channel usage.

[0118] C. Congestion Control: Monitor the depth of the sending queue and automatically reduce the HID sampling rate when the queue is backlogged. This can effectively reduce the congestion rate and avoid a vicious cycle of increasing congestion.

[0119] Figure 1 This embodiment illustrates the complete implementation logic of Profile concurrency and resource arbitration, specifically including:

[0120] By using a traffic monitor to monitor the transmission status of two types of data (handheld control data and audio data) in real time, such as the current data type, traffic indicators (e.g., the transmission period of audio frames), and the sending queue depth, a "real-time data status basis" is provided for subsequent QoS classification and timing arbitration, enabling early identification of congestion risks and avoiding blind scheduling;

[0121] The QOS classifier prioritizes various data types based on "real-time performance and importance," and the classification rules are matched to the needs of the game scenario.

[0122] The timing arbitration engine performs A2DP audio frame interval parsing and RF conflict prediction;

[0123] The dynamic scheduler, based on default and dynamic priority adjustments and congestion warnings from the traffic monitor, achieves "dynamic allocation of radio frequency resources," minimizing handset operation latency while ensuring smooth audio, and enabling dual-mode parallelism.

[0124] Meanwhile, the performance monitoring module collects transmission performance indicators (latency statistics, error statistics, link quality) in real time, generates performance feedback reports, and sends them to the dynamic scheduler.

[0125] IV. SteamOS System Integration and Status Management

[0126] 1. Core principles: such as Figure 2 As shown, role switching and time-sharing are based on work modes.

[0127] The Bluetooth controller for a handheld game console needs to dynamically switch its role and supported protocol profile in different operating modes. This module manages this switching through a precise mode state machine, ensuring that system behavior matches user intent. Figure 1 To.

[0128] 2. Pattern State Machine: The module maintains a clear state machine internally.

[0129] (1) Standlone: ​​Indie game console mode

[0130] A. Bluetooth Role: Classic Bluetooth Host.

[0131] B. Function Description: In this mode, the handheld game console operates as a standalone gaming device. The Bluetooth module is used to connect Bluetooth headsets, speakers (A2DP / AVRCP), or other classic Bluetooth peripherals. BLE functionality is either idle or off.

[0132] (2) Peripheral: Bluetooth controller mode

[0133] A. Bluetooth Role: Bluetooth Low Energy Peripheral.

[0134] B. Function Description: In this mode, the handheld game console emulates a BLE game controller. The Bluetooth module stops classic Bluetooth broadcasting and begins broadcasting the HID over GATT service, awaiting scanning and connection by a PC. The handheld game console's own audio output is typically forced to switch to the built-in speakers or the 3.5mm headphone jack, as classic Bluetooth audio connectivity is no longer available.

[0135] (3) Dual: Dual-mode time-division multiplexing mode

[0136] A. Bluetooth role: Dual-mode (dual-mode parallel).

[0137] B. Functional Description: This is the most complex and core mode. The handheld game console maintains two logical connections simultaneously:

[0138] i. As a classic Bluetooth host, it maintains a connection with audio devices for audio output.

[0139] ii. As a low-power Bluetooth Peripheral, it maintains a connection with the PC to transmit controller control data.

[0140] C. Implementation Mechanism: Time-division multiplexing of RF resources is achieved through a customized BlueZ stack. The module contains a scheduler responsible for inserting BLE HID data packets between the data packet intervals of the A2DP audio stream, and ensuring the response speed of HID operations through optimized connection parameters.

[0141] V. High-performance BLE transmission optimization module: such as Figure 4 As shown, this module comprehensively optimizes transmission rate and stability through multiple technologies to ensure a stable rate exceeding 50KB / s:

[0142] MTU negotiation optimization: During the connection establishment phase, actively negotiate the maximum transmission unit (MTU) with the PC and set it to the highest allowed value (e.g., 517 bytes) that is greater than the default value of 23 bytes, which significantly reduces protocol overhead and improves effective data throughput.

[0143] Connection parameter optimization: Dynamically adjust BLE connection parameters, including shortening the connection interval (ConnectionInterval), reducing slave latency, and setting a longer supervision timeout (SupervisionTimeout). This combination of parameters achieves the best balance between power consumption and real-time performance, greatly reducing data transmission latency.

[0144] Data compression and batch processing: Lightweight lossless compression and differential encoding are performed on HID report data (only the changed data is sent), and batch processing is performed within a single connection event to send multiple frames at once, making full use of the advantages of high MTU.

[0145] Furthermore, embodiments of this application may also provide a Windows-specific driver that runs on a PC. For example... Figure 3 and Figure 5 As shown, the core function of this driver is protocol conversion and remapping. It listens for and receives raw BLEHID report descriptors and data packets from the handheld game console, then converts and emulates them in real time into a data format that can be recognized by the Xbox 360 Controller driver (Xinput interface) natively supported by the Windows system. This driver acts as a virtual HID device, presenting itself as a standard Xbox 360 controller to upper-level games and applications, completely resolving system compatibility issues.

[0146] To facilitate understanding, an application example is provided below. This system is implemented on a handheld gaming console running SteamOS. The system architecture consisting of the handheld gaming console and the PC is as follows: Figure 3 As shown.

[0147] Handheld device implementation:

[0148] The Bluetooth module uses a dual-mode chip that supports Bluetooth 5.0 or higher (such as MTK 7925).

[0149] Bluetooth protocol stack modifications: Configure controller mode in ` / etc / bluetooth / main.conf` and write a daemon process to manage the priority and resource allocation of the two modes. Ensure the audio connection is not unexpectedly dropped due to BLE communication.

[0150] To implement the HOGP service: Use BlueZ's D-Bus API (such as the GattCharacteristic1 interface) to create the following service structure: "Service UUID: 0x1812 (Human Interface Device)," which includes features such as "HID information, report mapping, reports, protocol modes, and HID control points." The report mapping provides a detailed description of all the controls on the game controller.

[0151] Transmission optimization: such as Figure 4 As shown, after establishing a connection, BlueZ's MTU Exchange function is immediately invoked to set the MTU to 517; the connection parameters are set to "connection interval = 15ms, slave delay = 0, supervisor timeout = 1000ms" through a custom program; the coordinate data of the joystick and trigger buttons (such as 16-bit values) are compressed using simple run-length encoding (RLE), and new data is only sent when the change of the last reported value exceeds the threshold.

[0152] Desktop application / UI implementation: mode switching switch, i.e., a graphical switch that provides one-click to turn "PC gamepad mode" on / off; connection status display, including real-time display of BLE connection status with PC, signal strength, and transmission rate (KB / s).

[0153] Advanced settings panel: Includes audio output selection, allowing users to choose whether game audio is output from the handheld console or from the PC (when PC games support this); performance preferences, providing two preset modes: "Low Latency" (optimizes controller response) and "High Quality" (ensures smooth audio), each corresponding to different connection parameters and arbitration strategies.

[0154] PC-side driver implementation:

[0155] Develop service applications based on the Bluetooth LE explorer solution for BLE Bluetooth discovery and connection.

[0156] Based on the ViGEm solution, a virtual Xbox 360 controller driver was developed, with internal data flow as follows: Figure 5 As shown.

[0157] The driver first implements a data bridge, bridging the data received by BLE to the Xbox 360 controller.

[0158] The driver has a built-in mapping table that parses out the raw button and joystick data of BLE and reassembles it according to the format and data structure defined by the Microsoft Xinput API.

[0159] The driver creates a virtual device (Xbox 360 controller) node, and the game uses this virtual device driver by default after launching.

[0160] Through the above implementation methods, the embodiments of this application successfully transform a handheld game console into a powerful, compatible, and responsive PC dual-mode Bluetooth game controller.

[0161] In summary, compared with the prior art, the present invention has the following significant advantages:

[0162] 1) Seamless switching and coexistence: Users can enjoy the handheld's own game and audio functions while using it as a high-performance wireless controller for PC games without complicated settings, greatly improving the device's functionality and user experience.

[0163] 2) Excellent compatibility: Through a dedicated PC driver, the industry problem of poor Windows support for BLE game controllers is perfectly solved, enabling the device to be plug-and-play and recognized by all games that support Xinput.

[0164] 3) High performance and low latency: Through multiple technical means such as MTU optimization, connection parameter adjustment and data compression, the data transmission rate of BLE has been successfully increased to more than 50KB / s and kept stable, meeting the demanding requirements of high-end games for real-time control.

[0165] 4) Based on open source, low cost: The core of the solution is based on the open source BlueZ stack, which reduces development costs and is conducive to technology promotion and ecosystem building.

[0166] Secondly, embodiments of this application provide a handheld game console, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the multi-purpose handheld game console implementation method described in any embodiment of the application.

[0167] The aforementioned handheld game console can execute the methods provided in any embodiment of this application, possessing the corresponding functional modules and beneficial effects for executing the methods. Based on the foregoing embodiments, features not explained in this embodiment are explained using the methods described in the foregoing embodiments, and will not be repeated here.

[0168] Thirdly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the multi-purpose implementation method of a handheld game console as provided in all embodiments of this application.

[0169] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0170] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0171] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0172] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0173] Finally, it should be noted that although the above embodiments have been described in the text and drawings of this application, this should not limit the scope of patent protection of this application. Any technical solutions that are based on the essential concept of this application and utilize the content described in the text and drawings of this application, resulting in equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this application.

Claims

1. A multi-purpose implementation method of a game handheld machine, characterized by, The game console includes a Bluetooth module, and a working mode of the game console includes a dual-mode time-division multiplexing mode; in the dual-mode time-division multiplexing mode, the Bluetooth module supports dual-mode parallel, maintains connection with an audio device as classic Bluetooth for audio data output, and maintains connection with a PC as Bluetooth low energy (BLE) for transmission of handle control data; The multi-purpose implementation method includes: By extending a controller capability report, a Bluetooth controller of the Bluetooth module is enabled to simultaneously support a central device role and a peripheral role in the dual-mode time-division multiplexing mode, for controlling the classic Bluetooth and the BLE, respectively; two virtual adapters are created, which are simultaneously mapped to the Bluetooth controller through a time-division multiplexing mechanism and are used for the classic Bluetooth and the BLE, respectively; In the dual-mode time-division multiplexing mode, current to-be-transmitted data including the audio data and the handle control data is confirmed and classified according to priority; and the audio data and the handle control data are transmitted according to priority in time division.

2. The multi-purpose implementation method of a game handheld according to claim 1, characterized in that, The transmission of the audio data and the handle control data according to priority in time division includes: By default, the audio data is preferentially transmitted, and the handle control data is scheduled for transmission in a transmission gap between adjacent two frames of audio data; When it is detected that a current scene is a preset intense game scene, the priority of the handle control data is temporarily adjusted to be higher than that of the audio data; When it is detected that the audio data is stuck or retransmitted, the priority of the audio data is temporarily adjusted to be higher than that of the handle control data.

3. The method of claim 1, wherein, Further includes: In a connection establishment stage of the BLE and the PC, the maximum transmission unit is actively negotiated with the PC; In the transmission process of the handle control data, the handle control data is transmitted according to the maximum transmission unit.

4. The multi-purpose implementation method of a game handheld according to claim 1, characterized in that, Further includes: The BLE connection parameters are dynamically adjusted, including shortening a connection interval parameter, reducing a slave delay parameter, and prolonging a supervision timeout parameter; in the transmission process of the handle control data, the transmission of the handle control data is controlled according to the BLE connection parameters.

5. The multi-purpose implementation method of a game handheld according to claim 1, characterized in that, Further includes: In the transmission process of the handle control data, The target data in the handle control data that continuously changes is differentially encoded, and only the change amount is transmitted, the target data including rocker control data; And / or, in an intensive period of the audio data, the handle control data is batch-processed and then transmitted; And / or, the current sending queue depth is monitored in real time, and the sampling rate of the handle control data is automatically reduced when the sending queue is accumulated.

6. The multi-purpose implementation method of a game handheld according to claim 1, characterized in that, Further includes: By monitoring the timestamps of the data packets that have been scheduled for transmission, a radio frequency conflict time window is predicted, and preset non-critical handle control data is actively delayed in the radio frequency conflict time window.

7. The method of claim 1, wherein, In the transmission process of the audio data and the handle control data, a fixed guaranteed bandwidth is allocated to the audio data, and a best effort bandwidth is allocated to the handle control data.

8. The method of claim 1, wherein, Further includes: Real-time collection of statistics including data throughput, packet transmission delay distribution, radio frequency collision count, error rate and retransmission rate of each protocol, and exposing the statistics through debug monitoring interface debugfs and system bus D-Bus interface respectively for real-time display and problem diagnosis of desktop applications.

9. A game handheld machine comprising a memory and a processor, the memory storing a computer program, characterized in that, The computer program is executed by the processor to implement the multi-purpose implementation method of the game console as claimed in any one of claims 1 to 8.

10. A computer-readable storage medium having stored thereon computer- executable instructions, wherein, The computer executable instructions are executed by a computer processor to implement the multi-purpose implementation method of the game console as claimed in any one of claims 1 to 8.

Images