The function name doesn't represent what the function really does.
Rename it and be consistent with the naming of other related functions
like wheel_set_scroll_timer() or wheel_cancel_scroll_timer().
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1241>
The custom implementation of the send-events mode for tablet pads does
not actually suspend and resume the device, so events continue to be
sent despite the device being theoretically disabled. Fix this by
removing the custom send-events implementation in favor of
evdev_dispatch's implementation.
Also add a simple test to ensure the send-events mode works.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1238>
The vast majority of plugins are only interested in a single or a few
devices. Require that they enable the frame callback for those devices
and don't notify them for any other frames.
Give each plugin a unique index and use that for a bitmask to check if
the plugin wants events for a particular device. If not, skip it.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1229>
If the button we want to map to isn't enabled by the kernel allow
setting the button nonetheless. On some tablets we only get the
actual number of button codes (e.g. BTN_STYLUS only on an Inspiroy 2S)
so not being able to map the eraser button to some other button makes
this whole feature a bit pointless.
Special-case BTN_STYLUS* because these are the ones we'll always allow.
This fixes an issue with the eraser button defaulting to BTN_STYLUS2
on some devices but it couldn't actually be set to that value by the
caller.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1231>
This adds the public API to configure an eraser button on a tablet tool
to emulate a normal button. In DEFAULT mode the eraser button will
simply do whatever it does by default (i.e. toggle to eraser).
In BUTTON mode the eraser button will be converted to a regular tool
button event, with libinput handling the underlying proximity event
madness.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1218>
Previously we used uint32_t for bitmasks but having a custom type means
we're less likely to confuse an int value with a mask type.
Two types of API here, the u32 api for passing in masks and a bit API
for passing in single bits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1218>
This makes event handling easier where plugins queue other event frames
per frame. Our initialization guarantees that our evdev code is alway
the last plugin in the series so in the no-plugin case we just pass on
to that.
The effective event flow is now:
evdev.c -> plugin1 -> plugin2 -> evdev-plugin.c -> evdev.c
except that no plugins exist yet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This adds a callback for plugins (and lua plugins) to inject an evdev
frame into the event stream. Unlike the prepend/append functions
this one injects the event at the bottom of the plugin stack as if
the device had sent the frame right then and there.
There's a drawback though: the event frame isn't marked as synthetic
so it cannot be identified without having a guard in the plugin so
the same frame is not reprocessed.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This adds a event queue pointer to each plugin that is set when the
plugin's evdev_frame() callback is invoked. If the plugin calls
libinput_plugin_queue_event_frame() during the callback the given
event frame is appended to an event frame list (starting with the
current frame). Once the callback completes, that frame list is
passed to the next plugin and each frame is replayed on the next plugin.
In the case of multiple plugins queueing events this effectively builds
a tree of frames which each level of the tree representing one plugin.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This adds the scaffolding for an internal plugin architecture. No such
plugin currently exists and any plugin implemented against this
architecture merely is plugin-like in the event flow, not actually
external to libinput.
The goal of this architecture is to have more segmented processing
of the event stream from devices to modify that stream before libinput
ever sees it. Right now libinput looks at e.g. a tablet packet and then
determines whether the tool was correctly in proximity, etc.
With this architecture we can have a plugin that modifies the event
stream that the tool is *always* correctly in proximity and the tablet
backend itself merely needs to handle the correct case.
The event flow will thus logically change from:
evdev device -> backend dispatch
to
evdev device -> plugin1 -> plugin2 -> backend dispatch
The plugin API is more expansive than we will use immediately, it is the
result of several different implementation branches that all require
different functionality.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This provides both some type-safety but also better readability of what
the integer we're passing around is supposed to be. In particular the
pad buttons are numeric buttons while the normal buttons are evdev
codes.
Future extension of this could be to also check for (or against) the
valid BTN_* ranges for a button code or keycode.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
