A data input event filtering system, method, electronic device, and medium

Abstract

This application provides a data input event filtering system, method, electronic device, and medium. The method includes a core layer comprising: an event filtering registration module for receiving a custom filtering function and writing the custom filtering function into a preset function pointer member of the device structure corresponding to the target input device; and a core event processing module for, upon receiving an event to be processed, determining whether the preset function pointer member in the device structure corresponding to the target input device sending the event is not empty, and, if the preset function pointer member is not empty, calling the corresponding custom filtering function to filter the event to be processed, and discarding the event to be processed when the custom filtering function returns a preset interception value. This application achieves cross-device reuse of filtering logic and early kernel-level interception of invalid events, improving system real-time performance and reducing resource overhead.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a data input event filtering system, method, electronic device, and medium. Background Technology

[0002] Data input systems are widely used in various electronic devices to convert hardware-generated input signals into system-recognizable event data and transmit it to user space for application processing. A typical Linux input subsystem adopts a three-layer architecture of driver layer, kernel layer, and event processing layer to achieve unified acquisition and distribution of input events.

[0003] In existing technologies, there are two main approaches to filtering input events. One is for device driver developers to hard-code filtering logic at the driver layer for a single device. This approach results in the filtering code being strongly bound to a specific device, making it unusable across different devices and increasing driver development and maintenance costs. The second approach involves the application listening to device nodes in user space and performing post-filtering. In this method, invalid events are only filtered after the kernel layer has completed its full processing, leading to wasted kernel layer resources and insufficient real-time performance. Summary of the Invention

[0004] In view of the above, the purpose of this application is to provide a data input event filtering system, method, electronic device and medium, which aims to overcome at least one of the above-mentioned defects.

[0005] Firstly, this application provides a data input event filtering system, including a core layer, the core layer comprising: The event filtering registration module is used to receive custom filtering functions and write the custom filtering functions into the preset function pointer member of the device structure corresponding to the target input device; The core event processing module is used to determine whether the preset function pointer member in the device structure corresponding to the target input device that sent the event is not empty when receiving an event to be processed. If the preset function pointer member is not empty, the module calls the corresponding custom filtering function to filter the event to be processed, and discards the event to be processed when the custom filtering function returns a preset interception value.

[0006] In one possible implementation, the data input event filtering system further includes a driver layer and an event processing layer; The driver layer is used to convert hardware signals into events to be processed and to report the events to be processed to the core layer. The event processing layer is used to receive the pending event distributed by the core layer when the pending event has not been discarded, and to transmit the pending event to the user space.

[0007] In one possible implementation, the custom filtering function is encapsulated in the kernel dynamic link file, and the event filtering registration module writes the custom filtering function into the preset function pointer member when the kernel dynamic link file is loaded.

[0008] In one possible implementation, the registration interface corresponding to the event filtering registration module is provided by exporting symbolic functions, so that the kernel dynamic link file can call the registration interface to complete the writing of the custom filtering function.

[0009] In one possible implementation, the input parameters of the custom filtering function include a device pointer pointing to the target input device and an event pointer pointing to the event to be processed, and the return value of the custom filtering function includes a pass value and a preset block value.

[0010] In one possible implementation, the custom filtering function includes a time interval filtering condition, and the preset interception value is returned when the event to be processed meets the time interval filtering condition. The time interval filtering condition includes that the time interval between two events with the same encoding on the same input device is less than a preset threshold.

[0011] In one possible implementation, the custom filtering function further includes a coordinate offset filtering condition, and the preset interception value is returned when the event to be processed satisfies the coordinate offset filtering condition, wherein the coordinate offset filtering condition includes that the coordinate offset of the touch event is less than a preset offset threshold.

