Cloud desktop keyboard event processing method, device, equipment and storage medium

Abstract

The present invention provides a cloud desktop keyboard event processing method, apparatus, device, and storage medium for solving the technical problems of cloud desktop keyboard key state synchronization and convenient use. The cloud desktop client process opens the device file mapped by the physical keyboard device in exclusive mode, reads keyboard events from the device file mapped by the physical keyboard device, and transmits the keyboard events directly to the virtual machine. At the same time, a virtual keyboard device is simulated in user space, and keyboard events that do not need to be blocked are written to the device file mapped by the virtual keyboard device. The present invention can block local keyboard events while omitting key events that do not need to be blocked, thereby achieving synchronization of the local security state with the virtual machine and improving the convenience of cloud desktop applications.

Description

Technical Field

[0001] The present invention relates to the technical field of computers and cloud computing, and in particular to a cloud desktop keyboard event processing method, device, equipment and storage medium. Background Art

[0002] Against the backdrop of the rapid development of cloud computing technology, the application scenarios of cloud desktops are becoming more and more extensive. For example, cloud desktop solutions can be applied in daily office work and school teaching, which can rationally allocate computer resources, simplify computer management, reduce power consumption, and improve office efficiency.

[0003] The cloud desktop solution platform is based on Virtual Desktop Infrastructure (VDI), which can host the user's desktop environment as a virtual machine on a high-performance server, providing users with a user experience nearly identical to that of a physical PC. Ordinary users can access their cloud desktops through a variety of terminal devices, such as PCs and thin clients, to complete daily office tasks. Administrators can visually manage all cloud desktop resources and batch deploy cloud desktops to meet the needs of a large number of users. The cloud desktop system architecture primarily includes terminal devices (clients), desktop connection protocols, a cloud desktop management platform, a virtualization management platform, infrastructure components, and desktop resources, namely virtual machine (VM) pools.

[0004] In cloud desktop applications, after connecting to a virtual machine, it's necessary to block local keyboard event processing and transparently transmit all local keyboard events to the virtual machine to prevent shortcut keys from switching out of the virtual machine window. However, in some scenarios, it's necessary to also send some keyboard events to the local server for processing, such as NumLock and CapsLock, to quickly synchronize the local keyboard lock key status. Current technical solutions cannot achieve this. Summary of the Invention

[0005] In view of this, the present invention provides a cloud desktop keyboard event processing method, device, equipment and storage medium, which are used to solve the technical problems of cloud desktop keyboard key state synchronization and convenient use.

[0006] According to one aspect of an embodiment of the present invention, the present invention provides a cloud desktop keyboard event processing method, which is applied to a cloud desktop client and includes:

[0007] The cloud desktop client process opens the device file mapped to the physical keyboard device in exclusive mode, reads keyboard events from the device file mapped to the physical keyboard device, and transmits the keyboard events directly to the virtual machine;

[0008] The cloud desktop client process simulates a virtual keyboard device in user space and writes keyboard events that do not need to be shielded to the device file mapped by the virtual keyboard device. The keyboard events that do not need to be shielded are keyboard events read from the device file mapped by the physical keyboard device.

[0009] Furthermore, the method further comprises:

[0010] The XServer obtains the keyboard events that do not need to be shielded by reading the device file mapped by the virtual keyboard device, and then forwards the designated keyboard events that do not need to be shielded to each XClient for processing.

[0011] Furthermore, the cloud desktop client process uses Uinput to simulate a virtual keyboard device in user space.

[0012] Furthermore, the keyboard events that do not need to be shielded are keyboard events generated by the NumLock key, the CapsLock key, or the ScrollLock key.

[0013] Based on another aspect of the embodiment of the present invention, the present invention further provides a cloud desktop keyboard event processing device, which is applied to a device where a cloud desktop client is located, and the device includes:

[0014] An event transparent transmission module is used to open the device file mapped by the physical keyboard device in exclusive mode, read keyboard events from the device file mapped by the physical keyboard device, and transmit the keyboard events directly to the virtual machine;

[0015] The non-shielded module is used to simulate a virtual keyboard device in user space and write keyboard events that do not need to be shielded to the device file mapped by the virtual keyboard device. The keyboard events that do not need to be shielded are keyboard events read from the device file mapped by the physical keyboard device.

