An input device control switching method and device, electronic device, and storage medium

Abstract

This invention discloses an input device control switching method, apparatus, electronic device, and storage medium, relating to the fields of human-computer interaction and input device control technology. The method includes: formulating an input control plan and distributing it to the decoding and encoding ends; the decoding end's local input device server collects action data and determines the current working mode based on the mode field in the plan: in local mode, input events are handled by the local desktop system, and a policy entry determines whether to maintain remote auxiliary delivery; in remote mode, action data is encapsulated into an HID report and forwarded to the encoding end via a virtual IP tunnel. When a switch is triggered, the mode state machine verifies the validity and performs a migration, with the display interface module coordinating pointer visibility, filtering outdated requests by version number and stopping remote delivery, and using a heartbeat mechanism to complete anomaly rollback. This invention solves the problems of uncontrollable mode switching, pointer drift, lack of policy update verification, and missing multi-end collaborative closed-loop in existing technologies.

Description

Technical Field

[0001] This invention relates to the field of human-computer interaction and input device control technology, and in particular to an input device control switching method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of information technology, remote operation and multi-host collaborative work scenarios are becoming increasingly common. Users have an increasingly urgent need to seamlessly switch between local desktops and remote hosts using the same physical keyboard and mouse. Traditional remote control solutions typically bind input events to specific sessions, making it difficult to effectively correspond with the underlying USB HID input path. This results in complex and uncontrollable mode switching in multi-tasking scenarios. Furthermore, conventional input forwarding solutions lack clear mode differentiation and path management during switching, easily leading to problems such as pointer drift, focus errors, and multi-screen coordinate mapping errors, which seriously affect operational accuracy and user experience.

[0003] In existing solutions, multi-screen expansion methods that rely solely on system-level pointer management struggle to maintain consistency between cursor and focus states during switching, and the error is further amplified in display environments with varying resolutions and DPIs. While some solutions using HID pass-through forwarding can achieve cross-host transmission of input data, they lack explicit forwarding strategies and dynamic scheduling mechanisms, are sensitive to network jitter, and struggle to effectively integrate with upper-layer business policies, resulting in noticeable sluggishness in remote control operations. Regarding policy management, existing systems often lack version confirmation mechanisms, and there is a lack of consistency verification between policy updates and input paths. Interpretations of the same policy across multiple endpoints are prone to divergence, further exacerbating the problem of duplicate event delivery or path dangling at the switching edge.

[0004] In addition, common industry solutions have overly tight coupling or unclear division of responsibilities between functional modules such as policy configuration, input scheduling and remote injection, making it difficult to form a stable closed loop between policy distribution, decoding execution and encoding injection. This results in slow response to configuration changes and insufficient anomaly recovery capabilities in the running state.

[0005] Therefore, there is an urgent need for an input device control switching method that can clearly distinguish between local mouse and remote mouse input semantics, achieve controllable mode switching, consistent pointer state, and a verifiable closed-loop strategy. Summary of the Invention

[0006] The present invention provides an input device control switching method to address the problems of existing technologies, such as lack of clear mode differentiation during switching, pointer drift, focus misalignment, large multi-screen mapping errors, easy fork in policy update interpretation across multiple terminals, slow configuration response, and insufficient anomaly recovery capability. The technical solution is as follows: According to one aspect of the present invention, an input device control switching method is provided, the method comprising: formulating an input control plan and sending it to a local input device server, and performing verification and confirmation; the input control plan includes a mode field, an address mapping relationship, a data transmission channel port, hotkeys and policy entries, a control channel port, and a version number; when a decoding end accesses a local input device through an operating system, it obtains action data through the local input device server and determines the current mode according to the input control plan; if the current mode is a local mode, the action data is transmitted to the local desktop system for processing; the decoding end refers to the currently operating device; if the current mode is a remote mode, the action data is encapsulated into a data packet in the form of a message through a virtual IP tunnel and forwarded to an encoding end; the encoding end receives the data packet, parses the input semantics, and writes it to the corresponding USB emulation device; the encoding end refers to the remote device to be controlled; when a switching trigger event occurs, the mode state machine checks whether the trigger condition is valid; if valid, a state switch is executed, the display interface module coordinates pointer visibility, filters outdated requests according to the version number, and stops sending data to the encoding end.

[0007] In one embodiment, the input control plan is formulated, sent to the local input device server, and verified and confirmed through the following steps: The input control plan is formulated by the platform management side; the mode field is used to identify the current operating mode; the address mapping relationship is used to specify the target address or virtual address for data forwarding; the data transmission channel port and control channel port are used to distinguish different input devices from the receiving endpoints of control messages; the hotkeys and edge policy entries are used to define the triggering conditions for mode switching; the input control plan is sent to the local input device server at the decoding end through the control plane channel; the control plane channel is independent of the high-frequency input data channel to avoid competition between policy signaling and keyboard / mouse message processing rhythm; the local input device server verifies the version of the input control plan and returns confirmation or rejection to the platform management side; the rejection reason includes outdated plan or conflict with current operating facts.

[0008] In one embodiment, when the decoding end accesses the local input device through the operating system, the acquisition of action data through the local input device server is achieved through the following steps: the decoding end accesses the event source of the local input device through the input subsystem of the operating system and continuously reads action data from the input device node; the action data includes pointer displacement, key state, and scroll wheel value; the local input device server runs on the decoding end's operating system; the local input device server, in conjunction with the device hot-plug monitoring mechanism provided by the operating system, subscribes to or rebuilds the plugging and unplugging and enumeration changes of the input device; the local input device server simultaneously monitors the local mode switching message of the display interface module and links with the input control plan and mode state machine.

[0009] In one embodiment, the current mode is determined according to the input control plan. If the current mode is a local mode, the action data is transmitted to the local desktop system for processing through the following steps: the local input device server queries the mode field in the currently effective input control plan for each arriving input event to determine the current working mode; if the mode field indicates a local mode, the action data is handed over to the input subsystem of the decoding end local desktop system for interpretation and processing; the local input device server determines, based on the policy entries in the input control plan, whether to still deliver to the remote end, and whether to simultaneously maintain weak interaction or other auxiliary delivery of the remote link.

[0010] In one embodiment, if the current mode is remote mode, the action data is encapsulated into a data packet and forwarded to the encoding end via a virtual IP tunnel through the following steps: If the mode field indicates remote mode, the action data is encapsulated into an HID report by the local input device server, and distributed to different data channel ports according to the type of input device, and sent into the virtual IP tunnel in the form of a UDP packet; the received UDP packet is transparently forwarded to the corresponding receiving port of the encoding end through the virtual IP tunnel; in remote mode, the pointer drawn locally by the decoding end is hidden by the display interface module; the hiding of the pointer drawn locally by the decoding end is used to avoid the local pointer and the remote pointer appearing on the screen at the same time.

[0011] In one embodiment, the process of receiving the data packet and parsing the input semantics at the encoding end and writing it to the corresponding USB emulator is achieved through the following steps: the remote input device server at the encoding end listens to the UDP data port forwarded by the virtual IP tunnel, receives the UDP packet and parses the HID report, and writes the parsed HID report to the device node corresponding to the USB emulator; the USB emulator is recognized as a standard input device in the operating system of the encoding end; for coordinate data in the running data, relative displacement semantics and absolute coordinate semantics are written to different USB device nodes respectively, injected using different message formats, and the parsing and response to pointer behavior in the running data is completed by the HID driver of the operating system of the encoding end.