[0012] Secondly, this application provides a data input event filtering method, including: The event filtering registration module is used to receive custom filtering functions and write the custom filtering functions into the preset function pointer member of the device structure corresponding to the target input device; The core event processing module is used to determine whether the preset function pointer member in the device structure corresponding to the target input device that sent the event is not empty when receiving an event to be processed. If the preset function pointer member is not empty, the module calls the corresponding custom filtering function to filter the event to be processed, and discards the event to be processed when the custom filtering function returns a preset interception value.

[0013] Thirdly, this application also provides an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the method described above are performed.

[0014] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the method described above.

[0015] This application provides a data input event filtering system, method, electronic device, and medium. The method includes a core layer comprising: an event filtering registration module for receiving a custom filtering function and writing the custom filtering function into a preset function pointer member of the device structure corresponding to the target input device; and a core event processing module for, upon receiving an event to be processed, determining whether the preset function pointer member in the device structure corresponding to the target input device sending the event is not empty, and, if the preset function pointer member is not empty, calling the corresponding custom filtering function to filter the event to be processed, and discarding the event to be processed when the custom filtering function returns a preset interception value. This application achieves cross-device reuse of filtering logic and early kernel-level interception of invalid events, improving system real-time performance and reducing resource overhead.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is one of the structural schematic diagrams of a data input event filtering system provided in an embodiment of this application; Figure 2 This is a second schematic diagram of the structure of a data input event filtering system provided in an embodiment of this application; Figure 3 A flowchart illustrating a data input event filtering method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0020] First, the applicable scenarios for this application will be introduced. This application can be applied to the field of data processing technology.

[0021] Research has revealed that the Linux input subsystem is the core framework in the Linux kernel for handling various input devices such as keyboards, mice, and touchscreens. It adopts a three-layer architecture design consisting of a device driver layer, a kernel layer, and an event handling layer, which realizes the unified collection, transmission, and distribution of input device events, and provides a standardized device access interface for user-space applications.

[0022] In existing technologies, hardware signals generated by input devices are converted into events in the format of an `input_event` structure by the driver layer. These events are then processed initially by the core layer, distributed by the event handling layer, and finally transmitted to the ` / dev / input / eventX` device node in user space. Applications then retrieve event information by reading this node. This subsystem's design focuses on standardized event transmission and unified device management, refining a universal interface for driver development and significantly simplifying the input device driver development process.

[0023] However, the input subsystem of existing natively distributed Linux systems lacks event filtering functionality, making it impossible to filter and intercept invalid, falsely triggered, or events specific to business needs during the event flow. Existing technologies generally address event filtering in two ways: First, by writing filtering logic at the device driver layer, with driver developers customizing event filtering rules based on hardware characteristics. However, the implementation of drivers for different input devices varies significantly, making the filtering logic unreusable, resulting in code redundancy, poor portability, and increased costs for driver development and maintenance. Second, by listening to the / dev / input / eventX device node in user space, reading events, and then manually filtering valid events. This method requires repeatedly writing filtering code in user space, consuming system resources and resulting in low real-time performance due to events only being filtered after the entire kernel layer processing is complete. Furthermore, the end-to-end transmission of invalid events wastes kernel layer resources.

[0024] The root cause is that the Linux input subsystem was not designed with a general event filtering registration point and a unified filtering interface. The core layer's input_handle_event function only performs event validity checks and pre-dispatch processing, without any entry point for embedding third-party filtering logic. As a result, the filtering function is not uniformly implemented at the subsystem level, and developers can only meet their needs through "custom development." This affects the generality of the subsystem and causes redundant consumption of development resources. At the same time, the user-space post-filtering method cannot solve the problem of invalid event processing overhead at the kernel level.

[0025] Based on this, embodiments of this application provide a data input event filtering system, method, electronic device, and medium, which solves the technical problem that existing data input systems cannot implement general pre-event filtering at the core layer, resulting in the need for custom development of filtering logic at the driver layer or post-processing in user space, thus causing development redundancy and waste of kernel resources. It realizes cross-device reuse of filtering logic and early interception of invalid events at the kernel layer, improving system real-time performance and reducing resource overhead.

