A heterogeneous desktop fusion method based on hardware and software cooperation

Abstract

This invention discloses a heterogeneous desktop fusion method based on hardware and software collaboration, aiming to solve the problems of difficulty in balancing compatibility and performance, fragmented user experience, poor peripheral compatibility, and complex deployment when running Windows applications on domestic non-x86 platforms in the context of domestic IT innovation. This method connects the domestic system host and the x86 architecture Windows coprocessor unit through a dedicated USB bridge link, creating isolated virtual network and virtual USB dual channels in kernel mode. It uses a private protocol with single application window granularity for data transmission, and achieves hybrid rendering of remote windows and the local desktop through a kernel-level virtual display driver, while simultaneously realizing kernel-level transparent redirection of peripherals. This invention does not rely on the virtualization capabilities of domestic chips, achieving native-level compatibility with Windows applications, a seamless operating experience, and compatibility with all types of peripherals, significantly reducing the deployment and maintenance costs of domestic IT innovation transformation.

Description

Technical Field

[0001] This invention relates to the field of computer desktop virtualization and cross-platform desktop interaction technology, specifically to a heterogeneous desktop fusion method based on software and hardware collaboration. Background Technology

[0002] With the deepening of the Information Technology Application Innovation Project, terminal devices using domestically produced CPUs (such as Phytium, Kunpeng, Loongson, and Zhaoxin) and domestically produced operating systems have become increasingly popular. However, due to differences in underlying instruction set architecture, hardware virtualization support, and system kernels, running commercial software, industry-specific software, and specific hardware-related applications that heavily rely on specific Windows APIs, drivers, or high-performance graphics interfaces directly on domestically produced platforms still faces serious compatibility challenges.

[0003] Currently, the technical approaches used in the industry to solve the problem of operating heterogeneous system applications mainly have the following limitations: 1. Software binary translation and compatibility layer technology: This approach achieves dynamic instruction translation and system call interception by building a compatibility layer. However, this type of solution does not provide good support for complex applications that heavily rely on Windows kernel features, multi-threaded synchronization, and high-performance graphics interfaces. Furthermore, due to the significant overhead of instruction translation, its stability, performance, and compatibility are difficult to meet the stringent requirements of production environments.

[0004] 2. Hardware-assisted virtualization technology: This technology utilizes CPU virtualization to extend the operation of virtual machines. However, the virtualization support capabilities of existing domestic chips vary widely. Some models lack critical IOMMU (Input / Output Memory Management Unit) support or virtualization instruction extensions, resulting in low hardware passthrough efficiency and significant performance loss. Furthermore, deploying a complete virtualization stack (such as KVM+QEMU) on a domestic operating system requires extremely high user technical skills and is difficult to seamlessly integrate Windows applications with the local desktop environment, leading to extremely high resource consumption.

[0005] 3. Traditional Remote Desktop Protocols (RDP / VNC) and VDI Solutions: These solutions shift the computational load to the server, but are highly dependent on the network environment. Application availability drops significantly in scenarios with network fluctuations, high latency, or offline work. More importantly, standard remote protocols have significant limitations in hardware-level interaction support for industry-specific peripherals (such as medical imaging equipment, industrial control terminals, and specific encrypted USB tokens), making it difficult to achieve transparent forwarding and deep redirection of USB Request Blocks (URBs) at the kernel level.

[0006] 4. Deployment complexity and user experience disconnect: Existing solutions often require complex server-side management or local virtualization configuration, resulting in high maintenance costs. Furthermore, at the interaction level, heterogeneous applications typically run in independent remote desktop windows and cannot be integrated into the local desktop synthesizer in a "native" window format. This leads to a severe disconnect in interactive logic such as window stacking, clipboard sharing, and file dragging, resulting in low user efficiency.

[0007] In summary, existing technologies lack a heterogeneous desktop convergence solution that is low-cost, highly integrated, plug-and-play, and supports deep local hardware binding, under the constraint of limited support for virtualization of domestic chip hardware. Summary of the Invention

[0008] This invention aims to provide a heterogeneous desktop integration method based on hardware and software collaboration to solve the technical problems of compatibility bottlenecks, high computing resource overhead, insufficient support for industry-specific peripherals, and visual fragmentation in cross-system interaction when non-x86 architecture domestic platforms run x86 architecture applications. By constructing a collaborative processing architecture that includes physical bridging links and hardware coprocessing units, and utilizing host kernel drivers to achieve transparent interception and forwarding of underlying USB request blocks and deep composite rendering of heterogeneous application window textures, this invention achieves native-level compatibility of heterogeneous ecosystem applications in the local environment, kernel-level peripheral redirection, and seamless window-level fusion interaction without relying on a heavy virtualization stack.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a heterogeneous desktop integration method based on hardware and software collaboration, applied to a first computing device running a non-x86 architecture domestic operating system, wherein the first computing device communicates with a second computing device running an x86 architecture Windows operating system via a dedicated USB bridge link, comprising the following steps: S1. In response to the access event of the dedicated USB bridging link, the exclusive identifier built into the dedicated USB bridging link is verified by the vendor-defined instruction, and after the verification is passed, a dedicated point-to-point communication virtual network interface and a virtual USB host controller are synchronously created in the kernel mode of the first computing device. S2. Establish an encrypted communication session with the second computing device through the virtual network interface, obtain a list of runnable Windows applications in the second computing device, and generate a launch shortcut for the corresponding application in the local desktop environment of the first computing device; S3. In response to the trigger command for the launch shortcut, send an application launch request to the second computing device and receive graphical update data returned by the second computing device at the single application window level. S4. Call the kernel-level virtual display driver to convert the graphics update data into a GPU shared texture object that can be recognized by the local desktop compositor, and submit the GPU shared texture object to the desktop compositor and the local application window for mixed rendering, and display it on the local desktop in the form of a native window; S5. Capture user input events for the native window, convert the absolute screen coordinates of the first computing device into relative coordinates relative to the native window, and send them to the second computing device to achieve interactive synchronization; at the same time, through the virtual USB host controller, intercept the USB request block (URB) of the physical USB port of the first computing device and transparently forward it to the second computing device to achieve seamless redirection of peripherals.

[0010] Furthermore, the dedicated USB bridging link has a built-in read-only EEPROM non-volatile memory chip, and the exclusive identifier includes a pre-programmed manufacturer identification code and a link type identification code; the verification step specifically includes: reading the identification information in the memory chip through a custom supplier instruction, and only when the read identification information matches the preset authorization information, the first computing device loads the corresponding kernel driver module.

[0011] Furthermore, after the virtual network interface is established, the traffic of the virtual network interface is restricted to be transmitted only between the first computing device and the second computing device through network namespaces or firewall rules, so as to achieve complete isolation between the point-to-point link and the external public network; and multiple independent logical channels are divided in the communication link, and independent QoS priorities are configured for each channel, with the real-time input channel having a higher priority than the graphics data channel.

[0012] Furthermore, the received single-application window graphics update data only includes the graphics change area within the window; the graphics update data adopts a hybrid encoding strategy: lossless compression is used for static text and GUI control elements within the window, while hardware-accelerated lossy encoding is used for dynamic video or 3D content within the window, and the encoding parameters are adjusted in real time according to the dynamic characteristics of the screen.

[0013] Furthermore, the transmission of the graphic update data is based on a lightweight transport layer constructed using UDP or SCTP protocols. This lightweight transport layer does not execute the congestion control logic of the TCP protocol and only performs immediate retransmission for detected packet loss.

[0014] Furthermore, the specific steps of graphics rendering fusion in step S4 include: the protocol client transmitting the graphics update data and window coordinate information to the virtual display driver through inter-process communication; the virtual display driver uploading the data to the GPU memory to generate the GPU shared texture object, and submitting the corresponding texture handle and window geometric attributes to the desktop compositor.