[0012] In one embodiment, the state switching is performed by the display interface module, which coordinates the display and hiding of pointers, filters outdated requests by version number, and stops sending data to the encoding end through the following steps: If switching from remote mode back to local mode, data sending to the encoding end is stopped, input events are processed by the local input subsystem of the decoding end, the display interface module coordinates the re-display of the local pointer, and the remote input device server uses a heartbeat and session persistence mechanism to detect the link status; if the link status is abnormal, the control plane reports and cooperates with the state machine to complete the mode rollback and perform event deduplication; the switching trigger events include input control plan change, preset hotkey combination trigger, screen edge detection trigger, idle timeout, and link abnormality.

[0013] According to one aspect of the present invention, an input device control switching apparatus includes: a plan formulation and distribution module, configured to formulate an input control plan and send it to a local input device server, and perform verification and confirmation; the input control plan includes a mode field, an address mapping relationship, a data transmission channel port, hotkeys and policy entries, a control channel port, and a version number; and an event acquisition and discrimination module, configured to, when a decoding end accesses a local input device through an operating system, acquire action data through the local input device server and determine the current mode according to the input control plan; if the current mode is a local mode, then transmit the action data to the local desktop. The system processes the data; the decoding end refers to the currently operating device; the data forwarding and injection module is used to encapsulate the action data into a data packet in the form of a message through a virtual IP tunnel and forward it to the encoding end when the current mode is remote mode. The encoding end receives the data packet, parses the input semantics, and writes it to the corresponding USB emulation device; the encoding end refers to the remote device to be controlled; the state triggering and switching module is used to check whether the triggering condition is valid through the mode state machine when a switching trigger event occurs. If it is valid, the state switch is executed, and the display interface module coordinates the pointer display and hiding, filters outdated requests according to the version number, and stops sending data to the encoding end.

[0014] According to one aspect of the present invention, an electronic device includes at least one processor and at least one memory, wherein computer-readable instructions are stored on the memory; the computer-readable instructions are executed by one or more of the processors to cause the electronic device to implement the input device control switching method as described above.

[0015] According to one aspect of the present invention, a storage medium has computer-readable instructions stored thereon, which are executed by one or more processors to implement the input device control switching method as described above.

[0016] The beneficial effects of the technical solution provided by this invention are: In the above technical solution, this invention formulates an input control plan on the platform management side, including mode fields, address mapping relationships, port configurations, policy entries, and version numbers. This plan is then sent to the decoding and encoding ends via a control plane channel independent of the data plane, and version verification is performed to ensure consistency in policy distribution. Based on this, the local input device server on the decoding end continuously collects action data through the operating system's input subsystem. It determines the current working mode based on the mode field in the input control plan. In local mode, input events are handled by the local desktop system, and policy entries determine whether to maintain remote auxiliary delivery. In remote mode, action data is encapsulated into an HID report and transparently forwarded to the encoding end via a virtual IP tunnel. The remote input device server on the encoding end receives the data, parses the HID report, and writes the relative displacement and absolute coordinate semantics separately to different USB device nodes, enabling the encoding end's operating system to recognize it as a standard input device. When a switching trigger event occurs, the mode state machine verifies the validity of the trigger and then performs a state transition. The display interface module works together to show and hide the pointer, filters outdated requests by version number and stops remote delivery, and completes the fallback of abnormal links with the help of the heartbeat mechanism. This ensures the integrity of events and the consistency of paths at the switching edge, effectively solving the problems of uncontrollable mode switching, pointer drift, lack of verification for policy updates and lack of multi-terminal collaborative closed loop in the existing technology. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an input device control switching method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating the input device control switching method in an application scenario; Figure 3 This is a flowchart illustrating the process of switching between local and remote modes in an application scenario. Figure 4 This is a block diagram illustrating an input device control switching device according to an exemplary embodiment; Figure 5 This is a hardware structure diagram of an electronic device according to an exemplary embodiment; Figure 6 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0019] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0020] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this disclosure means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0021] This invention provides an input device control switching method. Through a control plane and data plane separation architecture, it achieves reliable distribution and version verification of input control plans. By coordinating a mode state machine and USB emulation device injection, it enables controllable switching of local and remote input semantics and consistency of pointer states. It effectively solves the problems of uncontrollable mode switching, pointer drift, and lack of policy update verification in existing technologies. This input device control switching method is applicable to input device control switching devices, which can be electronic devices. The input device control switching method in this invention can be applied to various scenarios, such as the use of non-volatile storage media.

[0022] Please see Figure 1 This invention provides an input device control switching method, which is applicable to electronic devices.

[0023] In the following method embodiments, for ease of description, the execution subject of each step of the method is an electronic device, but this does not constitute a specific limitation.

[0024] like Figure 1 As shown, the method may include the following steps: Step 110: Send the input control plan to the local input device server and perform verification and confirmation.

[0025] In one possible implementation, the platform management side formulates an input control plan, which is then sent to the local input device server at the decoding end via the control plane channel. The local input device server verifies the version of the input control plan and returns confirmation or rejection to the platform management side.

[0026] Among them, the mode field is used to identify the current working mode; the address mapping relationship is used to specify the target address or virtual address for data forwarding; the data transmission channel port and the control channel port are used to distinguish different input devices from the receiving endpoints of control messages; the hotkey and edge policy entries are used to define the trigger conditions for mode switching; the control plane channel is independent of the high-frequency input data channel to avoid policy signaling and keyboard and mouse messages competing for processing rhythm.

[0027] The input control plan includes mode fields, address mapping relationships, data transmission channel ports, hotkeys and policy entries, control channel ports and version numbers, etc. The reasons for rejection include outdated plans, conflicts with current operating facts, etc., none of which are specified here.

[0028] Specifically, the platform management side formulates an input control plan, which is a structured description of the intent regarding the destination, operating mode, and triggering rules of input events. The plan includes: a mode field to identify the current operating mode; an address mapping relationship to specify the target address or virtual address for data forwarding; data transmission channel ports and control channel ports to distinguish different input devices from the receiving endpoints of control messages; hotkeys and edge policy entries to define the triggering conditions for mode switching; and a version number to distinguish the order of the plan. This plan is transmitted independently of the high-frequency input data channel to avoid contention between policy signaling and keyboard / mouse messages for processing rhythm.

[0029] Furthermore, the platform management side distributes the plan to the local input device server at the decoding end via the control plane channel. The control plane channel uses a structured message-based remote procedure call protocol, physically separated from the keyboard and mouse UDP data plane. This ensures that changes to policy configurations do not compete with high-frequency input messages for processing speed, guaranteeing reliable plan delivery even during data plane congestion. The platform management side also obtains key status feedback from the execution side through an event subscription mechanism, forming a two-way closed loop of policy distribution and status reporting.

[0030] Furthermore, after verifying the plan's version, the receiving end returns an acknowledgment or rejection to the platform. If the receiving end's current running plan version is updated or a conflict exists, the outdated plan is rejected, and a rejection reason is returned to the platform. This version mechanism ensures consistent understanding of the plan version across multiple endpoints at the switching edge, avoiding input path confusion caused by plan interpretation forks. The acknowledgment mechanism enables the platform to track the execution status of each plan, supporting trusted application of configuration changes in the running state.

