Seat event filtering method, system and device under multi-seat desktop environment

Abstract

This invention relates to a method, system, and device for filtering seat events in a multi-seat desktop environment. Addressing the current issue of window event confusion caused by multi-seat collaborative operation, a window event filtering mechanism is designed. By adding a new protocol for setting window filtering, input events from specified seats are filtered out on designated windows. This simplifies the adaptation process from a single-seat application to a multi-seat system. Applications can avoid multi-seat event confusion simply through protocol communication without modifying the program's event handling logic. Furthermore, from the perspective of security and stability during multi-seat collaborative operation, it restricts the seats operating the application window, preventing interference between seat operations and achieving better multi-seat event error prevention.

Description

Technical Field

[0001] This invention belongs to the field of computer technology and relates to a method, system and device for filtering seat events in a multi-seat desktop environment. Background Technology

[0002] With the continuous improvement of computer performance, a single computer is sufficient to meet the performance needs of multiple users in everyday use scenarios. To improve the utilization of computer hardware resources and support scenarios where multiple users share the same computer, the concept of multiple seats has been introduced into operating systems. The system allocates hardware resources for input / output interaction on a seat-by-seat basis, allowing different users to operate the same computer simultaneously.

[0003] Each user seat can be assigned a keyboard and mouse for input interaction. Input events from different seats are forwarded to the application window with seat information for differentiation. The application window can distinguish the source of the event using this information, allowing it to respond separately to events from different seats even when two seats are operating the same window simultaneously. However, in traditional single-seat systems, some applications do not distinguish the source seat of an event. If such applications run on a multi-seat system and are operated by multiple seats simultaneously, unpredictable results can occur. For example, if two mice simultaneously press their left buttons, the application will receive two consecutive press events without any release events. This is an abnormal situation for programs that only focus on a single seat, potentially leading to program logic chaos or even crashes. Furthermore, for applications supporting multiple seats, it's necessary to limit the number of seats that can operate simultaneously. For example, a two-player game should only support two simultaneous operations, ignoring events from other seats. Therefore, preventing errors when the system receives events from multiple seats simultaneously becomes a technical problem that needs to be solved. Summary of the Invention

[0004] To address the problems existing in the above-mentioned traditional technologies, this invention proposes a seat event filtering method in a multi-seat desktop environment, a multi-seat multi-device computer system, and a computer device, which can avoid errors when the system receives events from multiple seats simultaneously.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0006] On the one hand, a method for filtering seat events in a multi-seat desktop environment is provided, including the following steps:

[0007] In a multi-seat desktop environment, after the window manager receives the input event of the current seat, it performs a data pair query and matching in the filter list based on the seat identifier of the current seat. The filter list is used to record the data pair consisting of the identifier of the specified window and the identifier of the specified seat passed by the application through Protocol 1. The filter list is maintained by the window manager. The data pair is used to instruct the window manager not to forward the input event of the specified seat to the specified window. The protocol parameters of Protocol 1 include the seat identifier of the specified seat and the window identifier of the specified window.

[0008] If a data pair matching the seat identifier of the current seat is found in the filter list, the window manager does not forward the input event of the current seat to the specified window corresponding to the matching data pair;

[0009] If no data pair matching the current seat identifier is found in the filter list, the window manager forwards the input event for the current seat to the specified window corresponding to the matching data pair.

[0010] On the other hand, a multi-seat, multi-device computer system is also provided, including a window manager and multiple seats. In a multi-seat desktop environment, after the window manager receives an input event from the current seat, it performs a data pair query and matching in a filter list based on the seat identifier of the current seat. The filter list is used to record data pairs consisting of the identifier of a specified window and the identifier of a specified seat passed by the application through Protocol 1. The filter list is maintained by the window manager. The data pairs are used to instruct the window manager not to forward the input event of the specified seat to the specified window. The protocol parameters of Protocol 1 include the seat identifier of the specified seat and the window identifier of the specified window.

[0011] If a data pair matching the current seat's identifier is found in the filter list, the window manager does not forward the current seat's input event to the specified window corresponding to the matching data pair. If no data pair matching the current seat's identifier is found in the filter list, the window manager forwards the current seat's input event to the specified window corresponding to the matching data pair.

