This is a leftover from the Lua plugin branch where the question of
whether to have public plugins before or after internal plugins is a
valid one. We don't have public plugins here, so let's remove this
fixme.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1269>
Fixes a regression causing missing scroll events on devices where the
kernel only sets REL_WHEEL/REL_HWHEEL but not the corresponding
hires events. On those devices we would get the legacy axis events but
no longer the new ones.
The mouse wheel plugin will correctly emulate missing hires events
but it doesn't attach to devices where the hires bit is never set.
This plugin can be very simple - since we know we enabled the code on
this device we don't need to keep any extra state around. If our frame
handler is called for this device we want to add the hi-res events.
Theoretically this breaks if the device has only one hi-res axis enabled
but not the other one (i.e. REL_WHEEL_HI_RES but only REL_HWHEEL) but
that's too theoretical to worry about.
Closes#1156
Fixes: 31854a829a ("plugin: only register the wheel plugin on devices that have a wheel")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1268>
mtdev is used only for MT Protocol A device of which there are quite
few. But that protocol is also a perfect example for event frames in ->
different event frame out so let's move this into the plugin pipeline.
Because the plugin doesn't really have full access to the device's
internals we set up mtdev base on the libevdev information rather than
just handing it the fd and letting it extract the right info.
A minor functionality change: previously mtdev-backed devices returned
zero on libinput_device_touch_get_touch_count(). Now it is hardcoded to
10 - the number of callers that care about this is likely near zero.
Because it's now neatly factored out into a plugin we can also make
mtdev no longer a strict requirement.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1245>
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>
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>