[0031] In the above process, the embodiments of the present invention decouple the policy distribution from the high-frequency data channel through an independent control plane channel and a version verification mechanism, providing reliable transmission and consistency assurance of policy configuration, and realizing a traceable closed loop of the platform side to the execution side plan implementation status.

[0032] Step 120: When the decoding end accesses the local input device through the operating system, it obtains the action data through the local input device server and determines the current mode according to the input control plan. If the current mode is the local mode, the action data is transmitted to the local desktop system for processing.

[0033] In one possible implementation, the decoding end accesses the event source of the local input device through the input subsystem of the operating system and continuously reads action data from the input device node. The local input device server, in conjunction with the device hot-plug monitoring mechanism provided by the operating system, subscribes to or rebuilds the plugging, unplugging and enumeration changes of the input device. The local input device server also listens for the local mode switching message of the display interface module and links with the input control plan and mode state machine.

[0034] In one possible implementation, the local input device server queries the mode field in the currently effective input control plan to determine the current working mode for each incoming input event. If the mode field indicates local mode, the action data is handed over to the input subsystem of the local desktop system at the decoding end for interpretation and processing. The local input device server then decides, based on the policy entries in the input control plan, whether to still deliver to the remote end and whether to simultaneously maintain weak interaction or other auxiliary delivery of the remote link.

[0035] Here, the decoding end refers to the currently operating device; the local input device server runs on the decoding end's operating system; the action data includes pointer displacement, key status, and scroll wheel value, etc., which are not specified here.

[0036] Specifically, the local input device server at the decoding end runs on the decoding end's operating system. It accesses the event source of the local input device through the operating system's input subsystem, continuously reading motion data from the input device node, including pointer displacement, key states, and scroll wheel values. This server, combined with the operating system's hot-swap monitoring mechanism, subscribes to or reconstructs changes in input device insertion / removal and enumeration, ensuring the continuity of the acquisition chain in multi-device scenarios. This mechanism keeps the acquisition path available in complex peripheral environments such as multiple mice and keyboards, avoiding acquisition interruptions caused by device replacement or insertion / removal.

[0037] Furthermore, after the event stream enters the input processing core, it is categorized into pointer movement, key presses, scroll wheel events, and other compatible event types. The categorized action data then enters the mode state machine and forwarding decision process. The local input device server also simultaneously listens for local mode switching messages from the display interface module, coordinating with the input control plan and mode state machine. Through the overlay module, it collaborates with the display interface module and graphics system during remote modes or mode switching, for example, indicating the current mode status, limiting accidental touch areas, or synchronizing pointer-related states during switching.

[0038] Furthermore, the local input device server queries the currently active input control plan for each incoming input event and determines the current operating mode based on the mode field in the plan. If the mode field indicates local mode, the action data is handed over to the input subsystem of the local desktop system at the decoding end for interpretation and processing, with the user's perception primarily based on the local pointer. Simultaneously, the server decides whether to still deliver data to the remote end according to the policy entries in the plan. That is, in local mode, remote forwarding is not absolutely suppressed, but rather the policy finely controls whether to simultaneously maintain weak interaction or other auxiliary delivery of the remote link. This policy linkage mechanism allows for selective maintenance of keep-alive or state synchronization with the remote end in local mode, providing a smooth transition basis for mode switching.

[0039] In the above process, the embodiments of the present invention enable physical input events to be distributed according to policies between local and remote paths through continuous collection of input subsystem and dynamic discrimination of pattern fields, providing flexible processing capabilities of local priority response and policy-based remote maintenance, and realizing the decoupling of user perception and background policy execution in local mode.

[0040] Step 130: If the current mode is remote mode, the action data is encapsulated into a data packet in the form of a message through the virtual IP tunnel and forwarded to the encoding end. The encoding end receives the data packet, parses the input semantics, and writes it to the corresponding USB emulation device.

[0041] In one possible implementation, if the mode field indicates remote mode, the action data is encapsulated into an HID report by the local input device server, and then distributed to different data channel ports according to the type of input device, and sent into the virtual IP tunnel in the form of UDP packets. The received UDP packets are transparently forwarded to the corresponding receiving port of the encoding end through the virtual IP tunnel. In remote mode, the pointer drawn locally on the decoding end is hidden by the display interface module.

[0042] Hiding the pointer drawn locally on the decoding end is used to prevent the local pointer and the remote pointer from appearing on the screen at the same time.

[0043] In one possible implementation, the remote input device server at the encoding end listens to the UDP data port forwarded by the virtual IP tunnel, receives UDP packets and parses out the HID report, and writes the parsed HID report to the device node corresponding to the USB emulator. For coordinate data in the runtime data, the relative displacement semantics and absolute coordinate semantics are written to different USB device nodes and injected using different message formats. The HID driver of the operating system at the encoding end completes the parsing and response to pointer behavior in the runtime data.

[0044] The encoding end refers to the remote device to be controlled; the USB emulator is recognized as a standard input device in the encoding end's operating system.

[0045] Specifically, if the mode field indicates remote mode, the local input device server encapsulates the action data that meets the forwarding conditions into HID report semantics, and distributes it to different data channel ports according to the input device type, sending it into the virtual IP tunnel in the form of UDP packets. Mouse and keyboard channels are separated into different UDP ports, and the control and data channels are independent of each other, reducing the blocking of signaling packets and high-frequency keyboard and mouse packets. The virtual IP tunnel transparently forwards the received UDP packets, ensuring that the packets arrive at the corresponding receiving port of the encoding end intact. The network path does not care about the packet content, only completing the transport layer transport.

[0046] Furthermore, in remote mode, the display interface module works in conjunction with the pointer drawn by the local graphics system on the hidden decoding end to avoid visual interference caused by the simultaneous appearance of the local pointer and the remote pointer on the screen. The display interface module controls the display and hiding of the pointer through a side channel configured by the graphics system, keeping the interface clean when the operator is operating remotely. When needed, coordinates can also be injected through a virtual absolute pointer device to align the local pointer position with the coordinate space of the business window, providing a synchronization basis for absolute coordinate positioning.

[0047] Furthermore, the remote input device server at the encoding end runs on the encoding end's operating system, listens to the UDP data port forwarded by the virtual IP tunnel, receives mouse and keyboard messages, and parses out HID reports. The parsed HID reports are written to the device node corresponding to the USB emulator, which is recognized as a standard input device in the encoding end's operating system, causing the controlled end's operating system to treat the encoding end as a real USB input device. For coordinate data, relative displacement semantics and absolute coordinate semantics are written to different USB device nodes and injected using different message formats to avoid semantic conflicts between relative and absolute coordinates within the same HID driver stack. The injection boundary ends at the byte stream output of the USB emulator; the controlled end's operating system's HID driver ultimately completes the parsing and response to pointer behavior, and the encoding end itself does not interfere with the calculation of the pointer's final position.

[0048] In the above process, the embodiments of the present invention enable the action data to reach the controlled end with standard HID semantics and be identified as real USB input by transparent forwarding through virtual IP tunnel and split injection of USB emulation device. It provides an injection path with relative / absolute coordinate semantic isolation, realizes zero-interpretation transparent transmission of input events at the encoding end and driver layer convergence.