[0015] Furthermore, the desktop compositor manages the GPU shared texture object as an independent top-level window surface. When the native window is displayed, it has the same visual decoration effect as the local application window and supports drag, zoom, split screen, stacking and taskbar preview operations as the local application window. When the desktop compositor detects that the native window is minimized, it triggers the first computing device to send a command to the second computing device to stop graphics capture.

[0016] Furthermore, the triggering logic for the peripheral seamless redirection is as follows: the first computing device sends the device descriptor of the physical peripheral and the URB to the second computing device, which triggers the second computing device to dynamically load the corresponding virtual USB device driver and create a virtual device in the Windows operating system that is consistent with the physical peripheral parameters on the first computing device side to inject the URB.

[0017] Furthermore, the relative coordinates after coordinate transformation correspond one-to-one with the client area coordinates of the target application window on the second computing device side; and the first computing device and the second computing device perform link connectivity detection based on periodic heartbeat packets. When it is determined that multiple consecutive heartbeat timeouts have occurred, the following abnormal handling actions are performed: freezing the original window screen, overlaying a disconnection prompt watermark, suspending the USB redirection operation, and using an exponential backoff strategy to perform automatic reconnection.

[0018] Furthermore, the method also includes a collaborative control and security hardening mechanism belonging to the same system management dimension: when the first computing device performs a shutdown operation, a secure shutdown command is sent to the second computing device through an encrypted communication session, triggering the second computing device to execute a secure shutdown process; when the idle time of a Windows application is detected to exceed a preset threshold, a low-power command is sent to the second computing device, triggering the second computing device to enter a low-power state; the encrypted communication session establishes an end-to-end encrypted tunnel based on two-way authentication and key exchange, all business data are transmitted through the encrypted tunnel, and the second computing device is configured as an application running container without external network access permissions.

[0019] Compared with existing technologies, this invention addresses the core pain points of running x86 architecture Windows applications on domestic non-x86 platforms in the context of information technology innovation. It proposes a heterogeneous desktop convergence architecture with hardware and software collaboration, effectively overcoming inherent shortcomings of existing technologies such as difficulty in balancing compatibility and performance, fragmented user experience, high deployment and maintenance costs, poor compatibility with industry-specific peripherals, and strong network dependence. This results in the following significant and beneficial technical effects: This invention offloads the computational workload of Windows applications to a native x86 architecture secondary computing device for execution. It eliminates the need for dynamic instruction translation, system API conversion, and the deployment of a heavy virtualization stack on the domestic host machine. It is fully compatible with various applications within the x86-Windows ecosystem, including commercial software and industry-specific applications that heavily rely on Windows kernel features, dedicated drivers, and high-performance graphics interfaces, thus fundamentally avoiding the compatibility limitations of the software compatibility layer. Simultaneously, the domestic host machine is only responsible for interface composition, input forwarding, and peripheral channel management, with no special requirements for the hardware virtualization capabilities of domestic CPUs. This effectively improves the performance degradation caused by insufficient virtualization support of domestic chips. While ensuring good application compatibility, it achieves extremely low host resource consumption, solving the industry pain point in existing technologies where "good compatibility leads to high performance degradation, and performance targets are met but compatibility is insufficient."

[0020] This invention employs a graphics capture and transmission mechanism at the single application window level, abandoning the redundant design of traditional remote desktop whole-screen frame transmission. Combined with a hybrid encoding strategy of lossless compression of static content and hardware-accelerated encoding of dynamic content, along with a lightweight transmission layer built on UDP or SCTP protocols, it significantly reduces transmission bandwidth consumption and interaction latency. Simultaneously, through a kernel-level virtual display driver, it converts the graphics data of the remote application window into GPU-shared texture objects that can be directly recognized by the local desktop compositor, and synchronously blends and renders them with the local application window. This gives Windows application windows consistent visual effects and window management capabilities with local applications, including drag-and-drop, scaling, split-screen, cascading, taskbar preview, and other common operations, effectively eliminating the fragmented experience caused by the "single large nested window" of traditional remote desktops. Users do not need to perceive the underlying differences between the two systems to achieve unified operation across ecosystem applications, greatly reducing user learning costs and improving cross-system office efficiency.

[0021] This invention employs a dedicated USB bridging link to achieve point-to-point direct connection between domestically produced hosts and coprocessing units. Through a built-in dedicated identifier pre-verification mechanism, it enables automatic driver loading, automatic link configuration, and automatic network isolation activation. Users are not required to perform complex network settings or virtualization environment deployments, making it easy to operate and deployable even for ordinary users without specialized technical backgrounds. Furthermore, this solution adopts a distributed architecture of "one machine, one box," eliminating the need for centralized VDI server clusters, connection proxies, or other dedicated infrastructure. It avoids high initial hardware investment and ongoing cluster maintenance costs, allowing enterprises to flexibly deploy and upgrade individual units as needed. It is particularly suitable for application scenarios such as distributed offices and mobile operations, which are difficult to cover with traditional solutions, significantly reducing the implementation threshold and lifecycle maintenance costs for domestically developed terminals.

[0022] This invention, through a kernel-level virtual USB host controller, enables low-level interception and transparent forwarding of USB Request Blocks (URBs) on the physical USB ports of domestically produced hosts. Combined with a dedicated peripheral virtualization channel, it can completely map various USB peripherals connected to domestically produced hosts into the Windows environment of a second computing device. This solution not only supports common peripherals such as keyboards, mice, printers, and scanners, but also adapts to non-standard industry-specific peripherals that rely on dedicated drivers, such as bank USB tokens, industrial data acquisition cards, medical imaging equipment, and dedicated dongles. It solves the core pain points of existing technologies, such as complex peripheral redirection configurations, poor compatibility, and difficulty in supporting dedicated hardware, thus clearing obstacles for the migration of industry-specific business applications to domestic IT infrastructure.

[0023] In this invention, both computational tasks and business data are stored locally and run within the coprocessing unit. Interface rendering and interactive control data are transmitted only via a dedicated USB direct link, significantly reducing reliance on public networks. This effectively solves the problems of traditional VDI solutions, such as strong network dependence, drastic drop in user experience during network fluctuations, and inability to function properly in offline scenarios. It is adaptable to field operations, mobile offices, and edge scenarios with unstable networks. Furthermore, the domestically produced host and coprocessing unit operate through a dedicated isolated link. System crashes, virus attacks, and update anomalies in the Windows environment will not affect the stable operation of the domestically produced host system, achieving fault isolation between the two systems and significantly improving the overall operational reliability of the business system.

[0024] This invention achieves end-to-end security protection for control signaling, graphical data, and peripheral data streams through dedicated link pre-verification, two-way authentication of communication sessions, and end-to-end encrypted tunnels, reducing the risk of leakage during data transmission. At the same time, the coprocessing unit can be configured as an application runtime container without external network access, effectively isolating it from the public network and significantly reducing the security attack surface. It avoids the security risks of remote attacks and data leakage from the architectural level, and complies with the network security level protection compliance requirements and data security management specifications under the domestic IT innovation scenario.

[0025] This invention, through an innovative hardware and software co-engineering architecture, provides a Windows application runtime solution for domestic platforms that is highly compatible, offers a smooth user experience, is easy to deploy, cost-effective, and secure, without relying on domestically produced chip hardware virtualization capabilities, changing user habits, or requiring the construction of complex backend systems. It can effectively support the large-scale deployment of domestic operating systems in core business scenarios. Attached Figure Description

[0026] Figure 1 This is a flowchart of the heterogeneous desktop fusion method based on software and hardware collaboration of the present invention.

[0027] Figure 2This is a schematic diagram of the data flow and collaborative system architecture of the host kernel module of the present invention. Detailed Implementation