[0016] In the technical solution provided by the present invention, a cloud desktop client process opens the device file mapped to a physical keyboard device in exclusive mode, reads keyboard events from the device file mapped to the physical keyboard device, and transmits the keyboard events directly to the virtual machine. Simultaneously, a virtual keyboard device is simulated in user space, and keyboard events that do not need to be blocked are written to the device file mapped to the virtual keyboard device. This invention can block local keyboard events while omitting key events that do not need to be blocked, achieving synchronization between the local security state and the virtual machine, and improving the convenience of cloud desktop applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments of the present invention or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings of the embodiments of the present invention.

[0018] Figure 1 A schematic diagram of the overall architecture of the X Window System;

[0019] Figure 2 A hierarchical diagram of the Linux input subsystem architecture;

[0020] Figure 3 A schematic diagram of the steps of a cloud desktop keyboard event processing method provided by one embodiment of the present invention;

[0021] Figure 4 A schematic diagram of the structure of a cloud desktop keyboard event processing device provided by one embodiment of the present invention;

[0022] Figure 5 The present invention provides a schematic structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the embodiments of the present invention. The singular forms "a," "the," and "the" used in the embodiments of the present invention are also intended to include the plural forms, unless the context clearly indicates otherwise. The term "and / or" used in the present invention refers to any and all possible combinations of one or more of the associated listed items.

[0024] It should be understood that although the terms "first," "second," "third," etc. may be used to describe various information in embodiments of the present invention, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, without departing from the scope of embodiments of the present invention, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the term "if" may also be interpreted as "when," "when," or "in response to determining."

[0025] The technical solution provided by the present invention relates to processing keyboard events by a Linux system cloud desktop client and an input subsystem framework of the Linux system.

[0026] The present invention aims to provide a cloud desktop keyboard event processing method, the purpose of which is to achieve the following two purposes after the cloud desktop client (hereinafter referred to as the client) is connected to the virtual machine:

[0027] (1) Except for the specified keyboard events, the processing of local keyboard events is shielded on the client side, that is, the key events that do not need to be shielded are omitted while the local keyboard event shielding effect is obtained;

[0028] (2) Transmit all local keyboard events on the client to the virtual machine side.

[0029] The technical solution provided by the present invention can realize the transparent transmission of keyboard events from the local Linux system cloud desktop client to the virtual machine, thereby improving the convenience of cloud desktop applications.

[0030] X Window is a software window system that uses a bitmap display and adopts a client / server architecture. In the X Window system, the client (C) is the program execution side, on which various X programs are executed, while the server (S) is responsible for displaying the window of the client program.

[0031] The X Window System consists of three parts: the X server, the X client, and the X protocol. The X server primarily controls input and output, maintaining resources such as fonts and colors. It receives input from input devices and passes it to the X client. The X client processes this information and returns information, which the X server also outputs to the output device (such as a monitor). Information transmitted by the X server to the X client is called an event, primarily information about input devices such as the keyboard and mouse, and the status of windows. Information transmitted by the X client to the X server is called a request, primarily requesting the X server to create a window, resize the window, or draw or output text on the window. The X client primarily performs application computing and does not accept user input. All input is sent to the X server, which then passes it to the X client in the form of an event. After the X client processes the received event, if it needs to output the information to the screen or change the appearance of the screen, it sends a request to the X server, which then displays the information.

[0032] Figure 1 This is a diagram of the overall architecture of the X Window System. The Linux input subsystem consists of three layers from top to bottom: the event handler layer, the input core layer, and the device driver layer.

[0033] Device driver layer: mainly implements read and write access to hardware devices, interrupt settings, and converts events generated by the hardware into specifications defined by the core layer and submits them to the event processing layer.

[0034] Core layer: Provides specifications and interfaces for the device driver layer. The device driver layer only needs to worry about how to drive the hardware and obtain hardware data (such as pressed button data). Then, it calls the interface provided by the core layer, and the core layer automatically submits the data to the event processing layer.

[0035] Event processing layer: The event processing layer is a user-programmed interface (device node) used to process data submitted by the driver layer.

[0036] The processing chain of an input event is: from the device driver layer of the specific device -> input driver layer -> input core layer -> event handler layer -> user space. Finally, the input event is passed to the application.