[0012] In another aspect, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for filtering seat events in a multi-seat desktop environment.

[0013] One of the above technical solutions has the following advantages and beneficial effects:

[0014] The aforementioned methods, systems, and devices for filtering seat events in multi-seat desktop environments address the current issue of window event chaos caused by multi-seat collaborative operations. They research and design a window event filtering mechanism by adding a new protocol for setting window filtering, which filters out input events from specified seats on designated windows. This simplifies the adaptation process from the perspective of adapting single-seat applications to multi-seat systems. Applications can avoid multi-seat event chaos simply through protocol communication without modifying the program's event handling logic. Furthermore, from the perspective of security and stability during multi-seat collaborative operations, it also restricts the seats operating the application window, preventing interference between seat operations and achieving a better multi-seat event error prevention effect. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating a seat event filtering method in a multi-seat desktop environment in one embodiment;

[0017] Figure 2 This is a flowchart illustrating a seat event filtering method in a multi-seat desktop environment, as described in another embodiment.

[0018] Figure 3 This is a block diagram of a multi-seat, multi-device computer system in one embodiment. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention.

[0020] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0021] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0022] In one embodiment, such as Figure 1 As shown, a method for filtering seat events in a multi-seat desktop environment is provided, which may include the following steps S12 to S14:

[0023] S12, In a multi-seat desktop environment, after the window manager receives the input event of the current seat, it performs a data pair query and matching in the filter list according to the seat identifier of the current seat. The filter list is used to record the data pair consisting of the identifier of the specified window and the identifier of the specified seat passed by the application through Protocol 1. The filter list is maintained by the window manager. The data pair is used to instruct the window manager not to forward the input event of the specified seat to the specified window. The protocol parameters of Protocol 1 include the seat identifier of the specified seat and the window identifier of the specified window.

[0024] S13, if a data pair matching the seat identifier of the current seat is found in the filter list, then the window manager does not forward the input event of the current seat to the specified window corresponding to the matching data pair;

[0025] S14. If no data pair matching the seat identifier of the current seat is found in the filter list, the window manager forwards the input event of the current seat to the specified window corresponding to the matching data pair.

[0026] It is understood that the interactive devices that can be bound to each seat can include, but are not limited to, devices such as a computer mouse, keyboard, and touchpad. The computer's window manager can display the seat information on the screen. There can be one or more screens currently connected to the computer, and each screen can be bound to one or more seats. This embodiment configures a new communication protocol between the window and the window manager (where Protocol 1 and Protocol 2 below can be configured according to the communication protocol format applicable between the computer's application and the window manager):

[0027] Protocol 1: This protocol instructs the window manager to reject input events from a specified user. Its parameters include the user's identifier (such as the user's name or other unique identifier) ​​and the window's identifier (such as the window name or other unique identifier). When Protocol 1 is sent from the specified window to the window manager, the window manager prevents the specified window from receiving input events from the specified user. By configuring Protocol 1 to be sent multiple times, the specified window can reject input events from multiple specified users. In other words, Protocol 1 instructs the window manager to set the specified window to filter input events from the specified user. The specified window can be any window already created in the system.

[0028] When the system first runs in a multi-seat desktop environment, the filter list maintained internally by the window manager can be updated by sending Protocol 1 with different configurations multiple times. This filter list records multiple pairs of windows and seats that require event filtering, allowing windows to reject events from certain seats or accept only events from a specified seat, thus avoiding errors caused by receiving events from multiple seats simultaneously. Alternatively, the filter list can be pre-configured using Protocol 1 based on the user's environment after system design and before delivery, so that users can avoid the step of configuring the filter list online when using the system, thereby improving efficiency.

[0029] The aforementioned method for filtering seat events in multi-seat desktop environments addresses the current issue of window event chaos caused by multi-seat collaborative operations. It designs a window event filtering mechanism by adding a new protocol for setting window filtering, filtering input events from specific seats on designated windows. This simplifies the adaptation process from the perspective of adapting single-seat applications to multi-seat systems. Applications can avoid multi-seat event chaos simply through protocol communication without modifying the program's event handling logic. Furthermore, from the perspective of security and stability during multi-seat collaborative operations, it restricts the seats operating on the application window, preventing interference between seat operations and achieving a better multi-seat event error prevention effect.