[0028] Example 1 like Figure 1 As shown, this embodiment provides a heterogeneous desktop integration method based on hardware and software collaboration. A typical application scenario for this embodiment is the migration of domestically produced office and industry business to domestic solutions. The first computing device is a desktop terminal equipped with domestic CPUs such as Phytium, Kunpeng, and Loongson, and a domestic operating system such as UnionTech UOS or Kylin. The second computing device is an embedded coprocessor equipped with an x86 low-power processor and a pre-installed simplified version of Windows operating system. The two devices communicate directly point-to-point via a dedicated USB bridge link. This method is applied to the first computing device running a non-x86 architecture domestic operating system. The first computing device communicates with the second computing device running an x86 architecture Windows operating system via a dedicated USB bridge link, including the following steps: S1. In response to the access event of the dedicated USB bridging link, verify the exclusive identifier built into the dedicated USB bridging link through the vendor's custom instruction, and after the verification is successful, synchronously create a dedicated point-to-point communication virtual network interface and a virtual USB host controller in the kernel mode of the first computing device.

[0029] This step is the core of the link initialization process in the entire method. Unlike existing technologies where users need to manually configure IP addresses, install corresponding drivers, and divide network partitions after connecting ordinary USB devices and Ethernet cables, this method automatically determines the legitimacy of the link through predefined dedicated identifier verification. At the same time, two functionally independent virtual channels are created synchronously in kernel mode, separating the data communication and peripheral control transmission links at the underlying level to avoid mutual interference between the two types of data streams. The virtual network interface is used to carry the transmission of graphics, audio, and control signaling, while the virtual USB host controller is used to carry the underlying forwarding of peripheral data streams. The two are isolated from each other and do not affect each other, realizing plug-and-play dedicated links from the bottom layer. Users do not need professional network and driver configuration knowledge, which greatly reduces the threshold for using the solution. At the same time, through the dual-channel kernel mode isolation design, low-latency transmission of graphics interaction is guaranteed, and the occupation and interference of peripheral data streams on the interaction channel are avoided, laying the architectural foundation for smooth interaction and stable peripheral adaptation.

[0030] S2. Establish an encrypted communication session with the second computing device through the virtual network interface, obtain a list of runnable Windows applications in the second computing device, and generate a launch shortcut for the corresponding application in the local desktop environment of the first computing device.

[0031] This step is the application layer integration of the two systems. The establishment of the encrypted communication session is based on a point-to-point direct connection channel at the link layer, without going through the public network or office LAN. After the session is established, the application list obtained is the Windows business applications pre-installed on the second computing device that users can directly call. The generated startup shortcuts are synchronously distributed in the desktop, start menu and application launcher of the domestic system, which is completely consistent with the entry form of local applications in the domestic system. Through the native integration of application shortcuts, the sense of separation between the operation entry points of the two systems is eliminated. Users do not need to switch between two independent system desktops and remote windows. They can simply click the shortcut to launch the Windows application as if opening a local application. This greatly reduces the user's learning cost and operation complexity, and realizes the unified management of application entry points of the two systems.

[0032] S3. In response to the trigger command for the launch shortcut, send an application launch request to the second computing device and receive graphical update data returned by the second computing device at the single application window level.

[0033] This step is the core of application startup and graphics transmission. Unlike the traditional remote desktop protocol that captures and transmits the entire desktop screen, in this step, the second computing device only captures the screen content of a single application window launched by the user. It only transmits the updated area's graphics data when the window screen changes, rather than continuously transmitting the entire desktop frame. This reduces the transmission of invalid data from the source. By capturing and transmitting at the granular level of a single application window, the amount of graphics data that needs to be transmitted is significantly reduced, lowering the bandwidth consumption. At the same time, it shortens the time spent on encoding, transmitting, and decoding graphics data, effectively reducing screen transmission latency. This provides a data foundation for subsequent smooth screen rendering and solves the problems of high bandwidth consumption and high latency caused by traditional remote desktop full-screen transmission.

[0034] S4. Call the kernel-level virtual display driver to convert the graphics update data into a GPU shared texture object that can be recognized by the local desktop compositor, and submit the GPU shared texture object to the desktop compositor and the local application window for mixed rendering, and display it on the local desktop in the form of a native window.

[0035] This step is the core of achieving seamless desktop integration. Unlike existing technologies that nest remote desktop images within user-mode application windows, this step directly connects to the graphics subsystem of the domestic system through a kernel-level virtual display driver. The received graphics data is directly uploaded to the GPU memory to generate shared textures, eliminating the need for multiple memory copies between user and kernel modes. The local desktop compositor then synchronously blends and renders this texture with the local application window's image before outputting it to the physical display. This kernel-level driver and GPU-shared texture design significantly improves graphics rendering efficiency and avoids screen tearing and stuttering. Simultaneously, the native blending rendering of the local desktop compositor ensures that Windows application windows have rendering logic completely consistent with local applications, visually eliminating the difference between remote and local windows. This achieves deep integration of heterogeneous application windows with the local desktop environment, solving the problem of fragmented experience in traditional remote desktops.

[0036] S5. Capture user input events for the native window, convert the absolute screen coordinates of the first computing device into relative coordinates relative to the native window, and send them to the second computing device to achieve interactive synchronization; at the same time, through the virtual USB host controller, intercept the USB request block (URB) of the physical USB port of the first computing device and transparently forward it to the second computing device to achieve seamless redirection of peripherals.

[0037] This step is the core of achieving bidirectional interactive collaboration, and it consists of two parallel interaction paths: the first is the synchronization of user input events. For operations using input devices such as keyboards, mice, and styluses, the coordinate system is first transformed, and then the data is sent to the second computing device in real time through a high-priority channel to ensure the accuracy and real-time performance of the operation. The second is the low-level forwarding of peripheral data streams. The kernel-mode driver directly intercepts the URB data of the physical USB port, without needing to go through user-mode protocol conversion, and directly transmits it to the second computing device, ensuring the integrity and real-time performance of peripheral data transmission. Through precise coordinate transformation, the positioning accuracy of user operations is guaranteed, avoiding the cursor offset and click misalignment problems common in traditional remote desktops, and achieving a consistent and responsive operation experience with local applications. Through kernel-level URB interception and transmission, the underlying seamless adaptation of USB peripherals is achieved, eliminating the need to develop dedicated redirection drivers for specific peripherals. This provides underlying support for the compatibility and adaptation of various industry-specific peripherals and solves the core pain point of poor peripheral redirection compatibility in existing technologies.

[0038] As one implementation method, the dedicated USB bridging link in this embodiment has a built-in read-only EEPROM non-volatile memory chip, and the exclusive identifier includes a pre-programmed manufacturer identification code and a link type identification code; the verification step specifically includes: reading the identification information in the memory chip through a custom supplier instruction, and only when the read identification information matches the preset authorization information, the first computing device loads the corresponding kernel driver module.

[0039] The read-only EEPROM chip can be a 24C02 series chip. The pre-programmed manufacturer identification code and link type identifier code are fixed-length hexadecimal values. The custom supplier instruction is the GET_CABLE_INFO instruction that conforms to the USB protocol specification and will not conflict with USB standard instructions. Only after the verification is successful will the host load the kernel driver module corresponding to the virtual network and virtual USB. Otherwise, the link will be identified as a regular USB device and the subsequent link creation operation will not be performed. Through low-cost hardware design, automatic identification and legality verification of dedicated links are achieved, eliminating the need for users to manually install drivers and configure link parameters, truly realizing plug-and-play functionality. At the same time, through predefined authorization identifier verification, unauthorized third-party cables and devices can be prevented from accessing the network, ensuring the underlying security of the communication link, avoiding the risk of data leakage caused by unauthorized device access, and improving the security and ease of use of the solution.