[0049] Step 140: When a switching trigger event occurs, the trigger condition is checked through the mode state machine. If it is valid, the state switch is executed. The display interface module coordinates the display of pointers, filters outdated requests by version number, and stops sending data to the encoding end.

[0050] In one possible implementation, if the device switches back from remote mode to local mode, data delivery to the encoding end is stopped. Input events are handled by the local input subsystem of the decoding end, and the local pointer is re-displayed in collaboration with the display interface module. The remote input device server detects the link status through a heartbeat and session persistence mechanism. If the link status is abnormal, it reports through the control plane and works with the state machine to complete the mode rollback and perform event deduplication.

[0051] The switching trigger events include changes to the input control plan, preset hotkey combination triggers, screen edge detection triggers, idle timeouts, link anomalies, etc., none of which are specified here.

[0052] Specifically, the transition actions of the mode state machine are driven by switching trigger events, including input control plan changes, preset hotkey combination triggers, screen edge detection triggers, idle timeouts, and link anomalies. After a trigger occurs, the mode state machine first verifies the validity of the trigger conditions. Verification criteria include whether the current running state allows the transition, and comparing the plan version number to reject outdated transition requests, thus avoiding invalid transitions caused by accidental triggers or obsolete instructions. Screen edge detection and hotkey combinations provide a quick switching exit at the physical operation level, allowing users to maintain convenient local switching capabilities even when operating remotely.

[0053] Furthermore, upon successful verification, a state transition is executed. If the transition is from remote mode back to local mode, data delivery to the encoder is stopped, and the local input subsystem at the decoder resumes its dominant role in handling input events. The display interface module collaboratively restores the local pointer's visibility and movement capability via the graphics system's side channel, achieving a smooth transition from the pointer being hidden in remote mode to being restored in local mode. During the transition, event deduplication is performed to prevent the same event from being repeatedly delivered or the path from being suspended at the switching edge. The overlay layer can indicate the current mode status during or after the transition, enhancing the perceptibility of mode switching.

[0054] Furthermore, the remote input device server uses a heartbeat and session persistence mechanism to detect the health status of cross-host links, maintaining link stability across tunnels and hosts. When a heartbeat times out or a link anomaly is detected, the server reports the abnormal status via the control plane. The mode state machine then triggers an anomaly fallback, migrating the operating mode back to the local dominant state, reducing the risk that the remote link may be unavailable while the local system continues to maintain the remote mode. The control plane relay can send hold-type or reset-type commands to the server, enabling the injected link to return to a predictable state after an anomaly. This mechanism, in conjunction with the decoding end's mode state machine, forms a closed-loop recovery capability in abnormal scenarios.

[0055] In the above process, the embodiments of the present invention, through multi-dimensional trigger source and state machine validity verification, enable mode transition to have clear trigger conditions and execution paths, provide switching guarantee for pointer explicit and implicit coordination and event deduplication processing, and realize the link self-healing capability of heartbeat detection and automatic rollback in abnormal scenarios.

[0056] Through the above process, this embodiment of the invention formulates an input control plan including mode fields, address mapping, port configuration, policy entries, and version numbers on the platform management side. This plan is then sent to the decoding and encoding ends via an independent control plane channel and verified for version confirmation, achieving reliable policy transmission and consistency assurance. The decoding end continuously collects action data through the input subsystem, determines the current working mode based on the mode fields in the plan, and in local mode, the desktop system processes the data while the remote end maintains it with fine-grained control through policy entries. In remote mode, the action data is encapsulated into an HID report and transparently forwarded through a virtual IP tunnel. The encoding end receives and parses the HID report, semantically separating the relative displacement and absolute coordinates and writing them to different USB device nodes, enabling the controlled operating system to recognize it as a standard input device. When a switch is triggered, the mode state machine verifies its validity and performs a migration. The display interface module coordinates the pointer to show / hide, filters outdated requests by version number and stops remote delivery, and completes anomaly rollback with a heartbeat mechanism. This effectively solves the problems of uncontrollable mode switching, pointer drift, lack of policy update verification, and missing multi-end collaborative closed loop in existing technologies.

[0057] In one application scenario, taking a large enterprise's cross-regional KVM remote control operation and maintenance scenario as an example, the enterprise has deployed hundreds of business servers in its headquarters server room. Operation and maintenance personnel in remote branch offices need to perform daily inspections and troubleshooting of the headquarters servers through a KVM over IP system. The maintenance personnel operate a decoding workstation from their branch office desk, with the target server located in the headquarters server room, and the encoding device physically connected to the server. The maintenance personnel need to use the same USB mouse and keyboard to controllably switch between their local office desktop and the remote server desktop. The input device control switching method of this invention is used for remote control of the input device.

[0058] Figure 2The flowchart illustrates the input device control switching process, which may include the following steps: In step S1, the local mouse server at the decoding end reads the raw input events from the input device node through evdev, obtains motion data including relative displacement and absolute coordinates through the Linux input subsystem, and at the same time, the display interface module presents the local mouse pointer through Weston.

[0059] Specifically, when maintenance personnel move the USB mouse, the decoding-side operating system reads the raw input event stream from the / dev / input / eventX device node through the input subsystem. The local mouse server reads the events through the evdev interface, obtaining relative displacement data of type EV_REL (including REL_X and REL_Y) and absolute coordinate data of type EV_ABS (including ABS_X and ABS_Y). When the mouse moves, the event types REL_X and REL_Y indicate the relative displacement in the horizontal and vertical directions; when maintenance personnel use input devices that support absolute positioning, such as touchpads or drawing tablets, the event types ABS_X and ABS_Y indicate the absolute position in the screen coordinate system. The display interface module draws and displays the local mouse pointer using the Weston graphics system, and the pointer responds normally to movement on the local desktop.

[0060] Furthermore, the local mouse server categorizes the received event stream, classifying different types of events such as pointer movement, button presses, and scroll wheel events. It continuously monitors device plugging / unplugging and enumeration changes, and automatically rebuilds the acquisition link when a device is replaced, in conjunction with the operating system's hot-plug monitoring mechanism. After event classification, the events enter the Linux input subsystem for preprocessing of absolute coordinates and mode switching. Simultaneously, the local mouse server performs subsequent discrimination and distribution of events based on the current mode state.

[0061] In the above process, the embodiments of the present invention read the raw input events containing relative displacement and absolute coordinates from the input device node through the evdev interface and preprocess them by the Linux input subsystem, so that the local mouse server can be compatible with multiple types of input devices and obtain motion data, providing a unified collection and classification processing capability for multiple types of input events, and realizing standardized data access between the physical input layer and the upper-layer mode discrimination.

[0062] In step S2, the platform management side sends an input control plan through the control plane via the relay service. The plan includes a mode field, address mapping relationship and version number. After receiving the plan, the local mouse server determines the current working mode based on the mode field. When entering remote mode, the display interface module hides the Weston local pointer, and the local mouse server encapsulates and forwards the action data to the encoding end through a virtual IP tunnel.

[0063] Specifically, maintenance personnel select the remote server session to be controlled in the operation panel of the display interface module. This selection triggers the platform management side to generate a new version of the input control plan. The plan is transmitted to the decoding end relay service via the control plane channel, and the relay service distributes the plan to the local mouse server. The mode field in the plan is set to remote mode, the address mapping relationship specifies the virtual IP address of the target encoding end, and the version number is incremented to V2.0. After receiving the plan, the local mouse server verifies the version number. If it confirms that V2.0 is the new version, it applies the plan and returns confirmation to the platform management side.