[0037] Figure 2 This is a layered diagram of the Linux input subsystem architecture. As shown in the figure, the keyboard device is ultimately mapped to the user layer as a device file, such as / input / event0. The XServer reads this file to obtain keyboard input events and then forwards the events to each XClient for processing.

[0038] Figure 3 The following is a flowchart of a method for processing cloud desktop keyboard events based on the Linux input subsystem architecture and the X Windows system architecture according to an embodiment of the present invention. The method includes:

[0039] Step 301: The cloud desktop client process opens the device file mapped to the physical keyboard device in exclusive mode, reads keyboard events from the device file mapped to the physical keyboard device, and transmits the keyboard events directly to the virtual machine;

[0040] This step directly uses the open function to open the device mapping file for the keyboard device, for example, / input / event0. Using the ioctl function in the device driver, the device file is set to EVIOCGRAB mode. This opens the keyboard device mapping file in exclusive mode and captures keyboard events from the device file. Because the keyboard device mapping file is opened in exclusive mode, the XServer cannot read keyboard input events from the device file, effectively shielding local keyboard events. Furthermore, the read keyboard events are transparently transmitted to the virtual machine in the cloud.

[0041] Step 302: The cloud desktop client process simulates a virtual keyboard device in user space and writes keyboard events that do not need to be masked to the device file mapped by the virtual keyboard device. The keyboard events that do not need to be masked are keyboard events read from the device file mapped by the physical keyboard device.

[0042] Uinput is a kernel module that can simulate input devices from user space. The cloud desktop client process can use Uinput to create a virtual input device with specific functions, such as a keyboard device.

[0043] After creating a virtual keyboard device, the cloud desktop client process can write specific keyboard events that do not need to be blocked to the device file mapped to the virtual keyboard device, such as " / dev / Uinput" or " / dev / input / Uinput". The written keyboard events are then passed to user space and kernel users. The XServer obtains the specified keyboard events that do not need to be blocked by reading the keyboard events from the device file mapped to the virtual keyboard device and distributes them to each window. The specified events that do not need to be blocked can be the keyboard events corresponding to pressing the NumLock key, CapsLock key, or ScrollLock key.

[0044] Through the above steps, it is equivalent to sending the specified keyboard events that do not need to be blocked to the cloud virtual machine while skipping the specified keyboard events that do not need to be blocked locally and sending them to the local system for processing, so that the status of these keys is synchronized with the virtual machine.

[0045] Through the technical solution provided by the present invention, local keyboard events can be shielded while key events that do not need to be shielded are omitted, so that the local security status is synchronized with the virtual machine, and the convenience of cloud desktop applications is improved.

[0046] Figure 4 This is a schematic diagram of the structure of a cloud desktop keyboard event processing device provided by one embodiment of the present invention. The functional modules in device 400 can be implemented using software, hardware, or a combination of software and hardware. Device 400 is applied to the device where the cloud desktop client resides and includes: an event transparent transmission module 401 and a non-shielding module 402.

[0047] The event transparent transmission module 401 is used to open the device file mapped by the physical keyboard device in exclusive mode, read the keyboard event from the device file mapped by the physical keyboard device and transmit the keyboard event directly to the virtual machine;

[0048] The non-shielding module 402 is used to simulate a virtual keyboard device in user space and write keyboard events that do not need to be shielded to the device file mapped by the virtual keyboard device. The keyboard events that do not need to be shielded are keyboard events read from the device file mapped by the physical keyboard device.

[0049] Furthermore, the XServer obtains keyboard events that do not need to be shielded by reading the device file mapped by the virtual keyboard device, and then forwards the designated keyboard events that do not need to be shielded to each XClient for processing.

[0050] Furthermore, the non-shielded module 402 uses Uinput to simulate a virtual keyboard device in the user space.

[0051] The keyboard events that do not need to be shielded may be keyboard events generated by keys such as the NumLock key, the CapsLock key, or the ScrollLock key.

[0052] Figure 5 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. The device 500 includes: a processor 510, such as a central processing unit (CPU), a communication bus 520, a communication interface 540, and a storage medium 530. The processor 510 and the storage medium 530 can communicate with each other via the communication bus 520. The storage medium 530 stores a computer program, which, when executed by the processor 510, implements the functions of each step of the method provided in the present invention.

[0053] The storage medium may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk storage. In addition, the storage medium may also be at least one storage device located away from the aforementioned processor. The processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component.