[0040] As one implementation method, after the virtual network interface is established in this embodiment, the traffic of the virtual network interface is restricted to be transmitted only between the first computing device and the second computing device through network namespaces or firewall rules, so as to achieve complete isolation between the point-to-point link and the external public network; and multiple independent logical channels are divided in the communication link, and independent QoS priorities are configured for each channel, wherein the priority of the real-time input channel is higher than that of the graphics data channel.

[0041] The virtual network interface is assigned an IP address within the local network segment. Through Linux system network namespaces or iptables firewall rules, traffic from this interface is prevented from being routed to the host's physical network card, ensuring that communication traffic between the two machines is transmitted in a closed loop within the dedicated link. Simultaneously, traffic control tools configure independent QoS priorities for different logical channels. The real-time channel corresponding to user input events has the highest priority, ensuring the real-time performance of keyboard and mouse operations; the graphics data channel has the second highest priority; and non-real-time channels such as file transfers have the lowest priority. This network isolation design avoids IP conflicts and traffic interference between the dedicated link and the office network or public network, ensuring link transmission stability and low latency. It also achieves physical isolation between the second computing device and the public network at the network level, reducing the security attack surface. QoS priority scheduling ensures the real-time performance of user interactions, avoiding operation lag and cursor delay caused by high-bandwidth graphics and file transfers, significantly improving the user experience.

[0042] As one implementation method, the single application window graphics update data received in this embodiment only includes the graphics change area within the window; the graphics update data adopts a hybrid encoding strategy: lossless compression is used for static text and GUI control elements within the window, while hardware-accelerated lossy encoding is used for dynamic video and 3D content within the window, and the encoding parameters are adjusted in real time according to the dynamic characteristics of the screen.

[0043] The system identifies changing regions in the graphics using a frame difference algorithm, encoding and transmitting only the rectangular areas that change in the image, while not transmitting unchanged content. In the hybrid encoding strategy, static text and GUI controls use PNG lossless compression to ensure the clarity of text and interface elements, while dynamic videos and 3D images are compressed using H.264 or H.265 hardware encoders. Simultaneously, the encoding bitrate and GOP length are adjusted in real-time according to the motion amplitude of the image. In high-speed motion scenes, the bitrate is automatically increased and the GOP length is shortened to reduce image latency and tearing. Through changing region identification and the hybrid encoding strategy, the system significantly reduces the amount of graphic data that needs to be transmitted while ensuring the clarity of static interfaces and the smoothness of dynamic images. This reduces bandwidth usage and encoding / decoding time, ensuring the display accuracy of office documents and software interfaces while meeting the smoothness requirements of dynamic scenes such as video playback and 3D modeling. It achieves a balance between clarity and smoothness, solving the problem of traditional encoding schemes where clarity results in stuttering or smoothness results in blurriness.

[0044] As one implementation method, the transmission of the graphic update data in this embodiment is based on a lightweight transport layer constructed using UDP or SCTP protocols. The lightweight transport layer does not execute the congestion control logic of the TCP protocol and only performs immediate retransmission for detected packet loss data.

[0045] Unlike TCP, which is designed for wide area networks and unreliable links, this solution is based on a stable, low-error-rate link via dedicated USB direct connection. It uses UDP or SCTP to build a lightweight transport layer, abandoning the complex sliding window, congestion control, and slow start mechanisms of TCP. It only performs immediate retransmission on lost data detected by verification, significantly reducing protocol header overhead and transmission latency. It has made deep optimizations to the transport layer for dedicated point-to-point direct connection scenarios, abandoning redundant mechanisms in TCP that are not suitable for local direct connection scenarios, greatly reducing protocol overhead and transmission latency, and improving the transmission efficiency of graphic data. At the same time, the extremely simple packet loss retransmission mechanism ensures the reliability of data transmission. It achieves sub-millisecond transmission latency and avoids screen tearing and missing issues caused by data loss, perfectly adapting to dedicated local direct connection scenarios.

[0046] As one implementation method, the specific steps of graphics rendering fusion in step S4 of this embodiment include: the protocol client transmits the graphics update data and window coordinate information to the virtual display driver through inter-process communication; the virtual display driver uploads the data to the GPU memory to generate the GPU shared texture object, and submits the corresponding texture handle and window geometric attributes to the desktop compositor.

[0047] The protocol client and the virtual display driver use UnixDomainSocket for inter-process communication, which is more efficient than traditional network sockets. The GPU shared texture object is implemented using the DRMPMrime mechanism, which directly uploads the decoded graphics data to the GPU memory without the need for memory copying between user space and kernel space. The generated shared texture handle can be directly recognized and called by the Wayland or X11 desktop compositor of domestic systems. Through efficient inter-process communication and the zero-copy mechanism of GPU memory, the rendering efficiency of graphics data is greatly improved, the performance loss and latency caused by memory copying are reduced, and screen tearing and stuttering problems are avoided. At the same time, by connecting to the desktop compositor through standard texture handles, there is no need to modify the desktop environment and graphics subsystem of domestic systems. It has strong versatility and can be adapted to all mainstream domestic operating systems, reducing the adaptation cost of the solution.

[0048] As one implementation method, the desktop compositor in this embodiment manages the GPU shared texture object as an independent top-level window surface. When the native window is displayed, it has the same visual decoration effect as the local application window and supports drag, zoom, split screen, stacking and taskbar preview operations as the local application window. When the desktop compositor detects that the native window is minimized, it triggers the first computing device to send a command to the second computing device to stop graphics capture.

[0049] The visual effects of Windows application windows, such as borders, shadows, transparency, and window animations, are all uniformly drawn by the window manager of the domestic system, completely adhering to the same system theme rules as local application windows. The desktop compositor manages this window as an independent top-level surface, supporting the native window operation logic of the domestic system, including drag and drop, split screen, multi-monitor adaptation, taskbar thumbnail preview, etc. When the window is minimized, the second computing device is simultaneously notified to stop the window's graphics capture and encoding, eliminating the need to transmit invalid data. This achieves deep integration of Windows application windows with the local desktop environment, making it completely indistinguishable from local applications in terms of visual effects and window operation logic. It completely eliminates the sense of separation of nested windows in traditional remote desktop windows, and users do not need to change their original operating habits. At the same time, the mechanism of stopping capture when minimized significantly reduces the bandwidth and CPU resource consumption of background applications, reduces the performance consumption of the host and coprocessor units, and improves the system resource utilization.

[0050] As one implementation method, the triggering logic for the peripheral seamless redirection in this embodiment is as follows: the first computing device sends the device descriptor of the physical peripheral and the URB to the second computing device, which triggers the second computing device to dynamically load the corresponding virtual USB device driver and create a virtual device in the Windows operating system that is consistent with the physical peripheral parameters on the first computing device side to inject the URB.

[0051] The transparently transmitted device descriptor contains complete information such as the physical peripheral's vendor ID, product ID, configuration descriptor, and interface descriptor. The virtual USB device created by the second computing device based on this descriptor has completely identical hardware parameters to the physical peripheral. The Windows system can directly load the original driver for this peripheral without secondary development and adaptation. The URB data intercepted on the host side is completely transparently transmitted to the virtual device, realizing bidirectional and seamless interaction of peripheral data. Through the complete transparent transmission of device descriptors and URB underlying forwarding, seamless adaptation of all types of USB peripherals is achieved. It not only supports general peripherals such as keyboards, mice, and printers, but also perfectly adapts to industry-specific peripherals that rely on original drivers, such as bank U-shields, industrial data acquisition cards, medical imaging equipment, and dedicated dongles. There is no need to develop dedicated redirection drivers for specific peripherals, which greatly reduces the adaptation cost of domestic migration of industry applications and removes the core obstacle of peripheral adaptation in the implementation of domestic IT innovation.