[0064] Furthermore, the local mouse server determines the current mode as remote mode based on the planned mode field. The display interface module hides the locally drawn mouse pointer through the Weston side channel to avoid confusion caused by both local and remote pointers appearing on the screen simultaneously. The local mouse server encapsulates action data that meets the forwarding policy into HID report semantics. The local mouse server distinguishes between relative and absolute types in the tunnel payload—relative displacement events (EV_REL) and absolute coordinate events (EV_ABS) carry different payload type identifiers. The encapsulated message is sent via the UDP mouse port, with REL and ABS carried in different payload structures according to their types. The UDP message is sent into the virtual IP tunnel, which transparently forwards the received UDP message, passing it intact to the corresponding receiving port of the encoding end.

[0065] In the above process, the embodiments of the present invention issue an input control plan containing a mode field and version number through the relay service via the control plane, so that the remote mode switching is uniformly driven by the platform policy and the version is traceable; by distinguishing relative and absolute types in the tunnel payload and carrying them separately by the local mouse server, different coordinate semantics are kept independently identified at the transport layer; by hiding the Weston local pointer and coordinating the transparent forwarding of the virtual IP tunnel through the display interface module, the operation interface in the remote mode presents a clean visual environment with a single pointer, realizing a complete data plane closed loop from the decoding end to the type identification to the encoding end forwarding of input events.

[0066] Step S3: The remote mouse server at the encoding end parses the UDP packet and converts the HID report identifier. The relative HID report and the absolute HID report are written to different USB emulation device nodes respectively. The host USB HID driver completes pointer positioning and movement according to different types. The relative displacement drives the pointer in the cumulative displacement mode, and the absolute coordinate directly positions the pointer in the logical coordinate.

[0067] Specifically, the remote mouse server runs on the encoding end Linux operating system and listens on the UDP data port forwarded by the virtual IP tunnel. After receiving a UDP packet, the remote mouse server parses the packet content and converts the HID report identifier (Report ID), and writes the parsing result to the corresponding Gadget device node according to the payload type.

[0068] Furthermore, for relative displacement loads, the remote mouse server generates a relative HID report and writes it to the / dev / hidg1 node, which corresponds to the Gadget relative mouse device. The report contains Δx and Δy displacement values. The host operating system recognizes this device as a USB relative mouse, and its HID driver reads the report and drives the pointer movement in an accumulated displacement manner—each time a relative displacement value is received, the offset is accumulated based on the current pointer position.

[0069] For absolute coordinate payloads, the remote mouse server generates an absolute HID report and writes it to the / dev / hidg2 node, which corresponds to the Gadget absolute mouse device. The report contains logical X and logical Y coordinate values. The host operating system recognizes this device as a USB absolute mouse, and its HID driver reads the report and directly positions the pointer using logical coordinates—upon receiving the absolute coordinates, it directly places the pointer at the corresponding logical coordinate on the screen.

[0070] The two types of device nodes operate independently, employing different message formats for injection. This avoids semantic conflicts arising from relative displacement and absolute coordinates within the same HID driver stack. The injection boundary terminates at the byte stream output of the Gadget device node. The host USB HID driver handles the final parsing and response to the pointer behavior, without the encoding end interfering with the pointer position calculation.

[0071] In the above process, the embodiments of the present invention write the relative displacement and absolute coordinate loads into independent Gadget device nodes through the remote mouse server at the encoding end, so that the two coordinate semantics remain isolated in the HID driver layer, providing the ability to inject relative mouse and absolute mouse separately, realizing the differentiated processing of relative displacement driving the pointer in the form of cumulative displacement and absolute coordinate directly locating the pointer in the form of logical coordinate, avoiding pointer jitter and positioning error caused by the mixing of the two coordinate semantics on the same stack in the traditional solution.

[0072] In step S4, the maintenance personnel trigger the mode switchback through the preset hotkey. The local mouse server suppresses remote delivery, and the display interface module restores the local pointer display through Weston. The remote mouse server on the encoding end keeps the link status monitored through the heartbeat mechanism and triggers automatic rollback when an anomaly occurs.

[0073] Specifically, after completing remote server maintenance operations, the operations and maintenance personnel press the preset local mode switchback hotkey. Once the mode state machine verifies that the trigger condition is valid, it initiates the state transition from remote-dominated mode to local-dominated mode. Upon receiving the switchback command, the local mouse server suppresses remote delivery, stops sending UDP packets to the virtual IP tunnel, and input events are resumed to be handled by the local desktop system.

[0074] The display interface module re-displays the local mouse pointer via the Weston side channel, maintaining the pointer position in its original coordinates to ensure no drift occurs after the switch. If maintenance personnel remain inactive for an extended period, triggering an idle timeout, or if a network link anomaly prevents UDP packets from reaching the encoding end, the mode state machine will also trigger an automatic rollback.

[0075] Furthermore, such as Figure 2 As shown in the control plane module, the remote mouse server at the encoding end continuously monitors the health status of the cross-host link through a heartbeat and session persistence mechanism. When a heartbeat timeout or link interruption is detected, the remote mouse server reports the abnormal status to the platform management side via the control plane. The platform management side then triggers the decoding end's mode state machine to perform an abnormal rollback via the control plane, automatically reverting the working mode back to the local dominant state.

[0076] The relay service can send reset commands to the remote mouse server, enabling the injection link to return to a predictable state after an anomaly. Throughout the process, mode switching and state changes are reported to the platform management side via the event subscription link, forming an auditable operation log.

[0077] In the above process, the embodiments of the present invention, through the coordination of preset hotkey trigger mode switchback and heartbeat mechanism link status monitoring, enable operation and maintenance personnel to have convenient manual switchback means and the system has the ability to automatically and safely roll back in abnormal scenarios. It provides a complete closed loop of continuous switching edge pointer position and auditable full-link operation, effectively reducing the risk of local still maintaining remote mode when remote link is unavailable.

[0078] Furthermore, this invention is applicable to various scenarios such as dual-machine or dual-node collaborative operation, KVM cloud desktops and remote workstations, KVM-like remote control environments, internal and external network isolation and cross-security domain operation consoles, industrial control and human-machine operation stations, etc.

[0079] In addition to policy configuration and session management, the display interface module (client) directly takes over the presentation and switching of the local mouse. It draws the local pointer through Weston and controls the display, hiding, movement enable and screen boundary of the Weston cursor through the agreed side channel. When needed, it can inject coordinates through the virtual absolute pointer device to synchronize the local pointer position. When entering remote mode, the transparent window of the display interface module captures the operation surface input, converts it into HID semantics and sends it to the encoding end through the data plane. At the same time, it coordinates the hiding or releasing of the Weston pointer to avoid the coexistence of two pointers.

[0080] The local mouse server includes an overlay module related to display interaction. This module works in conjunction with the display interface module and Weston during remote mode, hotkey triggering, edge triggering, or tooltip display. For example, the overlay can indicate the current mode, limit accidental touch areas, or synchronize pointer-related states with the display interface module during mode switching. This overlay can indicate the current mode status during or after the transition, enhancing the perceptibility of mode switching.