[0054] It should be appreciated that embodiments of the present invention can be implemented or implemented by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory memory. The methods described can be implemented in a computer program using standard programming techniques, including a non-transitory storage medium configured with a computer program, wherein the storage medium configured in this manner causes the computer to operate in a specific and predefined manner. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if desired, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. In addition, the program can be run on a programmed application-specific integrated circuit for this purpose. In addition, the operations of the processes described in the present invention can be performed in any suitable order, unless otherwise indicated by the present invention or otherwise clearly contradicted by the context. The processes described in the present invention (or variations and / or combinations thereof) can be executed under the control of one or more computer systems configured with executable instructions and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed collectively on one or more processors, by hardware, or a combination thereof. The computer program includes multiple instructions that can be executed by one or more processors.

[0055] Further, the method can be implemented in any type of computing platform that is operably connected to a suitable computer, including but not limited to a personal computer, a minicomputer, a mainframe, a workstation, a network or distributed computing environment, a separate or integrated computer platform, or in communication with a charged particle tool or other imaging device, etc. Various aspects of the present invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, an optical read and / or write storage medium, RAM, ROM, etc., so that it can be read by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the process described herein. In addition, the machine-readable code, or portions thereof, can be transmitted over a wired or wireless network. When such media includes instructions or programs that implement the steps described above in conjunction with a microprocessor or other data processor, the present invention includes these and other different types of non-transitory computer-readable storage media. When programmed according to the methods and techniques of the present invention, the present invention also includes the computer itself.

[0056] The foregoing is merely an embodiment of the present invention and is not intended to limit the present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A cloud desktop keyboard event processing method, characterized in that: The method is applied to a cloud desktop client, and the method includes: The cloud desktop client process opens the device file mapped to the physical keyboard device in exclusive mode, reads keyboard events from the device file mapped to the physical keyboard device, and transmits the keyboard events directly to the virtual machine. When the device file is opened in exclusive mode by the cloud desktop client process, the XServer cannot read the keyboard input events in the device file. The cloud desktop client process simulates a virtual keyboard device in user space and writes keyboard events that do not need to be shielded to the device file mapped by the virtual keyboard device. The keyboard events that do not need to be shielded are keyboard events read from the device file mapped by the physical keyboard device.

2. The method according to claim 1, characterized in that The method further comprises: The XServer obtains the keyboard events that do not need to be shielded by reading the device file mapped by the virtual keyboard device, and then forwards the designated keyboard events that do not need to be shielded to each XClient for processing.

3. The method according to claim 1, characterized in that The cloud desktop client process uses Uinput to simulate a virtual keyboard device in user space.

4. The method according to claim 1, wherein The keyboard events that do not need to be shielded are keyboard events generated by the NumLock key, the CapsLock key, or the ScrollLock key.

5. A cloud desktop keyboard event processing device, characterized in that: The device is applied to the device where the cloud desktop client is located, and the device includes: An event transparent transmission module is used to open the device file mapped to the physical keyboard device in exclusive mode, read keyboard events from the device file mapped to the physical keyboard device, and transmit the keyboard events directly to the virtual machine. When the device file is opened in exclusive mode by the cloud desktop client process, the XServer cannot read the keyboard input events in the device file; The non-shielded module is used to simulate a virtual keyboard device in user space and write keyboard events that do not need to be shielded to the device file mapped by the virtual keyboard device. The keyboard events that do not need to be shielded are keyboard events read from the device file mapped by the physical keyboard device.

6. The device according to claim 5, characterized in that The XServer obtains the keyboard events that do not need to be shielded by reading the device file mapped by the virtual keyboard device, and then forwards the designated keyboard events that do not need to be shielded to each XClient for processing.

7. The device according to claim 5, characterized in that The unshielded module uses Uinput to simulate a virtual keyboard device in user space.

8. The device according to claim 5, characterized in that The keyboard events that do not need to be shielded are keyboard events generated by the NumLock key, the CapsLock key, or the ScrollLock key.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a storage medium and a communication bus, wherein the processor, the communication interface and the storage medium communicate with each other via the communication bus; Storage medium for storing computer programs; A processor, configured to implement the method steps described in any one of claims 1 to 4 when executing a computer program stored on a storage medium.

10. A storage medium having a computer program stored thereon, characterized in that: The computer program implements the method steps of any one of claims 1 to 4 when executed by a processor.

Images