[0052] As one implementation method, the relative coordinates after coordinate transformation in this embodiment correspond one-to-one with the client area coordinates of the target application window on the second computing device side; and the first computing device and the second computing device perform link connectivity detection based on periodic heartbeat packets. When it is determined that the heartbeat timeout occurs multiple times in a row, the following abnormal handling actions are performed: freezing the original window screen, overlaying the disconnection prompt watermark, suspending the USB redirection operation, and performing automatic reconnection using an exponential backoff strategy.

[0053] During the coordinate transformation process, non-client areas such as the window title bar and borders are excluded, and the absolute coordinates of the host screen are accurately converted into the relative coordinates of the application window's client area, perfectly matching the window coordinate system on the second computing device side. Heartbeat detection uses a periodic sending of once per second; if no response is received after three consecutive attempts, the link is considered interrupted. During anomaly handling, the window screen is frozen to prevent user misoperation, and reconnection is performed using exponential backoff intervals of 1s, 2s, 4s, and 8s, with a maximum reconnection interval of no more than 32s. This precise coordinate system transformation ensures the positioning accuracy of user operations, avoiding issues such as cursor misalignment, misclicks, and menu triggering anomalies, achieving a precise interactive experience consistent with the local application. Through heartbeat detection and anomaly handling mechanisms, a rapid response is possible in case of link anomalies, preventing data loss due to application unresponsiveness or user misoperation. Furthermore, the exponential backoff reconnection strategy reduces the system resource consumption of invalid reconnections, improving system stability and fault tolerance, and ensuring business continuity.

[0054] As one implementation method, the method in this embodiment also includes a collaborative control and security hardening mechanism belonging to the same system management dimension: when the first computing device performs a shutdown operation, a secure shutdown command is sent to the second computing device through an encrypted communication session, triggering the second computing device to execute a secure shutdown process; when the idle time of a Windows application is detected to exceed a preset threshold, a low-power command is sent to the second computing device, triggering the second computing device to enter a low-power state; the encrypted communication session establishes an end-to-end encrypted tunnel based on two-way authentication and key exchange, all business data are transmitted through the encrypted tunnel, and the second computing device is configured as an application running container without external network access permissions.

[0055] When the host computer shuts down, it first sends a secure shutdown command to the coprocessor unit. After the Windows system completes the normal shutdown process, the host computer then performs the shutdown operation, avoiding system file corruption and data loss caused by forced power outages. The idle timeout threshold can be customized by the user, with a default low-power sleep mode triggered after 30 minutes of inactivity. The encrypted tunnel uses the AES-256 symmetric encryption algorithm, and two-way authentication is completed based on a pre-configured digital certificate. The coprocessor unit disables its physical network card and communicates with the host only through a dedicated USB link, completely preventing access to the external network. Through the lifecycle collaborative management of the dual systems, the secure startup and shutdown of the Windows system is ensured, avoiding data loss and system damage. At the same time, the low-power management mechanism reduces the idle power consumption of the coprocessor unit, meeting the requirements of green office. Through two-way authentication and end-to-end encrypted tunnels, full-link security protection for business data is achieved. Furthermore, the containerized configuration of the coprocessor unit without external network access eliminates the security risks of remote attacks and data leakage at the architectural level, fully complying with the network security level protection compliance requirements and data security management specifications under the domestic IT innovation scenario.

[0056] Example 2 This embodiment provides a heterogeneous desktop integration method based on hardware and software collaboration. The corresponding host kernel module data flow and collaborative system architecture diagram are shown below. Figure 2 As shown. This embodiment introduces a lightweight dedicated Windows hardware coprocessor unit that is deeply integrated with the local domestic system host to build a seamless hybrid computing environment, enabling transparent and smooth operation of natively unsupported Windows applications on the domestic system.

[0057] The heterogeneous desktop convergence system described in this embodiment consists of three parts: a domestically produced system host, a Windows coprocessor unit, and an intelligent bridging link connecting the two. The domestically produced system host runs an operating system based on domestically produced chips; the Windows coprocessor unit is a miniaturized, embedded computing device running a complete Windows operating system; the intelligent bridging link includes a physical connection to a proprietary, optimized remote desktop protocol stack running at both ends, specifically a data cable with a built-in USB-to-network chip. From the user's perspective, all applications, including Windows applications, are presented in a unified window on the domestically produced system desktop.

[0058] The specific implementation steps of this embodiment are as follows: Step 1: Construct a dedicated hardware coprocessor unit and its connections; A dedicated Windows coprocessor unit hardware was designed and manufactured. This unit utilizes a low-power embedded motherboard based on the x86 architecture, integrating the necessary CPU, memory, and solid-state storage, and pre-installed with a streamlined version of the Windows operating system. This unit connects to the domestically produced system host via a USB 3.0 / 2.0 to Ethernet cable. Its physical interface on the host side appears as a USB port, functioning as a host peripheral. Functionally, this connection simultaneously achieves: Network connectivity: The built-in USB to Ethernet chip in the data cable creates a virtual, high-bandwidth private LAN link between the host and the coprocessor unit. This link is completely independent of the host's original physical network, avoiding network configuration conflicts and interference from public network traffic. Device Channel: Provides an underlying channel for subsequent peripheral redirection via the USB protocol.

[0059] This design ensures extreme simplicity in connectivity; users can simply plug and play without needing to understand complex hardware knowledge and protocol configurations.

[0060] Step 1.1 Basic identification and establishment process of dedicated cables and links; 1. Electrical identification of dedicated cables At the USB interface end of the cable, a read-only EEPROM chip is integrated. This chip is pre-programmed with a specific manufacturer ID and cable type identification code, where the manufacturer ID is 0xA5A5 and the cable type identification code 0x01 indicates a high-speed data cable.

[0061] After detecting the insertion of a device, the USB host controller driver on the domestic host side first executes the standard USB enumeration process, and then initiates a custom vendor-specific command, specifically the GET_CABLE_INFO command, to read the identifier code in the EEPROM.

[0062] The host driver will only recognize the cable as a legitimate dedicated cable after receiving the correct manufacturer ID and type identification code, and then continue to load the subsequent virtual network and virtual USB drivers. The entire process of recognition and driver loading is completed within 500 milliseconds after insertion.

[0063] 2. Establishment and isolation of private links After successful identification, the host kernel module will create a virtual Ethernet interface for this USB link, specifically vboxnet0, and assign it a fixed link-local IP address, specifically [169.254.100.1 / 30](169.254.100.1 / 30). The Windows coprocessor unit will be assigned an address in the same network segment, [169.254.100.2](169.254.100.2).

[0064] By configuring the kernel's NetworkNamespace or firewall rules iptables, it is ensured that all traffic destined for vboxnet0 will not be routed to the host's physical network interface card, including eth0 or wlan0, thus achieving a physical-layer point-to-point direct connection and keeping loop latency stably within 0.1ms.

[0065] Step 2: Encapsulation of domestically developed system-side drivers and virtualization presentation layers; On a domestically developed system host, a core kernel module and user-space services are developed and installed. The kernel module is responsible for identifying the aforementioned dedicated data lines and virtualizing them as one or more standard virtual network interfaces and virtual USB host controllers. The user-space services include the following key components: Protocol Client: The client part that implements the private remote desktop protocol is responsible for establishing an encrypted communication session with the coprocessor unit, receiving audio and video streams and peripheral commands, and sending input events; Virtual display driver: Creates a virtual display adapter. This driver does not generate real graphics frames. Instead, it mixes and renders the Windows application window graphics data received by the protocol client from the coprocessor unit with other local application windows through the operating system's graphics compositor. Finally, it outputs the data to the physical display, so that the Windows application windows on the domestic desktop have the same visual effects as the local windows, including shadows, transparency, and animation effects. Application Dock / Launcher: A service or front-end interface that resides in the background and is used to enumerate the Windows applications available on the coprocessor unit and create corresponding shortcuts in the Start Menu, desktop, or launcher of the domestic system. When users click on these shortcuts, it is no different from launching local applications.