[0030] In another embodiment, such as Figure 2 As shown, the above-described method for filtering seat events in a multi-seat desktop environment may further include the following steps before step S12:

[0031] S10, after booting into the multi-seat desktop environment in multi-seat mode, wait for the system to automatically create all seats and complete the binding of interactive devices for each seat;

[0032] S11, when the application sends Protocol 1 to the window manager after creating any specified window, the window manager obtains the data pair of the specified window and the specified seat passed in by Protocol 1 and stores it in the filter list.

[0033] Specifically, in this embodiment, after the system starts up and enters the multi-seat desktop environment in a multi-seat mode, it automatically creates all seats according to the given seat usage requirements and waits for the users currently joining the system to complete the binding of interactive devices for each seat.

[0034] Next, the application (software program APP) can set up seat event filtering. For example, after creating any specified window, it can send Protocol 1 to the window manager so that the identifier of the specified window and the specified seat can be passed to the window manager through the protocol parameters configured in Protocol 1. In subsequent processing, the input events of the specified seats that need to be filtered can be set on the specified window.

[0035] The window manager responds to Protocol 1 and executes the setting process for filtering input events on a specified window for a specified seat. Specifically, the window manager maintains an internal filter list to store data pairs between windows and seats, recording the specified seats that each window needs to reject. When the window manager receives Protocol 1, it records the data pairs between the specified window and the specified seat (such as the window identifier of the specified window and the seat identifier of the specified seat) passed in the protocol parameters configured in Protocol 1 into the filter list, thereby allowing users to configure or update the filter list online using Protocol 1.

[0036] When forwarding an input event from a specific seat to a specified window, the window manager needs to query the filter list based on the seat identifier of the source seat of the input event. If a seat identifier matching the source seat of the input event exists in the filter list, it means that the specific seat (i.e., the source seat of the input event) is the specified seat for which the input event is filtered by the specified window, and the window manager will not forward the input event from that specific seat to the specified window.

[0037] In one embodiment, the above-described method for filtering seat events in a multi-seat desktop environment may further include the following steps:

[0038] When an application sends Protocol 2 to the window manager from the current window, the window manager obtains the window identifier of the current window passed in Protocol 2 and removes the data pairs that match the window identifier of the current window from the filter list; the protocol parameters of Protocol 2 include the window identifier of the specified window.

[0039] Protocol 2 is a protocol that instructs the window manager to reset the filtering settings of a specified window. Its protocol parameters include the window identifier of the specified window. After the application sends Protocol 2 to the window manager on the specified window, the window manager will cause the specified window to stop filtering input events for the specified seat, and the specified window will receive input events from all seats. In other words, Protocol 2 is used to instruct the window manager to reset the input event filtering settings of the specified window.

[0040] It is understandable that if any specified window needs to reset the filtering settings, the application can send Protocol 2 to the window manager from that specified window to pass the window identifier of the specified window to the window manager, so that the window manager can clear the input event filtering settings on the specified window. After that, the application can reconfigure and send Protocol 1 to set the new input event filtering.

[0041] Upon receiving Protocol 2, the window manager retrieves the window identifier of the specified window and removes the data pair matching that window identifier from the filter list. Therefore, when the window manager forwards input events for the specified position the next time, the data pair corresponding to that specified window will not be found in the filter list, thus forwarding the input events for that specified position to that specified window. Afterward, upon receiving Protocol 1 again, the window manager can reconfigure the filter for input events for the specified position on the specified window.

[0042] In one embodiment, the above-described method for filtering seat events in a multi-seat desktop environment may further include the following steps:

[0043] When a seat is removed or a window is closed during system operation, the window manager removes data pairs matching the removed seat or closed window from the filter list.

[0044] Specifically, if any specified seat is removed or any specified window is closed during system operation, the window manager needs to remove the data pairs matching the removed specified seat or closed specified window from the filter list to free up computing resources and avoid unnecessary resource occupation.