[0026] Please see Figure 1 , Figure 1 This is one of the structural schematic diagrams of a data input event filtering system provided in an embodiment of this application. Figure 1 As shown in the figure, the data input event filtering system provided in this application embodiment includes a core layer 100, which includes an event filtering registration module 101 and a core event processing module 102.

[0027] Specifically, this system is applied to the data input subsystem, which is the basic framework in the operating system kernel used to handle various input devices such as keyboards, mice, and touch screens.

[0028] Please see Figure 2 , Figure 2 This is a second schematic diagram of a data input event filtering system provided in an embodiment of this application. Figure 2 As shown, the data input subsystem of this application adopts a layered design, which is divided into a driver layer 200, a core layer 100 and an event processing layer 300.

[0029] The driver layer 200 interacts directly with the physical hardware, responsible for converting hardware signals such as button presses and coordinate movements into unified format events to be processed, and then passing them up to the core layer 100. The event handling layer 300 is responsible for further forwarding the events allowed by the core layer 100 to user space. Applications obtain input events by reading specific device node files, which are typically named like dev / input / eventX. The core layer 100 sits between the two layers, acting as an event relay hub. All events from the driver layer 200 must be processed by the core layer 100, which then decides whether to distribute them to the event handling layer 300.

[0030] This application enhances the functionality of the core layer 100. While keeping the original logic of the driver layer 200 and the event handling layer 300 completely unchanged, a general event filtering framework is embedded in the core layer 100 through incremental modification, so as to intercept invalid or unexpected events at the front end of the event flow path.

[0031] Specifically, the event filtering registration module 101 is used to receive custom filtering functions and write the custom filtering functions into the preset function pointer member of the device structure corresponding to the target input device.

[0032] Here, a custom filter function refers to a piece of judgment logic written by the developer according to specific business needs. Its core function is to check whether each input event meets the release conditions.

[0033] The device structure is a file maintained by the data input subsystem for each input device, recording attribute information such as which event types the device supports and which buttons or axes it has.

[0034] The default function pointer member is a newly created storage slot in this file, specifically used to store the entry address of the custom filtering function in memory.

[0035] The event filtering registration module 101 is equivalent to a standard mounting interface. When the developer submits the written filtering function to this module, the module will record the address of the function in the file slot of the target device, thereby completing the binding between the filtering function and the specific device.

[0036] At the implementation level, the event filter registration module 101 corresponds to a newly added registration function in the core layer 100 of the data input subsystem, named `input_register_event_filter`. This function accepts two parameters: the first, `dev`, is a pointer to the target input device file, and the second, `filter`, is a pointer to a custom filter function. Inside the function body, it first checks if `dev` is valid. If valid, it performs an assignment operation, storing the value of `filter` in the `event_filter` member of the device file pointed to by `dev`. This `event_filter` member is the aforementioned preset function pointer member. Through this simple assignment, the binding relationship between the filter function and the device is established. To allow other independently compiled modules in the kernel to easily call this registration function, the event filter registration module 101 also exports the function's symbol to the kernel's global symbol table using the `EXPORT_SYMBOL` macro. This is equivalent to making the name and address of the `input_register_event_filter` function public, allowing any kernel module to directly call it by including the corresponding header file.

[0037] The default function pointer member `event_filter` is defined in the device structure `struct input_dev`, which is declared in the header file `input.h` of the data input subsystem. `event_filter` is a function pointer that must follow the signature convention of taking a device pointer of type `struct input_dev` and an event pointer of type `struct input_event` as input parameters and returning a boolean value. When the value of `event_filter` is null, it means that no filter is installed on the device; when the value of `event_filter` is not null, it means that a filter is installed on the device, and the corresponding filter function can be found through this value. Simultaneously, the declaration of the registration function `input_register_event_filter` is also added to the `input.h` header file, adjacent to the declaration of the device registration function `input_register_device`, so that any code including this header file will be aware of the existence of the registration function and its parameter format.