[0066] Step 2.2 Boundaries of Responsibilities of Host Kernel Modules; 1. Data Carrying and Flow: Virtual network interface vboxnet0: mainly carries display compressed data streams, including H.264 / HEVC encoded window image differential data, audio streams, and control signaling, including application start / close and window movement commands; among them, the display data stream has the highest priority and is marked as real-time interactive traffic by setting QoS.

[0067] Virtual USB host controller: It mainly carries peripheral I / O data packets. Its driver intercepts USB request blocks (URBs) sent to specific physical ports, packages them, and forwards them to the coprocessor unit through the peripheral channel of the private protocol. For example, interrupt transmission messages of USB mice are mapped in real time.

[0068] 2. Collaboration and Exception Handling Logic: Normal Collaboration: The virtual network interface is responsible for transmitting display results, and the virtual USB interface is responsible for transmitting user input events. The two are associated through a shared SessionID. For example, when the user moves the mouse within the window, the input event is sent via the virtual USB channel, the Windows application responds and updates the cursor position, and the display update is returned via the virtual network channel.

[0069] Disconnection Handling: The kernel module initiates a heartbeat detection mechanism, specifically pinging once per second. If three consecutive heartbeats time out (i.e., no response for 3 seconds), a disconnection is determined. The kernel module immediately performs the following operations: sends a signal to the virtual display driver, freezes the application window, and overlays a watermark indicating a connection interruption on the window; suspends all ongoing USB redirection operations and sends a disconnection event to the user-space service process; attempts to automatically reconnect using an exponential backoff strategy, with intervals of 1 second, 2 seconds, 4 seconds, etc., until the cable is securely reconnected or the coprocessor restarts.

[0070] The data flow and coordination logic of the host kernel module in this step are as follows: Figure 2 As shown, Figure 2 The described workflow logic is as follows: After the host kernel module is loaded, it first identifies a legitimate dedicated cable via a dedicated USB link and simultaneously creates two independent channels: a virtual network interface (vboxnet0) and a virtual USB host controller. The virtual network interface (vboxnet0) carries the display compressed data stream (H.264 / HEVC encoded window image differential data), audio stream, and control signals such as application startup / shutdown and window movement. It also marks the display data stream as QoS real-time interactive traffic to ensure the highest priority. The virtual USB host controller specifically carries peripheral I / O packets, intercepts USB request blocks (URBs) from specific physical USB ports on the host, and packages them for forwarding to the coprocessor unit via a private protocol peripheral channel. The two work together through a shared SessionID: user input events (such as keyboard and mouse operations) are sent to the coprocessor unit via the virtual USB channel, and the display update data generated by the Windows application response is transmitted back to the host via the virtual network channel. Meanwhile, the host kernel module starts a heartbeat detection mechanism once per second. If the heartbeat times out three times in a row (i.e. no response for 3 seconds), the disconnection process is immediately triggered: the application window is frozen and a "connection interrupted" watermark is superimposed, the USB redirection operation is suspended, a disconnection event is sent to the user space service process, and then an automatic reconnection is performed with an exponential backoff strategy of 1s, 2s, 4s... until the link is restored to normal.

[0071] Step 3: Implementation of a proprietary, high-efficiency remote desktop protocol; One of the core features of this embodiment is a proprietary remote desktop protocol optimized for one-to-one, short-distance, wired direct connection scenarios, rather than the standard RDP or VNC protocol. This protocol has been deeply optimized in the following aspects: 1. Graphics Encoding: A hybrid encoding strategy is employed. For static desktop areas, text, and GUI controls, lossless compression or high-efficiency vector instruction replay is used to ensure interface clarity and color accuracy. For dynamic areas such as video, animation, and 3D graphics, a hardware-accelerated modern video encoder is used. The protocol client and server can dynamically negotiate and utilize the available encoding hardware on both ends, significantly reducing CPU usage and transmission latency. The protocol transmits not the entire desktop frame, but rather the graphically changing areas of a single application window, greatly reducing the amount of data that needs to be transmitted.

[0072] 2. Input and Event Channel: Establish a high-priority bidirectional channel to transmit input events from the domestic system host, such as keyboard, mouse, touch, and stylus, to the corresponding Windows application window in the coprocessing unit with extremely low latency and precise coordinate mapping; at the same time, synchronize information such as cursor shape and touch feedback from the Windows application back to the domestic host in real time.

[0073] 3. Audio Redirection: Bidirectional audio stream redirection, supporting audio output from Windows applications to the sound card of domestic host machines, and also supporting microphone input from domestic systems to be used by Windows applications.

[0074] 4. Peripheral Virtualization Channel: The protocol establishes a dedicated general-purpose peripheral virtualization channel. This channel allows the device descriptors and data streams of specific USB devices connected to domestic host computers, including USB tokens, printers, scanners, dongles, industrial data acquisition cards, etc., to be securely and transparently redirected to the coprocessor unit. This enables Windows applications in the coprocessor unit to recognize and drive these devices as if they were directly connected, which is key to supporting industry-specific applications.

[0075] Step 3.1: Explanation of the protocol layer's location; 1. Lightweight trade-offs in protocol stack: Abandoning complex network adaptability algorithms, since it is based on stable, high-speed wired direct connection, the protocol stack does not need to include the complex congestion control or forward error correction mechanism of the TCP protocol. Reliable transmission can be built directly on top of UDP, or a lighter, connection-oriented SCTP protocol can be used to reduce protocol header overhead; the retransmission mechanism only performs immediate retransmission for a very small number of packet losses.

[0076] 2. Control plane and data plane division: The control plane is extremely streamlined, only responsible for session establishment / destruction, application startup commands, and peripheral connection announcements. It adopts the lightweight text format JSON, which is easy to parse.

[0077] Data plane: It is divided into ultra-real-time channel, including input events and cursor position, and high-throughput channel, including graphics, audio and large file transfer; the former uses unacknowledged UDP broadcast with a latency of <10ms, while the latter uses acknowledged reliable transmission with a fixed large window size to make full use of bandwidth.

[0078] 3. Overall approach to content processing strategy: Static content, including text and GUI controls: uses a self-developed differential algorithm or lossless compression, specifically PNG compression, to identify changing rectangular areas in the image and transmit only the image of that area. For completely unchanging interface elements, more than 90% of bandwidth can be saved in one frame.

[0079] Dynamic content, including video and animation: uses hardware encoders, including NVENC and QuickSyncVideo, for real-time encoding. The target bitrate and GOP length of the encoder can be dynamically adjusted. When a high-speed motion scene is detected, the bitrate is automatically increased and the GOP is shortened to reduce latency and screen tearing.

[0080] Step 4: Coprocessor unit-side server software framework; On the Windows coprocessor unit, a resident system service runs automatically at system startup. Its main functions include: Protocol server: Listens for connection requests from dedicated data links, establishes secure communication sessions with domestic hosts, and manages image capture, input injection, audio redirection, and peripheral mapping.

[0081] Dynamic Session and Window Management: When receiving an application launch request from a domestic host, this service can automatically launch the specified Windows application and capture the content of the application window in a seamless window mode, rather than capturing the entire desktop, to ensure that less data is transmitted and to guarantee performance.

[0082] Graphics capture and encoding: Utilizes the Windows Graphics Subsystem Interface to efficiently capture the updated areas of application windows; for applications that support DirectX / OpenGL, GPU-accelerated capture methods can be used; the captured graphics data is encoded in real time according to protocol rules by calling the encoder.