[0045] It should be understood that, although the above process Figure 1 and Figure 2 The steps in the diagram are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed; they can be performed in other orders. Furthermore, the above process... Figure 1 and Figure 2 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0046] In one embodiment, such as Figure 3As shown, a multi-seat, multi-device computer system 100 is also provided, including a window manager and multiple seats. In a multi-seat desktop environment, after receiving an input event from the current seat, the window manager performs a data pair query and matching in a filter list based on the seat identifier of the current seat. The filter list records data pairs consisting of the identifier of a specified window and the identifier of a specified seat, passed by the application via Protocol 1. The filter list is maintained by the window manager, and the data pairs instruct the window manager not to forward the input event of a specified seat to the specified window. The protocol parameters of Protocol 1 include the seat identifier of the specified seat and the window identifier of the specified window. If a data pair matching the seat identifier of the current seat is found in the filter list, the window manager does not forward the input event of the current seat to the specified window corresponding to the matching data pair. If no data pair matching the seat identifier of the current seat is found in the filter list, the window manager forwards the input event of the current seat to the specified window corresponding to the matching data pair.

[0047] The aforementioned multi-seat, multi-device computer system 100 addresses the current issue of window event confusion caused by multi-seat collaborative operation by designing a window event filtering mechanism. By adding a new protocol for setting window filtering, input events from specified seats are filtered out on designated windows. This simplifies the adaptation process from the perspective of adapting a single-seat application to a multi-seat system. Applications can avoid multi-seat event confusion simply through protocol communication without modifying the program's event handling logic. Furthermore, from the perspective of security and stability during multi-seat collaborative operation, it can restrict the seats operating the application window, preventing interference between seat operations and achieving a better multi-seat event error prevention effect.

[0048] In one embodiment, when an application sends Protocol 1 to the window manager after creating any specified window, the window manager obtains the data pair of the specified window and the specified seat passed in by Protocol 1 and stores it in the filter list.

[0049] In one embodiment, when the application sends Protocol 2 to the window manager from the current window, the window manager obtains the window identifier of the current window passed in Protocol 2 and removes the data pairs that match the window identifier of the current window from the filter list; the protocol parameters of Protocol 2 include the window identifier of the specified window.

[0050] In one embodiment, when a seat is removed or a window is closed during system operation, the window manager removes data pairs matching the removed seat or closed window from the filter list.

[0051] It is understood that the explanations of the features in the multi-seat, multi-device computer system 100 can be understood by referring to the corresponding explanations in the embodiments of the seat event filtering method in the multi-seat desktop environment. Each module in the multi-seat, multi-device computer system 100 can be implemented entirely or partially through software, hardware, or a combination thereof. The components can be embedded in hardware or independently of a device with radar data processing capabilities, or stored in software in the memory of the aforementioned device, so that the processor can call and execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of computers already existing in the art.

[0052] In one embodiment, a computer device is also provided, including a memory and a processor. The memory stores a computer program, and the processor, when executing the computer program, implements the following processing steps: In a multi-seat desktop environment, after receiving an input event from the current seat, the window manager performs a data pair query and matching in a filter list based on the seat identifier of the current seat. If a data pair matching the seat identifier of the current seat is found in the filter list, the window manager does not forward the input event of the current seat to the designated window corresponding to the matching data pair. If no data pair matching the seat identifier of the current seat is found in the filter list, the window manager forwards the input event of the current seat to the designated window corresponding to the matching data pair. The filter list records data pairs consisting of the identifier of the designated window and the identifier of the designated seat, passed by the application via Protocol 1. The filter list is maintained by the window manager, and the data pairs instruct the window manager not to forward the input event of the designated seat to the designated window. The protocol parameters of Protocol 1 include the seat identifier of the designated seat and the window identifier of the designated window.

[0053] In one embodiment, when the processor executes the computer program, it can also implement the steps or sub-steps added in the various embodiments of the seat event filtering method in the multi-seat desktop environment described above.