[0038] The core event processing module 102, upon receiving an event to be processed, determines whether the preset function pointer member in the device structure corresponding to the target input device sending the event is not null. If the preset function pointer member is not null, it calls the corresponding custom filtering function to filter the event to be processed, and discards the event to be processed when the custom filtering function returns a preset interception value. In other words, the core event processing module 102 is an intelligent checkpoint on the event flow path. Whenever an event arrives, it first checks the file of the source device to see if a filtering function has been installed in the filtering slot. If the slot is empty, it means that no filtering is needed, and the event is allowed to pass normally; if the slot is not empty, the filtering function must be executed first, and the return value of the filtering function determines whether the event should continue or be discarded.

[0039] From the perspective of kernel source code modification, the core event handling module 102 directly corresponds to the core processing function input_handle_event in the core layer 100 of the data input subsystem. This application precisely embeds filtering and judgment code into the existing logic of this function while fully preserving its original functionality.

[0040] The specific modification is as follows: Inside the `input_handle_event` function, a temporary event structure of type `struct input_event`, named `temp_event`, is first defined. Its purpose is to provide a uniformly formatted copy of the event for the filtering function. Next, after the original device inaccessibility check in the function, the three key fields of the current event—event type, event code, and event value—are filled into the corresponding members of `temp_event`. The event type distinguishes different events such as button presses, relative displacement events, or absolute coordinate events; the event code specifies the specific button number or axis number; and the event value indicates whether the event was pressed, released, or a specific numerical value. After filling in the data, the newly added filtering judgment step begins.

[0041] The filtering logic can be described in natural language as follows: First, check if the `event_filter` member in the device file is not empty. If it is not empty, call the custom filtering function pointed to by this member with the device pointer `dev` and the address of the temporary event structure `&temp_event` as parameters. After obtaining the returned boolean value, perform a logical inversion operation on it. If the inverted condition is true, that is, the filtering function returned a false value, then execute the `return` statement, the function ends directly, the event is discarded, and it will not enter any subsequent dispatch process. If the inverted condition is false, that is, the filtering function returned a true value, then skip the `return` statement, continue to execute the original subsequent code of the `input_handle_event` function, and normally dispatch the event to the event handling layer 300. This implementation places the filtering logic at the choke point of event handling, so that the intercepted event is terminated within the core layer 100, avoiding all subsequent irrelevant processing overhead.

[0042] To make the whole solution clearer, this application provides a detailed description of the complete workflow after the data input event filtering system is started.

[0043] Hardware devices generate physical actions, such as a user pressing a key or touching the screen. Driver layer 200 captures this hardware signal and encapsulates it into a processable event according to the format specified by the data input subsystem. The event body contains three information fields: type, encoding, and value. Driver layer 200 then calls the reporting interfaces provided by the system, such as `input_report_key` for reporting key events and `input_report_abs` for reporting absolute coordinate events. These reporting interfaces ultimately converge on the same entry function, `input_event`, which sends the event to core layer 100.

[0044] Upon receiving an event, the `input_event` function first performs a validity check: it examines the bitmap of supported event types in the current device profile to determine if the event type is within the supported range. If not, the function returns immediately, and the event is discarded. If supported, it continues to call the core event handling function `input_handle_event`.

[0045] The `input_handle_event` function first checks if the device is disabled. If the device is temporarily disabled for some reason, the function returns immediately, and the event is discarded. If the device is normally enabled, a temporary event structure `temp_event` is prepared, and the event type, encoding, and value are assigned to the corresponding fields of `temp_event`. Next, the function queries the device file that sent the event and retrieves the `event_filter` member.

[0046] If the value of event_filter is empty, it means that the device has never registered any filtering function. The input_handle_event function will no longer perform any filtering action, but will directly follow the original event handling path, send the event to the event handling layer 300, and finally write it to the corresponding device node file for the user space application to read.