[0083] Peripheral Host: Receives virtualized peripheral data streams from domestically produced host machines, dynamically creates corresponding virtual devices in the Windows system, injects the data streams, and makes Windows applications believe that the devices are locally connected.

[0084] Step 5: Startup and connection initialization process; 1. The user connects the domestic host and the Windows coprocessor unit with the dedicated data cable and powers on the coprocessor unit.

[0085] 2. The domestic host recognizes the new composite device, loads the dedicated kernel driver, and creates a virtual network interface vboxnet0 and a virtual USB host controller.

[0086] 3. The user-space service on the domestic host starts automatically and attempts to initiate a connection to the predefined link-local address via vboxnet0.

[0087] 4. The server on the coprocessor unit accepts the connection, and both parties exchange keys and authenticate each other to establish an encrypted tunnel.

[0088] 5. After successful authentication, the coprocessing unit server sends a list of currently available applications to the domestic host client. The domestic host application dock component receives the list and dynamically creates corresponding shortcut icons on the domestic system desktop. At this point, the system is ready.

[0089] Step 6: Seamless launch and rendering of Windows applications; 1. A user double-clicks a shortcut to a Windows application on the desktop of a domestic operating system.

[0090] 2. The application dock service sends this startup command to the server of the coprocessor unit via a private protocol.

[0091] 3. The coprocessor unit server starts the corresponding Windows application on the Windows side.

[0092] 4. The server captures the application window and transmits the initial window image, position, size, and other information back to the domestic host via a protocol.

[0093] 5. The virtual display driver of the domestic host receives the data, calls the graphics compositor, and draws the border and content of the application window at a specified position on the desktop. This window has standard window decorations, can be controlled by the theme of the domestic system, and supports operations such as maximizing, minimizing, dragging, and resizing.

[0094] 6. In terms of user visuals and interaction, this Windows application window is no different from the local application window of the domestic system.

[0095] Step 6.1 The path to integrate the virtual display driver with the desktop compositor; 1. The path from protocol to synthesizer: The protocol client receives image data of the Windows application window from the coprocessor unit, including RGB or YUV pixel data and its coordinates on the Windows desktop, including x, y, width, and height.

[0096] The client transmits image data and coordinate information to the virtual display driver via inter-process communication, specifically UnixDomainSocket. The virtual display driver then uploads this data to the GPU's video memory in kernel space or through a specific IOCTL interface, forming a shared texture object that is indistinguishable from the local texture.

[0097] The virtual display driver then sends a redraw event to the desktop compositor, including Wayland's Weston or Compton under X11, and informs it of the handle of the shared texture and the window's geometric properties.

[0098] 2. Implementation of window management: The compositor manages this texture as an independent, top-level window surface. When the user performs drag-and-drop or resizing operations, the compositor processes the surface's metadata, including its position and size; actual window content updates are initiated by the compositor requesting the virtual display driver, which then requests new image data from the coprocessor unit via a protocol.

[0099] The core difference between this solution and traditional full-screen remote desktop is that the traditional solution transmits the entire frame buffer of the remote desktop, and there is only one window on the local machine containing all remote applications; this solution creates an independent window object for each remote application in the local compositor, so it can seamlessly participate in local window stacking, splitting, taskbar preview and minimize animation. The minimize command is sent to the coprocessor unit to stop capturing the window, thereby saving bandwidth.

[0100] Step 7: Real-time synchronization of graphics rendering and interaction; 1. When a user operates a domestic operating system and moves the mouse into a Windows application window, the mouse pointer is intercepted by the virtual display driver.

[0101] 2. The absolute coordinates of the mouse are converted to coordinates relative to the application window, and together with mouse click and move events, are sent to the coprocessor unit through the low-latency input channel of the proprietary protocol.

[0102] 3. The coprocessor server injects the input event into the message queue of the Windows system. The corresponding Windows application responds to the input and updates its interface, including cursor blinking, text input, and menu pop-up.

[0103] 4. The server captures the updated area of ​​the application window, uses encoding strategies such as lossless compression for text areas and lossy fast encoding for newly inserted images, and sends the encoded graphic differential data back to the domestic host.

[0104] 5. The domestic host client decodes the data and notifies the virtual display driver to update the corresponding area in the window. The latency of the entire input-response-display loop is optimized to within tens of milliseconds, and the user perceives it as an instant response.

[0105] Step 8: Seamless redirection of peripherals; 1. The user inserts the bank's USB security token into the USB port of the domestic host computer.

[0106] 2. The user-mode service on the domestic host obtains the device descriptor and data communication endpoint information of the USB key through the virtual USB host controller channel.

[0107] 3. The service advertises the device descriptor to the coprocessor unit through the peripheral virtualization channel of the private protocol.

[0108] 4. The coprocessor unit server dynamically loads a virtual USB device driver in the Windows system and creates a virtual USB device that matches the original USB key descriptor.

[0109] 5. The Windows system automatically recognizes this new USB device and loads the corresponding driver. At this point, the USB key can be recognized normally in the Windows system of the coprocessor unit.

[0110] 6. Users can use this USB key for authentication when opening Windows online banking applications on domestic systems. All USB communication data is forwarded in real time between the physical host and the coprocessor unit through the protocol channel. For the application, the device is locally connected, while for the user, the device is plugged into the domestic host.

[0111] Step 9: System Resource and Lifecycle Management; The service on the domestic host provides a management interface that allows users to view the system status of the coprocessor, including CPU and memory usage, running applications, and remotely terminate applications or hibernate / wake up the coprocessor.

[0112] When there is no Windows application activity for a period of time, the protocol can automatically enter a low-bandwidth hold-up state, and the Windows in the coprocessor unit can enter a sleep state to save energy.

[0113] When a domestic host computer is powered off or its data cable is unplugged, the management service will send a shutdown command to the coprocessor to ensure that the Windows system shuts down properly and avoids data loss.

[0114] Step 10: Security and Isolation Mechanisms; The entire communication link is encrypted to prevent data leakage.

[0115] The coprocessor unit can be configured not to log in to any Windows account and only act as an application runtime container, reducing security risks.

[0116] The network connection between the domestic host and the coprocessor is an isolated point-to-point link, not exposed to the external network.

[0117] Compared with existing technologies, the solution described in this embodiment produces significant and synergistic beneficial effects, effectively solving the fundamental problem of running incompatible Windows applications in a domestic environment: 1. This solution overcomes the bottleneck of insufficient hardware virtualization support in domestically produced chips, achieving excellent application compatibility. Existing technologies are limited by the hardware architecture of domestically produced chips, either failing to achieve efficient virtualization and exhibiting poor compatibility layer performance, or suffering from high virtualization overhead, incomplete features, and inadequate hardware virtualization support. This solution creatively decouples the computation and presentation of Windows applications at the physical hardware level, completely offloading computational tasks to independent, native x86 architecture Windows coprocessor units. It fully inherits the application compatibility of the x86-Windows ecosystem, requiring no instruction translation or API conversion. The hardware characteristics of domestically produced chips no longer pose a compatibility obstacle. The domestic system host is only responsible for final interface composition, user input forwarding, and peripheral channel management. These tasks have no special hardware requirements and can be efficiently handled by existing domestically produced chips.

[0118] 2. Achieved a seamless integration of user experience and high performance. Compared to traditional remote desktops, this solution achieves deep integration through two key technologies: proprietary protocol optimization and virtual display driver. First, the proprietary protocol performs mixed encoding for application windows, static interfaces, and dynamic media, and utilizes a dedicated wired link to achieve high frame rate, low latency, and low bandwidth consumption, making the response speed of remote applications approach that of local applications. Second, the virtual display driver seamlessly embeds the remote application window into the local desktop compositor, making it completely consistent with the local window in terms of visual effects and window management, including overlaying, dragging, and minimizing to the taskbar. This breaks down the disconnect between the remote desktop and the local window, eliminating the user's awareness of the existence of two systems and achieving a unified experience of one desktop and two ecosystems.