[0081] In remote or precise positioning scenarios, screen coordinates are obtained from the absolute coordinate events of the display interface module's operation surface (such as the pointer position captured by a transparent window) or the decoding input subsystem. After resolution normalization, multi-screen mapping, or boundary correction, these coordinates are encapsulated into absolute coordinate HID semantics. Relative displacement events are encapsulated into relative mouse messages, and a relative mouse gadget device node is written at the encoding end. Absolute coordinate events are encapsulated into absolute mouse messages, and an absolute mouse gadget device node independent of the relative mouse message is written at the encoding end. Relative and absolute coordinates are injected using different gadget nodes and different message formats to avoid conflicts between relative and absolute semantics within the same HID stack. The injection boundary ends at the gadget byte stream, and the host machine's HID drives the pointer behavior.

[0082] To maintain stable cross-tunnel and cross-host links, the remote mouse server can implement heartbeat and session persistence mechanisms to detect link failures, trigger reconnection policies, or coordinate with control plane commands from the control plane relay. The control plane relay can send persistence or reset commands to the remote mouse server, ensuring the injected link returns to a predictable state after an anomaly. This mechanism works in conjunction with the decoder-side mode state machine to reduce the risk of the local machine maintaining remote mode even when the remote end is unavailable. The data plane separates the mouse and keyboard channels into different UDP ports. Messages carrying HID report semantics are transparently forwarded via a virtual IP tunnel and may also include auxiliary UDP channels related to LEDs, screen lock, or display modes, separated from the control channel to reduce signaling and high-frequency message blocking. The control plane uses a remote invocation protocol based on structured messages. The separation of the data plane and control plane ensures that policy management and high-frequency data transmission do not interfere with each other.

[0083] Through the above process, this embodiment of the invention enables controllable switching between a local office desktop and a remote server in the headquarters server room using the same USB mouse and keyboard on the decoding workstation. The local mouse server reads the raw input events containing the relative displacement of EV_REL and the absolute coordinates of EV_ABS from the event device node via evdev. After classification and preprocessing by the Linux input subsystem, the working status is determined according to the mode field in the input control plan issued by the platform management side via the control plane. In remote mode, the display interface module hides the Weston local pointer. The local mouse server distinguishes between relative and absolute types in the tunnel payload and then transparently forwards the data via the virtual IP tunnel. The remote mouse server at the encoding end parses UDP packets and converts the HID report identifier. The relative HID report is written to the / dev / hidg1 node to drive the pointer using cumulative displacement, and the absolute HID report is written to the / dev / hidg2 node to directly locate the pointer position using logical coordinates. The host machine's USB HID driver interface completes the pointer response. Maintenance personnel trigger a switchback via a hotkey. The local mouse server suppresses remote delivery, the display interface module restores the local pointer, and the heartbeat mechanism triggers automatic rollback when the link status is abnormal. The entire process achieves split transmission and differentiated injection of relative and absolute coordinates, elimination of dual-pointer interference, smooth transition of switching edges, and auditable traceability of the entire link operation, effectively solving the problems of pointer jitter caused by coordinate semantic conflicts, uncontrollable mode switching, and lack of multi-terminal collaborative closed loop in the existing technology.

[0084] In one application scenario, this embodiment uses an industrial control operator station as an example for illustration. In an industrial control environment, the operator needs to perform collaborative operation between a local monitoring interface and a remote controlled device, which places extremely high demands on the real-time performance of the operation.

[0085] like Figure 3 The diagram illustrates the switching process between local-dominated mode and remote-dominated mode.

[0086] In local-dominated mode, the display interface module presents the local mouse pointer via the Weston graphics system, allowing the operator to interact with the local desktop at the decoding end. The local mouse server collects physical keyboard and mouse events through the input subsystem, determines the current mode as local-dominated based on the mode field in the input control plan, prioritizes the interpretation and processing of motion data by the local desktop system's input subsystem, and simultaneously suppresses or stops sending input events to the remote data plane according to the planned policy entries.

[0087] When the operator selects a remote session in the operation panel of the display interface module, an input control plan change is triggered. The new plan is sent to the decoding and encoding ends via the control plane channel and version confirmation is completed. The display interface module then hides the locally drawn mouse pointer via the Weston side channel to avoid confusion caused by both local and remote pointers appearing on the screen simultaneously. When the display interface module enters remote mode, it simultaneously hides the local pointer. The local mouse server enters remote-dominated mode, encapsulates action data that meets the forwarding policy into an HID report, and transparently forwards it to the encoding end via a virtual IP tunnel. The remote mouse server at the encoding end receives the data and writes it to the USB emulation device. The host machine's HID driver interface completes the pointer response, presenting the remote mouse operation semantics on the host side. During this process, the overlay module of the local mouse server can overlay prompts on the screen indicating the current mode status, enhancing the perceptibility of mode switching.

[0088] After the operator completes the remote operation, they can switch back to local mode via a preset hotkey or screen edge trigger. The operator can trigger the transition from remote-dominated mode back to local-dominated mode using hotkeys or edge triggers; the system can also automatically trigger mode rollback in case of idle timeout or link anomalies. After the mode state machine verifies the validity of the trigger conditions, it executes the state transition. The local mouse server stops sending data to the encoding end, restoring the local desktop system's dominance in handling input events, and the display interface module redisplays the local pointer via Weston. During the switching process, event deduplication is performed to avoid duplicate event delivery or path dangling at the switching edge. The remote mouse server continuously monitors the cross-host link status through a heartbeat and session persistence mechanism. When a heartbeat timeout or link interruption is detected, the control plane reports the anomaly, and the mode state machine automatically triggers a rollback to the local-dominated state, reducing the risk of the local system maintaining remote mode when the remote link is unavailable. The control plane relay can issue persist or reset commands to the remote mouse server, ensuring the injected link returns to a predictable state after anomaly recovery. Throughout the process, mode switching and state changes are reported to the platform management side through the event subscription link, forming an auditable operation record.

[0089] In the above process, this embodiment of the invention, through the pointer arrangement capability of the display interface module and the mode scheduling of the local mouse server, enables the same USB mouse and keyboard to achieve controllable switching between the local desktop and remote devices; by displaying the current mode status through an overlay layer, the perceptibility of mode switching is enhanced; through the abnormal rollback in coordination with the heartbeat mechanism and state machine, link self-healing and safe rollback capabilities are provided; and through the event subscription mechanism, the entire link of the switching operation is auditable and traceable. This effectively solves the problems of uncontrollable mode switching, pointer drift, and lack of multi-terminal collaborative closed loop in the prior art.

[0090] The following are embodiments of the apparatus of the present invention, which can be used to execute the input device control switching method involved in the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the method embodiments of the input device control switching method involved in the present invention.

[0091] Please see Figure 4 This invention provides an input device control switching device 800.

[0092] The input device control switching device 800 includes, but is not limited to: a plan formulation and distribution module 810, an event acquisition and discrimination module 830, a data forwarding and injection module 850, and a state triggering and switching module 870.

[0093] The planning and distribution module 810 is used to send the input control plan to the local input device server and perform verification and confirmation. The input control plan includes a mode field, address mapping relationship, data transmission channel port, hotkey and policy entries, control channel port and version number.