[0054] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus DRAM (RDRAM), and interface DRAM (DRDRAM), etc.

[0055] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0056] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of protection of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and all such modifications and improvements fall within the scope of protection of the present invention.

Claims

1. A method for filtering seat events in a multi-seat desktop environment, characterized in that, The method comprises the steps of: In the multi-seat desktop environment, after the window manager receives the input event of the current seat, the window manager performs a data pair query matching in the filter list according to the seat identifier of the current seat; when the application sends a protocol 1 to the window manager after creating any specified window, the window manager stores the data pair of the specified window and the specified seat transmitted by the protocol 1 into the filter list, the filter list is used to record the data pair of the identifier of the specified window and the identifier of the specified seat transmitted by the application through the protocol 1, the filter list is maintained by the window manager, the data pair is used to instruct the window manager not to forward the input event of the specified seat to the specified window, the protocol 1 is a communication protocol between the window and the window manager, and is used to instruct the window manager to set the specified window to filter the input event of the specified seat; the protocol parameter of the protocol 1 comprises the seat identifier of the specified seat and the window identifier of the specified window; If the data pair matched with the seat identifier of the current seat is found in the filter list, the window manager does not forward the input event of the current seat to the specified window corresponding to the matched data pair; If the data pair matched with the seat identifier of the current seat is not found in the filter list, the window manager forwards the input event of the current seat to the specified window corresponding to the matched data pair.

2. The method of claim 1, wherein the method further comprises: In the multi-seat desktop environment, before the step that, after the window manager receives the input event of the current seat, the window manager performs a data pair query matching in the filter list according to the seat identifier of the current seat, the method further comprises the steps of: After starting to enter the multi-seat desktop environment in the multi-seat mode, waiting for the system to automatically create all seats and complete the binding of the interactive devices of the seats.

3. The method according to claim 1 or 2, wherein, The method further comprises the steps of: When the application sends a protocol 2 to the window manager in the current window, the window manager removes the data pair matched with the window identifier of the current window from the filter list after obtaining the window identifier of the current window transmitted by the protocol 2; the protocol parameter of the protocol 2 comprises the window identifier of the specified window.

4. The method of claim 3, wherein the method further comprises: The method further comprises the steps of: When the system removes a seat or closes a window during the running, the window manager removes the data pair matched with the removed seat or the closed window from the filter list.

5. A multi-seat multi-device computer system, characterized by The method comprises a window manager and a plurality of seats, in the multi-seat desktop environment, after the window manager receives the input event of the current seat, the window manager performs a data pair query matching in the filter list according to the seat identifier of the current seat; wherein when the application sends a protocol 1 to the window manager after creating any specified window, the window manager stores the data pair of the specified window and the specified seat transmitted by the protocol 1 into the filter list, the filter list is used to record the data pair of the identifier of the specified window and the identifier of the specified seat transmitted by the application through the protocol 1, the filter list is maintained by the window manager, the data pair is used to instruct the window manager not to forward the input event of the specified seat to the specified window, the protocol 1 is a communication protocol between the window and the window manager, and is used to instruct the window manager to set the specified window to filter the input event of the specified seat; the protocol parameter of the protocol 1 comprises the seat identifier of the specified seat and the window identifier of the specified window; If a data pair matching the seat identifier of the current seat is found in the filter list, the window manager does not forward the input event of the current seat to the specified window corresponding to the data pair; if a data pair matching the seat identifier of the current seat is not found in the filter list, the window manager forwards the input event of the current seat to the specified window corresponding to the data pair.

6. The multi-cay multi-device computer system of claim 5, wherein, When the application sends a protocol 2 to the window manager, the window manager removes the data pair matching the window identifier of the current window from the filter list after obtaining the window identifier of the current window from the protocol 2; the protocol parameter of the protocol 2 includes the window identifier of the specified window.

7. The multi-cay multi-device computer system of claim 6, wherein, When the seat is removed or the window is closed during the running of the system, the window manager removes the data pair matching the removed seat or the closed window from the filter list.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor implements the steps of the seat event filtering method in the multi-seat desktop environment as claimed in any one of claims 1 to 4 when executing the computer program.

Images