[0119] 3. Significantly reduces deployment, usage, and maintenance costs and complexity. Compared to VDI solutions that require data centers and complex software stacks, this solution is a point-to-point model with one device per box, eliminating the need for network switches, servers, connection agents, and additional network configurations, achieving plug-and-play functionality. Enterprise procurement costs shift from centralized server investment to amortized terminal peripheral investment, offering flexible deployment, especially suitable for distributed and highly mobile scenarios. For users, operation is no different from using local applications, with extremely low learning costs; for IT administrators, there is no need to manage complex virtualization clusters and network policies, only the system image and pre-installed applications of the Windows coprocessor unit, significantly reducing maintenance workload compared to VDI solutions.

[0120] 4. Enhanced support for peripherals, especially dedicated hardware. Peripheral support for general remote desktop protocols is a weakness. This solution addresses this by using a general peripheral virtualization channel to provide basic support for USB device redirection at the protocol level. It not only emulates common input / output devices but, more importantly, transparently maps various USB devices connected to domestically produced hosts, including dedicated devices that rely on specific drivers, into the Windows environment. This allows industry software that must work with specific hardware dongles, card readers, and diagnostic devices to run smoothly on domestically produced systems, resolving the core pain point of migrating hardware-bound applications during the implementation of domestic IT solutions. This is something that software compatibility layers and standard virtualization solutions struggle to achieve.

[0121] 5. Enhanced flexibility and reliability. Since all computation and data processing, except for display and interactive streams, are localized on the coprocessor unit, this solution has extremely low network dependence, relying on only a single stable physical cable. This makes it ideal for offline work, mobile work, or use in environments with unstable networks. Furthermore, Windows environment crashes or updates typically do not affect the stability of the domestically produced host system; the two are isolated from each other, improving the overall system reliability.

[0122] This embodiment, through an innovative hardware and software co-processing architecture, organically combines dedicated coprocessing hardware, intelligent bridging links, and deeply optimized proprietary protocols. Without relying on domestically produced chip virtualization enhancements, changing user habits, or building complex backend systems, it bypasses the compatibility shortcomings of domestic platforms. It provides users with a Windows application solution that is highly compatible, offers a smooth experience, has high integration, is cost-controllable, and supports complex peripherals. It is an effective path to truly integrate domestically produced systems into core business scenarios.

[0123] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A heterogeneous desktop integration method based on hardware and software collaboration, applied to a first computing device running a non-x86 architecture domestic operating system, wherein the first computing device communicates with a second computing device running an x86 architecture Windows operating system via a dedicated USB bridge link, characterized in that: Including the following step: S1. In response to the access event of the dedicated USB bridging link, verify the exclusive identifier built into the dedicated USB bridging link through the vendor's custom instruction, and after the verification is passed, synchronously create a dedicated point-to-point communication virtual network interface and a virtual USB host controller in the kernel mode of the first computing device. S2. Establish an encrypted communication session with the second computing device through the virtual network interface, obtain a list of runnable Windows applications in the second computing device, and generate a launch shortcut for the corresponding application in the local desktop environment of the first computing device; S3. In response to the trigger command for the launch shortcut, send an application launch request to the second computing device and receive graphical update data returned by the second computing device at the single application window level. S4. Call the kernel-level virtual display driver to convert the graphics update data into a GPU shared texture object that can be recognized by the local desktop compositor, and submit the GPU shared texture object to the desktop compositor and the local application window for mixed rendering, and display it on the local desktop in the form of a native window; S5. Capture user input events for the native window, convert the absolute screen coordinates of the first computing device into relative coordinates relative to the native window, and send them to the second computing device to achieve interactive synchronization; at the same time, through the virtual USB host controller, intercept the USB request block (URB) of the physical USB port of the first computing device and transparently forward it to the second computing device to achieve seamless redirection of peripherals.

2. The method according to claim 1, characterized in that: The dedicated USB bridging link has a built-in read-only EEPROM non-volatile memory chip, and the exclusive identifier includes a pre-programmed manufacturer identification code and a link type identification code. The verification step specifically includes: reading the identification information in the storage chip through a custom supplier instruction; and loading the corresponding kernel driver module only when the read identification information matches the preset authorization information.

3. The method according to claim 1, characterized in that: After the virtual network interface is established, the traffic of the virtual network interface is restricted to be transmitted only between the first computing device and the second computing device through network namespaces or firewall rules, so as to achieve complete isolation between the point-to-point link and the external public network; and multiple independent logical channels are divided in the communication link, and independent QoS priorities are configured for each channel, with the real-time input channel having a higher priority than the graphics data channel.

4. The method according to claim 1, characterized in that: The received single-application window graphics update data only includes the graphics change area within the window; the graphics update data adopts a hybrid encoding strategy: lossless compression is used for static text and GUI control elements within the window, while hardware-accelerated lossy encoding is used for dynamic video or 3D content within the window, and the encoding parameters are adjusted in real time according to the dynamic characteristics of the screen.

5. The method according to claim 4, characterized in that: The transmission of the graphic update data is based on a lightweight transport layer constructed using UDP or SCTP protocols. This lightweight transport layer does not execute the congestion control logic of the TCP protocol and only performs immediate retransmission for detected packet loss.

6. The method according to claim 1, characterized in that: The specific steps of graphics rendering fusion in step S4 include: the protocol client transmits the graphics update data and window coordinate information to the virtual display driver through inter-process communication; the virtual display driver uploads the data to the GPU memory to generate the GPU shared texture object, and submits the corresponding texture handle and window geometric attributes to the desktop compositor.

7. The method according to claim 6, characterized in that: The desktop compositor manages the GPU shared texture object as an independent top-level window surface. When the native window is displayed, it has the same visual decoration effect as the local application window and supports drag, zoom, split screen, stacking and taskbar preview operations as the local application window. When the desktop compositor detects that the native window is minimized, it triggers the first computing device to send a command to the second computing device to stop graphics capture.

8. The method according to claim 1, characterized in that: The triggering logic for the seamless redirection of peripherals is as follows: the first computing device sends the device descriptor of the physical peripheral and the URB to the second computing device, which triggers the second computing device to dynamically load the corresponding virtual USB device driver and create a virtual device in the Windows operating system that is consistent with the physical peripheral parameters on the first computing device side to inject the URB.

9. The method according to claim 1, characterized in that: The relative coordinates after coordinate transformation correspond one-to-one with the client area coordinates of the target application window on the second computing device side; and the first computing device and the second computing device perform link connectivity detection based on periodic heartbeat packets. When it is determined that the heartbeat timeout occurs multiple times in a row, the following abnormal handling actions are performed: freeze the original window screen, overlay a disconnection prompt watermark, suspend the USB redirection operation, and perform automatic reconnection using an exponential backoff strategy.

10. The method according to claim 1, characterized in that: The method also includes a collaborative control and security hardening mechanism belonging to the same system management dimension: when the first computing device performs a shutdown operation, a secure shutdown command is sent to the second computing device through an encrypted communication session, triggering the second computing device to execute a secure shutdown process; when the idle time of a Windows application is detected to exceed a preset threshold, a low-power command is sent to the second computing device, triggering the second computing device to enter a low-power state; the encrypted communication session establishes an end-to-end encrypted tunnel based on two-way authentication and key exchange, and all business data is transmitted through the encrypted tunnel, and the second computing device is configured as an application running container without external network access permissions.

Images