[0047] If the value of event_filter is not empty, it indicates that the device has been bound to a custom filter function. In this case, the input_handle_event function calls the filter function through the address stored in event_filter, and passes in the device pointer dev and the pointer to the temporary event structure &temp_event.

[0048] The invoked custom filtering function reviews events according to rules pre-written by the developer. The function's interface is standardized and simple: input parameters are pointers to the device file and the event structure; the return value is a boolean, with a true value indicating permission and a false value indicating blocking. Developers only need to focus on their filtering logic, without needing to concern themselves with the subsystem's internal implementation.

[0049] In practical applications, filtering functions can accommodate diverse filtering conditions. For example, in an implementation that includes time interval filtering, the filtering function records the timestamp of the last occurrence of the same device and the same event code. When a new event arrives, the time difference between it and the previous event is calculated. If the time difference is less than a preset time threshold, the event is considered a false trigger or physical jitter, and the filtering function returns a false value as the preset blocking value; only when the time difference is greater than or equal to the threshold is a true value returned, allowing the event to proceed. This filtering condition is highly effective in eliminating key bounce and suppressing repeated reporting; the threshold can typically be set to 200 milliseconds.

[0050] In another implementation that includes coordinate offset filtering, the filtering function is specifically designed for touch events. On each call, it compares the coordinates of the current event with previously recorded coordinates and calculates the offset. If the offset is less than a preset offset threshold, it is considered an invalid minor jitter or noise, and a false value is returned for blocking; only when the offset is large enough is it considered a valid swipe or click, and a true value is returned for passage. The aforementioned time interval and coordinate offset conditions can be used independently or combined within the same filtering function to adapt to more complex business scenarios.

[0051] Regardless of the rules used internally by the filtering function, when it returns a false value, the filtering condition of the core event handling module 102 is immediately met, and a return statement is executed. The event is discarded on-site in the core layer 100 and will not be passed on. When the filtering function returns a true value, the filtering condition is not met, and the core event handling module 102 continues to execute the original distribution process. The event eventually reaches the user space via the event handling layer 300.

[0052] This application supports dynamic loading and unloading of filtering functions. In practical engineering, custom filtering functions, along with device binding logic, can be encapsulated in a kernel dynamic link file, commonly known as a .ko file. A .ko file is the binary format of a Linux kernel module, which can be loaded into the kernel during system runtime via specific commands and can also be unloaded at any time. Developers, following kernel module programming specifications, write the filtering function and registration call into the module's initialization function. During module loading, `input_register_event_filter` is automatically called to mount the filtering function to the `event_filter` slot of the specified device; in the module's exit function, the `event_filter` slot is restored to empty. After the module source code is compiled into a .ko file, the system administrator only needs to use the `insmod` or `modprobe` commands to load the file, and the filtering function takes effect immediately; using the `rmmod` command to unload it removes the filtering function immediately. The entire process does not affect the original source code of the data input subsystem and does not require recompiling the kernel, achieving hot-swappable and on-demand deployment of the filtering function, greatly enhancing the system's flexibility and scalability.

[0053] In summary, this application provides a universal pre-event filtering mechanism for all input devices by constructing an event filtering registration module 101 and a core event processing module 102 within the core layer 100 of the data input subsystem. The event filtering registration module 101 provides a standardized interface for mounting filtering functions, freeing the filtering logic from being tied to specific device drivers, enabling cross-device reuse, and completely eliminating the code redundancy and maintenance burden caused by the previous custom development of the driver layer 200. The core event processing module 102 sets filtering points along the necessary path of event distribution, directly intercepting invalid events deep within the kernel, avoiding invalid transport in subsequent processing layers and user space, saving system resources and significantly improving the real-time performance of event processing. Simultaneously, the dynamic loading mechanism based on .ko files and the standardized function signature design make the development, deployment, and adjustment of the filtering function exceptionally simple, strongly supporting the customized needs of input event management in numerous fields such as industrial control, mobile terminals, and automotive systems.