[0094] The event acquisition and discrimination module 830 is used to obtain action data from the local input device server and determine the current mode according to the input control plan when the decoding end accesses the local input device through the operating system. If the current mode is the local mode, the action data is transmitted to the local desktop system for processing. The decoding end refers to the current operating device.

[0095] The data forwarding and injection module 850 is used to encapsulate action data into data packets in the form of messages through a virtual IP tunnel and forward them to the encoding end when the current mode is remote mode. The encoding end receives the data packets, parses the input semantics, and writes them into the corresponding USB emulation device. The encoding end refers to the remote device to be controlled.

[0096] The state triggering and switching module 870 is used to check whether the triggering condition is valid through the mode state machine when a switching triggering event occurs. If it is valid, the state switching is performed, and the display interface module coordinates the pointer display and hiding, filters outdated requests according to the version number, and stops sending data to the encoding end.

[0097] It should be noted that the input device control switching provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the input device control switching device will be divided into different functional modules to complete all or part of the functions described above.

[0098] Furthermore, the input device control switching device and the input device control switching method provided in the above embodiments belong to the same concept, and the specific way in which each module performs its operation has been described in detail in the method embodiments, and will not be repeated here.

[0099] Figure 5 A schematic diagram of the structure of an electronic device according to an exemplary embodiment is shown.

[0100] It should be noted that this electronic device is merely an example adapted to the present invention and should not be construed as providing any limitation on the scope of use of the present invention. Furthermore, this electronic device should not be interpreted as requiring or depending on having... Figure 5 One or more components of the exemplary electronic device 2000 shown.

[0101] The hardware structure of electronic devices 2000 can vary significantly due to differences in configuration or performance, such as... Figure 5 As shown, the electronic device 2000 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0102] Specifically, power supply 210 is used to provide operating voltage for various hardware devices on electronic device 2000.

[0103] Interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. Of course, in other examples adapted to this invention, interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc. Figure 5 As shown, this does not constitute a specific limitation.

[0104] The memory 250 serves as a carrier for resource storage and can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it include the operating system 251, application programs 253, and data 255, etc., and the storage method can be temporary storage or permanent storage.

[0105] The operating system 251 is used to manage and control the various hardware devices and application programs 253 on the electronic device 2000, so as to enable the central processing unit 270 to perform calculations and processing on the massive data 255 in the memory 250. It can be Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0106] Application 253 is a computer-readable instruction based on operating system 251 that performs at least one specific task, and may include at least one module ( Figure 5 (Not shown), each module may contain computer-readable instructions for the electronic device 2000. For example, the input device control switching device may be considered as an application program 253 deployed on the electronic device 2000.

[0107] Data 255 may be signal information, etc., and is stored in memory 250.

[0108] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read computer-readable instructions stored in the memory 250, thereby performing operations and processing on massive amounts of data 255 stored in the memory 250. For example, an input device control switching method may be implemented by the central processing unit 270 reading a series of computer-readable instructions stored in the memory 250.

[0109] Furthermore, the present invention can also be implemented through hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of the present invention is not limited to any specific hardware circuit, software, or combination thereof.

[0110] Please see Figure 6 This invention provides an electronic device 4000, which may include: a desktop computer, a laptop computer, a server, etc., with sensor recognition capabilities.

[0111] exist Figure 6 In this context, the electronic device 4000 includes at least one processor 4001 and at least one memory 4003.

[0112] The data interaction between the processor 4001 and the memory 4003 can be achieved through at least one communication bus 4002. This communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0113] Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0114] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0115] The memory 4003 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program instructions or code in the form of instructions or data structures and accessible by the electronic device 4000, but not limited thereto.

[0116] The memory 4003 stores computer-readable instructions, and the processor 4001 can read the computer-readable instructions stored in the memory 4003 through the communication bus 4002.

[0117] The computer-readable instructions are executed by one or more processors 4001 to implement the input device control switching method in the above embodiments.

[0118] Furthermore, this embodiment of the invention provides a storage medium storing computer-readable instructions, which are executed by one or more processors to implement the input device control switching method described above.

[0119] This invention provides a computer program product, which includes computer-readable instructions stored in a storage medium. One or more processors of an electronic device read the computer-readable instructions from the storage medium, load and execute the computer-readable instructions, thereby enabling the electronic device to implement the input device control switching method as described above.

[0120] Compared with related technologies, the beneficial effects of the present invention are: 1. This invention enables clear distinction and controllable switching between local and remote input semantics. By dividing the input workspace into two mutually exclusive or quasi-mutually exclusive modes—local-dominated and remote-dominated—and using a mode field in the input control plan to uniformly identify the current working state, physical keyboard and mouse events can be clearly directed to the local desktop system or the remote forwarding path at the acquisition entry point. The mode state machine verifies the validity of the switching trigger conditions and performs controlled migration, completing event deduplication and path switching at the switching edge, avoiding the problems of "still following the old path after switching" or duplicate event delivery after switching in traditional solutions. The display interface module coordinates the control of pointer visibility during switching, ensuring that the operator's interface feedback is synchronized with the input mode, effectively improving the controllability and user trust of mode switching.

[0121] 2. This invention effectively avoids pointer drift and focus misalignment in multi-screen and multi-resolution scenarios. By writing relative displacement semantics and absolute coordinate semantics into independent USB emulation device nodes at the encoding end and injecting them using different message formats, the HID driver of the controlled operating system can independently handle pointer behavior according to its own coordinate interpretation method, avoiding semantic conflicts between relative and absolute coordinates within the same HID driver stack. During mode switching, the decoding end display interface module injects coordinates through a virtual absolute pointer device to synchronize the local pointer position, ensuring continuous pointer state before and after the switch. This mechanism effectively suppresses pointer jump and bounce problems in complex display environments such as multi-screen expansion and DPI differences, significantly improving remote operation accuracy.

[0122] 3. This invention enables reliable transmission of policy distribution and consistent execution across multiple terminals. By establishing a control plane channel independent of the high-frequency input data channel to transmit input control plans, policy configuration signaling does not need to compete for processing speed with high-frequency keyboard and mouse messages. Even when the data plane is congested, the plan can still reliably reach the execution end. The plan carries a version number, and the receiving end verifies the version of the plan, rejecting outdated updates or updates that conflict with current operational realities and returning confirmation or rejection reasons to the platform side, avoiding divergent interpretations of the same policy across multiple terminals. The event subscription mechanism feeds back key status changes from the decoding end to the platform side, forming a three-stage closed loop of policy configuration, execution confirmation, and status reporting, supporting reliable application of configuration changes and operational auditing during runtime.

[0123] 4. This invention achieves a stable closed loop with clearly defined responsibilities among policy configuration, input scheduling, and remote injection. By assigning the display interface module to handle the visual arrangement of local pointers, the local input device server to handle event acquisition and mode scheduling, and the remote input device server to handle data reception and USB injection, the division of labor among these three components is clear and their boundaries are well-defined, facilitating independent upgrades and problem localization. The separation of the control plane and data plane ensures that policy management and high-frequency data transmission do not interfere with each other. The decoding and encoding ends complete data pass-through through a virtual IP tunnel. The encoding end only performs the conversion from HID report to USB byte stream, without providing additional interpretation of the input semantics. This keeps the injection path concise and clear within the boundaries of each end's responsibilities, effectively avoiding slow configuration response and difficult anomaly recovery caused by overly tight module coupling.

