search

oblitum / Interception

The Interception API aims to build a portable programming interface that allows one to intercept and control a range of input devices.
http://oblita.com/interception
1.32k stars 271 forks source link

Update filter predicate without disabling filter? #135

Closed cgalway-ecs closed 2 years ago

cgalway-ecs commented 2 years ago

Is it technically feasible to allow updating the filter predicate without turning the filter off? For example, let's say I have turned the filter on, with a filter value of All (0xFFFF), and a predicate that returns 1 for a certain mouse, and 1 for a certain keyboard (ie turn on the filter for just a specific mouse and keyboard, and filter everything coming from those two devices)

In this scenario, I am blocking the mouse movement, and taking some other action (for example inverting an axis)

Now let's say that I wish to stop filtering the keyboard

If I update my predicate to now return 0 for the keyboard, but still return 1 for the mouse, then call interception_set_filter, still with a filter value of All, the keyboard is still filtered :( It's odd, because I have logged whenever my predicate is called, and what it is returning for each device, and when I call interception_set_filter with a filter of All (Even though the filter is already set to All), it does call the predicate again, get a value of 0 for the keyboard, but it seems to ignore it for some reason. It seems that what I must do is to call interception_set_filter with a filter value of none (0x0), then re-call interception_set_filter with a filter value of All (0xFFFF) - only then does it obey the new predicate.

This could mean that if the user is moving the mouse while I unsubscribe from the keyboard, then some mouse movement is allowed through the filter, which is not what I want

Am I missing something / doing something wrong, or is this just how it is, and can't be changed?

oblitum commented 2 years ago

At the moment it's how it's, you're correct, to reapply filters cleaning up any previously ones that have been set, it's needed to manually do a set_filter to clean. If you're solely just overwriting filters (same predicate), then this is not needed, which is not your case, as the predicate changes. This is because the predicate will serve to point the devices for which filters should be applied solely, meaning no action is taken when it returns 0. Calling it twice should be instant, almost as in a single step if you take device events timespan for comparison, which takes much longer than a short programming loop of some API calls.