[0054] Based on the same inventive concept, this application also provides a data input event filtering method corresponding to the data input event filtering system. Since the principle of the device in this application is similar to that of the data input event filtering system described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0055] Please see Figure 3 , Figure 3 A flowchart of the data input event filtering system provided in the embodiments of this application includes: S101, the event filtering registration module is used to receive custom filtering functions and write the custom filtering functions into the preset function pointer member of the device structure corresponding to the target input device.

[0056] S102, the core event processing module is used to determine whether the preset function pointer member in the device structure corresponding to the target input device that sent the event is not empty when receiving the event to be processed. If the preset function pointer member is not empty, the corresponding custom filtering function is called to filter the event to be processed, and the event to be processed is discarded when the custom filtering function returns a preset interception value.

[0057] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0058] The memory 420 stores machine-readable instructions that can be executed by the processor 410. When the electronic device 400 is running, the processor 410 and the memory 420 communicate via the bus 430. When the machine-readable instructions are executed by the processor 410, the steps of the method described above can be performed. For specific implementation details, please refer to the method embodiment, which will not be repeated here.

[0059] This application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it can execute the steps of the method described above. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0060] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0061] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0062] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0063] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0064] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0065] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data input event filtering system, characterized in that, Includes a core layer, which includes: The event filtering registration module is used to receive custom filtering functions and write the custom filtering functions into the preset function pointer member of the device structure corresponding to the target input device; The core event processing module is used to determine whether the preset function pointer member in the device structure corresponding to the target input device that sent the event is not empty when receiving an event to be processed. If the preset function pointer member is not empty, the module calls the corresponding custom filtering function to filter the event to be processed, and discards the event to be processed when the custom filtering function returns a preset interception value.

2. The system according to claim 1, characterized in that, The data input event filtering system also includes a driver layer and an event processing layer; The driver layer is used to convert hardware signals into events to be processed and to report the events to be processed to the core layer. The event processing layer is used to receive the pending event distributed by the core layer when the pending event has not been discarded, and to transmit the pending event to the user space.

3. The system according to claim 1, characterized in that, The custom filtering function is encapsulated in the kernel dynamic link file. When the kernel dynamic link file is loaded, the event filtering registration module writes the custom filtering function into the preset function pointer member.

4. The system according to claim 3, characterized in that, The registration interface corresponding to the event filtering registration module is provided by exporting symbolic functions, so that the kernel dynamic link file can call the registration interface to complete the writing of the custom filtering function.

5. The system according to claim 1, characterized in that, The input parameters of the custom filtering function include a device pointer pointing to the target input device and an event pointer pointing to the event to be processed. The return value of the custom filtering function includes a pass value and a preset intercept value.

6. The system according to claim 1, characterized in that, The custom filtering function includes a time interval filtering condition. The preset interception value is returned when the event to be processed meets the time interval filtering condition. The time interval filtering condition includes that the time interval between two events with the same encoding on the same input device is less than a preset threshold.

7. The system according to claim 6, characterized in that, The custom filtering function also includes a coordinate offset filtering condition. The preset interception value is returned when the event to be processed meets the coordinate offset filtering condition. The coordinate offset filtering condition includes that the coordinate offset of the touch event is less than a preset offset threshold.

8. A data input event filtering method, characterized in that, include: The event filtering registration module is used to receive custom filtering functions and write the custom filtering functions into the preset function pointer member of the device structure corresponding to the target input device; The core event processing module is used to determine whether the preset function pointer member in the device structure corresponding to the target input device that sent the event is not empty when receiving an event to be processed. If the preset function pointer member is not empty, the module calls the corresponding custom filtering function to filter the event to be processed, and discards the event to be processed when the custom filtering function returns a preset interception value.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in claim 8.

Images