[0124] 5. This invention provides link self-healing and secure rollback capabilities in abnormal scenarios. It implements a heartbeat and session persistence mechanism through a remote input device server, continuously monitoring the health status of links across tunnels and hosts. When a heartbeat times out or a link anomaly is detected, the server reports the abnormal status via the control plane. The mode state machine then triggers an anomaly rollback, automatically migrating the operating mode back to the local dominant state, avoiding the risk of operational stagnation caused by the remote link becoming unavailable while the local system maintains the remote mode. The control plane relay can send hold or reset commands to the server, ensuring the injected link returns to a predictable state after anomaly recovery. The above mechanisms, working in conjunction with the decoding end's mode state machine, form a complete closed-loop link management capability encompassing anomaly detection, reporting, rollback, and recovery.

[0125] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0126] The above description is only a partial embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An input device control switching method, characterized in that, The method includes: An input control plan is generated and sent to the local input device server for verification and confirmation. The input control plan includes a mode field, address mapping relationship, data transmission channel port, hotkeys and policy entries, control channel port, and version number. When the decoding end accesses the local input device through the operating system, it obtains action data through the local input device server and determines the current mode according to the input control plan. If the current mode is the local mode, the action data is transmitted to the local desktop system for processing. The decoding end refers to the current operating device. If the current mode is remote mode, the action data is encapsulated into a data packet in the form of a message through a virtual IP tunnel and forwarded to the encoding end. The encoding end receives the data packet, parses out the input semantics, and writes it into the corresponding USB emulation device. The encoding end refers to the remote device to be controlled. When a switching trigger event occurs, the mode state machine checks whether the trigger condition is valid. If it is valid, the state switch is executed, and the display interface module coordinates the pointer display and hiding. Old requests are filtered by version number and data delivery to the encoding end is stopped.

2. The input device control switching method as described in claim 1, characterized in that, The step of sending the input control plan to the local input device server and performing verification and confirmation includes: The platform management side formulates an input control plan; the mode field is used to identify the current working mode; the address mapping relationship is used to specify the target address or virtual address for data forwarding; the data transmission channel port and control channel port are used to distinguish different input devices from the receiving endpoints of control messages; the hotkeys and edge policy entries are used to define the triggering conditions for mode switching. The input control plan is sent to the local input device server at the decoding end via the control plane channel; the control plane channel is independent of the high-frequency input data channel to avoid competition between policy signaling and keyboard and mouse messages for processing rhythm; The local input device server performs version verification on the input control plan and returns confirmation or rejection to the platform management side; the reasons for rejection include outdated plan or conflict with current operating facts.

3. The input device control switching method as described in claim 1, characterized in that, When the decoding end accesses the local input device through the operating system, it obtains action data through the local input device server, including: The decoding end accesses the event source of the local input device through the input subsystem of the operating system and continuously reads action data from the input device node; the action data includes pointer displacement, key status and scroll wheel value; the local input device server runs on the decoding end's operating system; The local input device server, in conjunction with the device hot-plug monitoring mechanism provided by the operating system, subscribes to or rebuilds the insertion, removal and enumeration changes of the input device. The local input device server also monitors the local mode switching messages of the display interface module and links with the input control plan and mode state machine.

4. The input device control switching method as described in claim 1, characterized in that, The step of determining the current mode based on the input control plan, and if the current mode is local mode, then transmitting the action data to the local desktop system for processing, includes: The local input device server queries the mode field in the currently effective input control plan to determine the current working mode for each incoming input event; If the mode field indicates local mode, the action data will be handed over to the input subsystem of the local desktop system of the decoding end for interpretation and processing; The local input device server determines, based on the policy entries in the input control plan, whether to still deliver to the remote end, and whether to simultaneously maintain weak interaction or other auxiliary delivery on the remote link.

5. The input device control switching method as described in claim 4, characterized in that, If the current mode is a remote mode, then the action data is encapsulated into a data packet and forwarded to the encoding end via a virtual IP tunnel, including: If the mode field indicates remote mode, the action data is encapsulated into an HID report by the local input device server, and distributed to different data channel ports according to the type of input device, and sent into the virtual IP tunnel in the form of UDP packets; The received UDP packets are transparently forwarded to the corresponding receiving port of the encoding end through the virtual IP tunnel. In remote mode, the pointer drawn locally on the decoding end is hidden through the display interface module. The hiding of the pointer drawn locally on the decoding end is used to avoid the local pointer and the remote pointer appearing on the screen at the same time.

6. The input device control switching method as described in claim 5, characterized in that, The step of receiving the data packet through the encoding end, parsing the input semantics, and writing it to the corresponding USB emulation device includes: The remote input device server at the encoding end listens to the UDP data port forwarded by the virtual IP tunnel, receives the UDP packets and parses out the HID report, and writes the parsed HID report to the device node corresponding to the USB emulator; the USB emulator is recognized as a standard input device in the operating system at the encoding end; For coordinate data in the runtime data, relative displacement semantics and absolute coordinate semantics are written to different USB device nodes and injected using different message formats. The HID driver of the encoding end operating system completes the parsing and response to pointer behavior in the runtime data.

7. The input device control switching method as described in claim 1, characterized in that, The execution state switching is coordinated by the display interface module through pointer visibility, filtering outdated requests by version number and stopping data delivery to the encoding end, including: If the device switches from remote mode back to local mode, data delivery to the encoding end stops. Input events are processed by the local input subsystem of the decoding end, and the local pointer is re-displayed in collaboration with the display interface module. The remote input device server detects the link status through a heartbeat and session persistence mechanism. If the link status is abnormal, the control plane will report it and cooperate with the state machine to complete the mode rollback and perform event deduplication. The switching trigger events include input control plan change, preset hotkey combination trigger, screen edge detection trigger, idle timeout, and link abnormality.

8. An input device control switching device, characterized in that, The device includes: The plan creation and distribution module is used to create an input control plan and send it to the local input device server, and to verify and confirm it. The input control plan includes a mode field, address mapping relationship, data transmission channel port, hotkey and policy entries, control channel port and version number. The event acquisition and discrimination module is used to obtain action data from the local input device server when the decoding end accesses the local input device through the operating system and determine the current mode according to the input control plan. If the current mode is the local mode, the action data is transmitted to the local desktop system for processing. The decoding end refers to the current operating device. The data forwarding and injection module is used to encapsulate the action data into a data packet in the form of a message through a virtual IP tunnel and forward it to the encoding end when the current mode is remote mode. The encoding end receives the data packet, parses the input semantics, and writes it into the corresponding USB emulation device. The encoding end refers to the remote device to be controlled. The state triggering and switching module is used to check whether the triggering condition is valid through the mode state machine when a switching triggering event occurs. If it is valid, the state switching is performed, and the display interface module coordinates the pointer display and hiding. It filters outdated requests according to the version number and stops sending data to the encoding end.

9. An electronic device, characterized in that, include: At least one processor and at least one memory, wherein, The memory stores computer-readable instructions; The computer-readable instructions are executed by one or more of the processors, causing the electronic device to implement the input device control switching method as described in any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that, The computer-readable instructions are executed by one or more processors to implement the input device control switching method as described in any one of claims 1 to 7.

Images